Subject: DBMS_REPAIR example Content Type: TEXT/PLAIN Creation Date: 12-JAN-1999 PURPOSE This document provides an example of DBMS_REPAIR as introduced in Oracle 8i. Oracle provides different methods for detecting and correcting data block corruption - DBMS_REPAIR is one option. WARNING: Any corruption that involves the loss of data requires analysis to understand how that data fits into the overall database system. Depending on the nature of the repair, you may lose data and logical inconsistencies can be introduced; therefore you need to carefully weigh the gains and losses associated with using DBMS_REPAIR. SCOPE & APPLICATION This article is intended to assist an experienced DBA working with an Oracle Worldwide Support analyst only. This article does not contain general information regarding the DBMS_REPAIR package, rather it is designed to provide sample code that can be customized by the user (with the assistance of an Oracle support analyst) to address database corruption. The "Detecting and Repairing Data Block Corruption" Chapter of the Oracle8i Administrator's Guide should be read and risk assessment analyzed prior to proceeding. RELATED DOCUMENTS Oracle 8i Administrator's Guide, DBMS_REPAIR Chapter Introduction ============= Note: The DBMS_REPAIR package is used to work with corruption in the transaction layer and the data layer only (software corrupt blocks). Blocks with physical corruption (ex. fractured block) are marked as the block is read into the buffer cache and DBMS_REPAIR ignores all blocks marked corrupt.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Subject: DBMS_REPAIR example Content Type: TEXT/PLAIN Creation Date: 12-JAN-1999 PURPOSE This document provides an example of DBMS_REPAIR as introduced in Oracle 8i. Oracle provides different methods for detecting and correcting data block corruption - DBMS_REPAIR is one option.
WARNING: Any corruption that involves the loss of data requires analysis to understand how that data fits into the overall database system. Depending on the nature of the repair, you may lose data and logical inconsistencies can be introduced; therefore you need to carefully weigh the gains and losses associated with using DBMS_REPAIR.
SCOPE & APPLICATION This article is intended to assist an experienced DBA working with an Oracle Worldwide Support analyst only. This article does not contain general information regarding the DBMS_REPAIR package, rather it is designed to provide sample code that can be customized by the user (with the assistance of an Oracle support analyst) to address database corruption. The "Detecting and Repairing Data Block Corruption" Chapter of the Oracle8i Administrator's Guide should be read and risk assessment analyzed prior to proceeding.
RELATED DOCUMENTS Oracle 8i Administrator's Guide, DBMS_REPAIR Chapter
Introduction=============
Note: The DBMS_REPAIR package is used to work with corruption in thetransaction layer and the data layer only (software corrupt blocks).Blocks with physical corruption (ex. fractured block) are marked asthe block is read into the buffer cache and DBMS_REPAIR ignores allblocks marked corrupt.
The only block repair in the initial release of DBMS_REPAIR is to *** mark the block software corrupt ***.
DB_BLOCK_CHECKING and DB_BLOCK_CHECKSUM must both be set to FALSE.
A backup of the file(s) with corruption should be made before using package.
Database Summary===============
A corrupt block exists in table T1.
SQL> desc t1 Name Null? Type ----------------------------------------- -------- ---------------------------- COL1 NOT NULL NUMBER(38) COL2 CHAR(512)
SQL> analyze table t1 validate structure;analyze table t1 validate structure*ERROR at line 1:ORA-01498: block check failure - see trace file
---> Note: In the trace file produced from the ANALYZE, it can be determined--- that the corrupt block contains 3 rows of data (nrows = 3).--- The leading lines of the trace file follows:
CHECK_OBJECT procedure checks the specified object and populates the repairtable with information about corruption and repair directive(s). Validationconsists of block checking all blocks in the object. All blocks previouslymarked corrupt will be skipped.
Note: In the initial release of DBMS_REPAIR the only repair is to mark the block as software corrupt.
SQL> desc repair_table Name Null? Type ----------------------------------------- -------- ---------------------------- OBJECT_ID NOT NULL NUMBER TABLESPACE_ID NOT NULL NUMBER RELATIVE_FILE_ID NOT NULL NUMBER
BLOCK_ID NOT NULL NUMBER CORRUPT_TYPE NOT NULL NUMBER SCHEMA_NAME NOT NULL VARCHAR2(30) OBJECT_NAME NOT NULL VARCHAR2(30) BASEOBJECT_NAME VARCHAR2(30) PARTITION_NAME VARCHAR2(30) CORRUPT_DESCRIPTION VARCHAR2(2000) REPAIR_DESCRIPTION VARCHAR2(200) MARKED_CORRUPT NOT NULL VARCHAR2(10) CHECK_TIMESTAMP NOT NULL DATE FIX_TIMESTAMP DATE REFORMAT_TIMESTAMP DATE
The repair table indicates that block 3 of file 6 is corrupt - but remember that this block has not yet been marked as corrupt, therefore now is the time to extract any meaningful data. After the block is marked corrupt, the entire block must be skipped.
1. Determine the number of rows in the block from ALTER SYSTEM DUMP (nrows = 3).2. Query the corrupt object and extract as much information as possible.
SQL> -- The following query can be used to salvage data from a corrupt block.SQL> -- Creating a temporary table facilitates data insertion.
SQL> create table temp_t1 as 2 select * from system.t1 3 where dbms_rowid.rowid_block_number(rowid) = 3 4 and dbms_rowid.rowid_to_absolute_fno (rowid, 'SYSTEM','T1') = 6;
FIX_CORRUPT_BLOCKS procedure fixes the corrupt blocks in the specified objectsbased on information in the repair table. After the block has been marked as corrupt, an ORA-1578 results when a full table scan is performed.
SQL> select * from system.t1;select * from system.t1 *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 6, block # 3)ORA-01110: data file 6: '/tmp/ts_corrupt.dbf'
SQL> desc orphan_key_table Name Null? Type ----------------------------------------- -------- ---------------------------- SCHEMA_NAME NOT NULL VARCHAR2(30) INDEX_NAME NOT NULL VARCHAR2(30) IPART_NAME VARCHAR2(30) INDEX_ID NOT NULL NUMBER TABLE_NAME NOT NULL VARCHAR2(30) PART_NAME VARCHAR2(30) TABLE_ID NOT NULL NUMBER KEYROWID NOT NULL ROWID KEY NOT NULL ROWID DUMP_TIMESTAMP NOT NULL DATE
SQL> select index_name, count(*) from orphan_key_table 2 group by index_name;
Note: Index entry in the orphan key table implies that the index should be rebuilt to guarantee the a table probe and an index probe return the same result set.
SKIP_CORRUPT_BLOCKS enables/disables the skipping of corrupt blocks duringindex and table scans of a specified object.
Note: If an index and table are out of sync, then a SET TRANSACTION READ ONLY transaction may be inconsistent in situations where one query probes only the index and then a subsequent query probes both the index and the table. If the table block is marked corrupt, then the two queries will return different results.
Suggestion: If SKIP_CORRUPT_BLOCKS is enabled, then rebuild any indexes identified in the orphan key table (or all index associated with objectif DUMP_ORPHAN_KEYS was omitted).
Note - The above insert statement was used to provide a simple example.This is the perfect world - we know the data that was lost. The temporary table (temp_t1) should also be used to include all rows extracted from the corrupt block.
Conculsion=============
At this point the table T1 is available but data loss was incurred. In general,
data loss must be seriously considered before using the DBMS_REPAIR package formining the index segment and/or table block dumps is very complicated and logical inconsistencies may be introduced. In the initial release, the only repair affected by DBMS_REPAIR is to mark the block as software corrupt.
etect And Correct Corruption in Oracle
Oracle provides a number of methods to detect and repair corruption within datafiles:
DBVerify ANALYZE .. VALIDATE STRUCTURE
DB_BLOCK_CHECKING
RMAN VALIDATE (11g)
DBMS_REPAIR
Other Repair Methods
DBVerify
DBVerify is an external utility that allows validation of offline and online datafiles. In addition to offline datafiles it can be used to check the validity of backup datafiles.
When the DB_BLOCK_CHECKING parameter is set to TRUE Oracle performs a walk through of the data in the block to check it is self-consistent. Unfortunately block checking can add between 1 and 10% overhead to the server. Oracle recommend setting this parameter to TRUE if the overhead is acceptable.
RMAN VALIDATE (11g)
In Oracle 11g onward, Recover Manager (RMAN) can validate datafiles, tablespaces or the whole database.
Any block corruptions are visible in the V$DATABASE_BLOCK_CORRUPTION view.
Note. In prior versions, VALIDATE should only be used to validate backup-related files.
DBMS_REPAIR
Unlike the previous methods dicussed, the DBMS_REPAIR package allows you to detect and repair corruption. The process requires two administration tables to hold a list of corrupt blocks and index keys pointing to those blocks. These are created as follows.
Assuming the number of corrupt blocks is greater than 0 the CORRUPTION_DESCRIPTION and
the REPAIR_DESCRIPTION columns of the REPAIR_TABLE can be used to get more information about the corruption.
At this point the currupt blocks have been detected, but are not marked as corrupt. The FIX_CORRUPT_BLOCKS procedure can be used to mark the blocks as corrupt, allowing them to be skipped by DML once the table is in the correct mode.
Once the corrupt table blocks have been located and marked all indexes must be checked to see if any of their key entries point to a corrupt block. This is done using the DUMP_ORPHAN_KEYS procedure.
If the orphan key count is greater than 0 the index should be rebuilt.
The process of marking the table block as corrupt automatically removes it from the freelists. This can prevent freelist access to all blocks following the corrupt block. To correct this the freelists must be rebuilt using the REBUILD_FREELISTS procedure.
The final step in the process is to make sure all DML statements ignore the data blocks marked as corrupt. This is done using the SKIP_CORRUPT_BLOCKSprocedure.
The SKIP_CORRUPT column in the DBA_TABLES view indicates if this action has been successful.
At this point the table can be used again but you will have to take steps to correct any data loss associated with the missing blocks.
Other Repair Methods
Other methods to repair corruption include:
Full database recovery. Individual datafile recovery.
Block media recovery (BMR), available in Oracle 9i when using RMAN.
Recreate the table using the CREATE TABLE .. AS SELECT command, taking care to avoid the corrupt blocks by retricting the where clause of the query.
Drop the table and restore it from a previous export. This may require some manual effort to replace missing data.
DBMS_REPAIR
The DBMS_REPAIR package contains data corruption repair procedures that enable you to detect and repair corrupt blocks in tables and indexes. You can address corruptions where possible and continue to use objects while you attempt to rebuild or repair them.
See Also:For detailed information about using the DBMS_REPAIR package, see Oracle Database Administrator's Guide.
This chapter contains the following topics:
Using DBMS_REPAIR o Overviewo Security Modelo Constantso Operating Noteso Exceptionso Examples
Summary of DBMS_REPAIR Subprograms
Using DBMS_REPAIR
Overview Security Model Constants Operating Notes Exceptions Examples
OverviewNote:The DBMS_REPAIR package is intended for use by database administrators only. It is not intended for use by application developers.
Security Model
The package is owned by SYS. Execution privilege is not granted to other users.
The DBMS_REPAIR package defines several enumerated constants that should be used for specifying parameter values. Enumerated constants must be prefixed with the package name. For example, DBMS_REPAIR.TABLE_OBJECT.
Table 112-1 lists the parameters and the enumerated constants.
Table 112-1 DBMS_REPAIR Parameters with Enumerated Constants
The DBA would create the repair and orphan keys tables once. Subsequent executions of the CHECK_OBJECT Procedurewould add rows into the appropriate table indicating the types of errors found.
The name of the repair and orphan keys tables can be chosen by the user, with the following restriction: the name of the repair table must begin with the 'REPAIR_' prefix, and the name of the orphan keys table must begin with the 'ORPHAN_' prefix. The following code is also legal:
When invoking the CHECK_OBJECT Procedure the name of the repair and orphan keys tables that were created should be specified correctly, especially if the default values were not used in the ADMIN_TABLES Procedure or CREATE_ACTION.
Other actions in the ADMIN_TABLES Procedure can be used to purge/delete the REPAIR_TABLE and theORPHAN_KEYS_TABLE.
ADMIN_TABLES Procedure Provides administrative functions for the DBMS_REPAIR package repair and orphan key tables, including create, purge, and drop functions
CHECK_OBJECT Procedure Detects and reports corruptions in a table or index
DUMP_ORPHAN_KEYS Procedure
Reports on index entries that point to rows in corrupt data blocks
FIX_CORRUPT_BLOCKS Procedure
Marks blocks software corrupt that have been previously detected as corrupt byCHECK_OBJECT
ONLINE_INDEX_CLEAN Function
Performs a manual cleanup of failed or interrupted online index builds or rebuilds
Sets whether to ignore blocks marked corrupt during table and index scans or to report ORA-1578 when blocks marked corrupt are encountered
ADMIN_TABLES Procedure
This procedure provides administrative functions for the DBMS_REPAIR package repair and orphan key tables.
Syntax
DBMS_REPAIR.ADMIN_TABLES (
table_name IN VARCHAR2,
table_type IN BINARY_INTEGER,
action IN BINARY_INTEGER,
tablespace IN VARCHAR2 DEFAULT NULL);
Parameters
Table 112-4 ADMIN_TABLES Procedure Parameters
Parameter Description
table_name Name of the table to be processed. Defaults to ORPHAN_KEY_TABLE or REPAIR_TABLEbased on the specified table_type. When specified, the table name must have the appropriate prefix: ORPHAN_ or REPAIR_.
table_type Type of table; must be either ORPHAN_TABLE or REPAIR_TABLE.See "Constants".
action Indicates what administrative action to perform.Must be either CREATE_ACTION, PURGE_ACTION, or DROP_ACTION. If the table already exists, and if CREATE_ACTION is specified, then an error is returned. PURGE_ACTIONindicates to delete all rows in the table that are associated with non-existent objects. If the table does not exist, and if DROP_ACTION is specified, then an error is returned.When CREATE_ACTION and DROP_ACTION are specified, an associated view namedDBA_<table_name> is created and dropped respectively. The view is defined so that rows associated with non-existent objects are eliminated.Created in the SYS schema.
tablespace Indicates the tablespace to use when creating a table.By default, the SYS default tablespace is used. An error is returned if the tablespace is specified and if the action is not CREATE_ACTION.
CHECK_OBJECT Procedure
This procedure checks the specified objects and populates the repair table with information about corruptions and repair directives.
Validation consists of block checking all blocks in the object.
Syntax
DBMS_REPAIR.CHECK_OBJECT (
schema_name IN VARCHAR2,
object_name IN VARCHAR2,
partition_name IN VARCHAR2 DEFAULT NULL,
object_type IN BINARY_INTEGER DEFAULT TABLE_OBJECT,
repair_table_name IN VARCHAR2 DEFAULT 'REPAIR_TABLE',
flags IN BINARY_INTEGER DEFAULT NULL,
relative_fno IN BINARY_INTEGER DEFAULT NULL,
block_start IN BINARY_INTEGER DEFAULT NULL,
block_end IN BINARY_INTEGER DEFAULT NULL,
corrupt_count OUT BINARY_INTEGER);
Parameters
Table 112-5 CHECK_OBJECT Procedure Parameters
Parameter Description
schema_name Schema name of the object to be checked.
object_name Name of the table or index to be checked.
partition_name Partition or subpartition name to be checked.If this is a partitioned object, and if partition_name is not specified, then all partitions and subpartitions are checked. If this is a partitioned object, and if
the specified partition contains subpartitions, then all subpartitions are checked.
object_type Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT.See "Constants".
repair_table_name Name of the repair table to be populated.The table must exist in the SYS schema. Use the ADMIN_TABLES Procedure to create a repair table. The default name is REPAIR_TABLE.
flags Reserved for future use.
relative_fno Relative file number: Used when specifying a block range.
block_start First block to process if specifying a block range. May be specified only if the object is a single table, partition, or subpartition.
block_end Last block to process if specifying a block range. May be specified only if the object is a single table, partition, or subpartition. If only one of block_start or block_end is specified, then the other defaults to the first or last block in the file respectively.
corrupt_count Number of corruptions reported.
Usage Notes
You may optionally specify a DBA range, partition name, or subpartition name when you want to check a portion of an object.
DUMP_ORPHAN_KEYS Procedure
This procedure reports on index entries that point to rows in corrupt data blocks. For each such index entry encountered, a row is inserted into the specified orphan table.
If the repair table is specified, then any corrupt blocks associated with the base table are handled in addition to all data blocks that are marked software corrupt. Otherwise, only blocks that are marked corrupt are handled.
This information may be useful for rebuilding lost rows in the table and for diagnostic purposes.
object_type IN BINARY_INTEGER DEFAULT INDEX_OBJECT,
repair_table_name IN VARCHAR2 DEFAULT 'REPAIR_TABLE',
orphan_table_name IN VARCHAR2 DEFAULT 'ORPHAN_KEYS_TABLE',
flags IN BINARY_INTEGER DEFAULT NULL,
key_count OUT BINARY_INTEGER);
Parameters
Table 112-6 DUMP_ORPHAN_KEYS Procedure Parameters
Parameter Description
schema_name Schema name.
object_name Object name.
partition_name Partition or subpartition name to be processed.If this is a partitioned object, and if partition_name is not specified, then all partitions and subpartitions are processed. If this is a partitioned object, and if the specified partition contains subpartitions, then all subpartitions are processed.
object_type Type of the object to be processed. The default is INDEX_OBJECTSee "Constants".
repair_table_name Name of the repair table that has information regarding corrupt blocks in the base table.The specified table must exist in the SYS schema. The ADMIN_TABLES Procedure is used to create the table.
orphan_table_name Name of the orphan key table to populate with information regarding each index entry that refers to a row in a corrupt data block.The specified table must exist in the SYS schema. The ADMIN_TABLES Procedure is used to create the table.
This procedure fixes the corrupt blocks in specified objects based on information in the repair table that was previously generated by the CHECK_OBJECT Procedure.
Prior to effecting any change to a block, the block is checked to ensure the block is still corrupt. Corrupt blocks are repaired by marking the block software corrupt. When a repair is effected, the associated row in the repair table is updated with a fix timestamp.
Syntax
DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
schema_name IN VARCHAR2,
object_name IN VARCHAR2,
partition_name IN VARCHAR2 DEFAULT NULL,
object_type IN BINARY_INTEGER DEFAULT TABLE_OBJECT,
repair_table_name IN VARCHAR2 DEFAULT 'REPAIR_TABLE',
object_name Name of the object with corrupt blocks to be fixed.
partition_name Partition or subpartition name to be processed.If this is a partitioned object, and if partition_name is not specified, then all partitions and subpartitions are processed. If this is a partitioned object, and if the specified partition contains subpartitions, then all subpartitions are processed.
object_type Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT.See "Constants".
repair_table_name Name of the repair table with the repair directives.Must exist in the SYS schema.
This function performs a manual cleanup of failed or interrupted online index builds or rebuilds. This action is also performed periodically by SMON, regardless of user-initiated cleanup.
This function returns TRUE if all indexes specified were cleaned up and FALSE if one or more indexes could not be cleaned up.
Syntax
DBMS_REPAIR.ONLINE_INDEX_CLEAN (
object_id IN BINARY_INTEGER DEFAULT ALL_INDEX_ID,
wait_for_lock IN BINARY_INTEGER DEFAULT LOCK_WAIT)
RETURN BOOLEAN;
Parameters
Table 112-8 ONLINE_INDEX_CLEAN Function Parameters
Parameter Description
object_id Object id of index to be cleaned up. The default cleans up all object ids that qualify.
wait_for_lock This parameter specifies whether to try getting DML locks on underlying table [[sub]partition] object. The default retries up to an internal retry limit, after which the lock get will give up. If LOCK_NOWAIT is specified, then the lock get does not retry.
REBUILD_FREELISTS Procedure
This procedure rebuilds the freelists for the specified object. All free blocks are placed on the master freelist. All other freelists are zeroed.
If the object has multiple freelist groups, then the free blocks are distributed among all freelists, allocating to the different groups in round-robin fashion.
Syntax
DBMS_REPAIR.REBUILD_FREELISTS (
schema_name IN VARCHAR2,
object_name IN VARCHAR2,
partition_name IN VARCHAR2 DEFAULT NULL,
object_type IN BINARY_INTEGER DEFAULT TABLE_OBJECT);
object_name Name of the object whose freelists are to be rebuilt.
partition_name Partition or subpartition name whose freelists are to be rebuilt.If this is a partitioned object, and partition_name is not specified, then all partitions and subpartitions are processed. If this is a partitioned object, and the specified partition contains subpartitions, then all subpartitions are processed.
object_type Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT.See"Constants".
SEGMENT_FIX_STATUS Procedure
With this procedure you can fix the corrupted state of a bitmap entry. The procedure either recalculates the state based on the current contents of the corresponding block or sets the state to a specific value.
Syntax
DBMS_REPAIR.SEGMENT_FIX_STATUS (
segment_owner IN VARCHAR2,
segment_name IN VARCHAR2,
segment_type IN BINARY_INTEGER DEFAULT TABLE_OBJECT,
partition_name Optional. Name of an individual partition. NULL for nonpartitioned objects. Default isNULL.
segment_type Optional Type of the segment (for example, TABLE_OBJECT or INDEX_OBJECT). Default is NULL.
file_number (optional) The tablespace-relative file number of the data block whose status has to be fixed. If omitted, all the blocks in the segment will be checked for state correctness and fixed.
block_number (optional) The file-relative block number of the data block whose status has to be fixed. If omitted, all the blocks in the segment will be checked for state correctness and fixed.
status_value (optional) The value to which the block status described by the file_number andblock_number will be set. If omitted, the status will be set based on the current state of the block. This is almost always the case, but if there is a bug in the calculation algorithm, the value can be set manually. Status values:
1 = block is full 2 = block is 0-25% free 3 = block is 25-50% free 4 = block is 50-75% free 5 = block is 75-100% free
The status for bitmap blocks, segment headers, and extent map blocks cannot be altered. The status for blocks in a fixed hash area cannot be altered. For index blocks, there are only two possible states: 1 = block is full and 3 = block has free space.
SKIP_CORRUPT_BLOCKS Procedure
This procedure enables or disables the skipping of corrupt blocks during index and table scans of the specified object.
When the object is a table, skip applies to the table and its indexes. When the object is a cluster, it applies to all of the tables in the cluster, and their respective indexes.
Note:When Oracle performs an index range scan on a corrupt index after DBMS_REPAIR.SKIP_CORRUPT_BLOCKS has been set for the base table, corrupt branch blocks and root blocks are not skipped. Only corrupt non-root leaf blocks are skipped.
Syntax
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
schema_name IN VARCHAR2,
object_name IN VARCHAR2,
object_type IN BINARY_INTEGER DEFAULT TABLE_OBJECT,
schema_name Schema name of the object to be processed.
object_name Name of the object.
object_type Type of the object to be processed. This must be either TABLE_OBJECT (default) orCLUSTER_OBJECT.See "Constants".
flags If SKIP_FLAG is specified, then it turns on the skip of software corrupt blocks for the object during index and table scans. If NOSKIP_FLAG is specified, then scans that encounter software corrupt blocks return an ORA-1578.See"Constants".
Examples: Building a Repair Table or Orphan Key Table Example: Detecting Corruption Example: Fixing Corrupt Blocks Example: Finding Index Entries Pointing to Corrupt Data Blocks Example: Skipping Corrupt Blocks
Examples: Building a Repair Table or Orphan Key Table
The ADMIN_TABLE procedure is used to create, purge, or drop a repair table or an orphan key table.
A repair table provides information about the corruptions that were found by the CHECK_OBJECT procedure and how these will be addressed if the FIX_CORRUPT_BLOCKS procedure is run. Further, it is used to drive the execution of theFIX_CORRUPT_BLOCKS procedure.
An orphan key table is used when the DUMP_ORPHAN_KEYS procedure is executed and it discovers index entries that point to corrupt rows. The DUMP_ORPHAN_KEYS procedure populates the orphan key table by logging its activity and providing the index information in a usable manner.
Example: Creating a Repair Table
The following example creates a repair table for the users tablespace.
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/
For each repair or orphan key table, a view is also created that eliminates any rows that pertain to objects that no longer exist. The name of the view corresponds to the name of the repair or orphan key table and is prefixed by DBA_ (for example,DBA_REPAIR_TABLE or DBA_ORPHAN_KEY_TABLE).
The following query describes the repair table that was created for the users tablespace.
The CHECK_OBJECT procedure checks the specified object, and populates the repair table with information about corruptions and repair directives. You can optionally specify a range, partition name, or subpartition name when you want to check a portion of an object.
Validation consists of checking all blocks in the object that have not previously been marked corrupt. For each block, the transaction and data layer portions are checked for self consistency. During CHECK_OBJECT, if a block is encountered that has a corrupt buffer cache header, then that block is skipped.
The following is an example of executing the CHECK_OBJECT procedure for the scott.dept table.
The corrupted block has not yet been marked corrupt, so this is the time to extract any meaningful data. After the block is marked corrupt, the entire block must be skipped.
Example: Fixing Corrupt Blocks
Use the FIX_CORRUPT_BLOCKS procedure to fix the corrupt blocks in specified objects based on information in the repair table that was generated by the CHECK_OBJECT procedure. Before changing a block, the block is checked to ensure that the block is still corrupt. Corrupt blocks are repaired by marking the block software corrupt. When a repair is performed, the associated row in the repair table is updated with a timestamp.
This example fixes the corrupt block in table scott.dept that was reported by the CHECK_OBJECT procedure.
Example: Finding Index Entries Pointing to Corrupt Data Blocks
The DUMP_ORPHAN_KEYS procedure reports on index entries that point to rows in corrupt data blocks. For each index entry, a row is inserted into the specified orphan key table. The orphan key table must have been previously created.
This information can be useful for rebuilding lost rows in the table and for diagnostic purposes.
Note:This should be run for every index associated with a table identified in the repair table.
In this example, pk_dept is an index on the scott.dept table. It is scanned to determine if there are any index entries pointing to rows in the corrupt data block.
The following output indicates that there are three orphan keys:
orphan key count: 3
Index entries in the orphan key table implies that the index should be rebuilt. This guarantees that a table probe and an index probe return the same result set.
Example: Skipping Corrupt Blocks
The SKIP_CORRUPT_BLOCKS procedure enables or disables the skipping of corrupt blocks during index and table scans of the specified object. When the object is a table, skipping applies to the table and its indexes. When the object is a cluster, it applies to all of the tables in the cluster, and their respective indexes.
The following example enables the skipping of software corrupt blocks for the scott.dept table:
BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'DEPT',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.skip_flag);
END;
/
Querying scott's tables using the DBA_TABLES view shows that SKIP_CORRUPT is enabled for table scott.dept.
SELECT OWNER, TABLE_NAME, SKIP_CORRUPT FROM DBA_TABLES