DBADati e Oracle

Database Oracle corrotto (ORA-01578): cosa fare subito e perché non riavviare

Blocchi danneggiati ed errore ORA-01578: fermare ciò che scrive, conservare i messaggi, misurare il danno con gli strumenti di Oracle e solo dopo scegliere il rimedio. La sequenza delle prime ore.

Redazione Strategic 4 agosto 2026 Aggiornato il 16 settembre 2026 7 min di lettura

Database Oracle corrotto (ORA-01578): cosa fare subito e perché non riavviare

Quando un database Oracle segnala blocchi corrotti, per esempio con l’errore ORA-01578, la prima cosa da fare non è riavviare. Si fermano le elaborazioni che scrivono dati, si conservano i messaggi di errore e si mette al sicuro lo stato attuale. Poi si misura il danno con gli strumenti di Oracle, come RMAN VALIDATE e DBVERIFY, e solo allora si sceglie il rimedio. Per pochi blocchi danneggiati Oracle prevede il recupero dei singoli blocchi a database aperto, se esistono copie complete e l’archivio dei log.

Scenario tipico. Sono le tre del mattino e l’elaborazione notturna del gestionale si blocca. Nei registri compare più volte ORA-01578. Qualcuno propone la soluzione più istintiva: riavviare il database e vedere se il problema sparisce. Non sparisce. E se il guasto è nei dischi, o se tocca file essenziali, il riavvio può trasformare alcune tabelle illeggibili in un gestionale che non riparte.

Che cosa significa l’errore ORA-01578?

Oracle conserva i dati in blocchi, le unità minime di lettura e scrittura su disco. L’errore ORA-01578 dice che un blocco di dati è corrotto e indica il numero del file e del blocco coinvolti. In pratica, il contenuto di quel blocco non supera i controlli di integrità del database.

Le cause più frequenti sono fuori dal database: dischi o controller che si guastano, firmware difettoso, interruzioni di corrente durante una scrittura, errori nello strato di archiviazione. Più raramente si tratta di un difetto del software.

Da non confondere con ORA-00600. Quello è un errore interno generico: può accompagnare una corruzione, ma può avere molte altre cause, e si analizza con i file di diagnostica e, se c’è un contratto di assistenza attivo, con il supporto di Oracle.

Perché riavviare non è la prima mossa?

Un riavvio non ripara un blocco danneggiato. Nel migliore dei casi il database riparte e l’errore si ripresenta alla prima lettura di quel blocco. Negli altri casi le conseguenze peggiorano:

se il guasto è nei dischi, il database continua a leggere e scrivere su un supporto che si sta deteriorando, e il danno può estendersi;
se il danno tocca parti essenziali, come lo spazio di sistema del database o i file di controllo, l’istanza può non riaprirsi più;
se i riavvii si ripetono, i registri si riempiono di messaggi e diventa più difficile ricostruire la sequenza, cioè capire che cosa si è rotto per primo.

Un riavvio può essere necessario, a un certo punto. Ma è una decisione di chi amministra il database, da prendere dopo aver messo al sicuro lo stato attuale.

Corruzione fisica o logica: che differenza fa?

La corruzione fisica riguarda il blocco in sé: la struttura o il codice di controllo non tornano, e il database non riesce a leggerlo. È quella che produce l’ORA-01578.

La corruzione logica è più subdola: il blocco si legge, ma il contenuto è incoerente. Un indice che punta a righe che non esistono, dati che violano le regole della tabella. Il database può funzionare a lungo prima che qualcuno se ne accorga.

La distinzione conta perché i rimedi sono diversi. Per cercare anche la corruzione logica, RMAN va lanciato con l’opzione CHECK LOGICAL: di norma controlla solo quella fisica.

Quali sono i passi delle prime ore?

Fermare ciò che scrive. Si sospendono elaborazioni pianificate e integrazioni che modificano dati, d’accordo con chi conosce l’applicazione. Gli utenti vengono avvisati.
Conservare le prove. Si mettono da parte il registro degli avvisi del database (alert log), i file di diagnostica, l’elenco dei blocchi segnalati, gli orari. Si annota chi fa che cosa, e quando.
Mettere al sicuro lo stato attuale. Si fa una copia prima di ogni tentativo: con RMAN, se il database lo consente, oppure a livello di archiviazione (snapshot), d’accordo con chi gestisce i dischi. Una copia «a freddo» qui non è adatta: richiede di spegnere il database, cioè proprio ciò che si vuole evitare in questa fase.
Misurare il danno. Il comando RMAN VALIDATE controlla i file e registra i blocchi corrotti nella vista V$DATABASE_BLOCK_CORRUPTION. DBVERIFY controlla la struttura dei singoli file, anche delle copie. Nessuno dei due modifica i dati.
Cercare la causa. Registri del sistema operativo e dell’archiviazione, stato dei dischi, interventi recenti. Riparare senza togliere la causa significa ritrovarsi con lo stesso problema.
Scegliere il rimedio in base a ciò che la misura ha mostrato, con la tabella qui sotto.
Verificare e mettere a verbale. Nuovo controllo dei file dopo l’intervento, verifiche applicative, relazione con la sequenza dei fatti.

Quale rimedio per quale danno?

Situazione	Rimedio tipico	Condizioni
Pochi blocchi fisici danneggiati	recupero dei singoli blocchi con RMAN (`RECOVER ... BLOCK` o `RECOVER CORRUPTION LIST`), con i file in linea	database in modalità ARCHIVELOG, copie complete o di livello 0, log archiviati disponibili
Database di riserva con Active Data Guard	riparazione automatica dei blocchi dalla copia di riserva	licenza Active Data Guard
Un file danneggiato per intero	ripristino e recupero del file con RMAN	copie e log disponibili
Blocchi danneggiati solo in un indice	si ricrea l’indice	i dati della tabella sono integri
Dati cancellati o modificati per errore	tecnologie Flashback, per esempio Flashback Database	attive prima dell’errore; non riparano la corruzione fisica né i guasti dei dischi
Nessuna copia utilizzabile	si recuperano i dati leggibili e si ricostruisce, escludendo i blocchi persi (per esempio con DBMS_REPAIR)	i dati di quei blocchi vanno ricostruiti da altre fonti o accettati come persi

L’ultima riga non è una scelta tecnica: è una decisione della direzione, da prendere con i numeri davanti.

Che cosa decide la direzione in quelle ore?

Mentre i tecnici lavorano, chi guida l’azienda deve rispondere a domande che nessun manuale risolve.

Quanto possiamo restare fermi? È l’RTO (Recovery Time Objective), il tempo massimo di fermo sopportabile. Se è scritto e provato, le scelte sono più rapide.
Quanti dati possiamo perdere? È l’RPO (Recovery Point Objective): quanto lavoro, misurato in tempo, si può rifare o accettare come perso.
Ripartire subito o ripartire completi? A volte si può riaprire il servizio escludendo una parte dei dati e recuperarla dopo. A volte conviene aspettare.
Chi va informato? Clienti, fornitori, assicurazione. Se la corruzione ha reso indisponibili o ha fatto perdere dati personali, il titolare valuta, con il responsabile della protezione dei dati se è stato nominato, se l’evento va comunicato all’autorità di controllo come violazione dei dati personali: il termine è di 72 ore da quando se ne viene a conoscenza (GDPR, art. 33). Le aziende soggette alla NIS2 verificano anche gli obblighi di notifica degli incidenti.

Come si evita che succeda di nuovo?

Modalità ARCHIVELOG e copie complete, verificate con RMAN VALIDATE a calendario: sono la condizione per il recupero dei singoli blocchi.
Prove di ripristino con i tempi messi a verbale.
Controlli di integrità attivi: i parametri DB_BLOCK_CHECKSUM, DB_BLOCK_CHECKING e DB_LOST_WRITE_PROTECT aiutano a intercettare i blocchi danneggiati, con un costo sulle prestazioni da valutare caso per caso.
Database di riserva dove l’edizione lo consente, per avere una copia sempre allineata da cui ripartire.
Sorveglianza dell’archiviazione: gli avvisi dei dischi e dei controller vanno letti prima che diventino errori del database.

Chi sta pianificando un cambio di piattaforma può partire da qui: le stesse copie verificate servono anche per una migrazione con fermi ridotti, e una versione ancora coperta dalle patch riduce i difetti noti, come spiegato per i database Oracle fuori supporto.

In sintesi

Davanti a un ORA-01578 non si riavvia per primo: si ferma ciò che scrive, si conservano le prove e si mette al sicuro lo stato.
RMAN VALIDATE e DBVERIFY misurano il danno senza modificare i dati.
Per pochi blocchi fisici c’è il recupero dei singoli blocchi, a database aperto, con copie complete e log archiviati.
Flashback serve per gli errori logici, non ripara la corruzione fisica.
Si cerca la causa, spesso nell’archiviazione, prima di dichiarare chiuso l’incidente.
La direzione decide su tempi di fermo, dati sacrificabili e comunicazioni, anche verso l’autorità se ci sono dati personali.

Domande frequenti

Si può riparare un blocco corrotto senza fermare il database?

Spesso sì. Il recupero dei singoli blocchi con RMAN lascia in linea i file coinvolti: restano indisponibili solo i blocchi in riparazione. Servono però la modalità ARCHIVELOG, copie complete o di livello 0 e i log archiviati del periodo.

Flashback Database ripara la corruzione?

No. Flashback Database riporta l’intero database a un momento precedente e serve contro gli errori logici, come dati cancellati per sbaglio. La documentazione di Oracle chiarisce che rimedia ai guasti logici, non a quelli fisici come i guasti dei dischi: per i blocchi fisicamente danneggiati si usano copie e log con RMAN.

L’errore ORA-00600 significa che il database è corrotto?

Non necessariamente. ORA-00600 è un errore interno generico con molte cause possibili. Può comparire insieme a una corruzione, ma va analizzato con i file di diagnostica prima di trarre conclusioni.

Serve il supporto di Oracle?

Con un contratto di assistenza attivo conviene aprire subito una richiesta, allegando registri e file di diagnostica. Il supporto del produttore affianca chi amministra il database, che resta responsabile delle scelte da fare sull’ambiente dell’azienda.

Le emergenze sui database fanno parte del lavoro della nostra divisione Oracle & Database Engineering, insieme alla prevenzione che le rende più rare: copie verificate, prove di ripristino, controlli di integrità. Le regole essenziali per le prime ore sono riassunte anche nel riquadro Database fermo o dati danneggiati.