Scribd
Upload
152 views8 pages

SNIPED Sessions and ORA

The document discusses how to handle sessions that exceed the idle limit and become marked as SNIPED in the V$SESSION view. This can cause ORA-00020 errors when trying to connect. It demonstrates setting an IDLE_TIME profile limit, allowing sessions to become SNIPED, and then provides two methods to kill the SNIPED sessions - using ALTER SYSTEM KILL SESSION or killing the OS process directly.

Uploaded by

Rajab Tambwe
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
152 views8 pages

SNIPED Sessions and ORA

The document discusses how to handle sessions that exceed the idle limit and become marked as SNIPED in the V$SESSION view. This can cause ORA-00020 errors when trying to connect. It demonstrates setting an IDLE_TIME profile limit, allowing sessions to become SNIPED, and then provides two methods to kill the SNIPED sessions - using ALTER SYSTEM KILL SESSION or killing the OS process directly.

Uploaded by

Rajab Tambwe
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

SNIPED sessions and ORA-00020: maximum number of

processes (%s) exceeded
Posted by Kamran Agayev A. on December 14, 2010

When you implement the resource limit, the sessions that exceed the IDLE limit is marked as
SNIPED in V$SESSION view and you may get “ORA-00020: maximum number of processes
(%s) exceeded” error because Oracle doesn’t kill that session in OS level and it assumes it as a
“process”. So for this, you need to kill those sessions manually

Here I show a little demonstration of the whole process: – First of all, set the
RESOURCE_LIMIT parameter to TRUE to enforce the resource limit in database profiles

view source

print?

1 SQL> show parameter resource_limit


2 NAME                                 TYPE        VALUE
------------------------------------ -----------
3
------------------------------
4 resource_limit                       boolean     FALSE

5   
6 SQL> alter system set resource_limit=true;
7 System altered.

- Then create a profile and set IDLE_TIME  to 1 minute:

view source

print?

1 SQL> create profile test_profile limit


2   2  idle_time 1;
3 Profile created.

- Create a user and assign the profile to that user:

view source

print?
1 SQL> grant dba to usr identified by usr;
2 Grant succeeded.

3   
4 SQL> alter user usr profile test_profile;
5 User altered.

- Change the PROCESSES parameter to make the maximum number of operating system


processes lower

view source

print?

01 SQL> show parameter process


02 NAME                                 TYPE        VALUE
03 processes                            integer     150
04   
05 SQL> alter system set processes=25 scope=spfile;
06 System altered.

07   
08 SQL> startup force
09   
10 SQL> show parameter processes
11 NAME                                 TYPE        VALUE
12 processes                            integer     25

13   
14 SQL> select count(1) from v$process;
15   
16   COUNT(1)
17 ----------
18         22

Now open two different terminals and connect to the database with USR user:

view source

print?

1 sqlplus usr/usr
Check the view V$PROCESS. It should be 24

view source

print?

1 SQL> select count(1) from v$process;


2   
3   COUNT(1)
4 ----------
5         24

Now open third terminal and try to connect to the database with the user USR.You will get an
error because the count of the processes will reach the limit:

view source

print?

1 [oracle@localhost ~]$ sqlplus usr/usr


2   

3 ERROR:
4 ORA-00020: maximum number of processes (%s) exceeded
5   
6 Enter user-name: 
7   
8 SQL>

Now wait for a minute to reach the limit of the IDLE_LIMIT resource (we’ve set it to 1 minute)
and query the SYSDATE from any USR session:

view source

print?

01 SQL> select s.status, count(1), s.username from v$process p, v$session s


02 where paddr(+)=addr
03 group by s.status, s.username
04 order by 1;

05   
06 STATUS     COUNT(1) USERNAME
07 -------- ---------- ------------------------------
08 ACTIVE            1 SYS

09 ACTIVE           16
10 INACTIVE          2 SYS
11 SNIPED            2 USR
12                   3

That’s the issue. If you try to connect to the database, you’ll get ORA-00020 error again. Please
note that SNIPED doesn’t mean that it’s KILLED. It is not either killed, nor active. The user is
not able to run any query, however it holds a process on OS level:

view source

print?

1 SQL> select count(1) from v$process;


2   
3   COUNT(1)
4 ----------
5         24

Run any query with already connected (and SNIPED) USR user. You’ll get the following error:

view source

print?

1 SQL> select sysdate from dual;


2 select sysdate from dual

3*
4 ERROR at line 1:
5 ORA-02396: exceeded maximum idle time, please connect again
6 SQL>

Now query V$SESSION and V$PROCESS views again:

view source

print?
01 SQL> select s.status, count(1), s.username from v$process p, v$session s
02 where paddr(+)=addr
03 group by s.status, s.username
04 order by 1;

05   
06 STATUS     COUNT(1) USERNAME
07 -------- ---------- ------------------------------
08 ACTIVE            1 SYS

09 ACTIVE           16
10 INACTIVE          2 SYS
11 SNIPED            1 USR
12                   4

13   
14 SQL> select count(1) from v$process;
15   
16   COUNT(1)
17 ----------
18         24

The process will be free only when you “exit” from Sql*Plus. Exit from the session that you got
an error and query V$PROCESS again:

view source

print?

1 SQL> select count(1) from v$process;


2   
3   COUNT(1)
4 ----------
5         23

To kill the SNIPED sessions you have two options. The first option is to run ALTER SYSTEM
KILL SESSION command. For this you need to get SID and SERIAL# of the sniped session.

view source

print?

01 SQL> select sid, s.serial#, status from v$process p, v$session s


02 where paddr=addr
03 and s.username='USR';
04   

05        SID    SERIAL# STATUS


06 ---------- ---------- --------
07          9         10 SNIPED
08   
09 SQL> alter system kill session '9,10' immediate;
10 System altered.

11   
12 SQL> select s.status, count(1), s.username from v$process p, v$session s
13 where paddr(+)=addr
14 group by s.status, s.username
15 order by 1;  
16   

17 STATUS     COUNT(1) USERNAME


18 -------- ---------- ------------------------------
19 ACTIVE            1 SYS
20 ACTIVE           16
21 INACTIVE          2 SYS
22 KILLED            1 USR
23                   3

After some seconds you’ll see that the session is cleared from both views:

view source

print?

1 SQL> /
2   

3 STATUS     COUNT(1) USERNAME


4 -------- ---------- ------------------------------
5 ACTIVE            1 SYS
6 ACTIVE           16
7 INACTIVE          2 SYS
8                   3

However, due to some bugs, sometimes you may not get the sessions killed using ALTER
SYSTEM KILL SESSSION command. For this, you need to kill the process from OS level.

view source

print?

01 SQL> select spid, status from v$process p, v$session s


02 where paddr=addr
03 and s.username='USR';  
04   

05 SPID         STATUS
06 ------------ --------
07 2795         SNIPED
08   
09 [oracle@localhost ~]$ kill -9 2795
10   
11 SQL> select spid, status from v$process p, v$session s
12 where paddr=addr
13 and s.username='USR';  
14   
15 no rows selected
16   
17 SQL>

Run any sql command on the killed session:

view source

print?

1 SQL> select sysdate from dual;


2 select sysdate from dual

3*
4 ERROR at line 1:
5 ORA-03135: connection lost contact
6   
7 SQL>

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy