Oracle 基于用户管理恢复的处理

================================

-- Oracle 基于用户管理恢复的处理

--================================

Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整。除了使用RMAN工具以及第三方备份与恢复工具之外，基于

用户管理的备份与恢复也是DBA经常使用的方式之一。本文首先介绍了恢复的相关概念，接下来详细讲述了在归档模式下使用基于用户管理恢

复的处理过程。

一、恢复的相关概念

介质恢复

首先使用备份还原数据，然后再应用归档日志、重做日志的恢复方式称为介质恢复。

介质恢复能将一个经过还原的数据更新到当前的时间点或之前的某个时间点。

通常介质恢复这个术语专指对数据文件进行恢复的过程。

数据块的介质恢复指数据文件中的个别数据块出现错误时进行的特殊恢复操作。

介质恢复通常又可以分为完全恢复和不完全恢复

完全恢复

使用数据库,表空间或数据文件的备份进行还原,再使用归档,重做日志或增量备份将数据更新到当前时间点

用户可以实现基于对数据库、表空间、数据文件执行完全恢复

对整个数据库实现完全恢复的步骤

启动数据库到mount 状态

确保所有需要被恢复的数据文件处于联机（online）状态

还原数据库或需要恢复的数据文件

应用联机重做日志或/与归档重做日志

对表空间及数据文件实现完全恢复的步骤

如果数据库处于打开状态，应将需要恢复的表空间或数据文件置为脱机(offline)状态

还原需要恢复的数据文件

应用联机重做日志或/与归档重做日志

使表空间或数据文件联机

不完全恢复

与完全恢复是同样的步骤，只不过不完全恢复仅仅是将数据恢复到某一个特定的时间点或特定的SCN，而

不是当前时间点。下列情况通常需要进行不完全恢复：

介质故障(media failure)导致部分或全部联机重做日志(online redo log)损坏

用户操作失误(user error)导致数据丢失,例如,用户由于疏忽而移除了表,提交了无效的数据到表

由于归档重做日志(archived redo log)丢失而无法进行完全恢复(complete recovery)

当前控制文件(control file)丢失，必须使用备份的控制文件打开(open)数据库

不完全恢复的步骤

关闭数据库并备份数据库(以防止恢复失败)

启动数据库到mount 状态

还原所有受损的数据文件，同时可以选择还原控制文件

将数据库恢复至某个时间点、序列、或系统改变号

使用RESETLOGS关键字打开数据库

注意：

在做不完全恢复前建议在恢复前后做一次备份，避免恢复失败导致不必要的损失

不完全恢复完成后，建议不要直接使用OPEN RESETLOGS 命令以读/写模式打开(open)数据库，而应先以只读模式打开数据库，

并检查是否已将数据库恢复到正确的时间点。如果恢复的时间点有误，在没有使用OPEN RESETLOGS命令的情况下，重新执

行恢复操作相对简单。如果恢复结果早于指定的时间点，只需重新执行恢复操作。如果恢复结果超过了指定的时间点，则

应再次还原数据库并重新进行恢复。

Flashback Database(闪回数据库)是一种进行不完全恢复的方法

不完全介质恢复的几种类型：

基于时间的恢复(Time-based recovery)　将数据恢复到指定的时间点

　          用户控制的恢复(Cancel-based recovery) 当用户提交CANCEL后停止恢复(此选项在使用RMAN时无效)

　          基于SCN 的恢复(Change-based recovery) 将数据恢复到指定的SCN

按重做日志序号恢复(Log sequence recovery)将数据恢复到指定的重做日志序号(仅使用RMAN时有效)

表空间按时间点恢复(tablespace point-in-time recovery，TSPITR)

可以将一个或多个表空间恢复到与数据库中其他表空间不同的时间点

TSPITR的适用情况：

因错误地移除(drop)及清除(truncate)表而进行的恢复

恢复存在逻辑错误的表

由于不正确的批处理作业或其他DML 语句导致数据库中部分数据有误，因而需要恢复

单独将某个方案(schema)恢复到与物理数据库中其他方案不同的时间点

(假设数据库中不同的方案使用不同的表空间)

恢复大型数据库(VLDB)中的一个表空间，而不必先使用备份复原整个数据库再执行所有前滚(roll-forward)操作

TSPITR的限制

SYSTEM表空间,UNDO表空间,或任何包含回滚段(rollback segment)的表空间无法使用TSPITR功能

与其它表空间有依赖性的表空间应当同时恢复被依赖的表空间，如两张表存在依赖性且位于不同的表空间

数据文件的介质恢复

用于对丢失或损坏的数据文件及控制文件进行恢复

也可恢复因没有使用OFFLINE NORMAL 选项执行脱机操作而造成数据丢失的表空间

数据文件介质恢复具有以下特点：

能够将数据修改应用到被还原(restore)的受损数据文件中。

能够使用归档重做日志(archived redo log)及联机重做日志(online redo log)。

需要用户显式的执行。

不能自动地检测介质故障(media failure)(即不能自动地执行复原操作)。但在使用备份进行复原后，能够自动地检测是否需要

通过介质恢复(media recovery)来恢复数据。

恢复所需时间完全由用户备份恢复策略(例如备份频率,并行恢复参数,上次备份后数据库内的事务量)决定,与Oracle内部机制无关

如果数据库内存在需要介质恢复(media recovery)的联机数据文件(online datafile)，那么此数据库将无法打开(open)，如果一个

数据文件需要介质恢复，那么此文件将无法联机。因此需要脱机该数据文件(非系统数据文件)再打开数据库。

在出现以下情况时需要进行介质恢复：

使用备份还原了一个数据文件。

使用备份还原了一个控制文件（即使此时所有数据文件都是最新的）。

将数据文件脱机(offline)时(无论是用户手动执行的，还是Oracle 自动执行的)没有使用OFFLINE NORMAL 选项。

如果数据库已经被一个实例打开，数据文件介质恢复将只能针对脱机数据文件。即便数据库只需进行崩溃恢复(crash recovery)，

用户也可以在数据库打开前执行介质恢复。此时，崩溃恢复仍会在数据库打开时自动运行。

　      需要注意的是，如果一个文件需要介质恢复，即使所有对此文件的修改都包含在联机重做日志文件中也必须进行介质恢复.也就是说，

即使无需应用归档重做日志也必须进行介质恢复。如果对无需恢复的数据文件执行了介质恢复，那么介质恢复将发现自己无需进行

任何处理，并发出"no recovery required(无需恢复)"错误。

数据块介质恢复（block media recovery）

能够在所有数据文件联机且可用的情况下对个别的数据块进行还原(restore)及恢复(recover)。如果数据错误局限在某些数据文件的

少量数据块中，此时适宜采用数据块介质恢复来对数据文件进行恢复。

数据块介质恢复是通过RMAN 来执行的。如果用户没有使用RMAN 作为数据库的备份方案，可以向RMAN存储仓库(repository)中添

加相关的用户管理的数据文件(user-managed datafile)信息及归档重做日志备份(archived redo log backup)信息，这样也能使用

RMAN 进行数据块介质恢复。

二、基于用户管理恢复的方法　

数据恢复时的常用视图

v$reover_file     --查询需要恢复的文件,该视图信息来自控制文件,如控制文件来自备份或重建过则信息会不准

v$archived_log    --查询所有归档日志列表

v$recovery_log    --查询所有需要用于恢复的日志

常用的recover命令

--mount状态下执行恢复

SQL> recover database

SQL> recover datafile '<dir>' | fileno

--open状态下执行恢复

SQL> recover tablespace users

SQL> recover datafile '<dir>' | fileno

配置恢复自动使用归档日志

在介质恢复前通过设置set autorecovery on来自动应用归档日志实现恢复

也可以在输入归档日志路径、文件名时输入auto

使用recover automatic命令

恢复文件到新路径

使用操作系统命令恢复文件到新位置

使用alter database rename file '<dir>' to '<dir>'

三、基于用户管理的完全恢复

1.下面创建演示环境

SQL> create tablespace bk datafile '/u01/app/oracle/oradata/orcl/bk01.dbf' --创建表空间bk

2  size 100m extent management local segment space management auto;

SQL> create user bk identified by bk default tablespace bk  --创建用户bk

2  temporary tablespace temp;

SQL> grant connect ,resource to bk;    --授予权限

SQL> conn bk/bk

SQL> create table tb_bk(id int,name varchar2(10));   --创建表tb_bk

SQL> insert into tb_bk select 0,'Jackson' from dual;   --插入记录

SQL> commit;

SQL> shutdown immediate;    --关闭实例

[oracle@oradb orcl]$ cp * /u01/app/oracle/coolbak/   --进行冷备

--重启数据库后使用bk登陆

SQL> conn bk/bk    --等陆后，假定该session为session1

SQL> select * from tb_bk;

ID NAME

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

0 Jackson

SQL> insert into tb_bk values(1,'Frank');  --插入一条新记录

SQL> commit;

SQL> select * from tb_bk;

ID NAME

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

0 Jackson

1 Frank

--打开另外一个session中修改表空间的备份模式，假定为session2

SQL> show user;

USER is "SYS"

SQL> alter tablespace bk begin backup;   --将表空间bk置于热备模式

[oracle@oradb orcl]$ cp bk01.dbf /u01/app/oracle/hotbak  --对表空间bk进行热备

SQL> alter tablespace bk end backup;    --解冻表空间bk

SQL> insert into tb_bk values(2,'Henry');  --在session1中再次插入新记录

SQL> commit;

SQL> select * from tb_bk;   --最终结果

ID NAME

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

0 Jackson

1 Frank

2 Henry

--归档日志

SQL> alter system switch logfile;

SQL> ho ls -lht /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_17

total 364K

-rw-r----- 1 oracle oinstall 2.0K Oct 17 12:39 o1_mf_1_15_6cnzjft0_.arc

-rw-r----- 1 oracle oinstall 1.0K Oct 17 12:39 o1_mf_1_14_6cnzjdnc_.arc

-rw-r----- 1 oracle oinstall 350K Oct 17 12:39 o1_mf_1_13_6cnzjcgf_.arc

2.完全恢复的几种场景

a.数据库处于关闭状态下的恢复

包括系统表空间(系统数据文件)、Undo 表空间、整个数据库

步骤：-->关闭实例-->还原数据文件-->使用归档日志更新到最新-->打开数据库

[oracle@oradb orcl]$ rm -f *.dbf

SQL> shutdown immediate;  --如果不能关闭数据库，直接使用shutdown abort

SQL> startup   --启动后出现错误提示

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

SQL> select * from v$recover_file;  --视图中显示需要恢复的文件

FILE# ONLINE  ONLINE_ ERROR                   CHANGE# TIME

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

1 ONLINE  ONLINE                          1734106 17-OCT-10

2 ONLINE  ONLINE                          1734106 17-OCT-10

3 ONLINE  ONLINE                          1734106 17-OCT-10

4 ONLINE  ONLINE                          1734106 17-OCT-10

5 ONLINE  ONLINE                          1734106 17-OCT-10

6 ONLINE  ONLINE                          1734106 17-OCT-10

7 ONLINE  ONLINE                          1734106 17-OCT-10

SQL> ho cp /u01/app/oracle/coolbak/* $ORACLE_BASE/oradata/orcl/          --*/

SQL> set autorecovery off;  --关闭自动恢复选项

SQL> recover datafile 1,2;  --仅仅恢复数据文件和

ORA-00279: change 1734106 generated at 10/17/2010 12:32:10 needed for thread 1

ORA-00289: suggestion : ?/flash_recovery_area/ORCL/archivelog/2010_10_17/o1_mf_1_13_%u_.arc

ORA-00280: change 1734106 for thread 1 is in sequence #13

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

auto    --自动寻找所需要的归档日志

Log applied.

Media recovery complete.

SQL>  select * from v$recover_file;    --可以看到数据文件,2已经不存在于该视图中

FILE# ONLINE  ONLINE_ ERROR                   CHANGE# TIME

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

3 ONLINE  ONLINE                          1734106 17-OCT-10

4 ONLINE  ONLINE                          1734106 17-OCT-10

5 ONLINE  ONLINE                          1734106 17-OCT-10

6 ONLINE  ONLINE                          1734106 17-OCT-10

7 ONLINE  ONLINE                          1734106 17-OCT-10

SQL> recover database；

SQL> alter database open;

SQL> select * from bk.tb_bk;

ID NAME

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

1 Frank

2 Henry

0 Jackson

b.数据库处于打开状态下，非系统数据文件丢失的恢复

将数据文件offline(alter database datafile n offline)

还原数据文件(restore)

恢复数据文件(recover datafile n)

使数据文件online (alter database datafile n online)

SQL> connect bk/bk

[oracle@oradb orcl]$ rm bk01.dbf    --删除bk01.dbf文件

SQL>  insert into tb_bk values(3,'Robinson');

SQL> commit;  --表空间所在的文件删除后还可以插入和提交,因为数据是被更新到数据缓冲区,commit是写日志,因此没有报错

SQL> select * from v$recover_file;  --在session1中查看是否有文件需要恢复

no rows selected                    --现在Oracle还不知道有数据文件丢失

SQL>  alter system switch logfile;  --对日志进行归档

SQL> alter system checkpoint;--执行检查点进程,将数据缓冲区内容写入到文件,因bk01.dbf已丢失,则告警日志将产生该记录

SQL> ho tail -n 20 /u01/app/oracle/admin/orcl/bdump/alert_orcl.log --日志文件已显示出错

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_ckpt_3195.trc:

ORA-01171: datafile 7 going offline due to error advancing checkpoint

ORA-01116: error in opening database file 7

ORA-01110: data file 7: '/u01/app/oracle/oradata/orcl/bk01.dbf'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

Sun Oct 17 13:52:09 2010

Thread 1 advanced to log sequence 19 (LGWR switch)

Current log# 1 seq# 19 mem# 0: /u01/app/oracle/oradata/orcl/redo01.log

SQL> alter database datafile 7 offline;

SQL> select * from v$recover_file;  --Oracle已发现有数据文件丢失，需要进行恢复

FILE# ONLINE  ONLINE_ ERROR                   CHANGE# TIME

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

7 OFFLINE OFFLINE FILE NOT FOUND                0

SQL> ho cp $ORACLE_BASE/hotbak/bk01.dbf /$ORACLE_BASE/oradata/orcl/  --使用先前热备的数据还原数据文件

SQL> recover datafile 7;                 --恢复数据文件

ORA-00279: change 1734321 generated at 10/17/2010 12:38:23 needed for thread 1

ORA-00289: suggestion : ?/flash_recovery_area/ORCL/archivelog/2010_10_17/o1_mf_1_13_%u_.arc

ORA-00280: change 1734321 for thread 1 is in sequence #13

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 1734352 generated at 10/17/2010 12:39:39 needed for thread 1

ORA-00289: suggestion : ?/flash_recovery_area/ORCL/archivelog/2010_10_17/o1_mf_1_14_%u_.arc

ORA-00280: change 1734352 for thread 1 is in sequence #14

ORA-00278: log file '?/flash_recovery_area/ORCL/archivelog/2010_10_17/

o1_mf_1_13_6cnzjcgf_.arc' no longer needed for this recovery

Log applied.

Media recovery complete.

SQL> alter database datafile 7 online;   --将修复的数据文件联机

Database altered.

SQL> select * from bk.tb_bk;   --记录已经被恢复

ID NAME

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

3 Robinson

1 Frank

2 Henry

0 Jackson

c.数据初始状态处于关闭状态下由于硬件故障，且需要在打开状态下的恢复(非系统数据文件)

启动到mount状态

将受损的数据文件offline

打开数据库

还原受损的数据文件(restore)

恢复受损的数据文件(recover)

将受损的数据文件online

此场景类似于b场景仅仅是需要先启动到mount状态,然后再将受损的数据文件脱机,并打开数据库,使之能提供服务.因此该演示省略.

d.数据文件无备份情况下的恢复

前提是非系统表空间

控制文件未被重新创建或恢复到以前的版本(丢失数据文件的描述信息应在数据字典和控制文件中)

该数据文件从文件开始到丢失期间的所有日志必须存在

使用下面的命令重建数据文件

alter database create datafile 'filename';

alter database create datafile 'filename' as 'new file name'; --可以放置到不同目录

步骤：-->先将丢失数据文件脱机-->重建数据文件-->应用归档日志-->联机恢复的数据文件

SQL> create tablespace bk2 datafile '/u01/app/oracle/oradata/orcl/bk02.dbf'

2  size 10m extent management local segment space management auto;

SQL> conn bk/bk

SQL> create table tb_bk2(id int,name varchar2(10)) tablespace bk2;

SQL> insert into tb_bk2 select * from tb_bk;

SQL> commit;

SQL> select * from tb_bk2;

ID NAME

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

3 Robinson

1 Frank

2 Henry

0 Jackson

SQL> conn / as sysdba

SQL> alter system checkpoint;

SQL> alter system switch logfile;

SQL> ho ls -lht $ORACLE_BASE/flash_recovery_area/ORCL/archivelog/2010_10_17

total 16M

-rw-r----- 1 oracle oinstall 2.5K Oct 17 18:45 o1_mf_1_21_6conxt0o_.arc

-rw-r----- 1 oracle oinstall 2.0K Oct 17 18:45 o1_mf_1_20_6conxq2n_.arc

-rw-r----- 1 oracle oinstall  16M Oct 17 18:45 o1_mf_1_19_6conxmch_.arc

SQL> ho rm $ORACLE_BASE/oradata/orcl/bk02.dbf

SQL> insert into bk.tb_bk2 select 4,'Danny' from dual;

SQL> commit;

SQL> alter system checkpoint;

SQL> alter database datafile 8 offline;

SQL> select * from v$recover_file;

FILE# ONLINE  ONLINE_ ERROR                 CHANGE# TIME

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

8 OFFLINE OFFLINE FILE NOT FOUND              0

SQL> alter database create datafile 8;

SQL> select * from v$recovery_log;

THREAD#  SEQUENCE# TIME      ARCHIVE_NAME

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

1         19 17-OCT-10 /u01/app/oracle/flash_recovery_area/ORCL

/archivelog/2010_10_17/o1_mf_1_19_6conxm

ch_.arc

1         20 17-OCT-10 /u01/app/oracle/flash_recovery_area/ORCL

/archivelog/2010_10_17/o1_mf_1_20_6conxq

2n_.arc

SQL> ho ls /u01/app/oracle/oradata/orcl/bk02.dbf

/u01/app/oracle/oradata/orcl/bk02.dbf

SQL> recover datafile 8;

Log applied.

Media recovery complete.

SQL> alter database datafile 8 online;

SQL> select count(1) from bk.tb_bk2;

COUNT(1)

----------

5

3.基于用户管理控制文件的备份与恢复，由于控制文件的重要性是不言而喻的，因此单独拿出来探讨，请参考下面的文章：

Oracle控制文件(CONTROLFILE)

Oracle 控制文件的备份与恢复

四、基于用户管理的不完全恢复

1.不完全恢复的几种常用方法

recover database until cancel;                       --SQLPlus使用

recover database until time '2009-10-09:14:20:45'    --SQLPlus与RMAN都支持

recover database unitl time '2009-10-09:14:20:45' using backup controlfile

recover database until change 329102      --SQLPlus使用

recover database until scn 329102         --RMAN使用

recover database until sequence  10       --RMAN使用

2.演示基于until time的恢复

SQL> ho cp $ORACLE_BASE/oradata/orcl/*  $ORACLE_BASE/coolbak/  --先做冷备  */

SQL> ho cp $ORACLE_BASE/oradata/arch/* $ORACLE_BASE/coolbak/   --备份归档日志  */

--启动数据库并使用bk帐户登陆到数据库

SQL> select * from tb2;

ID NAME

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

1 Robinson

SQL> insert into tb2 select 2,'Henry' from dual;

SQL> commit;

SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;

TO_CHAR(SYSDATE,'YY'

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

2010-10-20 11:51:04

SQL> drop table tb2;

SQL> shutdown abort;

SQL> ho rm $ORACLE_BASE/oradata/orcl/*.dbf           --*/

SQL> ho cp $ORACLE_BASE/coolbak/*.dbf $ORACLE_BASE/oradata/orcl/      --*/

SQL> startup mount;

SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

1            2123966

2            2123966

3            2123966

4            2123966

5            2123966

6            2123966

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1            2123965

2            2123965

3            2123965

4            2123965

5            2123965

6            2123965

SQL> recover database until time '2010-10-20:11:51:04';

Media recovery complete.

SQL> alter database open resetlogs;

SQL> select * from bk.tb2;

ID NAME

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

1 Robinson

2 Henry

注意：Until time 恢复的格式是固定的，即格式必须为"CCYY-MM-DD:HH24:MI:SS"，与会话的NLS_DATE_FORMAT设置无关

3.基于Until Cancel的不完全恢复

SQL> ho cp $ORACLE_BASE/oradata/orcl/* $ORACLE_BASE/coolbak           --*/

SQL> ho cp $ORACLE_BASE/oradata/arch/* $ORACLE_BASE/coolbak           --*/

SQL> startup

SQL> conn bk/bk

SQL> select * from tb2;

ID NAME

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

1 Robinson

2 Henry

3 Danny

4 Jackson

SQL> insert into tb2 values(5,'Andy');

SQL> commit;

SQL> alter system switch logfile;

SQL> ho strings $ORACLE_BASE/oradata/arch/log_1_9_732888106.arc | grep Andy  --归档日志中已经存在Andy记录

Andy

SQL> ho strings $ORACLE_BASE/oradata/orcl/tbs01.dbf | grep Andy   --未执行检查点时，数据文件中不存在Andy记录

SQL> alte system checkpoint;                                      --执行检查点进程

SQL> ho strings $ORACLE_BASE/oradata/orcl/tbs01.dbf | grep Andy   --执行后，数据文件中存在Andy记录

Andy

SQL> insert into tb2 values(6,'Martin');

SQL> commit;

SQL> alter system checkpoint;

SQL> alter database backup controlfile to trace as '/tmp/rectl.sql';    --备份控制文件

SQL> ho rm -f $ORACLE_BASE/oradata/orcl/*            -- 数据文件，控制文件，日志文件将全部丢失*/

SQL> shutdown abort                                  --强制关闭数据库

SQL> ho cp $ORACLE_BASE/coolbak/*.dbf /$ORACLE_BASE/oradata/orcl/    --仅对数据文件进行还原 */

SQL> ho cat /tmp/rectl.sql    --修改前面备份的控制文件如下，手动来创建控制文件

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 '/u01/app/oracle/oradata/orcl/redo01.log'  SIZE 30M,

GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log'  SIZE 30M,

GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log'  SIZE 30M

DATAFILE

'/u01/app/oracle/oradata/orcl/system01.dbf',

'/u01/app/oracle/oradata/orcl/undotbs01.dbf',

'/u01/app/oracle/oradata/orcl/sysaux01.dbf',

'/u01/app/oracle/oradata/orcl/users01.dbf',

'/u01/app/oracle/oradata/orcl/example01.dbf',

'/u01/app/oracle/oradata/orcl/tbs01.dbf'

CHARACTER SET AL32UTF8

;

SQL> start /tmp/rectl.sql

ORACLE instance started.

Control file created.

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 2193406 generated at 10/21/2010 12:00:52 needed for thread 1

ORA-00289: suggestion : /u01/app/oracle/oradata/arch/log_1_10_732888106.arc

ORA-00280: change 2193406 for thread 1 is in sequence #10

ORA-00278: log file '/u01/app/oracle/oradata/arch/log_1_9_732888106.arc' no

longer needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

cancel          --log_1_10_732888106.arc不存在，还没有生成归档，而是在联机日志文件中，联机日志丢失，输入cancel

Media recovery cancelled.

SQL> alter database open resetlogs;

SQL> alter tablespace temp add tempfile '/u01/app/oracle/oradata/orcl/temp01.dbf'

2  size 31457280 reuse autoextend on;

SQL> select * from bk.tb2;     --因为联机日志全部丢失，因此第六条记录丢失，无法恢复

ID NAME

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

1 Robinson

2 Henry

3 Danny

4 Jackson

5 Andy

五、总结

1.可以使用冷备、热备来进行基于用户管理方式的备份，生产数据库强烈建议在归档模式下运作。

2.基于用户管理方式的备份仅仅是直接copy数据库的三大文件，因此不利于I/O，空间扩展需求大。

3.对于系统表空间的恢复，需要将数据库置于mount状态下，而非系统表空间数据可以在数据库处于open阶段来完成。

4.在open阶段完成的数据还原恢复操作,需要先将表空间脱机,然后执行还原操作,恢复操作,当恢复操作成功后需要将表空间置于online.

5.基于不完全恢复操作支持until time,until cancel,until change等方式，不完全恢复操作将导致部分数据丢失。

6.注意基于用户管理的不完全恢复方式与使用RMAN实现不完全恢复方式使用不同的关键字，RMAN使用的是until scn,until sequence

转：http://blog.csdn.net/leshami/article/details/6041217