2012-11-21 11gR2 "Backup and Recovery User's Guide" page 301 - 394

 

 

Physical and Logical Block Corruption -- 物理坏块和逻辑坏块
In a physical corruption, which is also called a media corruption, the database does
not recognize the block at all: the checksum is invalid, the block contains all zeros, or
the header and footer of the block do not match.
--物理坏块也就是说数据库不认为它是一个正确的块

 

In a logical corruption, the contents of the block are logically inconsistent. Examples of
logical corruption include corruption of a row piece or index entry. If RMAN detects
logical corruption, then it logs the block in the alert log and server session trace file.
--逻辑坏块，里面的行片和索引键损坏

 

Detection of Block Corruption -- 坏块的探测
Oracle Database supports different techniques for detecting, repairing, and monitoring
block corruption. The technique depends on whether the corruption is interblock
corruption or intrablock corruption. In intrablock corruption, the corruption occurs
within the block itself. This corruption can be either physical or logical. In an
interblock corruption, the corruption occurs between blocks and can only be logical.
--INTERBLOCK偏向于逻辑，而INTRABLOCK偏向于物理

 

 

To determine whether datafiles require media recovery: -- 确定需要恢复的文件

Query V$DATAFILE_HEADER to determine the status of your datafiles. Run the
following SQL statements to check the datafile headers:
SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME
FROM V$DATAFILE_HEADER
WHERE RECOVER = 'YES'
OR (RECOVER IS NULL AND ERROR IS NOT NULL);

 

Optionally, query V$RECOVER_FILE to list datafiles requiring recovery by datafile
number with their status and error information. For example, execute the
following query:
SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM V$RECOVER_FILE;

Alternatively, you can use a SQL query to determine the log sequence number that
contains the target SCN and then recover through this log. For example, run the
following query to list the logs in the current database incarnation (sample output
included):
--在进行数据恢复的时候，你可以查出日志与SCN号的对应关系

SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#
FIRST_TIME, NEXT_CHANGE#
FROM V$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# =
( SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION
WHERE STATUS = 'CURRENT');

RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG
---------- ---------- ---------- ---------- ---------- --------- ----------
1 344890611 1 1 20037 24-SEP-05 20043
2 344890615 1 2 20043 24-SEP-05 20045
3 344890618 1 3 20045 24-SEP-05 20046

Missing Redo During Block Recovery -- 在块恢复的过程中丢失REDO
When RMAN first detects missing or corrupt redo records during block media
recovery, it does not immediately signal an error because the block undergoing
recovery may create a new one later in the redo stream. When a block is recreated, all
previous redo for that block becomes irrelevant because the redo applies to an old
incarnation of the block.
 -- 即便在块恢复的过程中，找不到可以应用的REDO，它也未必就会失败，因为接下来可能会有其他“动作”，
举个例子，比如在随后的日志中，坏块所在的那张表被删除，那么对ORACLE来说，它可以重新CREATE一个新块给接下去
的对象使用，所以此刻的坏块REDO的丢失不影响新块的使用，它照样可以RECOVER下去。