Translate

Search This Blog

Showing posts with label RMAN. Show all posts
Showing posts with label RMAN. Show all posts

BACKUP , RECOVERY and archive log handling in RAC

Here are few basic points to consider about safe backup and recovery in RAC environment :

  • If DB running in archive log mode then archive logs should be placed on a single location(say single ASM directory) in shared disk so that if you ever needs to recover then you do not need to copy all archive logs to a single location or supply archive log file names manually for each log sequence#. Configuring Flash recovery area is so good option for RAC databases.
  • If you have less storage available or you want faster archiving only then you should consider archiving logs to local disks of nodes.                                                                                           
  • In case all instances crashes(power failure in data centre) then you should bring all nodes one by one. As this way it is not only cluster ware will have safe recovery but also  Database crash recovery will also be safe. 
  • Configure RMAN control file auto back-up feature also to shared disks (say OCFS file system,if applicable) as this will allow control file to be restored from any node and hence so recovery also.
  • As RAC instances has more shared pool available than single instance you can increase large pool size to increase RMAN buffers for faster backup so you may multiplex more files in backupset and parallelize more if enough CPUs available but remember higher multiplexing can potentially slow down restore.

  • To benefit from more CPUs available in RAC than single instance database backup channels can be opened across all RAC nodes this when combines with benefits of compressed backup sets speeds up backup   

ORA-16038: log 1 sequence# 2901 cannot be archived - ORA-19809: limit exceeded for recovery files logfileswitch(archiving needed)

ORA-16038: log 1 sequence# 36792 cannot be archived.
ORA-19809: limit exceeded for recovery files

Your DML statements ,even, session logon hangs and you get above error besides getting below error in alert log file as well. Further you see wait event logfileswitch(archiving needed) which implies sesion is waiting for log file switch to succeed which in turn is waiting for older logfiles to be archived.

SID,SEQ#,EVENT,P1TEXT,P1,P1RAW,P2TEXT,P2,P2RAW,P3TEXT,P3,P3RAW,WAIT_CLASS_ID,WAIT_CLASS#,WAIT_CLASS,WAIT_TIME,SECONDS_IN_WAIT,STATE,WAIT_TIME_MICRO,TIME_REMAINING_MICRO,TIME_SINCE_LAST_WAIT_MICRO

49,47571,logfileswitch(archivingneeded),,0,00,,0,00,,0,00,3290255840,2,Configuration,0,84,WAITING,84329776,-1,0

If this wait event is seen continuously then it means archiver process is not able to write archive redo logfiles due below reasons

1. mount point or directory pointed by log_archive_destination_n is full in disk space

2. There is flash recovery area being used for archiving, there may be enough space in directory/mount point on which flash recovery area lies but flash recovery area is filled upto space limit defined by instance init parameter db_recovery_file_dest_size   

 select *  from v$recovery_file_dest

NAME,           SPACE_LIMIT,SPACE_USED,   SPACE_RECLAIMABLE,NUMBER_OF_FILES
C:\flash_recovery_area,107374182400,107216960512,1081344,1147

107374182400=100GB

Here you can see flash recovery area has only free space=SPACE_LIMIT-SPACE_USED=149MB while the redo log file size is bigger(200MB) than this free space 149MB so redo log could not be archived.

Remedy 1:

 SQL> show parameter recovery_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------------------
db_recovery_file_dest                string      C:\flash_recovery_area
db_recovery_file_dest_size           big integer 100G

If there is enough free space in flash reocvery area location pointed by flash recovery area db_recovery_file_dest  then increase space limit(db_recovery_file_dest) which is set to 100GB in above: 
 
alter systemset db_recovery_file_dest_size=400g [

Remedy 2:

-delete older archive logs which are not needed according to backup policy

RMAN> delete archivelog until time 'sysdate-7'

-delete expired archive logs (archive log fiels deleted physically from OS command and not from RMAN.First, mark such archived logs to be expired in RMAN.

RMAN> crosscheck archivelog all
OR
RMAN>change archive log all validate;

then delete marked expired archive logs

RMAN>delete expired archivelog all;

Now archiving will succeed.

RMAN salient feature introduced from 10g incrementally updated image copy backup-- which is mostly ignored

Incrementally updated image copy backup:


It is faster to restore from RMAN image (copy) backup still   image copy backups were not considered very good practice because it takes longer to take rman copy(image)
backup as they backup whole database block to block backup and also incremental image copy backup was  not possible.

Oracle 10g has introduced incrementally updated image copy backup feature. In this feature first
copy backup was taken and then incremntal backup set is taken and image copy backup is updated with  this incremental backupset. So basically this is three steps task.

first step: update(recover) the image copy backup
second step : take image copy backup if this does not exist before
and then take incremental level 1 backupset(changed block from image copy backup)

RUN {
  RECOVER COPY OF DATABASE WITH TAG 'incr_backup' ;
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
}

Note the backuo tags must be same in both rman commands.
Note 1: When above commands are executed for first time. RMAN gives message
"no copy of datafile #n found to recover" as there are no existing image copy backup with given tag
and then take the image copy backup of database.
It does not take the incremental backupset.
Note 2: when above commands are executed for second time, then RMAN again gives message
"no copy of datafile #n found to recover" as there are no existing incremental backupset to apply(recover)
the image copy backup of database with the given tag. and takes the incremental level 1 backupset.

Note3: It performs  two steps: First recover the image copy backup of database with incremental backupset.
and then it takes incremental level 1 backup set(backup of changed blocks since image copy backup of database
was taken with given tag
First run:
RMAN> RUN {
2>   RECOVER COPY OF DATABASE WITH TAG 'incr_backup' ;
3>   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
4> }
Starting recover at 05-FEB-13
using channel ORA_DISK_1
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover
Finished recover at 05-FEB-13
Starting backup at 05-FEB-13
using channel ORA_DISK_1
no parent backup or copy of datafile 1 found
no parent backup or copy of datafile 3 found
no parent backup or copy of datafile 5 found
no parent backup or copy of datafile 2 found
no parent backup or copy of datafile 4 found
channel ORA_DISK_1: starting datafile copy
input datafile fno=00001 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
output filename=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-SYSTEM_FNO-1_5DO179AR tag=INCR_BACKUP recid=85 stamp=806593907
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile copy
input datafile fno=00003 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
output filename=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-SYSAUX_FNO-3_5EO179BK tag=INCR_BACKUP recid=86 stamp=806593922
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
input datafile fno=00005 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
output filename=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-EXAMPLE_FNO-5_5FO179C3 tag=INCR_BACKUP recid=87 stamp=806593929
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile fno=00002 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
output filename=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-UNDOTBS1_FNO-2_5GO179CB tag=INCR_BACKUP recid=88 stamp=806593934
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile fno=00004 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
output filename=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-USERS_FNO-4_5HO179CI tag=INCR_BACKUP recid=89 stamp=806593938
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 05-FEB-13
Starting Control File and SPFILE Autobackup at 05-FEB-13
piece handle=D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2013_02_05\O1_MF_S_806593939_8K1J9WD4_.BKP comment=NONE
Finished Control File and SPFILE Autobackup at 05-FEB-13
Second run:
RMAN> RUN {
2>   RECOVER COPY OF DATABASE WITH TAG 'incr_backup' ;
3>   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
4> }
Starting recover at 05-FEB-13
using channel ORA_DISK_1
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover
Finished recover at 05-FEB-13
Starting backup at 05-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental level 1 datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
input datafile fno=00003 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
input datafile fno=00005 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
input datafile fno=00002 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
input datafile fno=00004 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
channel ORA_DISK_1: starting piece 1 at 05-FEB-13
channel ORA_DISK_1: finished piece 1 at 05-FEB-13
piece handle=D:\ORATEMP\DEF_LOC_5JO179D2_1_1 tag=TAG20130205T135234 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 05-FEB-13
Starting Control File and SPFILE Autobackup at 05-FEB-13
piece handle=D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2013_02_05\O1_MF_S_806593979_8K1JC4OG_.BKP comment=NONE
Finished Control File and SPFILE Autobackup at 05-FEB-13
Third run:
RMAN> RUN {
2>   RECOVER COPY OF DATABASE WITH TAG 'incr_backup' ;
3>   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
4> }
Starting recover at 05-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy fno=00001 name=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-SYSTEM_FNO-1_5DO179AR
recovering datafile copy fno=00002 name=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-UNDOTBS1_FNO-2_5GO179CB
recovering datafile copy fno=00003 name=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-SYSAUX_FNO-3_5EO179BK
recovering datafile copy fno=00004 name=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-USERS_FNO-4_5HO179CI
recovering datafile copy fno=00005 name=D:\ORATEMP\DEF_LOC_DATA_D-ORCL_I-1333581083_TS-EXAMPLE_FNO-5_5FO179C3
channel ORA_DISK_1: reading from backup piece D:\ORATEMP\DEF_LOC_5JO179D2_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=D:\ORATEMP\DEF_LOC_5JO179D2_1_1 tag=TAG20130205T135234
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
Finished recover at 05-FEB-13
Starting backup at 05-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental level 1 datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
input datafile fno=00003 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
input datafile fno=00005 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
input datafile fno=00002 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
input datafile fno=00004 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
channel ORA_DISK_1: starting piece 1 at 05-FEB-13
channel ORA_DISK_1: finished piece 1 at 05-FEB-13
piece handle=D:\ORATEMP\DEF_LOC_5LO179EJ_1_1 tag=TAG20130205T135323 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:26
Finished backup at 05-FEB-13
Starting Control File and SPFILE Autobackup at 05-FEB-13
piece handle=D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2013_02_05\O1_MF_S_806594029_8K1JDP83_.BKP comment=NONE
Finished Control File and SPFILE Autobackup at 05-FEB-13


Recoverability Window:

If you want to recover to three days ago you can not do from using above backup strategy
so you can alter RMAN commands to as below:

RMAN> RUN {
2> RECOVER COPY OF DATABASE WITH TAG 'incr_backup'  until time 'sysdate-3';
3> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
4> }

Now if you want to recover to 27 hours ago you can recover as below:

RMAN { set until time "to_date('03-feb-2013 03:00:00','dd-mon-yy hh:mi:ss am')";
restore database;
recover database;
}
 

Clone the database and make standby database using RMAN in Oracle 11g

CLONE DATABSE(duplicate database): Use the DUPLICATE command to create a copy of a source database. A duplicate database, is a copy of the source database with a unique DBID which RMAN generated. Because a duplicate database has a unique DBID, it is independent of the source database and can be registered in the same recovery catalog.  Following are steps of an example where sorce(target) database and clone(duplicate or auxilary instace) are on different machines.

#1. create the oracle password file in the clone database oracle_home

orapwd file=$ORACLE_HOME/dbs/prod

#2.  Take the backup of source(target) database including control file auto backup

#3 Make tns entry for source and clone (say auxilary or target or duplicate ) instance.

#4. Prepare init file of auxilary instance
# Minimum parameters file in $ORACLE_HOME/dbs/initprod at clone oracle home.
DB_NAME=prod

If source and clone db has to be in different location then optional parameters are:
DB_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK")
LOG_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK")


#5. create all directories required to start the clone or duplicate database
    like directory for diag_dest,audit_file_dest etc

#6. ftp or scp copy the backups taken at step# 2  to same locations on duplicate(clone) database node.

#7. startup the clone (auxilary) instance in nomount mode at clone db node

# Backup files are in matching location to that on the source server.
# Duplicate database to TARGET's current state.
DUPLICATE TARGET DATABASE TO prod
SPFILE
NOFILENAMECHECK;

# Duplicate database to TARGET's state 4 days ago.
DUPLICATE TARGET DATABASE TO DB11G
  UNTIL TIME 'SYSDATE-4'
  SPFILE
  NOFILENAMECHECK;

# Backup files are in a different location to that on the source server.
# Duplicate database to the most recent state possible using the provided backups.
# Works with just an AUXILIARY connection only.
DUPLICATE DATABASE TO DB11G
  SPFILE
  BACKUP LOCATION '/source/app/oracle/fast_recovery_area/DB11G'
  NOFILENAMECHECK;

STANDBY DATABASE:  A standby database, which is a special copy of the source database (called a primary database in a Data Guard environment) that is updated by applying archived redo logs from the primary database. A standby database does not get a new DBID.
steps for creating standby database using RMAN are similar to steps for creating duplicate(clone) database.
To create a standby database with the DUPLICATE command you must connect as target to the primary database and specify the FOR STANDBY option.

A database in a Data Guard environment is uniquely identified by means of the DB_UNIQUE_NAME parameter in the initialization parameter file. TheDB_UNIQUE_NAME must be unique across all the databases with the same DBID for RMAN to work correctly in a Data Guard environment.

Recovery of a Standby Databas By default, RMAN does not recover the standby database after creating it. RMAN leavesthe standby database mounted, but does not place the standby database in manual or managed recovery mode.

Use the DORECOVER option of the DUPLICATE command to specify that RMAN should recover the standby database. RMAN performs the following steps after creating the standby database files: 

1.RMAN begins media recovery. If recovery requires archived redo log files, and if the log files are not already on disk, then RMAN attempts to restore backups.

2. RMAN recovers the standby database to the specified time, system change number (SCN), or log file sequence number, or to the latest archived redo log file generated if none of the preceding are specified.

3. RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode. 

simple example : DUPLICATE TARGET DATABASE FOR STANDBY DO RECOVER
           NOFILENAMECHECK;

NOFILENAMECHECK: prevents RMAN from checking whether the datafiles and online redo logs files of the source database are in use when the source database files share the same names as the duplicate database files (see Example 2-73). You are responsible for determining that the duplicate operation will not overwrite useful data. This option is necessary when you are creating a duplicate database in a different host that has the same disk configuration, directory structure, and filenames as the host of the source database. For example, assume that you have a small database located in the /dbs directory of host1:
/oracle/dbs/system_prod1.dbf
/oracle/dbs/users_prod1.dbf
/oracle/dbs/rbs_prod1.dbf
Assume that you want to duplicate this database to host2, which has the same file system /oracle/dbs/*, and you want to use the same filenames in the duplicate database as in the source database. In this case, specify the NOFILENAMECHECK option to avoid an error message. Because RMAN is not aware of the different hosts, RMAN cannot determine automatically that it should not check the filenames.

If duplicating a database on the same host as the source database, then make sure that NOFILENAMECHECK is not set. Otherwise, RMAN may signal the error.

Active Database Duplication: Beginning from Oracle 11g it has ability to create duplicate databases directly without the need for a backup,known as active database duplication. Its requirement is source database have to be in ARCHIVELOG mode..Both the source and destination database servers require a "tnsnames.ora" entry for the destination database.

Using the DUPLICATE Command to Create a Standby Database:
1. Creating a Standby Database with Active Database Duplication  (available from 11g)

DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER
  SPFILE
    SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
    SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
     VALID_FOR=(online_logfile,primary_role)"
    SET FAL_CLIENT="inst3" COMMENT "Is standby"
    SET FAL_SERVER="inst1" COMMENT "Is primary"

  NOFILENAMECHECK;

2. Creating a Standby Database with Backup-Based Duplication

DUPLICATE TARGET DATABASE
  FOR STANDBY
  DORECOVER
  SPFILE
    SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
    SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
     VALID_FOR=(online_logfile,primary_role)"
    SET FAL_CLIENT="inst3" COMMENT "Is standby"
    SET FAL_SERVER="inst1" COMMENT "Is primary"
  NOFILENAMECHECK;

Other examples:

Copying the Server Parameter File in Active Database Duplication

RMAN> CONNECT TARGET SYS@prod

target database Password: password
connected to target database: PROD1 (DBID=39525561)

RMAN> CONNECT AUXILIARY SYS@dup

auxiliary database Password: password
connected to auxiliary database: DUP1 (not mounted)

RMAN> DUPLICATE TARGET DATABASE TO dup
2> FROM ACTIVE DATABASE
3> PASSWORD FILE
4> SPFILE;

Setting New Filenames Manually for Duplication:

DUPLICATE TARGET DATABASE TO dup
  FOR STANDBY
  FROM ACTIVE DATABASE
  PASSWORD FILE
  SPFILE 
    PARAMETER_VALUE_CONVERT '/disk1', '/disk2'
    SET DB_FILE_NAME_CONVERT '/disk1','/disk2'
    SET LOG_FILE_NAME_CONVERT '/disk1','/disk2'
    SET SGA_MAX_SIZE 200M
    SET SGA_TARGET 125M;

references: oracle doc1
                 oracle doc2
                 oracle base
                      

block corruption using RMAN in oracle,also simulate block corruption

Check and repair physical and logical block corruption :

Block corruption errors are not detected in oralce until you run dbv,RMAN,analyze or export command etc. As a DBA you can proactively monitor the block corruptions in Oracle using RMAN. Further you can recover these block corruptions using RMAN with little efforts using healthy RMAN or user managed backup. If you are using user managed backup then this will need to be cataloged in oracle using catalog datafilecopy 'datafile_path_name'

When you take RMAN backup using backupset or backup image copy or run RMAN validate command it automatically checks for physical block corruptions(media blcok corruptions, hard corruption) and RMAN aborts at the first block corruption it encounters. You may want RMAN to check completely, in this case you need to allow RMAN explicitly for N number of block corruptions it encounters.

RUN { set maxcorrupt for datafile 1,2,3 ,4 to 200;
                  backup validate database;}

Since oracle 9i and onward we always have a default channel so there is no need to allocate one.

check physical as well as logical block corruption(software corruption):

RUN { set maxcorrupt for datafile 1,2,3 ,4 to 200;
          backup validate check logical database;}

Above commands mark the blocks as corrupt similar to dbv and populated v$database_block_corruption.
V$database_block_corruption gives you the file number of the datafiles that contain the corruption, and will provide the block number at which it starts and the number of blocks corrupted. You can find the object(s) affected by this corruption in the dba_segments view. using the provided values for file_id & block_id. Don't forget to check the indexes or constraints for any affected objects.

SQL> select * from v$database_block_corruption;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
4 756652 1 5.5157E+12 CORRUPT

select segment_name, segment_type, owner

from dba_extents
where file_id = 4
and 756652 between block_id
and block_id + blocks -1;

no rows selected

Question is is corrupted block the free block ?

 [ create table block_corr as select file#,block# from V$DATABASE_BLOCK_CORRUPTION where 1=0;

create unique index bcorr_pk on block_corr(file#,block#);
insert into block_corr select file#,block# from V$DATABASE_BLOCK_CORRUPTION order by file#,block#;

create table corr_objects as
SELECT de.segment_type, de.owner, de.segment_name, de.PARTITION_NAME
FROM dba_extents de, block_corr bc
WHERE de.file_id = bc.file#
and bc.block# between block_id AND block_id + blocks - 1
group by de.segment_type, de.owner, de.segment_name, de.PARTITION_NAME;
 ]

Next run this statement to identify the objects associated with corruption:

SQL> SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
- greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id = c.block#;

OWNER SEGMENT_TYPE SEGMENT_NAME PARTITION_NAME FILE#
---------- -------------------- -------------------- --------------- ----------
CORR_START_BLOCK# CORR_END_BLOCK# BLOCKS_CORRUPTED D
----------------- --------------- ---------------- -

TEST INDEX XXXXXXXXXXXX 62
ME_IDX
292779 292779 1

If the block does not belong to any object there is nothing to do, nothing to care, the block will be reformatted when it will be reallocated.

SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
- greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks - 1
AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
, header_block corr_start_block#
, header_block corr_end_block#
, 1 blocks_corrupted
, 'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
, greatest(f.block_id, c.block#) corr_start_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
- greatest(f.block_id, c.block#) + 1 blocks_corrupted
, 'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks - 1
AND f.block_id + f.blocks - 1 >= c.block#
order by file#, corr_start_block#;

OWNER SEGMENT_TYPE SEGMENT_NAME
------------------------------ ------------------ ---------------------------------------------------------------------------------
 PARTITION_NAME FILE# CORR_START_BLOCK# CORR_END_BLOCK# BLOCKS_CORRUPTED DESCRIPTION
------------------------------ ---------- ----------------- --------------- ---------------- --------------

4 756652 756652 1 Free Block

Note: DBMS_REPAIR does not recover the blocks , rather it marks the corrupted blocks as fixed so these blocks are skipped in read/write operation. Data in these blocks are lost forever.

Other examples:

# Check for physical and logical corruption of a tablespace.
RMAN { VALIDATE CHECK LOGICAL TABLESPACE USERS;}

# Check for physical corruption of all archived redo logs files.
VALIDATE ARCHIVELOG ALL;

# Check for physical and logical corruption of the controlfile.
VALIDATE CHECK LOGICAL CURRENT CONTROLFILE;

# Check for physical and logical corruption of a specific backupset.
VALIDATE CHECK LOGICAL BACKUPSET 3;

# Check for physical corruption of files to be backed up.
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

# Check for physical and logical corruption of files to be backed up.
BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

# Check for physical corruption of files to be restored.
RESTORE VALIDATE DATABASE;

# Check for physical and logical corruption of files to be restored.
RESTORE VALIDATE CHECK LOGICAL DATABASE;

Repair block corruption: RMAN can be used to recover corrupted blocks online.Without block media recovery, if even a single block is corrupt, then you must take the datafile offline and restore a backup of the datafile. You must apply all redo generated for the datafile after the backup was created. The entire file is unavailable until media recovery completes. With block media recovery, only the blocks actually being recovered are unavailable during the recovery.

Repairing All Block Corruption in the Database: Follwing runs a backup validation to populate V$DATABASE_BLOCK_CORRUPTION, then repairs any corrupt blocks recorded in the view:

RUN {
BACKUP VALIDATE CHECK LOGICAL DATABASE;
BLOCKRECOVER CORRUPTION LIST;}

OR

RECOVER CORRUPTION LIST;

Note: RMAN block media recovery required enterprise edition. 

Alternate 1 : following repairs all physically corrupted blocks recorded in the view:
 BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME 'SYSDATE - 7';

Other examples #1 Recovering a Group of Corrupt Blocks: This recovers corrupt blocks in three datafiles:

BLOCKRECOVER DATAFILE 2 BLOCK 12, 13 DATAFILE 3 BLOCK 5, 98, 99 DATAFILE 4 BLOCK 19;

#2 Limiting Block Media Recovery by Type of Restore:
following  recovers a series of blocks and restores only from datafile copies:

RUN {
BLOCKRECOVER DATAFILE 3 BLOCK 2,3,4,5 TABLESPACE sales DBA 4194405, 4194409, FROM DATAFILECOPY; }

#3 Limiting Block Media Recovery by Backup Tag:
This recovers blocks and restores only from the backup with the tag weekly_backup:

BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 FROM TAG "weekly_backup";

#4 Limiting Block Media Recovery by Time: Following  recovers two blocks in the SYSTEM tablespace. It restores only from backups that could be used to recover the database to a point two days ago:

BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 RESTORE UNTIL TIME 'SYSDATE-2';

References: 1
                  2
                  3
                  4
 finding corrupted blocks in detail

It was all about physical and logical block corruption but But what about when the data itself is "corrupted" but the block is fine? I'm not talking about a logical or application oriented corruption rather a corruption that happens when there is a "Lost Write." In versions 11.1 (Oracle says it is now corrected for 11.2 onwards) and earlier it was possible for dbwr process to get a write acknowledgement of the write when in fact it did not happen. Of course this isn't Oracle's fault, but try explaining that to your manager/director weeks or months later when a data corruption is encountered and you don't know where it came from! Check it out in the "Backup and Recovery User's Guide" as well as the parameter DB_LOST_WRITE_PROTECT.  The best protection is using Data Guard.

reference: db lost write
asl tom about db lost write & protection

Simulate block corruption in oracle:
select segment_name , header_file , header_block
from dba_segments
where segment_name = 'table_to_be_corrupted' and owner = 'user_name';

SEGMENT_NAME HEADER_FILE HEADER_BLOCK
---------------------------- ----------- ------------
table1                              8                          19

Lets corrupt block 20 using the dd command in Linux. For windows use ultra edit editor in hexa mode

DISCLAIMER: The dd command given below is just for learning purposes and should only be used on testing systems. I will not take any responsibility of any consequences or loss of data caused by this command.

$dd of=ts_corrupt01.dbf bs=8192 conv=notrunc seek=20 << EOF
Make it Corrupt.
EOF

11g Active Standby Database Automatic Block Corruption Repair(reference: Gavin Soorma)


In addition to the real time query capability of the 11g Active Data Guard feature, we can also add to our high availability capability by using the Automatic Block Media Repair feature whereby data block corruptions on the Primary database can be repaired by obtaining those blocks from the standby site – all performed by a background process (ABMR) transparent to the application. The same functionality can be used to repair block corruptions on the Active Standby site by applying blocks which are conversely now received from the Primary site.