Ora-00600 Agora ferrou…

Recentemente, tive o desprazer de presenciar uma situação quase trágica e que não deveria acontecer :/
Um shutdown inesperado em um servidor Oracle, que não tinha redundância, quase trouxe o caos a um de nossos clientes.

Após a restauração dos serviços, o tão temido Ora-00600 começou a nos assombrar.

Este erro, para quem não conhece, é um erro genérico que ocorre a nível de kernel do RDBMS. E diferente de todos os outros erros do Oracle este erro pode vir em vários formatos, porém nenhum deles nos dá muita informação.

ORA-00600 [14000][51202][1][51200][][]

Neste formato, temos algumas informações referentes ao erro, porém somente alguns sayajins conseguiriam interpretar isso.

Mas por que isso esta acontecendo?

Bom, dentre as várias possibilidades, duas se destacam.

  • Falta de recursos do servidor, o que pode ser facilmente resolvido;
  • Acessos errôneos a tabela DUAL (indicado usar SYS.DUAL);
  • Corrupção de arquivos, e aqui já não temos muito o que falar, só chorar mesmo;

Neste caso em especifico o problema foi ocasionado por uma corrupção de arquivos físicos, as dbfs do Oracle.

O que fazer?

A primeira e mais sensata opção, seria para o banco, efetuar uma verificação física dos arquivos (com o utilitário nativo do SO para o FS especifico), executar um analyze nas table spaces que estão apresentando problema, e ai sim, subir a base novamente.

Como nem sempre isto é possível, muitas vezes a restauração é feita on-line, o que não garante que o processo será integro. Por mais que o RDBMS seja extremamente avançado, robusto e consistente, não existe forma inteligente de se lidar com uma corrupção.

Com o comando abaixo, vamos coletar 5% dos dados do schema, o que vai nos dar uma noção de como ele está:

dbms_stats.gather_schema_stats(ownname=>'dono do schema', estimate_percent=>5, cascade=>true);

Após todo o processo “efetuado”, continuamos recebendo o erro. Desta forma concluímos que a corrupção passava a ser lógica e não física. Ou seja a integridade dos arquivos estava OK, porém os dados contidos neles não estavam.

A partir dai, começa uma caçada, tentando encontrar onde esta o erro. Nestes casos, devemos mapear o comando que esta estourando a exceção, e analisar o mesmo tentando isolar suas variáveis.

Neste caso, identificamos que o comando era um UPDATE, dentro deste update conseguimos isolar um índice em especifico.

Então, a primeira coisa seria recriar o índice, certo? Certo, mas neste caso, como a base estava online, o objeto estava ocupado, então recriá-lo não é uma tarefa tão simples assim, visto que pelo fato de este estar corrompido, um rebuild online não era uma opção.

Vamos então para um passo a passo, que pelo menos neste caso, nos ajudou a resolver o problema:

Vamos ver quem está bloqueando quem

select
  (select username from v$session where sid=a.sid) blocker,
  a.sid,
  ' bloqueando ',
  (select username from v$session where sid=b.sid) blockee,
  b.sid
from
  v$lock a, v$lock b
where
  a.block = 1 and
  b.request > 0 and
  a.id1 = b.id1 and
  a.id2 = b.id2;

Se “matarmos” as sessões que estão tando lock em nosso recurso, podemos começar a planejar a recuperação.

Com o id da sessão, podemos pegar mais informações na tabela v$session.

Para garantir que o objeto não seja ocupado pelo otimizador, vamos deixar ele inutilizável, em seguida vamos recriar o índice:

ALTER INDEX nome_indice UNUSABLE;
commit;
ALTER INDEX nome_indice REBUILD NOLOGGING;
commit;

Neste caso, não usamos o parâmetro ONLINE, pois queremos que a tabela seja bloqueada, e o índice antigo seja completamente sobreposto. O parâmetro NOLOGGING diz não gera informações de UNDO, o que torna o processo muito mais rápido.

Abaixo deixo alguns links, de quem entende MUITO mais neste assunto.

Até a próxima o/

http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes004.htm

http://profissionaloracle.com.br/blogs/flaviosoares/tag/rebuild-index/

http://www.mssqltips.com/sqlservertip/2361/rebuilding-sql-server-indexes-using-the-online-option/

http://jonathanlewis.wordpress.com/2009/06/05/online-rebuild/

About these ads
Marcado com: , , ,
Publicado em banco de dados, oracle

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 146 outros seguidores

%d blogueiros gostam disto: