Menu de navegação

[leo_jfParticipante]

Srs,

Tenho uma aplicação em pl/sql web e um dos links (uma package) quando tentava acessar dava erro. Na verdade nem dava erro, pois a tela de parâmetros nem entrava (acesso a package).
Quando conversei com o DBA o mesmo disse tava com lock no objeto, e que esse lock se encontra na library cache do oracle. Pelo que vi, na hora, tinha várias sessões abertas, e provavelmente uma delas (ou varias) estava causando esse problema. Logo após matarmos todas as sessoes consegui abrir a tela de parâmetros e gerar o relatório.
Pergunta: alguém ja teve um problema parecido e saberia como resolver, pois matar as sessões não seria a melhor forma.
Qq ajuda é bem vinda!

[Regis AraujoParticipante]

Salve Leonardo..

Aqui na empresa tivemos um problema parecido…e realmente era devido ao acumulo de sessões (inativas) dentro do banco de dados.. uma das soluções foi matar as sessões que estiverem inativas por mais de 15 minutos.. e depois pedimos para o desenvolvedor ajustar a aplicação, para desconectar qualquer sessão que estiver completamente inativa por mais de 15 minutos.. e isto diminuiu o número de sessões ativas de 1200 para no máximo 30…

Vcs precisam verificar o que está gerando tanta carga na library cache… Via EM vc consegue monitorar isto…se sua versão de oracle for 10g..

Abraços…

[leo_jfParticipante]

Olas Regis,

Saberia me dizer como o desenvolvedor fez a alteração, ou ele simplesmente usou um v$session, na aplicação, para matar as sessões que com mais de 15 mtos?

[Rodrigo AlmeidaParticipante]

Tive um problema de LOCK na Library Cache com a versão 9.2.0.4 do Oracle, para Materialized View, porém, é um BUG do banco.

Quando apliquei o último patchset para 9.2.0.8, tudo funcionava numa boa.

Geralmente, locks em Library cache não é normal acontecer, pois, Library Cache é instanciada em memória, e as travas em memória são os LATCHS! Locks aplica-se somente para estrutura de objetos. Por isso que acho estranho algo parecido.

Se for procurar mais detalhes do seu LOCK, veja se não tem tabelas com $ no final do nome, pois pode ser o dicionário de dados do Oracle que esteja BUGADA! E isso se resolve com patch.

Abraços,

[leo_jfParticipante]

Rodrigo,

Obrigado pela dica. Encaminhei essas observações para o DBA responsável para análise.
Meu usuário não tem privilégios de DBA, infelizmente.
Muitas coisas eu poderia resolver sozinho, mas para conseguir um login de DBA aqui na empresa é uma novena.
Aproveitando a duvida, alguém sabe me dizer se existe um programa no unix que eu consiga ver quais shells estão usando determinado usuário.
Pergunto isso por que tenho um usuário xxxxx, que irá mudar a senha, e preciso saber quais aplicativos estou usando esse usuário para fazer as devidas alterações.
Aqui o pessoal usa o control-M para agendar os shells.

[Regis AraujoParticipante]

Fala Leonardo..

Então.. Não sei qual foi a alteração que o analista fez no aplicação dele.. pois é terceiro.. Já nos.. alteramos o parametro abaixo.. dentro do arquivo ETC/SYSCTL.CONF

Tempo de ociosidade (segundos).

net.ipv4.tcp_keepalive_time = 900

Qtd Vezes de checagem da sessão ociosa, para confirmar ociosidade

net.ipv4.tcp_keepalive_intvl = 15

tempo entre as checagens da sessão ociosa (segundos).

net.ipv4.tcp_keepalive_probes = 8

Isto faz a verificação, após identificado que a sessão realmente é inativa o SO derruba a sessão…

E criamos um script no linux que loga no oracle.. e verifica quais as sessões que estão inativas a mais de 15 min e da um “Alter System Kill Session”…

Abraços.. Bom.. espero que lhe ajude…

[CleitonHanzenParticipante]

Opá…

Pois entaum, esse locks em library cache são bem comuns se você tentando compilar/alterar um objeto que está em uso naquele momento….existem alguns note no metalink que explicam como você faz para recuperar qual a sessão/comando que está gerando o bloqueio…. Uma fez fizemos um teste de mandar recompilar uma package que é muito acessada no banco de desenvolvimento, resultado = 3 horas e o comando recompilação estava travado por library cache lock, eliminamos uma sessão que estava executando a package e a recompilação prosseguiu… 🙂

A respeito de excesso de conexões inativas, existe o parâmetro IDLE_TIME do Profile que pode controlar isso daí (se as conexões forem via pool de conexão do Application Server, as sessões ficam com o status SNIPED, pois não há nenhum cliente final que iria dar o “OK” para a sessão finalizada)…

[]s

[Autor]

Posts