Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:kill_disconnect_session

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
dba:kill_disconnect_session [2015/01/02 19:24] – [Eine Sessoin beenden] gpipperrdba:kill_disconnect_session [2015/01/16 16:23] (aktuell) – [Eine gekillete Session in der DB wiederfinden] gpipperr
Zeile 100: Zeile 100:
  * "ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';"  * "ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';"
  * "ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;"  * "ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;"
 +
 +
 +==Unterschied zwischen KILL SESSION und DISCONNECT SESSION ==
 +
 +Wird eine Session mit "ALTER SYSTEM DISCONNECT SESSION" beendet, wird der dazugehörige User Prozess gleich mit beendet. Bei einem Kill wird die Session nur markiert und abgehängt, der PMON räumt dann später auf.
 +
 +
 +== OS Prozess beenden ==
 +
   
 Alternativ kann auch der Prozess der Session mit OS Mitteln hart beendet werden: Alternativ kann auch der Prozess der Session mit OS Mitteln hart beendet werden:
Zeile 109: Zeile 118:
 === Eine gekillete Session in der DB "wiederfinden" ==== === Eine gekillete Session in der DB "wiederfinden" ====
  
-Wenn eine Session mit "kill Session" beendet wird wird das Session object (und alle abhängigen Objeckte unter der Session) vom orginal Eltern Prozesse abgehängt  +Wenn eine Session mit "kill Session" beendet wird wird das Session Objekt (und alle abhängigen Objeckte unter der Session) vom original Eltern Prozesse abgehängt und unter einen "PSEUDO" Prozess gehängt.  
-und unter einen "PSEUDO" Prozess gehängt. Der PMON Prozess prüft regelmäßig auf diese "PSEUDO" Prozesse und bereinigt diese.+ 
 +Der PMON Prozess prüft regelmäßig auf diese "PSEUDO" Prozesse und bereinigt diese.
  
 Dies hat aber zur Folge das unter der ursprüngliche PADDR Adresse in der V$SESSION der Prozess nicht mehr gefunden werden kann, eine neue PADDR wird vergeben. Dies hat aber zur Folge das unter der ursprüngliche PADDR Adresse in der V$SESSION der Prozess nicht mehr gefunden werden kann, eine neue PADDR wird vergeben.
  
-Um das nun nach zuverfolgen stehen in der V$SESSION diese Spalten ab 11g zur Verfügung:+Um das nun nach zuverfolgen stehen in der V$SESSION diese Spalten zur Verfügung:
  
  * CREATOR_ADDR - state object address of creating process  * CREATOR_ADDR - state object address of creating process
  * CREATOR_SERIAL# - serial number of creating process  * CREATOR_SERIAL# - serial number of creating process
    
-Mit der  CREATOR_ADDR  kann nun die ADDR Spalte in der V$PROCESS gejoined werden um den killeten  Prozess der alten Session wieder zu finden +Mit der  CREATOR_ADDR  kann nun die ADDR Spalte in der V$PROCESS gejoined werden um den gekillten  Prozess der alten Session wieder zu finden
- +
-SQL: +
-<code> +
-select spid +
-     , program  +
-  from v$process  +
- where program!= 'PSEUDO' +
-    and addr not in (select paddr from v$session) +
-    and addr not in (select paddr from v$bgprocess) +
-    and addr not in (select paddr from v$shared_server) +
-/     +
-     +
-</code>+
  
  
 **ab 11g 11.1.0.6 ** **ab 11g 11.1.0.6 **
  
-Folgende zwei neue Views helfen die Session besser wieder zufinden:+Folgende zwei neue Views helfen die Session besser wieder zu finden:
  
  
Zeile 153: Zeile 150:
  
  
 +
 +<code sql>
 +ttitle left "Processes without entries in the v$session" skip 2
 +
 +
 +column process_id format a8     heading "Process|ID"
 +column inst_id    format 99     heading "Inst|ID"
 +column username   format a8     heading "DB User|name"
 +column osusername   format a8   heading "OS User|name"
 +column pname       format a8    heading "Process|name"
 +
 +select --p.inst_id  
 +      to_char(p.spid) as process_id
 + , p.username as osusername
 + , p.pname
 + , p.program
 +from v$process p
 + where p.program!= 'PSEUDO' 
 +   and p.addr not in (select gv.paddr from v$session gv)
 +   and p.addr not in (select bg.paddr from v$bgprocess bg)
 +   and p.addr not in (select ss.paddr from v$shared_server ss)
 +--order by p.inst_id 
 +/  
 +  
 +-- new column creator_addr in v$session!
 +
 +ttitle left  "get the prozess of a killed session with the help of the creator_addr" skip 2
 +
 +
 +select --p.inst_id  
 +      to_char(p.spid) as process_id
 + , p.username as osusername
 + , p.pname
 + , p.program
 +from v$process p
 + where p.addr in (select gv.creator_addr from v$session gv where status in ('KILLED') )
 +/
 +
 +ttitle off
 +</code>
 +
 +
 +=== SNIPED Sessions ====
 +..
 +
 +
 +Sniped - the session has passed the idle_time limit defined in user profile. The session will remain snipped until the client communicates with the db again, when it will get "ORA-02396: exceeded maximum idle time, please connect again" and the session is removed from v$session.
 +
 +...
 +
 +When IDLE_TIME is set in the users' profiles or the default profile. This will kill the sessions in the database (status in v$session now becomes SNIPED) and they will eventually disconnect. It does not always clean up the Unix session (LOCAL=NO sessions). At this time all oracle resources are released but the shadow processes remains and OS resources are not released. This shadow process is still counted towards the parameters of init.ora.
 +This process is killed and entry from v$session is released only when user again tries to do something. Another way of forcing disconnect (if your users come in via SQL*Net) is to put the file sqlnet.ora on every client machine and include the parameter "SQLNET.EXPIRE_TIME" in it to force the close of the SQL*Net session.
 +
 +...
 +
 +see https://community.oracle.com/thread/531765 
    
 <note important>In Arbeit</note> <note important>In Arbeit</note>
dba/kill_disconnect_session.txt · Zuletzt geändert: 2015/01/16 16:23 von gpipperr