Nope, veja as minhas outras msgs com demonstrações (que provavelmente não te
chegaram antes de vc escrever esta), que :
- é CLARO que as sessões estão SIM esperando por algo, sessão que não espera
por nadaé IMPOSSÍVEL
- é Claro que (ao menos desde a introdução do 10g) o banco Registra sim na
V$SESSION o SQL_ID sendo executado, a Espera, o objeto causando a espera, a
CLASSE da espera, então tanto DÁ SIM para vc identificar sessões acessando
sempre e sempre o mesmo objeto QUANTO dá para vc identificar que o SQL é com
NOWAIT, o que fecha o cenário que vc descreve - INCLUSIVE, ao menos por mim
essa foi uma das mais festejadas alterações no 10g, junto com a AUTOMAÇÂO das
estatísticas de execução de um SQL longo na V$SQL... Só quem teve o desprazer
de trabalhar com versões anteriores pode avaliar o quão útil isso é
- é VERDADE que não há como vc identificar o REGISTRO já lockado e sendo
acessado constantemente via for update nowait em um loop, Mas como eu mostrei
vc consegue Sim identificar as sessões constantemente acessando o mesmo OBJETO
e aí pelo SQL dessas sessões vc Comprova ou não que é esse caso do NOWAIT
==> e só para deixar Escrupulosamente Claro : quem TEM que fazer COMMIT ou
ROLLBACK é a sessão A, que obteve o lock e o está mantendo, SIM ??? A falha da
Aplicação é que ela NEM limita o tempo que A fica com a transação aberta e
mantendo o LOCK, e NEM (mesmo ela, Aplicação) sabendo que PODEM haver
transações erradamente abertas por muito muito tempo, nem mesmo assim ela
aplica algum LIMITE na qtdade de vezes e/ou no tempo que fica esperando A
liberar o lock com o encerramento da Transação....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, JLSilva <jljlsilva@...> escreveu
>
> Chiappa,
> Agradeço o tempo que você despendeu para analisar o caso, mas devo discordar
> totalmente de você, amigo.
> 1. Veja, não há nenhuma sessão esperando nada.. o select for update está
> usando NOWAIT, que é justamente para não esperar.. Ocorre o ORA-00054, e a
> aplicação tenta bloquear o registro novamente, e ocorre novamente o
> ORA-00054, e tenta novamente.. nesse processo, ela nunca faz commit/rollback,
> entende..? A sessão nunca fica numa longa espera por lock...
> 2. Não é possível identificar exatamente quem está bloqueando quem, já que
> não tenho como saber qual registro uma sessão está bloqueando sem ter
> antecipadamente ativado um trace. O máximo que consigo é verificar todas as
> sessões que têm uma transação aberta em uma tabela.. mas não em qual
> registro, correto?
> 3. Absolutamente verdadeiro quando digo que nunca vai terminar esse loop:
> veja que é como um deadlock, mas sem o mecanismo de deadlock do Oracle, uma
> vez que a aplicação é que fica num loop eterno tentando bloquear um registro
> que está blqueado por outra sessão, sendo que essa outra sessão nunca vai
> fazer commit/rollback já que ela também está tentando bloquear registros que
> estão bloqueados pela outra sessão.
>
> On Mar 18, 2013, at 7:39 PM, "J. Laurindo Chiappa" <jlchiappa@...> wrote:
>
> > Hmmm, peraí : "nunca vai sair" é absolutamente Falso : o lock que A está
> > mantendo (e que impede B de lockar o mesmo recurso) *** NÃO *** é Eterno,
> > ele VAI SIM ser liberado assim que A encerrar a transação, seja com COMMIT
> > seja com ROLLBACK, yes ??? Da mesma maneira, dizer que é "impossível
> > identificar quem está lockando registros de quem" sorry, mas afaik é
> > Inverdade também : via script é Plenamente Possível vc consultar quem está
> > esperando pelo que, aí não é impossível não vc localizar quem está com o
> > lock para si, os outros TODOS estão em espera por essa sessão, dado o
> > cenário que vc descreve...
> >
> > O que é Questionável, podendo mesmo ser considerado uma FALHA no
> > aplicativo é esse comportamento de :
> >
> > 1. deixar a transação que obteve o lock ficar ILIMITADAMENTE aberta, sem
> > nenhum tipo de timeout, nem de aviso ao Operador se a transação for
> > controlada pelo Usuário da aplicação e não for encerrada o mais logo
> > possível
> >
> > e
> >
> > 2. dado o fato 1. acima (de poder existir Transação sem controle
> > estrito de tempo), após a Aplicação corretamente usar o for update nowait
> > para testar se um recurso está lockado, quando detectar que um
> > registro/resource está lockado (recebendo o ORA-0054) a Aplicação ficar
> > tentando e retentando o lock INDEFINIDAMENTE é falha - o correto ao invés
> > seria LIMITAR a quantidade de vezes em que espera o lock ser liberado (via
> > LOOP ** não-eterno **, repetido uma qtdade FIXA de vezes) E/OU limitar o
> > período de tempo em que espera o lock já presente ser encerrado com o fim
> > datransação que o criou...
> >
> > Agora entendi, é uma falha de Controle/Tratamento pela Aplicação no
> > procedimento de LOCK NOWAIT, que em si está Corretíssimo e Não deveria
> > causar espanto algum, ok...
> >
> > Muito bem, o que vc vai poder fazer aí a nível de banco de dados, Enquanto
> > a Aplicação não tem essa falha corrigida é fazer no banco de dados o que a
> > Aplicação não faz, ie, LIMITAR a duração de uma transação (e portanto
> > limitar o tempo que um lock pode existir), OU então eliminar esses casos, o
> > que poderia ser feito via :
> >
> > a) implementação algum tipo de timeout nas sessões (via PROFILE, talvez),
> > para que uma sessão A que obteve um lock num dado recurso NÂO fique com
> > transações abertas por tempo irrazoavelmente longo, assim limitando o tempo
> > que B fica esperando pelo lock
> >
> > e/ou
> >
> > b) tendo um JOB no banco que a cada poucos x minutos consulta a V$SESSION
> > e/ou a DBA_LOCKS e/ou views de WAIT, e se detectar espera muito longa por
> > locks o JOB poderia mandar um e-mail para te avisar e/ou matar a sessão
> > incial que implantou o lock (REGISTRANDO essa ação nalgum lugar, é Claro),
> > coisa do tipo
> >
> > []s
> >
> > Chiappa
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, JLSilva <jljlsilva@> escreveu
> >>
> >> Chiappa, o meu espanto é devido à lógica utilizada na aplicação.
> >> Se o registro está lockado, o processo entra em um loop e tenta novamente
> >> executar exatamente o mesmo select for update nowait para lockar o
> >> registro.
> >> O efeito cascata disso é que, ao fazer isto, a sessão A não libera os
> >> registros anteriores e continua tentando lockar novos registros que estão
> >> lockados pela sessão B.
> >> Enquanto isso, a sessão B que está lockando outros registros, e em um
> >> determinado momento, a sessão B vai tentar lockar o registro que está
> >> lockado pela sessão A.
> >> Se não fosse utilizado o "nowait" nesse select, ocorreria um deadlock,
> >> pois A está locando o registro 1, B está locando o registro 2, A tenta
> >> locar o registro 2 e B tenta locar o registro 1.
> >> Mas, devido à forma que a aplicação foi construída, o deadlock nunca
> >> ocorre, e a aplicação nunca vai sair desse loop.
> >> Agora, imagine isto ocorrendo com muitas sessões (mais de 10 sessões).
> >> Acaba que tem várias sessões lockando registros, elas não liberam esses
> >> registros, e ficam tentando locar novos registros que já estão lockados
> >> por outras, e ficam nesse loop. Fica impossível identificar quem está
> >> lockando registros de quem.
> >> Infelizmente, o fornecedor é daquele tipo difícil, e diz que "o sistema
> >> está funcionando em 200 outros locais". Ok, mas aqui está ocorrendo esse
> >> problema...
> >> Mas, concordo com você. Desativar o nowait teria um resultado muito
> >> imprevisível para o funcionamento do rdbms como um todo.
> >>
> >> On Mar 18, 2013, at 5:30 PM, "J. Laurindo Chiappa" <jlchiappa@> wrote:
> >>
> >>> Bom, vamos começar respondendo à sua pergunta : Não, em princípio afaik
> >>> (salvo alguma alteração PESADA, não-suportada e EXTREMAMENTE perigosa de
> >>> interferir no banco como um todo, tipo via parâmetros internos, OU então
> >>> jogando-se o parâmetro de compatibility lá embaixo pra alguma versão
> >>> antiga, etc ) no caso não há como vc alterar o comportamento do comando
> >>> "SELECT FOR UPDATE NOWAIT", não... Aliás, de modo geral, Não Há como vc
> >>> fazer um dado comando que está documentado agir assim ou assado agir de
> >>> outro jeito, não...
> >>>
> >>> Isso respondido, observo que vc está "espantado" com a utilização, e nem
> >>> imagino porque : veja vc, é ABSOLUTAMENTE normal e documentado (vide
> >>> manual "Oracle® Database Advanced Application Developer's Guide" cap. 1 -
> >>> SQL Processing for Application Developers , e algumas entradas sobre
> >>> LOCKs no Concepts) que é EXATAMENTE ASSIM que vc "pergunta" se um
> >>> registro está lockado ou não : vc tenta fazer um lock com NOWAIT e se der
> >>> ORA-0054 ele tá lockado, se não der não está... Eu ABSOLUTAMENTE NÃO
> >>> ENTENDI a sua "admiração", os "!!!" que vc colocou na msg, sim ????
> >>> Também Não Entendi porque vc quer mudar isso - é Absolutamente Normal que
> >>> um recurso (tabela/registro/whatever) possa ser acessado em modo
> >>> exclusivo, corretamente o teu Aplicativo CHECA isso, e vc quer remover
> >>> esse check ?? Não entendo porque - diga para nós EXATAMENTE o que vc quer
> >>> que a gente tenta sugerir algo....
> >>>
> >>> []s
> >>>
> >>> Chiappa
> >>>
> >>>
> >>> --- Em oracle_br@yahoogrupos.com.br, JLSilva <jljlsilva@> escreveu
> >>>>
> >>>> Senhores, boa tarde.
> >>>> Temos uma aplicação de terceiros (CHB) que faz "select ... for update
> >>>> ... NOWAIT".
> >>>> Essa aplicação recebe o erro ORA-00054 e o tratamento que ela dá é:
> >>>> tenta o select novamente!!!!!!!
> >>>> Com isso, não ocorre o deadlock, nem consigo saber exatamente quem é o
> >>>> bloqueador, pois há dezenas de sessões atualizando a mesma tabela.
> >>>> Alguém aí sabe se é possível desativar o "nowait" através de algum
> >>>> parâmetro/configuração do banco?
> >>>> Obrigado!
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> --------------------------------------------------------------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > --------------------------------------------------------------------------------------------------------------------------
> >> 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
> >
> >
>
