Bom, antes de responder algumas obs importantes : 1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente : necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas possibilidades, que vão desde falha na infra de rede fazendo a comunicação com o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que sai criando conexões novas sem desativar anteriores, coisas assim.... Em ALGUNS CASOS inclusive pode ser possível como work-around vc solicitar que o banco mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz antes de tudo...
2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : http://www.fabioprado.net/2014/05/matando-sessoes-no-oracle-database.html é uma das refs pra ele 3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu banco tá usando MTS/SHARED SESSIONs.... Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc ID 387077.1) é possível que o ponteiro em memória do processo que atendia à sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO obviamente teu JOIN : SELECT p.spid FROM v$session s, v$process p WHERE s.paddr = p.addr.... NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados para encontrar o SPID (system pid, o id da task no Sistema Operacional) na V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, provavelmente (já que seu banco é 11g) deve ser : select spid from v$process where addr=(select creator_addr from v$session where STATUS='KILLED'); Ou alguma variação muito próxima.... Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus via script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos tipo : ==> vc tem um script sqlplus chamado gera_kills.sql contendo : set term off feedback off verify off pages 0 lines 500 trimspool on head off spool /tmp/kill_sessions.sh select 'kill -9 ' || spid from v$process where addr=(select creator_addr from v$session where STATUS='KILLED') / select 'exit' || chr(10) from dual / spool off exit Aí teu shell script principal seria tipo : #!/bin/sh sqlplus system/senhadele @gera_kills.sql /tmp/kill_sessions.sh exit ===> ok ? imho é MUUUITO mais simples vc gerar shell script a partir do sqlplus do que fazer o sqlplus se comunicar/retornar valores pro SO....Mas se por qquer motivo for isso que vc quer ok, é mais chatinho de fazer mas também é possivel, veja https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:430819636473 ou https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable para exemplos.... []s Chiappa
