You can use LICENSE_MAX_SESSIONS to associate with your license,
although I don't know why you would want to do it if your database is "in-house"
[if you are an ASP you might want to restrict the number of sessions
running against the database on *your* server].
SESSIONS has nothing to do with License. It is best left at its default [ie NOT defined in the init<SID>.ora] whereby it becomes PROCESSES*1.1 Else, if you really do have multiple sessions, you could set it higher.
Hemant
At 06:58 AM 04-03-03 -0800, you wrote:
Tim and Dennis: Thanks for your responses:
SVRMGR> show parameter session
NAME TYPE VALUE
----------------------------------- ------- ------------------------------
license_max_sessions integer 0
license_sessions_warning integer 0
session_cached_cursors integer 10
sessions integer 300
SVRMGR>
The SESSION parameter is hard-coded in our init.ora file to the value 300. The value for PROCESSES is set to 512. We have hard-coded our SESSION parameter because our number of licenses is set to 300 however, my intuition tells me that the SESSION parameter should not be set based on our number of licenses. Can anybody confirm this for me?
I have also set up a TAR with Oracle Support, and they too say we need to increase the SESSION parameter (but we want to confirm it has no link to licenses).
Thanks again!
Sam Bootsma
416-415-5000 x4933
-----Original Message----- From: Tim Gorman [mailto:[EMAIL PROTECTED] Sent: March 3, 2003 4:54 PM To: Multiple recipients of list ORACLE-L Subject: Re: ORA-00018: maximum number of sessions exceeded
I don't recall if the V$RESOURCE_LIMIT view existing in 7.3.4, but you might want to check. It is a better diagnostic point for that particular resource...
The "init.ora" parameter SESSIONS is related to the ORA-00018 error message, not any of the licensing parameters. Please use SHOW PARAMETER SESSIONS in SVRMGR to display its value. Generally, people let the value of the SESSIONS parameter default to 1.1 * PROCESSES, but you can increase it if you like.
Hope this helps... ----- Original Message ----- From: <mailto:[EMAIL PROTECTED]>Sam Bootsma To: <mailto:[EMAIL PROTECTED]>Multiple recipients of list ORACLE-L Sent: Monday, March 03, 2003 2:24 PM Subject: ORA-00018: maximum number of sessions exceeded
We are running Oracle 7.3.4.5.0 on an IBM/AIX RISC System/6000: Version 2.3.4.0.0.
This afternoon, our users started getting the error message ORA-00018: maximum number of sessions exceeded. As time went on, the number of sessions was decreasing (as shown by the count of rows in v$session). However, Oracle still did not allow connections. This lasted for about 40 minutes.
The sessions parameter in the initialization parameter file showed 300.
Querying v$session showed 246 rows.
Querying v$license reported: SQL> select * from v$license;
SESSIONS_MAX SESSIONS_WARNING SESSIONS_CURRENT SESSIONS_HIGHWATER USERS_MAX ------------ ---------------- ---------------- ------------------ --------- 0 0 204 248 0
There seems to be a contradiction here: 300 sessions in init.ora; sessions_highwater at 248, and Oracle not allowing connections because the maximum has been reached.
Has anybody encountered this problem before. Is there a simple reason for this erratic behavior?
Management is looking for an answer as to why this has happened. Thanks for any input!
Sam Bootsma <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Hemant K Chitale My personal web site is : http://hkchital.tripod.com
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Hemant K Chitale INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
