Sono le 3 del mattino. Un job batch si blocca, i log iniziano a riempirsi di ORA-01578, qualcuno in reparto IT propone la soluzione più ovvia: riavviare l’istanza e vedere se “si risolve da sola”. Non si risolve da sola. Quel riavvio, nella maggior parte dei casi, è il momento esatto in cui un problema recuperabile diventa una perdita di dati permanente.
Chi ci chiama in queste situazioni ha già capito che il tempo non è dalla sua parte. Non vuole una spiegazione teorica su cosa sia un block corruption. Vuole sapere cosa fare, in che ordine, e chi deve farlo.
Il riavvio è il primo errore
La corruzione di un database Oracle si manifesta quasi sempre con sintomi ambigui: query che restituiscono errori intermittenti, un tablespace che non si apre, un ORA-600 che compare senza pattern chiaro. La reazione istintiva è forzare un restart, sperando che il problema si “auto-corregga” al riavvio dell’istanza.
Il riavvio non corregge nulla. Sovrascrive lo stato del sistema nel momento esatto in cui quello stato ti serviva per capire cosa è successo e cosa è ancora recuperabile. Ogni checkpoint successivo alla corruzione è un’informazione che perdi per sempre.
Corruzione logica o corruzione fisica: non è la stessa emergenza
Prima regola: non tutte le corruzioni sono uguali, e trattarle come se lo fossero è il secondo errore più comune dopo il riavvio.
- Corruzione fisica — blocchi danneggiati a livello di storage, spesso causati da problemi hardware, controller RAID, o interruzioni improvvise durante una scrittura.
- Corruzione logica — struttura dei dati incoerente, indici disallineati, constraint violati: il blocco è leggibile, ma il contenuto non ha senso.
La diagnosi corretta cambia completamente la strategia di intervento. Confonderle significa applicare il rimedio sbagliato — e nel frattempo, il vero problema continua a propagarsi.
I passi che contano davvero
Prima di toccare qualsiasi cosa, la sequenza è sempre la stessa, indipendentemente dalla versione o dall’architettura:
- Isolare l’istanza — nessun nuovo accesso in scrittura, nessun job automatico che possa aggravare la situazione.
- RMAN VALIDATE DATABASE — per mappare esattamente quali blocchi sono corrotti e quali no, senza modificare nulla.
- DBVERIFY sui datafile sospetti, per confermare l’estensione reale del danno prima di decidere.
- Congelare lo stato attuale con un backup a freddo della situazione così com’è, corrotta o non corrotta — è la tua unica assicurazione contro un secondo errore.
- Solo dopo, valutare flashback database, restore point o recovery via RMAN, in base a cosa la diagnosi ha effettivamente rivelato.
Chi salta il primo passo per “guadagnare tempo” quasi sempre lo perde due volte.
RTO e RPO non sono slide da comitato
In molte aziende, RTO e RPO esistono solo su un documento di business continuity mai testato davvero. Nel momento della corruzione, quel documento diventa l’unica cosa che conta: quanto tempo puoi restare fermo, e quanti dati puoi permetterti di perdere tra l’ultimo backup buono e l’evento.
Se non hai mai simulato un recovery reale, non lo scopri leggendo la documentazione Oracle alle 4 del mattino. Lo scopri quando è troppo tardi per cambiare strategia.
Perché serve un DBA senior, non un tutorial
Su forum e community trovi decine di guide su come “risolvere ORA-01578”. Nessuna di quelle guide conosce la tua architettura, il tuo storage, la tua storia di backup, i tuoi vincoli di compliance. Applicare un comando copiato da uno stack overflow su un database di produzione corrotto è come operare a scatola chiusa — funziona, finché non funziona.
Un DBA certificato con esperienza reale su recovery critici non segue un tutorial: costruisce una diagnosi, valuta le opzioni in base al danno effettivo, e decide cosa sacrificare e cosa salvare — perché in certe situazioni, salvare tutto non è un’opzione, e bisogna scegliere in fretta cosa è davvero irrinunciabile.
Cosa facciamo, concretamente
La nostra divisione Oracle & DB Engineering lavora esattamente su questo tipo di emergenze: amministrazione, tuning, backup e migrazioni cloud, con DBA certificati disponibili on-site o in outsourcing. Non arriviamo con un manuale generico — arriviamo con una checklist di diagnosi già pronta e la capacità di attivare un intervento in presenza entro 48 ore in tutta Italia, o in remoto in tempi ancora più stretti quando la situazione lo richiede.
Se il tuo database Oracle è corrotto in questo momento: fermati prima di riavviare. Isola l’istanza. Congela lo stato. Poi chiamaci — la finestra in cui i dati sono ancora recuperabili è più stretta di quanto pensi, ma esiste, e va usata bene, non in fretta e male.
