Handling Oracle Block Corruptions (Doc ID 28814.1) 处理Oracle块损坏

PURPOSE  目的

Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g/12c    处理Oracle块损坏

DETAILS

Introduction  介绍

This article discusses how to handle one or more block corruptions on an Oracle datafile and describes the main actions to take to deal with them. Please read the complete article before taking any action.  本文讨论了如何处理Oracle数据文件上的一个或多个块损坏，并介绍了应对这些损坏的主要措施。请先阅读完整的文章，然后再采取任何措施。
This note does not cover memory corruption issues (typically ORA-600 [17xxx] type errors).  本说明不涵盖内存损坏问题（通常为ORA-600 [17xxx]类型错误）。

Note: If the problem is an ORA-1578 on STARTUP then please contact Oracle Support Services for advice.   注意：如果问题是STARTUP时的ORA-1578，请联系Oracle支持服务以获取建议。

This article can be referred from many places for many forms of error - it is important to have the following information for each corrupt block:  可以从许多地方引用本文，以了解多种形式的错误-每个损坏的块都有以下很重要信息：

• An absolute FILE NUMBER of the file containing the corrupt block.  包含损坏块的文件的绝对文件号。
  Referred to as "&AFN" in this article.  在本文中称为"&AFN"。
• The file name of the file containing the corrupt block.   包含损坏块的文件的文件名。
  Referred to as "&FILENAME" in this article.  在本文中称为"&FILENAME"。
  If the FILE NUMBER is known but not its name then V$DATAFILE can be used to get the file name:  如果知道文件号而不知道文件名，则可以使用V$DATAFILE来获取文件名：

  SELECT name FROM v$datafile WHERE file#=&AFN;

   If the file number does not appear in V$DATAFILE in Oracle8i
  AND &AFN is greater than the DB_FILES parameter value then it is probably a TEMPFILE. In this case the filename can be found using:    如果文件号未出现在Oracle8i的V$DATAFILE中，并且＆AFN大于DB_FILES参数值，则它可能是TEMPFILE。 在这种情况下，可以使用以下命令找到文件名：

  SELECT name FROM v$tempfile WHERE file#=(&AFN - &DB_FILES_value);

   

• The BLOCK NUMBER of the corrupt block in that file.   该文件中损坏块的块号。
  Referred to as "&BL" in this article.   在本文中称为"&BL"。
• The tablespace number and name containing the affected block.   包含受影响块的表空间编号和名称。
  Referred to as "&TSN" (tablespace number) and "&TABLESPACE_NAME" in this article.  在本文中称为"&TSN"（表空间号）和"&TABLESPACE_NAME"。
   If they are not known then they can be found using:   如果它们未知，则可以使用以下命令找到它们：

  SELECT ts# "TSN" FROM v$datafile WHERE file#=&AFN;
  SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN;

   

• The block size of the tablespace where the corruption lies.   损坏块所在的表空间的块大小。
  Referred to as "&TS_BLOCK_SIZE" in this article.   在本文中称为"&TS_BLOCK_SIZE"。

  SELECT block_size FROM dba_tablespaces
  WHERE tablespace_name =
  (SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN);

   

For Oracle 7, 8.0 and 8.1 every tablespace in the database has the same block size.  For these versions, execute "SHOW PARAMETER DB_BLOCK_SIZE" and use this value as the &TS_BLOCK_SIZE.   对于Oracle 7、8.0和8.1，数据库中的每个表空间都具有相同的块大小。  对于这些版本，执行"SHOW PARAMETER DB_BLOCK_SIZE"并将此值用作&TS_BLOCK_SIZE。

Example: For the ORA-1578 error:    示例：对于ORA-1578错误：

ORA-01578: ORACLE data block corrupted (file # 7, block # 12698)
ORA-01110: data file 22: '/<path>/<datafilename>.dbf'

then:

&AFN        is "22"     (from the ORA-1110 portion of the error)
&RFN        is "7"      (from the "file #" in the ORA-1578)
&BL         is "12698"  (from the "block #" in the ORA-1578)
&FILENAME   is '/<path>/<datafilename>.dbf'
&TSN etc..  should be determined from the above SQL

   For other errors (ORA-600 , ORA-1498 etc...) the above values should either be given by Oracle Support, or be given from the article which covers the relevant error.
   对于其他错误(ORA-600 , ORA-1498 etc...) ，以上值应该由Oracle支持人员提供，或者从涵盖相关错误的文章中给出。
   Some errors, such as ORA-1410 "invalid ROWID" , ORA-12899 "value too large for column" etc.., do not give details of the corrupt file / block. For such cases Note:869305.1 may help in locating the corrupt row.   某些错误，例如ORA-1410 "invalid ROWID"，ORA-12899 "value too large for column" 等，并未给出损坏的文件/块的详细信息。对于此类情况，Note:869305.1可能有助于查找损坏的行。  参考文章：https://blog.csdn.net/u010692693/article/details/103064339

Overview of Steps to handle a Corruption   处理损坏块的步骤概述

There are many possible causes of a block corruption including:    造成区块损坏的原因很多，其中包括：

• • Bad IO hardware / firmware    硬件/固件错误
  • OS problems   操作系统问题
  • Oracle problems   Oracle问题
  • Recovering through "UNRECOVERABLE" or "NOLOGGING" database actions  通过"UNRECOVERABLE" or "NOLOGGING"数据库操作进行恢复
    (in which case ORA-1578 is expected behaviour - see below)   在这种情况下，预期的行为是ORA-1578-参见下文）

The point in time when an Oracle error is raised may be much later than when any corruption initially occurred.  引发Oracle错误的时间点可能比最初发生任何损坏的时间要晚得多。

As the root cause is not usually known at the time the corruption is encountered, and as in most cases the key requirement is to get up and running again, then the steps used tackle corruption problems in this article are:  由于在遇到损坏时通常不知道根本原因，并且在大多数情况下，关键的要求是重新启动并再次运行，因此本文中用于解决损坏问题的步骤为：

1. Determine the extent of the corruption problems and also determine if the problems are permanent or transient.  确定损坏问题的程度，并确定问题是永久的还是暂时的。

   If the problem is widespread or the errors move about then focus on identifying the cause first (check hardware etc..). This is important as there is no point recovering a system if the underlying hardware is faulty.  如果问题很普遍或错误四处蔓延，则应首先集中于确定原因（检查硬件等）。这很重要，因为如果基础硬件出现故障，则无法恢复系统。

2. Replace or move away from any faulty or suspect hardware.    更换或远离任何有故障或可疑的硬件。
3. Determine which database objects are affected.   确定哪些数据库对象受到影响。
4. Choose the most appropriate database recovery / data salvage option.   选择最合适的数据库恢复/数据抢救选项。

For all steps above it is sensible to collect evidence and document exactly what actions are being taken. The 'Evidence>>' tags in this article list the information which should be collected to assist with identifying the root cause of the problem.  对于上述所有步骤，明智的是收集证据并准确记录正在采取的措施。本文中的“证据>>”标记列出了应收集的信息，以帮助识别问题的根本原因。

Corruption due to NOLOGGING or UNRECOVERABLE   

由于NOLOGGING or UNRECOVERABLE 而导致的损坏

If a NOLOGGING (or UNRECOVERABLE) operation is performed on an object and the datafile containing that object is subsequently recovered then the data blocks affected by the NOLOGGING operation are marked as corrupt and will signal an ORA-1578 error when accessed.    如果对某个对象执行了NOLOGGING (or UNRECOVERABLE)操作，并且随后恢复了包含该对象的数据文件，则受NOLOGGING操作影响的数据块将标记为损坏，并且在访问时将发出ORA-1578错误信号。
In Oracle8i and greater an ORA-26040 is also signalled ("ORA-26040: Data block was loaded using the NOLOGGING option" ) which makes the cause fairly obvious, but earlier releases have no additional error message. If a block is corrupt due to recovery through a NOLOGGING operation then use this article from  Section 3 "Information to Record for Each Corruption" onwards but note that:   在Oracle8i及更高版本中，还会发出ORA-26040信号("ORA-26040: Data block was loaded using the NOLOGGING option" )，这使得原因显而易见，但是早期版本没有其他错误消息。如果由于通过NOLOGGING操作进行恢复而导致某个块损坏，请使用  第3节“每次损坏的记录信息”开始的本文，但请注意：

1. Recovery cannot retrieve the NOLOGGING data    恢复无法检索NOLOGGING数据
2. No data is salvagable from inside the block    块内部无数据可回收

      Solution

      For Solution reference Note:794505.1    解决方案参考 Note:794505.1   或参考文章 https://blog.csdn.net/u010692693/article/details/103065246

(1) Determine the Extent of the Corruption Problem  确定损坏问题的程度

Reference Note 836658.1 for identifying the corruption extension.  It is a good idea to scan affected files (and any important files) with RMAN or DBVERIFY to check for other corruptions in order to determine the extent of the problem. For details of using DBVERIFY see Note:35512.1   有关识别损坏扩展的参考Note 836658.1。  最好使用RMAN或DBVERIFY扫描受影响的文件（和所有重要文件），以检查其他损坏，以确定问题的严重程度。有关使用DBVERIFY的详细信息，请参见Note 836658.1

Whenever a corruption error occurs note down the FULL error message/s and look in the instance's alert log and trace files for any associated errors. It is important to do this first to assess whether this is a single block corruption, an error due to an UNRECOVERABLE operation or a more severe issue.   每当发生损坏错误时，记下完整错误消息，并在实例的alert log和trace文件中查找是否有任何相关的错误。首先必须执行此操作，以评估这是单个块损坏，由于UNRECOVERABLE操作导致的错误还是更严重的问题，这一点很重要。

Once that a list of corrupt file/block combinations has been determined then the steps below can be used to help in what action can be taken.   一旦确定了损坏的文件/块组合的列表，则可以使用以下步骤来帮助采取措施。

Evidence:     证据

• Record the original error in full, along with details of the application which encountered the error.   完整记录原始错误，以及遇到错误的应用程序的详细信息。
• Save an extract from the alert log from a few hours before the FIRST recorded problem up to the current point in time.   从FIRST记录的问题开始到当前时间为止的几个小时内，保存alert log日志的摘要。
• Save any tracefiles mentioned in the alert log.  保存alert日志中提到的所有trace文件。
• Record any recent OS problems encountered.  记录最近遇到的所有操作系统问题。
• Note if using any special features - Example: ASYNC IO, fast write disk options etc..  请注意是否使用任何特殊功能-例如：ASYNC IO，快速写入磁盘选项等。
• Record the current BACKUP position (Dates, Type etc...)   记录当前的备份位置（日期，类型等）
• Note if the database is in ARCHIVELOG mode or not    请注意数据库是否处于ARCHIVELOG模式
  g: Issue "ARCHIVE LOG LIST" in SQL*Plus (or Server Manager)   

(2) Replace or Move Away from Suspect Hardware   更换或移走可疑硬件

The vast majority of corruption problems are caused by faulty hardware.   绝大多数损坏问题是由硬件故障引起的。
If there is a hardware fault or a suspect component then it is sensible to either repair the problem, or make disk space available on a separate disk sub-system prior to proceeding with a recovery option.  如果存在硬件故障或可疑组件，则在继续执行恢复选项之前先修复问题，或在单独的磁盘子系统上提供可用的磁盘空间是明智的。

One option is to move the datafiles using the following steps:   一种选择是使用以下步骤移动数据文件：

• • Make sure the file to be relocated is either OFFLINE or the instance is in the MOUNT state (not open)   确保要重定位的文件为OFFLINE或实例处于MOUNT状态（未打开）
  • Physically restore (or copy) the datafile to its new location   将数据文件物理restore (or copy)到新位置
    example: /newlocation/myfile.dbf
  • Tell Oracle the new location of the file.  告诉Oracle文件的新位置
    example: ALTER DATABASE RENAME FILE '/oldlocation/myfile.dbf' TO '/newlocation/myfile.dbf';
        (Note that a TEMPFILE cannot be renamed - TEMPFILEs should be dropped and recreated at the new location)   （请注意，TEMPFILE无法重命名-TEMPFILE应该删除并在新位置重新创建）

IMPORTANT:  If there are multiple errors (which are NOT due to NOLOGGING)   重要提示： 如果存在多个错误（不是由于NOLOGGING引起的）
            OR   There are OS level errors against the affected file   或者针对受影响的文件存在操作系统级别的错误
            OR   The errors are transient and keep moving about   或者这些错误是暂时性的并且一直在继续发展
    then there is little point proceeding until the underlying problem has been addressed or space is available on alternative disks.   那么在解决了基本问题或空间不足之前，几乎没有任何进展。在备用磁盘上可用。
    Get the hardware vendor to check the system over and contact Oracle Support with details of all errors.  请硬件供应商检查系统，并联系Oracle支持人员以获取所有错误的详细信息。
Please note: Whilst a failed hardware check is a good indication that there is a hardware issue, a successful hardware check should not be taken as proof that there is no hardware related issue - it is very  common for hardware tests to report success when there really is some underlying fault.   请注意：虽然失败的硬件检查可以很好地表明存在硬件问题，但是成功的硬件检查不能作为不存在与硬件相关的问题的证据-硬件测试通常会在实际出现问题时报告成功是一些潜在的错误。

 If using any special IO options such as direct IO, async IO or similar it may be worth disabling them in order to eliminate such options as a potential source of problems.   如果使用任何特殊的IO选项（例如direct IO，async IO或类似的方法），则可能需要禁用它们，以消除诸如潜在问题源之类的选项。

(3) Information to record for each Corruption   每次损坏记录的信息

It is best to determine which objects are affected BEFORE making any decisions about how to recover - this is because the corruption/s may be on object/s which can easily be re-created.    最好在决定如何恢复之前确定受影响的对象-这是因为损坏可能存在于对象上，很容易重新创建。  
Example: For a corruption on a 5 row lookup table it may be far quicker to drop and recreate the table than to perform a recovery.

示例：对于5行lookup table的损坏，删除和重新创建表的速度可能比执行恢复快得多。

For each corruption collect the information in the following table.   对于每个损坏，请收集下表中的信息。
The steps to do this are explained below.   下面说明了执行此操作的步骤。

Information to record for each Corruption  每次损坏记录的信息
Original Error	Absolute FILE# &AFN	Relative File# &RFN	Block# &BL	Tablespace	Segment Type	Segment Owner.Name	Related Objects	Recovery Options

 The notes below will help to fill in this table for each corruption.  以下注释将帮助您为每次损坏填写此表

1.  "Original Error"This is the error as initially reported. Eg: ORA-1578 / ORA-1110 , ORA-600 with all arguments etc..  “原始错误”这是最初报告的错误。例如：ORA-1578 / ORA-1110，带有所有自变量的ORA-600等。
2. "Absolute File#", "Relative File#" and "Block#"The File# and Block# should have been given either by the error, by Oracle Support, or by the steps in an error article which directed to this article.  “绝对文件号”，“相对文件号”和“块号”文件号和块号应该由错误信息中获得。
   In Oracle8/8i/9i/10g: The absolute and relative file numbers are often the same but can differ (especially if the database has been migrated from Oracle7). It is important to get the correct numbers for &AFN and &RFN to avoid salvaging the wrong object An ORA-1578 reports the RELATIVE file number, with the ABSOLUTE file number given in the accompanying ORA-1110 error. ORA-600 errors normally provide the absolute file number.  在Oracle8/8i/9i/10g中：绝对文件号和相对文件号通常相同，但是可以不同（特别是如果数据库已从Oracle7迁移过来）。重要的是，必须为＆AFN和＆RFN获取正确的编号，以避免挽回错误的对象。ORA-1578报告相对文件号，并在伴随的ORA-1110错误中给出绝对文件号。ORA-600错误通常提供绝对文件编号。
   The following query will show the absolute and relative file numbers for datafiles in the database:  以下查询将显示数据库中数据文件的绝对和相对文件号：

   SELECT tablespace_name, file_id "AFN", relative_fno "RFN" FROM dba_data_files;

   In Oracle8i/9i/10g:
   In addition to the notes above about Oracle8, Oracle8i onwards can have TEMPFILES.  The following query will show the absolute and relative file numbers for tempfiles in the database:   除了上面有关Oracle8的注释外，Oracle8i及以后版本还可以具有TEMPFILES。以下查询将显示数据库中tempfile的绝对和相对文件号：

   SELECT tablespace_name, file_id+value "AFN", relative_fno "RFN" FROM dba_temp_files, v$parameter WHERE name='db_files';

   In Oracle 7: Use the same file number for both the "Absolute File#" and the "Relative File#"   对“绝对文件号”和“相对文件号”使用相同的文件号
3. "Segment Type", "Owner", "Name" and "Tablespace"
   The following query provides the object TYPE , OWNER and NAME of a segment given the absolute file number "&AFN" and block number "&BL" of the corrupt block - the database must be open in order to use this query:   以下查询提供了给定段的object TYPE , OWNER and NAME，给出了损坏块的绝对文件号"&AFN"和块号"&BL"-必须打开数据库才能使用此查询：
     

   SELECT *
   FROM dba_extents
   WHERE file_id = &AFN
   and &BL between block_id AND block_id + blocks - 1;

   If the block is in a TEMPFILE the above query will return no data.   如果该块在TEMPFILE中，则上述查询将不返回任何数据。
   For TEMPFILES the "Segment Type" will be "TEMPORARY".  对于TEMPFILES，"Segment Type"将为"TEMPORARY"。
   
   If the above query does not return rows, it can also be that the corrupted block is a segment header in a Locally Managed Tablespace (LMT).  When the corrupted block is a segment header block in a LMT,  the above query produces a corruption message in the alert.log  but the query does not not fail.  In that case use this query:   如果上述查询未返回行，则也可能是损坏的块是本地管理表空间（LMT）中的段头。当损坏的块是LMT中的段标头块时，上述查询会在alert.log中产生一条损坏消息，但查询不会失败。在这种情况下，请使用以下查询：

   SELECT owner, segment_name, segment_type, partition_name
   FROM dba_segments
   WHERE header_file = &AFN
   and header_block = &BL;

(4) Which Object is affected and possible Recovery options:   

     受影响的对象以及可能的恢复选项：

The related objects and recovery options which can be used depend on the SEGMENT_TYPE. The additional queries and possible recovery options are listed below for each of the most common segment types
可以使用的相关对象和恢复选项取决于SEGMENT_TYPE。下面列出了每种最常见的细分类型的其他查询和可能的恢复选项
CACHE        
CLUSTER     
INDEX PARTITION     
INDEX         
LOBINDEX         
LOBSEGMENT
ROLLBACK             
TABLE PARTITION        
TABLE
TEMPORARY
IOT
TYPE2 UNDO     
Some other Segment Type
"no rows" from the query

CACHE    

    If the segment type is CACHE, recheck what have been entered and if the SQL / parameters are correct.

     如果段类型为CACHE，请重新检查已输入的内容以及SQL / parameters是否正确。
          
Solution:

Repair the Block with RMAN Block Media Recovery      使用RMAN块介质恢复修复块

CLUSTER

    If the segment is a CLUSTER determine which tables it contains.    如果该段是CLUSTER，则确定它包含哪些表。

Example:  SELECT owner, table_name FROM dba_tables WHERE owner='&OWNER' AND cluster_name='&SEGMENT_NAME';

Solution:

Repair the Block with RMAN Block Media Recovery    使用RMAN块介质恢复修复块

OR 

Salvage data from all tables in the CLUSTER then recreate the CLUSTER and all its TABLES. If the OWNER is "SYS" then contact Oracle support with all details.   从CLUSTER中的所有表中抢救数据，然后重新创建CLUSTER及其所有表。如果OWNER为“ SYS”，请与Oracle支持人员联系以获取所有详细信息。

      As the CLUSTER may contain a number of TABLES, it is best to collect information for each table in the cluster before making a decision.   由于CLUSTER可能包含许多TABLES，因此最好在做出决定之前为集群中的每个表收集信息。
 

INDEX PARTITION

    If the segment is an INDEX PARTITION note the PARTITION NAME and OWNER and then determine which partition is affected, example:    如果该段是INDEX PARTITION，请记下PARTITION NAME和OWNER，然后确定受影响的分区，例如：

SELECT *
FROM   dba_extents
WHERE  file_id = &AFN AND &BL BETWEEN block_id AND block_id + blocks - 1

Solution:

Repair the Block with RMAN Block Media Recovery       使用RMAN块介质恢复修复块

OR

Index partitions can be rebuilt using:      可以使用以下方法重建索引分区：

ALTER INDEX xxx REBUILD PARTITION ppp;    

     (take care with the REBUILD option as described in "Recreating Indexes" below)   （请按照下面"Recreating Indexes"中的说明使用REBUILD选项）

INDEX

    Find out which table the INDEX is on:   找出INDEX在哪个表上：

SELECT table_owner, table_name
FROM   dba_indexes
WHERE  owner='&OWNER' AND index_name='&SEGMENT_NAME';

 Possible values for CONSTRAINT_TYPE are:    CONSTRAINT_TYPE的可能值为
    -  P    The index supports a primary key constraint.      索引支持主键约束
    -  U    The index supports a unique constraint.        索引支持唯一约束
    If the INDEX supports a PRIMARY KEY constraint (type "P") then check if the primary key is referenced by any foreign key constraints:   如果INDEX支持PRIMARY KEY约束(type "P")，则检查主键是否被任何外键约束引用：

SELECT owner, constraint_name, constraint_type, table_name
FROM dba_constraints
WHERE r_owner='&TABLE_OWNER' AND r_constraint_name='&INDEX_NAME';

Solution:   

Repair the Block with RMAN Block Media Recovery      使用RMAN块介质恢复修复块

OR 

Recreate the Index (with any associated constraint disables/enables). If the OWNER is "SYS" then contact Oracle support with all details.   重新创建索引（使用任何关联的约束禁用/启用）。如果OWNER为"SYS"，请与Oracle支持人员联系以获取所有详细信息。   

ROLLBACK

If the segment is a ROLLBACK segment contact Oracle support as rollback segment corruptions require special handling.

如果该段是ROLLBACK段，请联系Oracle支持，因为回滚段损坏需要特殊处理。

Solution:

Repair the Block with RMAN Block Media Recovery        使用RMAN块介质恢复修复块

YPE2 UNDO

TYPE2 UNDO is a system managed undo segment which is a special form of rollback segment. Corruptions in these segments require special handling.   TYPE2 UNDO是系统管理的撤消段，它是回滚段的一种特殊形式。这些部分的损坏需要特殊处理。

Solution:

Repair the Block with RMAN Block Media Recovery     使用RMAN块介质恢复修复块

TABLE PARTITION

If the segment is a TABLE PARTITION note the NAME and OWNER and then determine which partition is affected thus:

如果该段是TABLE PARTITION，请记下NAME和OWNER，然后确定受影响的分区是：

SELECT partition_name
FROM dba_extents
WHERE file_id = &AFN
AND &BL BETWEEN block_id AND block_id + blocks - 1;

then continue below as if the segment was a TABLE segment.    然后继续下去，就好像该段是TABLE段一样。 

Solution:

Repair the Block with RMAN Block Media Recovery       使用RMAN块介质恢复修复块

OR

If all corruptions are in the same partition then one option at this point is to EXCHANGE the corrupt partition with an empty TABLE - this can allow the application to continue (without access to the data in the corrupt partition) whilst any good data can then be extracted from the table.    如果所有损坏都在同一个分区中，则此时的一种选择是用空的TABLE交换损坏的分区-这可以使应用程序继续运行（而无需访问损坏的分区中的数据），而随后可以将任何良好的数据从表中提取。
For other options see the TABLE options below.    有关其他选项，请参见下面的TABLE选项。

TABLE

If the OWNER is "SYS" then contact Oracle support with all details.   如果OWNER为"SYS"，请与Oracle支持人员联系以获取所有详细信息。
The database is likely to require recovery.   该数据库可能需要恢复。

For a non-dictionary TABLE or TABLE PARTITIONs find out which iNDEXES exist on the TABLE:

对于非字典表或表分区，找出表上存在哪些INDEXES：

 

Example:  SELECT owner, index_name, index_type
          FROM dba_indexes
          WHERE table_owner='&OWNER'
          AND table_name='&SEGMENT_NAME';

and determine if there is any PRIMARY key on the table:   并确定表上是否有PRIMARY key：

Example: SELECT owner, constraint_name, constraint_type, table_name
         FROM dba_constraints
         WHERE owner='&OWNER'
         AND table_name='&SEGMENT_NAME'
         AND constraint_type='P';

If there is a primary key then check if this is referenced by any foreign key constraints:   如果有主键，则检查是否有外键约束引用了该主键：

 Example: SELECT owner, constraint_name, constraint_type, table_name
          FROM dba_constraints
          WHERE r_owner='&OWNER'
          AND r_constraint_name='&CONSTRAINT_NAME';

Solution:

Repair the Block with RMAN Block Media Recovery       使用RMAN块介质恢复修复块

OR

Salvage data from the TABLE (or PARTITION).  If the OWNER is "SYS" then contact Oracle support with all details.  从TABLE (or PARTITION)中抢救数据。  如果OWNER为"SYS"，请与Oracle支持人员联系以获取所有详细信息。

THEN Recreate the table (or partition)     然后重新创建表（或分区），
OR  Leave the corruption in place            或将损坏保留在原处
(example: Use DBMS_REPAIR to mark the problem blocks to be skipped)  （例如：使用DBMS_REPAIR标记要跳过的问题块）

IOT (INDEX ORGANIZED TABLE)   索引组织部

The corruption in IOT table should be handled in the same way as in a heap or partitioned table.   IOT表中的损坏应以与heap or partitioned table中相同的方式处理。
The only exception is if the PK (Primary Key) is corrupted.   唯一的例外是PK (Primary Key)已损坏。
PK of an IOT table is the table itself and cannot be dropped and recreated.   IOT表的PK是表本身，不能删除和重新创建。

Solution:

Repair the Block with RMAN Block Media Recovery        使用RMAN块介质恢复修复块

OR

Salvage data from the TABLE (or PARTITION) and Methods of extracting data from a corrupt table AROUND a corrupt block.   If the OWNER is "SYS" then contact Oracle support with all details.   从TABLE (or PARTITION)中抢救数据以及从损坏的表周围提取数据的方法。如果OWNER为"SYS"，请与Oracle支持人员联系以获取所有详细信息。

THEN   然后
Recreate the table (or partition)      重新创建table (or partition)
OR  
Leave the corruption in place     将损坏保留在原位

(DBMS_REPAIR cannot be used with IOTs)      （DBMS_REPAIR不能与IOTs一起使用）

LOBINDEX

FInd out which table the LOB belongs to:     查找LOB属于哪个表

 SELECT table_name, column_name
 fROM dba_lobs
 wHERE owner='&OWNER'
 AND index_name='&SEGMENT_NAME';

It is not possible to rebuild LOB indexes; treat the problem as a corruption on the LOB column of the affected table.   无法重建LOB索引。将问题视为受影响的表的LOB列上的损坏。
Get index and constraint information for the table which has the corrupt LOB index using the SQL in the TABLE section, then return here.   使用TABLE部分中的SQL获取具有损坏的LOB索引的表的索引和约束信息，然后返回此处。

Solution:

Repair the Block with RMAN Block Media Recovery      使用RMAN块介质恢复修复块

OR

MOVE the LOB Segment which rebuilds the LOB index:      移动LOB段以重建LOB索引：

alter table &table_owner.&table_with_lob move LOB (&&lob_column) store as (tablespace &tablespace_name);

If the OWNER is "SYS" then contact Oracle support with all details.   如果OWNER为“ SYS”，请与Oracle支持人员联系以获取所有详细信息。

LOBSEGMENT

Find out which table the LOB belongs to:   找出LOB属于哪个表

Example:

SELECT table_name, column_name
  FROM dba_lobs
   WHERE owner='&OWNER'
   AND segment_name='&SEGMENT_NAME'; 

For non-dictionary tables (Owner != SYS) ...    对于非字典表(Owner != SYS)... 

Get index and constraint information for the table which has the corrupt LOB data using the SQL in the TABLE section, then return here to find details of the exact rows affected.   使用TABLE部分中的SQL获取具有损坏的LOB数据的表的索引和约束信息，然后返回此处以查找受影响的确切行的详细信息。

Finding the exact row which references the corrupt LOB block can be a challenge as the errors reported do not show any detail about which table row owns the lob entry which is corrupt.  找到引用损坏的LOB块的确切行可能是一个挑战，因为报告的错误未显示有关哪个表行拥有损坏的lob条目的任何详细信息。

Typically one can refer to application logs or any SQL_TRACE or 10046 trace of a session hitting the error (if available) or see if having 通常，可以参考应用程序日志或会话中任何SQL_TRACE或10046跟踪中遇到错误的trace（如果有），或者查看是否有 

event "1578 trace name errorstack level 3" 

 set in the session helps identify the current SQL/binds/row.   在会话中设置有助于确定当前的SQL/binds/row。

Eg:
ALTER SYSTEM SET EVENTS '1578 trace name errorstack level 3'; 

 Then wait for the error to be hit by the application and find the trace file.   然后等待该错误被应用程序发现并找到trace文件。

 If there are no clues then there is the option to construct a PLSQL block to scan the problem table row by row extracting the LOB column data which loops until it hits an error. Such a technique may take a while but it should be possible to get a primary key or rowid of any row which references a corrupt LOB block.   如果没有任何线索，则可以选择构造一个PLSQL块来逐行扫描问题表，提取LOB列数据，该数据将循环运行直到遇到错误为止。这种技术可能要花一些时间，但是应该可以获取引用损坏的LOB块的任何行的主键或rowid。

Example:

set serverout on
exec dbms_output.enable(100000);
declare
 error_1578 exception;
 pragma exception_init(error_1578,-1578);
 n number;
 cnt number:=0;
 badcnt number:=0;
begin
  for cursor_lob in
        (select rowid r, &LOB_COLUMN_NAME L from &OWNER..&TABLE_NAME)
  loop
    begin
      n:=dbms_lob.instr(cursor_lob.L,hextoraw('AA25889911'),1,999999) ;
    exception
     when error_1578 then
       dbms_output.put_line('Got ORA-1578 reading LOB at '||cursor_lob.R);
       badcnt:=badcnt+1;
    end;
    cnt:=cnt+1;
  end loop;
  dbms_output.put_line('Scanned '||cnt||' rows - saw '||badcnt||' errors');
end;
/

 another script more generic:    另一个更通用的脚本

set serverout on
exec dbms_output.enable(100000);
declare
  pag    number;
  len    number;
  c      varchar2(10);
  charpp number := 8132/2;

begin
  for r in (select rowid rid, dbms_lob.getlength (<your_clob_column>) len
            from   <your_table_with_clcob_column>) loop
    if r.len is not null then
      for page in 0..r.len/charpp loop
        begin
          select dbms_lob.substr (<your_clob_column>, 1, 1+ (page * charpp))
          into   c
          from   <your_table_with_clcob_column>
          where  rowid = r.rid;
       
        exception
          when others then
            dbms_output.put_line ('Error on rowid ' ||R.rid||' page '||page);
            dbms_output.put_line (sqlerrm);
        end;
      end loop;
    end if;
  end loop;
end;
/

Solution:

Repair the Block with RMAN Block Media Recovery         使用RMAN块介质恢复修复块

OR

Update the lob column with empty_clob/empty_blob to avoid ORA-1578; this is cleaning the LOB column in the table - note that the LOB is already corrupt and cannot be accessed:   使用empty_clob/empty_blob更新lob列，以避免ORA-1578; 这正在清除表中的LOB列-请注意，LOB已损坏并且无法访问：

SQL> set concat off
SQL> update &table_owner.&table_with_lob
        set &lob_column = empty_blob()
     where rowid in ('list the identified rowids from the table from the plsql above');

Setting the corrupt lob to empty lob will add the blocks formerly mapped to this lob to the freelist.  Eventually when PCTVERSION or RETENTION criteria causes the space to be salvaged and reused for new data, error ORA-1578  can be seen again in the same LOB blocks.  In that case and after applying the above procedure the lob segment can be moved to a new segment:   将损坏的lob设置为空lob会将先前映射到此lob的块添加到空闲列表。最终，当PCTVERSION或RETENTION标准导致空间被抢救并重新用于新数据时，可以在同一LOB块中再次看到错误ORA-1578。在这种情况下，在应用上述过程之后，可以将lob段移至新段：

alter table &table_owner.&table_with_lob move LOB (&&lob_column) store as (tablespace &tablespace_name);

OR   Salvage data from the TABLE (and its LOB column/s)   从表（及其LOB列）中挽救数据，
THEN Recreate the table     然后重新创建表
OR  Leave the corruption in place    或将损坏保留在原位置 
(It is not possible to use DBMS_REPAIR on LOB segments)   （无法在LOB段上使用DBMS_REPAIR）

TEMPORARY

 If the segment type is TEMPORARY then the corruption does not affect a permanent object. Check if the tablespace where the problem occurred is being used as a TEMPORARY tablespace thus:     如果段类型为TEMPORARY，则损坏不会影响永久对象。检查发生问题的表空间是否被用作TEMPORARY表空间，因此：

SELECT count(*) FROM dba_users WHERE temporary_tablespace='&TABLESPACE_NAME';

Solution:

Use Note 1332088.1

No restore is normally required, although if the disk is suspect and the tablespace contains useful data then a database recovery of the affected file/s may be wise.

通常不需要还原，尽管如果磁盘可疑并且表空间包含有用的数据，则对受影响的文件进行数据库恢复可能是明智的。

Some Other SEGMENT_TYPE 

If the segment type returned is not covered above then contact Oracle support for advice with all information collected so far.

如果上面未涵盖返回的段类型，请联系Oracle支持以获取到目前为止收集到的所有信息的建议。

"NO ROWS SELECTED" 

If there appears to be no extent containing the corrupt block then first double check the figures used in the query. If sure that the file and block are correct and do not appear as belonging to an object in DBA_EXTENTS then:    如果似乎没有范围包含损坏的块，则首先仔细检查查询中使用的数字。如果确定文件和块正确且在DBA_EXTENTS中不显示为属于对象，则：

• Double check if the file involved is a TEMPFILE.   仔细检查所涉及的文件是否为TEMPFILE。
  Note that TEMPFILE file numbers depend on the init.ora parameter DB_FILES so any changes to this parameter change the absolute file number reported in errors.   请注意，TEMPFILE文件号取决于init.ora参数DB_FILES，因此对此参数的任何更改都会更改错误报告的绝对文件号。
• DBA_EXTENTS does not include blocks which are used for local space management in locally managed tablespaces.   DBA_EXTENTS不包括用于本地管理的表空间中的本地空间管理的块。
• If the database being queried is from a different point in time to the datafile with the error then the problem object may have been dropped and so queries against DBA_EXTENTS may show no rows.  如果要查询的数据库是从另一个时间点到出现错误的数据文件，则问题对象可能已被删除，因此对DBA_EXTENTS的查询可能不会显示任何行。
• If the error being investigated was reported by DBVERIFY then DBV checks all blocks regardless of whether they belong to an object or not. It is possible for a corrupt block to exist in the datafile but in a block not in use by any segment.   如果DBVERIFY报告了正在调查的错误，则DBV会检查所有块，无论它们是否属于对象。损坏的块可能存在于数据文件中，但存在于任何段未使用的块中。

Options:   选项：

An error on an UNUSED Oracle block (listed in dba_freespace) can be ignored as Oracle will format the block once it's reused by any DML operation .  可以忽略未使用的Oracle块（在dba_freespace中列出）上的错误，因为一旦任何DML操作重用了该块，Oracle就会对其进行格式化。
Note that a simple allocation of extent does not format the block, it is also necessary for the DML operation to modify/use  the block.  注意，简单的扩展分配不会格式化该块，DML操作也必须修改/使用该块。
If you want to manually format the block you can refer How to Format Corrupted Block Not Part of Any Segment Document 336133.1   如果要手动格式化该块，请参阅How to Format Corrupted Block Not Part of Any Segment Document 336133.1

If suspected that the block may be a space management block then use DBMS_SPACE_ADMIN to help check this by running:  如果怀疑该块可能是空间管理块，请使用DBMS_SPACE_ADMIN通过运行以下命令来帮助检查：

exec DBMS_SPACE_ADMIN.TABLESPACE_VERIFY('&TABLESPACE_NAME');

 This should write inconsistencies to the trace file but if it encounters a fatally corrupt block it will report an error like: 这应该将不一致之处写入trace文件，但是如果遇到致命损坏的块，它将报告如下错误：

ORA-03216: Tablespace/Segment Verification cannot proceed 

EVIDENCE    证据

For each corrupt block it is also a good idea to collect the following physical evidence if there is a need to try and identify the actual cause of the corruption:   对于每个损坏的块，如果需要尝试找出损坏的实际原因，则收集以下物理证据也是一个好主意：

1. An operating system HEX dump of the bad block and the block either side of it.  坏块及其两侧的块的操作系统十六进制dump。
   
   On UNIX: 
    

   dd if=&FILENAME bs=&TS_BLOCK_SIZE skip=&BL-1 count=3 of=BL.dd

   Example: For BL=1224:
    

   dd if=ts11.dbf bs=4k skip=1223 count=3 of=1223_1225.dd 

   On VMS:
    

   DUMP/BLOCKS=(start:XXXX,end:YYYY)/out=dump.out &FILENAME

   Where XXXX=Operating system block number (in 512 byte chunks)   其中XXXX =操作系统块编号（以512字节块为单位）
   To calculate this multiply the block number reported by '&TS_BLOCK_SIZE/512'    要计算此值，请乘以'&TS_BLOCK_SIZE/512'报告的块编号
2. If the database is in ARCHIVELOG mode, make a safe copy of the archived log files around the time of the error, and preferably for a few hours before the error was reported. Also secure any backup/s of the problem datafile from before the errors as the before image PLUS redo can help point towards a cause.  如果数据库处于ARCHIVELOG模式，请在发生错误时，最好在报告错误之前数小时，对归档日志文件进行安全复制。还应确保从错误发生之前对问题数据文件进行任何备份，因为之前的映像PLUS重做可以帮助指出原因。
   (DBV can often be used to check if the problem exists in a backup copy of a file). The ideal scenario is to have a datafile backup image which does not have any corruption and all the redo from that point in time up to and just past the time when the corruption is first reported.   (DBV通常可用于检查文件的备份副本中是否存在问题）。理想的情况是拥有一个数据文件备份映像，该映像不存在任何损坏，并且从该时间点开始直到刚报告损坏为止的所有重做。
3. Obtain an Oracle dump of the problem block/s:   获取问题块的Oracle dump：

   ALTER SYSTEM DUMP DATAFILE '&FILENAME' BLOCK &BL;

   (The output will go to a tracefile in the USER_DUMP_DEST).  （输出将转到USER_DUMP_DEST中的tracefile）。

(5) Choosing A Recovery Option.  选择恢复选项。

The best recovery option now depends on the objects affected. The notes in Section (3) above should have highlighted the main options available for each affected object. The actual recovery method chosen may include a mix or one or more methods thus:

现在，最佳恢复选项取决于受影响的对象。上面Section (3)的注释应突出显示每个受影响对象可用的主要选项。实际选择的恢复方法可以包括混合或一种或多种方法，因此：

Recovery Required ?    需要恢复吗？

If the error is in a TEMPORARY tablespace, or is in a block which is no longer part of any database object then no action is required, although it may be wise to relocate the problem tablespace to a different storage device.   如果错误是在TEMPORARY表空间中，或者是在不再是任何数据库对象的块中，则无需采取任何措施，尽管将问题表空间重新定位到其他存储设备可能是明智的。

Is Complete Recovery an option ?     是否可以选择完全恢复？

In order for complete recovery to be an option the following must be true:   为了使完全恢复成为一种选择，必须满足以下条件：

• The database is in ARCHIVELOG mode  数据库处于ARCHIVELOG模式 

  (The "ARCHIVE LOG LIST" command shows Archivelog Mode)   （"ARCHIVE LOG LIST"命令显示归档日志模式）

• There is a good backup of the affected files.  Note that in some cases, the corruption may have been present, but undetected, for a long period of time.  If the most recent datafile backup still contains the corruption, try an earlier backup as long as all the necessary ARCHIVELOGS are available.   对受影响的文件进行了良好的备份。请注意，在某些情况下，损坏可能已经存在很长时间，但未被发现。如果最新的数据文件备份仍然包含损坏，请尝试较早的备份，只要所有必要的ARCHIVELOGS都可用。
  (DBV with the START / END options can be used to check if specific block/s in a restored copy of a backup file are corrupt)  （带有START / END选项的DBV可用于检查备份文件的已还原副本中的特定块是否损坏）

• All ARCHIVELOGS are available from the time of the backup to the current point in time   从备份时间到当前时间点，所有ARCHIVELOGS均可用

• The current online log/s are available and intact  当前的在线日志可用并且完整无缺

• The errors are NOT due to recovery through a NOLOGGING operation   错误不是由于通过NOLOGGING恢复操作导致

When the above criteria are satisfied then complete recovery is usually the preferred option  当满足上述条件时，通常首选完全恢复 

*BUT NOTE*    *注意* 

1. If the rollback of a transaction has seen a corrupt block on an object other than the rollback segment itself then UNDO may have been discarded. In this case the indexes may need to be rebuilt; check data integrity AFTER the recovery completes. 
   如果事务的回滚在除回滚段本身之外的其他对象上看到损坏的块，则可能已放弃了UNDO。在这种情况下，可能需要重建索引。恢复完成后检查数据完整性。 
2. If the files to be recovered contain data from NOLOGGING operations performed since the last backup then those blocks will be marked corrupt if datafile or database recovery is used. In some cases this can put the problem in a worse scenario than the current position.  如果要恢复的文件包含自上次备份以来执行的NOLOGGING操作的数据，则如果使用数据文件或数据库恢复，这些块将被标记为损坏。在某些情况下，这可能会使问题比目前的情况更糟。

If database recovery has already been performed and the corruption is still there then either all the backups contain the corruption, the underlying fault is still present or the problem is replaying through redo.  In these cases choose some other recovery option.  如果已经执行了数据库恢复并且损坏仍然存在，则所有备份都包含损坏，根本的故障仍然存在或问题通过redo重播。在这些情况下，请选择其他一些恢复选项。

 See "(4A) Complete Recovery" for complete recovery steps.   有关完整的恢复步骤，请参见 "(4A) Complete Recovery"。

Can the object be Dropped or Re-created without needing to extract any data from the object itself?

是否可以删除或重新创建对象而无需从对象本身提取任何数据？

It may be possible to lose the object, or to recreate it from a script / recent export.  Once an object is dropped then blocks in that object are marked as "free" and will be re-formatted when the block gets allocated to a new object. It is advisable to RENAME rather than DROP a table unless absolutely sure that the data in it is not needed.    可能会丢失该对象，或者从脚本/最近的导出中重新创建该对象。一旦删除对象，该对象中的块将被标记为“空闲”，并且在将块分配给新对象时将重新格式化。建议重命名而不是删除表，除非绝对确保不需要表中的数据。

In the case of a table partition then only the affected partition needs to be dropped.  对于表分区，则仅需要删除受影响的分区。

example: ALTER TABLE ... DROP PARTITION ...

If the corruption affects the partition segment header, or the file containing the partition header is offline, then DROP PARTITION may fail. In this case it may still be possible to drop the partition by first exchanging it with a table of the same definition. 

如果损坏影响分区段标头，或者包含分区标头的文件处于脱机状态，则DROP PARTITION可能会失败。在这种情况下，仍然可以通过首先与相同定义的表交换分区来删除该分区。

example: ALTER TABLE .. EXCHANGE PARTITION .. WITH TABLE ..;

The most common object which can be re-created is an index.   可以重新创建的最常见对象是索引。
Always address TABLE corruptions before INDEX problems on a table.   始终在表上的INDEX问题之前解决TABLE损坏的问题。
See "(4B) Recreating Indexes" for more details.  有关更多详细信息，请参见"(4B) Recreating Indexes"。

For any segment, a quick way to extract the DDL for an object, when the absolute file number and block number of the corrupt block are known, is:  对于任何段，当已知损坏块的绝对文件号和块号时，提取对象DDL的快速方法是：

set long 64000
select dbms_metadata.get_ddl(segment_type, segment_name, owner)
FROM dba_extents
WHERE file_id=&AFN
AND &BL BETWEEN block_id AND block_id + blocks -1;

Is it required to salvage data before recreating the object ?   重新创建对象之前是否需要挽救数据？

If the problem is on a critical application table which is regularly updated then it may be required to salvage as much data from the table as possible, then recreate the table.   如果问题出在定期更新的关键应用程序表上，则可能需要从表中抢救尽可能多的数据，然后重新创建表。

See "(5C) Salvaging Data from Tables" for more details.   有关更多详细信息，请参见"(5C) Salvaging Data from Tables"。

Is it acceptable to leave the corruption in place for the moment?   暂时将损坏保留在原处可以接受吗？

In some cases the best immediate option may be to leave the corruption in place and isolate it from application access.

在某些情况下，最好的立即选择是保留损坏，并将其与应用程序访问隔离。

See "(5D) Leaving the Corruption In Place" for more details.  有关更多详细信息，请参见"(5D) Leaving the Corruption In Place"。 

Last Options   最后的选择

Are any of the following possible ?     有以下几种可能吗？

Recovery to an old point-in-time (via point in time recovery)of either the database or tablespace point in time recovery

恢复到数据库或表空间时间点恢复的旧时间点（通过时间点恢复）

OR Restore of a COLD backup from before the corruption   或从损坏之前还原冷备份

OR Use of an existing export file   或使用现有的导出文件

See "(5E) Last Options" for more details.    有关更多详细信息，请参见"(5E) Last Options"。

 (5A) Complete Recovery    完全恢复

If the database is in ARCHIVELOG mode and there is a good backup of the affected files then recovery is usually the preferred option.  如果数据库处于ARCHIVELOG模式，并且已对受影响的文件进行了良好的备份，则通常首选恢复。
This is not GUARANTEED to clear a problem, but is effective for the majority of corruption issues. If recovery re-introduces the problem then return to the list of options above and choose another method.   这不能保证清除问题，但对大多数损坏问题有效。如果恢复重新引入了问题，请返回到上面的选项列表，然后选择另一种方法。

If using Oracle9i (or higher) then it may be possible to perform block level recovery using the RMAN BLOCKRECOVER command.   如果使用Oracle9i（或更高版本），则可以使用RMAN BLOCKRECOVER命令执行块级恢复。 
If using an earlier Oracle release then either perform a Datafile Recovery (which can be done while the rest of the database is still up and running), or Database Recovery (which requires the database to be taken down) .   如果使用的是较早的Oracle版本，则执行数据文件恢复（可以在数据库的其余部分仍处于运行状态时执行）或数据库恢复（要求将数据库关闭）。 

If using Oracle 11g (or higher) then it may be possible to use Data Recovery Advisor.  如果使用Oracle 11g（或更高版本），则可以使用Data Recovery Advisor。

RMAN Block Media Recovery    RMAN块介质恢复 

As of Oracle9i RMAN allows individual blocks to be recovered whilst the rest of the database (including other blocks in the datafile) are available for normal access. Note that block level recovery can only be used to recover a block fully to the current point in time.   从Oracle9i开始，RMAN允许恢复单个块，而数据库的其余部分（包括数据文件中的其他块）可用于正常访问。请注意，块级恢复只能用于将块完全恢复到当前时间点。

Example:

Consider having an ORA-1578 on file #6 block #30 which is likely due to a media corruption problem and there is a good cold backup image of that file which has been restored to '.../RESTORE/filename.dbf'.  考虑在file #6 block #30上有一个ORA-1578，这可能是由于介质损坏问题造成的，并且该文件有一个良好的冷备份映像，该映像已还原到'.../RESTORE/filename.dbf'。
Provided all archivelogs exist (in the default location) then RMAN can be used to perform a Block Media Recovery (BMR) using a command sequence like:  如果所有归档日志都存在（位于默认位置），则可以使用RMAN通过以下命令执行块介质恢复（BMR）：

rman nocatalog
  connect target
   catalog datafilecopy '.../RESTORE/filename.dbf';
      run {blockrecover datafile 6 block 30;}

This uses the registered datafile backup image and any required archivelogs to perform block recovery of just the one problem block to current point in time.  这将使用已注册的数据文件备份映像和任何必需的归档日志来仅将一个问题块执行块恢复到当前时间点。

See the documentation for full details of the RMAN BLOCKRECOVER command and limitations. See Note 144911.1 for an example and Note 342972.1 to perform Block Media Recovery when backups are not taken by RMAN.  

有关RMAN BLOCKRECOVER命令和限制的完整详细信息，请参见文档。有关示例，请参见Note 144911.1，如果RMAN不进行备份，请参见Note 342972.1以执行块介质恢复。

Datafile Recovery    数据文件恢复

Datafile recovery of a file involves the following steps. If there are several files repeat the steps for each file or see "Database Recovery" below.  These steps can be used if the database is either OPEN or MOUNTED.  恢复数据文件涉及以下步骤。如果有多个文件，请对每个文件重复步骤，或参阅下面的"Database Recovery"。如果数据库为OPEN或MOUNTED，则可以使用这些步骤。

OFFLINE the affected data file:   脱机受影响的数据文件：

ALTER DATABASE DATAFILE '&datafile_name' OFFLINE;

Copy it to a safe location (in case the backup is bad)   将其复制到安全位置（以防备份损坏）

Restore the latest backup of the file onto a GOOD disk   将文件的最新备份还原到好的磁盘上

Check the restored file for obvious corruptions with DBVERIFY   使用DBVERIFY 检查已还原的文件是否有明显损坏。
    For details of using DBVERIFY see Note:35512.1  有关使用DBVERIFY的详细信息，请参阅Note:35512.1

Assuming the restored file is OK, then RENAME the datafile to the NEW location (if different from the old location)

假设还原的文件正常，则将数据文件重命名为新位置（如果与旧位置不同）

ALTER DATABASE RENAME FILE '&old_name' TO '&new_name';

 Recover the datafile:   恢复数据文件：

RECOVER DATAFILE '&datafile_name';

 Online the file/s   在线文件

ALTER DATABASE DATAFILE '&datafile_name' ONLINE;

Database Recovery    数据库恢复

Database recovery generally involves the following steps:   数据库恢复通常包括以下步骤：

Shutdown (Immediate or Abort)

Copy the current copy of all files to be recovered to a safe location  将所有要恢复的文件的当前副本复制到安全位置

Restore the backup files to a GOOD disk location  
DO NOT RESTORE THE CONTROL FILES or ONLINE REDO LOG FILES  将备份文件还原到良好的磁盘位置请勿还原 控制文件或联机重做日志文件

Check restored files with DBVERIFY. For details of using DBVERIFY see Note:35512.1   使用DBVERIFY检查还原的文件。有关使用DBVERIFY的详细信息，请参见Note:35512.1

STARTUP MOUNT

 Rename any relocated files:   重命名所有重定位的文件：

ALTER DATABASE RENAME FILE '&old_name' TO '&new_name';

Ensure all required files are online:   确保所有必需的文件都在线：

ALTER DATABASE DATAFILE '&datafile_name' ONLINE;

 Recover the database:  恢复数据库：

RECOVER DATABASE

 Open the database:   打开数据库：

ALTER DATABASE OPEN;

After a Complete Recovery     完全恢复后

Once a complete recovery has been performed it is advisable to check the database before allowing it to be used:  一旦执行了完整的恢复，建议在允许使用数据库之前检查数据库：

Run: 

"ANALYZE &table_name VALIDATE STRUCTURE CASCADE" 

against each problem object to check for table/index mis-matches.  针对每个问题对象检查表/索引不匹配。

If there has been any UNDO discarded this may show a mismatch requiring indexes to be re-created.  如果有任何UNDO被丢弃，则可能显示不匹配，需要重新创建索引。

Check the logical integrity of data in the table at the application level.  在应用程序级别检查表中数据的逻辑完整性。

(5B) Recreating Indexes   重新创建索引

If the corrupt object is a user INDEX, simply drop and re-create it PROVIDED the underlying table is not also corrupt.   如果损坏的对象是用户INDEX，只需删除并重新创建它即可，前提是基础表也没有损坏。  
If the underlying table is also corrupt it is advisable to sort out the TABLE before recreating any indexes.  如果基础表也已损坏，建议在重新创建任何索引之前先对TABLE进行排序。

If the information collected shows that the index has dependent FOREIGN KEY constraints then something like this may be needed:   如果收集的信息表明索引具有相关的FOREIGN KEY约束，则可能需要类似以下内容：

•  for each foreign key   每个外键

  ALTER TABLE &table_name DISABLE CONSTRAINT &pk_constraint;

   

• Rebuild the primary key using   使用以下命令重建主键

  ALTER TABLE &table_name DISABLE CONSTRAINT &pk_constraint;
  DROP INDEX &index_name;
  CREATE INDEX &index_name .. with appropriate storage clause
  ALTER TABLE &table_name ENABLE CONSTRAINT &pk_constraint; 

   

• Enable the foreign key constraints  启用外键约束

  ALTER TABLE &child_table ENABLE CONSTRAINT &fk_constraint;

   

For an index partition:  对于索引分区：

ALTER INDEX ... REBUILD PARTITION ...;

Notes:

1. It is important not to REBUILD a non-partitioned corrupt index using an "ALTER INDEX ..  REBUILD" command as this will usually try to build the new index from the existing index segment, which contains a corrupt block.   重要的是不要使用"ALTER INDEX ..  REBUILD"命令来重建未分区的损坏索引，因为这通常会尝试从包含损坏块的现有索引段中构建新索引。

   "ALTER INDEX ... REBUILD ONLINE" and "ALTER INDEX ... REBUILD PARTITION ..." 

   do not build the new index from the old index segment and so can be used.  不要从旧索引段构建新索引，因此可以使用。
2. Create INDEX can use the data from an existing index if the new index is a sub-set of the columns in the existing index. Hence if there are 2 corrupt indexes drop them BOTH before re-creating them.  如果新索引是现有索引中列的子集，则Create INDEX可以使用现有索引中的数据。因此，如果有2个损坏的索引，则在重新创建它们之前将它们都丢弃。
3. Be sure to use the correct storage details when recreating indexes.  重新创建索引时，请确保使用正确的存储详细信息。

(5C) Salvaging Data from Tables  从表中抢救数据

If the corrupt object is a TABLE or CLUSTER or LOBSEGMENT then it must be understood that the data within the corrupt block is lost.    如果损坏的对象是TABLE or CLUSTER or LOBSEGMENT，则必须理解损坏块中的数据会丢失。
Some of the data may be salvageable from a HEX dump of the block, or from columns covered by indexes.  某些数据可从块的十六进制dump或索引覆盖的列中抢救。

Important:  重要说明：
As it may be required to salvage data in the corrupt block from the indexes it is a good idea NOT to drop  any existing index until any required data has been extracted  由于可能需要从索引中挽救损坏的块中的数据，因此最好不要在提取任何所需数据之前删除任何现有索引

There are many ways to get data out of a table which contains a corrupt block. Choose the most appropriate method as detailed below. The aim of these methods is to extract as much data as  possible from the table blocks which can be accessed. It is  usually a good idea to RENAME the corrupt table so that the new object can be created with the correct name.   有很多方法可以从包含损坏块的表中获取数据。选择最合适的方法，如下所述。这些方法的目的是从可访问的表块中提取尽可能多的数据。重命名损坏的表通常是一个好主意，以便可以使用正确的名称创建新对象。

Example: RENAME <emp> TO <emp_corrupt>;

Methods of extracting data from a corrupt table AROUND a corrupt block  从损坏的表周围提取数据的方法

1. From Oracle 7.2 onwards, it is possible to SKIP over corrupt blocks in a table.  从Oracle 7.2起，可以跳过表中的损坏块。
   This is the simplest option to extract table data and is discussed in:  这是提取表数据的最简单选项，将在以下内容中讨论：
   
   Extracting data using DBMS_REPAIR.SKIP_CORRUPT_BLOCKS or Event 10231  Note:33405.1  使用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS或事件10231提取数据Note:33405.1
   If the corruption is in an IOT overflow segment then the same method should be followed, but using event 10233 together with a full index scan or in 10.2.0.4 / 10.2.0.5 use Event:43810; in 11g onward use parameter _index_scan_check_skip_corrupt=TRUE. See also section "SKIP ORA-600 in IOT" in Note:1527738.1
   如果损坏发生在IOT溢出段中，则应遵循相同的方法，但是将事件10233与全索引扫描或在10.2.0.4 / 10.2.0.5中使用Event：43810 ; 从11g开始，请使用参数_index_scan_check_skip_corrupt = TRUE。另请参见Note:1527738.1中的"SKIP ORA-600 in IOT"部分
   Note that this method can only be used if the block "wrapper" is marked corrupt. Example: If the block reports ORA-1578.  注意，仅当块"wrapper"标记为损坏时，才可以使用此方法。示例：如果该块报告ORA-1578。
   If the problem is an ORA-600 or other error which does not report and ORA-1578 error then it is often possible to use DBMS_REPAIR to mark the problem blocks in a table as "soft corrupt" such that they will then signal ORA-1578 when accessed which then allows to use DBMS_REPAIR.SKIP_CORRUPT_BLOCKS  如果问题是ORA-600或其他未报告的错误以及ORA-1578错误，则通常可以使用DBMS_REPAIR将表中的问题块标记为"soft corrupt"，以便它们随后向ORA-1578发出信号在访问时允许使用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS
   
   Note: Any blocks which are marked corrupt by the "FIX_CORRUPT_BLOCKS" procedure will also be marked corrupt following any restore / recover operation through the time of the FIX_CORRUPT_BLOCKS.     注意：在"FIX_CORRUPT_BLOCKS"期间进行任何还原/恢复操作之后，任何被"FIX_CORRUPT_BLOCKS"过程标记为损坏的块也将被标记为损坏。 
   
   Full details of using DBMS_REPAIR for this can be found in the documentation but in summary the steps are:  可以在文档中找到有关使用DBMS_REPAIR的完整详细信息，但总的来说，这些步骤是：

   - Use DBMS_REPAIR.ADMIN_TABLES to create the admin tables    创建管理表
   - Use DBMS_REPAIR.CHECK_OBJECT to find problem blocks   查找问题块
   - Get any good data out of problem blocks before corrupting them.  在损坏问题块之前，先从问题块中获取所有好的数据。
   - Use DBMS_REPAIR.FIX_CORRUPT_BLOCKS to mark the found problem
   blocks as corrupt so that they will then signal ORA-1578  将找到的问题块标记为损坏，以便它们随后发出信号ORA-1578
   - If required use DBMS_REPAIR.SKIP_CORRUPT_BLOCKS to skip corrupt
   blocks on the table.  如果需要，请使用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过表上的损坏块。

2. From Oracle 7.1 onwards use a ROWID range scan.   从Oracle 7.1起，使用ROWID范围扫描。
   The syntax for this is a little tricky but it is possible to select around a corrupt block using a ROWID hint.  这样做的语法有些棘手，但是可以使用ROWID提示在损坏的块周围进行选择。
   As the format of ROWIDs changed between Oracle7 and Oracle8 there are 2 articles which discuss this:
   由于在Oracle7和Oracle8之间更改了ROWID的格式，因此有2篇文章对此进行了讨论：
   Using ROWID Range Scans to extract data in Oracle8 and higher Note:61685.1
   Using ROWID Range Scans to extract data in Oracle7 Note:34371.1
    
3. If there is a primary key select table data via this index.  如果有主键，则通过该索引选择表数据。
   It may also be possible to select some of data via any other index.   也可以通过任何其他索引选择一些数据。
   This can be slow and time consuming and is only normally needed for Oracle 7.0 releases. This method is described in Note:34371.1 (which also describes the ROWID range scans)  这可能很慢且耗时，并且通常仅在Oracle 7.0版本中才需要。Note:34371.1（也描述了ROWID范围扫描）中描述了此方法。
4. There are various salvage programs / PLSQL scripts which can be used to salvage data from a table. These can take longer to set up and use than the above methods but can often cope with various kinds of corruption besides an ORA-1578.  有各种抢救程序/ PLSQL脚本，可用于抢救表中的数据。与上述方法相比，这些方法的建立和使用可能需要更长的时间，但是除了ORA-1578之外，通常还可以应对各种损坏。
   As these methods typically require much hand-holding from support then some of these articles may not be visible to customers.  由于这些方法通常需要获得支持的大量支持，因此其中一些物品可能对客户不可见。
   
   These require Pro*C to be available and an understanding of how to build Pro*C executables:
   这些要求提供Pro * C并需要了解如何构建Pro * C可执行文件：
   SALVAGE.PC for Oracle8.1 Note:97357.1
   SALVAGE.PC for Oracle7  Note:2077307.6
   
   These requires manual interaction:   这些需要手动交互：
   
   SALVAGE.SQL for Oracle7/8 Note:2064553.4
   SALVAGE.SQL for Oracle7/8 Note:28308.1
   The following is only possible in Oracle8i and 9i. The aim is to mark the block as corrupt and then use the SKIP_CORRUPT table attribute to extract the table data:
   以下仅适用于Oracle8i和9i。目的是将块标记为损坏，然后使用SKIP_CORRUPT表属性提取表数据：
   Use DBMS_REPAIR to mark the block corrupt Note:68013.1
   For corruption in a LONG column: Recreating a Table with a corruption in a LONG Note:876493.1

Methods of extracting data from a table with a corrupt LOBSEGMENT block  从具有损坏的LOBSEGMENT块的表中提取数据的方法

It is not possible to used DBMS_REPAIR on LOB segments.  在LOB段上不能使用DBMS_REPAIR。

If the corrupt LOB block is NOT referenced by any row in the table then it should be possible to CREATE TABLE as SELECT (CTAS) or export / drop / import the table as is.  如果表中的任何行未引用损坏的LOB块，则应该可以将SELECT作为创建表（CTAS）或按原样导出/删除/导入表。

If the corrupt LOB block is referenced by a row then it should be possible to select or export with a WHERE predicate that excludes the problem row/s.  如果行引用了损坏的LOB块，则应该可以选择或导出WHERE谓词，以排除问题行。

WARNING:
It is possible to update the LOB column value of a problem row to NULL (empty_blob() / empty_clob) which will clear the ORA-1578 on SELECT operations *BUT* the corrupt block will then be waiting to be reclaimed and will eventually signal an ORA-1578 on attempts to get a new LOB for INSERT or UPDATE operations on any row which can be a worse situation than having a corruption on a known row.   可以将问题行的LOB列值更新为NULL (empty_blob() / empty_clob)，这将清除SELECT操作上的ORA-1578 *但是*损坏的块将等待回收，并最终向ORA-1578发出信号，表示尝试在任何行上获取用于INSERT或UPDATE操作的新LOB，这比在已知行上损坏有可能更糟。
Hence the LOB column can be set to NULL only if intended to immediately recreate the table.   因此，仅当打算立即重新创建表时，才可以将LOB列设置为NULL 

Setting the corrupt lob to empty lob will add the blocks formerly mapped to this lob to the freelist.  Eventually when PCTVERSION or RETENTION criteria causes the space to be salvaged and reused for new data, error ORA-1578  can be seen again in the same LOB blocks.  In that case and after applying the above procedure the lob segment can be moved to a new segment:   将损坏的lob设置为空lob会将先前映射到此lob的块添加到空闲列表。最终，当PCTVERSION或RETENTION标准导致空间被抢救并重新用于新数据时，可以在同一LOB块中再次看到错误ORA-1578。在这种情况下，在应用上述过程之后，可以将lob段移动到新段
    alter table &table_owner.&table_with_lob move LOB (&&lob_column) store as (tablespace &tablespace_name);

Extracting data from the corrupt block itself   从损坏的块本身中提取数据

As the corrupt block itself is "corrupt" then any data extracted from the block should be treated as suspect.  The main methods of getting the rows from the corrupt block itself are:   由于损坏的块本身是“损坏​​的”，因此从该块中提取的任何数据都应视为可疑。从损坏的块本身获取行的主要方法是：

• Use any existing indexes on the table to extract data for columns covered by the index where the ROWID falls inside the corrupt block. This is described towards the end of the ROWID range scan articles mentioned above:  使用表上的所有现有索引来提取ROWID落在损坏的块内的索引所覆盖的列的数据。上面提到的ROWID范围扫描文章的末尾对此进行了描述：
  For Oracle8/8i see Note:61685.1
  For Oracle7 see Note:34371.1

• It may be possible to use LogMiner on the redo stream to find the original inserts/updates which loaded the data to the problem block. The main factor here is WHEN the data was actually put in the block.  可以在重做流上使用LogMiner查找将数据加载到问题块的原始插入/更新。这里的主要因素是何时将数据实际放入块中。
  example: row 2 may have been inserted yesterday but row 1 may have been inserted 5 years ago.  例如：昨天可能已插入第2行，但5年前可能已插入第1行。

(5D) Leaving A Corruption In Place  将损坏留在原地

It is possible to leave a corruption in place and just accept the errors reported, or prevent access to the problem rows at an application level.  可以保留损坏的位置，仅接受报告的错误，或者在应用程序级别阻止访问问题行。

Example: If the problem block / row is in a child table then it may be possible at application level to prevent access via the parent row/s such that the child rows are never accessed. (Be wary of cascade type constraints though)  示例：如果问题块/行位于子表中，则在应用程序级别可能会阻止通过父行进行访问，从而使子行永远不会被访问。（尽管要警惕级联类型约束）

This may not help with reports and other jobs which access data in bulk so it may also be desirable to use the DBMS_REPAIR options shown in 4C above to prevent the block/s erroring when accessed. Marking a corruption like this and leaving it around may  give a short term solution allowing full data salvage and/or recovery  to be attempted at scheduled outage, or allowing time to check other recovery options on a second (clone) database. Note though that marking a block corrupt with DBMS_REPAIR.FIX_CORRUPT_BLOCKS will cause the marked block/s to also be corrupt after recovery through the  time that FIX_CORRUPT_BLOCKS was executed.   这可能不适用于批量访问数据的报表和其他作业，因此也可能需要使用上面4C中显示的DBMS_REPAIR选项，以防止在访问时出现块错误。像这样标记损坏并将其遗留在外，可能会提供一个短期解决方案，允许在计划内的中断情况下尝试进行完整的数据抢救和/或恢复，或者留出时间检查第二个（克隆）数据库上的其他恢复选项。请注意，尽管使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS标记已损坏的块将导致在执行FIX_CORRUPT_BLOCKS的恢复后标记的块也已损坏。

Leaving a corruption may be sensible for data which rapidly ages and is subsequently purged (example: In a date partitioned table where older partitions are dropped at some point).  对于迅速老化并随后被清除的数据而言，留下损坏可能是明智的（例如：在日期分区表中，某些时候删除了较旧的分区）。

Leaving Corruptions in LOB segments   在LOB细分中留下损坏

At application level it can be possible to leave a corrupt LOB column in place until such time as the table can be rebuilt.  在应用程序级别，可以将损坏的LOB列留在原处，直到可以重建表为止。

One way to ensure to not hit the "WARNING" scenario above is to ensure that the table is only ever accessed via a view which includes a WHERE predicate to prevent the problem row/s from being seen.  确保不达到上述"WARNING" 情况的一种方法是确保仅通过包含WHERE谓词的视图访问该表，以防止看到问题行。
example: Consider table MYTAB( a number primary key, b clob ) has one or more rows pointing at corrupt LOB data.  示例：考虑表MYTAB（一个数字主键b clob）有一个或多个行指向损坏的LOB数据。

ALTER TABLE MYTAB ADD ( BAD VARCHAR2(1) );
CREATE VIEW MYVIEW AS SELECT a,b FROM MYTAB WHERE BAD is null;

Set BAD='Y' for any problem row/s  为任何问题行设置BAD ='Y'

If MYTAB is only accessed via MYVIEW, the row will never be visible and cannot be updated; keeping the corrupt entry isolated until it can be dealt with.  如果仅通过MYVIEW访问MYTAB，则该行将永远不可见且无法更新；将损坏的条目隔离开，直到可以解决为止。

Clearly this example is more of a design time solution but some applications may already have similar mechanisms and may only access data via a view (or via an RLS policy) giving some option/s to hide the problem rows.  显然，该示例更多是设计时解决方案，但是某些应用程序可能已经具有类似的机制，并且只能通过视图（或通过RLS策略）访问数据，从而提供一些选项来隐藏问题行。

Warnings when Leaving a Corruption in Place  放置损坏时的警告

Whilst it is possible to leave a corruption in place it should be noted that the corrupt blocks will still show up in runs of DBVERIFY, in RMAN backup warnings / errors etc..   尽管可以将损坏保留在原处，但应注意，损坏的块仍将在DBVERIFY的运行，RMAN备份警告/错误等中显示。

It is important to make a careful record of any corruption expected to be seen from these tools, particularly any blocks expected to be skipped with RMAN (having MAX_CORRUPT set) and be sure to remove any "acceptance" of the errors once the corruptions have been cleared.  重要的是，仔细记录可能会从这些工具中看到的任何损坏，特别是预期将被RMAN跳过的任何块（已设置MAX_CORRUPT），并确保一旦损坏已被删除，就一定要删除任何“接受”的错误。已清除。

Example: Consider that a corrupt block has been handled by leaving the corruption in place and avoiding the problem row/s at application level.  示例：考虑通过将损坏保留在原处并避免在应用程序级别出现问题的行来处理损坏的块。
RMAN may be configured to allow the corruptions during backup.  可以将RMAN配置为允许备份期间损坏。
The table is then recreated at a later date during some table reorganisation.  然后，在某些表重组期间，稍后会重新创建该表。
If RMAN is not updated to reflect that no errors should now be expected then RMAN may ignore some other corruption which occurs at a later time.  如果未更新RMAN以反映现在不应出现任何错误，则RMAN可能会忽略稍后发生的其他损坏。

It is also important to note that leaving corrupt blocks around in table segments can lead to mismatched results from queries; different results can occur for tables with SKIP_CORRUPT set depending on whether an index scan or table access occurs. Other reports may just error .  同样重要的是要注意，将损坏的块留在表段中会导致查询结果不匹配。对于设置了SKIP_CORRUPT的表，可能会发生不同的结果，具体取决于是否发生索引扫描或表访问。 其他报告可能只是错误。

Note that leaving a corruption in place but marking the block with DBMS_REPAIR.FIX_CORRUPT_BLOCKS writes redo to corrupt the block which may limit subsequent recovery options.  请注意，将损坏保留在适当的位置，但用DBMS_REPAIR.FIX_CORRUPT_BLOCKS标记该块会重做以破坏该块，这可能会限制后续的恢复选项。

(5E) Last Options   最后选择

If there is a STANDBY setup (physical or logical) then check that first.   如果有备用设置（物理或逻辑），请首先检查。
Whatever sort of block the problem occurred on, one possible option is to recover the database, or problem tablespace, to a point in time BEFORE the corruption appeared. The difficulty with this option is that it is not always possible to know when the problem first appeared.  无论发生什么问题，一种可能的选择是将数据库或问题表空间恢复到出现损坏之前的某个时间点。使用此选项的困难在于，并非总是能够知道问题何时首次出现。

DBVERIFY can be often be used to check a restored file for corruptions.  DBVERIFY通常可用于检查还原的文件是否损坏。
For details of using DBVERIFY see Note:35512.1 . In particular the START/END DBV options can be used to give a quick first test of whether the problem block itself is bad on a restored backup image.  有关使用DBVERIFY的详细信息，请参见Note:35512.1。特别是，可以使用START / END DBV选项进行快速的第一个测试，以测试问题块本身是否对恢复的备份映像有害。

This section outlines some final options available for recovering.  本节概述了一些可用于恢复的最终选项。
If arrived here then one or more of the following have happened:   如果到达这里，则发生以下一项或多项：

• A "vital" datafile has been lost (or have a corruption on it) and have no good backup of the problem file/s (without the corruption)   “重要”数据文件已丢失（或损坏），并且没有对问题文件的良好备份（没有损坏）
• The database is either not in ARCHIVELOG mode OR do not have all archivelogs since the file was first created  自文件首次创建以来，数据库未处于ARCHIVELOG模式或没有所有存档日志
• Complete recovery keeps reintroducing the problem  完全恢复使问题再次出现

Last chance:  最后的机会：

Please note that if all copies of a datafile have been lost but DO still have the ARCHIVE logs from when the file was first created it is still possible to recover the file.  请注意，如果数据文件的所有副本都丢失了，但是从首次创建文件起，仍然有ARCHIVE日志，仍然可以恢复该文件。

Example:
ALTER DATABASE CREATE DATAFILE '....' [as '...'] ;
RECOVER DATAFILE '....'
ALTER DATABASE DATAFILE '....' ONLINE;

If currently in this scenario try to recover the datafile using these steps before proceeding below.  如果当前在这种情况下，请尝试按照以下步骤恢复数据文件，然后再继续进行下面的操作。

If reached this line there are no options left to recover to the current point in time.  It is advisable to shutdown the instance and take a BACKUP of the current database NOW in order to provide a fall-back  position if the chosen course of action fails. (Example: if identified that the backup is bad).   如果到达此行，则没有其他选项可恢复到当前时间点。建议关闭实例并立即对当前数据库进行BACKUP，以便在选择的操作过程失败时提供后备位置。（例如：如果确定备份不正确）。 

Some outline options available are:  一些可用的大纲选项是

Revert to an old COLD backup   还原到旧的COLD备份
- example: If in NOARCHIVELOG mode   例如：如果处于NOARCHIVELOG模式

Set up a clone database from a COLD backup and extract (export) the problem table/s or transport the problem tablespace 从COLD备份中设置克隆数据库并提取（导出）问题表或传输问题表空间

Point in time recovery to an older point in time that is consistent:  时间点恢复到一致的旧时间点：

• requires a good backup and any necessary archive logs  需要良好的备份和任何必要的存档日志
• ALL files have to be restored and the whole DB rolled forward to a suitable point in time.  必须还原所有文件，并将整个数据库前滚到合适的时间点
• It may be possible to do the point in time recovery in a clone database and then transport the problem tablespace to the problem database, or export / import the problem table from the clone to the problem database .   可以在克隆数据库中进行时间点恢复，然后将问题表空间传输到问题数据库，或者将问题表从克隆导出/导入到问题数据库。 

Tablespace point in time recovery  表空间时间点恢复
- It may be possible to perform a point in time recovery of the affected tablespace only. There are many notes describing tablespace point in time recovery such as Note:223543.1.   可能仅对受影响的表空间执行时间点恢复。有许多描述表空间时间点恢复的注释，例如Note:223543.1。 

Rebuild of DB from some logical export / copy  从某些逻辑导出/复制中重建数据库
- Requires there to already be a good logical backup of the database  要求那里已经有一个良好的数据库逻辑备份
- NB: The database has to be RECREATED for this option.  注意：此选项必须将数据库重新存储。
- As with other options the rebuild could be in a clone database just to get a good image of the problem table/s.  与其他选项一样，重建可能会在克隆数据库中进行，以获取问题表的良好图像。

If a good backup is available then rolling forwards with DB_BLOCK_CHECKING=TRUE can help find the first point in time where something started to go wrong.  如果有良好的备份，则使用DB_BLOCK_CHECKING = TRUE进行前滚可以帮助您找到出现问题的第一个时间点。
It is not generally necessary to take the problem database down while investigating the recovery options.  在研究恢复选项时，通常不必关闭问题数据库。

Example: Restore the system tablespace and problem tablespace datafiles only to a totally different location and/or machine as a different instance to investigate how far the database can roll forward etc..  示例：仅将系统表空间和问题表空间数据文件还原到一个完全不同的位置和/或作为不同实例的计算机，以调查数据库可以向前滚动多远等。
As of Oracle9i the "Trial Recovery" option can be used to save having to keep restoring a backup while looking into possible options.  从Oracle9i开始，“试用恢复”选项可用于保存在研究可能的选项时，必须继续还原备份。

REFERENCES

NOTE:1088018.1 - Master Note for Handling Oracle Database Corruption Issues
NOTE:1543698.2 - Troubleshooting Assistant: Get Assistance to understand and solve Oracle Database Server Corruptions