Esse seu workaround.. isso também poderia ser chamado de "RTA - Recurso Tecnico Alternativo" um nome mais pomposo para a gambi, afinal fica feio falar pro cliente que fez uma "gambiarra"... Kkkk
mas as vezes a gente tem que lançar mão dessas tecnicas mesmo.. Ta lembrando o caso do outro thread do problema que tava rolando com o Nagios, que o colega estava reclamando que de vez em quando travava o banco. O que nos conforta é que é tudo nessa vida é codigo, e código sempre tem bug.. tomara que a Oracle responda isso rapido, se é que o problema está lá, siga com sua pesquisa enquanto isso 2017-12-12 18:20 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] <oracle_br@yahoogrupos.com.br>: > > > Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um > workaround vulgo gambiarra para poder sanar o problema do cliente enquanto > nao se descobri a causa raiz, um chamado com a Oracle ja foi aberto para > suporte. > > Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo > pid do SO, tanto que ela existe na v$process, e nao na v$session. Tanto que > funcionou! > > Essa questao do alter system disconnect session eu vou testar tambem, > obrigado pela dica. > > > Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br > [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: > > > > 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 > > > >
