Corrupted Oracle database (ORA-01578): what to do first, and why not to restart

When an Oracle database reports corrupt blocks, for example with the ORA-01578 error, restarting it should not be your first move. Stop the jobs that write data, keep the error messages and secure the current state. Then measure the damage with Oracle’s own tools, such as RMAN VALIDATE and DBVERIFY. Only then do you choose the remedy. For a handful of damaged blocks, Oracle provides block media recovery, which repairs individual blocks while the database stays open, as long as full backups and the archived logs exist.

A typical scenario. The overnight batch run of the company’s ERP system has stalled, and by morning the problem is on the table. ORA-01578 appears several times in the logs. Someone proposes the most instinctive fix, which is to restart the database and see whether the problem goes away. It does not. And if the fault lies in the disks, or affects essential files, a restart can turn a few unreadable tables into an ERP system that will not start again.

What does the ORA-01578 error mean?

Oracle stores data in blocks, the smallest units it reads from and writes to disk. The ORA-01578 error says that a data block is corrupt, and it gives the numbers of the file and the block involved. In practice, the contents of that block fail the database’s integrity checks.

The most common causes lie outside the database. They include failing disks or controllers, faulty firmware, power cuts during a write and errors in the storage layer. Less often, the cause is a software defect.

Do not confuse it with ORA-00600. That is a generic internal error. It can accompany corruption, but it can have many other causes. You analyse it with the diagnostic files and, if you have an active support contract, with Oracle Support.

Why is restarting not the first move?

A restart does not repair a damaged block. In the best case the database comes back up, and the error returns the first time that block is read. In the other cases, things get worse:

• if the fault lies in the disks, the database keeps reading from and writing to a medium that is deteriorating, and the damage can spread
• if the damage affects essential components, such as the database’s SYSTEM tablespace or the control files, the instance may never open again
• if restarts are repeated, the logs fill up with messages and it becomes harder to reconstruct the sequence of events, that is, to work out what broke first.

A restart may be necessary at some point. But it is a decision for whoever administers the database, to be taken after the current state has been secured.

Physical or logical corruption: what difference does it make?

Physical corruption concerns the block itself. Its structure or checksum does not add up, and the database cannot read it. This is the kind that produces ORA-01578.

Logical corruption is more insidious. The block can be read, but its contents are inconsistent. Think of an index that points to rows that do not exist, or data that breaks the table’s rules. The database can keep working for a long time before anyone notices.

The distinction matters because the remedies are different. To look for logical corruption as well, RMAN must be run with the CHECK LOGICAL option. By default it checks only for physical corruption.

What are the steps in the first hours?

1. Stop whatever is writing. Suspend scheduled jobs and integrations that change data, in agreement with the people who know the application. Let users know.
2. Preserve the evidence. Set aside the database’s alert log, the diagnostic files, the list of reported blocks and the times. Note who does what, and when.
3. Secure the current state. Take a copy before any attempt at repair. Use RMAN if the database allows it, or take a snapshot at storage level, in agreement with whoever manages the disks. An RMAN backup stops at the first corrupt block unless you use SET MAXCORRUPT to say how many damaged blocks to tolerate. Decide that value with the DBA. A cold backup is not suitable here. It requires shutting the database down, which is exactly what you want to avoid at this stage.
4. Measure the damage. The RMAN VALIDATE command checks the files and records the corrupt blocks in the V$DATABASE_BLOCK_CORRUPTION view. DBVERIFY checks the structure of individual files, including image copies made with RMAN, but not backup sets. Neither tool changes the data.
5. Look for the cause. Check the operating system and storage logs, the state of the disks and any recent work on the systems. If you repair without removing the cause, you will end up with the same problem again.
6. Choose the remedy on the basis of what the measurement showed, using the table below.
7. Verify and record everything. Check the files again after the repair, run application checks and write a report with the sequence of events.

Which remedy for which damage?

The last row is not a technical choice. It is a decision for management, to be taken with the figures in front of them.

What does management decide in those hours?

While the technical team works, the people running the company must answer questions that no manual can settle.

• How long can we stay down? This is the RTO (Recovery Time Objective), the maximum downtime the business can bear. If it is written down and tested, decisions come faster.
• How much data can we afford to lose? This is the RPO (Recovery Point Objective). It measures, in time, how much work can be redone or accepted as lost.
• Restart quickly, or restart with all the data? Sometimes the service can reopen without part of the data, which is recovered later. Sometimes it is better to wait.
• Who needs to be told? Think of customers, suppliers and the insurer. If the corruption has made personal data unavailable or caused it to be lost, the controller assesses whether the event must be reported to the supervisory authority as a personal data breach. The assessment is made with the data protection officer, if one has been appointed. The deadline is 72 hours from becoming aware of the breach (GDPR, Article 33). Companies subject to NIS2, the EU directive on network and information security, also check their incident notification obligations.

How do you stop it happening again?

• ARCHIVELOG mode and full backups, checked with RMAN VALIDATE on a set schedule. They are the precondition for block media recovery.
• Restore tests, with the times put on record.
• Active integrity checks. The DB_BLOCK_CHECKSUM, DB_BLOCK_CHECKING and DB_LOST_WRITE_PROTECT parameters help catch damaged blocks. They carry a performance cost that has to be weighed case by case.
• A standby database where your edition allows it, so that you always have an up-to-date copy to restart from.
• Watching the storage layer. Disk and controller warnings must be read before they turn into database errors.

If you are planning a platform change, this is a good place to start. The same verified backups also serve for a migration with minimal downtime. And a version still covered by patches reduces known defects, as we explained for Oracle databases out of support.

In brief

• Faced with ORA-01578, do not restart first. Stop whatever is writing, preserve the evidence and secure the current state.
• RMAN VALIDATE and DBVERIFY measure the damage without changing the data.
• For a few physically damaged blocks there is block media recovery, with the database open, provided you have full backups and archived logs.
• Flashback is for logical errors. It does not repair physical corruption.
• Look for the cause, often in the storage layer, before you declare the incident closed.
• Management decides on downtime, on which data can be sacrificed and on communications, including to the authority if personal data is involved.

Frequently asked questions

Can a corrupt block be repaired without shutting the database down?

Often, yes. Block media recovery with RMAN keeps the affected files online. Only the blocks being repaired are unavailable. You do need ARCHIVELOG mode, full or level 0 backups and the archived logs for the period.

Does Flashback Database repair corruption?

No. Flashback Database takes the whole database back to an earlier point in time. It is meant for logical errors, such as data deleted by mistake. Oracle’s documentation makes clear that it remedies logical failures, not physical ones such as disk failures. For physically damaged blocks you use backups and logs with RMAN.

Does ORA-00600 mean the database is corrupt?

Not necessarily. ORA-00600 is a generic internal error with many possible causes. It can appear together with corruption, but it must be analysed with the diagnostic files before you draw any conclusions.

Do we need Oracle Support?

If you have an active support contract, open a service request straight away and attach the logs and diagnostic files. The vendor’s support works alongside your database administrator, who remains responsible for the choices made on the company’s environment.

Repairing damaged databases, and the prevention that makes such repairs rarer, is part of the work of our Oracle & Database Engineering division. That means verified backups, restore tests and integrity checks. The essential rules for the first hours are also summarised in the box Database down or data damaged. The contact form is not an emergency channel. During an incident, use the contacts written in your own plan.

Sources

Consulted on 16 September 2026.

• Oracle, ORA-01578: ORACLE data block corrupted
• Oracle, ORA-00600: internal error code
• Oracle, Backup and Recovery User’s Guide 19c, “Performing Block Media Recovery”
• Oracle, Backup and Recovery User’s Guide 19c, “Validating Database Files and Backups”
• Oracle, Database Utilities 19c, “DBVERIFY: Offline Database Verification Utility”
• Oracle, Backup and Recovery Reference 19c, FLASHBACK DATABASE
• Oracle, Database Licensing Information User Manual 19c, automatic block repair
• Oracle, Database Reference 19c, DB_BLOCK_CHECKING
• Oracle, PL/SQL Packages and Types Reference 19c, DBMS_REPAIR
• Regulation (EU) 2016/679 (GDPR), Article 33, EUR-Lex