L'Incident
Questo Case Study tocca un punto dolente, molto comune. Rubrik considerava corretti i backup Oracle, tuttavia, da un test di restore dell’ambiente, risultava che, post recover PITR, il database segnalasse 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 risultavano errori di accesso a determinate tabelle, rendendo inutilizzabile il restore.
La causa
Quando contemporaneamente abbiamo gli errori ORA-01578 ( se abilitata la TDE troverete ORA-28304) e ORA-26040 siamo in presenza di un caso di corruption “controllata”, ovvero l’applicativo ha impostato delle operazioni con hint NOLOGGING, creando, de facto, delle operazioni volutamente non recuperabili.
Per abilitare il NOLOGGING serve una serie di combinazioni di parametri a livello DB/TBS/TABELLA/DDL
| Table Mode | Insert Mode | ArchiveLog Mode | Result |
|---|---|---|---|
| LOGGING | APPEND | ARCHIVE LOG | Redo generated |
| NOLOGGING | APPEND | ARCHIVE LOG | No redo (Critical) |
| LOGGING | No append | ARCHIVE LOG | Redo generated |
| NOLOGGING | No append | ARCHIVE LOG | Redo generated |
| LOGGING | APPEND | NoArchiveLog | No redo |
| NOLOGGING | APPEND | NoArchiveLog | No redo |
| LOGGING | No append | NoArchiveLog | Redo generated |
| NOLOGGING | No append | NoArchiveLog | Redo generated |
Esempio classico: il database è in ARCHVELOG e viene lanciato un insert con hint /*+ APPEND NOLOGGING */. Questo evita la generazione di REDO, rendendo l’operazione veloce ma non recuperabile in caso di media recovery.
Di norma lato DBA, il database administrator, assieme all’applicativo può decidere di impostare la parametrizzazione a livello di :
- tablespace
- tabella
- indice
- partizione
- sottopartizione
Invece a livello DML è possibile con gli hint su:
- INSERT
- CTAS
- CREATE INDEX
- ALTER TABLE
- ALTER INDEX
Di per sè tale opzione è una feature se usata consapevolmente, ma anche un enorme problema se usata massicciamente per dato non ricaricabile.
La remediation
Se non si ha il controllo sul codice è possibile forzare il FORCE LOGGING in uno di questi livelli:
- database
- pluggable db
- tablespace
in modo da propagare a tutti gli oggetti ivi contenuti.
Questo permette di evitare che implementazioni di operazioni di NOLOGGING creino 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, poiché la corruzione non emerge durante il backup, ma solo durante il ripristino.
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 il database si apra (OPEN). È necessario eseguire query di lettura (SELECT COUNT(*)) sulle tabelle critiche o eseguire test applicativi. Solo accedendo fisicamente ai dati l'errore ORA-01578 verrà scatenato se il blocco è corrotto.
2. Validazione Tecnica tramite RMAN
Se si desidera un controllo più rapido e mirato senza dover eseguire test applicativi manuali, è possibile utilizzare RMAN direttamente sul database appena ripristinato (post Recover PITR). La procedura varia a seconda della versione di Oracle:
- A) Per Oracle 12.2 e versioni successive - su un database ripristinato (dopo il Recover PITR), eseguire il comando specifico:
RMAN> VALIDATE DATABASE NONLOGGED BLOCK;
Questo comando scansiona i file e popola la vista dinamica v$nonlogged_block. Per vedere i risultati, interrogare la vista via SQL: SELECT * FROM v$nonlogged_block;
- B) Per Oracle 11g e versioni precedenti alla 12.2 - la sintassi specifica non è disponibile, quindi si utilizza il comando di validazione generico:
RMAN> VALIDATE DATABASE;
Successivamente, bisogna interrogare la vista di sistema che registra le corruzioni:
Per Oracle 11g e 12.1
SELECT * FROM v$database_block_corruption
WHERE CORRUPTION_TYPE = 'NOLOGGING';
Per versioni molto obsolete (pre-11g)
SELECT * FROM v$database_block_corruption
WHERE CORRUPTION_TYPE = 'LOGICAL';
È cruciale comprendere che i software di backup (come Rubrik, Veeam, ecc.) non segnaleranno mai questo errore. Dal punto di vista di RMAN (e quindi del software di backup), un blocco marcato come "NOLOGGING" è un blocco tecnicamente valido e coerente: Oracle ha scelto volontariamente di non scriverci dati. Di conseguenza, una dashboard di backup "verde" non garantisce l'assenza di questo problema.
Ti è piaciuto quanto hai letto? Iscriviti a MISPECIAL, la nostra newsletter, per ricevere altri interessanti contenuti.
Iscriviti a MISPECIAL
