Durante a execução do ORAchk em um banco de produção, foi identificado que alguns datafiles apareceram como não recuperáveis. Neste ambiente, o forcing log não estava ativado, permitindo operações diretas como cargas SQL*Loader ou DMLs paralelas sem geração de redo logs. Esse cenário é esperado, mas exige atenção, pois os datafiles podem estar em risco caso não existam backups recentes.
O problema Indicado
SQL>
SELECT COUNT(1) AS total_files,
TRUNC(unrecoverable_time) AS unrecoverable_date
FROM v$datafile
WHERE unrecoverable_time IS NOT NULL
AND unrecoverable_change# > 0
GROUP BY TRUNC(unrecoverable_time)
ORDER BY unrecoverable_date;
TOTAL_FILES UNRECOVER
----------- ---------
1 18-NOV-24
1 27-NOV-24
2 28-DEC-24
3 14-JAN-25
1 15-JAN-25
238 19-JAN-25
1 22-JAN-25
7 rows selected
SQL> O resultado da consulta apontado pelo ORAchk é considerado um problema porque indica que alguns datafiles possuem valores no campo unrecoverable_time. Isso significa que foram realizadas operações não recuperáveis nesses datafiles, e o ORAchk interpreta que essas alterações podem estar sem proteção caso não tenha sido feito um backup após essas operações.
Será Mesmo? Vamos Verificar de outra Forma
RMAN> REPORT UNRECOVERABLE;
Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------
RMAN>Isso indicou que não havia um problema de fato no banco, porque o comando acima não apresentou nenhum indicativo de datafiles necessitando de backup devido a operações não recuperáveis.
Ao consultar a documentação oficial do Oracle sobre unrecoverable_time na visão V$DATAFILE, temos o seguinte:
Documentação oficial do Oracle – V$DATAFILE
- Esse campo só é atualizado se o banco de dados estiver no modo ARCHIVELOG.
- Ele não é redefinido automaticamente após a execução de backups completos ou incrementais.
Consulta alternativa para validação
Para garantir que os datafiles estão protegidos, foi executada a seguinte consulta, cruzando as informações de alterações não recuperáveis com os últimos backups completos (DB FULL) e incrementais (DB INCR) bem-sucedidos no RMAN:
SQL>
SELECT df.*
FROM v$datafile df, v$backup bk
WHERE df.file# = bk.file#
AND df.unrecoverable_change# <> 0
AND df.unrecoverable_time >
(SELECT MAX(end_time)
FROM v$rman_backup_job_details
WHERE input_type IN ('DB FULL', 'DB INCR')
AND status = 'COMPLETED');
no rows selected
SQL>Neste caso específico, a consulta não retornou resultados. Isso significa que:
- Não há datafiles em risco atualmente. Todos os datafiles com alterações não recuperáveis já estão protegidos por um backup completo ou incremental realizado após essas alterações.
- O campo unrecoverable_time continua mostrando o histórico de operações, mas isso não reflete o estado atual de risco.
Apesar de o ORAchk indicar o problema como um alerta, como pudemos comprovar, trata-se de um alarme falso.
Como redefinir o campo unrecoverable_time
Se o valor exibido no campo unrecoverable_time for um problema (gerando alertas falsos em ferramentas de monitoramento), ele só pode ser redefinido recriando o control file . A recriação do control file exige a interrupção do serviço do banco. Esse é um procedimento crítico que deve ser planejado cuidadosamente e executado em janelas de manutenção.
O passo a passo para essa operação não será abordado neste post técnico.
Embora o campo unrecoverable_time no V$DATAFILE exiba o histórico de operações não recuperáveis, a consulta apresentada confirmou que nenhum datafile está em risco atualmente, pois todas as alterações não recuperáveis foram protegidas por backups completos ou incrementais.
Esse tipo de alerta é esperado em bancos sem forcing log, mas não representa um problema imediato, desde que backups regulares estejam sendo realizados. Apesar do ORAchk indicar isso como um problema, pudemos comprovar que se trata de um alarme falso.
e zás . . .
⛑️🪖 #20250124 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #OracleACE ⛑️🪖
