教你如何成为Oracle 10g OCP - 第十二章手工管理的备份与恢复

最新推荐文章于 2022-03-30 23:47:44 发布

cuixie2370

最新推荐文章于 2022-03-30 23:47:44 发布

阅读量90

点赞数

第十二章手工管理的备份与恢复

备份分为两种：物理备份和逻辑备份

物理备份 -- 指对数据文件，控制文件，归档日志文件的备份，是数据块级别的备份；
逻辑备份 -- 指对数据库内部的逻辑对象(比如表)进行的备份，主要工具如exp/expdp 等；

12.1 备份

Oracle所有发生的事务都会记录到联机日志文件中，当实例crash时，SMON进程能够利用记录
在联机日志文件中的重做记录(redo record)进行前滚。

备注：

前滚(roll forward) : 将已经写入redo log file 中但是没有写入datafile中的提交与未提交
的数据写入数据文件。属于实例恢复，一般在数据库开启的时候进行。

回滚(rollback): 在数据库开启之后，oracle会查找redo log file中记录的commit maker,根
据undo block中的内容将它回滚到一致的状态。

联机日志文件(online redo log) 及归档日志，归档模式相对简单，这里不做介绍。

12.1.1 冷备份

冷备份 - 将数据库正常关闭以后，使用OS命令将所有数据文件及控制文件拷贝到备份介质上。

非归档模式的数据库只能进行冷备份。

冷备份时，因为是正常关闭数据库(不是abort), 因此会触发完全检查点，从而将内存中的
脏数据块全都写入数据文件，因此关闭的数据库是干净的数据库。因为冷备份时online redo
log保护的脏数据块都已经写入了数据文件中，所以不再需要联机日志文件了。如果关闭
的时候使用的shutdown abort, 那么冷备份的时候需要online redo log 文件。

相关视图： dba_data_files , v$controlfile

除了测试环境，我们一般不会将数据库置为非归档模式，冷备份必须关闭数据库进行，这是
它最大的缺点。

12.1.2 热备份

热备份优点 - 数据库始终保持可用
热备份缺点 - 概念复杂，操作步骤多，配置了归档，相对非归档冷备份来说对性能有一点影响。

如何设置归档模式 -

SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog ;
SQL> alter database open ;
SQL> archive log list; 确认是否是自动归档模式

归档模式有两种 ----- 手工方式和自动方式

手工方式归档 -- 当前联机日志文件A写满后，切换到另外一个联机日志文件B时，必须手工发出
命令对A进行归档： SQL > alter system archive log current ;
除非测试目的，我们一般不建议手工归档。

自动方式归档 -- LGWR在将重做记录写入current online redo log时，发现写满了，于是切换到
下一个新的online redolog, 进行日志切换，同时触发归档进程(ARCn), 将当前已经写满的联机
日志文件进行归档，其中ARCn中的n代表可以启动多个ARCH进程(1~30)，参数log_archive_max_processes
表示启动多少个归档进程，可以动态调整。

alter system switch log file ;
对单实例数据库或RAC中的当前实例执行强制日志切换，归档当前重做日志，Oracle9i之前
如果自动归档没有开启，就不归档当前重做日志文件。

alter system archive log current ;
对数据库中的所有实例执行日志切换(只归档当前日志)。

alter system archive log all ;
对数据库中的非当前未归档日志进行归档，不负责归档current日志。设一个繁忙的系统中
有日志6个组，分别是group1~6；当前的日志组是group5，而归档进程正在操作group3的内
容，未写完；这个时候group4就是未归档的非当前日志。

--------------------------------------------------------
在Oracle9i及以前版本，在ARCHIVELOG模式下，LOG_ARCHIVE_START=FALSE时，系统在循环到
第一组没有归档的log时，系统会hang住，必须靠DBA手工一个个去归档，如果log group
数量多，直接运 ALTER SYSTEM ARCHIVE LOG ALL; 就可以了。

如果 LOG_ARCHIVE_START=TRUE时，一般情况下只要运行：ALTER SYSTEM ARCHIVE LOG CURRENT;
--------------------------------------------------------

log_archive_start参数在10g中被废弃 --

在Oracle10g中，log_archive_start参数已经被废弃，只要启动数据库的归档模式，Oracle就会
启用自动归档，避免了10g以前由于用户疏忽所带来的一些问题。

--- 归档日志文件路径

log_archive_dest_1 = 'location=/u01/backup'
location 说明将归档日志文件放在本地目录下。

log_archive_dest_2 = 'service=std'
放在远程服务器目录上，具体放在远程服务器哪个目录下，由远程服务器上的standby_archive_dest
来决定，在11g中这个参数被废弃了。

log_archive_dest_1 = 'location=/u01/backup/ mandatory reopen=600'
log_archive_dest_2 = 'location=/u02/backup/ optional'
mandatory表示只有将联机日志文件成功归档到/u01/backup/目录后，该联机日志文件
才能被覆盖，否则不能被覆盖。reopen表示一旦不能成功归档到指定目录，则每个600秒
尝试再次归档到该路径; optional 表示即使当前联机日志文件没有成功归档到/u02/backup/
下，该联机日志文件也是可以被覆盖的。

必须成功归档的路径个数相关参数 ---

A. 定义为mandatory的归档路径的个数；
B. 初始化参数log_archive_min_succeed_dest 值, 必须成功归档的路径个数；
C. log_archive_dest_state_1 对应 log_archive_dest_1 , 值enable表示归档路径可用，
defer表示对应归档路径不可用。

-- Log_archive_format
A. %s - 日志序列号
B. %S - 固定长度的日志序列号，不足位数在左边以0补齐
C. %t - 日志线程号, thread
D. %T - 固定长度的日志线程号，不足位数在左边以0补齐
E. %a - 激活ID
F. %d - 数据库ID
G. %r - resetlogs生成的ID

组合的例子： %t_%s_%r.dbf

12.1.2.2 热备份数据库

热备份过程 --
SQL> alter tablespace users begin backup ;
拷贝此表空间下的数据文件到备份介质上；
SQL> alter tablespace users end backup ;
SQL> alter system switch logfile; 强制归档一次current redo.
对每个表空间执行上述过程；
备份所有的归档日志文件；

--- 为什么只有将表空间设置为begin backup模式后才能进行拷贝呢？

Oracle数据块的大小是操作系统数据块的整数倍，如果直接通过OS命令拷贝数据
文件到备份介质，由于数据库一直在使用，我们通过OS命令拷贝数据文件是以
OS Block为单位进行的，那么一个Oracle block会被分成好几次被操作系统复制，
我们可能在复制一个Oracle block中的一些OS Block的时候，该Oracle block因为
用户操作而被修改了，那么这个Oracle block中一部分OS Block已经被拷贝过去了，
而这个Oracle block中的后一半部分被改动过了，该数据块的状态已经不一致了，
该Oracle block的备份是不能被使用的(因为block内部版本不一致)，这叫做分离
数据块(split blocks)的现象。

Oracle判断某个数据块是否出现这种分离的现象，是通过比较数据块头部和尾部的
版本号是否一致来实现的。只要修改了数据块，Oracle就会同时更新数据块头和尾
的版本号，因此，如果头尾版本号不一致，说明该数据块损坏，不能被使用。

发出begin backup以后，第一次修改数据块中的数据行之前，在online redo log文件
中记录整个数据块的修改前的数据(以重做记录形式)。在使用热备份进行恢复时，一旦
发现某个数据块被分离，则会利用日志文件中记录的数据对整个数据块进行恢复。

期间如果有第二次，第三次修改了数据块，只是记录整个数据块第一次修改前的
数据到联机日志文件。

--- 为什么热备份期间产生了比平时多的归档日志

由于记录了整个数据块中所有数据行的重做记录，而不是只记录被修改的数据行的重做记录.
因此，热备份中我们会发现产生的归档日志量比平时多，热备份期间，如果DML操作有很多，
则产生的归档日志会更多。

--- 热备份为什么要冻结数据文件头的SCN及日志序列号

当发出begin backup以后，Oracle会对被备份的表空间说对应的数据文件触发文件级别的
检查点，将内容中属于该表空间的所有dirty block写入数据文件。检查点结束以后，数据
文件头部(第1，2号数据块)记录的检查点SCN号和日志序列号不再变化，直到end backup发出。
尽管热备会冻结文件头部的SCN和日志序列号，但是数据文件内容本身还是最新的，用户对
数据文件中的数据行做修改时，DBWn仍然会将最新的内容写入到被备份的表空间中去。

之所有要冻结DATAFILE的检查点SCN及日志序列号，是为了将来使用热备恢复的时候知道从
哪里开始应用重做记录，也就是从备份出来的数据文件头部记录的日志序列号对应的日志
文件开始，而在该日志文件中，则从数据文件头部记录的检查点SCN开始向后应用所有的
日志文件。

热备份完毕，发出end backup命令以后，这时数据文件头部的检查点SCN号将前推至数据库
检查点，同时日志序列号也将前推至当前最新的日志序列号。

--- 热备相关视图

v$backup 可以查看哪些表空间正出于热备状态
比如有时候我们热备某个表空间时，数据库或OS忽然crash, 再次startup库的时候，发现
报错，那么我们需要查询v$backup 来查看哪些出于热备状态，发出end backup, 然后开启
即可。

--- 备份控制文件

如果发生增加，删除或重命令数据文件或日志文件，那么我们应该备份控制文件。

备份控制文件的两种方式：

A. 二进制方式，一旦控制文件损坏，可以直接拿来使用。
alter database backup controlfile to '/u01/backup/control.ctl.bak' ;

B. SQL命令的方式在udump下生成一个trace文件。如果控制文件丢失，可以
选取这个文本文件中的create controlfile部分，将DB置为nomount状态，执行
脚本重建控制文件。
alter database backup controlfile to trace ;

--- 初始化参数及密码文件的备份，直接拷贝即可。

12.2 介质恢复

介质恢复的过程 -- restore(OS段文件复原) + recover(将归档日志或联机日志
重做记录apply到还原出来的文件上) 。

打开数据库时，所有的数据文件(除了offline及read only的),控制文件和联机日志文件
必须同步一致，才能打开数据库。否则必须恢复到一致才能打开。

--- 数据库的一致性

一致性是基于检查点SCN号(checkpoint SCN)和日志序列号而言的，通过比较各个文件的
文件头中记录的检查点SCN号和日志序列号是否相同来判断数据库是否为一致的。其中主
要的检查点SCN号都记录在控制文件中。

--- 检查点SCN (控制文件中)

在控制文件中记录了3种主要的检查点SCN号：
A, 系统检查点SCN号(system checkpoint SCN)
B, 数据文件检查点SCN号(datafile checkpoint SCN)
C, 结束检查点SCN号(end checkpoint SCN)

备注：还有一种检查点SCN记录在数据文件头部，start SCN (ORACLE将Start SCN号
存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery).

- 系统检查点SCN
当CKPT启动时，会将检查点结束时的SCN号记录在控制文件里，该检查点是全局范围的，
如果发生文件级别的检查点，比如表空间begin backup引起检查点，不会更新系统检查
点SCN 。系统检查点SCN可以通过v$database中的checkpoint_change# 查询到。

- 数据文件检查点SCN
当CKPT启动时，包括全局范围及文件级别的检查点，全局范围比如发生日志切换，这时
会在控制文件中记录每个数据文件上发生的检查点SCN . 使用v$datafile可以查询到每
个数据文件所对应的检查点SCN .

备注：将datafile设置为正常离线，只读，或将表空间设置为begin backup时，触发
文件级别的检查点，并将该检查点更新控制文件和数据文件头部后，就不再变化了。

例子：

SQL> alter tablespace users read only ;

发出后查询v$database中的checkpoint_change# 为 166025 ，这个是系统
检查点SCN, 查询v$datafile 中的 checkpoint_change# ，发现users表空间
对应的文件的数据文件检查点SCN号为 166026 ，而其他表空间对应的数据文
件检查点SCN 仍然为 166025，因为没有发生全局性检查点，所以控制文件中
的系统检查点SCN没有变化。其他数据文件没有发生文件级别的检查点，所以
数据文件检查点SCN号等于这时的系统检查点SCN, 没有增加。

- 结束检查点SCN
ORACLE将End SCN号存放在控制文件中。这个SCN号用于检查数据库启动过程是
否需要做instance recovery.

每个数据文件都会有一个结束SCN号，在数据库正常运行中，在线的和可读可写
的数据文件，其终止SCN都为空，而当正常关闭数据库时或者将数据文件设置为
begin backup, 正常offline或read only时，都会由于触发了检查点进程在控制
文件中记录每个数据文件上的结束SCN号，使用下面的SQL语句查询每个数据文件
的SCN号：
SQL> select file#, last_change# from v$datafile ;

可以发现其他数据文件的结束SCN都为空，设置为READ ONLY的有结束SCN号 166026 。

如果关闭数据库，然后开启为mount状态，发现每个文件都有结束SCN.
然后OPEN数据库，发现又回到只有read only的文件有结束SCN, 其他为空的状态。

-- 数据文件头中的检查点SCN与控制文件中记录的数据文件检查点SCN号含义是一样的。
也就是说，一旦发生全局范围以及文件级别的检查点时，不仅会将这时的检查点SCN号
记录到控制文件，还会记录在检查点作用的数据文件头部。

select name, checkpoint_change# from v$datafile_header ;

--------------------------------------------------------------------------------------------

几种重要的SCN

Commit SCN
当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redo buffer中，并马上更新到redo log 文件里。

Offline SCN
除了System tablespace以外的任何表空间，当我们执行SQL>alter tablespace … offline normal命令时，就会触发一个checkpoint，将内存中的dirty buffer写入磁盘文件中。Checkpoint
完成后，数据文件头会更新checkpoint scn和offline normal scn值。其中数据库文件头的checkpoint scn值可通过查询列x$kccfe.fecps得到。
如果执行SQL>alter tablespace …offline命令时采用temporary或 immediate选项，而不用normal选项时，offline normal scn会被设成0。这样当数据库重启后通过resetlog方式打开时，
该表空间就无法再改回在线状态。

Checkpoint SCN
当数据库内存的脏数据块(dirty blocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在数据库恢复中起着至关重要
的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpoint scn都相同时，数据库才能打开。虽然参数“_allow_resetlogs_corruption”可以在checkpoint scn不一致时强
制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。

Resetlog SCN
数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redo log也会被重新设置。

Stop SCN
Stop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打开过程
中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。

High and Low SCN
Oracle的Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。
在视图v$log_history中，sequence#代表redo log的序列号，first_change#表示当前redo log的low scn，列next_change#表示当前redo log的high scn。

--------------------------------------------------------------------------------------------

补充资料：
--------------------------------------------------------------------
以下资料来自于网络：
与checkpoint相关的SCN号有四个，其中三个存在控制文件中，一个存放在数据文件头中。
具体参考： http://space.itpub.net/35489/viewspace-674151
--------------------------------------------------------------------

数据库的一致性 --

在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN和
Start SCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当
中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN号为
NULL，则需要做instance recovery.ORACLE在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery.

当数据由于库正常关闭时，触发一个完全检查点，并用检查点结束时的SCN号更新几个数据
文件的检查点SCN号(除了offline的和read only的以外)，因此当下次启动数据库的时候，
会比较这几个检查点SCN号，如果他们相同，说明数据库是一致的，可正常打开DB.

如果数据库发生了非正常关闭, 数据库还来不及进行一个完全检查点,整个库就崩溃了,
这时, 由于来不及更新数据文件的终止SCN, 每个在线的以及可读写的数据文件的终止
SCN号仍然为空，下次启动数据库时，发现这些数据文件的终止SCN为空，则会由SMON
进程进行实例恢复。当SMON进程完成前滚后，打开数据库。

如果我们用备份的文件覆盖当前的数据文件，开启DB时Oracle会发现记录在控制文件
中的数据文件检查点SCN号与备份还原出来的数据文件头部记录的检查点SCN号不一致，
因为控制文件比较新，备份还原出来的数据文件比较旧，控制文件中记录的检查点SCN
号要大于还原出来的的数据文件头部记录的检查点SCN. 这时数据库不能打开，会要求
对检查点SCN比较小的还原的数据文件进行恢复，应用重做记录，从而将该数据文件头
部的SCN提升到控制文件中记录的检查点SCN号。

如果我们用旧的备份的控制文件覆盖当前的控制文件，这时控制文件比较旧，而数据
文件时当前最新的数据文件，数据库会发现控制文件里记录的数据文件检查点SCN号
要比数据文件头部检查点SCN号小，也会要求进行恢复。

在启动DB时，如果控制文件中的数据文件检查点SCN和数据文件头部记录的检查点SCN
相同，但是每个在线的可读写的数据文件之间，他们的检查点SCN不一致，也会要求
进行介质恢复。

补充：
----------------------------------------------------------

SCN号与数据库启动
在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN
和Start SCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当
中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN号为
NULL，则需要做instance recovery.ORACLE在启动过程中首先检查是否需要media
recovery，然后再检查是否需要instance recovery.

SCN号与数据库关闭
如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN
号设置为相应数据文件的Start SCN号。当数据库启动时，发现它们是一致的，则不需
要做instance recovery。在数据库正常启动后，ORACLE会将END SCN号设置为NULL.如果
数据库异常关闭的话，则END SCN号将为NULL.

为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号
    为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时，还需要为每
个数据文件记录Datafile Checkpoint SCN号？
原因有二：
    1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN
号均相同。这三个SCN在表空间处于只读期间都将被冻结。
    2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或
END SCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。

Recovery database using backup controlfile
当有一个Start SCN号超过了System Checkpoit SCN号时，则说明控制文件不是当
前的控制文件，因此在做recovery时需要采用using backup controlfile。这是为什么
需要记录System Checkpoint SCN的原因之一。这里需要一提的是，当重建控制文件的
时候，System Checkpoint SCN为0，Datafile Checkpoint SCN的数据来自于Start SCN。
根据上述的描述，此时需要采用using backup controlfile做recovery.

----------------------------------------------------------

12.2.1 完全恢复

完全恢复 -- 表示将数据库恢复到备份允许的最新状态，分为非归档及归档模式下的
完全恢复。

非归档完全恢复 -- 及时只是丢失一个数据文件，也必须还原所有的数据文件，
还原或不还原联机日志文件都可以(看是否有备份)，还原时用的备份必须是同
一个时间点上做的备份。

A. 在备份的时候，同时备份了联机日志文件
这个恢复过程很简单，只需要关闭DB, 通过OS命令拷贝最近的一次备份到原来目录即可。

B. 在备份的时候没有备份联机日志文件
按照上面的步骤拷贝数据文件及控制文件到原来目录，启动数据库时会报错找不到联机
日志文件或不匹配等类似信息，这时候我们可以：

SQL> recover database until cancel using backup controlfile ;

提示输入日志文件的时候，直接输入cancel ; 然后
SQL> alter database open resetlogs ;

--------------------------------------------------------------
备注：

在普通的recover database 或者 recover tablespace, recover datafile时
(即不加using backup controlfile)，Oracle会以当前controlfile所纪录的SCN为准，
利用archive log和 redo log的redo entry, 把相关的datafile的 block恢复到“当
前controlfile所纪录的SCN” .

而某些情况下，Oracle需要把数据恢复到比当前controlfile(一般当前controlfile是
以前备份的或着通过trace文件中的create controlfile新建的) 所纪录的SCN靠后的
位置，这时候，就需要用using backup controlfile. 恢复就不会受“当前
controlfile所纪录的SCN”的限制。这时候的限制就来自于你的语句(until time ,
until scn)，或者可用的archive log (until cancel) 。

create controlfile resetlogs/noresetlogs
1）．用noresetlogs重建控制文件时，控制文件中datafile checkpoint来自online
redo logs中的Current log头 ( 参考前面说到的，redo log 中也有对应的SCN ; redo损坏的话，就不能使用noresetlogs)
2）．用resetlogs重建控制文件时，控制文件中datafile checkpoint来自各数据文件头。

以下条件需要使用using backup controlfile
1）、使用备份控制文件
2）、重建resetlogs控制文件,如果重建立noresetlogs不必要使用using backup
controlfile

以下条件需要使用resetlog (使用resetlogs打开DB后务必完整备份一次数据库)
1）在不完全恢复（介质恢复）
2）使用备份控制文件

具体参考：
http://space.itpub.net/35489/viewspace-674270
--------------------------------------------------------------

12.2.1.2 归档模式下的完全恢复

1. 归档模式下，如果控制文件和联机日志文件都没有损坏，而数据文件损坏，那么只要
存在备份以及自从备份以来所有的归档日志文件，那么可以将DB恢复到发生介质损坏的
那个时间点上。

2. 如果所有控制文件损坏或者整个联机日志文件丢失，或自从最新的备份以来丢失了某
个归档日志文件，则不能进行完全恢复，只能进行不完全恢复。

--- 归档模式下完全恢复的三个级别：
A. 数据库级别； B. 数据文件级别； C. 表空间级别

恢复整个数据库需要将数据库启动到mount阶段，如果恢复某个数据文件或者恢复某个表
空间，则可以在数据库打开状态下进行 (系统表空间和undo表空间除外)。

--- 恢复过程
当发出recover命令时，Oracle从所有被还原的数据文件头中选择一个最小的检查点SCN号
及日志序列号，从该日志序列号指定的日志文件开始，向后依次开始应用所有的重做记录。
应用重做记录会一致持续，直到每个数据文件头部的检查点SCN号达到控制文件中所记录的
数据文件检查点SCN为止。

Oracle在恢复一个数据文件的时候，必须以独占的方式锁定被恢复的数据文件，如果不能
锁定，则报出错误。

--- 相关的视图
当数据文件损坏或丢失需要介质恢复时，我们可以先通过查询v$recover_file来确定哪些
文件需要进行介质恢复，然后可以查询v$recover_log 显示需要完全恢复受损的数据文件，
需要应用哪些日志文件。

--- 恢复方式
确定了要恢复的数据文件以后，我们可以确定使用那种方式进行恢复。

A. recover database : 数据库关闭的时候使用(mount阶段)，若系统表空间或undo表
空间损坏，或者所有数据文件损坏，只能使用这种方式。

B. recover tablespace + 表空间名或编号 : 可以在数据库open的状态下进行，在恢复
表空间之前，必须将要恢复的表空间离线(offline)。在非系统表空间及非undo表空间损坏
时，推荐使用该方式。注意，这里的数据库open指的是数据库一直是open的，虽然期间
有数据文件出问题需要recover .

C. recover datafile + 数据文件名或编号 : 数据库open或非open时(mount阶段)都能
使用，恢复之前，必须将要恢复的数据文件离线。数据库open时，不能用于系统表空间和
undo表空间的数据文件。

--- 使用归档进行恢复

让Oracle自动应用所有的归档日志，可以用以下方式：
A. SQL> set autorecovery on ;
SQL> recover datafile 4 ;
B. recover datafile 4 ; 输入auto .
C. recover automatic datafile 4 ;

--- 完全恢复例子：

1. 模拟user表空间损坏 (数据库为open状态)
SQL> create table hr.tab1 tablespace users as select * from user_objects;
SQL> !rm -rf $ORACLE_BASE/oradata/ora10g/user01.dbf
SQL> alter system flush buffer_cache ; 清空buffer cache;
SQL> select count(*) from hr.tab1 ; 报错

我们开始恢复users表空间 (这时数据库还是open状态)。

A. alter tablespace users offline immeidate ;
B. 还原user01.dbf的备份 ;
C. 查询v$recover_file 及 v$recover_log 视图;
D. recover automatic tablespace users ;

2. 数据库当前为关闭状态，系统表空间和undo表空间损坏。

A. 启动DB到mount阶段： SQL>startup mount ;
B. 还原系统表空间的数据文件或者受损的数据文件;
C. 恢复数据库 SQL> recover automatic database ;
或者只恢复受损的系统表空间即可
SQL > recover automatic datafile 1 ;

D. 打开数据库 SQL> alter database open ;

3. 数据库为关闭状态，系统表空间及UNDO都没有损坏，其他表空间损坏

A. 启动数据库到mount状态，SQL>startup mount;
B. 设置损坏的数据文件为离线状态
SQL>alter database datafile 4 offline ;
C. 从备份中还原4号文件； (因为受损的datafile已经离线，所以如果这时用户需要使用此数据库也是可以打开的)
D. SQL>recover automatic adtafile 4 ; (这时数据库可能是mount或open状态)
E. 恢复完成后将4号文件ONLINE
SQL> alter database datafile 4 online ;

4.   数据文件没有备份，恰好丢失，但是有这个文件创建以来所有的归档
A. 假设users表空间的users01.dbf丢失，将丢失的数据文件设置为OFFLINE
   SQL> alter database datafile 'xxxx' offline ;
B .因为没有user01.dbf的备份，我们需要重建一个内容为空的user01.dbf.
   SQL>alter database create datafile 'xxxx';
   我们可以查询v$datafile看到空的数据文件的scn是控制文件中记录的创建
   该数据文件时候的SCN.
C. 恢复数据文件 recover automatic datafile 6 ; 恢复完毕后可以查看到
   数据文件头部的检查点SCN与控制文件记录的检查点SCN一致，可以查看
   视图 v$datafile_header及v$datafile;
D. alter database datafile 6 online ;

12.2.2 不完全恢复

如果需要将数据库恢复到历史上的某个时间点，或者由于丢失了联机日志文件或归档日志文件，
或者使用了以前备份的控制文件进行恢复时，则进行的恢复叫做不完全恢复，恢复到历史时间
点后的数据变化将会全部丢失，不完全恢复比较危险，只有在必要的情况下才进行不完全恢复。

--- 通常出现以下情况才需要进行不完全恢复。

A. 进行完全恢复的时候如果丢失一个或多个归档，这时候只能将数据库做不完全恢复。
B. 丢失了整个联机日志组，而该联机日志文件组还没有完成归档。
C. 用户误删除了表中数据，表或某个重要用户，可以通过备份进行不完全恢复到误操作之前
的时间点。
D. 当前控制文件全部丢失，并使用了备份的控制文件进行恢复,这时进行的是不完全恢复，
不过如果所有归档及联机日志文件都在，仍然可以恢复所有的数据。

--- 进行不完全恢复的两个前提
A. 具有所有数据文件的备份，并且该备份是在要恢复到的时间点之前做的。
B. 具有从备份时间点开始，到要恢复的时间点之间的所有归档日志文件。

--- 存在以下三种类型的不完全恢复
A. 基于时间点的不完全恢复：
SQL> recover database until time 'yyyy-mm-dd hh24:mi:ss' ；
SQL> recover database until time '2010-09-10 14:29;16' ；
SQL> recover database automatic until time '2010-09-10 14:29;16' ；
SQL> alter database open resetlogs ；

B. 基于CANCEL的不完全恢复，恢复到我们输入cancel为止。这种方式通常用于丢失联机日志
文件或归档日志文件。
SQL> recover database until cancel;

C. 基于SCN的不完全恢复，和基于时间的恢复比较类似，如果我们能确定恢复到SCN,否则建议
使用基于时间点的恢复。
SQL> recover database until cancel scn ;

不完全恢复容易出现人为错误，所以在进行不完全恢复的之前最好关闭数据库，并进行冷备份。
如果没有条件冷备份，至少应该归档当前的联机日志文件及备份当前的控制文件：
SQL> alter system archive log current ;
SQL> alter database backup controlfile to trace (或某路径) ;

在不完全恢复之前，应该检查alter log文件，可能从中找到误操作的一些时间和SCN方面的信息。

--- 进行不完全恢复的步骤。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-673906/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-673906/