用户管理的备份--冷备份

冷备份也被称为脱机备份，一致性备份。总所周知，Oracle的冷备份是在数据库正常关闭（normal，immediate，transactional）后，使用操作系统的文件复制命令进行的备份。可以备份的Oracle文件类型有：数据文件、控制文件、联机重做日志文件、参数文件、密码文件（冷备份通常是在noarchivelog模式下进行的备份，所以这里不涉及归档日志文件），其中数据文件和控制文件的备份是必须的。我想说的是，冷备并不是一件很容易的事情，起码在我是这样认为的。

一、备份过程
1、查看当前数据库的归档模式
SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USER_DB_RECOVERY_FILE_DEST
Oldest online log sequence     10
Current log sequence           12
2、正常关闭数据库，这个就不用多说了吧，大家都了解。
showdown immediate
3、拷贝所有数据文件，控制文件和在线重做日志文件到备份目录。

二、恢复实验

实验1：当数据文件损坏或丢失时，使用备份目录下的所有文件覆盖数据目录下的内容。这里注意一点：如果控制文件不在同一目录下的话，请用备份控制文件逐一覆盖，否则将会出现ORA-00214错误。然后就可以用startup命令打开数据库了。当然，在进行冷备后到数据文件损坏这期间的数据库变化都将丢失了。这是一个很容易理解的过程，大概这是让我们认为"冷备是很容易的一件事情！"的主要原因吧，这里步骤就不贴了。

实验2：当数据文件损坏或丢失时，用备份目录下的所有文件覆盖数据目录下的内容。这里注意一点：如果控制文件不在同一目录下的话，请用备份控制文件逐一覆盖，否则将会出现ORA-00214错误。

a.)在t1表中插入一条数据实验后观察
SQL> select * from t1;
         A B
---------- ----
         1 abcd
         2 abce
SQL> insert into t1 values (1,'abcf');
1 row created.
SQL> commit;
Commit complete.

b.)仅用备份目录下的数据文件和控制文件覆盖数据目录下的对应文件，然后使用startup mount加载数据库
SQL> startup mount
ORACLE instance started.
Total System Global Area  839282688 bytes
Fixed Size                  2217992 bytes
Variable Size             503318520 bytes
Database Buffers          331350016 bytes
Redo Buffers                2396160 bytes
Database mounted.

c.)执行不完全恢复
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 1106413 generated at 03/07/2014 21:51:24 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/db_1/dbs/USER_DB_RECOVERY_FILE_DESTarch_testdb_1_
12_841150380.dbf
ORA-00280: change 1106413 for thread 1 is in sequence #12
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

d.)打开数据库且重置联机重做日志
SQL> alter database open resetlogs;
Database altered.

e.)查看之前插入的记录已经丢失
SQL> select * from t1;
         A B
---------- ----
         1 abcd
         2 abce

试验3：当数据文件损坏或丢失时，使用备份目录下的对应数据文件替代数据目录下的损坏或丢失文件，在实验中，表中插入的记录不会由于文件的损坏而丢失，但是这样的恢复是有条件的。

a.)查看当前联机重做日志的序号
SQL> select sequence#,first_change#,status from v$log;
 SEQUENCE# FIRST_CHANGE# STATUS
---------- ------------- ----------------
         7       1054222 INACTIVE
         8       1054332 INACTIVE
         9       1095600 CURRENT

b.)创建一个观察结果用的表
SQL> create table t1 (a int,b varchar(4)) tablespace test;
Table created.
SQL> insert into t1 values (1,'abcd');
1 row created.
SQL> commit;
Commit complete.

c.)查看在创建表和插入一行记录后当前联机重做日志的序号是否发生变化
SQL> select sequence#,first_change#,status from v$log;
 SEQUENCE# FIRST_CHANGE# STATUS
---------- ------------- ----------------
         7       1054222 INACTIVE
         8       1054332 INACTIVE
         9       1095600 CURRENT
ok，这里的结果显示联机重做日志的序号，scn和状态都没有发生变化。

d.)正常关闭数据库：shutdown immediate

e.)删除表空间对应的数据文件，用备份目录下的同名文件来替代

f.)先startup mount，然后尝试打开数据库：alter database open
SQL> startup mount
ORACLE instance started.
Total System Global Area  839282688 bytes
Fixed Size                  2217992 bytes
Variable Size             503318520 bytes
Database Buffers          331350016 bytes
Redo Buffers                2396160 bytes
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/u01/app/oracle/oradata/prac/test01.dbf'
这里提示说文件9需要介质恢复

g.)进行介质恢复
SQL> recover datafile 9;
Media recovery complete.

h.)打开数据库验证表中插入的记录没有丢失
SQL> alter database open;
Database altered.
SQL> select * from t1;
         A B
---------- ----
         1 abcd

实验4：当数据文件损坏或丢失时，使用备份目录下的对应数据文件替代数据目录下的损坏或丢失文件。与实验3不同的是，这一次，联机重做日志被覆盖了，结果可以想象，这个文件无法恢复了。

SQL> select sequence#,first_change#,status from v$log;
 SEQUENCE# FIRST_CHANGE# STATUS
---------- ------------- ----------------
         7       1054222 INACTIVE
         8       1054332 INACTIVE
         9       1095600 CURRENT
SQL> insert into t1 values (2,'abce');
1 row created.
SQL> commit;
Commit complete.
SQL> select sequence#,first_change#,status from v$log;
 SEQUENCE# FIRST_CHANGE# STATUS
---------- ------------- ----------------
         7       1054222 INACTIVE
         8       1054332 INACTIVE
         9       1095600 CURRENT
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL>  select sequence#,first_change#,status from v$log;
 SEQUENCE# FIRST_CHANGE# STATUS
---------- ------------- ----------------
        10       1105414 INACTIVE
        11       1105417 INACTIVE
        12       1105421 CURRENT

经过上述操作后，正常关闭数据库，删除数据文件目录下的文件， 用备份目录下的同名文件来替代。然后先startup mount，然后尝试打开数据库：alter database open
SQL> startup mount
ORACLE instance started.
Total System Global Area  839282688 bytes
Fixed Size                  2217992 bytes
Variable Size             503318520 bytes
Database Buffers          331350016 bytes
Redo Buffers                2396160 bytes
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/u01/app/oracle/oradata/prac/test01.dbf'
这时再尝试介质恢复是无法成功的，因为我们需要的练级重做日志（9号日志）已经被12号日志给覆盖掉了，起始scn和重做记录都已经没有了。
SQL> recover datafile 9;
ORA-00279: change 1104411 generated at 03/07/2014 19:06:20 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/db_1/dbs/USER_DB_RECOVERY_FILE_DESTarch_testdb_1_
9_841150380.dbf
ORA-00280: change 1104411 for thread 1 is in sequence #9
Specify log: {=suggested | filename | AUTO | CANCEL}

三、总结

在实验2中：由于没有备份联机重做日志，现有的重做日志对于文件的恢复是无用的，所以Oracle允许重置联机重做日志；在实验3和实验4中：利用备份文件和联机重做日志修复的单个文件的损坏或丢失时，我们还得考虑联机重做日志是否被循环覆盖这样一个问题，比起之前的复制粘贴要复杂多了。相信还有更多的细节还没有了解到，所以说这个话题真的不是那么容易！

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

转载于:http://blog.itpub.net/29515435/viewspace-1103444/