Introdução
Manter um banco de dados operando em modo ARCHIVELOG é uma boa prática para ambientes de produção e que “garante” que qualquer operação DML realizada no banco de dados pode ser recuperada. Contudo, quando uma operação que não gera redo log é executada, os resultados dessa operação são consideradas inrrecuperáveis mesmo em um banco de dados operando em ARCHIVELOG.
Quando isso ocorre, a única garantia de recuperabilidade é realizar um backup os datafiles alterados por essas operações. A depender do ambiente, pode ser fácil identificar qual datafile precisa ser submetido a um backup. Por outro lado, há ambientes com muitos schemas e tablespaces que tornam essa tarefa um pouco mais complicada. Também, nem sempre o DBA está ciente que essas operações estão sendo executadas (aquele desenvolvedor que usa hint nologging “secretamente”).
Solução
Como sempre, pensando em facilitar a vida do DBA (obrigado, Oracle!) a Oracle disponibiliza um recurso muito útil para esse tipo de situação: Um relatório do RMAN!
O comando:
RMAN> report unrecoverable database;
Exemplo
- Verificando se há datafiles afetados por operações inrrecuperáveis
RMAN> report unrecoverable database;
2. Fazendo um INSERT em uma tabela com NOLOGGING
SQL> Create table exemplo_rman nologging tablespace users as select * from user_tables;
3. Verificando datafiles afetados por essa operação no RMAN
4. Realizando um backup do datafile específico
RMAN> backup datafile 6; Starting backup at 21-JAN-20 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=243 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=299 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00006 name=/u02/oradata/hot/users.dbf channel ORA_DISK_1: starting piece 1 at 21-JAN-20 channel ORA_DISK_1: finished piece 1 at 21-JAN-20 piece handle=/u02/fast_recovery_area/HOT/backupset/2020_01_21/o1_mf_nnndf_TAG20200121T000805_h2dtro79_.bkp tag=TAG20200121T000805 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 21-JAN-20 Starting Control File and SPFILE Autobackup at 21-JAN-20 piece handle=/u02/fast_recovery_area/HOT/autobackup/2020_01_21/o1_mf_s_1030234086_h2dtrp94_.bkp comment=NONE Finished Control File and SPFILE Autobackup at 21-JAN-20 RMAN>
5. Verificação final
Outras variações do comando
Um tablespace específico
RMAN> report unrecoverable tablespace users;
Um datafile específico
RMAN> report unrecoverable datafile 6;
Conclusão
Esse pequeno exemplo apresentou de maneira simples o funcionamento de uma das opções de report no RMAN. Note que apesar de ser possível especificar um tablespace ou datafile em vez de todo o database na emissão do relatório, na maioria dos casos faz mais sentido emitir para todo o database, afinal, a ideia principal é descobrir qual datafile foi submetido a esse tipo de operação).
Referências e mais opções de report no RMAN aqui