Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1538
  • Last Modified:

Maximum number of processes exceeded

Oralce 8.1.6 is running on a Sun Solaris 220R box.
The maximum number of processes is set to 200, yet a few days after running this limit is reached.

Doing a ps list or a top listing shows over 200 processes, and they almost all look like dead oracle connections.

The v$session table only shows about 25 connections.
The v$process table shows all 200 but not much more information than that.

What I need to know is what caused these 200 dead connections?

v$session has the information I want (MACHINE, TERMINAL, PROGRAM) but it only has that info on current connections. The dead ones don't show up there.

They must have been in v$session at one point, but that point has passed.

I was thinking maybe have oracle automatically copy anything that enters into v$session into another table where they won't be removed, so that I'll have sort of a transaction log. But I have no idea how to set up 'triggers' do this sort of thing.

1 Solution

THere are a few parameters that can help with this:
1) Dead Connection Detection (DCD)
DCD is initiated on the server when a connection is established.  At The timer interval is set by providing a non-zero value in minutes for  the SQLNET.EXPIRE_TIME parameter in the sqlnet.ora file.
  When the timer expires, SQL*Net on the server sends a "probe" packet to the client.  (In the case of a database link, the destination of the link constitutes the server side of the connection.)  The probe is essentially an empty SQL*Net packet and does not represent any form of SQL*Net level data, but it creates data traffic on the underlying protocol.
  If the client end of the connection is still active, the probe is discarded, and the timer mechanism is reset.  If the client has terminated abnormally, the server will receive an error from the send call issued for the probe, and SQL*Net on the server will signal the operating system to release the connection's resources.

In the SQLNET.ORA file on the host,  add the following line:

2) Setup a generic profile in Oracle and set the idle time to expire the processes after a reasonable amount of time idle.
Taken from the Oracle8i SQL Reference Release 3 (8.1.7)
Use the CREATE PROFILE statement to create a profile, which is a set of limits on database resources. If you assign the profile to a user, that user cannot exceed these limits.

SESSIONS_PER_USER -- Specify the number of concurrent sessions to which you want to limit the user.
IDLE_TIME  -- Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit.  
CONNECT_TIME  -- Specify the total elapsed time limit for a session, expressed in minutes.  
For example:   a profile to limit idle time to 1 hour  would be:

CREATE PROFILE  limit_time
    idle_time 60;

Then you need to alter the user accounts to have that profile as their default.

Also, you have to add the following parameter in you init.ora file to enable profiles and resource limits:

RESOURCE_LIMIT determines whether resource limits are enforced in database profiles:
TRUE: enables the enforcement of resource limits.
FALSE: disables the enforcement of resource limits.

This should be a start that will help clear up those dead connections.


Hi -- an addition.

Most of the time,  I find the above mentioned parameters helpful --   I have found that

1) DCD helps especially when users power off their desktops with active sqlnet connections.
2) Profiles help with the long inactive sessions.

One of the biggest reasons I have found has turned out to be the application logic!
I number of people forgetting to close or disconnect their session --  A very big problem in a lot of web applications.

Hope you find this and the above information helpful.
SembianceAuthor Commented:
Ok, I will try those suggestions.
What I'm really after is trying to track down what is CAUSING these dead connections. I feel it is a third party software solution we are using here, but I need proof.
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Check v$process view. I think that you can join v$session, v$process and v$sesstat in order to have view on processes.
You may also want to look at the sqlnet.log file for information on the connections.
SembianceAuthor Commented:
The network/admin/sqlnet.log says tracing is not on. How do I enable tracing? This will record all connections then correct?

You can enable tracing on the host through two methods:

1)Turn tracing on via NetMan.  Go to the object screen for the desired object and look for 'tracing'. You will then be asked to specify the trace level, directory and filename.  For level you can specify off, user or admin.  16 is the highest level of tracing.

2)Manual Method:
To enable tracing for the listener, set the following parameter in the LISTENER.ORA file:

Where:  OFF disables tracing.
        USER enables limited tracing.
        ADMIN enables detailed tracing.

You are also going to need to set the following in your SQLNET.ORA file on the host for the log & trace file locations  (the defaults are a little obscure..):

Pretty much that is it....


Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now