Chiappa, gosto muito do nível de detalhes que vc responde, colocando bons exemplos e sempre muito úteis. Mas, vejo que você apenas está repetindo o que eu disse na minha primeira mensagem. Parafraseando seu modo de escrever: Eu ***JÁ*** sei que é um select for update nowait. Ja identifiquei isto, por isso enviei o meu primeiro email, pois não tenho como evitar qua a aplicação faça o que está fazendo. Eu ***JÁ*** sei que é a aplicação que ***********DEVERIA************ encerrar a transação. Mas, com eu ***JÁ*** disse: a aplicação ***NÃO O FAZ***. Eu achei que tinha deixado claro qual era a minha intenção ao perguntar se alguém conhece uma maneira de desativar um nowait: a aplicação está fazendo caca, e o cliente está sofrendo a consequencia, portanto "será que existe uma forma de auxiliá-lo a melhorar a situação?".
O que eu gostaria de responder é: Quem está bloqueando ***QUEM*** (não "oque", ok?) O "que" está esperando eu já sei, é uma determinada tabela. O problema é descobrir a ordem dessa fila, para fazer o deadlock manualmente e adequadamente. Ok? On Mar 18, 2013, at 9:16 PM, "J. Laurindo Chiappa" <jlchia...@yahoo.com.br> wrote: > 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 >>> >>> >> > > > > > ------------------------------------ > > -------------------------------------------------------------------------------------------------------------------------- >> 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 > >
