小e随笔：这部分主要是用户管理备份恢复方式，属于早期的恢复方式，虽然现在有了RMAN和flashback,但这种恢复方式还是值得研究和了解。
1 了解与恢复相关的信息
1.1 理解警告日志文件
警告日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般命令规则为calert_<SID>.log，如我的测试数据库的警告日志文件的名称为calert_elvis.log。
警告日志文件的路径是根据初始参数
SQL> show parameter background_dump_dest;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest string /u01/app/oracle/diag/rdbms/elvis/elvis/trace
我的11g数据库，我发现与10g有些许不同，在10g中警告日志应该在bdump文件夹里，但是在11g里单独有一个diag文件夹，不知道11g是不是都这样，还是单独我的环境是，初次使用11g。。。，先不管啦，总之大同小异，能找到警告日志文件就行，找不到没关系，用上面的参数先看下。
1.2 后台进程跟踪文件
后台进程跟踪文件的路径与警告日志文件的路径一致，这通常是一个服务器进程对某种异常错误条件作出响应时创建的诊断文件。在某些情况下，你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。
1.3 v$recover_file和v$recovery_log
这是两个动态性能视图，可以在mount下查看，通过这两个视图，你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。
2 完全脱机备份 --archivelog|noarchivelog
案例1：归档模式下一个或多个数据文件损坏，其它文件都完好
备份方案： OS冷备份
l 关闭数据库&备份文件
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
[oracle@elvis elvis]$ cp sys* undotbs01.dbf users01.dbf bak/ --OS备份文件
l 开启数据库&模拟数据
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted.
Database opened.
SQL> create table t(id int,scn int) tablespace users; --创建表模拟数据
Table created.
SQL> insert into t values(1,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> select group#,sequence#,archived,status from v$log; --查看redo log
GROUP# SEQUENCE# ARC STATUS
---------- ---------- --- ----------------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT --当前在第3组
SQL> alter system switch logfile; --日志切换
System altered.
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARC STATUS
---------- ---------- --- ----------------
1 4 NO CURRENT --日志切换成功当前为第1组
2 2 YES INACTIVE
3 3 YES ACTIVE
重复上述动作，最终表中数据如下：
SQL> select * from t;
ID SCN
---------- ----------
1 904079
2 904222
3 904236
4 904243
5 904251 --其中这条没有commit
l 这时模拟毁坏一个或多个数据文件
Linux操作系统可以在线删除文件，这个跟贴近于实际
Win下只能能操作系统关闭才能删除文件，但关闭的时候最好用abort
我的环境是Linux可以在线删除数据文件。
[oracle@elvis elvis]$ ll
total 1916456
drwxr-xr-x 2 oracle oinstall 4096 Oct 1 19:46 bak
-rw-r----- 1 oracle oinstall 9748480 Oct 1 20:06 control01.ctl
drwxr-x--- 4 oracle oinstall 4096 Oct 1 13:49 ELVIS
-rw-r----- 1 oracle oinstall 52429312 Oct 1 20:05 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Oct 1 19:59 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Oct 1 20:00 redo03.log
-rw-r----- 1 oracle oinstall 629153792 Oct 1 20:05 sysaux01.dbf
-rw-r----- 1 oracle oinstall 734011392 Oct 1 20:05 system01.dbf
-rw-r----- 1 oracle oinstall 71311360 Sep 30 11:06 temp01.dbf
-rw-r----- 1 oracle oinstall 408952832 Oct 1 20:05 undotbs01.dbf
-rw-r----- 1 oracle oinstall 5251072 Oct 1 20:05 users01.dbf
[oracle@elvis elvis]$ rm -fr sys* undotbs01.dbf users01.dbf
[oracle@elvis elvis]$ ls
bak control01.ctl ELVIS redo01.log redo02.log redo03.log temp01.dbf
删除后，这个地方需要注意下，数据文件损坏后，数据库不会直接宕掉。
然后关闭数据库 --这个地方要用abort，因为你正常关闭数据库会报错，因为文件缺失无法归档
SQL> shutdown abort
ORACLE instance shut down.
l 开启数据库
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted. –在数据加载的时候提示，数据文件丢失，详情可以看跟踪文件
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/u01/app/oracle/oradata/elvis/system01.dbf'
l 数据文件的恢复
模拟总共丢失4个文件，大同小异，我就一次性把丢失的文件全拷贝回来（restore过程）
SQL> select file#,checkpoint_change# from v$datafile; --它来自于控制文件
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 904249
2 904249
3 904249
4 904249
SQL> select file#,checkpoint_change# from V$datafile_header; --它来自于数据文件头
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 0
2 0
3 0
4 0
它俩的scn必须保持一致，才能正常开启数据库
[oracle@elvis bak]$ cp sys* undotbs01.dbf users01.dbf /u01/app/oracle/oradata/elvis/
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 904249
2 904249
3 904249
4 904249
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 903863
2 903863
3 903863
4 903863
查看需要恢复的数据文件和日志
SQL> col error format a5;
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ----- ---------- ---------
1 ONLINE ONLINE 903863 01-OCT-12
2 ONLINE ONLINE 903863 01-OCT-12
3 ONLINE ONLINE 903863 01-OCT-12
4 ONLINE ONLINE 903863 01-OCT-12
SQL> col archive_name format a50;
SQL> select * from v$recovery_log;
THREAD# SEQUENCE# TIME ARCHIVE_NAME
---------- ---------- --------- --------------------------------------------------
1 3 01-OCT-12 /u01/app/oracle/flash_recovery_area/ELVIS/archivel
og/2012_10_01/o1_mf_1_3_86m18vlk_.arc
1 4 01-OCT-12 /u01/app/oracle/flash_recovery_area/ELVIS/archivel
og/2012_10_01/o1_mf_1_4_86m1fkbb_.arc
所需要的3和4归档日志文件都在
[oracle@elvis 2012_10_01]$ ll
total 13016
-rw-r----- 1 oracle oinstall 1536 Oct 1 13:51 o1_mf_1_1_86lctbbm_.arc
-rw-r----- 1 oracle oinstall 2892800 Oct 1 16:34 o1_mf_1_2_86lodm42_.arc
-rw-r----- 1 oracle oinstall 10380800 Oct 1 19:57 o1_mf_1_3_86m18vlk_.arc
-rw-r----- 1 oracle oinstall 8704 Oct 1 19:59 o1_mf_1_4_86m1fkbb_.arc
-rw-r----- 1 oracle oinstall 3072 Oct 1 19:59 o1_mf_1_5_86m1fxy9_.arc
-rw-r----- 1 oracle oinstall 2560 Oct 1 20:00 o1_mf_1_6_86m1g9y8_.arc
-rw-r----- 1 oracle oinstall 3072 Oct 1 13:49 o1_mf_1_79_86lcqbqr_.arc
也可以通过这个视图定位是从哪个归档日志文件开始恢复
SQL> select sequence#,first_change#,first_time,next_change#,next_time from v$archived_log where first_change#<=903863 and next_change#>=903863 ;
SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ------------- --------- ------------ ---------
3 896073 01-OCT-12 904174 01-OCT-12
刚开始记得详细一些，以后可就不这样啰嗦啦！！！
开始恢复，这些归档在默认路径下，Oracle都会自动定位所需要的归档日志。
可以一个一个文件恢复
--recover datafile 1;
但我这丢失了4个文件，一个一个恢复较麻烦，可以按以下命令来。
SQL> recover database;
ORA-00279: change 903863 generated at 10/01/2012 19:38:33 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_01/o1_mf_1_3_86m18vlk_.arc
ORA-00280: change 903863 for thread 1 is in sequence #3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 904174 generated at 10/01/2012 19:57:15 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_01/o1_mf_1_4_86m1fkbb_.arc
ORA-00280: change 904174 for thread 1 is in sequence #4
Log applied.
Media recovery complete.
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 924841
2 924841
3 924841
4 924841
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 924841
2 924841
3 924841
4 924841
SCN一致了，可以正常开启数据库了，但在开启之前，还有个问题，应该强调下。
SQL> select sequence#,first_change#,first_time,next_change#,next_time from v$archived_log where sequence#>=1 and sequence#<=6;
SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ------------- --------- ------------ ---------
1 852915 01-OCT-12 872923 01-OCT-12
2 872923 01-OCT-12 896073 01-OCT-12
3 896073 01-OCT-12 904174 01-OCT-12
4 904174 01-OCT-12 904235 01-OCT-12
5 904235 01-OCT-12 904242 01-OCT-12
6 904242 01-OCT-12 904249 01-OCT-12 --恢复的924841比归档日志文件里最大的SCN都大
6 rows selected.
这是因为
--select * from v$log;
--select * from v$logfile;
因为当前三个重做日志文件，还在且没有被覆盖，所以Oracle优先使用了这几个文件SCN，且这三个文件又是当前数据库的一部分，并用到了当前重做日志文件7，所以比归档日志文件里最大的SCN大。
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARC STATUS
---------- ---------- --- ----------------
1 7 NO CURRENT
3 6 YES INACTIVE
2 5 YES INACTIVE
l 成功恢复数据库
SQL> alter database open;
Database altered.
SQL> select * from t;
ID SCN
---------- ----------
1 904079
2 904222
3 904236
4 904243
恢复的非常成功，除了没有提交的id=5(rollback了)的数据之外数据显然都恢复回来了。
总结：
这种备份方式，数据虽然不会丢失，但需要在数据库关闭情况下备份，这在实际业务中，很有局限性，而且直接使用操作系统的copy命令即浪费了时间又浪费了空间，除非特殊情况下，否则不建议冷备份。但完全脱机备份也有个好处就是它在归档和非归档模式下都适用，而且操作简单。
elvis
2012.10.2
知识共享~共同进步
转载请注明：
http://blog.csdn.net/elvis_dataguru/article/details/8044905