Oracle控制文件详解

xiaoerp

Small, binary file
• Required:
– At mount
– To operate
• Linked to a single database
• Should be multiplexed
• Loss may require  recovery
==========================
1.控制文件是小的二进制文件,控制文件中包含了数据库的配置信息:
2.控制文件包含以下内容:
•数据库的名称和标识
• 数据库创建的时间
• 数据文件和Redo log文件的位置
• Tablespace名称
• Log history
• 备份信息
• Current log sequence number
• Checkpoint information

The control file of a database is a small binary file necessary for the database to start
and operate successfully. Each control file is associated with only one Oracle database.
A control file is updated continuously by the Oracle server during database use, so it
must be available for writing whenever the database is open. The information in the
control file can be modified only by the Oracle server; no DBA or end user can edit the
control file.
If for some reason the control file is not accessible, the database will not function
properly. If all copies of a database’s control files are lost, the database must be
recovered before it can be opened.

xiaoerp

控制文件的角色
每一个 Oracle9i 数据库都必须有一个控制档。它是一个小型二进制档案，主要是储存 Oracle9i 数据库结构信息，包括：
n          数据库名称
n          数据库建立时间
n          资料文件名称与所在位置
n          重置日志文件名称与所在位置
n          目前的日志序列码(log sequence number)
n          检查点信息

简言之，控制文件可用来描述 Oracle9i 实体结构。因此开启 Oracle9i 数据库时一定要读取控制文件才能取得所有数据库实体档案相关信息。一旦控制文件不幸毁损，数据库便无法顺利开启。也因为如此，控制档的管理与维护工作显得格外重要。

如何管理控制文件
设定控制文件名称与所在位置
因为控制文件将用来存放 Oracle9i 数据库的实体结构信息，即使目前尚未建置 Oracle9i 数据库，您也必须先准备好控制文件！换言之，在激活 Oracle Instance 时就必须知道控制文件的名称与所在位置。为此，控制文件的相关信息必须设定在起始参数档内，才能在开启 Oracle Instance 时一并读取控制档内容，进而激活 Oracle9i 数据库。控制文件的名称与所在路径位置是设定在起始参数档内 CONTROL_FILES 参数。
如何配置控制文件
每个 Oracle9i 数据库最好拥有两个以上控制档，并各自存放在不同磁盘上。如此一来当控制档因故毁损时，您便可以在最短时间内修复控制文件，尽可能缩短数据库停摆时间。假定您的 Oracle9i 数据库目前配置了三个控制文件，那么 Oracle 如何维护这些控制档呢? Oracle9i 与控制档的互动方式如下：
n          开启 Oracle 数据库时，只会读取第一个控制文件(顺序以 CONTROL_FILES 的设定值为基准)。
n          如果需要将特定信息写入控制文件，则 Oracle 会同时写入 CONTROL_FILES 参数所指定的档案。
n          当某个控制档发生问题时，Oracle Instance 将因此停摆。

如前所述，各控制档复本应该分散在不同实体磁盘。因此实际上规划一个正式系统时，请仔细思考控制文件与重置日志文件之搭配方式。

假定目前的重置日志群组有两个，分别置于 /u01 与 /u02两个磁盘；每个重置群组包含三个重置日志文件：
/u01/oradata/ora901/log1a.rdo(Group1)
/u01/oradata/ora901/log2a.rdo(Group2)
/u02/oradata/ora901/log1b.rdo(Group1)
/u02/oradata/ora901/log2b.rdo(Group2)
/u03/oradata/ora901/log1c.rdo(Group1)
/u03/oradata/ora901/log2c.rdo(Group2)

此时不妨在 /u01 与 /u02 各配置一个控制文件。如此可有效降低重置日志文件与控制文件同时遗失的风险。因为不管哪个磁盘出问题，另一个磁盘仍然保留完整的重置日志文件与控制文件资料。

如何决定控制档大小
Oracle9i 控制文件大小主要是由 CREATE DATABASE 指令内数个参数所决定，分别是： MAXDATAFILES、MAXLOGFILES、MAZLOGMEMBERS、MAXLOGHISTORY 与 MAXINSTANCES。

控制文件建立方式
经由 CREATE DATABASE 指令建立控制文件
Oracle9i 控制文件在建立数据库的同时就会一并建立；换句话说，当您执行 CREATE DATABASE 之后就会产生控制文件。但是有一点必须注意：CREATE DATABASE 指令内并未指定控制文件相关信息! 其实控制文件的名称与所在位置是定义在起始参数档的CONTROL_FILES参数，其命名方式必须视操作系统环境而定；例如 Windows 系统与 Linux 系统的档案路径表示法就不相同。以下是 CONTROL_FILES 参数之定义方式：
CONTROL_FILES = ( /u01/Oracle/ora901/control01.ctl,
/u02/Oracle/ora901/control02.ctl,
/u03/Oracle/ora901/control03.ctl)

如果 CONTROL_FILES 参数所指定的文件名称已经存在于操作系统中怎么办? 此时您在执行 CREATE DATABASE 指令时就会发生错误，不过只要加上 CONTROL FILE REUSE 子句即可。然而，如果现有控制档名称与 CONTROL_FILES 所设定的名称相同，但是其 “大小” 却不同，那么您还是无法使用 REUSE 选项。

建立额外的控制文件
为了避免控制文件(或其所在磁盘)毁损时影响到 Oracle9i 数据库正常运作，您也许需要在其它硬盘上新增其它控制档。最简单的方式就是先将既有控制文件复制到目的位置，然后将控制文件名称加入起始参数档的 CONTROL_FILES 之中。同理，如果想更改控制档名称，也可以先将控制文件复制到目的位置后予以更名，再更新 CONTROL_FILES 参数。请注意，不管是上述何项动作，都应该先关闭 Oracle9i instance 再进行。在其它磁盘建立额外控制文件的步骤如下：
1.       关闭 Oracle9i 数据库。
2.       在操作系统下将既有控制文件复制到目的位置。
3.       开启起始参数档，并修改 CONTROL_FILES 参数。您必须将新的控制文件名与所在目录名称加入 CONTROL_FILES 参数。
4.       重新开启 Oracle9i 数据库。

建立全新的控制文件
除了将控制文件复制到其它磁盘之外，某些时候您可能需要建立 ”全新的” 控制文件，例如：
n          目前数据库既有的控制文件不幸毁损，不仅未进行备份，也尚未在其它磁盘建立镜射控制文件。
n           您希望更改 CREATE DATABASE 指令内设定的控制文件相关参数，例如：数据库名称，或是 MAXLOGFILES、MAXLOGMEMBERS 与 MAXLOGHISTORY 等参数。

举例来说，在分布式运算环境中可能会有两部 Oracle9i 数据库名称相同，其中一台必须更改数据库名称。也有可能因为 MAXLOGFILES 与 MAXLOGMEMBERS 最初设定值太小，现在必须加大。上述情况都必须建立全新的控制档。以下是建立详细的建置步骤：

1.          先整理一份数据库档案清单，其中包含所有数据文件与重置日志档案之路径与名称。V$LOGFILE 与 V$DATAFILE 这两个视观表可协助您进行这项供工作，例如：

SELECT member FROM v$logfile;

参与“恭贺IBM存储用户精英俱乐部正式上线！  
回复 引用 报告 使用道具 TOP
.
  

发短消息加为好友Apollo.yang 当前离线
UID1408 帖子53 精华2 阅读权限20 注册时间2009-9-28 最后登录2011-11-1 .  

二星级会员



社区金钱294 C币 专家积分0 分 注册时间2009-9-28 .
3#
Apollo.yang发表于 2010-6-24 11:40 | 只看该作者 通过系统表 V$logfile查看控制文件信息：
1)select member from v$logfile
MEMBER
C:\Oracle\ORADATA\MINER\REDO03.LOG
C:\Oracle\ORADATA\MINER\REDO02.LOG
C:\Oracle\ORADATA\MINER\REDO01.LOG


2)select name,(blocks*8)/1024  from v$datafile
NAME        (BLOCKS*8)/1024

C:\Oracle\ORADATA\MINER\SYSTEM01.DBF        400
C:\Oracle\ORADATA\MINER\UNDOTBS01.DBF        200
C:\Oracle\ORADATA\MINER\CWMLITE01.DBF        20
C:\Oracle\ORADATA\MINER\DRSYS01.DBF        20
C:\Oracle\ORADATA\MINER\EXAMPLE01.DBF        149.375
C:\Oracle\ORADATA\MINER\INDX01.DBF        25
C:\Oracle\ORADATA\MINER\ODM01.DBF        20
C:\Oracle\ORADATA\MINER\TOOLS01.DBF        10
C:\Oracle\ORADATA\MINER\USERS01.DBF        25
C:\Oracle\ORADATA\MINER\XDB01.DBF        38.125
C:\Oracle\ORADATA\MINER\OCSTBL.DBF        50

xiaoerp

控制文件的角色
每一个 Oracle9i 数据库都必须有一个控制档。它是一个小型二进制档案，主要是储存 Oracle9i 数据库结构信息，包括：
n          数据库名称
n          数据库建立时间
n          资料文件名称与所在位置
n          重置日志文件名称与所在位置
n          目前的日志序列码(log sequence number)
n          检查点信息

简言之，控制文件可用来描述 Oracle9i 实体结构。因此开启 Oracle9i 数据库时一定要读取控制文件才能取得所有数据库实体档案相关信息。一旦控制文件不幸毁损，数据库便无法顺利开启。也因为如此，控制档的管理与维护工作显得格外重要。

如何管理控制文件
设定控制文件名称与所在位置
因为控制文件将用来存放 Oracle9i 数据库的实体结构信息，即使目前尚未建置 Oracle9i 数据库，您也必须先准备好控制文件！换言之，在激活 Oracle Instance 时就必须知道控制文件的名称与所在位置。为此，控制文件的相关信息必须设定在起始参数档内，才能在开启 Oracle Instance 时一并读取控制档内容，进而激活 Oracle9i 数据库。控制文件的名称与所在路径位置是设定在起始参数档内 CONTROL_FILES 参数。
如何配置控制文件
每个 Oracle9i 数据库最好拥有两个以上控制档，并各自存放在不同磁盘上。如此一来当控制档因故毁损时，您便可以在最短时间内修复控制文件，尽可能缩短数据库停摆时间。假定您的 Oracle9i 数据库目前配置了三个控制文件，那么 Oracle 如何维护这些控制档呢? Oracle9i 与控制档的互动方式如下：
n          开启 Oracle 数据库时，只会读取第一个控制文件(顺序以 CONTROL_FILES 的设定值为基准)。
n          如果需要将特定信息写入控制文件，则 Oracle 会同时写入 CONTROL_FILES 参数所指定的档案。
n          当某个控制档发生问题时，Oracle Instance 将因此停摆。

如前所述，各控制档复本应该分散在不同实体磁盘。因此实际上规划一个正式系统时，请仔细思考控制文件与重置日志文件之搭配方式。

假定目前的重置日志群组有两个，分别置于 /u01 与 /u02两个磁盘；每个重置群组包含三个重置日志文件：
/u01/oradata/ora901/log1a.rdo(Group1)
/u01/oradata/ora901/log2a.rdo(Group2)
/u02/oradata/ora901/log1b.rdo(Group1)
/u02/oradata/ora901/log2b.rdo(Group2)
/u03/oradata/ora901/log1c.rdo(Group1)
/u03/oradata/ora901/log2c.rdo(Group2)

此时不妨在 /u01 与 /u02 各配置一个控制文件。如此可有效降低重置日志文件与控制文件同时遗失的风险。因为不管哪个磁盘出问题，另一个磁盘仍然保留完整的重置日志文件与控制文件资料。

如何决定控制档大小
Oracle9i 控制文件大小主要是由 CREATE DATABASE 指令内数个参数所决定，分别是： MAXDATAFILES、MAXLOGFILES、MAZLOGMEMBERS、MAXLOGHISTORY 与 MAXINSTANCES。

控制文件建立方式
经由 CREATE DATABASE 指令建立控制文件
Oracle9i 控制文件在建立数据库的同时就会一并建立；换句话说，当您执行 CREATE DATABASE 之后就会产生控制文件。但是有一点必须注意：CREATE DATABASE 指令内并未指定控制文件相关信息! 其实控制文件的名称与所在位置是定义在起始参数档的CONTROL_FILES参数，其命名方式必须视操作系统环境而定；例如 Windows 系统与 Linux 系统的档案路径表示法就不相同。以下是 CONTROL_FILES 参数之定义方式：
CONTROL_FILES = ( /u01/Oracle/ora901/control01.ctl,
/u02/Oracle/ora901/control02.ctl,
/u03/Oracle/ora901/control03.ctl)

如果 CONTROL_FILES 参数所指定的文件名称已经存在于操作系统中怎么办? 此时您在执行 CREATE DATABASE 指令时就会发生错误，不过只要加上 CONTROL FILE REUSE 子句即可。然而，如果现有控制档名称与 CONTROL_FILES 所设定的名称相同，但是其 “大小” 却不同，那么您还是无法使用 REUSE 选项。

建立额外的控制文件
为了避免控制文件(或其所在磁盘)毁损时影响到 Oracle9i 数据库正常运作，您也许需要在其它硬盘上新增其它控制档。最简单的方式就是先将既有控制文件复制到目的位置，然后将控制文件名称加入起始参数档的 CONTROL_FILES 之中。同理，如果想更改控制档名称，也可以先将控制文件复制到目的位置后予以更名，再更新 CONTROL_FILES 参数。请注意，不管是上述何项动作，都应该先关闭 Oracle9i instance 再进行。在其它磁盘建立额外控制文件的步骤如下：
1.       关闭 Oracle9i 数据库。
2.       在操作系统下将既有控制文件复制到目的位置。
3.       开启起始参数档，并修改 CONTROL_FILES 参数。您必须将新的控制文件名与所在目录名称加入 CONTROL_FILES 参数。
4.       重新开启 Oracle9i 数据库。

建立全新的控制文件
除了将控制文件复制到其它磁盘之外，某些时候您可能需要建立 ”全新的” 控制文件，例如：
n          目前数据库既有的控制文件不幸毁损，不仅未进行备份，也尚未在其它磁盘建立镜射控制文件。
n           您希望更改 CREATE DATABASE 指令内设定的控制文件相关参数，例如：数据库名称，或是 MAXLOGFILES、MAXLOGMEMBERS 与 MAXLOGHISTORY 等参数。

举例来说，在分布式运算环境中可能会有两部 Oracle9i 数据库名称相同，其中一台必须更改数据库名称。也有可能因为 MAXLOGFILES 与 MAXLOGMEMBERS 最初设定值太小，现在必须加大。上述情况都必须建立全新的控制档。以下是建立详细的建置步骤：

1.          先整理一份数据库档案清单，其中包含所有数据文件与重置日志档案之路径与名称。V$LOGFILE 与 V$DATAFILE 这两个视观表可协助您进行这项供工作，例如：

SELECT member FROM v$logfile;

参与“恭贺IBM存储用户精英俱乐部正式上线！  
回复 引用 报告 使用道具 TOP
.
  

发短消息加为好友Apollo.yang 当前离线
UID1408 帖子53 精华2 阅读权限20 注册时间2009-9-28 最后登录2011-11-1 .  

二星级会员



社区金钱294 C币 专家积分0 分 注册时间2009-9-28 .
3#
Apollo.yang发表于 2010-6-24 11:40 | 只看该作者 通过系统表 V$logfile查看控制文件信息：
1)select member from v$logfile
MEMBER
C:\Oracle\ORADATA\MINER\REDO03.LOG
C:\Oracle\ORADATA\MINER\REDO02.LOG
C:\Oracle\ORADATA\MINER\REDO01.LOG


2)select name,(blocks*8)/1024  from v$datafile
NAME        (BLOCKS*8)/1024

C:\Oracle\ORADATA\MINER\SYSTEM01.DBF        400
C:\Oracle\ORADATA\MINER\UNDOTBS01.DBF        200
C:\Oracle\ORADATA\MINER\CWMLITE01.DBF        20
C:\Oracle\ORADATA\MINER\DRSYS01.DBF        20
C:\Oracle\ORADATA\MINER\EXAMPLE01.DBF        149.375
C:\Oracle\ORADATA\MINER\INDX01.DBF        25
C:\Oracle\ORADATA\MINER\ODM01.DBF        20
C:\Oracle\ORADATA\MINER\TOOLS01.DBF        10
C:\Oracle\ORADATA\MINER\USERS01.DBF        25
C:\Oracle\ORADATA\MINER\XDB01.DBF        38.125
C:\Oracle\ORADATA\MINER\OCSTBL.DBF        50

xiaoerp

Oracle灾难恢复
随着办公自动化和电子商务的飞速发展，企业对信息系统的依赖性越来越高，数据库作为信息系统的核心担当着重要的角色。尤其在一些对数据可靠性要求很高的行业如银行、证券、电信等，如果发生意外停机或数据丢失其损失会十分惨重。为此数据库管理员应针对具体的业务要求制定详细的数据库备份与灾难恢复策略，并通过模拟故障对每种可能的情况进行严格测试，只有这样才能保证数据的高可用性。数据库的备份是一个长期的过程，而恢复只在发生事故后进行，恢复可以看作是备份的逆过程，恢复的程度的好坏很大程度上依赖于备份的情况。此外，数据库管理员在恢复时采取的步骤正确与否也直接影响最终的恢复结果，本文主要针对 Oracle数据库可能遇到的各种故障提供了相应的恢复的方法，仅供大家参考。
要对Oracle数据库备份与恢复有清晰的认识，首先有必要对数据库的几种运行状态有充分的了解。Oracle数据库的运行状态主要分为3种，他们依次为：
l Nomount（非安装）Oracle只是读取ini文件中的配置信息，并初始化SGA区。
l Mount（安装）Oracle除了需要读取ini文件还要读取控制文件，并从中获取有关数据库的物理结构等信息。
l Open（打开）数据库要检查所有文件处于同一时间点，对错误进行恢复对未完成事务回滚，并最终可以允许用户访问。

数据库的备份主要分为三种类型：冷备份；热备份；逻辑备份；
数据库的备份不是本文讨论的重点，在这里只作一个概要的介绍，Oracle数据库备份主要有：
l Cold Backup（冷备份） 主要指在关闭数据库的状态下进行的数据库完全备份，备份内容包括所有数据文件、控制文件、联机日志文件、ini文件。
l Hot Backup（热备份） 指在数据库处于运行状态下，对数据文件和控制文件进行备份，要使用热备份必须将数据库运行在(Archive Log)归档方式下。
l Export（逻辑备份）这是最简单的备份方法，可按数据库中某个表、某个用户或整个数据库来导出，并且支持全部、累计、增量三种方式。使用这种方法，数据库必须处于打开状态，而且如果数据库不是在restrict状态将不能保证导出数据的一致性。

数据库的恢复可分为两大类：完全恢复；不完全恢复；
完全恢复指将数据库恢复到发生故障的时间点，不丢失任何数据。不完全恢复指将数据库恢复到发生故障前的某一个时间点，此时间点以后的所有改动将会丢失。如果没有特殊需求，我们建议应尽量使用完全恢复。
Oracle数据库的恢复过程分两步进行，首先将把存放在重做日志文件中的所有重做运用到数据文件，之后对重做中所有未提交的事务进行回滚，这样所有数据就恢复到发生灾难那一时刻了。数据库的恢复只能在发生故障之前的数据文件上运用重做，将其恢复到故障时刻，而不能将数据文件反向回滚到之前的某一个时刻。举个例子，我们有一个2001/1/1的数据库备份，当2001/5/1使我们发现数据库中数据发生混乱，希望将数据库恢复到2001/4/30时的状态，我们只能先恢复2001/1/1的数据库备份然后在其上运用重做记录使其前滚到2001/4/30时的状态，而不能将2001/5/1的数据库向后回滚到2001/4/30。
为了系统的设计数据库的恢复方案，我们先对可能遇到的错误进行分类，Oracle数据库错误主要分为5大类：
l SQL语句失败
l 线程失败
l 实例失败
l 用户操作失败
l 存储设备失败
如果发生前三种失败，不需要我们人为干涉，Oracle系统会自动进行恢复。对于用户操作型的失败（如误删除数据），我们采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。从Oracle 8之后的新版本中引入了基于表空间的时间点恢复(TSPITR)，可以单独将包含错误操作的表空间恢复到指定时间，而不必对整个数据库进行不完全恢复。当错误操作发现比较及时而且数据量不大的情况下也可以考虑使用logminer生成反向SQL。

针对存储设备的失败的情况比较复杂也是本文讨论的重点，存储设备的失败必然会使放置在其上的文件变为不可用，我们先将Oracle数据库所涉及到的文件进行一个划分，主要可分为：
l Oracle的系统文件，指Oracle的运行文件，各种应用程序
l 数据库控制文件
l 数据库联机重做日志文件
l 数据文件
l 归档日志文件
避免第一种文件失败主要依赖系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将其恢复。
控制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息，在创建数据库时会让用户指定三个位置来存放控制文件，他们之间互为镜像，当其中任何一个发生故障，只需将其从ini文件中注释掉故障数据文件就可重新将数据启动。当所有控制全部失效时，可以在Nomount模式下执行create controlfile来重新生成控制文件，但必须提供redo log，data file，文件名和地址以及MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等信息。如果失败之前运行过alter database backup controlfile to trace或alter database backup controlfile to ‘xxx’对控制文件作备份，恢复时可使用生成的脚本来重建或用备份文件覆盖，如果使用了旧的控制文件在恢复时要使用recover xxx using backup controlfile选项来进行恢复，并使用resetlogs选项来打开数据库。

xiaoerp

Oracle灾难恢复
随着办公自动化和电子商务的飞速发展，企业对信息系统的依赖性越来越高，数据库作为信息系统的核心担当着重要的角色。尤其在一些对数据可靠性要求很高的行业如银行、证券、电信等，如果发生意外停机或数据丢失其损失会十分惨重。为此数据库管理员应针对具体的业务要求制定详细的数据库备份与灾难恢复策略，并通过模拟故障对每种可能的情况进行严格测试，只有这样才能保证数据的高可用性。数据库的备份是一个长期的过程，而恢复只在发生事故后进行，恢复可以看作是备份的逆过程，恢复的程度的好坏很大程度上依赖于备份的情况。此外，数据库管理员在恢复时采取的步骤正确与否也直接影响最终的恢复结果，本文主要针对 Oracle数据库可能遇到的各种故障提供了相应的恢复的方法，仅供大家参考。
要对Oracle数据库备份与恢复有清晰的认识，首先有必要对数据库的几种运行状态有充分的了解。Oracle数据库的运行状态主要分为3种，他们依次为：
l Nomount（非安装）Oracle只是读取ini文件中的配置信息，并初始化SGA区。
l Mount（安装）Oracle除了需要读取ini文件还要读取控制文件，并从中获取有关数据库的物理结构等信息。
l Open（打开）数据库要检查所有文件处于同一时间点，对错误进行恢复对未完成事务回滚，并最终可以允许用户访问。

数据库的备份主要分为三种类型：冷备份；热备份；逻辑备份；
数据库的备份不是本文讨论的重点，在这里只作一个概要的介绍，Oracle数据库备份主要有：
l Cold Backup（冷备份） 主要指在关闭数据库的状态下进行的数据库完全备份，备份内容包括所有数据文件、控制文件、联机日志文件、ini文件。
l Hot Backup（热备份） 指在数据库处于运行状态下，对数据文件和控制文件进行备份，要使用热备份必须将数据库运行在(Archive Log)归档方式下。
l Export（逻辑备份）这是最简单的备份方法，可按数据库中某个表、某个用户或整个数据库来导出，并且支持全部、累计、增量三种方式。使用这种方法，数据库必须处于打开状态，而且如果数据库不是在restrict状态将不能保证导出数据的一致性。

数据库的恢复可分为两大类：完全恢复；不完全恢复；
完全恢复指将数据库恢复到发生故障的时间点，不丢失任何数据。不完全恢复指将数据库恢复到发生故障前的某一个时间点，此时间点以后的所有改动将会丢失。如果没有特殊需求，我们建议应尽量使用完全恢复。
Oracle数据库的恢复过程分两步进行，首先将把存放在重做日志文件中的所有重做运用到数据文件，之后对重做中所有未提交的事务进行回滚，这样所有数据就恢复到发生灾难那一时刻了。数据库的恢复只能在发生故障之前的数据文件上运用重做，将其恢复到故障时刻，而不能将数据文件反向回滚到之前的某一个时刻。举个例子，我们有一个2001/1/1的数据库备份，当2001/5/1使我们发现数据库中数据发生混乱，希望将数据库恢复到2001/4/30时的状态，我们只能先恢复2001/1/1的数据库备份然后在其上运用重做记录使其前滚到2001/4/30时的状态，而不能将2001/5/1的数据库向后回滚到2001/4/30。
为了系统的设计数据库的恢复方案，我们先对可能遇到的错误进行分类，Oracle数据库错误主要分为5大类：
l SQL语句失败
l 线程失败
l 实例失败
l 用户操作失败
l 存储设备失败
如果发生前三种失败，不需要我们人为干涉，Oracle系统会自动进行恢复。对于用户操作型的失败（如误删除数据），我们采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。从Oracle 8之后的新版本中引入了基于表空间的时间点恢复(TSPITR)，可以单独将包含错误操作的表空间恢复到指定时间，而不必对整个数据库进行不完全恢复。当错误操作发现比较及时而且数据量不大的情况下也可以考虑使用logminer生成反向SQL。

针对存储设备的失败的情况比较复杂也是本文讨论的重点，存储设备的失败必然会使放置在其上的文件变为不可用，我们先将Oracle数据库所涉及到的文件进行一个划分，主要可分为：
l Oracle的系统文件，指Oracle的运行文件，各种应用程序
l 数据库控制文件
l 数据库联机重做日志文件
l 数据文件
l 归档日志文件
避免第一种文件失败主要依赖系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将其恢复。
控制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息，在创建数据库时会让用户指定三个位置来存放控制文件，他们之间互为镜像，当其中任何一个发生故障，只需将其从ini文件中注释掉故障数据文件就可重新将数据启动。当所有控制全部失效时，可以在Nomount模式下执行create controlfile来重新生成控制文件，但必须提供redo log，data file，文件名和地址以及MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等信息。如果失败之前运行过alter database backup controlfile to trace或alter database backup controlfile to ‘xxx’对控制文件作备份，恢复时可使用生成的脚本来重建或用备份文件覆盖，如果使用了旧的控制文件在恢复时要使用recover xxx using backup controlfile选项来进行恢复，并使用resetlogs选项来打开数据库。

xiaoerp

如果丢失的是联机日志文件，分两种情况处理1、丢失的是非活动的日志文件；2、丢失的是当前激活的日志文件。
如果是第一种情况，而发生故障的日志文件组又具有多个成员，可以先将数据库shutdown，然后用操作系统命令将损坏日志文件组中好的日志成员文件把损坏的成员文件覆盖（在同一个日志成员组中的所有日志文件的各为镜象的），如果其物理位置不可用可将其拷贝到新的驱动器上，使用alter database rename file ‘xxxx’ to ‘xxxx’改变文件位置，之后启动数据库，如果正常马上进行一个冷备份。如果损坏的日志组中只有一个日志成员，先mount上数据库，将其转换为 noarchivelog模式，执行alter database add logfile member ‘xxx’ to group ‘x’给相关组增加一个成员，再执行alter database drop logfile member ‘bad_file’将损坏的日志文件删除，由于数据库的结构发生变动需要备份控制文件，之后将数据库改回archivelog模式，做一个冷备份。
如果丢失的是当前激活的日志文件，数据库又没有镜像而且当前日志组中所有成员均变为不可用。首先将数据库shutdown abort，从最近的一次全备份中恢复所有的数据文件，将数据库启动到mount状态。如果原来的日志文件物理位置不可用，使用alter database rename file ‘xxx’ to ‘xxx’改变文件的存放位置。然后，使用recover database until cancel命令来恢复数据库，直到提示最后一个归档日志运用完之后，输入cancel。之后用alter database open resetlogs打开数据库，如果没有问题，立即进行一个冷备份。注意！所有包含在损坏的redo log中的信息将会丢失，也就是说数据库崩溃前已经提交的数据有可能会丢失。这对于某些要求很高的应用将会损失惨重，因此应尽量使每个日志组具有多个日志成员，并且放置在不同的驱动器上一防止发生介质故障。
数据文件发生故障的情况也分为多种情况，1、丢失包含在SYSTEM表空间的数据文件；2、丢失没有回滚段的非SYSTEM数据文件；3、丢失有回滚段的非SYSTEM数据文件。
如果损坏的是系统表空间的数据文件。唯一的办法是从上一次备份中恢复受损的数据文件，（如果原位置不可用使用alter database rename命令改变新文件的位置），之后在数据库mount的状态下执行recover database/datafile对数据库进行回复，才能将数据库打开。注意：当SYSTEM表空间或其中的数据文件脱机，数据库是无法被打开的，因此必须在mount状态下将所有的恢复工作完成。
当丢失的数据文件不属于系统表空间而且也不包含回滚段时，有可选择在数据库的两种状态下进行恢复---在数据库open的状态或者在数据库mount的状态。如果用户急于访问数据库中未受损部分的数据或对损坏的数据文件进行恢复需要很长时间，可以先使受损的数据文件脱机，将数据库打开给用户访问，再恢复受损的数据文件最后将其联机。步骤如下：先在数据库mount时，将相关的数据文件或表空间进行脱机alter database datafile xxx offline，然后将数据库open，这样就能使数据库未受损的部分先供用户访问，之后再进行recover datafile/tablespace，完成后用alter database datafile/tablespace ‘xxx’ online使其恢复联机就可被访问了。 当然用户也可以选择在数据库mount状态下，用recover database/datafile将所有的恢复工作做完，将所有数据文件一起打开供用户访问。
如果丢失的数据文件是最后一种情况，即包含有回滚段的非系统表空间数据文件。也可以选择是在数据库先open的状态还是在mount状态下恢复。不过与上一种情况不同的是当包含回滚段的数据文件损坏时，如果使其先offline将数据库打开，那么所有数据库崩溃前未提交的事务涉及到的表将无法访问，也就是说在回滚段恢复前其中涉及的对象都不允许被访问。而且当所有包含回滚段的数据文件都在offline状态时，数据库无法进行任何DML操作，因此在数据库 open状态恢复包含回滚段的数据文件时，可以先创建几个临时回滚段供数据使用create rollback segment temp1 tablespace system; alter rollback segment temp1 online;，当数据文件恢复后再将他们删除alter rollback segment temp1 offline; drop rollback segment temp1;。注意：当用这种方法使恢复的数据文件online之后，所有的原有回滚段将处于offline状态，必须手工使用alter rollback segment RBSxx online;使他们恢复联机状态，这样才能被数据库正常使用。如果在数据库mount状态下完成所有恢复，则不需要上述步骤。
如果丢失数据文件后，用户发现没有故障前的数据文件的备份，而且自从丢失的数据文件最早建立之后一直没有使用过resetlogs选项打开过数据库。也就是说用户的控制文件是在损坏的数据文件建立前创建的，归档日志中包括对损坏数据文件的所有重做记录。用户就还有一种恢复方法，用户可以先将损坏的数据文件或表空间脱机alter database datafile / tablespace xxx offline，之后执行alter database create datafile ‘new/xxx.dbf’ as ‘old/xxx.dbf’，数据库会根据保存在控制文件中的信息重建一个空的数据文件，之后再执行recover tablespace / datafile将所有重做记录运用到数据文件，使其完全恢复到当前状态，之后便可再将其恢复联机。
如果丢失的是最后一种文件---归档文件或归档文件所处的物理位置不可用，首先shutdown数据库，立即作一个冷备份。然后修改ini文件中的归档日志文件目的路径，重新启动数据库。以后再发生灾难只需从最新的备份中将相关文件恢复，数据库作recover时就不需要备份之前丢失的归档文件了。在 Oracle 8之后的新版本中提供了log_archive_duplex_dest和log_archive_dest_1...5等参数允许保留多份归档文件到不同位置，甚至到远端服务器从而保证归档文件的可靠性。

最后再说几点数据库恢复时的注意事项：
1.本文讨论所有情况的默认前提是数据库运行在归档(ARCHIVELOG)方式下，并只涉及到一般常见的情况和最基本的恢复方法。使用Oracle提供的恢复管理器RMAN也能完成上述任务，如果运行环境比较复杂建议使用RMAN来做备份和恢复。
2.一旦数据库发生灾难，最好在进行恢复之前做一次完全的冷备份，以便在进行恢复时产生差错还可以进行补救。很大一部分数据丢失是由于不正确的恢复操作所引起的。
3.当数据库完成恢复之后，尤其是使用resetlogs选项打开数据库之后，要马上关闭数据库进行一次完全的冷备份。因为，为防止放弃的重做日志被下次恢复时再次运用，resetlogs选项会重新创建redo log文件并将其的计数清零，这将使之前做的所有备份将变为不可用（一般情况下）。
4.要特别注意当进行数据库完全恢复，从发生故障的时间点前的备份中恢复损坏文件时，一定不要使备份中的redo log文件覆盖了当前的redo log文件，否则就只能进行不完全恢复并且要丢失一部分数据了。