Recuperação de corrupção de dados

Uma árvore de decisão passo a passo para corrupção de dados (erros de checksum de bloco/página, tabelas ilegíveis, RDB/AOF corrompidos): primeiro confirme o escopo da corrupção e, em seguida, escolha corretamente entre recuperação no nível de bloco, restore completo/PITR a partir do backup e ferramentas de reparo de último recurso.

Qual é o escopo da corrupção?

Primeiro execute uma verificação de integridade para determinar até onde a corrupção se espalhou. Apenas alguns blocos/páginas estão corrompidos, um único objeto (tabela/índice) foi afetado ou a corrupção é generalizada? Faça a varredura com os comandos abaixo para determinar o escopo e escolha o ramo adequado.

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;  -- then: SELECT file#, block#, blocks, corruption_type FROM v$database_block_corruption;

• Apenas alguns blocos / páginas estão corrompidos
• Um único objeto (tabela/índice) foi afetado
• A corrupção é generalizada / muitos objetos
• As ferramentas de verificação não funcionam, o banco não abre
• A corrupção continua se repetindo (suspeita de causa raiz)

Causa raiz: corrupção limitada de blocos/páginas → recuperação direcionada

Se apenas alguns blocos/páginas estiverem corrompidos, não é necessário restaurar o banco inteiro. Minimize a perda de dados reparando apenas as partes corrompidas a partir do backup/logs com o recurso de recuperação no nível de bloco/página do engine.

Causa raiz: corrupção no nível de objeto/generalizada → restore completo ou PITR a partir do backup

Se a corrupção se espalhou para um ou mais objetos, o caminho mais seguro é restaurar a partir de um backup bom e, quando possível, avançar até o momento da corrupção (PITR). Isso evita a perda de dados que as ferramentas de reparo causariam.

Sem backup / o banco não abre — partindo para o último recurso?

As ferramentas de reparo (REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery, --fix) PODEM CAUSAR PERDA DE DADOS e podem violar restrições de integridade. Elas são o último recurso somente quando não existe backup utilizável e o banco não pode ser aberto. Primeiro, certifique-se de que realmente não há backup utilizável.

• Encontrei um backup bom, vou restaurar
• Não há nenhum backup, uma ferramenta de reparo é a única opção

Último recurso: ferramentas de reparo com risco de perda de dados

Essas ferramentas descartam linhas/páginas corrompidas para tornar o banco possível de abrir. Use-as somente se não houver backup e depois de ter feito uma cópia dos arquivos existentes. Objetivo: abrir o suficiente para exportar os dados e depois movê-los para uma cópia limpa.

Causa raiz: hardware/infraestrutura → corrija a origem e habilite checksums

Se a corrupção continua se repetindo, a causa real é muito provavelmente o disco, a controladora, a memória (RAM) ou uma camada de armazenamento instável. Recuperar os dados não basta; se você não corrigir a origem, a corrupção voltará. Habilite também a verificação de checksum/integridade para detecção precoce.