手工管理的备份和恢复

最新推荐文章于 2024-09-14 19:55:29 发布

cldh1492

最新推荐文章于 2024-09-14 19:55:29 发布

阅读量306

点赞数

文章标签：数据库操作系统运维

物理备份和逻辑备份

物理备份：

对数据库物理文件如数据文件、控制文件、重做日志文件进行备份，包括两种实现方式：

1）通过操作系统工具备份和管理；

2）使用RMAN工具备份和管理。

逻辑备份：

使用Oracle提供的数据迁移工具如EXP、EXPDP等导出数据库对象的逻辑结构定义和数据。相比物理备份，逻辑备份对数据库的恢复需要较长的时间，需要创建数据库对象并插入数据。

冷备和热备

冷备是在数据库关闭情况下的备份，它是一致的数据库备份。

热备是在数据库打开状态下的备份，此时用户可以继续访问数据库并进行DML操作，但要求数据库必须运行在归档模式。归档模式下可以对整个数据库或单独的数据库对象进行备份，而非归档模式无法做到。

实例恢复、介质恢复、完全和不完全恢复

实例恢复是指实例在遭遇失败造成数据库不一致如异常关闭后重启时，需要利用数据文件和联机重做日志文件对事务原子性进行的恢复，包括对联机日志文件中已提交记录写入数据文件的前滚和对数据文件中未提交记录进行删除的回滚。实例恢复需要的时间可以通过参数fast_start_mttr_target来控制，Oracle定时将脏数据写入数据文件以前移检查点，因此位于检查点之前的提交事务将不再需要前滚操作。实例恢复是Oracle自动完成的。

介质恢复是由于磁盘数据文件损坏而需要进行的数据库恢复，它不是Oracle自动完成的，需要人工干预来启动恢复过程。介质恢复需要备份的数据文件、归档日志和联机日志。介质恢复包括还原restore和恢复recover。还原是将备份的数据文件复制到对应的目录，恢复是利用归档日志文件和联机日志文件恢复数据库到最新状态或历史某个状态。恢复过程也包括前滚和回滚。

完全恢复是将数据库恢复到最新状态，不丢失任何数据。不完全恢复则是把数据库恢复到指定的历史时间点，会有数据丢失。通常不完全恢复是由于丢失了归档日志或联机日志而无法实现完全恢复，或是由于人为错误而需要将数据库回退到指定的历史时间点。

一、非归档模式下的冷备和恢复

1、非归档模式下的冷备份

干净的关闭数据库，将全部数据文件、控制文件、联机日志文件、临时文件复制到备份目录，然后重新打开数据库。以下可以生成冷备份的脚本。

set heading off

set timing off

set feedback off

set linesize 200

set pagesize 0

col name for a100

spool c:\bak.txt

select 'copy /y ' || name || ' e:\bak\' from v$controlfile

union all

select 'copy /y ' || name || ' e:\bak\' from v$datafile

union all

select 'copy /y ' || name || ' e:\bak\' from v$tempfile

union all

select 'copy /y ' || member || ' e:\bak\' from v$logfile;

spool off

联机日志文件和临时文件其实不是必须的，但前提条件是数据库必须被干净的关闭。如果由于某些错误造成实例异常终止，那么没有这些备份，还原后将无法打开数据库。

可能还需要备份参数文件，使用当前的SPFILE生成PFILE文件，即使实例关闭的也可以操作

create pfile = 'e:\bak\INITmes.ora' from spfile;

2、非归档模式下冷备份的恢复

关闭数据库，将备份的全部数据文件、控制文件、联机日志文件、临时文件及初始化参数文件复制到相应目录，重新打开数据库。此时在备份之后所做的全部工作将丢失。

如果没有联机日志文件，数据库只能启动到加载模式，此时可用备份的控制文件恢复数据库

recover database until cancel using backup controlfile;

在Oracle要求指定日志时，选择cancel，让Oracle自己寻找需要的日志到停止，然后用resetlogs打开数据库

alter database open resetlogs;

或者可以发出以下命令来重建所有的日志文件组，再打开数据库

alter database clear logfile group <group_number>;

二、归档模式下的热备份

1、手工热备数据库的步骤

1）以备份表空间users为例，将要备份的表空间至于备份模式

alter tablespace users begin backup;

此时通过v$backup可以查看表空间对应的数据文件是否处于备份状态

select * from v$backup;

FILE# STATUS CHANGE# TIME

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

1 NOT ACTIVE 0

2 NOT ACTIVE 0

3 NOT ACTIVE 0

4 ACTIVE 9797476 2017-01-18 14:41:40

5 NOT ACTIVE 0

6 NOT ACTIVE 0

7 NOT ACTIVE 0

8 NOT ACTIVE 0

9 NOT ACTIVE 0

其中状态status为active表示该数据文件处于备份模式。此时会单独对该文件做检查点，将缓冲区脏数据写入数据文件，并将其SCN号和对应的日志序列号冻结。但数据文件本身是可以继续正常DML操作的，发生变化的数据块中的所有记录都会被写入重做日志，而不是仅仅变化的记录，这使得进入热备后的时间段，日志生成量明显增大，故联机备份时不要一次备份过多的表空间，最好一个个切换，并选择在业务不忙时段进行。其后在恢复时，Oracle对由于操作系统块复制过程导致的数据块头尾版本号不一致的数据块执行恢复，恢复就从这个锁定的SCN开始，从重做日志中获取开始恢复的起点，并应用重做日志完成介质恢复，并解除数据文件中SCN和日志序列号的冻结，使所有数据文件头中记录的SCN一致，并被向前推进。

2）利用操作系统工具复制数据文件到备份的目录

3）结束表空间的备份模式

alter tablespace users end backup;

此时通过v$backup可以查看表空间对应的数据文件状态已经恢复为NOT ACTIVE。

4）做一次检查点

alter system checkpoint;

此时查看所有数据文件检查点数值都是一致的，并获得提升。

select file#, checkpoint_change# from v$datafile;

2、热备过程中对数据库崩溃的处理方法

在进入begin backup后，由于数据文件头SCN被冻结，此时如果出现实例失败如异常关闭，则重启后由于数据库文件SCN不一致，将提示需要介质恢复。此时数据库处于mount状态，可进行以下处理：

1）查看哪些文件仍处于热备状态

select * from v$backup;

需要对状态status为ACTIVE的数据文件执行介质恢复。

2）执行数据文件的恢复

recover datafile 4;

结束备份的命令也可以完成数据文件的恢复

alter tablespace users end backup;

3）打开数据库

alter datasbase open;

此时的数据文件已经是非备份模式，其状态status为NOT ACTIVE

select * from v$backup;

三、控制文件的备份

1、二进制备份

将控制文件备份到指定的二进制文件

alter database backup controlfile to 'd:\control_bak.ctl';

2、重建脚本的备份

备份到trace文件中的控制文件重建脚本

alter database backup controlfile to trace;

或者指定转储路径

alter database backup controlfile to trace as 'e:\bak\controlfile.log';

trace文件默认位于user_dump_dest参数指定的目录下

show parameter user_dump_dest;

NAME TYPE VALUE

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

user_dump_dest string c:\oracle\diag\rdbms\mes\mes\t

race

确定本会话进程的SPID

select spid from v$process where addr = (select paddr from v$session where sid = (select sid from v$mystat where rownum = 1));

由此找到trace文件<sid>_ora_<spid>.trc，在文件最后部分有一段重建控制文件的脚本

CREATE CONTROLFILE REUSE DATABASE "MES" RESETLOGS ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 'D:\ORADATA\MES\REDO01.LOG' SIZE 50M BLOCKSIZE 512,

GROUP 2 'D:\ORADATA\MES\REDO02.LOG' SIZE 50M BLOCKSIZE 512,

GROUP 3 'D:\ORADATA\MES\REDO03.LOG' SIZE 50M BLOCKSIZE 512

DATAFILE

'D:\ORADATA\MES\SYSTEM01.DBF',

'D:\ORADATA\MES\SYSAUX01.DBF',

'D:\ORADATA\MES\UNDOTBS01.DBF',

'D:\ORADATA\MES\USERS01.DBF',

'D:\ORADATA\MES\CMES01.DBF',

'D:\ORADATA\MES\RMES01.DBF',

'D:\ORADATA\MES\HMES01.DBF',

'D:\ORADATA\MES\INDX01.DBF',

'D:\ORADATA\MES\RMANCAT01.DBF'

CHARACTER SET ZHS16GBK;

3、使用RMAN的自动备份

设置RMAN的自动备份

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:\rman_bak\mes\control_bak\%F';

此后在执行RMAN的任何备份操作时都会自动备份控制文件和spfile文件。

数据库结构发生改变如增减表空间和数据文件时，会应用控制文件的自动备份。

需要注意，Oracle11g有控制文件自动备份延迟的特性。即使设置了控制文件的自动备份，在数据库结构发生改变后不会立即进行控制文件的自动备份，这是为了防止由于数据库结构发生多次改变而频繁的备份控制文件。这个延迟时间由隐含参数_controlfile_autobackup_delay决定，缺省值为300s。

四、不影响数据文件的介质失败的恢复

1、丢失多路复用的控制文件后的恢复

一旦有一路控制文件受损，实例就会终止。有三种恢复选择：

1）从完好的副本中复制一个来替换损坏的副本；

2）编辑参数文件或修改初始化参数control_files，删除对受损控制文件副本的引用；

3）更改初始化参数control_files，指向一个全新的文件来替换损坏的文件，该文件是实例关闭时从好的控制文件复制的。

第一种方法容易出错，可能相反的从损坏的副本中复制一个到原本完好的副本上，因此虽然简单，但并不推荐。第二种方法丢失了一个控制文件副本，给数据库的安全带来隐患，也不推荐。最好采用第三种方法，保证控制文件副本的多路复用。

2、丢失多路复用的联机重做日志文件后的恢复

丢失一个多路复用的联机日志成员并不会造成任何停机时间，但是警告日志文件中会有错误提醒。如果能容忍停机时间，那么可以关闭数据库，将日志组中的完好成员复制到受损文件上，然后重启数据库即可。如果必须在数据库打开状态下恢复，则需要使用alter database clear logfile group <group_number>命令清除并重建日志组文件，该组日志序列号sequence#将归0，状态status被置为unused。

命令alter database clear logfile group <group_number>能够执行的条件是该日志组必须处于未激活（inactive）状态，当前日志组（current）和仍处于活动状态（active）的日志组文件是不能清除的，另外如果数据库处于归档模式，则归档状态archived必须是已归档（yes）才可清除。如果需要强行清除尚未归档的日志，则使用alter database clear unarchived logfile group <group_number>。

3、丢失临时文件后的恢复

如果是临时文件受损，那么数据库仍可以打开。只有当使用到临时文件时才会出现问题，警告日志文件中会报告它们。修复临时文件的办法就是向临时表空间中添加另一个临时文件，然后删除受损的临时文件。

alter tablespace temp add tempfile 'd:\oradata\mes\temp02.dbf' size 100m;

alter tablespace temp drop tempfile 'd:\oradata\mes\temp01.dbf';

五、非归档模式下丢失非关键数据文件的处理

如果因为非关键数据文件（非SYSTEM、非当前UNDO表空间文件）的损坏导致无法访问或者数据库无法打开，则先使受损文件脱机，再打开数据库，但受损部分的数据将无法访问。

alter database datafile 'D:\ORADATA\MES\USERS01.DBF' offline drop;

除非实施了介质恢复，否则无法再使数据文件联机。但除非自上次恢复以来所有的变更都还在联机日志文件中，也就这种极少情况可以使用介质恢复

recover datafile 4;

alter database datafile 'D:\ORADATA\MES\USERS01.DBF' online;

否则将建议使用相应的归档日志来恢复，但又没有可用的归档，因此恢复将失败

ORA-00279: 更改 7707942 (在 09/29/2017 17:05:41 生成) 对于线程 1 是必需的

ORA-00289: 建议: C:\ORACLE\FLASH_RECOVERY_AREA\MES\ARCHIVELOG\2017_09_29\O1_MF_1_6_%U_.ARC

ORA-00280: 更改 7707942 (用于线程 1) 在序列 #6 中

17:09:17 指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

如果用之前的数据文件备份来覆盖损坏的文件，由于SCN不一致，同样无法打开和恢复。此时一个办法就是修改隐藏参数_allow_resetlogs_corruption，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态而强制打开。

alter system set "_allow_resetlogs_corruption"=true scope=spfile;

重启到mount状态

shutdown abort

startup mount

执行恢复

recover database until cancel using backup controlfile;

ORA-00279: 更改 7698469 (在 09/29/2017 15:27:01 生成) 对于线程 1 是必需的

ORA-00289: 建议: C:\ORACLE\FLASH_RECOVERY_AREA\MES\ARCHIVELOG\2017_09_29\O1_MF_1_2_%U_.ARC

ORA-00280: 更改 7698469 (用于线程 1) 在序列 #2 中

22:14:06 指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

cancel

ORA-10879: error signaled in parallel recovery slave

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误

ORA-01152: 文件 1 没有从过旧的备份中还原

ORA-01110: 数据文件 1: 'D:\ORADATA\MES\SYSTEM01.DBF'

用resetlogs方式打开数据库

alter database open resetlogs;

因为数据库是被强制打开的，可能存在因不一致导致的错误，因此应当立即通过导出导入重建数据库。

六、归档模式下的完全恢复

1、数据文件在有备份情况下的恢复

如果损坏的是非关键数据文件，数据库可以打开，恢复总结为以下四步：

使受损的文件脱机

还原文件

恢复文件

将恢复的文件联机

如果损坏的是关键数据文件，数据库只能启动到加载模式，恢复总结为以下四步：

加载数据库

还原文件

恢复文件

打开数据库

以下是一个恢复例子：

对表空间进行热备

alter tablespace cmes begin backup;

用操作系统命令备份数据文件cmes01.dbf

结束备份

alter tablespace cmes end backup;

更新cmes表空间数据，模拟备份后的业务

select * from cmes.c_line_t;

update cmes.c_line_t set plant_id=1000 where line_id=100;

commit;

select * from cmes.c_line_t;

关闭数据库

shutdown immediate

删除cmes表空间数据文件cmes01.dbf

重启数据库，提示数据文件故障

startup

...

数据库装载完毕。

ORA-01157: 无法标识/锁定数据文件 5 - 请参阅 DBWR 跟踪文件

ORA-01110: 数据文件 5: 'D:\ORADATA\MES\CMES01.DBF'

此时可以查看需要恢复的数据文件

col error for a30

select * from v$recover_file;

FILE# ONLINE ONLINE_ ERROR CHANGE# TIME

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

5 ONLINE ONLINE 10097581 2017-01-21 17:02:10

先将数据文件或数据文件对应的表空间离线，再打开数据库，使数据库其余业务可以进行

alter database datafile 5 offline;

alter database open;

用操作系统命令将备份的数据文件cmes01.dbf复制到数据文件对应的路径

恢复数据文件

recover datafile 5;

数据文件联机

alter database datafile 5 online;

查看数据未丢失

select * from cmes.c_line_t;

2、数据文件在无备份情况下的恢复

在数据文件无备份的情况下，没有还原这一步，恢复依赖于联机日志和归档日志的完备。

以下是一个恢复例子：

创建表空间、表，插入数据

create tablespace test datafile 'd:\oradata\mes\test01.dbf' size 100m;

conn scott/tiger

create table t1(id number) tablespace test;

insert into t1 values(100);

commit;

select * from t1;

关闭数据库

shutdown immediate;

将数据文件test01.dbf删除

重新打开数据库后报错

startup

...

数据库装载完毕。

ORA-01157: 无法标识/锁定数据文件 10 - 请参阅 DBWR 跟踪文件

ORA-01110: 数据文件 10: 'D:\ORADATA\MES\TEST01.DBF'

如果是在linux下，则不必关闭数据库，可以直接删除数据文件，之后刷新缓冲区，再查询数据时便会报错无法打开数据文件

alter system flush buffer_cache;

select * from t1;

ERROR at line 1:

ORA-01116: error in opening database file 10

ORA-01110: data file 10: '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/d:oradatamestest01.dbf'

ORA-27041: unable to open file

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

将数据文件离线

alter database datafile 10 offline;

在原目录重新创建一个新的同名数据文件

alter database create datafile 'd:\oradata\mes\test01.dbf';

恢复数据文件

recover datafile 10;

如果数据库未打开，则打开数据库

alter database open;

如果数据文件被离线，则重新联机

alter database datafile 10 online;

验证数据未丢失

conn scott/tiger

select * from t1;

3、系统表空间数据文件损坏的恢复

系统表空间数据文件损坏的修复类似于非系统表空间，但系统表空间数据文件损坏时，数据库总是无法打开的，因此必须在mount状态下恢复。

开始热备

alter tablespace system begin backup;

用操作系统命令备份system表空间数据文件system01.dbf

结束备份

alter tablespace system end backup;

关闭数据库

shutdown immediate

删除system表空间数据文件system01.dbf

重启数据库，提示数据文件1故障

startup

...

数据库装载完毕。

ORA-01157: 无法标识/锁定数据文件 1 - 请参阅 DBWR 跟踪文件

ORA-01110: 数据文件 1: 'D:\ORADATA\MES\SYSTEM01.DBF'

尝试将数据文件1离线，也是无法打开数据库的

alter database datafile 1 offline;

alter database open;

此时提示系统表空间被脱机

ORA-01147: SYSTEM 表空间文件 1 处于脱机状态

ORA-01110: 数据文件 1: 'D:\ORADATA\MES\SYSTEM01.DBF'

将备份的system01.dbf文件复制到数据文件对应的路径

执行介质恢复

recover datafile 1;

将数据文件1联机

alter database datafile 1 online;

打开数据库

alter database open;

如果是当前UNDO表空间数据文件的损坏，同system表空间数据文件的处理，即在mount状态下，复制回备份的数据文件，然后做recover datafile，再打开数据库。

如果是非当前UNDO表空间数据文件的损坏，由于不是当前的UNDO表空间，因此可以先将其offline，然后打开数据库，保证数据库业务的正常进行。之后drop掉损坏的UNDO表空间，删除其数据文件，重新创建新的非当前UNDO表空间。

七、归档模式下的不完全恢复

执行不完全恢复的四个步骤：

加载数据库

还原所有数据文件（必要时还原控制文件）

将数据库恢复到某个时间点

用RESETLOGS打开数据库

如果数据库当前的物理结构与执行还原的数据库物理结构不一致（如增加了表空间数据文件），则需要还原控制文件。恢复到某个时间点的操作有三种选择：

recover database until time '2008-12-31 13:50:00';

recover database until change 93228650;

recover database until cancel;

还原必须针对所有数据文件。所有情况下都将恢复到恰好在请求的停止点之前的变更向量上，将不会应用指定的SCN。如果恢复涉及到还未提交的事务处理的变化，那么将回滚这些变化。如果配置了RMAN恢复目录，还必须更新RMAN的存储信息，以更新控制文件中记录的降为1的日志序列号。

以下是一个人不完全恢复的例子：

创建测试用的表空间

create tablespace test datafile 'd:\oradata\mes\test01.dbf' size 100m;

连接到scott用户创建表并插入数据

conn scott/tiger

create table t1(n number) tablespace test;

insert into t1 values(100);

commit;

开始备份，将数据库置于备份模式

alter database begin backup;

找出所有数据文件并实施备份

select name from v$datafile;

用操作系统工具将所有数据文件复制到安全路径

退出数据库的备份模式

alter database end backup;

再插入数据并做几次日志切换模拟用户的活动

conn scott/tiger

insert into t1 values(200);

commit;

select * from t1;

conn / as sysdba

alter system switch logfile;

确定准确的恢复时间

select sysdate from dual;

SYSDATE

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

2017-10-01 16:36:40

删除测试表空间，确认无法查询到表数据

drop tablespace test including contents and datafiles;

终止实例

shutdown abort;

使用操作系统工具还原所有数据文件

加载数据库

startup mount

将数据库恢复到上面特定的时间，在提示需要的归档日志应用时逐个键入enter或者直接键入auto让Oracle自己定位需要的归档日志

recover database until time '2017-10-01 16:36:40';

使用resetlogs打开数据库

alter database open resetlogs;

此时再查表t1，会提示数据文件名需要更正

conn scott/tiger

select * from t1;

ORA-00376: 此时无法读取文件 5

ORA-01111: 数据文件 5 名称未知 - 请重命名以更正文件

ORA-01110: 数据文件 5: 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005'

查一下数据文件状态，5号文件需要更名和恢复

col file_name for a60

select tablespace_name, file_name, file_id, status, online_status from dba_data_files;

TABLESPACE_NAME FILE_NAME FILE_ID STATUS ONLINE_

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

USERS D:\ORADATA\MES\USERS01.DBF 4 AVAILABLE ONLINE

UNDOTBS1 D:\ORADATA\MES\UNDOTBS01.DBF 3 AVAILABLE ONLINE

SYSAUX D:\ORADATA\MES\SYSAUX01.DBF 2 AVAILABLE ONLINE

SYSTEM D:\ORADATA\MES\SYSTEM01.DBF 1 AVAILABLE SYSTEM

TEST C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005 5 AVAILABLE RECOVER

将待恢复的数据文件更名

alter database rename file 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005' to 'd:\oradata\mes\test01.dbf';

恢复数据文件，按照提示键入enter或auto完成恢复

recover datafile 5;

将数据文件联机

alter database datafile 5 online;

再查数据文件状态已恢复

col file_name for a60

select tablespace_name, file_name, file_id, status, online_status from dba_data_files;

TABLESPACE_NAME FILE_NAME FILE_ID STATUS ONLINE_

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

USERS D:\ORADATA\MES\USERS01.DBF 4 AVAILABLE ONLINE

UNDOTBS1 D:\ORADATA\MES\UNDOTBS01.DBF 3 AVAILABLE ONLINE

SYSAUX D:\ORADATA\MES\SYSAUX01.DBF 2 AVAILABLE ONLINE

SYSTEM D:\ORADATA\MES\SYSTEM01.DBF 1 AVAILABLE SYSTEM

TEST D:\ORADATA\MES\TEST01.DBF 5 AVAILABLE ONLINE

查询表数据确认恢复

conn scott/tiger

select * from t1;

启动RMAN连接目标和目录数据库

rman target / catalog rman/rman@catdb

更新存储库

reset database;

八、所有控制文件丢失的恢复方法

1、使用备份的控制文件来恢复

备份控制文件

alter database backup controlfile to 'd:\control01.ctl.bak';

创建表空间

create tablespace test datafile 'd:\oradata\mes\test01.dbf' size 100m;

连接到SCOTT用户创建表并插入数据

conn scott/tiger

create table t1(n number) tablespace test;

insert into t1 values(100);

commit;

关闭数据库

conn / as sysdba

shutdown immediate

用操作系统命令删除所有控制文件。

重启数据库，报错没有控制文件，只能启动到nomount

startup

ORA-00205: error in identifying control file, check alert log for more info

查看控制文件路径，将备份的控制文件复制到指定位置

show parameter control_files;

NAME TYPE VALUE

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

control_files string D:\ORADATA\MES\CONTROL01.CTL,

D:\ORADATA\FLASH_RECOVERY_AREA

\MES\CONTROL02.CTL

加载数据库

alter database mount;

查看控制文件中记录的数据文件SCN号和数据文件自己头部记录的SCN号是否一致，确定数据库需要恢复

select file#, checkpoint_change#, last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

1 10142090

2 10142090

3 10142090

4 10142090

5 10142090

6 10142090

7 10142090

8 10142090

9 10142090

select file#, checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1 10145529

2 10145529

3 10145529

4 10145529

5 10145529

6 10145529

7 10145529

8 10145529

9 10145529

可见从备份复制过来的控制文件中记录的SCN号较旧，因此需要恢复

recover database using backup controlfile;

选择auto，提示缺少归档日志

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

auto

ORA-00308: cannot open archived log 'D:\ARCHIVELOG\MES\ARC_774CE76E_1_933284598_28.LOG'

28这个序列号并未归档，而是当前的联机日志文件

col member for a50

select group#, t1.sequence#, t1.members, t2.member, t1.bytes, t2.type, t1.status, t1.archived from v$log t1 right join v$logfile t2 using (group#) order by group#, member;

GROUP# SEQUENCE# MEMBERS MEMBER BYTES TYPE STATUS ARC

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

1 28 1 D:\ORADATA\MES\REDO01.LOG 52428800 ONLINE CURRENT NO

2 26 1 D:\ORADATA\MES\REDO02.LOG 52428800 ONLINE INACTIVE YES

3 27 1 D:\ORADATA\MES\REDO03.LOG 52428800 ONLINE INACTIVE YES

再次执行恢复，使用联机日志组1，提示通过介质恢复后有一个新增的数据文件已记录到控制文件中，但未命名

recover database using backup controlfile;

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

D:\ORADATA\MES\REDO01.LOG

ORA-00283: recovery session canceled due to errors

ORA-01244: unnamed datafile(s) added to control file by media recovery

ORA-01110: data file 10: 'D:\ORADATA\MES\TEST01.DBF'

ORA-01112: media recovery not started

再次执行恢复，提示了该未命名的数据文件，或者查阅视图v$datafile可以看到该未命名的文件

recover database using backup controlfile;

ORA-00283: recovery session canceled due to errors

ORA-01111: name for data file 10 is unknown - rename to correct file

ORA-01110: data file 10: 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\UNNAMED00010'

修改数据库文件名和指向

alter database rename file 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\UNNAMED00010' to 'D:\ORADATA\MES\TEST01.DBF';

再次执行恢复，指定当前联机日志序列28，完成恢复

recover database using backup controlfile;

ORA-00279: change 10144487 generated at 01/22/2017 10:59:49 needed for thread 1

ORA-00289: suggestion : D:\ARCHIVELOG\MES\ARC_774CE76E_1_933284598_28.LOG

ORA-00280: change 10144487 for thread 1 is in sequence #28

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

D:\ORADATA\MES\REDO01.LOG

Log applied.

Media recovery complete.

用resetlogs打开数据库

alter database open resetlogs;

检查数据未丢失

conn scott/tiger

select * from t1;

2、通过重建控制文件来恢复

通过将控制文件备份到trace文件，可以获取控制文件的创建脚本，其存放位置在参数user_dump_dest指定的路径下，并根据备份会话的spid可以找到对应的trace文件<sid>_ora_<spid>.trc

alter database backup controlfile to trace;

show parameter user_dump_dest;

select spid from v$process where addr = (select paddr from v$session where sid = (select sid from v$mystat where rownum = 1));

也可直接指定文件位置

alter database backup controlfile to trace as 'e:\cf.log';

获取的控制文件创建脚本如下，这个脚本之前如果没有备份，可以从其它库中生成，参考修改

CREATE CONTROLFILE REUSE DATABASE "MES" RESETLOGS ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 'D:\ORADATA\MES\REDO01.LOG' SIZE 50M BLOCKSIZE 512,

GROUP 2 'D:\ORADATA\MES\REDO02.LOG' SIZE 50M BLOCKSIZE 512,

GROUP 3 'D:\ORADATA\MES\REDO03.LOG' SIZE 50M BLOCKSIZE 512

-- STANDBY LOGFILE

DATAFILE

'D:\ORADATA\MES\SYSTEM01.DBF',

'D:\ORADATA\MES\SYSAUX01.DBF',

'D:\ORADATA\MES\UNDOTBS01.DBF',

'D:\ORADATA\MES\USERS01.DBF'

CHARACTER SET ZHS16GBK;

创建表空间

create tablespace test datafile 'd:\oradata\mes\test01.dbf' size 100m;

连接到SCOTT用户创建表并插入数据

conn scott/tiger

create table t1(n number) tablespace test;

insert into t1 values(100);

commit;

关闭数据库

conn / as sysdba

shutdown immediate

用操作系统命令删除所有控制文件

重启数据库，报错无法定位到控制文件，此时只能启动到nomount

startup

ORA-00205: error in identifying control file, check alert log for more info

用之前准备好的控制文件创建脚本创建控制文件

重启数据库到mount状态

shutdown abort;

startup mount;

查看几个检查点号，由于重建控制文件，此时全局的检查点号和SCN号已变为0，这个检查点号从联机日志的first_change#中获得

select name, current_scn, checkpoint_change# from v$database;

NAME CURRENT_SCN CHECKPOINT_CHANGE#

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

MES 0 0

select group#, first_change#, status from v$log;

GROUP# FIRST_CHANGE# STATUS

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

1 0 UNUSED

3 0 CURRENT

2 0 UNUSED

而控制文件中记录的数据文件检查点号与之不同，它从数据文件头部获得

select file#, checkpoint_change#, last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

1 1009802

2 1009802

3 1009802

4 1009802

select file#, checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1 1009802

2 1009802

3 1009802

4 1009802

执行数据库恢复，选择auto，此时使用完了归档日志

recover database using backup controlfile;

ORA-00279: 更改 1009802 (在 10/02/2017 21:06:51 生成) 对于线程 1 是必需的

ORA-00289: 建议: E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_9.LOG

ORA-00280: 更改 1009802 (用于线程 1) 在序列 #9 中

21:10:39 指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00308: 无法打开归档日志 'E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_9.LOG'

ORA-27041: 无法打开文件

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

这里提示了需要恢复到SCN号1009802，这正是上面控制文件中记录的数据文件检查点号，查看归档日志信息

col name for a50

select name, sequence#, first_change#, next_change#, to_char(first_time, 'yyyy-mm-dd hh24:mi:ss') first_time, to_char(next_time, 'yyyy-mm-dd hh24:mi:ss') next_time, to_char(round(blocks * block_size / 1024 /1024, 2), '990.00') size_mb, to_char(completion_time, 'yyyy-mm-dd hh24:mi:ss') completion_time from v$archived_log order by sequence# desc;

NAME SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# FIRST_TIME NEXT_TIME SIZE_MB COMPLETION_TIME

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

E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_8.LOG 8 1007985 1007989 2017-10-02 21:01:30 2017-10-02 21:01:34 0.00 2017-10-02 21:13:46

E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_7.LOG 7 1007982 1007985 2017-10-02 21:01:28 2017-10-02 21:01:30 0.00 2017-10-02 21:13:46

E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_6.LOG 6 1005482 1007982 2017-10-02 20:45:43 2017-10-02 21:01:28 2.42 2017-10-02 21:13:46

可见当前最后的归档还不包括需要恢复到的SCN和时间，查看当前联机日志文件

col member for a60

col status for a10

select group#, t1.sequence#, t1.members, t2.member, t1.bytes, t2.type, t1.status, t1.archived, t1.first_change#, next_change# from v$log t1 right join v$logfile t2 using (group#) order by group#, member;

GROUP# SEQUENCE# MEMBERS MEMBER BYTES TYPE STATUS ARC FIRST_CHANGE# NEXT_CHANGE#

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

1 0 1 D:\ORADATA\MES\REDO01.LOG 52428800 ONLINE UNUSED YES 0 0

2 0 1 D:\ORADATA\MES\REDO02.LOG 52428800 ONLINE UNUSED YES 0 0

3 0 1 D:\ORADATA\MES\REDO03.LOG 52428800 ONLINE CURRENT YES 0 0

再次执行恢复，使用当前的联机日志文件来恢复

recover database using backup controlfile;

ORA-00279: 更改 1009802 (在 10/02/2017 21:06:51 生成) 对于线程 1 是必需的

ORA-00289: 建议: E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_9.LOG

ORA-00280: 更改 1009802 (用于线程 1) 在序列 #9 中

21:16:36 指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

D:\ORADATA\MES\REDO03.LOG

已应用的日志。

完成介质恢复。

以RESETLOGS打开数据库，已经可以正常打开

alter database open resetlogs;

但是这个时候仍然无法查到前面的数据，因为恢复过来的控制文件中不包含新增的数据文件信息，提示需要更正数据文件名

conn scott/tiger

select * from t1;

ORA-00376: 此时无法读取文件 5

ORA-01111: 数据文件 5 名称未知 - 请重命名以更正文件

ORA-01110: 数据文件 5: 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005'

查看数据文件信息

col filename for a60

select d.file#, ts#, d.name filename, d.bytes/1024/1024 bytes_M, d.enabled, d.status, t.name tablespace, d.creation_time from v$datafile d join v$tablespace t using (ts#);

FILE# TS# FILENAME BYTES_M ENABLED STATUS TABLESPACE CREATION_TIME

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

1 0 D:\ORADATA\MES\SYSTEM01.DBF 680 READ WRITE SYSTEM SYSTEM 2010-03-30 10:07:48

2 1 D:\ORADATA\MES\SYSAUX01.DBF 510 READ WRITE ONLINE SYSAUX 2010-03-30 10:07:52

3 2 D:\ORADATA\MES\UNDOTBS01.DBF 85 READ WRITE ONLINE UNDOTBS1 2010-03-30 11:07:21

4 4 D:\ORADATA\MES\USERS01.DBF 5 READ WRITE ONLINE USERS 2010-03-30 10:08:04

5 6 C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005 0 READ WRITE RECOVER TEST

更名新增的数据文件并恢复

alter database rename file 'C:\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\MISSING00005' to 'd:\oradata\mes\test01.dbf';

recover datafile 5;

ORA-00279: 更改 1009802 (在 10/02/2017 21:06:51 生成) 对于线程 1 是必需的

ORA-00289: 建议: E:\ARCHIVELOG\MES\ARC_7996D53A_1_956349309_9.LOG

ORA-00280: 更改 1009802 (用于线程 1) 在序列 #9 中

21:30:37 指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

auto

已应用的日志。

完成介质恢复。

再次查看数据文件信息

col filename for a50

select d.file#, ts#, d.name filename, d.bytes/1024/1024 bytes_M, d.enabled, d.status, t.name tablespace, d.creation_time from v$datafile d join v$tablespace t using (ts#);

FILE# TS# FILENAME BYTES_M ENABLED STATUS TABLESPACE CREATION_TIME

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

1 0 D:\ORADATA\MES\SYSTEM01.DBF 680 READ WRITE SYSTEM SYSTEM 2010-03-30 10:07:48

2 1 D:\ORADATA\MES\SYSAUX01.DBF 510 READ WRITE ONLINE SYSAUX 2010-03-30 10:07:52

3 2 D:\ORADATA\MES\UNDOTBS01.DBF 85 READ WRITE ONLINE UNDOTBS1 2010-03-30 11:07:21

4 4 D:\ORADATA\MES\USERS01.DBF 5 READ WRITE ONLINE USERS 2010-03-30 10:08:04

5 6 D:\ORADATA\MES\TEST01.DBF 100 READ WRITE OFFLINE TEST 2017-10-02 21:05:04

恢复过来的数据文件还处于脱机状态，将其联机

alter database datafile 5 online;

再次查看数据文件信息已联机

col filename for a50

select d.file#, ts#, d.name filename, d.bytes/1024/1024 bytes_M, d.enabled, d.status, t.name tablespace, d.creation_time from v$datafile d join v$tablespace t using (ts#);

FILE# TS# FILENAME BYTES_M ENABLED STATUS TABLESPACE CREATION_TIME

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

1 0 D:\ORADATA\MES\SYSTEM01.DBF 680 READ WRITE SYSTEM SYSTEM 2010-03-30 10:07:48

2 1 D:\ORADATA\MES\SYSAUX01.DBF 510 READ WRITE ONLINE SYSAUX 2010-03-30 10:07:52

3 2 D:\ORADATA\MES\UNDOTBS01.DBF 85 READ WRITE ONLINE UNDOTBS1 2010-03-30 11:07:21

4 4 D:\ORADATA\MES\USERS01.DBF 5 READ WRITE ONLINE USERS 2010-03-30 10:08:04

5 6 D:\ORADATA\MES\TEST01.DBF 100 READ WRITE ONLINE TEST 2017-10-02 21:05:04

确认数据未丢失

conn scott/tiger

select * from t1;

由于重建的控制文件没有临时表空间文件信息，因此还需要手工添加临时文件

alter tablespace temp add tempfile 'd:\oradata\mes\temp01.dbf' size 100m reuse autoextend on;

确认临时表空间文件状态

col file_name for a50

select t1.tablespace_name, t1.file_name, t1.bytes / 1024 / 1024, t1.status, t2.status, t2.enabled, t1.autoextensible, t2.creation_time from dba_temp_files t1 join v$tempfile t2 on t1.file_id = t2.file#;

TABLESPACE_NAME FILE_NAME T1.BYTES/1024/1024 STATUS STATUS ENABLED AUT CREATION_TIME

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

TEMP D:\ORADATA\MES\TEMP01.DBF 100 ONLINE ONLINE READ WRITE YES 2017-10-02 21:37:22

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

转载于:http://blog.itpub.net/28974745/viewspace-2145682/