[oracle_br] Re: Deadlock misterioso.

2010-03-25 Por tôpico José Laurindo
Não sei se vai servir isso, pois o cara lá tá tendo DEADLOCKs, é algo diferente 
de LOCKs... Conflito de LOCKs entre sessões (duas querendo atualizar uma o 
registro que a outra já tem lockado) podem causar deadlocks, mas como ele diz 
que é uma sessão só, acho que não deve ser isso... Tamos por enquanto chutando 
Triggers e Falta de Índices em FKs como causas prováveis...

 []s

   Chiappa

--- Em oracle_br@yahoogrupos.com.br, Raul Francisco Costa F. de Andrade, DBA 
raulf...@... escreveu

 Amigo estou enviando abaixo algumas queries detectoras de lock... roda lá
 talvez consiga achar o que está ocasionando eles.
 
 
 Um abraço,
 
 
 Raul
 
  1- Verifica Lock ORACLE 10g 
 
 SELECT /*+ rule */  l.inst_id,s.event, l.SID, s.serial# serial, p.spid,
 s.username,
 s.status, s.osuser, s.machine, s.program,
  to_char(s.logon_time,'dd/mm/ hh24:mm:ss') LOGON_TIME, l.ctime
 LOCK_TIME
 FROM gv$lock l, gv$session s, gv$process p
WHERE s.inst_id = l.inst_id
  and s.inst_id = p.inst_id
  AND s.SID = l.SID
  and s.PADDR = p.addr
  AND (l.id1, l.id2, l.TYPE) IN (SELECT id1, id2, TYPE
   FROM gv$lock
  WHERE request  0)
 ORDER BY ctime DESC;
 
 
 
 -- 1.1 verifica lock e mostra a query
 
 SELECT   w.SID,
  w.event,
  w.seconds_in_wait,
  SQL.sql_text
 FROM v$session_wait w, v$session s, v$process p, v$sqltext SQL
WHERE w.SID = s.SID
  AND s.paddr = p.addr
  AND SQL.address = s.sql_address
  AND SQL.hash_value = s.sql_hash_value
  AND w.wait_class != 'Idle'
 ORDER BY w.seconds_in_wait, w.SID, SQL.piece;
 
 
  3 - Verifica lock de dicionário de dados Oracle 10g 
 
  select /*+ ordered */
 w1.sid  waiting_session,h1.sid  holding_session,
 w.kgllktype lock_or_pin, w.kgllkhdl address,
 decode(h.kgllkmod,  0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
 'Unknown') mode_held,
 decode(w.kgllkreq,  0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
 'Unknown') mode_requested
 from
 dba_kgllock w,
 dba_kgllock h,
 v$session w1,
 v$session h1
 where
 (((h.kgllkmod != 0)
 and (h.kgllkmod != 1)
 and ((h.kgllkreq = 0) or (h.kgllkreq = 1)))
 and  (((w.kgllkmod = 0) or (w.kgllkmod= 1))
 and ((w.kgllkreq != 0)
 and (w.kgllkreq != 1
 and  w.kgllktype   =  h.kgllktype
 and  w.kgllkhdl=  h.kgllkhdl
 and  w.kgllkuse =   w1.saddr
 and  h.kgllkuse =   h1.saddr;
 
 Em 24 de março de 2010 13:20, Fábio Telles Rodriguez fabio.tel...@...
  escreveu:
 
 
 
  Senhores, estou com um Oracle 10.2.0.4 num Linux x86_64 com RH 4.6 e
  começando a utilizar swap. Ok, quando a memória se vai, os problemas
  começam
  e de fato ouveram algumas ocorrências isoladas de ORA-4031.
 
  Mas o que está estranho são os deadlocks recorrentes onde o mesmo deadlock
  surge várias veses no alert (com diferença de segundos) e apontando sempre
  para o mesmo trace. O SQL é sempre o mesmo, um DELETE, e o bizarro é com
  apenas uma sessão. Pelo que eu entendo, não é possível haver deadlock em
  uma
  única sessão. Alguma dica de qual o problema pode estar ocorrendo?
 
  *** 2010-03-22 15:20:04.817
  *** ACTION NAME:(M_LAN_AMB_PARTICULAR) 2010-03-22 15:20:04.710
  *** MODULE NAME:(MVFNCT ) 2010-03-22 15:20:04.710
  *** SERVICE NAME:(SYS$USERS) 2010-03-22 15:20:04.710
  *** SESSION ID:(498.12593) 2010-03-22 15:20:04.710
  DEADLOCK DETECTED ( ORA-00060 )
  [Transaction Deadlock]
  The following deadlock is not an ORACLE error. It is a
  deadlock due to user error in the design of an application
  or from issuing incorrect ad-hoc SQL. The following
  information may aid in determining the deadlock:
  Deadlock graph:
  -Blocker(s)
  -Waiter(s)-
  *Resource Name process session holds waits process session holds
  waits*
  *TX-00150013-00031d12 30 498 X 30 498
  X*
  session *498*: DID 0001-001E-0206 session *498*: DID
  0001-001E-0206
  Rows waited on:
  Session *498*: obj - rowid = B8D0 - AAALjQAAGAADgRIAAj
  (dictionary objn - 47312, file - 6, block - 918600, slot - 35)
  Information on the OTHER waiting sessions:
  End of information on OTHER waiting sessions.
  Current SQL statement for this session:
  *DELETE FROM SCHEMA.ITREG_AMB WHERE CD_REG_AMB = :B2 AND DECODE(:B1 , NULL,
  1,CD_ATENDIMENTO) = DECODE(:B1 , NULL, 1,:B1 )*
 
  Qualquer dica é bem vinda, uma vez que não encontrei nada parecido no
  google
  ou no metalink.
 
  Atenciosamente,
  --
  blog: http://www.midstorm.org/~telles/
  e-mail / jabber: fabio.tel...@... fabio.telles%40gmail.com
 
  [As partes desta mensagem que não continham texto foram removidas]
 
  
 
 
 
 
 -- 
 --
 Raul Francisco da Costa Ferreira de Andrade
 DBA - OCA - Oracle Certified Associate
 COBIT Foundation 4.1
 Fone: (41)8855-8874 Brt
 email: raulf...@...
 Skype: raul.andrade
 www.clickdba.com
 Deus não dá prova superior às 

[oracle_br] Re: Deadlock misterioso.

2010-03-24 Por tôpico José Laurindo
Sim, triggers são uma possibilidade, outras são :

a) JOBs de banco, SQL paralelizado e quetais : são casos aonde outra sessão é 
aberta SEM que mais ninguém conecte, isso pode levar a deadlock

b) FKs não-indexadas : em 
http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1068032649872#3458766515191
 o autor chama essa de 'principal causa de deadlocks', acho que é um pouco de 
exagero, mas a ref é muito boa, fala inclusive sobre a base teórica do 
deadlock, E tem um script para listar Fks sem índice... Claro, Fk sem índice só 
poderia causar deadlock em casos muito específicos, mas fica a dica.

E é claro, vale SEMPRE uma análise breve no arquivo de trace do deadlock , 
http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1528515465282#1529918226750
 e 
http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6369740147072 
falam um pouco sobre...

[]s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, Marcos de Moura Gonçalves mgmar...@... 
escreveu

 Olá Fábio,
 
 Se está havendo deadlock com uma única sessão é possível que esteja sendo
 utilizado Autonomous Transaction no código. Assim, na mesma sessão é aberta
 uma outra transação, que pode estar locando a principal. Veja se existem
 triggers na tabela onde está sendo feito esse delete, e tende entender o que
 está acontecendo nelas. Se não houver triggers nessa tabela, tente  procurar
 por esse delete dentro da dba_source pra ver se ele pertence a alguma
 trigger ou procedure, pra tentar rastrear o problema. Você identifica a
 utilização de transações autônomas através do código PRAGMA
 autonomous_transaction;.
 
 []'s
 
 Marcos
 
 Em 24 de março de 2010 13:20, Fábio Telles Rodriguez fabio.tel...@...
  escreveu:
 
 
 
  Senhores, estou com um Oracle 10.2.0.4 num Linux x86_64 com RH 4.6 e
  começando a utilizar swap. Ok, quando a memória se vai, os problemas
  começam
  e de fato ouveram algumas ocorrências isoladas de ORA-4031.
 
  Mas o que está estranho são os deadlocks recorrentes onde o mesmo deadlock
  surge várias veses no alert (com diferença de segundos) e apontando sempre
  para o mesmo trace. O SQL é sempre o mesmo, um DELETE, e o bizarro é com
  apenas uma sessão. Pelo que eu entendo, não é possível haver deadlock em
  uma
  única sessão. Alguma dica de qual o problema pode estar ocorrendo?
 
  *** 2010-03-22 15:20:04.817
  *** ACTION NAME:(M_LAN_AMB_PARTICULAR) 2010-03-22 15:20:04.710
  *** MODULE NAME:(MVFNCT ) 2010-03-22 15:20:04.710
  *** SERVICE NAME:(SYS$USERS) 2010-03-22 15:20:04.710
  *** SESSION ID:(498.12593) 2010-03-22 15:20:04.710
  DEADLOCK DETECTED ( ORA-00060 )
  [Transaction Deadlock]
  The following deadlock is not an ORACLE error. It is a
  deadlock due to user error in the design of an application
  or from issuing incorrect ad-hoc SQL. The following
  information may aid in determining the deadlock:
  Deadlock graph:
  -Blocker(s)
  -Waiter(s)-
  *Resource Name process session holds waits process session holds
  waits*
  *TX-00150013-00031d12 30 498 X 30 498
  X*
  session *498*: DID 0001-001E-0206 session *498*: DID
  0001-001E-0206
  Rows waited on:
  Session *498*: obj - rowid = B8D0 - AAALjQAAGAADgRIAAj
  (dictionary objn - 47312, file - 6, block - 918600, slot - 35)
  Information on the OTHER waiting sessions:
  End of information on OTHER waiting sessions.
  Current SQL statement for this session:
  *DELETE FROM SCHEMA.ITREG_AMB WHERE CD_REG_AMB = :B2 AND DECODE(:B1 , NULL,
  1,CD_ATENDIMENTO) = DECODE(:B1 , NULL, 1,:B1 )*
 
  Qualquer dica é bem vinda, uma vez que não encontrei nada parecido no
  google
  ou no metalink.
 
  Atenciosamente,
  --
  blog: http://www.midstorm.org/~telles/http://www.midstorm.org/%7Etelles/
  e-mail / jabber: fabio.tel...@... fabio.telles%40gmail.com
 
  [As partes desta mensagem que não continham texto foram removidas]
 
   
 
 
 
 [As partes desta mensagem que não continham texto foram removidas]





Re: [oracle_br] Re: Deadlock misterioso.

2010-03-24 Por tôpico Fábio Telles Rodriguez
Em 24 de março de 2010 15:48, José Laurindo jlchia...@yahoo.com.brescreveu:



 Sim, triggers são uma possibilidade, outras são :

 a) JOBs de banco, SQL paralelizado e quetais : são casos aonde outra sessão
 é aberta SEM que mais ninguém conecte, isso pode levar a deadlock

 Hum, mas mesmo os JOBs criam sessões, não?


  b) FKs não-indexadas : em
 http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1068032649872#3458766515191o
  autor chama essa de 'principal causa de deadlocks', acho que é um pouco de
 exagero, mas a ref é muito boa, fala inclusive sobre a base teórica do
 deadlock, E tem um script para listar Fks sem índice... Claro, Fk sem índice
 só poderia causar deadlock em casos muito específicos, mas fica a dica.

Não, não é o caso de falta de FK.


 E é claro, vale SEMPRE uma análise breve no arquivo de trace do deadlock ,
 http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1528515465282#1529918226750e
 http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6369740147072falam
  um pouco sobre...

 Bom, o trace foi de fato a primeira coisa que fui olhar. Veja que eu
inclusive colei ele aqui.


  []s

 Chiappa

 --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br,
 Marcos de Moura Gonçalves mgmar...@... escreveu

 
  Olá Fábio,
 
  Se está havendo deadlock com uma única sessão é possível que esteja sendo
  utilizado Autonomous Transaction no código. Assim, na mesma sessão é
 aberta
  uma outra transação, que pode estar locando a principal. Veja se existem
  triggers na tabela onde está sendo feito esse delete, e tende entender o
 que
  está acontecendo nelas. Se não houver triggers nessa tabela, tente
 procurar
  por esse delete dentro da dba_source pra ver se ele pertence a alguma
  trigger ou procedure, pra tentar rastrear o problema. Você identifica a
  utilização de transações autônomas através do código PRAGMA
  autonomous_transaction;.
 
  []'s
 
  Marcos
 
  Em 24 de março de 2010 13:20, Fábio Telles Rodriguez fabio.tel...@...

   escreveu:
 
  
  
   Senhores, estou com um Oracle 10.2.0.4 num Linux x86_64 com RH 4.6 e
   começando a utilizar swap. Ok, quando a memória se vai, os problemas
   começam
   e de fato ouveram algumas ocorrências isoladas de ORA-4031.
  
   Mas o que está estranho são os deadlocks recorrentes onde o mesmo
 deadlock
   surge várias veses no alert (com diferença de segundos) e apontando
 sempre
   para o mesmo trace. O SQL é sempre o mesmo, um DELETE, e o bizarro é
 com
   apenas uma sessão. Pelo que eu entendo, não é possível haver deadlock
 em
   uma
   única sessão. Alguma dica de qual o problema pode estar ocorrendo?
  
   *** 2010-03-22 15:20:04.817
   *** ACTION NAME:(M_LAN_AMB_PARTICULAR) 2010-03-22 15:20:04.710
   *** MODULE NAME:(MVFNCT ) 2010-03-22 15:20:04.710
   *** SERVICE NAME:(SYS$USERS) 2010-03-22 15:20:04.710
   *** SESSION ID:(498.12593) 2010-03-22 15:20:04.710
   DEADLOCK DETECTED ( ORA-00060 )
   [Transaction Deadlock]
   The following deadlock is not an ORACLE error. It is a
   deadlock due to user error in the design of an application
   or from issuing incorrect ad-hoc SQL. The following
   information may aid in determining the deadlock:
   Deadlock graph:
   -Blocker(s)
   -Waiter(s)-
   *Resource Name process session holds waits process session holds
   waits*
   *TX-00150013-00031d12 30 498 X 30 498
   X*
   session *498*: DID 0001-001E-0206 session *498*: DID
   0001-001E-0206
   Rows waited on:
   Session *498*: obj - rowid = B8D0 - AAALjQAAGAADgRIAAj
   (dictionary objn - 47312, file - 6, block - 918600, slot - 35)
   Information on the OTHER waiting sessions:
   End of information on OTHER waiting sessions.
   Current SQL statement for this session:
   *DELETE FROM SCHEMA.ITREG_AMB WHERE CD_REG_AMB = :B2 AND DECODE(:B1 ,
 NULL,
   1,CD_ATENDIMENTO) = DECODE(:B1 , NULL, 1,:B1 )*
  
   Qualquer dica é bem vinda, uma vez que não encontrei nada parecido no
   google
   ou no metalink.
  
   Atenciosamente,
   --
   blog: http://www.midstorm.org/~telles/
 http://www.midstorm.org/%7Etelles/
e-mail / jabber: fabio.tel...@... fabio.telles%40gmail.com

  
   [As partes desta mensagem que não continham texto foram removidas]
  
  
  
 
 
  [As partes desta mensagem que não continham texto foram removidas]
 

  




-- 
blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@gmail.com


[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Re: Deadlock misterioso.

2010-03-24 Por tôpico José Laurindo
Segue :


 Hum, mas mesmo os JOBs criam sessões, não?

Sim : na verdade a pergunta que eu não fiz e deveria ter feito é, vc OLHOU 
mesmo a V$SESSION ou assumiu que não tinha outras sessões porque só vc tava 
usando o server ? E isso foi ** IMEDIATAMENTE ANTES ** do deadlock ? pergunto 
isso porque, como creio que vc sabe, o DEADLOCK além de gerar msg ele ** MATA 
** quase imediatamente uma das sessões envolvidas se foi caso de clash entre 
sessões, aí LOGICAMENTE se vc olhar depois do deadlock só vai ter UMA mesmo na 
V$SESSION ...
 Se olhou mesmo na V$SESSION, imediatamente antes do DEADLOCK,  e realmente não 
tinha ninguém fora a sessão em causa, OK, pode-se descartar JOBs e Parallels , 
ambos criam sessões...


Não, não é o caso de falta de FK.

** REPITO **, não é FALTA DE FKs, é falta de ÍNDICE em FKs, ok ? É 
diferente... Inclusive, o fato de (ao menos consultando o que vc postou pela 
web, como estou, que dá uma bagunçadinha) não haver info para a parte de OTHER 
SESSION parece mesmo indicar por FK ou trigger, que são duas possibilidades 
boas de DEADLOCK snuma sessão só...



 Bom, o trace foi de fato a primeira coisa que fui olhar. Veja que eu
inclusive colei ele aqui.

Sim, mas além de olhar vc ** FEZ ** a análise dele ? Por exemplo, com as infos 
de identificação de linha/bloco vc localizou o ROWID do objeto em questão ? Com 
as infos de data/hora/sessão e de BIND VARIABLEs vc localizou QUEM exatamente 
(qual usuário, em qual terminal, com qual sistema), estava fazendo o que na 
sessão relatada pelo deadlock, para daí tentar identificar os SQLs, talvez até 
checando o cache de SQLs, views ASH/AWR ?? Esse tipo de análise só vc a penas 
vc pode fazer, na sua máquina, é é FUNDAMENTAL para que, se preciso, vc 
Reproduza a issue mas desta vez com trace Ativado, o que é algo que mui 
provavelmente o Suporte vai te pedir, e que pode ser revelador em alguns 
casos... 

 []s

  Chiappa