This document gives you some general information about Oracle Block Corruptions.
Typical error messages that helps to recognize Block Corruption
- ORA-00600 
- ORA-00600 [kdsgrp1]
What causes Block Corruption?
Block Corruptions likely happen and caused by at a level below database, hardware, operating system, firmware, and so on.
In rare cases Oracle bugs may cause corruptions. Since Restore/Recovery can generally not repair this type of corruption, SAP releases a Hot News note for this to notify our Customers.
Under certain conditions, Oracle may indicate that blocks of objects are corrupt during a recovery process since changes to these objects were not written to the online redo log. This may occur, for example, in a BW system when you create indexes with the 'nologging' option. Please note 'NOLOGGING' corruption is not critical as long as it is happening in index blocks!
- Contact the certified hadrware vendor the company is in contact to analyze possible problems and bottlenecks on their level. This can not be done by SAP Porduct Support! The hardware has to be fully functional before actually trying to solve the block corruption. If the hardware elements were not verified as fully functional and error free, Block Corruption likely will happen again!
- Validate available backups with Oracle Recovery Manager (RMAN). This is possible without any problems even if the backups were not created with RMAN and the backup option '-w only_rmw'.
- To enable the better recognition of block corruptions, you must ensure that the database parameter db_block_checksum (as of Oracle 11g) is set to TRUE or TYPICAL (see SAP Note 923919).
- Use BR*TOOLS for all consistency checks (brconnect, brbackup) and invaestigate the whole database for corrupted blocks. If possible, you should avoid a manual execution of the checks.
- If you find a corruption, check THOROUGHLY to determine which step you have to carry out next in order to correct the corruption (see SAP Note 365481).
- Unless expressly recommended by SAP Oracle Support, do NOT simply RECOVER the database. In many cases, superfluous reload or recovery actions can result in serious problems and data losses.
- If no backup is available and you have a valid PE agreement ("MaxAttention","ActiveEmbedded", or "MaxAttention Generation"), contact your TQM to start the expertise on demand service.
Tools for Analyzing and Repairing the Corruption
- BR*Tools ( to execute Oracle Tools in a guided way)
- Oracle Data Pump (expdp/impdp)
- Oracle Recovery Manager (RMAN)
- Oracle DB Verify (DBV)
- ANALYZE Command (ANALYZE Table .... validate structure cascade;)
Comparison of Consistency Check Methods
- X - check is executed
- Y - partly via checksum
- green color - check performed
- yellow color - check performed partly
- red color - check is not performed
|ANALYZE Command||DB Verify||Recovery Manager||Data Pump|
|Checks LOB segments||X||X|
|Checks Oracle Blocks||X||X|
|Checks Oracle Data Files||X||X|
|Checks Oracle Redo Logs||X|
|Checks Control File||X|
|Checks Oracle Parameter File||X|
|Checks Oracle Wallet File||X|
|Checks RMAN Backup File||X|
|Stops segment analysis at the first corrupted block found||X||X|
|Possible without having an DB||X||X|
Information to Collect
- Oracle Alert Log
- Trace File
- Name of corrupted objects
- Precise location of the corrupted data
Navigating to other Chapters