É isso mesmo : vou aproveitar a thread e tentar dar uma esclarecida no que foi falado . PRIMEIRO DE TUDO, um deadlock absolutamente *** NÃO É *** causado por ausência/presença de parâmetro NENHUM, e não há parâmetro NENHUM que intensifique/diminua/previna deadlocks. Um deadlock é ** SEMPRE **, absolutamente ** SEMPRE **, resultado de DUAS (ou mais, porém ao menos duas) transações querendo fazer DMLs nos mesmo registros e numa determinada sequência, que mostrarei abaixo, E/OU existem DMLs internos fazendo lock, tipicamente por causa de FKs sem índices - assim, Juliano, se num banco A vc tem um deadlock e num banco B vc não tem significa ** SIMPLESMENTE ** que OU a sequência dos DMLs não foi a mesma nos dois bancos E/OU vc tem FKs indexadas em um e não no outro. Sobre a questão das FKs, inclusive, temos que pensar no TAMANHO e na PERFORMANCE dos bancos envolvidos : o que ocorre é que se não houver índices enquanto as FKs estão sendo checadas após um DML a tabela toda é lockada, se no banco B a tabela tem muitíssimo menos registros, ou o banco B é menor/mais rápido do que A, tranquilamente PODE SER que o lock de tabela que vai acontecer em ambos houverem FKs sem índice não ocasione deadlock em B, pois a checagem termina rápido e não conflita com outras transações, ENQUANTO o mesmo comando talvez cause deadlock em A pois em A a checagem é mais demorada, a tabela é maior....
Muito bem, afora o caso das FKs, o mecanismo de um deadlock é algo mais ou menos do tipo : a transação 1 faz um DML num registro X da tabela, lockando-o e não ficando bloqueada (supondo que nesse instante ainda não haviam outras transações querendo usar o mesmo registro X), e com essa transação AINDA NÃO COMITADA (e portanto o lock presente) , uma transação 2 começa e locka um registro Y com sucesso - com este cenário , a transação 1 tenta fazer um lock (via DML ou não, não importa) no registro Y, que está em uso , e sem especificar wait time máximo, já que Y está em uso pela T2 a transação T1 esperando o registro ser liberado com COMMIT ou ROLLBACK da T2. Imediatamente enquanto isso, a T2 tenta lockar o registro X, que está em uso pela T1, T2 passa a esperar, e assim caímos numa situação de círculo : T1 está esperando pela T2 e T2 está esperando pela T1, é o DEADLOCK, o banco Oracle reconhece a situação e faz ROLLBACK numa das transações, liberando assim a outra. OK ? Até aqui estamos bem ?? Então agora ficou fácil, o que fazer para não ter DEADLOCKS ? Vc pode : a) as duas transações T1 e T2 para intervalos de tempo/janelas DIFERENTES, aonde não conflitem, se possível OU b) se há grandes chances de conflitos do tipo ocorrerem, alterar os programas para que ** ANTES ** de tentarem o lock via DML, ** CHEQUEM ** se o registro está disponível (lock pessimista), isso pode ser feito (por exemplo) com a cláusula de WAIT , http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5771117722373#28949166930931 tem um exemplinho. Assim, se o seu programa que faz UPDATE necessariamente TEM QUE rodar na mesma janela que o outro tal programa que faz SELECT... FOR UPDATE, vc altere o seu programa para ** CHECAR ** se está disponível antes de sair UPDATEando o registro, yes ? []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Thiago Azevedo <thiago.a.azev...@...> escreveu > > Juliano, > > Os motivos para o dead lock ocorrerem em um ambiente e em outro com a mesma > configuração não podem ser diversos, mas entre eles o mais provável é a > concorrência de processos. > > Verifique no alert.log a mensagem de dead lock e os arquivos de trace > referenciados, pois neles você encontrará os comandos que estão causando > esse problema. Já que você não pode alterar o SELECT ... FOR UPDATE, talvez > você possa alterar o comado que junto com esse gera o dead lock. > > []s! > > Thiago > > 2009/4/2 Caio Spadafora <caiospadaf...@...> > > > É possivel que seja a parametrização do banco, mas enquanto você não > > fizer o teste que eu te recomendei fica dificil diagnosticar... > > > > Refaça passo a passo o que você faz para simular essa situação acompanhando > > o comportamento de cada sessão dentro da v$lock... > > > > Verifique a existência de tabelas filhos e constraints de relacionamento > > (foreign key) nos dois bancos para os objetos envolvidos nesses comandos... > > Caso exista sugiro a criação de um índice na tabela filho na coluna que se > > referencia com a tabela pai. > > > > Mas, por favor, faça o acompanhamento de locks e enqueues se não fica > > complicado arriscar um diagnóstico. > > > > > > Atenciosamente, > > Caio Spadafora. > > http://0011brothers.blogspot.com/ > > > > --- Em qui, 2/4/09, Juliano <juli...@... <juliano%40marca.com.br>> > > escreveu: > > > > De: Juliano <juli...@... <juliano%40marca.com.br>> > > Assunto: [oracle_br] Re: ORA-00060 - Deadlock detected while waiting for > > resource > > Para: oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br> > > Data: Quinta-feira, 2 de Abril de 2009, 9:20 > > > > Meu maior problema é que não poderei mudar a regra do negócio, pois esse > > comando está em uma aplicação que não tenho o código-fonte. > > > > Sei que é um mecanismo de LOCK do Banco, mas minha maior dúvida, é porque o > > problema ocorre em uma determinada Base de Dados e não ocorre em outra?? As > > duas são Oracle 9.2.0.4, com o mesmo tipo de instalação. > > > > Poderia ser algum parâmetro de configuração do Banco?? > > > > Atenciosamente, > > > > Juliano > > > > --- Em oracle...@yahoogrup os.com.br, Caio Spadafora <caiospadafora@ ...> > > escreveu > > > > > > > > > > Caros, > > > > > > > > > > Trata-se do mecanismo de lock do banco de dados. Sugiro você (caso sua > > regra de negócio permita) não utilize a cláusula "for update" no seu select, > > provavelmente esse sincronismo entre aplicativos não está legal e por conta > > disso esta ocorrendo alguma referência ciclica. > > > > > > > > > > Minha sugestão é você analisar se após esse comit o lock na tabela some, > > e se ao iniciar a segunda aplicação em algum momento surge algum enqueue. > > > > > > > > > > Se você entrar no meu blog: 0011brothers. blogspot. com, existe uma > > matéria a respeito de como identificar isso e contornar o problema de > > maneira contingêncial. > > > > > > > > > > O deadlock pode ser causado por alguns fatores e vai depender do seu > > modelo de dados, se você tem tabelas filhos envolvidas e algum outro tipo de > > dependencia, sugiro que você monitore a v$lock em diferentes momentos dessa > > sua execução provavelmente você vai conseguir diagnosticar melhor. > > > > > > > > > > Atenciosamente, > > > > > Caio Spadafora. > > > > > http://0011brothers .blogspot. com/ > > > > > > > > > > --- Em qua, 1/4/09, Júlio César Corrêa <juliotubista@ ...> escreveu: > > > > > > > > > > De: Júlio César Corrêa <juliotubista@ ...> > > > > > Assunto: Re: [oracle_br] ORA-00060 - Deadlock detected while waiting for > > resource > > > > > Para: oracle...@yahoogrup os.com.br > > > > > > > Data: Quarta-feira, 1 de Abril de 2009, 18:07 > > > > > > > > > > Falei besteira,sim não talvez? > > > > > > > > > > 2009/4/1 Júlio César Corrêa <juliotubista@ ...> > > > > > > > > > > > Humm. > > > > > > > > > > > > Assim. > > > > > > > > > > > > A partir do momento que a a primeira query executa,nenhum, update ou > > insert > > > > > > pode ser executado nestas linhas da tabela TABELA o qual se enquadram > > na > > > > > > clausula where (where nr_pk = 12). > > > > > > Enquanto você não executar commit ou rollback você vai ter erro. > > > > > > > > > > > > No seu caso alguns segundos podem ser responsável por essa diferença. > > > > > > > > > > > > 2009/4/1 Juliano <juliano@ > > > > > > > > > > > > > Olá lista, > > > > > >> Estou tendo o seguinte problema e gostaria de algum auxílio. > > > > > >> > > > > > >> Tenho um determinado programa que está rodando a seguinte instrução: > > > > > >> > > > > > >> Select * from TABELA where nr_pk = 12 for update; > > > > > >> update TABELA set campo1=valor1, campo2=valor2 where nr_pk = 12; > > > > > >> commit; > > > > > >> > > > > > >> Após essa instrução, é executado através de OUTRO programa, a seguinte > > > > > >> instrução: > > > > > >> > > > > > >> update TABELA set campo1=valor9 where nr_pk = 12; > > > > > >> commit; > > > > > >> > > > > > >> O problema.... > > > > > >> Quando executo esses dois programas em um determinado BD (Oracle > > 9.2.0.4), > > > > > >> tenho a mensagem de erro mostrada no título: Deadlock detected while > > waiting > > > > > >> for resource. > > > > > >> > > > > > >> Porém, ao executar os mesmos dois programas em outro BD, também > > (Oracle > > > > > >> 9.2.0.4) não é apresentado nenhum erro e as instruções são realizadas > > > > > >> corretamente. > > > > > >> > > > > > >> Penso ser algum parâmetro de configuração na base de dados. Alguém já > > > > > >> passou por um problema parecido??? Agradeço qualquer ajuda. > > > > > >> > > > > > >> OBS: Não tenho como modificar o FOR UPDATE do primeiro programa, pois > > é um > > > > > >> software de outra empresa que está funcionando de forma integrado ao > > meu. > > > > > >> > > > > > >> Abraços, > > > > > >> Juliano > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Júlio César Corrêa > > > > > > IS Technologist - Oracle DBA > > > > > > http://jccorrea. blogspot. com > > > > > > > > > > > > "To stay competitive in the tech industry, never stop > > > > > > learning. Always be on the lookout for better ways of > > > > > > doing things and new technologies. Our industry does > > > > > > not reward people who let themselves stagnate" > > > > > > -John Hall, Senior Vice President, Oracle University > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Júlio César Corrêa > > > > > IS Technologist - Oracle DBA > > > > > http://jccorrea. blogspot. com > > > > > > > > > > "To stay competitive in the tech industry, never stop > > > > > learning. Always be on the lookout for better ways of > > > > > doing things and new technologies. Our industry does > > > > > not reward people who let themselves stagnate" > > > > > -John Hall, Senior Vice President, Oracle University > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > ------------ --------- --------- ------ > > > > > > > > > > ------------ --------- --------- --------- --------- --------- - > > > > > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de > > inteira responsabilidade de seus remetentes. > > > > > Acesse: http://www.mail- archive.com/ oracle_br@ yahoogrupos. com.br/ > > > > > ------------ --------- --------- --------- --------- --------- - > > > > > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » > > Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! > > VISITE: http://www.oraclebr .com.br/ > > > > > ------------ --------- --------- --------- --------- --------- - Links do > > Yahoo! Grupos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > > > > > http://br.maisbusca dos.yahoo. com > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > > http://br.maisbuscados.yahoo.com > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
