• 说明用户管理的备份和恢复与服务器管理的备份和恢复
之间的差异
• 执行用户管理的数据库完全恢复
• 执行用户管理的数据库不完全恢复
数据库备份和恢复的类型包括:
• 用户管理的:不使用RMAN
– 使用OS 命令移动文件
– DBA 需要手动维护备份活动记录
• 服务器管理的:使用RMAN
有两种方法可用来恢复数据库。可以使用RMAN 并利用其自动恢复功能。它可以还原相
应的文件,并使用非常少的命令使数据库恢复到当前状态。还可以手动进行恢复。这称为
“用户管理的恢复”。用户管理的恢复需要使用OS 命令来移动文件,然后在SQL*Plus
中发出恢复命令。
这两种方法都使用还原和恢复过程。
可以使用OS 命令创建数据文件的副本,从而备份数据库。操作过程取决于数据库是否处
于ARCHIVELOG模式。如果是,则通过在复制表空间的数据文件之前将每个表空间置于
备份模式,可以使数据库处于打开且可用状态。否则,在复制数据文件之前必须先关闭数
据库。
归档模式下,手工热备份脚本: http://blog.csdn.net/rlhua/article/details/11850629
非归档模式下,手工冷备份脚本: http://blog.csdn.net/rlhua/article/details/11850445
如果在执行数据操纵语言(DML) 语句期间写入某个块,则可能会影响该块的多个部分。
对块的所有修改并不是同时发生的,因此在特定时间块可能会不一致。假设t
2表示介于块
的不同部分的写入时间之间的时刻。如果在执行OS 复制命令期间,在t
2时刻复制块,则
该块被视为破碎的。此外,OS 复制命令不一定先复制文件头,因此在执行复制期间必须
冻结文件头。
RMAN 可以设法处理此问题。如果读取的块是破碎的,则将不停地重复读取该块,直到
该块一致为止。
但是,如果OS 命令(如Linux cp命令)正在复制数据文件,则不会将破碎块视为破碎块,
且块的副本也不一致。为了补救这种情况,请将
表空间甚至整个数据库置于备份模式
。这
样做的效果就是生成更多的重做。每个块的映像在修改之前会写入重做日志。然后,在恢
复该数据文件中的块期间,可以使用破碎块的前像作为恢复基础,并将更多的重做数据应
用于块。为了降低维护额外的重做数据带来的开销,Oracle 建议一次将一个表空间置于备
份模式,同时复制其数据文件。
sys@TEST0924>
select name from v$datafile;
NAME
----------------------------------------------------------------------------------------------------
/u01/app/oracle/oradata/test0924/system01.dbf
/u01/app/oracle/oradata/test0924/sysaux01.dbf
/u01/app/oracle/oradata/test0924/fla_tbs02.dbf
/u01/app/oracle/oradata/test0924/users01.dbf
/u01/app/oracle/oradata/test0924/example01.dbf
/u01/app/oracle/oradata/test0924/fla_tbs01.dbf
/u01/app/oracle/oradata/test0924/undotbs02.dbf
/u01/app/oracle/oradata/test0924/undotbs01.dbf
/u01/app/oracle/oradata/test0924/inventory01.dbf
9 rows selected.
sys@TEST0924>
select name from v$controlfile;
NAME
----------------------------------------------------------------------------------------------------
/u01/app/oracle/oradata/test0924/control01.ctl
/u01/app/oracle/fast_recovery_area/test0924/control02.ctl
采用用户管理的备份要求了解磁盘上的数据文件名和位置,从而知道需要复制哪些文件。
通过查询V$DATAFILE视图确定要备份的数据文件。通过查询V$CONTROLFILE视图确
定控制文件位置。只需要备份一个多路复用控制文件,因为它们是相同的。
• 关闭数据库实例:
SQL> SHUTDOWNIMMEDIATE
• 将数据文件复制到备份位置:
$ cp $ORACLE_BASE/ORCL/datafile/*.dbf \
> /u02/backup/datafile
• 将控制文件复制到备份位置:
$ cp $ORACLE_BASE/ORCL/controlfile/*.ctl \
> /u02/backup/controlfile
• 启动实例并打开数据库:
SQL> STARTUP
通过
关闭数据库并将所有数据文件和控制文件复制到一个备份目录,可以对
NOARCHIVELOG数据库进行一致的整体数据库备份
。由于文件复制操作是使用OS 命令
(在本例中为Linux cp命令)执行的,因此必须先关闭数据库。这会将数据库置于一致
状态。如果数据库正在NOARCHIVELOG模式下运行,则这是唯一的选择。否则,在
ARCHIVELOG模式下,可以执行不一致备份,这样可以在执行备份时使数据库保持运
行状态。
• 确定表空间及其数据文件:
sys@TEST0924> select file_name,tablespace_name from dba_data_files;
FILE_NAME TABLESPACE_NAME
-------------------------------------------------- ------------------------------
/u01/app/oracle/oradata/test0924/users01.dbf USERS
/u01/app/oracle/oradata/test0924/fla_tbs02.dbf FLA_TBS2
/u01/app/oracle/oradata/test0924/sysaux01.dbf SYSAUX
/u01/app/oracle/oradata/test0924/system01.dbf SYSTEM
/u01/app/oracle/oradata/test0924/example01.dbf EXAMPLE
/u01/app/oracle/oradata/test0924/fla_tbs01.dbf FLA_TBS1
/u01/app/oracle/oradata/test0924/undotbs02.dbf UNDOTBS2
/u01/app/oracle/oradata/test0924/undotbs01.dbf UNDOTBS1
/u01/app/oracle/oradata/test0924/inventory01.dbf INVENTORY
9 rows selected.
对每个表空间执行以下操作:
• 将表空间置于备份模式:
sys@TEST0924> alter tablespace users begin backup;
Tablespace altered.
• 将该表空间的数据文件复制到备份位置:
$ cp /u01/app/oracle/oradata/test0924/users01.dbf
/u02/backup/datafile
• 使该表空间退出备份模式:
sys@TEST0924> alter tablespace users end backup;
Tablespace altered.
如果数据库处于ARCHIVELOG模式下,则
复制文件前不一定必须关闭数据库。最终会得
到
不一致备份
,但应用重做数据后会使其恢复到一致状态。
启动备份模式:复制数据文件之前,必须将每个数据文件都置于备份模式。请使用
ALTER TABLESPACE和ALTER DATABASE命令的BEGIN BACKUP子句来执行此操作。
以下是每个命令的语法:
ALTER TABLESPACE <tablespace> BEGIN BACKUP;
ALTER DATABASE BEGIN BACKUP;
ALTER TABLESPACE命令仅影响属于该表空间的那些数据文件。ALTER DATABASE影
响数据库中的所有数据文件。
结束备份模式:使数据文件退出备份模式非常重要。关闭数据库时,不能有任何数据文件
处于备份模式。如果尝试关闭处于该状态的数据库,将收到错误。此外,由于备份模式会
导致生成额外的重做数据,因此会给系统带来额外的负载。如果不主动备份数据文件,
则没有理由使任何数据文件处于备份模式。
注:此外,你需要归档出当前的重做日志文件,并将其安全备份。
备份控制文件的方式包括:
• 创建为映像副本,写入到指定名称的文件:
• 生成重新创建控制文件的脚本,写入到跟踪文件:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO
'/u01/backup/controlfile.bak';
Database altered.
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Database altered.
每次对数据库进行结构更改时,都应备份控制文件。使用示例显示的命令之一执行此
操作。第一条命令创建该文件的二进制副本。如果备份文件已存在且你希望覆盖该文件,
则可以选择提供REUSE关键字。
第二条命令创建纯文本版本的控制文件,实际上是运行后会创建控制文件的脚本。生成的
脚本被写入诊断跟踪目录,如:
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace
你也可使用AS 'filename'子句指定跟踪文件的名称。
用户管理的数据库完全恢复:
• 将数据库恢复到最新的SCN
• 可以一次处理整个数据库,也可以一次处理一个数据
文件或表空间
• 需要当前控制文件或备份控制文件
• 需要有待恢复的所有文件的备份
• 需要到目前为止的
所有归档日志
数据库完全恢复会使数据库恢复至其最新状态。可以一次恢复整个数据库,也可以一次恢
复一个表空间或数据文件。必须具备当前或备份控制文件,才能对数据库执行完全恢复。
你还必须具有进行介质恢复时所需的所有文件的备份,或者具有自数据文件添加到数据库
以来生成的所有归档重做日志文件。
必须具备从执行备份的时间点到现在的所有可用归档日志。如果没有所有归档日志,则只
能恢复到重做可用的上一个时间点。如果不需要任何归档日志,则只应用联机重做日志。
可查询以下视图:
• V$RECOVER_FILE:查看哪些文件需要介质恢复
• V$RECOVERY_LOG:查看执行恢复需要哪些归档日志
在某些情况下,属于SYSTEM表空间的文件受到损坏时,实例将自动关闭。当某些数据
文件有问题时,即使实例保持运行状态,你也可以判定使数据库保持运行状态没有任何
意义;受影响的数据库对象太多了。在这种情况下,请关闭数据库执行恢复。
如果数据库仍处于打开状态,则可以查询V$RECOVERY_FILE视图以了解哪些数据文件
需要恢复,并在
还原数据文件
后查询V$RECOVERY_LOG以了解需要哪些归档日志。这会
指示你需要从备份中还原哪些文件(如果有)。
然后关闭数据库。调查介质故障,确定问题原因。修复该问题,以便可以从备份中还原文
件。例如,你可能需要更换磁盘驱动器。
现在,可使用RECOVER命令来执行恢复。将恢复范围限制在所需范围,如数据文件或表
空间。如果需要,可恢复整个数据库。然后打开数据库。
• 确定需要恢复的数据文件:
sys@TEST0924> SELECT file#, error FROM v$recover_file;
FILE# ERROR
---------- -----------------------------------------------------------------
4 FILE NOT FOUND
• 确定完成恢复所需的归档日志文件:
sys@TEST0924> SELECT archive_name FROM v$recovery_log;
no rows selected
如果数据库仍处于打开状态,请按照下述步骤查询文件。否则,请尝试启动实例并装载数
据库以便发出查询。
为了确定哪些数据文件需要恢复,请查询V$RECOVER_FILE视图。ERROR列指明文件
需要恢复的原因。如果此列具备OFFLINE NORMAL以外的任何值,则需要恢复。要查看
所有受影响的数据文件和表空间的概况,请在此查询中加入V$DATAFILE和
V$TABLESPACE。下面是一个示例:
SELECT r.FILE#, d.NAME df_name, t.NAME tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;
sys@TEST0924> l
1 SELECT r.FILE#, d.NAME df_name, t.NAME tbsp_name,d.STATUS, r.ERROR, r.CHANGE#, r.TIME
2 FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
3* WHERE t.TS# = d.TS# AND d.FILE# = r.FILE#
sys@TEST0924> /
FILE# DF_NAME TBSP_NAME STATUS ERROR CHANGE# TIME
---------- -------------------------------------------------- ---------- ------- -------------------- ---------- -------------------
4 /u01/app/oracle/oradata/test0924/users01.dbf USERS ONLINE FILE NOT FOUND 0
这可指示受损的程度,帮助你确定RECOVER命令的对象。
V$RECOVERY_LOG视图显示执行恢复所需的归档日志文件。如果列表显示某些文件已移
出默认归档日志位置,则必须将它们还原到某个位置,再执行恢复。
记录这些查询的结果后,关闭数据库。
确定了需要哪些数据文件和归档日志文件后,将它们还原到相应的磁盘位置。通过从备份
位置复制某个数据文件来还原该数据文件,如下例所示:
[oracle@rtest ~]$ cp /u01/app/oracle/oradata/test0924/users01old.dbf /u01/app/oracle/oradata/test0924/users01.dbf
如果恢复需要任何归档日志,请检查这些日志是否仍位于归档日志的默认磁盘位置。这些
日志可能不在默认位置,例如,已将它们移至磁带或其它磁盘驱动器。如果日志已被移动,
则需将它们还原到默认归档日志位置或临时位置。如果默认位置(由
LOG_ARCHIVE_DEST_1初始化参数指定)中有足够的可用空间,请在该位置还原日志。
否则,可以将日志置于某个其它磁盘位置。还原时,可指定该备用位置来查找归档日志
文件。
如果必须移动数据文件,则必须在控制文件中记录这一事实。这是通过执行ALTER
DATABASE RENAME FILE命令来完成的,如下例所示:
SQL> ALTER DATABASE RENAME FILE
'/u01/app/oracle/oradata/test0924/users01.dbf
' TO
'/newdisk/ORCL/datafile/users01
.dbf';
注:在执行ALTER DATABASE RENAME FILE命令之前,
你必须启动实例并装载数据库。
如果您尚未执行此操作,请装载数据库并使所有数据文件联机。可以通过查询
V$DATAFILE视图来检查每个数据文件的状态。可使用如下命令使数据文件联机:
SQL> ALTER DATABASE DATAFILE
'/newdisk/ORCL/datafile/users01
.dbf' ONLINE;
现在,数据文件已还原到过去的某个时间点。归档日志文件也已还原到其默认位置或某个
其它位置(仅用于此恢复)。你已准备就绪,可执行真正的恢复步骤,这意味着已应用重
做且数据文件已恢复到最新SCN。请使用SQL*Plus RECOVER命令执行此操作。
如果没有指定AUTOMATIC选项,则系统会提示你指定要应用的每个重做日志文件。这样
可以提高对恢复过程的控制。通常,AUTOMATIC用于完全恢复。
如果归档日志文件已还原到数据库默认位置以外的某个磁盘位置,则必须指定FROM子句。
提供存储这些文件的目录,恢复过程将在该目录中寻找文件。
最后,打开数据库。此时已完全恢复。
如果在数据库处于打开状态时出现介质故障,则数据库将继续运行。
尝试向其中的数据文件写入数据时,数据文件将自动脱机。对这些数据文件进行查询不会导致其脱机,但是会向发出查询的用户返回错误。
与恢复关闭的数据库类似,你首先需要查询需恢复的文件和归档日志。然后,使包含受损
数据文件的所有表空间脱机。可使用如下命令完成该操作:
SQL> ALTER TABLESPACE survey OFFLINE TEMPORARY;
使用TEMPORARY选项会导致Oracle 对所有属于表空间的联机数据文件执行检查点操作。
经过检查点操作的数据文件在重新联机后不需要进行恢复,因为对于可能会影响它们的任
何事务处理的最新SCN 而言,它们是最新的。尽管在此命令运行时数据文件必须可用,
但此选项更符合需要。问题可能是临时的,你可以在不产生错误的情况下使表空间联机。
检查介质以确定问题原因。可使用DBVERIFY实用程序来执行此操作。如果文件被永久
损坏,请按照前面就恢复关闭数据库所述的内容进行还原和恢复。还原和恢复步骤完
成后,应使所有表空间重新联机。
在以下情况下,可将数据库恢复到过去的时间点:
• 希望数据库处于出现用户错误或管理错误之前的状态。
• 在尝试块介质恢复后,数据库中包含损坏的块。
• 由于缺少某些重做日志文件而无法对数据库执行完全
恢复。
• 希望创建一个测试数据库,使数据库处于过去某个
时间的状态。
• 丢失了数据文件和一个或多个未归档重做日志文件。
不完全恢复是指不会使数据库恢复到已经过事务处理的最新SCN 的恢复。出于某种原因
,只需将该数据库恢复到过去的某个时间点,而不是现在。执行不
完全恢复时进行的处理不同于完全恢复处理,其差别主要在应用重做的数量上。
可通过以下方式指明何时停止应用重做数据:
• 指定停止的时间
• 指定停止的SCN
• 在执行恢复时发出CANCEL命令
计划不完全恢复时,请确定要使用哪种方法来指定何时停止应用重做数据。可以通过指定
以下某一项来停止恢复过程:
• 时间:应停止恢复的日志时间。该操作可自动执行,这样恢复过程便不会提示你输入
每个文件名。
• SCN:恢复应在该点停止的系统更改号。该操作可自动执行,这样恢复过程便不会提
示你输入每个文件名。
• CANCEL:在恢复过程提示你输入下一个重做日志文件名称时,指定CANCEL关键字。
不能自动执行该过程,因为你必须指定CANCEL来终止恢复操作。
• 将数据库恢复到某一时刻:
SQL> RECOVER DATABASE UNTIL
TIME '2005-12-14:12:10:03';
• 恢复数据库直到执行取消操作:
SQL> RECOVER DATABASEUNTIL CANCEL;
使用以下命令执行不完全恢复:
RECOVER [AUTOMATIC] DATABASE option
下面是选项的含义:
• AUTOMATIC:自动应用归档和重做日志文件
• option:UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS'
UNTIL CANCEL
UNTIL CHANGE <integer>
USING BACKUP CONTROLFILE
基于取消的不完全恢复
基于取消的不完全恢复与对关闭数据库执行的完全恢复非常相似。差异在于执行
RECOVER命令的方式;指定UNTIL CANCEL子句。此子句将导致恢复过程提示你确认要
应用的每个重做日志文件的建议名称。因此,在进行恢复过程中,系统会提示你确认已归
档或联机的重做日志文件名,而且对于每个文件名,你可以接受它,也可以更改它。到达
要让恢复停止的时间点时,请输入CANCEL,而不要接受文件名。这将停止恢复。
完成此操作后,必须使用RESETLOGS选项打开数据库。数据库目前正在执行另一实例化
操作,因此需要重置重做日志序列号。
打开数据库后,请检查预警日志中的消息。通过这种方式,您可以获知恢复是否已成功。
基于时间和更改的不完全恢复
基于时间和更改的不完全恢复与基于取消的恢复类似,区别在于使用不同标准来指定停止
恢复的时间。基于时间的恢复使用在RECOVER命令的命令行中指定的时间来获知何时停
止。基于更改的恢复使用在命令行中指定的SCN。
与所有的不完全恢复一样,之后必须使用RESETLOGS选项打开数据库。
注:要在恢复过程中自动应用重做日志文件,可以使用SQL*Plus SET AUTORECOVERY
ON命令,在恢复提示符下输入AUTO,或者使用RECOVER AUTOMATIC命令。
要执行用户管理的不完全恢复,请按以下步骤进行操作:
1. 关闭数据库。
2. 还原数据文件。
3. 装载数据库。
4. 恢复数据库。
5. 使用RESETLOGS选项打开数据库。
1.如果数据库已打开,请使用NORMAL、IMMEDIATE或TRANSACTIONAL选项将其
关闭。
2.从备份还原所有数据文件。你必须使用在打算恢复到的时间之前创建的备份。可能还
需要还原归档日志。如果有足够的可用空间,请还原到LOG_ARCHIVE_DEST位置或
使用ALTER SYSTEM ARCHIVE LOG START TO <LOCATION>命令或SET
LOGSOURCE <LOCATION>命令来更改位置。在执行不完全恢复来恢复到某个时间
点时,如果彼时数据库结构不同于当前的数据库结构,则你还需要还原控制文件。
3.装载数据库。
4.使用RECOVER DATABASE命令恢复数据库。
5.要使数据文件与控制文件和重做日志同步,请使用RESETLOGS选项打开数据库。
情况如下:
• 某个作业运行出错,必须取消其结果和影响。
• 该操作发生在15 分钟前,并且在此之后数据库活动
很少。
• 你决定执行不完全恢复,将数据库还原到15 分钟前的
状态。
SQL> SHUTDOWNIMMEDIATE
$ cp /BACKUP/*.dbf /u01/db01/ORADATA
SQL> STARTUP MOUNT
SQL> RECOVER DATABASE UNTIL TIME '2005-11-28:11:44:00';
SQL> ALTER DATABASE OPEN RESETLOGS;
下面是使用UNTIL TIME恢复的典型情况。假设:
• 当前时间为2005 年11 月28 日中午12:00。
• 某个作业运行出错,影响了多个方案中的许多表。
• 该操作大约发生在上午11:45。
• 因为大多数员工现在都在开会,所以数据库活动很少。必须还原到作业运行前数据库
的状态。
因为知道错误的大概时间,而且自上午11:44 以来数据库的结构未发生更改,所以可以使
用UNTIL TIME方法:
1.如果数据库已打开,请使用NORMAL、IMMEDIATE或TRANSACTIONAL选项将其
关闭。
2.从备份(如果可能,使用最新的)还原所有数据文件。可能还需要还原归档日志。如
果有足够的可用空间,请还原到LOG_ARCHIVE_DEST位置或使用ALTER SYSTEM
ARCHIVE LOG START TO <LOCATION>命令或SET LOGSOURCE <LOCATION>
命令来更改位置。
3.装载数据库。
4.恢复数据库:
SQL> recover database until time '2005-11-28:11:44:00'
ORA-00279: change 148448 … 11/27/05 17:04:20 needed for thread
...
Media recovery complete.
5.要使数据文件与控制文件和重做日志同步,请使用RESETLOGS选项打开数据库:
SQL> alter database open resetlogs;
SQL> archive log list
...
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
恢复成功完成后,会通知用户数据库已经可用,需要重新输入恢复时间(上午11:44)之后
输入的所有数据。
情况与基于时间的示例相同,除了以下各项:
• 重做日志未进行多路复用。
• 一个联机重做日志丢失。
• 丢失的重做日志未归档。
• 该重做日志包含自上午11:34 以来的信息。
• 丢失了26 分钟的数据。
• 用户可以手动重新输入其数据。
在目录中搜索重做日志文件后,发现找不到重做日志log2a.rdo且该日志尚未归档。
因此,无法恢复到此点之后。
查询V$ARCHIVED_LOG后确定缺少归档日志序列48 (log2a.rdo):
SQL> SELECT * FROM v$archived_log;
RECID STAMP ... FIRST_CHANGE# FIRST_TIME
----- --------- ... ------------- ----------
1 318531466 ... 88330 05-11-15:12:43
47 319512880 ... 309067 05-11-28:11:26
按以下步骤恢复数据库:
• 关闭数据库。
• 从最新备份还原所有数据文件。
• 装载数据库。
• 执行RECOVER DATABASE UNTIL CANCEL。
• 执行ALTER DATABASE OPEN RESETLOGS以打开
数据库。
基于取消的恢复与基于时间的恢复步骤相同,除了RECOVER DATABASE这一步。执行
RECOVER DATABASE UNTIL CANCEL命令时,它将恢复数据库直到找不到日志文件。
提示你输入丢失的归档重做日志文件的名称时,请输入CANCEL;恢复将在该时间点停止。