De forma alguma - na verdade se fosse obrigatório em 100% dos casos facilmente
a Oracle já poderia ter programado o banco para o índice ser criado se não
existir, como é para PKs.... De modo geral, índice pode ser colocado nas
colunas FKs quando :
- vc faz alteração na tabela-pai (seja DELETE seja um ON DELETE CASCADE nela,
ou mesmo a asnice de UPDATE na PK da tabela-pai), aí obviamente o banco VAI TER
QUE checar as FKs na filha, se não houver índice o lock na tabela-filha é
inescapável, via de regra
- vc faz pesquisa (join) usando a pai e a filha simultaneamente , tipo :
select * from dept, emp
where emp.deptno = dept.deptno and dept.deptno = :X;
supondo que deptno é FK na emp, um índice nela pode ser útil
É + ou - isso que me ocorre, escrevendo de cabeça.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Moacir Lourenço <moac...@...> escreveu
>
> Chiappa,
> Podemos afirmar que é obrigatório o uso de index para fk´s?
>
>
> From: jlchiappa
> Sent: Thursday, April 02, 2009 6:24 PM
> To: oracle_br@yahoogrupos.com.br
> Subject: [oracle_br] Re: ORA-00060 - Deadlock detected while waiting for
> resource
>
>
> É 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.azevedo@>
> 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 <caiospadafora@>
> >
> > > É 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 <juliano@ <juliano%40marca.com.br>>
> > > escreveu:
> > >
> > > De: Juliano <juliano@ <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]
> >
>
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
