Algumas vezes sess\u00f5es ficam \u201cpresas\u201d no banco de dados com status KILLED. Elas est\u00e3o\/s\u00e3o mortas e mesmo assim n\u00e3o desaparecem da gv$session, ficam como \u201czumbis\u201d. Algumas podem at\u00e9 impedir o shutdown do banco de dados. Aqui vamos ver como resolver isso.<\/p>\n
Felizmente resolver este problema n\u00e3o \u00e9 complicado, mas temos que verificar algumas coisas antes de sair matando os processos do Oracle. De forma resumida (e bem resumida) toda a conex\u00e3o feita pelo usu\u00e1rio ao banco de dados cria um processo no servidor que fica respons\u00e1vel por fazer a comunica\u00e7\u00e3o com o kernel do banco de dados. Ao finalizarmos este processo a conex\u00e3o do usu\u00e1rio \u00e9 terminada e o Oracle libera a sess\u00e3o do usu\u00e1rio.<\/p>\n
<\/p>\n
No exemplo abaixo temos uma lista de sess\u00f5es que est\u00e3o marcadas como \u201ckilled\u201d na gv$session, todas estas sess\u00f5es foram finalizadas com \u201calter system kill session\u201d mas mesmo assim continuam aparecendo.<\/p>\n
SQL> SELECT s.inst_id, s.sid, s.SERIAL#, s.STATUS, s.USERNAME, s.MACHINE\r\n 2 FROM gv$session s\r\n 3 WHERE s.status = 'KILLED'\r\n 4 \/\r\n\r\n INST_ID SID SERIAL# STATUS USERNAME MACHINE\r\n---------- ---------- ---------- -------- ------------------------------ ----------------------------------------------------------------\r\n 3 84 44325 KILLED DJE lpb6-opg32t\r\n 2 198 51965 KILLED DJE lpb6-opg32t\r\n 1 233 34653 KILLED DJE lpb6-opg32t\r\n 1 257 15969 KILLED DJE lpb6-opg32t\r\n\r\nSQL><\/pre>\nMesmo a sess\u00e3o aparecer listada como \u201ckilled\u201d e demorar para sumir da gv$session n\u00e3o significa problema, muitas vezes a sess\u00e3o pode estar realizando rollback. Para verificarmos isso, podemos usar a consulta abaixo, caso tenha algum retorno (de alguma sess\u00e3o com status \u201ckilled\u201d) n\u00e3o podemos finalizar o seu processo no sistema operacional.<\/p>\n
SQL> select t.INST_ID\r\n 2 , s.sid\r\n 3 , s.program\r\n 4 , t.status as transaction_status\r\n 5 , s.status as session_status\r\n 6 , s.lockwait\r\n 7 , s.pq_status\r\n 8 , t.used_ublk as undo_blocks_used\r\n 9 , decode(bitand(t.flag, 128), 0, 'NO', 'YES') rolling_back\r\n 10 from\r\n 11 gv$session s\r\n 12 , gv$transaction t\r\n 13 where s.taddr = t.addr\r\n 14 and s.inst_id = t.inst_id\r\n 15 and s.STATUS = 'KILLED'\r\n 16 order by t.inst_id;\r\n\r\n INST_ID SID PROGRAM TRANSACTION_STATUS SESSION_STATUS LOCKWAIT PQ_STATUS UNDO_BLOCKS_USED ROLLING_BACK\r\n---------- ---------- ------------------------------------------------ ------------------ -------------- ---------------- --------- ---------------- ------------\r\n\r\nSQL><\/pre>\nComo visto, n\u00e3o existe nenhuma sess\u00e3o fazendo rollback e podemos continuar na tentativa de remover as sess\u00f5es. Como disse acima, toda a sess\u00e3o do usu\u00e1rio cria um processo no servidor do banco de dados. Voc\u00ea pode verificar estes processos atrav\u00e9s da gv$process e fazer uma rela\u00e7\u00e3o com a gv$session para mapear as sess\u00f5es dos usu\u00e1rios com os processos do servidor. Se consultarmos os processos das sess\u00f5es marcadas como “killed” n\u00e3o temos retorno. Isso \u00e9 interessante, pois nenhuma sess\u00e3o fica sem processo associado no Oracle.<\/p>\n
SQL> SELECT s.username, s.osuser, s.machine, s.sid, s.serial#, p.spid\r\n 2 FROM gv$session s, gv$process p\r\n 3 WHERE s.inst_id = p.inst_id\r\n 4 AND s.paddr = p.addr\r\n 4 AND s.username IS NOT NULL\r\n 5 AND s.STATUS = 'KILLED'\r\n 6 \/\r\n\r\nUSERNAME OSUSER MACHINE SID SERIAL# SPID\r\n------------------------------ ------------------------------ ---------------------------------------------------------------- ---------- ---------- ------------------------\r\n\r\nSQL><\/pre>\nPodemos verificar o que estas sess\u00f5es est\u00e3o esperando, uma simples consulta na gv$session_wait pode ajudar. Abaixo com o retono da consulta identificamos que as sess\u00f5es marcadas como \u201ckilled\u201d est\u00e3o esperando retorno do usu\u00e1rio, a coluna \u201cwait_time\u201d mostra que o Oracle est\u00e1 esperando o retorno do cliente (wait_time = 0 significa que o Oracle est\u00e1 aguardando o cliente). Provavelmente a sess\u00e3o recebeu o kill e tentou comunicar isso ao cliente, como n\u00e3o conseguiu e ficou no limbo.<\/p>\n
SQL> SELECT sw.INST_ID, SW.SID, SW.SEQ#, SW.EVENT, SW.STATE, sw.WAIT_TIME\r\n 2 FROM gv$session_wait sw\r\n 3 WHERE sw.sid IN (SELECT sid FROM gv$session s WHERE s.status = 'KILLED' AND s.inst_id = sw.INST_ID)\r\n 4 ORDER BY sw.inst_id\r\n 5 \/\r\n\r\n INST_ID SID SEQ# EVENT STATE WAIT_TIME\r\n---------- ---------- ---------- ---------------------------------------------------------------- ------------------- ----------\r\n 1 233 6288 SQL*Net message from client WAITING 0\r\n 1 257 39818 SQL*Net message from client WAITING 0\r\n 2 198 1422 SQL*Net message from client WAITING 0\r\n 3 84 33615 SQL*Net message from client WAITING 0\r\n\r\nSQL><\/pre>\nPossivelmente ap\u00f3s a receber o kill e tentar comunicar o cliente o Oracle modificou o \u201cpaddr\u201d da sess\u00e3o. Assim, a liga\u00e7\u00e3o entre a gv$session e a gv$process foi \u201cinterrompida\u201d. Partindo disso, podemos localizar todos os processos sem rela\u00e7\u00e3o com sess\u00f5es. A consulta abaixo retorna os processos sem sess\u00f5es, como estamos em um ambiente RAC observe as inst\u00e2ncias de cada sess\u00e3o.<\/p>\n
SQL> SELECT p.INST_ID, p.pid, p.serial#, p.spid, p.program\r\n 2 FROM gv$process p\r\n 3 WHERE p.spid is not null\r\n 4 AND NOT EXISTS (SELECT 1 FROM gv$session s WHERE s.inst_id = p.inst_id and s.paddr = p.addr)\r\n 5 AND p.pname is null\r\n 6 ORDER BY p.inst_id\r\n 7 \/\r\n\r\n INST_ID PID SERIAL# SPID PROGRAM\r\n---------- ---------- ---------- ------------------------ ------------------------------------------------\r\n 1 115 210 24011 oracle@exadb01.tjsc.jus.br\r\n 1 79 134 4533 oracle@exadb01.tjsc.jus.br\r\n 2 110 150 29153 oracle@exadb02.tjsc.jus.br\r\n 3 53 214 24512 oracle@exadb03.tjsc.jus.br\r\n\r\nSQL><\/pre>\nA coluna \u201cspid\u201d nos d\u00e1 o n\u00famero do processo do sistema operacional, para finalizar ele basta verificar se est\u00e1 como \u201cLOCAL=NO\u201d. Assim, sabemos que \u00e9 uma conex\u00e3o do usu\u00e1rio e nenhum processo interno do Oracle.<\/p>\n
Verificando o processo e fazendo o \u201ckill -9\u201d no sistema operacional a sess\u00e3o com status “killed” \u00e9 removida do Oracle. Abaixo, observe a inst\u00e2ncia (servidor), o tipo do processo e seu n\u00famero; relacione com o resultado da \u00faltima consulta.<\/p>\n
[root@exadb01 ~]# ps -ef |grep 24011\r\nroot 14628 14154 0 14:24 pts\/4 00:00:00 grep 24011\r\noracle 24011 1 0 Aug28 ? 00:00:05 oracleopg51 (LOCAL=NO)\r\n[root@exadb01 ~]# ps -ef |grep 4533\r\noracle 4533 1 0 Aug28 ? 00:00:00 oracleopg51 (LOCAL=NO)\r\nroot 14826 14154 0 14:24 pts\/4 00:00:00 grep 4533\r\n[root@exadb01 ~]#\r\n[root@exadb01 ~]#\r\n[root@exadb01 ~]# kill -9 24011 \r\n[root@exadb01 ~]# kill -9 4533\r\n[root@exadb01 ~]#\r\n[root@exadb01 ~]# ssh exadb02\r\nLast login: Mon Jun 24 17:27:12 2013 from 10.17.42.21\r\n[root@exadb02 ~]#\r\n[root@exadb02 ~]# ps -ef |grep 29153\r\nroot 25421 25226 0 14:25 pts\/0 00:00:00 grep 29153\r\noracle 29153 1 0 Aug28 ? 00:00:17 oracleopg52 (LOCAL=NO)\r\n[root@exadb02 ~]# kill -9 29153\r\n[root@exadb02 ~]#\r\n[root@exadb02 ~]#\r\n[root@exadb02 ~]# ssh exadb03\r\nLast login: Mon Jun 24 17:27:47 2013 from 10.17.42.21\r\n[root@exadb03 ~]#\r\n[root@exadb03 ~]# ps -ef |grep 24512\r\nroot 22948 22815 0 14:25 pts\/0 00:00:00 grep 24512\r\noracle 24512 1 0 Aug28 ? 00:00:12 oracleopg53 (LOCAL=NO)\r\n[root@exadb03 ~]# kill -9 24512\r\n[root@exadb03 ~]#<\/pre>\nSe verificarmos, n\u00e3o existe mais nenhum processo na gv$process sem rela\u00e7\u00e3o na gv$session, bem como nenhum sess\u00e3o marcada como \u201ckilled\u201d. Algumas vezes o Oracle demora alguns segundos at\u00e9 remover a sess\u00e3o ap\u00f3s o kill do sistema operacional.<\/p>\n
SQL> SELECT p.INST_ID, p.pid, p.serial#, p.spid, p.program\r\n 2 FROM gv$process p\r\n 3 WHERE p.spid is not null\r\n 4 AND NOT EXISTS (SELECT 1 FROM gv$session s WHERE s.inst_id = p.inst_id and s.paddr = p.addr)\r\n 5 AND p.pname is null\r\n 6 ORDER BY p.inst_id\r\n 7 \/\r\n\r\n INST_ID PID SERIAL# SPID PROGRAM\r\n---------- ---------- ---------- ------------------------ ------------------------------------------------\r\n\r\nSQL> \r\nSQL> SELECT s.inst_id, s.sid, s.SERIAL#, s.STATUS, s.USERNAME, s.MACHINE\r\n 2 FROM gv$session s\r\n 3 WHERE s.status = 'KILLED'\r\n 4 \/\r\n\r\n INST_ID SID SERIAL# STATUS USERNAME MACHINE\r\n---------- ---------- ---------- -------- ------------------------------ ----------------------------------------------------------------\r\n\r\nSQL><\/pre>\n