Tá certo, chefe. Obrigado. On Mar 19, 2013, at 12:52 PM, "J. Laurindo Chiappa" <jlchia...@yahoo.com.br> wrote:
> Então, achei que estava claro mas pelo jeito não ficou : > > a) "será que existe uma forma de auxiliá-lo a melhorar a situação?". > > A ÚNICA forma segura e adequada é o Fornecedor corrigir a aplicação, não > ficando indefinidamente tentando lockar o objeto, PONTO. Enquanto isso não > ocorre, o que vc pode fazer como Paliativo é o > que eu indiquei em msgs anteriores, ie : > > 1. SE vc quer serializar completamente (ie, se quando já há alguém > executando o processo vc quer que as outras sessões que tentem executar > simultaneamente falhem, com aviso) , vc pode ter alguma tela/programa que o > usuário executa antes de entrar na rotina e checa se a rotina já está em > execução em outra sessão , abortando > > 2. SE não é serialização completa o que vc quer : > > - caso o processo chega a terminar depois de demorar muito, fazer algum > TUNING no processo para que ele termine o mais rapidamente possível e assim a > sessão A mantenha o lock o mínimo possível e libere o lock para a sessão B > processar, e B terminando o mais rápido possível libera o quanto antes C, > assim por diante > > e/ou > > - vc faz o que a aplicação não faz, ie, ENCERRA a transação que está > demorando muito : para isso (provavelmente num job que rode a cada x > minutos), vc Identifica a sessão que obteve o lock , OU então coloca um > PROFILE limitando o tempo de conexão > > e é ISSO o quew vc pode fazer, sim ?? E como identificar os envolvidos, > vide abaixo... > > > b) "quem está bloqueando ***QUEM***" > > Esse é o ponto PRINCIPAL das minhas respostas, que pelo jeito não ficou > Claro : as outras sessões que estão num loop aguardando para obter o lock *** > NÂO ESTÃO BLOQUEADAS, elas estão acessando o objeto e tentando obter o lock, > mas ainda NÃO o obtiveram, sim ??? Não há LOCK WAIT aí, captou ??? Então, > para "quem está bloqueando" a resposta é, NINGUÉM, não há Bloqueio, não há > LOCK... E IMPORTANTE : como não há locks, não há uma FILA de espera, as n > sessões que estão acessando o objeto lockado para tentar obter o lock NÂO vão > ser atendidas por ordem, eu mostrei isso ... > O que há na verdade é ACESSO constante ao objeto que está lockado na > Tentativa de obter um lock, sim ??? E como vc identifica um objeto lockado ? > pelas views de lock, como mostrei.... Como vc identifica as sessões que estão > CONSTANTEMENTE, pesadamente, tentando e tentando e tentando acessar esse > objeto lockado ? Pelo evento de concorrência, como mostrei. E como vc SABE > que esse acesso constante é para obter lock com FOR UPDATE NOWAIT ?? Vc > consulta o SQL que está sendo enviado pelas sessões sofrendo de Concurrency E > confere se é o SELECT FOR UPDATE NOWAIT, okdoc ??? > > Então ESSA é a resposta : não há bloqueio, há Acesso Constante a um objeto > bloqueado, e para Identificar esse cenário vc faz o que eu disse acima e > mostrei no meu exemplo, tá bem ?? Afora isso não sei realmente o que mais > dizer... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, JLSilva <jljlsilva@...> escreveu >> >> 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" <jlchiappa@...> 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 >>> >>> >> > > > > > ------------------------------------ > > -------------------------------------------------------------------------------------------------------------------------- >> 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 > >
