Olá! Hoje estou aqui para compartilhar, além do conhecimento adquirido, um problema que vivenciei recentemente.

Aviso que não sou especialista em RMAN, muito menos em Backup, apenas tenho muita teoria acumulada e pouca prática. Mas vamos ao ocorrido…

Após duas quedas abruptas da rede elétrica do meu data center, consequentemente tudo que se situava dentro dele veio abaixo. Claro que, como havia o NO-Break segurando a rede, 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.

Segue o passo a passo do ocorrido.

Ambiente

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

Antes de começar o processo, solicitei ao pessoal da Infa (Suporte a redes e servers, os Sysadmins) que restaurasse meu último backup válido, que seria o anterior à segunda queda. 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, mas cada um tem sua formatação e nomes de acordo com seu ambiente e com suas necessidades.

Notem que há 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 restaurado o 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.

Quem informou que você tinha blocos corrompidos?

Tomei consciência desses 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.

Diante desse cenário, comecei a tentar fazer a recuperação desses Blocos. É necessário que o banco de Dados saiba quais blocos estão corrompidos e nos forneça essa informação para conseguirmos dar início às 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 possa popular a visão v$database_block_corrpution com os blocos comprometidos no processo:

Visão:

V$DATABASE_BLOCK_CORRUPTION

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.: Um breve descritivo do que contém essa visão e quais informações 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: Me conectei ao meu catálogo, à minha base, se você possuir nas suas pré-definições de políticas uma opção de PARALELLISM definida, não há necessidade que sejam alocados canais manualmente, pois estes obedecerão ao que estiver definido nesta linha “CONFIGURE DEVICE TYPE DISK PARALLELISM 10 BACKUP TYPE TO BACKUPSET;”

Para esse processo, usei 10 threads, mas pode variar de acordo com o hardware que cada um de vocês tiver disponível.

Feito isso, temos a opção de CROSSCHECK BACKUP. que serve para marcar seus BS’s (Backuppieces) como disponíveis para uso pelo seu processo de restore, ele irá validar os BS’s restaurados da fita colocando-os em status de available.

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 nível de corrupção dos blocos de um banco 10g, você pode sim manter um backup funcionando. Até um Duplicate Database pode rolar normalmente, visto que o status desses blocos são fraturados, não é uma corrupção a nível físico, 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, nesse caso é inutil, ele não conseguirá recuperar esse bloco.

Veja como fica a saída do Validate após o preencimento da Visão

Iniciando o block recover:

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 específicos BLOCOS de um DATAFILE em específico. 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 nesse 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 os seus Backups restaurados não possuem a informação de que ele precisa para que seu backup seja recuperado. Tudo que você precisará fazer agora é se valer do comando LIST BACKUP no seu RMAN para identificar os BS’s do seu Datafile em questão e restaurá-los e tentar novamente a recuperação. Há também ainda no comando LIST a opção de que ele mostre os BS’s de um determinado período, basta que executemos esta 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

Essa é uma saída simples de um comando LIST BACKUP OF DATAFILE X; executado dentro do seu RMAN. Nele, temos todas as informações necessárias (datas, nomes, tamanho, etc) informações importantes para que identifiquemos com precisão qual nosso BS’s necessários.

Passados esses apuros, refaça o processo e execute o comando de BLOCKRECOVER denovo. 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

Ele demonstra claramente os BS’s que está lendo, para quais Datafiles e o tempo que levou para a restauração.

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 necessariamente recorrer ao BMR para recuperá-los, há outras alternativas, como REBUILD ONLINE, ou o próprio DROP e CREATE do índice em questão. Basta identificar no seu banco de dados, através do número de bloco fornecido na tabela V$DATABASE_BLOCK_CORRUPTION, e checar junto a outra visão a DBA_SEGMENTS. Lá, você encontrará colunas como BLOCKS, SEGMENT_NAME e SEGMENT_TYPE, o que ajuda a identificar o objeto, no caso for um índice tentar os outros caminhos.

Obrigado!