Conta do Oracle não está respondendo

Question

Eu tenho uma instância do Oracle que possui contas user1, user2 e user3. Ontem consegui fazer o login em todas as três contas. Hoje, posso entrar no user1 e user3, mas o user2 está completamente "congelado" de alguma forma que eu não entendo.

Se eu tentar logar no user2 com o sqlplus, isso só vai durar para sempre. Não conecta, não expira, nada acontece até que eu pressione CTRL + C para matar o processo. Conectar como user1 ou user3 é instantâneo.

Eu pensei em tentar bloquear o user2 e tentar desbloqueá-lo. A consulta para bloquear o usuário foi executada por 25 minutos antes de eu desistir! Bloquear user1 e desbloquear o usuário1 foi executado instantaneamente.

Usando TOAD e conectando como DBA, usei o Navegador de sessão para investigar. Eu encontrei 11 conexões para o banco de dados como user2. Cinco dessas parecem ser minhas tentativas fracassadas de conexão usando o sqlplus. Nenhuma dessas conexões está mostrando nenhum cursor aberto, uma instrução atual ou nenhum bloqueio. Na guia de esperas 10 das conexões mostra um "bloqueio de cache de linha" com:

• segundos de espera entre 3.000 e 60.000
• P1 = 7
• P1 Text="cache id"
• P2 = 0
• P2 Text="modo"
• P3 = 3
• P3 Text="request"

Uma das conexões se destaca, pois parece ser muito antiga. Mostra uma mensagem "SQL * Net do cliente" com:

• segundos em espera > 600.000
• P1 = 1413697536
• P1 Text="id do motorista"
• P2 = 1
• P2 Text="#bytes"
• P3 = 0
• P3 Text=""

Eu não posso matar nenhuma dessas 11 sessões. Depois de emitir o comando kill (usando TOAD, com ou sem opção imediata), ele é executado por 45 a 60 segundos e depois diz "A sessão está marcada para kill". mas a sessão nunca desaparece.

Alguma idéia do que isso significa ou como posso matar essas sessões e restaurar o acesso à conta do usuário2?

Atualizar : havia algumas linhas interessantes no log de alerta:

Tue Dec 29 09:37:45 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:25:45 2009
>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=17
System State dumped to trace file [snip]\udump\ora_1988.trc
Tue Dec 29 10:54:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:55:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:56:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:57:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 11:12:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:06:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:26:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:27:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 13:46:17 2009
WARNING: inbound connection timed out (ORA-3136)
Wed Dec 30 10:02:16 2009 >>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=37
System State dumped to trace file [snip]\udump\ora_2860.trc
Wed Dec 30 11:55:59 2009
orakill: attempting to kill tid=436
Wed Dec 30 11:56:04 2009
orakill: ssthreadkill(tid=436) unable to get the thread list mutex: err=0

Resolução : Parece que este é um bug 10.2.0.3 e eu preciso reiniciar a instância, que eu não tenho permissão para fazer, então vou esperar alguns dias.

    

Answer 1

Tente o seguinte:

select s.username, s.sid, p.spid 
  from v$session s join v$process p on addr=paddr
where s.username = 'USER2';

Usando o valor spid da consulta acima, efetue logon no servidor e emita o seguinte comando em um prompt de comando do DOS:

orakill YOURSID spid

YOURSID é o SID da instância do banco de dados com a qual você está lidando.

orakill geralmente funciona quando as ferramentas GUI não matam processos. Aqui está uma visão geral do orakill . Observe o motivo # 1 para usar o orakill - isso pode explicar por que você não pode usar sua ferramenta GUI:

The alter system statement will not clear any locks that exist. Instead, the session will remain connected until it times out, then the session is killed and the locks are released. The orakill command will kill the thread and the locks instantly.

Atualização:

Você também pode tentar:

select sid, serial#, program from v$session;
alter system kill session '<SID>,<SERIAL#>' immediate;

embora eu não esperasse muita esperança ...