Re: [oracle_br] Sessões fican do "Presas" workaround please

[jlchia...@yahoo.com.br [oracle_br]]

Pelo que o colega lá falou, ao que entendi a aplicação em si tá normal, os 
outros usuários que conectam no banco tá tudo bem, são a(s) sessão/ões advindas 
do Nagios que estão 'congelando'/sofrendo de waits... SE for isso mesmo não me 
parece ser nada a nível de banco, acho Exagero apelar pro hanganalyze num 
cenário do tipo, diria pra ele INSISTIR mesmo ainda na 
monitoração/trace/análise dessa(s) sessão/ões não responsivas

[]s

  Chiappa

Re: [oracle_br] Sessões fican do "Presas" workaround please

[jlchia...@yahoo.com.br [oracle_br]]

Oi : então, é que vc tinha dito Claramente em outra msg (enfase com *s minha)  :

"Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, 
SOMENTE DESSE USUÁRIO, do nagios, *** minha sessão fica travada e não consigo 
realizar o trace ***,"

==> então eu entendi que vc Não estava abrindo nova sessão SE vc na verdade 
abre outra sessão E USA um dos métodos que indiquei, *** NECESSARIAMENTE *** vc 
Tem que conseguir fazer o trace, uma vez que vc identificou o SID e o SERIAL da 
sessão alvo - não tem o que interferir a sessão remota com a sua nova sessão, 
em princípio... Ao fazer isso, QUAIS WAITS vc encontrou nessa sessão ??? Tem 
alguma espera por LOCKs por exemplo - não é incomum que apps de monitoramento 
queiram gravar dados em tabelas internas delas mesmo e que algum bug da app 
cause espera por locks, ou contenção de latches 

 []s

  Chiappa

OBS :  como eu disse, provavelmente vc vai querer matar a sessão que está 
não-responsiva depois de coletar  o trace - cfrme 
http://www.fabioprado.net/2014/05/matando-sessoes-no-oracle-database.html mesmo 
já nos indica, via de regra o DISCONNECT é mais efetivo do que o KILL mas não é 
incomum que alguma aplicação mais problemática consuma tanto e tão intensamente 
que nem um nem o outro funcione, aí vc identifica o spid da sessão e apela por 
KILL -9 (se for Linux/Unix) ou pro ORAKILL se for Windows...

Re: [oracle_br] Sessões fican do "Presas" workaround please

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Rafael,
      Se está travando desse jeito, aquele wait que está aparecendo talvez não 
tenha a ver com o problema.
      A sessão pode estar parada em algum lugar no "kernel" do Oracle, pode ser 
algum bug mesmo nessa versão do banco, ou alguma àrea de memória muito 
fragmentada ou com contenção. O texto do "wait"  é atualizado na v$session em 
pontos específicos, e nesse caso ai pode não refletir o local onde está parada 
a sessão.
     Se você rodar um "oradebug dump errorstack 3;" em vez de ativar o trace, a 
sessão do oradebug trava também?
   Outra coisa que poderia fazer é abrir uma terceira sessão e fazer um 
"oradebug hanganalyze", ou fazer um "systemstate dump", mas tem uma chance 
disso fazer a base travar inteira.

Atc,Luis Freitas     


 

On Monday, December 4, 2017 10:46 AM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  wrote:
 

     Obrigado Mulafani e o CHiappa.
Chiappa, **MAS É CLARO** que eu estou abrindo um outra sessão no banco para 
gerar o trace da sessão que eu desejo. Mulafani, obrigado pelo apoio, mas essa 
procedure não me serve.
Estou criando uma e assim que acabar irei postar o código dela aqui para que no 
futuro, se alguém precisar, tenha como exemplo. 

Em Segunda-feira, 4 de Dezembro de 2017 10:06, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     PMFJI, mas se a sessão a analisar está travada ou quase isso, é óbvio que 
vc deve ativar o trace a partir de OUTRA sessão, dificilemnte vc vai conseguir 
realizar trace na sessão que já está não-responsiva ou quase...
 Para isso, vc abre uma OUTRA sessão nesse banco, com um usuário DBA ou pelo 
menos com privilégios mais altos, e a partir daí vc tem VÁrias possibilidades 
para tracejar sessão de OUTRO usuário :
 
 a) já que vc já sabe o SID/SERIAL#, vc os passa como argumentos para um  
dbms_system.set_ev : trace de SQL é o evento 10046, se vc ativar esse evento é 
o mesmo que acionar o trace 
 
 ou
 
 b) pode instalar a package DBMS_SUPPORT
 
 ou
 
 c) pode descobrir o PID no sistema operacional da sessão que vc quer tracejar, 
aí informa esse PID pro oradebug
 
 ou (para alguns o melhor / mais fácil método, se teu banco é recente, 10g ou 
acima)
 
 d) usa a package DBMS_MONITOR, entre os diversos procedimentos/rotinas que ela 
possui há o session_trace_enable que permitie Sim que vc indique o SID/SERIAL# 
da OUTRA sessão, que vc já saberia quais são
 
 ==> Vc acha exemplos de TODAS essas opções em 
http://www.petefinnigan.com/ramblings/how_to_set_trace.htm   UMA VEZ QUE vc 
monitorou por bastante tempo, vc mata a sessão com um disconnect (normalmente a 
maioria dos métodos só grava o arquivo de trace quando a sessão é 
desconectada), e vc tanto pode consultar os WAITs olhando diretamente o arquivo 
de trace (as linhas que começam com WAIT#) quanto pode pedir um profile do 
arquivo de trace via tkprof ...
 
 []s
 
   Chiappa  

 #yiv7200748506 #yiv7200748506 -- #yiv7200748506ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7200748506 
#yiv7200748506ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7200748506 
#yiv7200748506ygrp-mkp #yiv7200748506hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7200748506 #yiv7200748506ygrp-mkp #yiv7200748506ads 
{margin-bottom:10px;}#yiv7200748506 #yiv7200748506ygrp-mkp .yiv7200748506ad 
{padding:0 0;}#yiv7200748506 #yiv7200748506ygrp-mkp .yiv7200748506ad p 
{margin:0;}#yiv7200748506 #yiv7200748506ygrp-mkp .yiv7200748506ad a 
{color:#ff;text-decoration:none;}#yiv7200748506 #yiv7200748506ygrp-sponsor 
#yiv7200748506ygrp-lc {font-family:Arial;}#yiv7200748506 
#yiv7200748506ygrp-sponsor #yiv7200748506ygrp-lc #yiv7200748506hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7200748506 
#yiv7200748506ygrp-sponsor #yiv7200748506ygrp-lc .yiv7200748506ad 
{margin-bottom:10px;padding:0 0;}#yiv7200748506 #yiv7200748506actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7200748506 
#yiv7200748506activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7200748506
 #yiv7200748506activity span {font-weight:700;}#yiv7200748506 
#yiv7200748506activity span:first-child 
{text-transform:uppercase;}#yiv7200748506 #yiv7200748506activity span a 
{color:#5085b6;text-decoration:none;}#yiv7200748506 #yiv7200748506activity span 
span {color:#ff7900;}#yiv7200748506 #yiv7200748506activity span 
.yiv7200748506underline {text-decoration:underline;}#yiv7200748506 
.yiv7200748506attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7200748506 .yiv7200748506attach div a 
{text-decoration:none;}#yiv7200748506 .yiv7200748506attach img 
{border:none;padding-right:5px;}#yiv7200748506 .yiv7200748506attach label 
{display:block;margin-bottom:5px;}#yiv7200748506 .yiv7200748506attach label a 
{text-decoration:none;}#yiv7200748506 blockquote 

Re: [oracle_br] Sessões fican do "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado Mulafani e o CHiappa.
Chiappa, **MAS É CLARO** que eu estou abrindo um outra sessão no banco para 
gerar o trace da sessão que eu desejo. Mulafani, obrigado pelo apoio, mas essa 
procedure não me serve.
Estou criando uma e assim que acabar irei postar o código dela aqui para que no 
futuro, se alguém precisar, tenha como exemplo. 

Em Segunda-feira, 4 de Dezembro de 2017 10:06, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     PMFJI, mas se a sessão a analisar está travada ou quase isso, é óbvio que 
vc deve ativar o trace a partir de OUTRA sessão, dificilemnte vc vai conseguir 
realizar trace na sessão que já está não-responsiva ou quase...
 Para isso, vc abre uma OUTRA sessão nesse banco, com um usuário DBA ou pelo 
menos com privilégios mais altos, e a partir daí vc tem VÁrias possibilidades 
para tracejar sessão de OUTRO usuário :
 
 a) já que vc já sabe o SID/SERIAL#, vc os passa como argumentos para um  
dbms_system.set_ev : trace de SQL é o evento 10046, se vc ativar esse evento é 
o mesmo que acionar o trace 
 
 ou
 
 b) pode instalar a package DBMS_SUPPORT
 
 ou
 
 c) pode descobrir o PID no sistema operacional da sessão que vc quer tracejar, 
aí informa esse PID pro oradebug
 
 ou (para alguns o melhor / mais fácil método, se teu banco é recente, 10g ou 
acima)
 
 d) usa a package DBMS_MONITOR, entre os diversos procedimentos/rotinas que ela 
possui há o session_trace_enable que permitie Sim que vc indique o SID/SERIAL# 
da OUTRA sessão, que vc já saberia quais são
 
 ==> Vc acha exemplos de TODAS essas opções em 
http://www.petefinnigan.com/ramblings/how_to_set_trace.htm   UMA VEZ QUE vc 
monitorou por bastante tempo, vc mata a sessão com um disconnect (normalmente a 
maioria dos métodos só grava o arquivo de trace quando a sessão é 
desconectada), e vc tanto pode consultar os WAITs olhando diretamente o arquivo 
de trace (as linhas que começam com WAIT#) quanto pode pedir um profile do 
arquivo de trace via tkprof ...
 
 []s
 
   Chiappa  #yiv5794922530 #yiv5794922530 -- #yiv5794922530ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5794922530 
#yiv5794922530ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5794922530 
#yiv5794922530ygrp-mkp #yiv5794922530hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5794922530 #yiv5794922530ygrp-mkp #yiv5794922530ads 
{margin-bottom:10px;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad 
{padding:0 0;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad p 
{margin:0;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad a 
{color:#ff;text-decoration:none;}#yiv5794922530 #yiv5794922530ygrp-sponsor 
#yiv5794922530ygrp-lc {font-family:Arial;}#yiv5794922530 
#yiv5794922530ygrp-sponsor #yiv5794922530ygrp-lc #yiv5794922530hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5794922530 
#yiv5794922530ygrp-sponsor #yiv5794922530ygrp-lc .yiv5794922530ad 
{margin-bottom:10px;padding:0 0;}#yiv5794922530 #yiv5794922530actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5794922530 
#yiv5794922530activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5794922530
 #yiv5794922530activity span {font-weight:700;}#yiv5794922530 
#yiv5794922530activity span:first-child 
{text-transform:uppercase;}#yiv5794922530 #yiv5794922530activity span a 
{color:#5085b6;text-decoration:none;}#yiv5794922530 #yiv5794922530activity span 
span {color:#ff7900;}#yiv5794922530 #yiv5794922530activity span 
.yiv5794922530underline {text-decoration:underline;}#yiv5794922530 
.yiv5794922530attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5794922530 .yiv5794922530attach div a 
{text-decoration:none;}#yiv5794922530 .yiv5794922530attach img 
{border:none;padding-right:5px;}#yiv5794922530 .yiv5794922530attach label 
{display:block;margin-bottom:5px;}#yiv5794922530 .yiv5794922530attach label a 
{text-decoration:none;}#yiv5794922530 blockquote {margin:0 0 0 
4px;}#yiv5794922530 .yiv5794922530bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5794922530 
.yiv5794922530bold a {text-decoration:none;}#yiv5794922530 dd.yiv5794922530last 
p a {font-family:Verdana;font-weight:700;}#yiv5794922530 dd.yiv5794922530last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5794922530 
dd.yiv5794922530last p span.yiv5794922530yshortcuts 
{margin-right:0;}#yiv5794922530 div.yiv5794922530attach-table div div a 
{text-decoration:none;}#yiv5794922530 div.yiv5794922530attach-table 
{width:400px;}#yiv5794922530 div.yiv5794922530file-title a, #yiv5794922530 
div.yiv5794922530file-title a:active, #yiv5794922530 
div.yiv5794922530file-title a:hover, #yiv5794922530 div.yiv5794922530file-title 
a:visited {text-decoration:none;}#yiv5794922530 div.yiv5794922530photo-title a, 
#yiv5794922530 div.yiv5794922530photo-title a:active, #yiv5794922530 

Re: [oracle_br] Sessões fican do "Presas" workaround please

[jlchia...@yahoo.com.br [oracle_br]]

PMFJI, mas se a sessão a analisar está travada ou quase isso, é óbvio que vc 
deve ativar o trace a partir de OUTRA sessão, dificilemnte vc vai conseguir 
realizar trace na sessão que já está não-responsiva ou quase...
 Para isso, vc abre uma OUTRA sessão nesse banco, com um usuário DBA ou pelo 
menos com privilégios mais altos, e a partir daí vc tem VÁrias possibilidades 
para tracejar sessão de OUTRO usuário :
 
 a) já que vc já sabe o SID/SERIAL#, vc os passa como argumentos para um  
dbms_system.set_ev : trace de SQL é o evento 10046, se vc ativar esse evento é 
o mesmo que acionar o trace 
 
 ou
 
 b) pode instalar a package DBMS_SUPPORT
 
 ou
 
 c) pode descobrir o PID no sistema operacional da sessão que vc quer tracejar, 
aí informa esse PID pro oradebug
 
 ou (para alguns o melhor / mais fácil método, se teu banco é recente, 10g ou 
acima)
 
 d) usa a package DBMS_MONITOR, entre os diversos procedimentos/rotinas que ela 
possui há o session_trace_enable que permitie Sim que vc indique o SID/SERIAL# 
da OUTRA sessão, que vc já saberia quais são
 
 ==> Vc acha exemplos de TODAS essas opções em 
http://www.petefinnigan.com/ramblings/how_to_set_trace.htm   UMA VEZ QUE vc 
monitorou por bastante tempo, vc mata a sessão com um disconnect (normalmente a 
maioria dos métodos só grava o arquivo de trace quando a sessão é 
desconectada), e vc tanto pode consultar os WAITs olhando diretamente o arquivo 
de trace (as linhas que começam com WAIT#) quanto pode pedir um profile do 
arquivo de trace via tkprof ...
 
 []s
 
   Chiappa