Oracle NOLOGGING. Quando il backup è "Success" ma il Restore è inutilizzabile

L'Incident

Questo caso tocca un punto dolente, molto comune. Rubrik considerava corretti i backup Oracle; tuttavia un test di restore dell’ambiente ha mostrato che, dopo il recover PITR, il database segnalava una serie di blocchi corrotti:

ORA-01578: ORACLE data block corrupted (file # .., block # ..)
ORA-01110: data file 4: '*DISKGROUP/…'
ORA-26040: Data block was loaded using the NOLOGGING option

Una volta aperto il database, l’accesso a determinate tabelle generava errori e il restore risultava inutilizzabile.

La causa

Quando compaiono insieme gli errori ORA-01578 (o ORA-28304, se è abilitata la TDE) e ORA-26040, siamo in presenza di una corruzione “controllata”: l’applicativo ha eseguito operazioni in modalità NOLOGGING, che non generano redo e sono quindi, di fatto, volutamente non recuperabili.

Che un’operazione generi redo oppure no dipende dalla combinazione di tre impostazioni: modalità di logging della tabella, tipo di insert (direct-path con hint APPEND o convenzionale) e modalità di archiviazione del database. La tabella riassume i casi possibili quando non è attivo il FORCE LOGGING:

 

Esempio classico: il database è in ARCHIVELOG, la tabella è in modalità NOLOGGING e viene lanciata una insert direct-path con hint /*+ APPEND */. I dati caricati non generano REDO: l’operazione è veloce, ma non è recuperabile in caso di media recovery.

Di norma il DBA (database administrator), d’accordo con il team applicativo, può impostare la modalità NOLOGGING a livello di:

• tablespace
• tabella
• indice
• partizione
• sottopartizione

A livello di singola istruzione, invece, possono essere eseguite in NOLOGGING:

• INSERT direct-path (hint APPEND)
• CREATE TABLE … AS SELECT (CTAS)
• CREATE INDEX
• ALTER TABLE … MOVE
• ALTER INDEX … REBUILD

Di per sé questa opzione è una funzionalità utile, se usata consapevolmente, ma diventa un enorme problema se usata massicciamente su dati non ricaricabili.

La remediation

Se non si ha il controllo sul codice, si può attivare il FORCE LOGGING a uno di questi livelli:

• database
• pluggable database (PDB)
• tablespace

in modo che si estenda a tutti gli oggetti che contengono.

Con il FORCE LOGGING attivo, Oracle genera redo anche per le operazioni NOLOGGING, che quindi non creano più problemi nei ripristini PITR o nei recover da snapshot.

 

Come diagnosticare la “corruzione silenziosa”

Verificare se i propri backup contengono blocchi corrotti da operazioni NOLOGGING è fondamentale, perché la corruzione non emerge durante il backup, ma solo dopo il ripristino, quando si accede ai dati.

Esistono due metodi principali di verifica:

1. Test di restore funzionale (metodo empirico)

Il metodo più sicuro è pianificare test di restore periodici. Attenzione: non basta che il restore termini con successo e che il database si apra (OPEN). Bisogna leggere davvero i dati delle tabelle critiche, con query che ne scansionino tutti i blocchi, oppure eseguire test applicativi: l’errore ORA-01578 compare solo quando si accede a un blocco corrotto. Una semplice SELECT COUNT(*) può non bastare, perché Oracle può risolverla leggendo un indice senza toccare i blocchi della tabella; meglio forzare la scansione completa, per esempio con SELECT /*+ FULL(t) */ COUNT(*) FROM nome_tabella t;

2. Validazione tecnica con RMAN

Per un controllo più rapido e mirato, senza test applicativi manuali, si può usare RMAN direttamente sul database appena ripristinato (dopo il recover PITR). La procedura varia a seconda della versione di Oracle:

• A) Oracle 12.2 e versioni successive – su un database ripristinato (dopo il recover PITR), eseguire il comando dedicato: RMAN> VALIDATE DATABASE NONLOGGED BLOCK;

Questo comando scansiona i datafile e popola la vista dinamica v$nonlogged_block. Per vedere i risultati, interrogare la vista via SQL: SELECT * FROM v$nonlogged_block;

• B) Versioni precedenti alla 12.2 – la sintassi dedicata non è disponibile, quindi si usa il comando di validazione generico: RMAN> VALIDATE DATABASE;

Successivamente, bisogna interrogare la vista che registra i blocchi corrotti:

Per Oracle 11g e 12.1
SELECT * FROM v$database_block_corruption 
WHERE CORRUPTION_TYPE = 'NOLOGGING';

Per versioni precedenti alla 11g (i blocchi NOLOGGING risultano come corruzione LOGICAL)
SELECT * FROM v$database_block_corruption 
WHERE CORRUPTION_TYPE = 'LOGICAL';

È fondamentale capire che i software di backup (come Rubrik, Veeam ecc.) non segnaleranno mai questo errore. Per RMAN, e quindi per il software di backup, un blocco marcato come NOLOGGING non è una corruzione fisica: è un blocco formalmente valido e coerente, di cui Oracle ha scelto di non registrare le modifiche nel redo. Di conseguenza, una dashboard di backup “verde” non garantisce l’assenza di questo problema.