This action might not be possible to undo. Are you sure you want to continue?
Version: 55 Validity:
Valid Since 06.10.2010
You have a corrupt block and want to clean it up. Oracle error messages that indicate a corrupt block are listed in the following. An ORA-08103 or ORA-01410 does not necessarily indicate a corruption for the reasons mentioned in Note 1144558. ORA-01410: Invalid ROWID ORA-01498: Block check failure - see trace file ORA-01499: Table/index cross reference failure - see trace file ORA-01578: ORACLE data block corrupted ORA-08102: Index key not found ORA-08103: Object no longer exists ORA-00600 [x]: This error message states that a few arguments indicate corruptions, for example ORA-00600 , ORA-00600 , ORA-00600 , ... . In general Ora-00600 does not indicate corruption. However, you must determine the cause of Ora-00600.
ora-1578, ora-1499, ora-1498, corruption, corrupt block  
Reason and Prerequisites
It is very likely that the corruption is caused by problems at a level below that of the 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, we have released a Hot News note for this. 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. The following are clear indications of blocks deliberately marked as software-corrupt: After a recovery (1), a large number (2) of corrupt blocks occur in a relatively small number (3) of indexes (4). The system displays the corrupt blocks consecutively in sequences (5) (for example, blocks 5,6,7,8,9,10,11, and 127,128,129,130, and 1120,1121,1122 are reported as corrupt). A DBV reports DBV-00201 for these types of blocks. You cannot correct this type of corruption using the restore and recovery function, as the corruption actually occurred during a recovery operation. The only solution here is to recreate the indexes. For more details, see Note 547464.
In addition to the procedures for cleaning up a corrupt block described below, you should ALWAYS: o See FAQ Note 540463 for further information about consistency checks and block corruptions. This note is essential to help you
Page 1 of 11
relative file numbers and file names using the following statement: select file#. the system does not record a table name anywhere if a corrupt block is identified during running operation. for example: Corrupt block relative dba: 0x24400b33 (file 145. Although these are often the same. Identify the object that belongs to this corrupt block Depending on the consistency check procedures. Check your ENTIRE database according to Note 23345. always ensure that the initial status can be restored (for example. In addition.12.2011 . this is not necessarily always the case. blocks from dba_extents where (<corrupted block> between block_id and (block_id + blocks .always rename the indexes of corrupt tables. block 2867) For all selects on dba_extents. Log EXACTLY which actions were carried out and in which sequence. rfile#. 'file number' refers to the absolute file number in all cases below. Check your ENTIRE database according to Note 23345. The relative file number is also indicated in dbv messages that refer to a relative dba (database block address). Unless otherwise indicated. o Check your hardware (or have it checked) because defective hardware is the cause for corruption in most cases. Within the context of this note. do not drop them).1)) Page 2 of 11 27. block_id. Under unfavorable circumstances. the database user is referred to as SAPR3. Oracle distinguishes between relative and absolute file numbers. always copy the files you want to replace beforehand . SAPSR3 and so on. if there is a non-corrupt back-up. when you dump blocks or during brrestore of individual files. It is possible to map between absolute file numbers. you will receive the object (table or index) name directly or simply the number of the corrupt block and the name of the data file that contains the corrupt block. v$datafile. you must always specify the absolute file number. relative file numbers only play a role in the specification of rowids (see below). For all steps that you execute. Replace this name as appropriate to your situation with SAP<SID>. name from v$datafile. this note describes the option to recover corrupt blocks with almost zero downtime. => file number of the file that contains the corrupt block o select segment_name. 1. o o o In the following section.SAP Note 365481 - Block corruptions understand the activities described in the following. segment_type. execute the following SQL queries in sqlplus or servermanager: o select file# from v$datafile where name = '<Filename>'. partition_name. If you have only file names and block numbers (=page numbers).
'ONLINE') and vd. s. it is a question of: a corrupt block that does not belong to any object (this is probably the case). These types of blocks are only identified by the DB Verify.file_id and dd. the system reformats it and then no longer reports it as being corrupt. Be aware that the copy requires a considerable amount of memory. The procedure is described in detail in Note 354293. You can ignore these blocks or preferably delete them using one of the following methods: a) Use brspace to reorganize the tablespaces in question (including data files) OR b) Create a dummy object (dummy table) that uses this block.partition_name. fill this dummy object and then delete it.12.segment_type. 2.SAP Note 365481 - Block corruptions and file_id = <Filenummer from the first statement> and rownum < 2. block_id.tablespace_name and vd. s. and to execute the statement on the copy. a block that belongs to an object that is located in a LMTS.status not in ('SYSTEM'.2011 Page 3 of 11 .tablespace_name = s. If Oracle wants to use this block for an object. s. Is it an object of type Cache? 27.file# = dd.segment_name. execute the following statement: select s. => Object name. object type If this SELECT needs to be executed for several blocks.tablespace_name = t. it may be worth while to copy the dba_extents completely using 'create table as select'.header_file.extent_management = 'LOCAL' and t.header_file from dba_tablespaces t.file# = s. create an index for file_id.tablespace_name and t. To get an overview of all of the objects that are not displayed in dba_extents. s. the header block of which is in a data file that is currently set offline (this is rarely the case). If this query does not return any object. dba_data_files dd. v$datafile vd where vd.header_block. and that you should delete it immediately after the queries in order to avoid the risk of reading obsolete data in future SELECT statements. dba_segments s.
attach the trace file created by the following command in the saptrace/usertrace: alter system dump datafile <file_id> block min <lowest block_id> block max <highest block_id>. In addition. Development Support will repair the underlying dictionary inconsistency. 4. Does the database object belong to the SYS database user or is it located in the SYSAUX tablespace? General rule: The object only belongs to the SYS user if it is in the system tablespace. If you have no such backup.12. Is it an undosegment (you use new Undo Management as of Oracle 9)? If yes: Check whether all the following conditions have been met: o the DB can be stopped with 'shutdown normal' or 'shutdown immediate' there are no entries written during stopping/starting in the alert log that are connected to the undo corruption o 27. If the procedures described are not successful. which make it impossible to proceed (Note 53716 may also be helpful). To eliminate THIS TYPE of corruption. attach the output of the following command: select owner. relative_fno. 5. Since it selects data from the dictionary. blocks from dba_segments where segment_type = 'CACHE'. the system may return corruption messages when you follow this procedure. To your message. Recover this file up to the current time. If yes: Save the corrupt data file and transfer a backup of this file from a backup that does not contain the corruption. your consistency check/backup concept is inadequate. From now on. 3. header_file. segment_name. but it is inconvenient. contact SAP Support for more help. dbverify identifies blocks of this object as being corrupt.SAP Note 365481 - Block corruptions A cache object may become corrupt if the database was upgraded to Oracle 9 and installed on Oracle 6. referring to this note. header_block.2011 Page 4 of 11 . See Note 1116190 for information. open a message on the BC-DB-ORA component and send it directly to Oracle Development Support. This is not critical. Is it a rollback segment of the SAPR3 user? If yes: Proceed according to Note 4190. The approach described in Note 748434 may be of further help.
For information about rebuild online. You can recognize unique indexes if the following select returns a 'UNIQUE' (otherwise 'NONUNIQUE'): select INDEX_NAME. Even if the index tablespace is set to offline. Otherwise. However. see Note 682926.12.SAP Note 365481 - Block corruptions o o v$fast_start_transaction is empty after each restart of the DB no rollback segment-specific underscore parameters were used => The corruption is either in the free space of the undo table or in an area of the undo segment that is no longer required for a rollback of an open transaction. 6. 7. Is it a user sapr3 table? If yes: If you have not done so already. provided that you do not have additional table corruptions. If all the prerequisites have been met. an index reorganization is considerably faster than a restore/recovery unless you QUICKLY have a CHECKED backup available as well as ALL archive logs that have arisen since you created the backup and only a few changes were carried out in the tablespace in question that must be traced. Is it a user SAPR3 index? If yes: You can correct index corruption by reorganization (delete/recreate or "rebuild online" of the index) using brspace or by restoring/recovering the corrupt file. In most cases. select the index reorganization. they may lead to terminations of the application if you try to use the corrupt index. use dbverify to analyze all the 27. UNIQUENESS from dba_indexes where index_name = '<OBJECTNAME>'. whereas the "rebuild online" reads the table. Delete/recreate for a unique index must be carried out when the database is closed. there is a risk of duplicate keys.2011 Page 5 of 11 . rebuild online has the advantage over delete/recreate that you can continue to use the system. Especially for unique indexes. open a problem message. you can use rebuild online. A "rebuild" WITHOUT the "online" option does not work because the "rebuild" tries to read the index. Otherwise. If you are not sure which method is better for you. the undo tablespace can be dropped and created again. Index corruptions are not critical regarding data loss because you can always set up indexes again.
the table is locked against changes. The corruption should then appear in the free space and should therefore be deleted as described there. for example if your WP update hangs with an update on the table.afd -m 59=c:\temp d) dbverify without errors/analyze with errors This case differs from the previous case in that dbverify does not 27. AND if none of the procedures described in Note 23345 reports a problem. Certain corruptions can be exported and errors only occur during the import process (IMP-00020). If this is successful this time AND if you can read the table using a select * from sapr3. in tables with LOB columns. c) dbverify with errors/analyze with errors Save the corrupt data file and transfer a backup of this file from a backup that does not contain the corruption. Note 786645 contains additional reasons for temporary corruption. The analysis is not capable of recognizing this type of corruption. dbverify can recognize the corruption and. your backup does not have any corruptions. you have subsequently verified your backup because.12. Repeat the access that indicated the corruption. Furthermore. on the one hand.2011 Page 6 of 11 . you can carry out an 'analyze table validate structure cascade online' that no longer blocks the table. on the other. proceed as described under "dbverify with errors/analyze with errors". Note: During this time. it is very likely that a temporary corruption existed in the memory but not on the hard disk. the corruption may be located in the lob segment. To import a file back into another directory using brrestore. b) dbverify with errors/analyze without errors The corruption is probably located in a block of the table that has never contained data. The block (which was only corrupt in the main memory) was not reimported to the hard disk because it was not changed. Analyze the table (if you have not done this already) using 'analyze table validate structure cascade'.SAP Note 365481 - Block corruptions tablespace files that contain the table. you can restore a file from a backup that is still available in A DIRECTORY THAT DOES NOT BELONG TO THE DB and check this backup using dbv. If a corruption is not reported. Execute the following command: alter table <tablename> deallocate unused. Always check your hardware in this case. If you do not have a backup that you can definitely say does not contain the corruption. terminate the Analyze. As of Oracle 9. In this case. a) dbverify without errors/analyze without errors You probably do not have a corruption. If necessary."<TABLE>". Do not try to reorganize the table after a successful export. use the following command: Abstract: brrestore -b <log> -m <number of file>=<Restore Directory> For example: brrestore -b bddcbjcq. to check whether the table still has more corrupt blocks. Recover this file up to the current time.
After you have made a backup of the corrupt file. If a 'NUMBER' is contained instead of 'CHAR'."RESB". If you do not have a backup that you can definitely say does not contain the corruption. If all the backups contain the corruption. you must ALWAYS change <column1> >= ' ' or <column1> < ' ' to <column1> >= 0 or <column1> < 0 Even if the condition appears meaningless. in retrospect you have verified your backup and you can restore and recover this. For example: Table RESB is corrupt select /*+ INDEX("RESB" "RESB~0") */ count(*) 27. Abstract: describe sapr3. Null? -------NOT NULL NOT NULL Type ---VARCHAR2(3) VARCHAR2(10) All of the following restrictions of the type <column1> >= ' ' or <column1> < ' ' in the WHERE conditions require that the 'CHAR' string must be contained in the 'Type' column in the FIRST row.2011 Page 7 of 11 .. you can reimport and recover the backup of the file without checking it and hope that the corruption was not yet contained in the backup OR you can create a temporary check system using a (partial) DB copy from this backup (consisting of the rollback. Create a message and provide the following information: Information 1) Determine the total number of table records using the primary index. This is almost always a character field. => Column Name -----------------------------MANDT RSNUM ."<TABLE>". your consistency check/backup concept is inadequate..12.also in the example. The hint alone is not sufficient. To do this. it forces Oracle to make a primary index access. This is almost always the case ."<TABLE>" where <column1> >= ' ' or <column1> < ' '. you can check this easily at a later stage. system and tablespace that contains the corruption) and analyze the table on this check system. Now count the entries: Abstract: select /*+ INDEX("<TABLE>" "<TABLE>~0") */ count(*) from sapr3. If this is possible without errors.SAP Note 365481 - Block corruptions recognize an existing corruption that an analysis finds. For example: describe sapr3. first determine the data type of the first primary index column (called <column1> in the following).
1) like '<rowid>' and <column1> >= ' ' or <column1> < ' '.rowid_block_number(rowid) = <corrupted block> and dbms_rowid. block. Include the call and command output of the commands in your message (Information 2) Information 3) . For example: The file that contains the corrupt block has the relative file number 59 (hex: 003B). Include the call and command output of the commands in your message (Information 1) Information 2) Determine the primary keys of the data records in the FIRST corrupt block of the table by using the following statement: Abstract: select /*+ INDEX("<TABLE>" "<TABLE>~0") */ <keyfields of TABLE> from "<TABLE>" where dbms_rowid. Pay attention to upper and lower case for the terms in quotation marks.RSNUM.'SAPR3'."RESB" a where mandt >= ' ' or mandt < ' '.'<TABLE>') = <file# of the corrupted block> and <column1> >= ' ' or <column1> < ' '.file OR the file that contains the corrupt block has the absolute file number 59 (hex: 003B).RSPOS.SAP Note 365481 - Block corruptions from sapr3.'RESB') = 59 and mandt >= ' ' or mandt < ' '.rowid_block_number(rowid) = 118882 and dbms_rowid. select /*+ INDEX("RESB" "RESB~0") */ MANDT. and the table containing this block (determined in accordance with 1)) is RESB.row.'SAPR3'.RSNUM.RSPOS.rowid_to_absolute_fno(rowid. select /*+ INDEX("RESB" "RESB~0") */ MANDT.003B' and mandt >= ' ' or mandt < ' '.RSART from "RESB" where dbms_rowid. OR select /*+ INDEX("<TABLE>" "<TABLE>~0") */ <keyfields of table> from "<TABLE>" where dbms_rowid.rowid_to_absolute_fno(rowid.RSART from "RESB" where dbms_rowid. the corrupt block has number 118882 (hex: 0001D062).on request only Dump the corrupt block using: Abstract: Alter system dump datafile <file# of the corrupted block> block 27. the corrupt block has number 118882 (hex: 0001D062) Table that contains this block (determined in accordance with 1)) is RESB.rowid_to_restricted(rowid.1) like '0001D062.12. Both commands must return the same results.%.rowid_to_restricted(rowid.2011 Page 8 of 11 .
although you can delete the DB corruptions. you can discover whether other corrupt blocks still exist in a table. D010LINF D020L.SAP Note 365481 <corrupted block>. USGRP. know). The following is a list of tables that can probably be restored from the application support (secondary index tables): BSAD. These corrupt blocks are skipped and logged in the saptrace/usertrace directory. SAP Support will now clarify to what extent this is redundant data or how you can read corrupt blocks. Since these parameters may result in very serious inconsistencies in the database. only use the parameter in the session that you use for analysis. As part of remote consulting. CROSS. all tables of the relevant row must nevertheless be emptied for consistency reasons): D010L. Block corruptions For example: Alter system dump datafile 59 block 118882. you can activate the parameters for the entire database and reorganize the table. By setting certain parameters in init<SID>. they are only issued by request or if the tables that contain corruptions are specified. After you have completed the analysis. application inconsistencies will occur as a result.12. you can force Oracle to read corruptions. It is ESSENTIAL that they are removed again before you include the production operation again after you have reorganized the table. BSIK. D342L DDFTX D344L REPOLOAD DYNPTXTLD. Save the relevant file in the $SAPDATA_HOME/saptrace/usertrace directory and set it on sapserv3 as described in Note 40024. BSAK. BSIX. D010Q. BSIM. After this type of action. DYNPLOAD DDLOG 27. You can then analyze these as described under Information 2) and Information 3). It is YOUR responsibility whether to use the parameters or not. BSID. WBCROSSGT Fully indexed tables (all columns of the table appear in the primary index): SCPARTICIP. BSAS. For the time being. Under no circumstances try to clean up the corruptions in SAP tables yourself by reading the corrupt blocks because only SAP knows the dependencies between the tables. You can execute these steps during productive operation. D010Y. the remote consulting can try to restore the lost data or return dependent tables to a consistent status again (this does not apply to customer tables whose query dependencies only you. WBCROSSI Tables that can be created empty and are filled automatically when the system is stopped (if only one of the tables is affected. this represents a partial loss of data that cannot be avoided. Otherwise. BSIW. BSIS. Consequently. D021L.ora. If you already know the parameter. the customer.2011 Page 9 of 11 . D021LINF D346T. D020LINF. In this case. NEVER use it without prior consultation with SAP. provided that the corruption is not so serious that you cannot work productively anyway.
10. dba <address>.2011 Page 10 of 11 . marked corrupt for invalid ORA-08103 or ORA-01410 in connection with DROPs Handling of database corruptions by the SAP Support Segment corruption in ASSM tablespace ORA-00200: Block. dba <address>.2010 11:57:31 German Recommendations/additional info Consulting BC-DB-ORA Oracle The Note is release-independent Related Notes Number 1395074 1144558 1116190 764015 724972 605062 591600 546006 540463 434645 354293 96296 31496 23345 4190 4161 Short Text ORA-00201: Block.12.SAP Note 365481 - Block corruptions Header Data Release Status: Released on: Master Language: Priority: Category: Primary Component: Released for Customer 06. already marked corrupted FAQ: Restore and recovery Error due to inappropriate column values Problems with Oracle due to operating system errors FAQ: Consistency Checks + Block Corruptions Point-in-time recovery: What must I be aware of? DBVerify reports corrupt block in freespace area CC-ERROR: Database problem in client copy CC-INFO: Client deleted by mistake Consistency check of ORACLE database Recovery for defective rollback segments Complete recovery Attributes 27.
12.SAP Note 365481 Attribute Database system Block corruptions Value ORACLE 27.2011 Page 11 of 11 .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.