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, 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. 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. DBMS_REPAIR Chapter

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: Dump file /export/home/oracle/product/8.1.5/admin/V815/udump/v815_ora_2835.trc Oracle8 Enterprise Edition Release 8.1.5.0.0 - Beta With the Partitioning option *** 1998.12.16.15.53.02.000 *** SESSION ID:(7.6) 1998.12.16.15.53.02.000 kdbchk: row locked by non-existent transaction table=0 slot=0 lockid=32 ktbbhitc=1 Block header dump: 0x01800003 Object id on Block? Y seg/obj: 0xb6d csc: 0x00.1cf5f itc: 1 flg: fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid 0x01 xid: 0x0002.011.00000121 0x0000.0001cf60 data_block_dump =============== tsiz: 0x7b8 hsiz: 0x18 pbl: 0x28088044 bdba: 0x01800003 flag=----------ntab=1 nrow=3 frre=-1 fsbo=0x18 fseo=0x19d avsp=0x185 tosp=0x185 0xe:pti[0] nrow=3

typ: 1 - DATA Scn/Fsc 3 fsc

Uba Flag Lck uba: 0x008018fb.0345.0d

--U-

offs=0

0x12:pri[0] offs=0x5ff 0x14:pri[1] offs=0x3a6 0x16:pri[2] offs=0x19d block_row_dump: [... remainder of file not included] end_of_block_dump

DBMS_REPAIR.ADMIN_TABLES (repair and orphan key ================================================ ADMIN_TABLES provides administrative functions for repair and orphan key tables. SQL> @adminCreate SQL> connect sys/change_on_install Connected. SQL> SQL> -- Repair Table SQL> SQL> declare 2 begin 3 -- Create repair table 4 dbms_repair.admin_tables ( 5 -table_name => 'REPAIR_TABLE', 6 table_type => dbms_repair.repair_table, 7 action => dbms_repair.create_action, 8 tablespace => 'USERS'); -- default TS of SYS if not specified 9 end; 10 / PL/SQL procedure successfully completed. SQL> select owner, object_name, object_type 2 from dba_objects 3 where object_name like '%REPAIR_TABLE'; OWNER OBJECT_NAME OBJECT_TYPE -----------------------------------------------------------------SYS DBA_REPAIR_TABLE VIEW SYS REPAIR_TABLE TABLE SQL> SQL> SQL> SQL> 2 3 4 5

-- Orphan Key Table declare begin -- Create orphan key table dbms_repair.admin_tables ( table_type => dbms_repair.orphan_table,

6 action => dbms_repair.create_action, 7 tablespace => 'USERS'); -- default TS of SYS if not specified 8 end; 9 / PL/SQL procedure successfully completed. SQL> select owner, object_name, object_type 2 from dba_objects 3 where object_name like '%ORPHAN_KEY_TABLE'; OWNER OBJECT_NAME OBJECT_TYPE -----------------------------------------------------------------SYS DBA_ORPHAN_KEY_TABLE VIEW SYS ORPHAN_KEY_TABLE TABLE

DBMS_REPAIR.CHECK_OBJECT ========================= CHECK_OBJECT procedure checks the specified object and populates the repair table with information about corruption and repair directive(s). Validation consists of block checking all blocks in the object. All blocks previously marked corrupt will be skipped. Note: In the initial release of DBMS_REPAIR the only repair is to mark the block as software corrupt. SQL> @checkObject SQL> set serveroutput on SQL> SQL> declare 2 rpr_count int; 3 begin 4 rpr_count := 0; 5 dbms_repair.check_object ( 6 schema_name => 'SYSTEM', 7 object_name => 'T1', 8 repair_table_name => 'REPAIR_TABLE', 9 corrupt_count => rpr_count); 10 dbms_output.put_line('repair count: ' || to_char(rpr_count)); 11 end; 12 / repair count: 1 PL/SQL procedure successfully completed. SQL> desc repair_table Name -------------------------------------------------------------------OBJECT_ID TABLESPACE_ID RELATIVE_FILE_ID Null? Type -------NOT NULL NUMBER NOT NULL NUMBER NOT NULL NUMBER

BLOCK_ID CORRUPT_TYPE SCHEMA_NAME OBJECT_NAME BASEOBJECT_NAME PARTITION_NAME CORRUPT_DESCRIPTION REPAIR_DESCRIPTION MARKED_CORRUPT CHECK_TIMESTAMP FIX_TIMESTAMP REFORMAT_TIMESTAMP

NOT NOT NOT NOT

NUMBER NUMBER VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) VARCHAR2(2000) VARCHAR2(200) NOT NULL VARCHAR2(10) NOT NULL DATE DATE DATE

NULL NULL NULL NULL

SQL> select object_name, block_id, corrupt_type, marked_corrupt, 2 corrupt_description, repair_description 3 from repair_table; OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR ------------------------------ ---------- ------------ ---------CORRUPT_DESCRIPTION ------------------------------------------------------------------------------REPAIR_DESCRIPTION ------------------------------------------------------------------------------T1 3 1 FALSE kdbchk: row locked by non-existent transaction table=0 slot=0 lockid=32 ktbbhitc=1 mark block software corrupt

Data Extraction =============== 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> 2 3 4 create table temp_t1 as select * from system.t1 where dbms_rowid.rowid_block_number(rowid) = 3 and dbms_rowid.rowid_to_absolute_fno (rowid, 'SYSTEM','T1') = 6;

Table created. SQL> select col1 from temp_t1; COL1 ---------2 3

DBMS_REPAIR.FIX_CORRUPT_BLOCKS (ORA-1578) ============================================ FIX_CORRUPT_BLOCKS procedure fixes the corrupt blocks in the specified objects based 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> declare 2 fix_count int; 3 begin 4 fix_count := 0; 5 dbms_repair.fix_corrupt_blocks ( 6 schema_name => 'SYSTEM', 7 object_name => 'T1', 8 object_type => dbms_repair.table_object, 9 repair_table_name => 'REPAIR_TABLE', 10 fix_count => fix_count); 11 dbms_output.put_line('fix count: ' || to_char(fix_count)); 12 end; 13 / fix count: 1 PL/SQL procedure successfully completed. SQL> select object_name, block_id, marked_corrupt 2 from repair_table; OBJECT_NAME BLOCK_ID MARKED_COR ------------------------------ ---------- ---------T1 3 TRUE 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'

DBMS_REPAIR.DUMP_ORPHAN_KEYS ==============================

DUMP_ORPHAN_KEYS reports on index entries that point to rows in corrupt data blocks. SQL> select index_name from dba_indexes 2 where table_name in (select distinct object_name from repair_table); INDEX_NAME -----------------------------T1_PK SQL> @dumpOrphanKeys SQL> set serveroutput on SQL> SQL> declare 2 key_count int; 3 begin 4 key_count := 0; 5 dbms_repair.dump_orphan_keys ( 6 schema_name => 'SYSTEM', 7 object_name => 'T1_PK', 8 object_type => dbms_repair.index_object, 9 repair_table_name => 'REPAIR_TABLE', 10 orphan_table_name => 'ORPHAN_KEY_TABLE', 11 key_count => key_count); 12 dbms_output.put_line('orphan key count: ' || to_char(key_count)); 13 end; 14 / orphan key count: 3 PL/SQL procedure successfully completed. SQL> desc orphan_key_table Name -------------------------------------------------------------------SCHEMA_NAME INDEX_NAME IPART_NAME INDEX_ID TABLE_NAME PART_NAME TABLE_ID KEYROWID KEY DUMP_TIMESTAMP Null? Type -------NOT NULL VARCHAR2(30) NOT NULL VARCHAR2(30) VARCHAR2(30) NOT NULL NUMBER NOT NULL VARCHAR2(30) VARCHAR2(30) NOT NULL NUMBER NOT NULL ROWID NOT NULL ROWID NOT NULL DATE

SQL> select index_name, count(*) from orphan_key_table 2 group by index_name; INDEX_NAME COUNT(*) ------------------------------ ---------T1_PK 3 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.

DBMS_REPAIR.SKIP_CORRUPT_BLOCKS =============================== SKIP_CORRUPT_BLOCKS enables/disables the skipping of corrupt blocks during index 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 object if DUMP_ORPHAN_KEYS was omitted). SQL> SQL> 2 3 4 5 6 7 8 9 @skipCorruptBlocks declare begin dbms_repair.skip_corrupt_blocks ( schema_name => 'SYSTEM', object_name => 'T1', object_type => dbms_repair.table_object, flags => dbms_repair.skip_flag); end; /

PL/SQL procedure successfully completed. SQL> select table_name, skip_corrupt from dba_tables 2 where table_name = 'T1'; TABLE_NAME SKIP_COR ------------------------------ -------T1 ENABLED SQL> -- rows in corrupt block skipped, no errors on full table scan SQL> select * from system.t1; COL1 COL2 ------------------------------------------------------------------------------4 dddd 5 eeee --> Notice the pk index has not yet been corrected. SQL> insert into system.t1 values (1,'aaaa'); insert into system.t1 values (1,'aaaa') * SQL> select * from system.t1 where col1 = 1; no rows selected

DBMS_REPAIR.REBUILD_FREELISTS =============================== REBUILD_FREELISTS rebuilds freelists for the specified object. SQL> 2 3 4 5 6 7 8 declare begin dbms_repair.rebuild_freelists ( schema_name => 'SYSTEM', object_name => 'T1', object_type => dbms_repair.table_object); end; /

PL/SQL procedure successfully completed.

Rebuild Index ============= Note: Every index identified in the orphan key table should be rebuilt to ensure consistent results. SQL> alter index system.t1_pk rebuild online; Index altered. SQL> insert into system.t1 values (1, 'aaaa'); 1 row created. SQL> select * from system.t1; COL1 COL2 ------------------------------------------------------------------------------4 dddd 5 eeee 1 aaaa 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. general, In

data loss must be seriously considered before using the DBMS_REPAIR package for mining 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. C:\>dbv file=C:\Oracle\oradata\TSH1\system01.dbf feedback=10000 blocksize=8192 This utility can't be used for controlfiles or redo logs.

ANALYZE .. VALIDATE STRUCTURE

The ANALYZE command can be used to verify each data block in the analyzed object. If any corruption is detected rows are added to the INVALID_ROWStable. -- Create the INVALID_ROWS table SQL> @C:\Oracle\901\rdbms\admin\UTLVALID.SQL -- Validate the table structure. SQL> ANALYZE TABLE scott.emp VALIDATE STRUCTURE; -- Validate the table structure along with all it's indexes. SQL> ANALYZE TABLE scott.emp VALIDATE STRUCTURE CASCADE; -- Validate the index structure. SQL> ANALYZE INDEX scott.pk_emp VALIDATE STRUCTURE;

DB_BLOCK_CHECKING
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. RMAN> VALIDATE DATAFILE 1; RMAN> VALIDATE DATAFILE '/u01/app/oracle/oradata/ORCL/system01.dbf'; RMAN> VALIDATE TABLESPACE users; RMAN> VALIDATE 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. BEGIN DBMS_REPAIR.admin_tables ( table_name => 'REPAIR_TABLE', table_type => DBMS_REPAIR.repair_table, action => DBMS_REPAIR.create_action, tablespace => 'USERS'); DBMS_REPAIR.admin_tables ( table_name => 'ORPHAN_KEY_TABLE', table_type => DBMS_REPAIR.orphan_table, action => DBMS_REPAIR.create_action, tablespace => 'USERS'); END; / With the administration tables built we are able to check the table of interest using the CHECK_OBJECT procedure. SET SERVEROUTPUT ON DECLARE v_num_corrupt INT; BEGIN v_num_corrupt := 0; DBMS_REPAIR.check_object ( schema_name => 'SCOTT', object_name => 'DEPT',

repair_table_name => 'REPAIR_TABLE', corrupt_count => v_num_corrupt); DBMS_OUTPUT.put_line('number corrupt: ' || TO_CHAR (v_num_corrupt)); END; / 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. SET SERVEROUTPUT ON DECLARE v_num_fix INT; BEGIN v_num_fix := 0; DBMS_REPAIR.fix_corrupt_blocks ( schema_name => 'SCOTT', object_name => 'DEPT', object_type => Dbms_Repair.table_object, repair_table_name => 'REPAIR_TABLE', fix_count => v_num_fix); DBMS_OUTPUT.put_line('num fix: ' || TO_CHAR(v_num_fix)); END; / 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. SET SERVEROUTPUT ON DECLARE v_num_orphans INT; BEGIN v_num_orphans := 0; DBMS_REPAIR.dump_orphan_keys ( schema_name => 'SCOTT', object_name => 'PK_DEPT', object_type => DBMS_REPAIR.index_object, repair_table_name => 'REPAIR_TABLE', orphan_table_name => 'ORPHAN_KEY_TABLE', key_count => v_num_orphans); DBMS_OUTPUT.put_line('orphan key count: ' || TO_CHAR(v_num_orphans)); END; / 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. BEGIN DBMS_REPAIR.rebuild_freelists ( schema_name => 'SCOTT', object_name => 'DEPT', object_type => DBMS_REPAIR.table_object); END; / 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. BEGIN DBMS_REPAIR.skip_corrupt_blocks ( schema_name => 'SCOTT', object_name => 'DEPT', object_type => DBMS_REPAIR.table_object, flags => DBMS_REPAIR.skip_flag); END; / 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 Overview o Security Model o Constants o Operating Notes o Exceptions o Examples Summary of DBMS_REPAIR Subprograms

Using DBMS_REPAIR

Overview Security Model Constants Operating Notes Exceptions Examples

Overview

Note:
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.

Constants

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

Parameter Option
object_type

Type
BINARY_INTEGER

Description

TABLE_OBJECT INDEX_OBJECT CLUSTER_OBJECT CREATE_ACTION DROP_ACTION PURGE_ACTION REPAIR_TABLE ORPHAN_TABLE SKIP_FLAG NOSKIP_FLAG ALL_INDEX_ID := 0 LOCK_WAIT := 1 LOCK_NOWAIT := 0

action

BINARY_INTEGER

table_type

BINARY_INTEGER

Clean up all objects that qualify Specifies whether to try getting DML locks on underlying table [[sub]partition] object

flags

BINARY_INTEGER

object_id wait_for_lock

BINARY_INTEGER BINARY_INTEGER

Note:
The default table_name will be REPAIR_TABLE when table_type is REPAIR_TABLE, and will beORPHAN_KEY_TABLE when table_type is ORPHAN_TABLE.

Operating Notes

The procedure to create the the REPAIR_TABLE.

CONNECT / AS SYSDBA;

ORPHAN_KEYS_TABLE

is similar to the one used to create

EXEC DBMS_REPAIR.ADMIN_TABLES('ORPHAN_KEYS_TABLE', DBMS_REPAIR.ORPHAN_TABLE, DBMS_REPAIR.CREATE_ACTION); EXEC DBMS_REPAIR.ADMIN_TABLES('REPAIR_TABLE', DBMS_REPAIR.REPAIR_TABLE, DBMS_REPAIR.CREATE_ACTION); DESCRIBE ORPHAN_KEYS_TABLE; DESCRIBE REPAIR_TABLE; SELECT * FROM ORPHAN_KEYS_TABLE; SELECT * FROM REPAIR_TABLE;

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:
CONNECT / AS SYSDBA; EXEC DBMS_REPAIR.ADMIN_TABLES('ORPHAN_FOOBAR', DBMS_REPAIR.ORPHAN_TABLE, DBMS_REPAIR.CREATE_ACTION); EXEC DBMS_REPAIR.ADMIN_TABLES('REPAIR_ABCD', DBMS_REPAIR.REPAIR_TABLE, DBMS_REPAIR.CREATE_ACTION); DESCRIBE ORPHAN_FOOBAR; DESCRIBE REPAIR_ABCD; SELECT * FROM ORPHAN_FOOBAR; SELECT * FROM REPAIR_ABCD;

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.

Exceptions

Table 112-2 DBMS_REPAIR Exceptions

Except ion Description
942

Action

Reported by DBMS_REPAIR.ADMIN_TABLES duri ng aDROP_ACTION when the specified table doesn't exist. Reported by DBMS_REPAIR. CREATE_ACTION w hen the specified table already exists.

955

Except ion Description

24120

Action

An invalid parameter was passed to the specifiedDBMS_REPAIR procedure. An incorrect block range was specified.

Specify a valid parameter value or use the parameter's default. Specify correct values for the BLOCK_START andBLOCK_END parameters.

24122

24123

An attempt was made to use the Do not attempt to use the feature. specified feature, but the feature is not yet implemented. An invalid ACTION parameter was specified. An attempt was made to fix corrupt blocks on an object that has been dropped or truncated sinceDBMS_REPAIR.CHECK_OBJECT w as run. parameter specified with an ACTIONother than CREATE_ACTION.
TABLESPACE

24124

Specify CREATE_ACTION, PURGE_ACTION orDROP_ACTION for the ACTION parameter. Use DBMS_REPAIR.ADMIN_TABLES to purge the repair table and run DBMS_REPAIR.CHECK_OBJECT to determine whether there are any corrupt blocks to be fixed. Do not specify TABLESPACE when performing actions other than CREATE_ACTION.

24125

24127

24128

A partition name was specified for Specify a partition name only if the object is an object that is not partitioned. partitioned. An attempt was made to pass a Pass a valid table name parameter. table name parameter without the specified prefix. An attempt was made to specify a Specify a valid table name parameter. repair or orphan table that does not exist. An attempt was made to specify a Specify a table name that refers to a properly created repair or orphan table that does table. not have a correct definition. An attempt was made to specify a Specify a valid table name parameter. table name is greater than 30 characters long.

24129

24130

24131

24132

Examples
/* Fix the bitmap status for all the blocks in table mytab in schema sys */

EXECUTE DBMS_REPAIR.SEGMENT_FIX_STATUS('SYS', 'MYTAB'); /* Mark block number 45, filenumber 1 for table mytab in sys schema as FULL.*/ EXECUTE DBMS_REPAIR.SEGMENT_FIX_STATUS('SYS', 'MYTAB', TABLE_OBJECT,1, 45, 1);

Summary of DBMS_REPAIR Subprograms

Table 112-3 DBMS_REPAIR Package Subprograms
Subprogram Description

ADMIN_TABLES Procedure

Provides administrative functions for the DBMS_REPAIR package repair and orphan key tables, including create, purge, and drop functions Detects and reports corruptions in a table or index Reports on index entries that point to rows in corrupt data blocks Marks blocks software corrupt that have been previously detected as corrupt byCHECK_OBJECT Performs a manual cleanup of failed or interrupted online index builds or rebuilds Rebuilds an object's freelists Fixes the corrupted state of a bitmap entry Sets whether to ignore blocks marked corrupt during table and index scans or to report ORA-1578 when blocks marked corrupt are encountered

CHECK_OBJECT Procedure DUMP_ORPHAN_KEYS Procedure FIX_CORRUPT_BLOCKS Procedure ONLINE_INDEX_CLEAN Function REBUILD_FREELISTS Procedure SEGMENT_FIX_STATUS Procedure SKIP_CORRUPT_BLOCKS Procedure

ADMIN_TABLES Procedure

This procedure provides administrative functions for the orphan key tables. Syntax

DBMS_REPAIR

package repair and

DBMS_REPAIR.ADMIN_TABLES ( table_name table_type action tablespace IN IN IN IN VARCHAR2, BINARY_INTEGER, BINARY_INTEGER, VARCHAR2 DEFAULT NULL);

Parameters

Table 112-4 ADMIN_TABLES Procedure Parameters

Paramet er 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_. Type of table; must be either ORPHAN_TABLE or REPAIR_TABLE. See "Constants". 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. See "Constants". 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.

table_type

action

tablespace

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 object_name partition_name object_type flags relative_fno block_start block_end corrupt_count IN IN IN IN IN IN IN IN VARCHAR2, VARCHAR2, VARCHAR2 VARCHAR2 DEFAULT NULL, DEFAULT 'REPAIR_TABLE', BINARY_INTEGER DEFAULT TABLE_OBJECT, BINARY_INTEGER DEFAULT NULL, BINARY_INTEGER DEFAULT NULL, BINARY_INTEGER DEFAULT NULL, BINARY_INTEGER DEFAULT NULL,

repair_table_name IN

OUT BINARY_INTEGER);

Parameters

Table 112-5 CHECK_OBJECT Procedure Parameters

Parameter
schema_name object_name partition_name

Description

Schema name of the object to be checked. Name of the table or index to be checked. 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. Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT. See "Constants". 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. Reserved for future use. Relative file number: Used when specifying a block range. First block to process if specifying a block range. May be specified only if the object is a single table, partition, or subpartition. 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. Number of corruptions reported.

object_type

repair_table_name

flags relative_fno block_start

block_end

corrupt_count

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. Syntax
DBMS_REPAIR.DUMP_ORPHAN_KEYS ( schema_name object_name partition_name object_type IN IN IN IN VARCHAR2, VARCHAR2, VARCHAR2 VARCHAR2 VARCHAR2 DEFAULT NULL, DEFAULT 'REPAIR_TABLE', DEFAULT 'ORPHAN_KEYS_TABLE', BINARY_INTEGER DEFAULT INDEX_OBJECT,

repair_table_name IN orphan_table_name IN flags key_count IN

BINARY_INTEGER DEFAULT NULL,

OUT BINARY_INTEGER);

Parameters

Table 112-6 DUMP_ORPHAN_KEYS Procedure Parameters

Parameter
schema_name object_name partition_name

Description

Schema name. Object 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

Parameter

Description

the specified partition contains subpartitions, then all subpartitions are processed.
object_type

Type of the object to be processed. The default is INDEX_OBJECT See "Constants". 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. 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. Reserved for future use. Number of index entries processed.

repair_table_name

orphan_table_name

flags key_count

FIX_CORRUPT_BLOCKS Procedure

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 object_name partition_name object_type flags fix_count IN IN IN IN IN VARCHAR2, VARCHAR2, VARCHAR2 VARCHAR2 DEFAULT NULL, DEFAULT 'REPAIR_TABLE', BINARY_INTEGER DEFAULT TABLE_OBJECT, BINARY_INTEGER DEFAULT NULL,

repair_table_name IN

OUT BINARY_INTEGER);

Parameters

Table 112-7 FIX_CORRUPT_BLOCKS Procedure Parameters

Parameter
schema_name object_name partition_name

Description

Schema name. Name of the object with corrupt blocks to be fixed. 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. Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT. See "Constants". Name of the repair table with the repair directives. Must exist in the SYS schema. Reserved for future use. Number of blocks fixed.

object_type

repair_table_name

flags fix_count

ONLINE_INDEX_CLEAN Function

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 more indexes could not be cleaned up. Syntax
DBMS_REPAIR.ONLINE_INDEX_CLEAN ( object_id wait_for_lock RETURN BOOLEAN; IN BINARY_INTEGER DEFAULT ALL_INDEX_ID, IN BINARY_INTEGER DEFAULT LOCK_WAIT) FALSE

if one or

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. 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.

wait_for_lock

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 object_name object_type IN VARCHAR2, IN VARCHAR2,

partition_name IN VARCHAR2 DEFAULT NULL, IN BINARY_INTEGER DEFAULT TABLE_OBJECT);

Parameters

Table 112-9 REBUILD_FREELISTS Procedure Parameters

Parameter
schema_name object_name partition_name

Description

Schema name. Name of the object whose freelists are to be rebuilt. 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. Type of the object to be processed. This must be either TABLE_OBJECT (default) orINDEX_OBJECT.

object_type

Parameter

Description

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 segment_name segment_type file_number block_number status_value partition_name IN VARCHAR2, IN VARCHAR2, IN BINARY_INTEGER DEFAULT TABLE_OBJECT, IN BINARY_INTEGER DEFAULT NULL, IN BINARY_INTEGER DEFAULT NULL, IN BINARY_INTEGER DEFAULT NULL, IN VARCHAR2 DEFAULT NULL,);

Parameters

Table 112-10 SEGMENT_FIX_STATUS Procedure Parameters

Parameter
schema_owner segment_name partition_name

Description

Schema name of the segment. Segment name. Optional. Name of an individual partition. NULL for nonpartitioned objects. Default isNULL. Optional Type of the segment (for example, TABLE_OBJECT or INDEX_OBJECT). Default is NULL. (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. (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.

segment_type

file_number

block_number

Parameter
status_value

Description

(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 object_name object_type flags IN VARCHAR2, IN VARCHAR2, IN BINARY_INTEGER DEFAULT TABLE_OBJECT, IN BINARY_INTEGER DEFAULT SKIP_FLAG);

Parameters

Table 112-11 SKIP_CORRUPT_BLOCKS Procedure Parameters

Paramete r Description
schema_name object_name object_type

Schema name of the object to be processed. Name of the object. Type of the object to be processed. This must be either TABLE_OBJECT (default) orCLUSTER_OBJECT. See "Constants". 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".

flags

DBMS_REPAIR Examples
This section includes the following topics:

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 END; / => dbms_repair.create_action, TABLESPACE => 'USERS');

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.
DESC REPAIR_TABLE Name OBJECT_ID TABLESPACE_ID RELATIVE_FILE_ID BLOCK_ID CORRUPT_TYPE SCHEMA_NAME OBJECT_NAME BASEOBJECT_NAME PARTITION_NAME CORRUPT_DESCRIPTION REPAIR_DESCRIPTION MARKED_CORRUPT CHECK_TIMESTAMP FIX_TIMESTAMP REFORMAT_TIMESTAMP Null? Type

---------------------------- -------- -------------NOT NULL NUMBER NOT NULL NUMBER NOT NULL NUMBER NOT NULL NUMBER NOT NULL NUMBER NOT NULL VARCHAR2(30) NOT NULL VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) VARCHAR2(2000) VARCHAR2(200) NOT NULL VARCHAR2(10) NOT NULL DATE DATE DATE

Example: Creating an Orphan Key Table

This example illustrates the creation of an orphan key table for the
BEGIN DBMS_REPAIR.ADMIN_TABLES ( TABLE_NAME => 'ORPHAN_KEY_TABLE', TABLE_TYPE => dbms_repair.orphan_table,

users

tablespace.

ACTION END; /

=> dbms_repair.create_action,

TABLESPACE => 'USERS');

The orphan key table is described in the following query:

DESC ORPHAN_KEY_TABLE Name SCHEMA_NAME INDEX_NAME IPART_NAME INDEX_ID TABLE_NAME PART_NAME TABLE_ID KEYROWID KEY DUMP_TIMESTAMP Null? Type

---------------------------- -------- ----------------NOT NULL VARCHAR2(30) NOT NULL VARCHAR2(30) VARCHAR2(30) NOT NULL NUMBER NOT NULL VARCHAR2(30) VARCHAR2(30) NOT NULL NUMBER NOT NULL ROWID NOT NULL ROWID NOT NULL DATE

Example: Detecting Corruption

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 the scott.dept table.
SET SERVEROUTPUT ON DECLARE num_corrupt INT; BEGIN num_corrupt := 0; DBMS_REPAIR.CHECK_OBJECT ( SCHEMA_NAME => 'SCOTT', OBJECT_NAME => 'DEPT', REPAIR_TABLE_NAME => 'REPAIR_TABLE', CHECK_OBJECT

procedure for

CORRUPT_COUNT => END; /

num_corrupt);

DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));

SQL*Plus outputs the following line, indicating one corruption:

number corrupt: 1

Querying the repair table produces information describing the corruption and suggesting a repair action.
SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT, CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION FROM REPAIR_TABLE; OBJECT_NAME CORRUPT_DESCRIPTION -----------------------------------------------------------------------------REPAIR_DESCRIPTION -----------------------------------------------------------------------------DEPT table=0 lockid=32 slot=0 ktbbhitc=1 3 1 FALSE kdbchk: row locked by non-existent transaction BLOCK_ID CORRUPT_TYPE MARKED_COR

------------------------------ ---------- ------------ ----------

mark block software corrupt

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 the CHECK_OBJECT procedure.
SET SERVEROUTPUT ON DECLARE num_fix INT; BEGIN scott.dept

that was reported by

num_fix := 0; DBMS_REPAIR.FIX_CORRUPT_BLOCKS ( SCHEMA_NAME => 'SCOTT', OBJECT_NAME=> 'DEPT', OBJECT_TYPE => dbms_repair.table_object, REPAIR_TABLE_NAME => 'REPAIR_TABLE', FIX_COUNT=> num_fix); DBMS_OUTPUT.PUT_LINE('num fix: ' || TO_CHAR(num_fix)); END; /

SQL*Plus outputs the following line:

num fix: 1

The following query confirms that the repair was done.

SELECT OBJECT_NAME, BLOCK_ID, MARKED_CORRUPT FROM REPAIR_TABLE; OBJECT_NAME DEPT BLOCK_ID MARKED_COR 3 TRUE

------------------------------ ---------- ----------

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.
SET SERVEROUTPUT ON DECLARE num_orphans INT; BEGIN num_orphans := 0; DBMS_REPAIR.DUMP_ORPHAN_KEYS ( SCHEMA_NAME => 'SCOTT',

OBJECT_NAME => 'PK_DEPT', OBJECT_TYPE => dbms_repair.index_object, REPAIR_TABLE_NAME => 'REPAIR_TABLE', ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE', KEY_COUNT => num_orphans); DBMS_OUTPUT.PUT_LINE('orphan key count: ' || TO_CHAR(num_orphans)); END; /

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 table scott.dept.

DBA_TABLES

view shows that

SKIP_CORRUPT

is enabled for

SELECT OWNER, TABLE_NAME, SKIP_CORRUPT FROM DBA_TABLES WHERE OWNER = 'SCOTT'; OWNER SCOTT SCOTT TABLE_NAME ACCOUNT BONUS SKIP_COR DISABLED DISABLED

------------------------------ ------------------------------ --------

SCOTT SCOTT SCOTT SCOTT SCOTT SCOTT SCOTT SCOTT 10 rows selected.

DEPT DOCINDEX EMP RECEIPT SALGRADE SCOTT_EMP SYS_IOT_OVER_12255 WORK_AREA

ENABLED DISABLED DISABLED DISABLED DISABLED DISABLED DISABLED DISABLED

sing DBMS_REPAIR to check for corruption.

Posted on May 31, 2011 by Gary

[Translate]

dbms_repair can be used to check for corruption in the database. Heres what to do when corruption is reported in the alert log. The corruption has to be identified initially. This can be done with one of the following methods: Using DBMS_REPAIR. This performs block checking for a table, partition or index, and places the information in the repair table. DB_VERIFY. This will perform block checks on an offline database. Analyze Table. Is using the analyze table validate structure option, the integrity of an index, table or partition will be checked for synchronization. DB_BLOCK_CHECKING

When set to true, it will identify corrupt blocked before they are marked corrupt, when a block is changed. This has a mild overhead. Fixing Corruption. Before using dbms_Repair, consider the following questions: What is the extent of the corruption? To determine if there are corruptions and repair actions, execute the CHECK_OBJECT procedure and query the repair table. What other options are available for addressing block corruptions? Consider the following: 1.If the data is available from another source, then drop, re-create, and repopulate the object. 2.Issue the CREATE TABLEAS SELECT statement from the corrupt table to create a new one. 3.Ignore the corruption by excluding corrupt rows from SELECT statements. 4.Perform media recovery. What logical corruptions or side effects are introduced when you use DBMS_REPAIR to make an object usable? Can these be addressed? What is the effort required to do so ? It is possible that you do not have access to rows in blocks marked corrupt. However, a block can be marked corrupt even if there are rows that you can validly access. It is also possible that referential integrity constraints are broken when blocks are marked corrupt. If this occurs, then disable and reenable the constraint; any inconsistencies are reported. After fixing all problems, you should be able to reenable the constraint.

Logical corruption can occur when there are triggers defined on the table. For example, if rows are reinserted, should insert triggers be fired or not? You can address these issues only if you understand triggers and their use in your installation. If indexes and tables are not synchronized, then execute the DUMP_ORPHAN_KEYS procedure to obtain information from the keys that might be useful in rebuilding corrupted data. Then issue the ALTER INDEXREBUILD ONLINE statement to synchronize the table with its indexes. If repair involves loss of data, can this data be retrieved? You can retrieve data from the index when a data block is marked corrupt. The DUMP_ORPHAN_KEYS procedure can help you retrieve this information. You will have to create the repair table which will be used to store the results of the check. Both are shown for the repair table and orphan keys table. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES(REPAIR_TABLE, DBMS_REPAIR.REPAIR_TABLE,DBMS_REPAIR.CREATE_ACTION); PL/SQL procedure successfully completed. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES(ORPHAN_KEYS_TABLE, DBMS_REPAIR.ORPHAN_TABLE,DBMS_REPAIR.CREATE_ACTION); PL/SQL procedure successfully completed. If dbms_repair os still the better option, dbms_repair consists of the following procedures in the package. I have yet to document the remaining procedures in the package. These on oracle 9i. procedure admin_tables( table_name IN varchar2 DEFAULT GENERATE_DEFAULT_TABLE_NAME, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);

procedure 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); procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT REPAIR_TABLE, orphan_table_name IN varchar2 DEFAULT ORPHAN_KEY_TABLE, flags IN binary_integer DEFAULT NULL, key_count OUT binary_integer); procedure 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, flags IN binary_integer DEFAULT NULL, fix_count OUT binary_integer); procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);

procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN binary_integer DEFAULT SKIP_FLAG); procedure segment_fix_status( segment_owner IN varchar2, segment_name IN varchar2, segment_type IN binary_integer DEFAULT TABLE_OBJECT, file_number IN binary_integer DEFAULT NULL, block_number IN binary_integer DEFAULT NULL, status_value IN binary_integer DEFAULT NULL, partition_name IN varchar2 DEFAULT NULL); 10g additionally has the following: procedure rebuild_shc_index( segment_owner IN varchar2, cluster_name IN varchar2); function online_index_clean( object_id IN binary_integer DEFAULT ALL_INDEX_ID, wait_for_lock IN binary_integer DEFAULT LOCK_WAIT) return boolean; An example is supplied for 10g. DECLARE isClean BOOLEAN; BEGIN isClean := FALSE; WHILE isClean=FALSE LOOP isClean := DBMS_REPAIR.ONLINE_INDEX_CLEAN(DBMS_REPAIR.ALL_INDEX_ID,

DBMS_REPAIR.LOCK_WAIT); DBMS_LOCK.SLEEP(10); END LOOP; EXCEPTION WHEN OTHERS THEN RAISE; END; / Heres our problem that we had corruption reported. I found the segment whose extents were corrupted and decided to check the whole tablespace. WILLOW2K TABLE DOC WILLOW2K TABLE DOCL WILLOW2K TABLE REPORT_LINES WILLOW2K TABLE EXTERNAL_ACCOUNTS_AUDIT WILLOW2K TABLE SKYTRAX_UPLOAD WILLOW2K TABLE SKYTRAX_UPLOAD_FIXES WILLOW2K TABLE SKYTRAX_UPLOAD2 To check the object for corruption, we can use the following: set serveroutput on size 9999 declare cnt number; begin dbms_repair.CHECK_OBJECT(SCHEMA_NAME=>WILLOW2K,OBJECT_NAME=> DOC,CORRUPT_COUNT=>cnt); dbms_output.put_line(cnt|| Corrupt on the count);

end; / The output of this will be the text 0 Corrupt on the count, indicating that this object, DOC owned by WILLOW2K has to corrupt blocks in the segment. This can be further placed into a loop to seek all segments which are in a data files. In the example below, we are looping through all segments in datafile 138, and the output will be as above to detail the number of corrupt blocks in each segment. set serveroutput on size 9999 declare cnt number; begin for c1 in (select owner, SEGMENT_NAME from dba_extents where file_id = 138) loop dbms_repair.CHECK_OBJECT(SCHEMA_NAME=>c1.owner,OBJECT_NAME=>c1.SE GMENT_NAME,CORRUPT_COUNT=>cnt); dbms_output.put_line(c1.owner||.'||c1.SEGMENT_NAME|| ||cnt|| Corrupt on the count); end loop; end; / The output here will be something like Owner.Segment_name 0 Corrupt on the count, for each segment in the tablespace. Remember that the object type defaults to type table, you can however change it with the dbms_repair data type number. Here are the fixed parameters used in dbms_repair for object identification. Objects TABLE_OBJECT 1 INDEX_OBJECT 2 CLUSTER_OBJECT 4

Flags SKIP_FLAG 1 NOSKIP_FLAG 2 Admin CREATE_ACTION 1 PURGE_ACTION 2 DROP_ACTION 3 Admin Tables REPAIR_TABLE 1 ORPHAN_TABLE 2 Oracle 10g has additional parameters. ALL_INDEX_ID 0 and LOCK_NOWAIT 0 LOCK_WAIT 1 You can specify the object as a number, or use the dbms_repair package to obtain it, below I use dbms_repair.index_object, which has the value 2 associated with it. SQL> declare cnt number; begin dbms_repair.CHECK_OBJECT( schema_name=>WILLOW2K, object_name=>DOC_IDX_NEW_03, OBJECT_TYPE => dbms_repair.index_object, corrupt_count=>cnt);

dbms_output.put_line(Corrupt count : ||cnt); end; / 2 3 4 5 6 7 8 9 10 11 Corrupt count : 0 PL/SQL procedure successfully completed. Here Im telling it to check a specific index, so have to let it know with the dbms_repair.index_object parameters. If we find that a segment has a count higher than zero, then we can attempt to fix it using the following procedure in the package. declare fix_count binary_integer; begin dbms_repair.fix_corrupt_blocks(schema_name=>WILLOW2K,object_name=>DOC_ IDX_09,fix_Count=>fix_count); dbms_output.put_line(fix_count); end; / Here, we are looking to find and fix corruption occuring in the WILLOW2K.DOC_IDX_09 index, and a count of the blocks that are fixed will be output at the end of the procedure execution. Now, we have to make the object usable. This can be done through setting the object to SKIP_CORRUPT_BLOCKS (index or table scans) or using FIX_CORRUPT_BLOCKS to skip all corrupt blocks. If the corruption involves data loss, such as a bad data block row, then all the blocks are marked corrupt using FIX_CORRUPT_BLOCKS. SKIP_CORRUPT_BLOCKS will just skip those marked corrupt. The SKIP_FLAG parameter indicates that all table and index scans will skip all blocks marked as corrupted. Implications.

With an index and table out of sync, with the set transaction read only, then different results can be returned by the same query where one uses a table scan and another uses an index scan. Also, chained rows can cause the same problem. Do not rely on the results until the corruption is corrected in the object. Use Dump Orphan Keys. The DUMP_ORPHAN_KEYS procedure will report index entries which point to currupt blocks. These index entries are placed in an orphan table, with the key and rowid of the corruption. Alter the index. You can just rebuild the index once the information has been retrieved, online with the REBUILD ONLINE statement. The SEGMENT_FIX_STATUS procedure is for free space in segments managed by bitmaps, or auto segment space management. This will recalculate the bitmap entry on the current contents of the block. You can set the entry manually, but its normally done correctly and not required. Example 1. A query was failing. Below are the checks performed, with the objects referenced by a materialized view, followed by a specific list of tables referenced in a query. set linesize 132 pagesize 9999 select distinct referenced_owner, referenced_name from dba_dependencies where name = PWC_MV_JOBKEY_FIG; REFERENCED_OWNER REFERENCED_NAME PWCDW PWC_MV_JOBINV_LINE PWCDW PWC_MV_JOBKEY_FIG PWCDW PWC_MV_NETONACCOUNT

PWC PWCDW

JOBHEADER PWC_MV_JOBENTRY

set serveroutput on size 9999 declare cnt number; begin for c1 in (select distinct referenced_owner, referenced_name from dba_dependencies where name = PWC_MV_JOBKEY_FIG) loop dbms_repair.CHECK_OBJECT(SCHEMA_NAME=>c1.referenced_owner,OBJECT_NA ME=>c1.referenced_name,REPAIR_TABLE_NAME=>REPAIR_TABLE,CORRUPT_C OUNT=>cnt); dbms_output.put_line(cnt|| Corrupt on the count for ||c1.referenced_owner||.'|| c1.referenced_name); end loop; end; / 0 Corrupt on the count for PWCDW.PWC_MV_JOBINV_LINE 0 Corrupt on the count for PWCDW.PWC_MV_JOBKEY_FIG 0 Corrupt on the count for PWCDW.PWC_MV_NETONACCOUNT 0 Corrupt on the count for PWC.JOBHEADER 0 Corrupt on the count for PWCDW.PWC_MV_JOBENTRY PL/SQL procedure successfully completed. set serveroutput on size 9999 declare cnt number; begin for c1 in (select distinct owner referenced_owner, table_name referenced_name from dba_tables where owner = PWC and table_name in (EMPLOYEE,'LOCATION,'CUSTOMER)) loop dbms_repair.CHECK_OBJECT(SCHEMA_NAME=>c1.referenced_owner,OBJECT_NA ME=>c1.referenced_name,REPAIR_TABLE_NAME=>REPAIR_TABLE,CORRUPT_C

OUNT=>cnt); dbms_output.put_line(cnt|| Corrupt on the count for ||c1.referenced_owner||.'|| c1.referenced_name); end loop; end; / 0 Corrupt on the count for PWC.EMPLOYEE 0 Corrupt on the count for PWC.CUSTOMER 0 Corrupt on the count for PWC.LOCATION PL/SQL procedure successfully completed. The counter on both was zero, so I started to look into the indexes related to the table at the point the ORA-00600 occurred. ERROR at line 131: ORA-00600: internal error code, arguments: [qkabix], [0], [], [], [], [], [], [] Therefore we should be looking at 128 129 130 131 132 133 134 FROM popupitem po WHERE jh.currency = po.popupitemnumber AND po.popuptypename = CurrencyType) AS currency FROM jobheader jh, customer c, employee em, employee csp,

set serveroutput on size 9999 declare cnt number; begin for c1 in (select distinct owner referenced_owner, index_name referenced_name from dba_indexes where owner = PWC and table_name in (JOBHEADER)) loop

dbms_repair.dump_orphan_keys(SCHEMA_NAME=>c1.referenced_owner,OBJECT_ NAME=>c1.referenced_name,REPAIR_TABLE_NAME=>REPAIR_TABLE, OBJECT_TYPE=>dbms_repair.INDEX_OBJECT,ORPHAN_TABLE_NAME=>ORPH AN_KEYS_TABLE,KEY_COUNT=>cnt); dbms_output.put_line(cnt|| Corrupt on the count for ||c1.referenced_owner||.'|| c1.referenced_name); end loop; end; / This will output all indexes on the table with the corrupt count. From here we can look in the repair_table and orphan_keys_table for specific information. 0 Corrupt on the count for PWC.JOBHEADER1006PWC 0 Corrupt on the count for PWC.JOBHEADER1004PWC 0 Corrupt on the count for PWC.JOBHEADER1003PWC 0 Corrupt on the count for PWC.JOBHEADER03 0 Corrupt on the count for PWC.JOBHEADER09 0 Corrupt on the count for PWC.JOBHEADER10 0 Corrupt on the count for PWC.JOBHEADER11 0 Corrupt on the count for PWC.JOBHEADER24 0 Corrupt on the count for PWC.JOBHEADER27 0 Corrupt on the count for PWC.JOBHEADER32PWC 0 Corrupt on the count for PWC.JOBHEADER29PWC 0 Corrupt on the count for PWC.INSTANCEKEY489 0 Corrupt on the count for PWC.JOBHEADER1010PWC 0 Corrupt on the count for PWC.JOBHEADER13 0 Corrupt on the count for PWC.JOBHEADER15 0 Corrupt on the count for PWC.JOBHEADER34PWC 0 Corrupt on the count for PWC.JOBHEADER1015PWC 0 Corrupt on the count for PWC.JOBHEADER1013PWC 0 Corrupt on the count for PWC.JOBHEADER1002PWC 0 Corrupt on the count for PWC.JOBHEADER08 0 Corrupt on the count for PWC.JOBHEADER26 0 Corrupt on the count for PWC.JOBHEADER01 0 Corrupt on the count for PWC.JOBHEADER06

0 Corrupt on the count for PWC.JOBHEADER16 0 Corrupt on the count for PWC.JOBHEADER18 0 Corrupt on the count for PWC.JOBHEADER22 0 Corrupt on the count for PWC.JOBHEADER29 0 Corrupt on the count for PWC.JOBHEADER33PWC 0 Corrupt on the count for PWC.JOBHEADER1014PWC 0 Corrupt on the count for PWC.JOBHEADER27PWC 0 Corrupt on the count for PWC.JOBHEADER1016PWC 0 Corrupt on the count for PWC.JOBHEADER12 0 Corrupt on the count for PWC.JOBHEADER19 0 Corrupt on the count for PWC.JOBHEADER1011PWC 0 Corrupt on the count for PWC.JOBHEADER1008PWC 0 Corrupt on the count for PWC.JOBHEADER07 0 Corrupt on the count for PWC.JOBHEADER14 0 Corrupt on the count for PWC.JOBHEADER1012PWC 0 Corrupt on the count for PWC.JOBHEADER02 0 Corrupt on the count for PWC.JOBHEADER17 0 Corrupt on the count for PWC.JOBHEADER23 0 Corrupt on the count for PWC.JOBHEADER28 0 Corrupt on the count for PWC.JOBHEADER1009PWC 0 Corrupt on the count for PWC.JOBHEADER1007PWC 0 Corrupt on the count for PWC.JOBHEADER1005PWC 0 Corrupt on the count for PWC.JOBHEADER04 0 Corrupt on the count for PWC.JOBHEADER05 0 Corrupt on the count for PWC.JOBHEADER20 0 Corrupt on the count for PWC.JOBHEADER21 0 Corrupt on the count for PWC.JOBHEADER25 0 Corrupt on the count for PWC.JOBHEADER30PWC PL/SQL procedure successfully completed. Therefore, we can find no corruption on the database around this object.