Re: [oracle_br] Re: AJuda script shell
Obrigado Angelo, isso mesmo.k, com ajuda dos amigos acima, consegui fazer esse RTA :) Em Quinta-feira, 14 de Dezembro de 2017 11:40, "angelo angelolis...@gmail.com [oracle_br]" escreveu: 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] : 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]" 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 sim
Re: [oracle_br] Re: AJuda script shell
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] : > > > 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]" 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
Re: [oracle_br] Re: AJuda script shell
Seguem obs : "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." ok : apenas não esqueça que como eu falei NÂO NECESSARIAMENTE é a Oracle que vai solucionar - como eu disse, NADA IMPEDE por exemplo de ser um prob na rede digamos, que causa perda de comunicação com o banco, OU bug/falha no middleware (ODBC é useiro e vezeiro em coisas do tipo), pode ser app porquinha que abre a conexão e não a encerra no final do trabalho Blz ??? E nem preciso dizer, vc vai implementar o work-around de sair matando as sessões MAS NÂO PODE deixar de perseguir até encontrar a causa raiz e a consertar, senão vc fica eternamente "correndo atrás do rabo", "enxugando gelo", como se diz... E não deixe de Analisar/testar/validar a possibilidade de implementar DCD+profile com timeout, para que a eventual sessão deixada aberto sem uso seja removida pelo próprio RDBMS... "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!" Repito : o caso Não É ausência de dados na V$PROCESS e sim a coluna ADDR na V$SESSION que como Documentado na nota metalink que indiquei Em Alguns Casos de sessão killed fica nula, Não permitindo Portanto o JOIN de V$SESSION com V$PROCESS por essa coluna, como vc indicou SE no seu caso isso não ocorreu ótimo, vc pode usar o mesmo JOIN que indicou sem probs, não precisa usar o work-around indicado na nota metalink A query do script sqlplus (se vc for Adotar a minha Recomendação de gerar o shell script pelo sqlplus, que repito imho é muito mais simples/fácil de se usar) portanto ficaria tipo : set term off feedback off verify off pages 0 lines 500 trimspool on head off spool /tmp/kill_sessions.sh SELECT 'kill -9 ' || p.spid FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.usernameIS NOT NULL AND s.status = 'KILLED' / select 'exit' || chr(10) from dual / spool off exit okdoc ?? "Essa questao do alter system disconnect session eu vou testar tambem, obrigado pela dica. " Blz, como eu disse a minha Recomendação é sempre pelo DISCONNECT, na minha experiência ele é mais efetivo do que KILL SESSION Mas testa aí direitinho, num cenário onde vc tem sessão que fica "eternamente" em KILLED talvez nem mesmo o DISCONNECT IMMEDIATE seja tão efetivo, aí talvez vc tenha mesmo que apelar pro KILL -9 do processo diretamente... []s Chiappa OBS : o ponto MAIS CRÍTICO do assunto eu REPITO aqui, para ficar Bem Claro : vc só deve usar alguma opção de matar a sessão (seja via KILL, seja via DISCONNECT IMMEDIATE, seja via KILL -9 direto) SE, e APENAS SE, as suas sessões são DEDICATED e SE vc não tem nenhum tipo de POOL DE CONEXÃO ativo, ou MTS/Shared Sessions no database... Matar uma sessão que está sendo compartilhada com outras via POOL DE CONEXÃO ou via MTS/Shared Server pode ser DESASTROSO, pois vc pode acabar matando outras conexões que compartilham essa tal sessão
Re: [oracle_br] Re: AJuda script shell
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]" 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 SOMas 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:0P11_QUESTION_ID:430819636473 ou https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable para exemplos []s Chiappa #yiv4054497711 #yiv4054497711 -- #yiv4054497711ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4054497711 #yiv4054497711ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4054497711 #yiv4054497711ygrp-mkp #yiv4054497711hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv4054497711 #yiv4054497711ygrp-mkp #yiv4054497711ads {margin-bottom:10px;}#yiv4054497711 #yiv4054497711ygrp-mkp .yiv4054497711ad {paddin
[oracle_br] Re: AJuda script shell
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 SOMas 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:0P11_QUESTION_ID:430819636473 ou https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable para exemplos []s Chiappa