quarta-feira, 12 de agosto de 2009

RMAN - BMR (Block Media Recover )

Opa!!..e ai pessoal como vão vocês?

Bem , hoje estou aqui para compartilhar além do conhecimento adquirido, um problema que vivenciei nesta semana.

Antes de mais nada, não sou especialista em RMAN, muito menos em Backup, tenho muita teoria acumulada mais muito pouca prática, e esta semana ocorreu o seguinte problema, após 2 (duas) quedas abruptas da rede eletrica do meu data center, consequentemente tudo que se situava dentro dele veio abaixo, é claro que como havia u NO-Break segurando a rede por um tempo tive tempo de baixar algumas bases, porém uma das bases caiu (shutdown abort) sozinha, o que ocasionou na segunda volta uma corrupção de blocos no meu banco de dados.

Sendo assim me vi numa situação inusitada, com blocos corrompidos, backups via RMAN feitos e necessitando fazer um restore destes blocos.

Tentarei postar aqui neste pedaço como realizei o processo passo a passo, o que precisei fazer e tentarei também explicar o porque de cada passo.

Espero que apreciem.

AMBIENTE

Banco: Oracle 10g Release 10.2.0.3
S.O: Linux Red Hat Server 4

Primeiramente antes de começar o processo, solicitei ao pessoal da Infa ( Suporte a redes e servers , os Sysadmins) que restaurassem meu ultimo backup válido que seria o anterior a segunda queda, pois bem eis que restaurei os seguintes arquivos :

ARCHIVES
--------

/u03/backup/BKP_ARCHIVES_SPPE_694303245_7679.rman
/u03/backup/BKP_ARCHIVES_SPPE_694303245_7677.rman
/u03/backup/BKP_ARCHIVES_SPPE_694303245_7676.rman
/u03/backup/BKP_ARCHIVES_SPPE_694420597_7702.rman
/u03/backup/BKP_ARCHIVES_SPPE_694420597_7699.rman
/u03/backup/BKP_ARCHIVES_SPPE_694420597_7701.rman
/u03/backup/BKP_ARCHIVES_SPPE_694420597_7700.rman
/u03/backup/BKP_ARCHIVES_SPPE_694476818_7714.rman
/u03/backup/BKP_ARCHIVES_SPPE_694476818_7713.rman

HOT BACKUP
-----------

/u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7667.rman
/u03/backup/BKP_FULL_ONLINE_SPPE_694296026_7671.rman
/u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7668.rman
/u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7669.rman
/u03/backup/BKP_FULL_ONLINE_SPPE_694296026_7670.rman

Obs.: Esse é apenas um modelo dos meus arquivos, mais cada um tem sua formatação e nomes de acordo com seu ambiente e suas necessidades.

Notem que acima tem uma listagem de ARCHIVES e de HOT BACKUPS ( Backuppieces, termo utilizado pela Oracle para identificar o "pedaço" do seu backup onde se encontram as informações necessárias para a volta do seu Backup).

Tendo isso em mãos e restaurados em disco em um diretório pré-configurado para abrigar os arquivos provenientes de RESTORE de fita ( LTO's, DAT, DLT's, etc), eu ainda precisava saber quais eram os tais blocos corrompidos que me informaram existir. MAS ESPERA UM POUCO, QUEM INFORMOU QUE VOCÊ TINHA BLOCOS CORROMPIDOS? Bom questionamento, tomei consciencia destes blocos quando um dos developers precisou acessar uma tabela e recebeu a seguinte mensagem de erro ORA-00604,ORA-01578, esses erros informam exatamente o número do DATAFILE e o número do BLOCO com problemas.

Bom, então diante desse cenário começei a tentar fazer a recuperação desses Blocos, antes de iniciar é necessário que o banco de Dados saiba quais blocos estão corrompidos e nos forneça essa informação para que consigamos dar inicio as recuperações.

POPULANDO A VISÃO V$DATABASE_BLOCK_CORRUPTION

Conectado ao seu RMAN, CATALOGO e BASE ( TARGET), efetue o comando de VALIDATE para que este possa popular a visão v$database_block_corrpution com os blocos comprometidos no processo:

Visão:

V$DATABASE_BLOCK_CORRUPTION displays information about database blocks that were corrupted after the last backup.

Column Datatype Description
FILE# NUMBER Absolute file number of the datafile that contains the corrupt blocks
BLOCK# NUMBER Block number of the first corrupt block in the range of corrupted blocks
BLOCKS NUMBER Number of corrupted blocks found starting with BLOCK#
CORRUPTION_CHANGE# NUMBER Change number at which the logical corruption was detected. Set to 0 to indicate media corruption.
CORRUPTION_TYPE VARCHAR2(9) Type of block corruption in the datafile:
•ALL ZERO - Block header on disk contained only zeros. The block may be valid if it was never filled and if it is in an Oracle7 file. The buffer will be reformatted to the Oracle8 standard for an empty block.

•FRACTURED - Block header looks reasonable, but the front and back of the block are different versions.

•CHECKSUM - optional check value shows that the block is not self-consistent. It is impossible to determine exactly why the check value fails, but it probably fails because sectors in the middle of the block are from different versions.

•CORRUPT - Block is wrongly identified or is not a data block (for example, the data block address is missing)

•LOGICAL - Specifies the range is for logically corrupt blocks. CORRUPTION_CHANGE# will have a nonzero value.

Obs.: Acima um breve descritivo do que contém esta visão e quais informações nos serão mostradas em seu conteúdo.

Então vamos aos comandos de VALIDATE:

connect catalog rmancat/******@xxxx;
connect target rman/*******@xxxx;

crosscheck backup;
crosscheck archivelog all;
backup validate check logical database;

Nota: Veja , eu me conectei ao meu catalogo a minha base como informei acima, se você possuir nas suas prédefinições de politicas uma opção de PARALELLISM definida não há necessidade que sejam alocados canais manualmente, pois estes obedeceram ao que estiver definido nesta linha "CONFIGURE DEVICE TYPE DISK PARALLELISM 10 BACKUP TYPE TO BACKUPSET;"

Para este meu processo eu usei 10 threads, mais isso pode variar de acordo com cada Hardware que cada um de vocês tiver disponivel para uso.

Feito isto temos a opção de CROSSCHECK BACKUP, este comando serve para marcar seus BS's ( Backuppieces) como disponiveis para uso pelo seu processo de restore, ele ira validar os BS's restaurados da fita colocando-os em status de AVALIABLE.

O comando CROSSCHECK também deve ser executado para seus Archive logs (CROSSCHECK ARCHIVELOG ALL), pois eles serão fundamentais no processo de restauração.

E por fim executaremos o BACKUP VALIDATE CHECK LOGICAL DATABASE , para podermos saber quais blocos estão comprometidos.

Obs.: Dependendo do nivel de corrupção dos blocos de um banco 10g , você pode sim manter um backup funcionando, e até um DUPLICATE DATABASE pode rolar normalmente, visto que o status desses blocos são FRATURADOS, não é uma corrupção a nível fisico, que possa comprometer seu backup, isso pode ser verificado atráves do DBVerify, ele passará pelo seu datafile sem alertar nenhum bloco como corrompido fisicamente, e também se houver uma tentativa de utilizarmos a DBMS_REPAIR neste caso é inutil, ele não conseguirá recuperar este BLOCO.

Veja como fica a saida do Validate após o preencimento da Visão:

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
1 82608 1 0 CORRUPT
13 153512 1 0 CORRUPT
1 80864 1 0 CORRUPT
1 64148 1 0 CORRUPT
13 55512 1 0 CORRUPT
1 63932 1 0 CORRUPT
1 92540 1 0 CORRUPT
13 153560 1 0 CORRUPT
13 153720 1 0 CORRUPT
166 25940 1 0 CORRUPT
61 368792 1 0 CORRUPT

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
76 480016 1 0 CORRUPT
122 245036 1 0 CORRUPT


13 linhas selecionadas.

Essa é a "lista negra", que você deve ir eliminado aos poucos.

INICIANDO O BLOCKRECOVER

Ao terminarmos com o Validate , é hora de iniciar a recuperação, há 2 métodos distintos, você pode muito bem pedir que o RMAN faça a recuperação direta de toda sua lista de blocos corrompidos ou pode também pedir que o RMAN recupere especificos BLOCOS de um DATAFILE em especifico, isso tudo através do comando :


blockrecover corruption list; [Este irá recuperar toda sua lista de blocos corrompidos]

blockrecover datafile x block x,y,z; [Este comando irá recuperar os blocos determinados de um mesmo datafile em questão]

Obs.: Pode ocorrer neste periodo o seguinte problema :

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of blockrecover command at 08/10/2009 17:33:49
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 122 found to restore
RMAN-06023: no backup or copy of datafile 76 found to restore
RMAN-06023: no backup or copy of datafile 61 found to restore

Nada de pânico, você não fez nada de errado, essa mensagem de erro quer dizer que no seus Backups restaurados não possuem a informação que ele precisa para que seu backup seja recuperado, tudo que você precisara fazer agora é se valer do comando LIST BACKUP no seu RMAN para identificar os BS's do seu Datafile em questão e restauralos e tentar novamente a recuperação, ha também ainda no comando LIST a opção de que ele mostre os BS's de um determinado periodo basta que executemos essa linha LIST BACKUP OF DATABASE ARCHIVELOG FROM TIME 'sysdate-3';, veja :

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
285126 Full 61.86G DISK 01:03:15 07/08/2009 21:03:40
BP Key: 285135 Status: AVAILABLE Compressed: NO Tag: TAG20090807T200023
Piece Name: /u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7669.rman
List of Datafiles in backup set 285126
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
122 Full 8179671094807 07/08/2009 20:00:26 /u02/oracle/oradata/sppe/tbs_par_index_04_02.dbf

Esta é uma saida simples de um comando LIST BACKUP OF DATAFILE X; executado dentro do seu RMAN, nele temos todas informações necessárias ( datas, nomes, tamanho, etc) informações essas necessárias para que identifiquemos com precisão qual nosso BS's necessário.

Passado esses apuros, refaça o processo e execute o comando de BLOCKRECOVER dinovo. Ao fazer isso ele iniciará o processo assim :

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00061
restoring blocks of datafile 00166
restoring blocks of datafile 00001
channel ORA_DISK_1: reading from backup piece /u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7667.rman
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/u03/backup/BKP_FULL_ONLINE_SPPE_694296025_7667.rman tag=TAG20090807T200023
channel ORA_DISK_1: block restore complete, elapsed time: 00:03:26
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00076
channel ORA_DISK_1: reading from backup piece /u03/backup/BKP_FULL_ONLINE_SPPE_694296026_7671.rman
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/u03/backup/BKP_FULL_ONLINE_SPPE_694296026_7671.rman tag=TAG20090807T200023

Aqui ele demonstra claramente os BS's que ele esta lendo para quais Datafiles e o tempo para a restauração que ele levou.

o RMAN terminara o processo lhe mostrando a seguinte mensagem, caso dê tudo certo :


starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished blockrecover at 11-AGO-2009 14:26:08


Isso indica que seus blocos corrompidos foram RECUPERADOS com sucesso, e para se certificar disso refaça o processo de VALIDATE BACKUP para que a visão de blocos corrompidos possa ser populada novamente com a nova situação.

Uma observação de minha parte, caso seus blocos correspondam a objetos do tipo INDEX, você não precisa necessáriamente recorrer ao BMR para recupera-los, tem outras alternativas, como REBUILD ONLINE, ou o proprio DROP e CREATE do indice em questão, basta identificar no seu Banco de Dados através do numero de bloco fornecido na tabela V$DATABASE_BLOCK_CORRUPTION , e checkar junto a outra visão a DBA_SEGMENTS , lá você encontrará colunas como BLOCKS, SEGMENT_NAME e SEGMENT_TYPE , o que ajuda em muito identificar o objeto e se no caso for um indice tentar os outros caminhos.

Bom é isso rapaziada, obrigado e ofereço este Post aos meus amigos Rodrigo Almeida e Régis, dois excelentes profissionais.

Abraço á todos!!!!