sexta-feira, 17 de setembro de 2010

ORA-00313 - COMO RESOLVER ESSE PROBLEMA?

Olá pessoal, como estão vocês?

Antes de mais nada quero agradecer as visitas, os emails, os comentários e principalmente pelo respeito que todos demonstram, aqui vai meu muito obrigado á todos.

Bem, agradecimentos feitos vamos ao artigo.

No nosso ultimo artigo eu indiquei possiveis problemas envolvendo REDO LOG files, perdas, corrupções, adições , remoções, etc Agora eu trago para nós uma "SIMULAÇÃO" de um daqueles problemas que descrevi.

Neste ambiente controlado onde simulei o problema eu utilizo meu próprio DESKTOP, com um banco de dados 10g Release 2.

Espero que apreciem o artigo, e não deixem de comentar.


ORA-00313

Sempre que nos deparamos com algum erro ORA em nosso Banco de Dados, é tendencioso de no mesmo momento recorremos aos buscadores para checkar a mensagem de erro, ou as vezes por vicios da profissão você até os decora e já sabe de cor o porque daquela sinalização.

Aqui nos estamos falando de um erro particularmente ligado aos REDO, ou melhor, a perda deles.

Antes de iniciarmos vejamos a mensagem completa sinalizada pelo nosso database :

Fri Sep 17 09:46:38 2010
Errors in file c:\oracle\product\10.2.0\admin\labdb\bdump\labdb_lgwr_5884.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\LABDB\REDO01B.LOG'
ORA-27041: unable to open file
OSD-04002: não é possível abrir arquivo
O/S-Error: (OS 2) O sistema não pode encontrar o arquivo especificado.



Esta informação acima eu retirei do meu arquivo de ALERT.LOG, um poderoso "dedo-duro" do seu banco de Dados Oracle, e também um excelente termometro que sempre indica os problemas que seu Banco pode estar passando.


Como podemos ver na mensagem, o nosso Banco esta sinalizando que não conseguiu abrir um de nossos arquivos de REDO, e que este mesmo arquivo muito provavelmente esta perdido. Isso pode ser ocasionadopor "N" situações, um restore de arquivos mal feito, uma manutenção em disco onde alguem apaga algo que não deveria, um setor defeituoso no disco que impossibilita a leitura do arquivo, o que nos força a remove-lo , etc 

Vamos ver então como simular esse problema acima e como corrigir sem causar danos e dores aos DBA's.

DETECTANDO E CORRIGINDO O ORA-00313

Inicialmente vale salientar que a perda dos membros do seu grupo que estiver em CURRENT pode ocasionar outros erros e a indisponibilidade da Base de dados, no nosso caso a perda se deu nos membros dos grupos não CORRENTES

Passo1 : Me conecto ao Banco para ver quais arquivos já possuo , sua respectiva nomemclatura e status.

Ok, feito isso sem maiores transtornos vamos a tarefa seguinte.

Passo2 : Adicionar mais membros de REDO em todos os grupos.


Aqui podemos notar que eu coloquei mais um membro em cada grupo de REDO, e tudo isso através do comando "ALTER DATABASE ADD LOGFILE MEMBER", mencionado no nosso ultimo artigo.


Passo3 : Checkar a Adição dos novos Membros.



Usando nossas visões de apoio V$LOG e V$LOGFILE eu consigo saber informações suficientemente necessárias para as minhas atividades pertinentes a manutenção em REDO LOG files.


Passo4 : Colocando os novos arquivos disponiveis para uso.




Notem que no passo3, o status dos arquivos novos que adicionamos está como INVALID, é uma caracteristica normal , pois eles ainda não foram colocados para uso, e para que possamos indicar para o nosso Banco que ele tem novos membros para utilizar , nós podemos forçar isso via SWITCH LOGFILE, como demonstrado acima.


Reparem na figura acima que agora estão todos membros ONLINE e DISPONIVEIS para uso pelo banco de dados.

Agora vem um passo importante, execute essas atividades após ter adicionado seus membros novos :


- SHUTDOWN IMMEDIATE no seu Banco
- Vá até o diretório onde estão seus REDO LOGS e REMOVA qualquer um dos seus arquivos de REDO que não fazem parte do grupo CURRENT , no meu caso acima são os membros do GRUPO 1, 3 e 4.
- STARTUP em seu banco de dados.


Essas tarefas acima, são uma espécie de simulação de queda de energia, onde seu BD cai, ou até mesmo uma simulação de uma manutenção no servidor onde apagaram coisas que não deveriam.


OBS.: Com seu banco ONLINE se você estiver usando WINDOWS, um erro aparecerá ao tentar deletar qualquer dos arquivos de REDO, uma mensagem informando que estão em uso é mostrada.


Passo5 : Eis que surge nosso Erro.


Após realizar o STARTUP do seu Banco, vá até o diretório BDUMP, onde fica localizado seu arquivo de ALERT.LOG. Para os que não estão familiarizados com a estrutura do OFA o diretório BDUMP fica no seu "%ORACLE_BASE%/admin/nome_da_instancia/bdump".

Localizado o arquivo, abra-o com algum editor, vá até o final do arquivo que você encontrará a mensagem que está aparecendo na imagem acima, um erro ORA-00313.


Antes de sair restaurando bakup a toa, chamando Deus e o mundo, alarmando sem necessidade, verifique primeiro tudo que for possivel.


Quando essa mensagem aparecer vá até o diretório e check realmente se os arquivos ainda estão lá, ou se a referencia a eles realmente é verdadeira e os mesmos não estão presentes em disco.




Reparem que realmente eu não tenho os MEMBROS que estavam criados para o grupo 1,3 e 4 com a letra "B" ao final dos seus respectivos nomes. Eu realmente os perdi, o que fazer então?


Antes de mais nada veja como ficou sua visão de dicionário após o incidente.




Os arquivos falntantes voltam ao status de "INVALID", e se você ficar acompanhando seu arquivo de ALERT.LOG, verá que é marcado diversas vezes o erro após ter iniciado , isso ocorre porque a cada SWITCH que ele tenta fazer entre os grupos , e recebe a mensagem de que essa referencia lógica, fisicamente esta perdida, ele loga o nosso bom erro ORA-00313.


Passo6 : Removendo a referencia LÓGICA dos arquivos.


Bem, acima vimos que nós de fato não contamos mais com nossos arquivos fisicamente presentes no Banco de Dados, o que resta deles apenas é a referencia lógica, portanto nos resta apenas eliminar essa referencia, COMO FAZER ISSO?




Simples, isso é possivel através do comando "ALTER DATABASE DROP LOGFILE MEMBER", também citado no nosso ultimo artigo.


Com isso removemos lógicamente a referencia do nosso Banco a esses arquivos perdidos, feito isto vejam como nós encontraremos nossas visões de banco referentes aos REDO's:




Temos então as visões limpas, e sem os arquivos com STATUS de INVALID, o que já é um bom começo. Mas e o nosso ALERT.LOG, será que parou de "flegar" aquele erro intermitentemente?
Vejamos :

Fantastico, limpo e cristalino nosso ALERT.LOG, sem aquele erro que tanto incomodava quando era visto. Mas então e agora acaba assim? Como ficamos? Deixaremos nosso banco sem aqueles membros adicionais?

A resposta a isso é "NÃO", nós retornaremos com eles sem problemas.

Passo6 : Readicionando nossos arquivos de REDO

Agora que já eliminamos o erro, e que nosso ambiente aparentemente esta 100%, vamos devolver a estrutura do nosso Banco, os respectivos arquivos perdidos, pois se eles foram adicionados em algum momento é porque o Banco necessita deles para suas tarefas cotidianas e rotineiras , e para manter a boa performance também.


Uma vez readicionados, revisitaremos nossas visões V$LOG e V$LOGFILE para nos certificarmos de tudo :

 E lá estão eles, readicionados e com status de INVALID, isso é normal devido a razão aqui já explicada, vamos então proceder com a colocação dos mesmo a disposição do nosso banco.

 Mas antes disso, um pequeno "PIT STOP", em nosso disco fisico para realmente nos certificarmos de que agora esse STATUS INVALID é pela sua indisponibilidade para uso e não pela sua falta em DISCO. Vejam os arquivos já estão devolta a sua arvore estrutural.


Agora sim, a nossa constatação lógica do que acamos de realizar, vejam que tudo esta como deveria ser antes da problematica gerada pela perda de nossos membros de REDO LOG FILES.

Uma ultima olhada em nosso ALERT.LOG é extremamente válida para nos certificarmos de tudo.

E então um PARABÉNS para nós, cumprimos nossa missão de eliminar um erro de nosso banco e mantelo sempre em funcionamento pleno.

CONCLUSÃO :

Neste artigo nós aprendemos mais uma tarefa do dia-a-dia de um DBA de qualquer empresa, aprendemos como nos valer de ferramentas uteis e eficazes como nossas visões de banco, o ALERT.LOG nosso dedo-duro oficial, e também aprendemos uma técnica de recuperação e restauração de nosso ambiente sem gerar maiores complicações.

Saliento que isso é matéria de provas de certificação OCP, aqueles que já tiveram a oportunidade de se certificar podem comprovar isso aqui para vocês.

Espero sicneramente que tenham apreciado, fiz com muito gosto e aguardo seus comentários.


Abraço á todos e Sucesso Sempre!!!!