以下是小编整理的优化Oracle停机时间及数据库恢复数据库教程（共含7篇），欢迎阅读分享。同时，但愿您也能像本文投稿人“盲人黑”一样，积极向本站投稿分享好文章。
oracle|恢复|数据|数据库|优化
这里会讨论令Oracle停机时间最小化的步骤，优化Oracle停机时间及数据库恢复数据库教程
。各种形式的停机--计划的或者是非计划的--总是不断地发生，一个DBA应该有正确的备份策略，这样在数据库出现问题时就可以更快地恢复。以下是假定的备份策略和数据库的运作条件
控制文件是镜像的
数据库运行在archivelog模式
每个星期都进行冷备份
每日都进行热备份
每日都进行一次全数据库导出
事件1：完整的数据库重构
在这种情形下，你可以使用全数据库导出或者冷热备份结合的方式来重构数据库。要注意的是无论你选择哪种方式，在线redo log中的事务都会丢失。
事件2：恢复部分的表空间
可以使用以下的步骤来恢复：
1、以restrict模式启动数据库
2、重新创建表空间
3、使用最新的全数据库导出来导入，并且使用ignore=y的选项；
4.关闭并且重新以normal的模式启动数据库实例
事件3：丢失一般的数据文件
丢失一般数据文件的恢复步骤根据所丢失的数据文件包含的表空间类型而定；例如：回滚段，用户表空间，索引表空间或者是只读的表空间、你可能会遇到以下的错误：
. 尝试启动数据库并且碰到错误的信息ORA-1157, ORA-1110，可能还有一个操作系统的错误
. 尝试以normal或者immediate的模式关闭数据库，可能会碰到ORA-1116, ORA-1110的错误信息，还有一个系统错误
以下的步骤可以用作恢复：
1、关闭数据库
2、由热备份中恢复丢失的数据文件
3、Startup mount数据库
4、执行以下的查询来得到所有你的在线redo log文件和它们相应的次序和首次修改号：
SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
FROM V$LOG X, V$LOGILE Y
WHERE X.GROUP# = Y.GROUP#;
5、如果得到的CHANGE#比在线redo log最小的FIRST_CHANGE# 还小，那么该文件不能被完全恢复，你可以有两个选择：
. 如果可以接受丢失最近一次冷备份以来的数据库修改，装入备份并且继续恢复
. 如果不能接受丢失数据库的修改，那么必须重新创建表空间
6、通过使用存档和在线的redo log来恢复数据文件
7、打开数据库
事件4：恢复一个特别的表
可以采用以下的步骤恢复：
1、使用最近的一次全数据库导出来导入表，并且使用owner=和tables=的选项
2、考虑到性能的原因，可能需要重建表索引
事件5：丢失控制文件
在数据库起来并且运行时，通常都不能检测到控制文件的问题、如果控制文件丢失或者损坏了，Oracle将不会了解，下次数据库的启动时将会导致ORA-205错误（标识控制文件“%s的错误），还有一个系统级的错误、
如果只是丢失了其中的一个控制文件，可以采用下面的步骤来恢复：
1、如果它正在运行的话，先关闭它
2、查找丢失控制文件的原因、是由于硬件的问题吗（磁盘还是控制器）？
3、如果不是硬件的问题，将控制文件的一个好的拷贝复制到丢失的位置，并且跳到步骤5、
4、如果是硬件的问题，复制一个好的控制文件拷贝到一个可靠的位置
5、编辑initsid.ora 或者 configsid.ora，更新CONTROL_FILES以反映最新的控制文件位置
6、启动数据库
事件6：丢失全部的控制文件
可以采用以下的步骤恢复：
1、关闭数据库
2、进行一次全数据库备份，包括全部的数据文件和redo log文件
3、以NOMOUNT的状态启动数据库
4、使用CREATE CONTROLFILE重新创建控制文件、你也可以备份控制文件到一个trace文件，然后执行该文件
5、在数据库上进行媒体恢复
6、打开数据库
7、使用shutdown normal关闭数据库
8、对数据库进行一次冷备份
事件7：丢失一个索引
最简单的方法就是重新创建丢失的索引
事件8：丢失一个非活动的redo log
如果丢失redo数据，恢复将是不完全的，必须重新创建涉及的表空间。要重新创建表空间，可以使用全的数据库导出，这样就可以很容易的导入数据并且重新创建该表空间的对象。可以使用以下的步骤来恢复：
1、通过Alter system来切换redo log文件
2、关闭数据库
3、startup mount数据库
4、离线删除涉及的数据文件
5、打开数据库
6、删除用户的表空间，包括其中的内容、
7、通过全数据库备份重新创建表空间和其中的对象
事件9：丢失活动的Redo log
如事件8讨论的一样，如果丢失了redo数据，恢复将是不完全的，必须重新创建涉及的表空间、可以采用以下的步骤恢复：
1、关闭数据库
2、startup mount数据库
3、离线删除涉及的数据文件
4、打开数据库
5、删除用户的表空间，包括其中的内容、
6、通过全数据库备份重新创建表空间和其中的对象
要注意的是活动的事务将会丢失
事件10：丢失存档的Redo log文件
如果存档的redo log文件丢失，应该马上进行一次冷备份、最好也进行一次全数据库导出、没有丢失的存档redo log文件的任何恢复都将是不完全的、
事件11：丢失活动的回滚段
这里指的是丢失一个回滚段的一个数据文件、这是一个危急的恢复过程，它主要是在于保存活动的事务，
这里假定数据库已经起来，而你想保存当前运行的事务。要使用以下的恢复过程，数据库必须运行在archivelog模式下。
可以使用以下步骤恢复：
1、不要关闭数据库、对于这种事件，数据库启动比关闭更容易解决问题、
2、令属于该数据文件中的全部回滚段离线
3、删除全部离线的回滚段
4、在上面的第2步中，如果回滚段中有活动的事务，你将不能令它离线、可运行以下的查询来查看哪些事物是活动的：
SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = 'tablespace_name' AND
SEGMENT_ID = USN;
如果上面的查询没有结果，那么所有的回滚段都是离线的，但是，如果上面的查询返回一行或者多行，并且其状态为PENDING OFFLINE，那么可检查这些回滚段的ACTIVE_TX列、带有0值的回滚段将很快会离线；但是，非0的值表示上面有活动的事务，它们需要被提交或者回滚、
5、处理活动的事务、执行以下的查询来查看哪些用户的事务被指派到该回滚段：
SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME ”ROLLBACK“
FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
WHERE R.NAME IN ('pending_rollback1','pending_rollback2', .... 'pending_rollbackN') AND
S.TADDR = T.ADDR AND
T.XIDUSN = R.USN;
在知道哪些用户在”pending offline“的回滚段上有活动的事务后，可以要求他们提交或者回滚他们的事务，或者可以使用以下的命令杀掉它们的进程：
ALTER SYSTEM KILL SESSION 'sid, serial#';
6、在你处理完所有活动的事务后，执行以下的步骤：
丢弃表空间及其中的全部内容
重新创建回滚表空间
重新创建回滚段，并且令它们在线
事件12：丢失全部的回滚段
在这种事件下，将丢失全部活动的事务，并且需要重新创建回滚段。这样大的问题可能是由于一个硬件问题造成的，可以采用以下的步骤恢复：
1、关闭数据库
2、使用DBVERIFY验证全部的数据文件
3、解决其它的硬件问题或者数据文件损坏
4、以startup mount的方式启动数据库实例
5、在数据库上执行媒体恢复
6、打开数据库
7、按需要创建新的回滚段
事件13：导出文件损坏
如果导出文件不能用了，那么应该冷备份数据库并且进行一个全的数据库导出、这是假定数据库自身没有问题、如果数据库也损坏了，那么应该执行以下的步骤：
1、ORA-1157错误信息通常都表示一个或者多个的数据文件损坏了。查明哪些表受到影响，它们应该是错误信息中指明的数据文件中的表格
2、跳过坏的数据块，将数据由表格中选择到临时表格中、
3、丢弃损坏的表
4、将临时表重命名为丢弃的表
5、重新建立受影响表上的全部索引
6、使用VALIDATE STRUCTURE CASCADE的选项来分析全部损坏的表
要注意的是损坏块中数据将会丢失并且不能恢复
事件14：在热备份时关机
如果在热备份正在进行的时候突然关机，其中的一些表空间将可能处在备份模式、当你尝试打开数据库时，它将只能mount，并且指示某些表空间处于热备份模式、由于数据库不能打开，你将不能让表空间脱离热备份模式、你可以使用以下的步骤恢复：
1、startup mount数据库
2、查询v$backup以查看哪些数据文件处于ACTIVE状态、
3、通过使用命令ALTER DATABASE DATAFILE END BACKUP.来将这些数据文件脱离备份模式
4、打开数据库
事件15：恢复到某个特别的时间点
以下的步骤可用来执行point-in-time恢复
1、关闭数据库实例
2、以NOMOUNT的状态启动数据库实例
3、使用UNTIL的选项来恢复数据库
4、打开数据库
5、Shutdown NORMAL
6、启动数据库实例
事件16：恢复到一个特别的事件或者活动
可以使用以下的步骤来恢复：
1、关闭数据库实例
2、以NOMOUNT状态启动数据库实例；
3、使用UNTIL CANCEL来恢复数据库，提供存档的redo log文件请求直到该活动/事件为止
4、输入CANCEL来取消恢复
5、打开数据库；
6、使用NORMAL的模式来关闭数据库
7、启动数据库实例
结论
高可用性对于任何的商业都是很重要的，ORACLE DBA可以通过一些计划以确保停机时间最小化、这篇文章讨论了不同的策略可以达到这个目的。
oracle|备份|恢复
一. 理解什么是数据库恢复
当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失，因此当发生上述故障后，希望能重构这个完整的数据库，该处理称为数据库恢复。恢复过程大致可以分为复原(Restore)与恢复(Recover)过程。
数据库恢复可以分为以下两类：
1.1实例故障的一致性恢复
当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况Oracle在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：
1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，
包括对回滚段的内容恢复。
2） 回滚未提交的事务，按步1重新生成回滚段所指定的操作。
3） 释放在故障时正在处理事务所持有的资源。
4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
1.2介质故障或文件错误的不一致恢复
介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都是不一致的，需要DBA手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行的归档方式和备份方式。
（1） 完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全恢复可使用，其决定于毁坏文件和数据库的可用性。
（2） 不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。
挥诔废(CANCEL)恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
挥谑奔(TIME)和基于修改(SCN)的恢复：如果DBA希望恢复到过去的某个指定点，是一种理想的不完全介质恢复，一般发生在恢复到某个特定操作之前，恢复到如意外删除某个数据表之前。
第二章. 数据库恢复案例测试环境
2.1 数据库环境
以下的所有案例都是通过测试经过，环境为：
OS：Windows Server
DB：Oracle 816
DBNAME：TEST
数据文件：
SQL> select file#,status,enabled,name from v$datafile;
FILE# STATUS ENABLED NAME
----------------------------------------------------------------
1 SYSTEM READ WRITE D:OracleORADATATEST YSTEM01.DBF
2 ONLINE READ WRITE D:OracleORADATATESTRBS01.DBF
3 ONLINE READ WRITE D:OracleORADATATESTUSERS01.DBF
4 ONLINE READ WRITE D:OracleORADATATESTTEMP01.DBF
5 ONLINE READ WRITE D:OracleORADATATESTTOOLS01.DBF
6 ONLINE READ WRITE D:OracleORADATATESTINDX01.DBF
控制文件：
SQL> select * from v$controlfile;
STATUS NAME
---------------------------------------------------------------------
D:OracleORADATATESTCONTROL01.CTL
D:OracleORADATATESTCONTROL02.CTL
D:OracleORADATATESTCONTROL03.CTL
联机日志：
SQL> select * from v$logfile;
GROUP# STATUS MEMBER
---------------------------------------------------------------------
1 STALE D:OracleORADATATESTREDO01.LOG
2 D:OracleORADATATESTREDO02.LOG
3 STALE D:OracleORADATATESTREDO03.LOG
2.2 数据库备份脚本
冷备份脚本:
rem script.:coldbak.sql
rem creater:chenjiping
rem date:5.8.
rem desc:offline full backup database
--connect database
connect internal/password;
--shutdown database
shutdown immediate;
--Copy Data file
!xcopy d:Oracleoradatatest*.dbf d:database/H/R;
--Copy Control file
!xcopy d:Oracleoradatatest*.ctl d:database/H/R;
--Copy Log file
!xcopy d:Oracleoradatatest*.log d:database/H/R;
--startup database
startup;
说明：
1、以上脚本在数据库关闭状态下备份数据库所有的数据文件，联机日志，控制文件（在一个目
录下），如果成功备份，所有文件是一致的;
2、没有备份参数文件，参数文件可以另外备份，没有必要每次都备份，只需要在改变设置后备份一次;
3、如果以上命令没有成功依次执行，那么备份将是无效的，如连接数据库不成功，那么肯定关闭数据库也不成功，那么备份则无效;
4、冷备份建议下人工干预下执行。
数据库OS热全备份脚本
rem script.:hotbak.sql
rem creater:chenjiping
rem date:5.8.2003
rem desc:backup all database datafile in archive
--connect database
connect internal/password;
--archive
alter system archive log current;
--start
alter tablespace system begin backup;
!xcopy d:Oracleoradatatest ystem01.dbf d:databak/H/R;
alter tablespace system end backup;
alter tablespace rbs begin backup;
!xcopy d:Oracleoradatatestrbs01.dbf d:databak/H/R;
alter tablespace rbs end backup;
alter tablespace users begin backup;
!xcopy d:Oracleoradatatestusers01.dbf d:databak/H/R;
alter tablespace users end backup;
alter tablespace tools begin backup;
!xcopy d:Oracleoradatatesttools01.dbf d:databak/H/R;
alter tablespace tools end backup;
alter tablespace indx begin backup;
!xcopy d:Oracleoradatatestindx01.dbf d:databak/H/R;
alter tablespace indx end backup;
--end
--bak control file
--binary
alter database backup controlfile to 'd:databakcontrolbinbak.000';
--ascii
alter database backup controlfile to trace;
alter system archive log current;
说明：
1、热备份必须在数据库归档方式下才可以运行；
2、以上脚本可以在数据库运行状态下备份数据库所有的数据文件（除了临时数据文件），没有必要备份联机日志；
3、归档日志至少需要一次完整备份之后的所有日志；
4、如果以上命令没有成功依次执行，那么备份也是无效的，如连接数据库不成功，那么备份则无效。
RMAN备份只讲叙有恢复目录的情况，如果没有恢复目录，情形大致相似。以下是RMAN的热备份全备份的脚本：
# script.:bakup.rcv
# creater:chenjiping
# date:5.8.2003
# desc:backup all database datafile in archive with rman
# connect database
connect rcvcat rman/rman@back;
connect target internal/virpure;
# start backup database
run{
allocate channel c1 type disk;
backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
include current controlfile;
sql 'alter system archive log current';
release channel c1;
}
# end
说明：
1、 数据库必须运行在归档模式下;
2、 RMAN将自动备份数据文件，运行可靠;
3、 归档日志另外备份处理，但至少需要保存一次备份来的日志;
4、 没有必要用RMAN做冷备份，效果不好。
以上举例说明了数据库的恢复案例的测试环境与部分备份测试脚本，其它的备份脚本可以根据以上脚本演变而来或在案例中加以说明。
数据库的自动实例将不加以说明，这里只举例说明媒体错误或人为错误造成的恢复可能。
以上包括以下案例都是在WINDOWS+Oracle816上测试验证的，在不同的操作系统与不同的数据库版本中略有差别。
第三章. 了解与恢复相关的信息
1、 理解报警日志文件
报警日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般令名规则为
报警日志文件的路径是根据初始化参数background_dump_dest来决定的，如在我的机器上，该参数值为 D:Oracleadmintestbdump，那么，你就可以在该路径下找到该文件。
2、 后台进程跟踪文件
后台进程跟踪文件的路径与报警日志文件的路径一致，在某些情况下，你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。如在数据库需要恢复的时候，报警日志文件中常有这样的语句：
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
通过提示的DBWR跟踪文件，可以查询到更详细的信息。
3、 v$recover_file与v$recovery_log
这是两个动态性能视图，可以在mount下查看，通过这两个视图，你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。
第四章. 数据库恢复案例
4.1非归档模式下的备份与恢复
备份方案：采用OS冷备份
1. 连接数据库并创建测试表
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2. 备份数据库
SQL> @coldbak.sql 或在DOS下 svrmgrl @coldbak.sql
3. 再插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
-------------------
1
2
4. 关闭数据库
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
5. 毁坏一个或多个数据文件，如删除user01.dbf
C:>del D:OracleORADATATESTUSERS01.DBF
模拟媒体毁坏。
6. 重新启动数据库，会发现如下错误
SQL> startup
Oracle instance started.
Total System Global Area 10364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
在报警文件中，会有更详细的信息
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
7. 拷贝备份复原到原来位置(restore过程)
C:>xcopy d:database*.* d:Oracleoradatatest/H/R/S
8. 打开数据库，检查数据
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
这里可以发现，数据库恢复成功，但在备份之后与崩溃之前的数据丢失了。
说明：
1、非归档模式下的恢复方案可选性很小，一般情况下只能有一种恢复方式，就是数据库的冷备
份的完全恢复，仅仅需要拷贝原来的备份就可以(restore)，不需要recover；
2、这种情况下的恢复，可以完全恢复到备份的点上，但是可能是丢失数据的，在备份之后与崩溃之前的数据将全部丢失；
3、不管毁坏了多少数据文件或是联机日志或是控制文件，都可以通过这个办法恢复，因为这个恢复过程是Restore所有的冷备份文件，而这个备份点上的所有文件是一致的，与最新的数据库没有关系，就好比把数据库又放到了一个以前的”点“上；
4、对于非归档模式下，最好的办法就是采用OS的冷备份，建议不要用RMAN来作冷备份，效果不好，因为RMAN不备份联机日志，restore不能根本解决问题；
5、如果没有备份联机日志，如RMAN的备份，就需要利用不完全恢复(until cancel)的方法来重新创建联机日志文件。
4.2归档模式下丢失或损坏一个数据文件
4.2.1 OS备份方案
在归档方式下损坏或丢失一个数据文件，如果存在相应的备份与该备份以来的归档日志，恢复还是比较简单的，可以作到尽量少的Down机时间，并能作到数据库的完全恢复。
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
--------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATESTUSERS01.DBF
模拟媒体毁坏。
5、 启动数据库错误，脱机该数据文件：
SQL> startup
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
还可以查看报警文件（见上一个恢复案例）或动态视图v$recover_file
如SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
3 ONLINE 1013500 2003-05-07
脱机数据文件
SQL> alter database datafile 3 offline drop;
Database altered.
6、 打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机:
SQL> alter database open;
Database altered.
拷贝备份从备份处
copy d:databak users01.dbf d:Oracleoradatatest;
恢复该数据文件
SQL> recover datafile 3;
ORA-00279: change 1053698 generated at 05/07/2003 17:51:26 needed for
thread 1
ORA-00289: suggestion :
D:OracleORADATATESTARCHIVETESTT001S00304.ARC
ORA-00280: change 1053698 for thread 1 is in sequence #304
Specify log: {
AUTO
ORA-00279: change 1053701 generated at 05/07/2003 17:51:39 needed for
thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00305.ARC
ORA-00280: change 1053701 for thread 1 is in sequence #305
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00304.ARC' no longer needed for this recovery Log applied.
Media recovery complete.
恢复成功，联机该数据文件
SQL> alter database datafile 3 online;
Database altered.
7、 检查数据库的数据（完全恢复）
SQL> select * from test;
A
--------------------------------
1
2
说明：
1、采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失;
2、可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）；
3、如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（第5步中需要对数据文件一一脱机，第6步中需要对数据文件分别恢复），也可以采用整个数据库的恢复方法；
4、如果是系统表空间的损坏，不能采用此方法。
4.2.2 RMAN备份方案
RMAN也可以进行联机备份，而且备份与恢复方法将比OS备份更简单可靠。
1、连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库表空间users
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> backup tag 'tsuser' format 'd:backuptsuser_%u_%s_%p'
4> tablespace users;
5> release channel c1;
6> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=16 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03023: executing command: backup
RMAN-08008: channel c1: starting full datafile backupset
RMAN-08502: set_count=5 set_stamp=494177612 creation_time=16-MAY-03
RMAN-08010: channel c1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=D:OracleORADATATESTUSER01.DBF
RMAN-08013: channel c1: piece 1 created
RMAN-08503: piece handle=D:BACKUPTSUSER_05EN93AC_5_1 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:01
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL>r
1* alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATESTUSER01.DBF
5、 启动数据库，检查错误
SQL> startup
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSER01.DBF'
6、 先打开数据库
SQL> alter database datafile 3 offline drop;
Database altered.
SQL> alter database open;
Database altered.
7、 恢复该表空间
恢复脚本可以是恢复单个数据文件
run{
allocate channel c1 type disk;
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
release channel c1;
}
也可以是,恢复表空间
run{
allocate channel c1 type disk;
restore tablespace users;
recover tablespace users;
sql 'alter database datafile 3 online';
release channel c1;
}
过程如下：
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> restore datafile 3;
4> recover datafile 3;
5> sql 'alter database datafile 3 online';
6> release channel c1;
7> }
//输出内容冗长，省略--编者
RMAN>
8、 检查数据是否完整
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、RMAN也可以实现单个表空间或数据文件的恢复，恢复过程可以在mount下或open方式下，如果在open方式下恢复，可以减少down机时间;
2、如果损坏的是一个数据文件，建议offline并在open方式下恢复;
3、这里可以看到，RMAN进行数据文件与表空间恢复的时候，代码都比较简单，而且能保证备份与恢复的可靠性，所以建议采用RMAN的备份与恢复.
4.3丢失多个数据文件，实现整个数据库的恢复.
4.3.1 OS备份方案
OS备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库，备份除临时数据文件后的所数据文件
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATEST YSTEM01.DBF
C:>del D:OracleORADATATESTINDX01.DBF
C:>del D:OracleORADATATESTTOOLS01.DBF
C:>del D:OracleORADATATESTRBS01.DBF
模拟媒体毁坏（这里删除多个数据文件）
5、 启动数据库，检查错误
SQL> STARTUP
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
详细信息可以查看报警文件
ORA-1157 signalled during: ALTER DATABASE OPEN...
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 'D:OracleORADATATESTRBS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: 'D:OracleORADATATESTTOOLS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: 'D:OracleORADATATESTINDX01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
通过查询v$recover_file可以看到
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
1 ONLINE FILE NOT FOUND 0
2 ONLINE FILE NOT FOUND 0
5 ONLINE FILE NOT FOUND 0
6 ONLINE FILE NOT FOUND 0
有四个数据文件需要恢复
6、 拷贝备份回到原地点(restore)，开始恢复数据库(recover)
restore过程:
C:>copy D:DATABAK YSTEM01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTINDX01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTTOOLS01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTRBS01.DBF.DBF D:OracleORADATATEST
Recover过程:
SQL> recover database;
ORA-00279: change 1073849 generated at 05/08/2003 08:58:35 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00311.ARC
ORA-00280: change 1073849 for thread 1 is in sequence #311
Specify log: {
auto
ORA-00279: change 1073856 generated at 05/08/2003 09:03:27 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00312.ARC
ORA-00280: change 1073856 for thread 1 is in sequence #312
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00311.ARC' no
longer needed for this recovery
ORA-00279: change 1073858 generated at 05/08/2003 09:11:43 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00313.ARC
ORA-00280: change 1073858 for thread 1 is in sequence #313
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00312.ARC' no
longer needed for this recovery
ORA-00279: change 1073870 generated at 05/08/2003 09:11:46 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00314.ARC
ORA-00280: change 1073870 for thread 1 is in sequence #314
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00313.ARC' no
longer needed for this recovery
Log applied.
Media recovery complete.
7、 打开数据库，检查数据库的数据（完全恢复）
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、只要有备份与归档存在，就可以实现数据库的完全恢复（不丢失数据）;
2、适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、恢复过程在mount下进行，如果恢复成功，再打开数据库，down机时间可能比较长一些。
4.3.2 RMAN备份方案
RMAN备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、备份数据库
DOS下 C:> rman cmdfile=bakup.rcv msglog=backup.log;
以下是backup.log内容。
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> # script.:bakup.rcv
2> # creater:chenjiping
3> # date:5.8.2003
4> # desc:backup all database datafile in archive with rman
5>
6> #connect database
7> connect rcvcat rman/rman@back;
8> connect target internal/virpure;
9>
10> #start backup database
11> run{
12> allocate channel c1 type disk;
13> backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
14> include current controlfile;
15> sql 'alter system archive log current';
16> release channel c1;
17> }
18> #end
19>
RMAN-06008: connected to recovery catalog database
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=15 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03023: executing command: backup
RMAN-08008: channel c1: starting full datafile backupset
RMAN-08502: set_count=4 set_stamp=494074368 creation_time=15-MAY-03
RMAN-08010: channel c1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00002 name=D:OracleORADATATESTRBS01.DBF
RMAN-08522: input datafile fno=00001 name=D:OracleORADATATEST YSTEM01.DBF
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00005 name=D:OracleORADATATESTTOOLS01.DBF
RMAN-08522: input datafile fno=00004 name=D:OracleORADATATESTTEMP01.DBF
RMAN-08522: input datafile fno=00006 name=D:OracleORADATATESTINDX01.DBF
RMAN-08522: input datafile fno=00003 name=D:OracleORADATATESTUSER01.DBF
RMAN-08013: channel c1: piece 1 created
RMAN-08503: piece handle=D:BACKUPFULL04EN5UG0_4_1 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:01:16
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter system archive log current
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
Recovery Manager complete.
到这里表示备份成功。
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL>alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATEST YSTEM01.DBF
C:>del D:OracleORADATATESTINDX01.DBF
C:>del D:OracleORADATATESTTOOLS01.DBF
C:>del D:OracleORADATATESTRBS01.DBF
5、启动数据库，检查错误
SQL> STARTUP
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
查询v$recover_file
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
1 ONLINE FILE NOT FOUND 0
2 ONLINE FILE NOT FOUND 0
5 ONLINE FILE NOT FOUND 0
6 ONLINE FILE NOT FOUND 0
可以知道有四个数据文件需要恢复.
6、利用RMAN进行恢复
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database;
5> sql 'alter database open';
6> release channel c1;
7> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=17 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=4 set_stamp=494074368 creation_time=15-MAY-03
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to D:OracleORADATATEST YSTEM01.DBF
RMAN-08523: restoring datafile 00002 to D:OracleORADATATESTRBS01.DBF
RMAN-08523: restoring datafile 00003 to D:OracleORADATATESTUSER01.DBF
RMAN-08523: restoring datafile 00004 to D:OracleORADATATESTTEMP01.DBF
RMAN-08523: restoring datafile 00005 to D:OracleORADATATESTTOOLS01.DBF
RMAN-08523: restoring datafile 00006 to D:OracleORADATATESTINDX01.DBF
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=D:BACKUPFULL04EN5UG0_4_1 tag=DBFULL params=NULL
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-03022: compiling command: recover(4)
RMAN-06050: archivelog thread 1 sequence 327 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00327.ARC
RMAN-06050: archivelog thread 1 sequence 328 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00328.ARC
RMAN-06050: archivelog thread 1 sequence 329 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00329.ARC
RMAN-06050: archivelog thread 1 sequence 330 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00330.ARC
RMAN-03023: executing command: recover(4)
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00327.ARC thread=1 sequence=327
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00328.ARC thread=1 sequence=328
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
7、 检查数据库的数据（完全恢复）
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、只要有备份与归档存在，RMAN也可以实现数据库的完全恢复（不丢失数据）;
2、同OS备份数据库恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、目标数据库在mount下进行，如果恢复成功，再打开数据库;
4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用RMAN进行数据库的备份，
4.4 不完全恢复案例
4.4.1 OS备份下的基于时间的恢复
不完全恢复可以分为基于时间的恢复，基于改变的恢复与基于撤消的恢复，这里已基于时间的恢复为例子来说明不完全恢复过程。
基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。
1、 连接数据库，创建测试表并插入记录:
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库，这里最好备份所有的数据文件，包括临时数据文件:
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
或冷备份也可以
3、 删除测试表，假定删除前的时间为T1，在删除之前，便于测试，继续插入数据并应用到归
档。
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
Statement processed.
SQL> alter system switch logfile;
Statement processed.
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YY
-------------------
2003-05-21 14:43:01
SQL> drop table test;
Table dropped.
4、 准备恢复到时间点T1，找回删除的表，先关闭数据库:
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
5、 拷贝刚才备份的所有数据文件回来
C:>copy D:DATABAK*.DBF D:OracleORADATATEST
6、 启动到mount下
SQL> startup mount;
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
7、 开始不完全恢复数据库到T1时间
SQL> recover database until time '2003-05-21:14:43:01';
ORA-00279: change 30944 generated at 05/21/2003 14:40:06 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00191.ARC
ORA-00280: change 30944 for thread 1 is in sequence #191
Specify log: {
auto
Log applied.
Media recovery complete.
8、 打开数据库，检查数据
SQL> alter database open resetlogs;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的;
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例;
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后再用以前的备份恢复是很难了;
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间;
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统.
4.4.2 RMAN备份下的基于改变的恢复
以上用OS备份说明了一个基于时间的恢复，现在用RMAN说明一个基于改变的恢复
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=874705288)
RMAN> run{
2> allocate channel c1 type disk;
3> backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
4> include current controlfile;
5> sql 'alter system archive log current';
6> release channel c1;
7> }
//屏幕输出内容冗长，省略--编辑
RMAN>
3、 删除测试表，在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的scn号。
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
Statement processed.
SQL> alter system switch logfile;
Statement processed.
SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;
SCN
----------
31014
SQL> drop table test;
Table dropped.
4、 准备恢复到SCN 31014，先关闭数据库，然后启动到mount下
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount;
5、 开始恢复到改变点SCN 31014
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn 31014;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=10 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=1 set_stamp=494613682 creation_time=21-MAY-03
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to D:OracleORADATATEST YSTEM01.DBF
RMAN-08523: restoring datafile 00002 to D:OracleORADATATESTRBS01.DBF
RMAN-08523: restoring datafile 00003 to D:OracleORADATATESTUSERS01.DBF
RMAN-08523: restoring datafile 00004 to D:OracleORADATATESTTEMP01.DBF
RMAN-08523: restoring datafile 00005 to D:OracleORADATATESTTOOLS01.DBF
RMAN-08523: restoring datafile 00006 to D:OracleORADATATESTINDX01.DBF
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=D:BACKUPFULL01ENMD5I_1_1 tag=DBFULL params=NULL
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-03022: compiling command: recover(4)
RMAN-06050: archivelog thread 1 sequence 191 is already on disk as file D:ORACL
EORADATATESTARCHIVETESTT001S00191.ARC
RMAN-06050: archivelog thread 1 sequence 192 is already on disk as file D:ORACL
EORADATATESTARCHIVETESTT001S00192.ARC
RMAN-03023: executing command: recover(4)
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00191.AR
C thread=1 sequence=191
RMAN-08515:archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00192.ARC
Thread=1 sequence=192
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: ALTER DATABASE OPEN RESETLOGS
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
6、 检查数据
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
可以看到，表依然存在。
说明：
1、 RMAN也可以实现不完全恢复，方法比OS备份恢复的方法更简单可靠；
2、 RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可以指定恢复到哪个日志序列，如
run {
allocate channel ch1 type disk;
allocate channel ch2 type 'sbt_tape';
set until logseq 1234 thread 1;
restore controlfile to '$Oracle_HOME/dbs/cf1.f' ;
replicate controlfile from '$Oracle_HOME/dbs/cf1.f';
alter database mount;
restore database;
recover database;
sql ”ALTER DATABASE OPEN RESETLOGS“;
}
3、 与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs；
4、 基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一个改变号(SCN)，在正常生产中，获取SCN的办法其实也有很多，如查询数据库字典表(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。
第五章 其它恢复案例
5.1 损坏联机日志的恢复方法
5.1.1 损坏非当前联机日志
大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。
1、启动数据库，遇到ORA-00312 or ORA-00313错误，如
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、 查看V$log视图
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT
可以知道，该组是非当前状态，而且已经归档。
3、 用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档，则需要用
SQL>alter database clear unarchived logfile group 1;
4、 打开数据库，重新备份数据库
SQL>alter database open;
说明：
1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear；
2、建议clear，特别是强行clear后作一次数据库的全备份；
3、此方法适用于归档与非归档数据库。
5.1.2 损坏当前联机日志
归档模式下当前日志的损坏有两种情况，
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损 坏就可以直接用alter database clear unarchived logfile group n来重建。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法:
A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份
B. 通过强制性恢复，但是可能导致数据库不一致。
下面分别用来说明这两种恢复方法：
5.1.2.1 通过备份来恢复
1、 打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、 查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
--------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、 发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
4、 拷贝有效的数据库的全备份，并不完全恢复数据库：
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽量恢复可以利用的归档日志，然后重新
recover database until cancel
这次输入cancel，完成不完全恢复，也就是说恢复两次。
如：
SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;
5、 利用alter database open resetlogs打开数据库.
说明：
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据;
2、这种方法适合于归档数据库并且有可用的数据库全备份;
3、恢复成功之后，记得再做一次数据库的全备份;
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
5.1.2.2 如果没有备份，进行强制性恢复
1、 打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、 查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、 发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
4、 把数据库down掉
SQL>shutdown immediate
5、 在init
_allow_resetlogs_corruption=TRUE
6、 重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错，不再理会，发出
SQL>alter database open resetlogs;
7、 数据库被打开后，马上执行一个full export
8、 shutdown数据库,去掉_all_resetlogs_corrupt参数
9、 重建库
10、import并完成恢复
11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致；
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据；
3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析；
4、全部完成后做一次数据库的全备份；
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
5.2 损坏控制文件的恢复方法
5.2.1 损坏单个控制文件
损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。
1、 控制文件损坏，最典型的就是启动数据库出错，不能mount数据库
SQL>startup
ORA-00205: error in identifying controlfile, check alert log for more info
查看报警日志文件，有如下信息
alter database mount
Mon May 26 11:59:52 2003
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
2、 停止数据库：
SQL>shutdown immediate
3、 拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。
4、 重新启动数据：
SQL>startup
说明：
1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的
拷贝一个好的就可以了；
2、建议镜相控制文件在不同的磁盘上；
3、建议多做控制文件的备份，长期保留一份由alter database backup control file to trace产生的控制文件的文本备份。
5.2.2 损坏全部控制文件
损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。
同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。
以下是详细重新创建控制文件的步骤：
1、 关闭数据库
SQL>shutdown immediate;
2、 删除所有控制文件，模拟控制文件的丢失
3、 启动数据库，出现错误，并不能启动到mount下
SQL>startup
ORA-00205: error in identifying controlfile, check alert log for more info
查看报警日志文件，有如下信息
alter database mount
Mon May 26 11:53:15 2003
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
4、 关闭数据库
SQL>shutdown immediate;
5、 在internal或sys下运行如下创建控制文件的脚本，注意完整列出联机日志或数据文件的路径，或修改由alter database backup control file to trace备份控制文件时产生的脚本，去掉多余的注释即可。
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE ”TEST“ NORESETLOGS NOARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'D:OracleORADATATESTREDO01.LOG' SIZE 1M,
GROUP 2 'D:OracleORADATATESTREDO02.LOG' SIZE 1M,
GROUP 3 'D:OracleORADATATESTREDO03.LOG' SIZE 1M
DATAFILE
'D:OracleORADATATEST YSTEM01.DBF',
'D:OracleORADATATESTRBS01.DBF',
'D:OracleORADATATESTUSERS01.DBF',
'D:OracleORADATATESTTEMP01.DBF',
'D:OracleORADATATESTTOOLS01.DBF',
'D:OracleORADATATESTINDX01.DBF'
CHARACTER SET ZHS16GBK;
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
--if the last shutdown was not normal or immediate
--noarchive
-- RECOVER DATABASE UNTIL CANCELUSING BACKUP CONTROLFILE
--archive
-- RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
-- Database can now be opened normally.
ALTER DATABASE OPEN;
--if recover database until cancel
--ALTER DATABASE OPEN RESETLOGS;
6、 如果没有错误，数据库将启动到open状态下。
说明：
1、重建控制文件用于恢复全部数据文件的损坏，需要注意其书写的正确性，保证包含了所有的数据文件与联机日志；
2、经常有这样一种情况，因为一个磁盘损坏，我们不能再恢复(store)数据文件到这个磁盘，因此在store到另外一个盘的时候，我们就必须重新创建控制文件，用于识别这个新的数据文件，这里也可以用这种方法用于恢复。
5.3 损坏回滚数据文件的恢复方法
回滚段表空间中的一个数据文件丢失或者损坏导致数据库无法识别它，在启动数据库的时候会出现ORA-1157, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7360。在关闭数据库的时候(normal或者immediate)会出现ORA-1116, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7368。
感谢Coolyl的辛勤工作，关于回滚段的大部分内容都是摘自他在itpub的文章。
5.3.1 损坏数据文件，但数据库处于Open状态
如果你发现有回滚段的数据文件丢失或者损坏了，而此时的数据库是处于打开的状态下并且在运行，就千万不要关闭数据库了，因为在大多数的情况下打开的时候比关闭的时候好解决问题一些。
一般也是存在有两种情况：
A、是offline丢失或损坏的数据文件，然后从一个备份中恢复，执行介质恢复以保持一致性。但是这种情况要求数据库是归档方式下才可以采用的。
B、是offline那个存在丢失或损坏的数据文件所在的整个回滚段表空间，然后删除整个回滚段表空间并重建，但是你必须要杀掉那些在回滚段中已经激活的用户进程才可以offline的。
通常第一种情况就比较简单实现，但是更多的用户事务将会出错并且回滚。
A的具体步骤：
1、 offline丢失或损坏的数据文件
ALTER DATABASE DATAFILE '
2、 从一个有效的备份中恢复。
3、 执行以下查询：
SELECT V1.GROUP#, MEMBER, SEQUENCE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这个将列出你的所有redolog文件以及它们所代表的sequence numbers。
4、 恢复数据文件。
RECOVER DATAFILE '
5、 确信你应用了所有的redolog文件，直至出现提示信息”Media recovery complete“。
6、 online那个数据文件。
ALTER DATABASE DATAFILE '
B的具体步骤：
1、 offline存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段。
ALTER ROLLBACK SEGMENT
2、 检测当然回滚段的状态。
SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '';
3、 删除所有offline的回滚段
DROP ROLLBACK SEGMENT
4、 处理那些online状态的回滚段。
重新执行第二步的查询
如果你已经执行过offline操作的回滚段状态仍然是online，则说明这个回滚段内有活动的事务。你要接着查询
SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '' AND SEGMENT_ID = USN;
如果没有返回结果，则证明存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段都已经被offline了，然后重新执行第二步，第三步。如果查询有结果返回，则状态应该是”PENDING OFFLINE“.接着查看ACTIVE_TX列，如果值为0，则表明此回滚段中已经没有未处理的事务了，很快就会被offline的，然后等它offline后重新执行2，3步后跳至第六步。如果值大于0，则继续到第五步。
5、 强制那些包含活动事务的回滚段offline。
活动的事务应该被提交或者回滚，执行下面的查询看看哪些用户占用了回滚段：
SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME ”ROLLBACK“
FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
WHERE R.NAME IN ('
', ... ,
'
')
AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;
最好能直接联系到那些user让他们自己去回滚或者提交事务，如果不能做到的话，那就只能强制性的杀掉进程了。
ALTER SYSTEM KILL SESSION '
杀掉进程后再过一段时间后回滚段会自动清除那些事务，然后就可以回到第二步继续查询了。
6、 删除回滚段。
DROP TABLESPACE INCLUDING CONTENTS;
7、 重建回滚段并online它们。
说明：
1、数据库如果是open状态，就可以直接在open状态下解决问题，没有必要停下数据库，增加down机时间；
2、不管上上面那种恢复方法都是正常性的恢复，不会引起数据的不一致或错误。
5.3.2数据库关闭，但是数据文件中没有活动事务
这种情况下最简单的方法就是offline drop掉这个坏了的或者丢失的数据文件，然后以restricted模式打开数据库然后删除并且重建包含损坏文件的回滚段表空间。
具体步骤如下：
1、 确定数据库是正常的关闭的。方法是可以去查看alert文件，到最后看是否有如下信息：
”alter database dismount
Completed: alter database dismount“
如果有的话，就证明数据库是正常关闭的，否则就不能用这个方法去恢复。
2、 修改init参数文件，移去ROLLBACK_SEGMENTS中包含的损坏数据文件的回滚段表空间的回滚段，如果你不能确定哪些回滚段是坏的，简单的方法是你可以注释掉整个ROLLBACK_SEGMENTS。
3、 以restricted模式去mount数据库。
STARTUP RESTRICT MOUNT
4、 offline drop掉那个坏的数据文件
ALTER DATABASE DATAFILE '
5、 打开数据库
ALTER DATABASE OPEN
如果你看到如下信息”Statement processed“，则跳到第7步，如果你看到ORA-604, ORA-376, and ORA-1110的错误信息，继续第6步。
6、 正常的关闭数据库，然后在init文件中注释掉ROLLBACK_SEGMENTS，并加入隐含参数
_corrupted_rollback_segments = (
然后以restricted模式打开数据库
STARTUP RESTRICT
7、 删除掉那个包含损坏文件的回滚段表空间。
DROP TABLESPACE INCLUDING CONTENTS;
8、 重建回滚段表空间，记得创建后要把回滚段都online。
9、 重新使数据库对所有用户可用。
ALTER SYSTEM DISABLE RESTRICTED SESSION;
10、然后正常关闭数据库，修改init文件，如果开始只是注释掉了ROLLBACK_SEGMENTS的，就去掉注释即可，如果加了隐含参数的，注释掉它，并在ROLLBACK_SEGMENTS加入所有的回滚段。
11、正常启动数据库：
Startup
说明：
1、这种方法的前提条件是数据库是正常关闭（不是abort）可用；
2、这种方法是正常方法，不会引起数据错误。
5.3.3 数据库关闭，数据文件中有活动事务，没有可用备份。
一般造成这种原因的情况是采用了shutdown abort或其它原因异常关机（如断电）导致的。
1、开启一个事务
SQL> set transaction use rollback segment rbs0;
Transaction set.
SQL> insert into test (a) values (1);
1 row created.
2、异常关闭
SQL> shutdown abort;
Oracle instance shut down.
3、删除rbs的一个数据文件
C:>del D:Oracleoradatachenrbs01.
4、修改INIT
rollback_segments=(system)
添加_corrupted_rollback_segments=(rbs0,rbs1,rbs2……)
5、SQL>Startup mount
6、SQL>alter database datafile 'd:Oracleoradatat8irbs01.dbf' offline drop;
数据库已更改。
7、SQL>recover database ；
完成介质恢复。
8、SQL>alter database open ;
数据库已更改。
9、SQL>select * from v$rollname;
USN NAME
---- -------
0 SYSTEM
10、SQL>select segment_name,tablespace_name,status
FROM dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
----------- ------ ------------------------------------
SYSTEM SYSTEM ONLINE
RBS0 RBS NEEDS RECOVERY
RBS1 RBS NEEDS RECOVERY
RBS2 RBS NEEDS RECOVERY
11、SQL>drop rollback segment rbs0;
重算段已丢弃。
SQL>drop rollback segment rbs1;
重算段已丢弃。
SQL>drop rollback segment rbs2;
重算段已丢弃。
12、SQL>select segment_name,tablespace_name,status
FROM dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
-------------------------------------
SYSTEM SYSTEM ONLINE
13、SQL>drop tablespace rbs including contents;
表空间已丢弃。
14、重建新的回滚表空间及回滚段，并联机。
15、SQL>shutdown abort
16、再修改INIT
rollback_segments=(rbs0,rbs1,rbs2)
将_corrupted_rollback_segments=(rbs0,rbs1,rbs2)去掉。
17、SQL>startup
说明：
1、这种办法是万不得以的时候使用的方法，如果有备份，都建议从备份上进行恢复；
2、这种方法恢复的数据库，可能会引起数据库的数据错误；
3、恢复成功以后，建议exp/imp数据，并重新分析检查数据库。
5.3.4 数据库关闭，数据文件中有活动事务，从备份恢复
1、从一个有效的备份中恢复损坏的数据文件。
2、mount数据库。
3、执行以下查询：
SELECT FILE#, NAME, STATUS FROM V$DATAFILE;
如果发现要恢复的文件是offline状态的话，要先online它：
ALTER DATABASE DATAFILE '
4、执行以下查询
SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这个将列出redlog文件所代表的sequence和first change numbers。
5、如果数据库是非归档情况下，执行以下查询：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果CHANGE#大于最小的redolog文件的FIRST_CHANGE#，则数据文件可以被恢复，记得在应用日志的时候要把所有redolog文件全部应用一遍。
如果CHANGE#小于最小的redolog文件的FIRST_CHANGE#，则数据文件就不可以被恢复了，这时候你要从一个有效的全备份中去恢复数据库了，如果没有全备份的话，那你就只能把数据库强制打开到一个不一致的状态去exp出数据，然后重新建库导入数据，因为这种方式的恢复Oracle是不推荐用户自己做的，所以这里我就不详细说明了。
6、恢复数据文件：
RECOVER DATAFILE '
7、确信你应用了所有的redolog文件，直至出现提示信息”Media recovery complete“。
8、打开数据库。
说明：
1、这种方法要求在归档有备份的方式下进行，而且是建议方式；
2、这种方法不会导致数据库的错误。
5.4 损坏临时数据文件的恢复方法
临时数据文件的恢复是比较简单的，因为临时文件中不涉及到其它的有用的数据，所以可以删除后重建。
1、关闭数据库：
SQL>shutdown immediate
2、删除临时数据文件，模拟媒体失败；
3、启动数据库，检测到文件错误；
4、脱机该数据文件：
SQL>alter database datafile '文件名全名' offline drop;
5、打开数据库
SQL>alter database open
6、删除该临时表空间
SQL>drop tablespace temp(或其它临时表空间名称);
7、重新创建该表空间，并重新分配给用户。
说明：
1、临时数据文件是非重要文件，不保存永久数据，可以随时删除重建，不影响数据库的数据安全；
2、如果重新建立以后，别忘了重新分配给用户。
第六章. 常见恢复误区
1、可以不需要备份，只有归档就能进行数据库的向前的恢复
答：这个在Oracle 9i以前起码是不可能的，在别的数据库我也没有听说过，不完全恢复的主要思路是利用不完全点之前的备份，加上归档日志，恢复到不完全恢复点，9i中出现了一个flashback的特性，这个特性的使用，也是有很多局限的。
2、进行不完全恢复只需要拷贝一个需要恢复的备份数据文件
答：不完全恢复需要拷贝所有的数据文件，最好包括临时数据文件在内，否则需要另外的处理，如果有一个数据文件的SCN大于不完全恢复点，那么这个恢复都将是失败的。
3、使用RMAN目录与目标数据库在同一数据库能很好进行数据库的恢复
答：使用恢复目录与目标数据库在同一个数据库中，将存在很大的恢复局限，如该数据库的系统数据文件的损害，数据库根本不能open，那么RMAN也就无法连接恢复目录，也就不存在恢复了。
第七章. 小结
这里我们反复演示了多种情况下的恢复方案，通过这些演示，我们应该掌握了如下内容：
1、利用OS与RMAN进行各种常规备份与恢复。
2、熟悉没有备份或简单的非常规备份与恢复的方法。
约束条件就是Oracle数据库系统提供的对数据的完整性进行制约的机制，
Oracle 9i 约束条件数据库教程
。Oracle 9i允许创建5种约束条件。参见表7.8。创建检查约束条件
（1）在【管理目标导航器】中按照7.6节修改数据表结构的步骤进行操作。
（2）切换到图7.61所示的编辑表的【约束条件】选项卡。
（3）上述创建检查约束条件的SQL码如下?br> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
ALTER TABLE ”SCOTT“.”STUDENT“
ADD (CONSTRAINT ”研究生编号检查约束条件“
CHECK(student_id>= and student_id<=20030909))
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
【参见光盘文件】：第7章 createcheck.sql。
（4）读者也可以直接在【SQLPlus Worksheet】中执行createcheck.sql 文件完成检查约束条件的创建，如图7.62所示，
测试检查约束条件
（1）在7.63所示的【表数据编辑器】界面中按照图示内容输入，单击“应用(P)”按钮。
（2）上述输入数据的SQL代码如下。
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
INSERT INTO ”SCOTT“.”STUDENT“
(”STUDENT_ID“ ,”NAME“ ,”PROFESSIONAL“ ,”BIRTHDAY“ ,”DIRECTOR_ID“ )
VALUES (20010101 ,'纪晓芙' ,'软件工程' ,TO_DATE('15-7月 -1971', 'dd-Mon-yyyy HH:MI:SS AM') ,01)
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
【参见光盘文件】：第7章 testcheck.sql。
（3）出现如图7.64所示界面。
（4）读者也可以直接在【SQLPlus Worksheet】中执行testcheck.sql 文件完成检查约束条件的测试，结果如图7.65所示。
（1）启动【数据库配置助手】，一直到出现如图6.44所示的【操作】界面，
删除Oracle 9i数据库数据库教程
。（2）出现如图6.45所示的【数据库】界面，
（3）出现如图6.46所示的【概要】界面。
（4）出现如图6.47所示的【删除确认】界面。
（5）成功删除数据库后出现如图6.48所示的【成功境】界面。单击“否”按钮?br>
SELECT时不利用函数
在做频繁的查询垄断时，尽量直接select字段名，然后利用C语言代码对查询收获做二次加工，避免让Oracle来做混杂的函数可能数学计算。因为Oracle出于通用性的琢磨，其函数及数学计算的速度远不及用C语言直接编译成机器码后计算来的快。
绑定变量
这个能够大幅度减退SQL的“hard parse”，我们大局部过程都曾经告终了变量绑定。个别未曾告终的，修正一下，也能很快看到收获。
批量FETCH
万一顺次select会归来多条（几百、上千）登记，利用批量Fetch，例如顺次fetch 1000条登记，要比一条条的fetch数据快的多，也能够管用减退oracle的压力。
批量提交
顺次修正多条（例如小于10000条左右）登记，然后顺次性提交，要比每条提交顺次快的多。当然前提是业务逻辑批准这么做。
批量增删改
万一必需顺次性修正可能剔除多条登记，能够批准批量数组绑定的措施，这个和前面说得“绑定变量”相仿，差异是前者绑定的是一个变量，这里绑定的是一个大数组的首指针，这种措施要比逐条绑定厉行快的多。
SQL预解析
前面的大局部是批量垄断，还有一种常见的场景是小事务垄断，但频率极其高nextplas.com。这种场景等闲SQL也不混杂，几乎未曾优化的余地了，然而由于垄断频繁，同样会构成CPU居高不下。现在我们的过程大局部都是下面这个利用形式：
loop parse sql; bind var; execute sql; end loop;
固然我们利用了绑定变量的措施，然而由于垄断频繁，同样构成许多的“soft parse”以及网络通信。在内存数据库中，我们等闲批准预解析的措施来长进效率，事实上，Oracle很早就给开发者供给这种形式，只是开发者嫌繁琐没利于用而已。将过程改成下列形式：
parse sql; bind var; loop execute sql; end loop;
这么就能够管用减退Oracle的压力，能够将厉行效率起码长进一倍。然而这种形式波及到过程构造的改变，定然在设计阶段就这么做。否则，后期再调剂的话，危险和工作量都会很大。
SQL语句的一些优化措施
1、SQL语句用大写的；因为Oracle总是先解析SQL语句，把小写的字母转换成大写的再厉行。
2、避免在索引列上利用NOT等闲，我们要避免在索引列上利用NOT， NOT会发生在和在索引列上利用函数雷同的波及。
3、当Oracle“碰到”NOT，他就会静止利用索引转而厉行全表扫描。
4、避免在索引列上利用计算。WHERE子句中，假定索引列是函数的一局部。优化器将不利用索引而利用全表扫描。
5、尽量少用DISTINCT垄断，用EXISTS轮换DISTINCTvalues should never be negative。
[Oracle数据库优化策略总结]
理主要是为防止非法登录者或非授权用户对SQL Server 数据库或数据造成破坏，但在有些情况下这种安全管理机制显得力不从心，
备份和恢复概述数据库教程
。例如合法用户不小心对数据库数据做了不正确的操作或者保存数据库文件的磁盘遭到损坏或者运行SQL Server 的服务器因某种不可预见的事情而导致崩溃。所以我们需要提出另外的方案即数据库的备份和恢复来解决这种问题。本章的主要目的就是介绍备份、恢复的含
义，数据库备份的种类以及备份设备等基本的概念，以及如何创建备份和恢复数据库，使读者对其有全面的了解和认识，能够自主制定自己的备份和恢复计划。
15.1.1 备份和恢复
备份和恢复组件是SQL Server 的重要组成部分。备份就是指对SQL Server 数据库或事务日志进行拷贝，数据库备份记录了在进行备份这一操作时数据库中所有数据的状态，如果数据库因意外而损坏，这些备份文件将在数据库恢复时被用来恢复数据库。
由于SQL Server 支持在线，备份所以通常情况下可一边进行备份，一边进行其它操作，但是，在备份过程中不允许执行以下操作：
创建或删除数据库文件；
创建索引；
执行非日志操作；
自动或手工缩小数据库或数据库文件大小。如果以上各种操作正在进行当中，且准备进行备份则备份，处理将被终止；如果在备份过程中，打算执行以上任何操作，则操作将失败而备份继续进行。
恢复就是把遭受破坏或丢失数据或出现错误的数据库恢复到原来的正常状态，这一状态是由备份决定的，但是为了维护数据库的一致性，在备份中未完成的事务并不进行恢复。
进行备份和恢复的工作主要是由数据库管理员来完成的。实际上数据库管理员日常比较重要、比较频繁的工作就是对数据库进行备份和恢复。
注意：如果在备份或恢复过程中发生中断，则可以重新从中断点开始执行备份或恢复。这在备份一个大型数据库时极有价值。
15.1.2 数据库备份的类型
在SQL Server 中有四种备份类型，分别为；
数据库备份（Database Backups）
事务日志备份（Transaction Log Backup）
差异备份（Differential Database Backups）
文件和文件组备份（File and File Group Backup）下面我们将详细介绍其所表述的内容，并涉及到一些使用时注意事项。
1 数据库备份（Database Backups）
数据库备份是指对数据库的完整备份，包括所有的数据以及数据库对象。实际上备份数据库过程就是首先将事务日志写到磁盘上，
然后根据事务创建相同的数据库和数据库对象以及拷贝数据的过程。由于是对数据库的完全备份，所以这种备份类型不仅速度较慢，
而且将占用大量磁盘空间。正因为如此，在进行数据库备份时，常将其安排在晚间，因为此时整个数据库系统几乎不进行其它事务操作，从而可以提高数据库备份的速度。
在对数据库进行完全备份时，所有未完成的事务或者发生在备份过程中的事务都不会被备份。如果您使用数据库备份类型，
则从开始备份到开始恢复这段时间内发生的任何针对数据库的修改将无法恢复。所以我们总是在一定的要求或条件下才使用这种备份类型，比如：
数据不是非常重要，尽管在备份之后恢复之前数据被修改，但这种修改是可以忍受的；
通过批处理或其它方法，在数据库恢复之后可以很容易地重新实现在数据损坏前发生的修改；
数据库变化的频率不大。在进行数据库备份时，如果您在备份完成之后又进行了事务日志备份，则在数据库备份过程中发生的事务将被备份：但若只进行数据库备份，常将数据库选项“trunc.log onchkpt” 设置为true， 这样每次在运行到检查点（checkpoint） 时，都会将事务日志截断。
注意：如果对数据一致性要求较高（将数据库恢复到发生损坏的刻），则不应使用数据库备份。
2 事务日志备份（Transaction Log Backup）
事务日志备份是指对数据库发生的事务进行备份，包括从上次进行事务日志备份、差异备份和数据库完全备份之后，所有已经完成的事务。在以下情况下我们常选择事务日志备份。
不允许在最近一次数据库备份之后发生数据丢失或损坏现象；
存储备份文件的磁盘空间很小或者留给进行备份操作的时间有限，例如兆字节级的数据库需要很大的磁盘空间和备份时间；
准备把数据库恢复到发生失败的前一点；
数据库变化较为频繁。由于事务日志备份仅对数据库事务日志进行备份，所以其需要的磁盘空间和备份时间都比数据库备份（备份数据和事务）少得多，这是它的优点所在。正是基于此，我们在备份时常采用这样的策略，即每天进行一次数据库备份，而以一个或几个小时的频率备份事务日志。这样利用事务日志备份，我们就可以将数据库恢复到任意一个创建事务日志备份的时刻。
但是，创建事务日志备份却相对比较复杂。因为在使用事务日志对数据库进行恢复操作时，还必须有一个完整的数据库备份，而且事务日志备份恢复时必须要按一定的顺序进行。比如在上周末对数据库进行了完整的数据库备份，在从周一到本周末的每一天都进行一次事务日志备份，那么若要打算对数据库进行恢复，则首先恢复数据库备份，然后按照顺序恢复从周一到本周末的事务日志备份。
有些时侯数据库事务日志会被中断，例如数据库中执行了非日志操作（如创建索引、创建或删除数据库文件、自动或手工缩小数据库文件大小），此时应该立即创建数据库或差异备份，然后再进行事务日志备份。以前进行的事务日志备份也没有必要了。
3 差异备份（Differential Database Backups）
差异备份是指将最近一次数据库备份以来发生的数据变化备份起，来因此差异备份实际上是一种增量数据库备份，
与完整数据库备份相比，差异备份由于备份的数据量较小，所以备份和恢复所用的时间较短。通过增加差异备份的备份次数，可以降低丢失数据的风险，将数据库恢复至进行最后一次差异备份的时刻，但是它无法像事务日志备份那样提供到失败点的无数据损失备份。
但在实际中为了最大限度地减少数据库恢复时间以及降低数据损失数量，我们常一起使用数据库备份、事务日志备份和差异备份，而采用的备份方案是这样的；
首先有规律地进行数据库备份，比如每晚进行备份；
其次以较小的时间间隔进行差异备份，比如三个小时或四个小时；
最后在相临的两次差异备份之间进行事务日志备份，可以每二十或三十分钟一次。
这样在进行恢复时，我们可先恢复最近一次的数据库备份，接着进行差异备份，最后进行事务日志备份的恢复。
但是，在更多的情况下我们希望数据库能恢复到数据库失败那一时刻，那么我们该怎样做呢？下面的方法也许会有大帮助。
首先如果能够访问数据库事务日志文件则应备份当前正处于活动状态的事务日志；
其次恢复最近一次数据库备份；
接着恢复最近一次差异备份；
最后按顺序恢复自差异备份以来进行的事务日志备份。当然，如果无法备份当前数据库正在进行的事务，则只能把数据库恢复到最后一次事务日志备份的状态，而不是数据库失败点。
4 文件和文件组备份（File and File Group Backup）
文件或文件组备份是指对数据库文件或文件夹进行备份，但其不像完整的数据库备份那样同时也进行事务日志备份。使用该备份方法可提高数据库恢复的速度，因为其仅对遭到破坏的文件或文件组进行恢复。
但是在使用文件或文件组进行恢复时，仍要求有一个自上次备份以来的事务日志备份来保证数据库的一致性。所以在进行完文件或文件组备份后应再进行事务日志备份。否则备份在文件或文件组备份中所有数据库变化将无效。
如果需要恢复的数据库部分涉及到多个文件或文件组，则应把这些文件或文件组都进行恢复。例如，如果在创建表或索引时，表或索引是跨多个文件或文件组，则在事务日志备份结束后应再对表或索引有关的文件或文件组进行备份，否则在文件或文件组恢复时将会出错。
15.1.3 备份和恢复的策略
通常而言，我们总是依赖所要求的恢复能力（如将数据库恢复到失败点） 、备份文件的大小（如完成数据库备份或只进行事务日志的备份或是差异数据库备份）以及留给备份的时间等来决定该使用哪种类型的备份。常用的备份选择方案有：仅仅进行数据库备份、或在进行数据库备份的同时进行事务日志备份，或使用完整数据库备份和差异数据库备份。
选用怎样的备份方案将对备份和恢复产生直接影响，而且也决定了数据库在遭到破坏前后的一致性水平。所以在做出该决策时，您必须认识到以下几个问题：
如果只进行数据库备份，那么将无法恢复自最近一次数据库备份以来数据库中所发生的所有事务。这种方案的优点是简单，而且在进行数据库恢复时操作也很方便；
如果在进行数据库备份时也进行事务日志备份，那么可以将数据库恢复到失败点，那些在失败前未提交的事务将无法恢复，但如果您在数据库失败后立即对当前处于活动状态的事务进行备份，则未提交的事务也可以恢复。
从以上可以看出，对数据库一致性的要求程度成为我们选择这样或那样的备份方案的主要的普遍性原因。但在某些情况下对数据库备份提出更为严格的要求，例如在处理比较重要业务的应用环境中，常要求数据库服务器连续工作，至多只留有一小段时间来执行系统维护任务，在该情况下一旦出现系统失败，则要求数据库在最短时间内立即恢复到正常状态，以避免丢失过多的重要数据，由此可见备份或恢复所需时间往往也成为我们选择何种备份方案的重要影响因素。
那么如何才能减少备份和恢复所花费时间呢？SQL Server 提供了几种方法来减少备份或恢复操作的执行时间。
使用多个备份设备来同时进行备份处理。同理，可以从多个备份设备上同时进行数据库恢复操作处理；
综合使用完整数据库备份、差异备份或事务日志备份来减少每次的需要备份的数据数量；
使用文件或文件组备份以及事务日志备份，这样可以只备份或恢复那些包含相关数据的文件，而不是整个数据库。
另外需要注意的是，在备份时我们也要决定该使用哪种备份设备如磁盘或磁带，并且决定如何在备份设备上创建备份，比如将备份添加到备份设备上或将其覆盖。在SQL Server 2000 中，有三种数据库恢复模式，它们分别是：简单恢复（SimpleRecovery）、 完全恢复（Full Recovery）、 批日志恢复（Bulk-logged Recovery）。
1 简单恢复（Simple Recovery）
所谓简单恢复就是指在进行数据库恢复时仅使用了数据库备份或差异备份，而不涉及事务日志备份。简单恢复模式可使数据库恢复到上一次备份的状态，但由于不使用事务日志备份来进行恢复，所以无法将数据库恢复到失败点状态。当选择简单恢复模式时常使用的备份策略是：首先进行数据库备份，然后进行差异备份。
2 完全恢复（Full Recovery）
完全数据库恢复模式是指通过使用数据库备份和事务日志备份将数据库恢复到发生失败的时刻，因此几乎不造成任何数据丢失，这成为对付因存储介质损坏而数据丢失的最佳方法。为了保证数据库的这种恢复能力，所有的批数据操作比如SELECT INGO、创建索引都被写入日志文件。选择完全恢复模式时常使用的备份策略是：
首先进行完全数据库备份；
然后进行差异数据库备份；
最后进行事务日志的备份。
如果准备让数据库恢复到失败时刻必须对数据库失败前正处于运行状态的事务进行备份。3 批日志恢复（Bulk-logged Recovery）
批日志恢复在性能上要优于简单恢复和完全恢复模式，它能尽最大努力减少批操作所需要的存储空间。这些批操作主要是：SELECT INTO 批装载操作（如bcp 操作或批插入操作）、创建索引针对大文本或图像的操作（如WRITETEXT、 UPDATETEXT）。选择批日志恢复模式所采用的备份策略与完全恢复所采用的恢复策略基本相同。
从以上的论述中我们可以看到，在实际应用中，备份策略和恢复策略的选择不是相互孤立的，而是有着紧密的联系。我们并不仅仅是因为数据库备份为数据库恢复提供了 “原材料”这一事实，以便在采用何种数据库恢复模式的决策中考虑该怎样进行数据库备份，更多是因为在选择该使用哪种备份类型时我们必须考虑到当使用该备份进行数据库恢复时，它能把遭到损坏的数据库“带”到怎样的状态（是数据库失败的时刻，还是最近一次备份的时刻）。但有一点我们必须强调，即备份类型的选择和恢复模式的确定都应服从于这一目标：尽最大可能，以最快速度减少或消灭数据丢失。
恢复|数据|数据库
昨天帮一个朋友恢复了sql server 7.0 数据库，现在把过程写出来，大家一起分享：
我那个哥们是从别人那拷了一个数据库的数据文件 （c:mssql7data 目录下的文件）
最初我是用的：
在一台好的机器上重新安装SQL Server，建立相同的数据库设备（大小），和数据库
停掉SQL Server，用拷贝出来的数据库文件覆盖刚建立的数据库文件，再重新启动
SQL Server。但一直不可以。我猜关键是无法建立相同的数据库设备（大小）。
后来采用了
系统存储过程：
sp_attach_db // 附加数据库文件到服务器
或
sp_attach_db_single_file // 附加数据库的单个文件到服务器
具体的sql 语句就是：
例如：
EXEC sp_attach_single_file_db 'pubs', 'e:datapubs.mdf'
sp_attach_db @dbname=”conmis2000“,@filename1=”d:1conmis2000_data.mdf“,@filename2=” d:1conmis2000_log.ldf"
如何附加数据库文件到服务器（即：通过*.mdf *ldf 文件修复数据库）
另外查找资料时看到也可以通过日志恢复以前的数据，
不知那位哥们看看是不是可以
用日志恢复：
restore log {data_name|@database_name_var}
from
with [norecoveryrecovery tandby_undo_file_name]
[,][stopat={data_time|@data_time_var}
例如：库名为database1 日志为database1_log 要求恢复2000/6/15 1:00前的数据：
restroe log database1
from database_log
with recovery,stopat='jun 15,2000 1:00 am'
参考书有：＜SQL SERVER7.0 系统管理和应用开发指南＞（清华大学出版社）
