Userlimit
- 1. Limiting concurrent connections Administration Tips Limiting concurrent connections by Users Having Users make multiple connections to a database is a problem for a variety of reasons. Firstly, it chews up resources. Each connection acquires (in dedicated server mode, at least) a Server Process and a PGA –which means each connection starts using up memory and CPU cycles, even if the session itself is sitting their doing nothing very strenuous. Secondly, it’s a potential security issue: if a User is logged on 6 times, it is unlikely that they can be physically present at all 6 workstations simultaneously, which means the ones they aren’t at are wide-open to abuse by passing disgruntled employees. It’s therefore a very good idea to limit the maximum number of concurrent connections a User is permitted to make to a database, and the tool used to do that is the Resource Profile, which has been around since at least Oracle 7. A resource profile allows the DBA to limit a number of things that a User can do –for example, a maximum connection time can be specified (e.g., 480 minutes, or 8 hours), or a maximum idle time. But for our purposes, we can concentrate on the ability to limit the number of sessions a User is permitted to have running at any one time. That’s governed by a particular attribute of a resource profile, called SESSIONS_PER_USER. Every User has a profile already, even if you’ve never been aware of it, or made use of the fact. That profile is called ‘DEFAULT’, and is the one all Users acquire (by default!) when first created, unless you specify another named profile. A quick solution to the concurrent connections problem would thus involve simply editing the DEFAULT profile, like this: ALTER PROFILE DEFAULT SESSIONS_PER_USER 2; … and that would then prevent all Users from ever acquiring more than 2 concurrent sessions (although it will only take effect when they start re-connecting to the database). Note that there is no equals sign between the attribute name and its setting. A more subtle approach would be to allow some Users to make 3 connections, others to create 5. For that sort of discrimination, you’ll need to create your own profiles, like this: CREATE PROFILE BLAH3 LIMIT SESSIONS_PER_USER 3; CREATE PROFILE BLAH5 LIMIT SESSIONS_PER_USER 5; You then have to assign the right profile to the right user, like this: Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 2
- 2. Limiting concurrent connections Administration Tips ALTER USER FRED PROFILE BLAH3; ALTER USER MARY PROFILE BLAH5; … and so on. Next time Fred tries to log on multiple times, he’ll get the following error message on his fourth attempt: ERROR:ORA-02391: EXCEEDED SIMULTANEOUS SESSIONS_PER_USER LIMIT There is one extremely important point to know about resource profiles, however: they take no effect whatsoever until you switch them on. That is, even though they have been created, and properly assigned to all Users, no-one will have any connection limits until you tell the database to actually start enforcing the limits. That’s done with the following command: ALTER SYSTEM SET RESOURCE_LIMIT=TRUE; That switches on profile limits for the duration of the Instance, and for new connections only. A more permanent fix is to edit your init.ora, and enter the line resource_limit=true there. That way, every time you bounce the Instance, you’ll find resource profile limit being enforced. (Incidentally, any sessions a User already has running when you assign him the new profile and switch resource limiting on with the ‘alter system’ command are counted against his allowed total. So if a User already has 4 connections when you suddenly start limiting him to just 3, he will immediately not be able to make a fifth connection. However, the original 4 are not disconnected, and are allowed to proceed as normal). Copyright © Howard Rogers 2001 10/18/2001 Page 2 of 2