借助SCN的变化来理解oracle备份与恢复的基本原理
SCN是oracle挂在墙上的时钟。早上起床，曰“起床SCN”；吃早餐，名“早餐SCN”；出门上班，称之为“出门SCN”。我们的任何活动，都会对应一个SCN。我们可借助oracle内部的一个包来获取系统的SCN（注意：这里只是系统的scn，因为，oracle还有commit scn，checkpoint scn，select scn等等）。
SQL> select dbms_flashback.get_system_change_number "system's scn" from dual;
system's scn
------------
555956SQL> select creation_change# "oracle内部最小scn" from v$datafile where file#=1;
oracle内部最小scn
-----------------
9我们对oracle所在的事，她会记在当前日志组。我们可以用v$log来查询。
SQL> select group#,sequence#,status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 5 CURRENT
2 3 INACTIVE
3 4 INACTIVE SQL> create table t(id int,scn number) 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 * from t;
ID SCN
---------- ----------
1 585887
SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss';
Session altered.
SQL> select group#,status,first_change#,first_time from v$log;
GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -------------------
1 CURRENT 583374 2012/07/17 19:59:23
2 INACTIVE 560959 2012/07/17 17:13:32
3 INACTIVE 560981 2012/07/17 17:14:33继续我们的事，我们把当前日志组归档。
SQL> alter system switch logfile;
System altered.再瞧瞧v$log里面的first_change#
SQL> select group#,status,first_change#,first_time from v$log;
GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -------------------
1 ACTIVE 583374 2012/07/17 19:59:23
2 CURRENT 586090 2012/07/18 09:35:40
3 INACTIVE 560981 2012/07/17 17:14:33再来继续我们未完的事。
SQL> insert into t values(2,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from t;
ID SCN
---------- ----------
1 585887
2 586129
从这里我们可以看出，586129比当前日志组2的first_change#(586090)大。从而，证明了first_change#是当前日志组最小的SCN，之后，我们所做的任何事，产生的SCN，都会比这个来得大。
我们再日志却，将日志组2归档。
SQL> alter system switch logfile;
System altered.
SQL> select group#,status,first_change#,first_time from v$log;
GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -------------------
1 ACTIVE 583374 2012/07/17 19:59:23
2 ACTIVE 586090 2012/07/18 09:35:40
3 CURRENT 586181 2012/07/18 09:39:21现在，日志组3变成了当前日志组了，相应的first_change#也发生了变化。
再来继续我们事情。为了产生更多的归档日志，我们不断的插入，提交，却换。
SQL> insert into t values(3,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> insert into t values (4,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> insert into t values (5,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> insert into t values(6,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> insert into t values (7,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> insert into t values (8,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> select * from t;
ID SCN
---------- ----------
1 585887
2 586129
3 586643
4 586666
5 586692
6 586722
7 586751
8 586805我们再来看一下，当前日志组是哪一组？
SQL> select group#,status,first_change#,first_time from v$log;
GROUP# STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------------- ------------- -------------------
1 ACTIVE 586734 2012/07/18 09:45:12
2 ACTIVE 586762 2012/07/18 09:46:15
3 CURRENT 586816 2012/07/18 09:47:15当前的日志组是3.那么，我们再来插入。
SQL> insert into t values(9,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.这时，我们并没有却换日志组。然后，再插入。
SQL> insert into t values(10,dbms_flashback.get_system_change_number);
1 row created.注意了，此时，我们没有提交也没有却换。那么，第9,10条的数据都在日志组3上面。
这里，我们模拟一个实验来阐述备份与恢复的基本原理。
实验：正常关机下，数据文件损坏的完全恢复。
[oracle@localhost ~]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 17 20:48:19 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
[oracle@localhost ORCL]$ cd datafile/
[oracle@localhost datafile]$ ls
o1_mf_example_8050jhm7_.dbf o1_mf_temp_8050j34j_.tmp
o1_mf_sysaux_8050fk3w_.dbf o1_mf_undotbs1_8050fkc6_.dbf
o1_mf_system_8050fk2z_.dbf o1_mf_users_8050fkdh_.dbf
[oracle@localhost datafile]$ rm o1_mf_system_8050fk2z_.dbf
[oracle@localhost datafile]$ rm o1_mf_sysaux_8050fk3w_.dbf
[oracle@localhost datafile]$ rm o1_mf_users_8050fkdh_.dbf
[oracle@localhost datafile]$ rm o1_mf_undotbs1_8050fkc6_.dbf这个时候，假如我们要启动数据库会报什么错呢？
[oracle@localhost ~]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 17 20:57:00 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 419430400 bytes
Fixed Size 1219760 bytes
Variable Size 142607184 bytes
Database Buffers 272629760 bytes
Redo Buffers 2973696 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1:
'/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_8050fk2z_.dbf'因为，有控制文件，所以，我们会到mount状态，这是个oracle的介态。这个状态，我们可以做很多事。这时，它报文件1不能锁定。那么，我们一个个来。先把冷备的文件1拷来。
[oracle@localhost datafile]$ cp o1_mf_system_8050fk2z_.dbf /u01/app/oracle/oradata/ORCL/datafile
然后，再来打开数据库，看会报什么错？
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1:
'/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_8050fk2z_.dbf'这个时候报的错误不一样了。报文件1需要媒介恢复。oracle是根据什么报这个错误的呢？要了解这个，我们需要借助两个视图。
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 587004
2 587004
3 587004
4 587004
5 587004
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 583375
2 0
3 0
4 0
5 587004这两个视图所取的信息来源完全不一样。v$datafile的信息来自控制文件；v$datafile_header的信息则来自每个数据文件的文件头。我们刚刚已经把file 1拷回来，所以，oracle可以读到它头上的scn。而2,3,4已经被删了便是读不到的。但是，file 1在两处的scn不一致。记住了，oracle会横向比较，纵向是不会比较的。即：不会拿file 1和file 3比较。oracle打开的必要条件是控制文件和数据文件的文件头的scn要一致。那么大于583375，而小于585469的scn都在归档日志里面。每个scn对应相关的操作。
SQL> select sequence#,first_change#,next_change# from v$archived_log;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
5 544404 558719
6 558719 559931
7 559931 560709
8 560709 560959
9 560959 560981
10 560981 583374什么是next_change#?日志组由当前日志组却换到非当前日志组时，所取的系统scn，来作为它的最大scn。first_change#是它成为current的开始；而next_change#则是它结束了current生涯的标志。
我们知道，比583375小的scn都已经写入数据文件。现在，我们需要确定583375是落在哪对first_change#和next_change#之间。从而确定广义前滚的起点。
SQL> select sequence#,first_change#,next_change# from v$archived_log
2 where 583375>=first_change# and
3 583375<=next_change#;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
11 583374 586090由此，我们知道，583375落在归档日志11的first_change#和next_change#之间。我们恢复的时候，就从归档日志11开始。那么，我们到底需要多少的归档日志呢？
SQL> select sequence#,first_change#,next_change# from v$archived_log
2 where sequence#>=11;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
11 583374 586090
12 586090 586181
13 586181 586656
14 586656 586676
15 586676 586704
16 586704 586734
17 586734 586762
18 586762 586816从上面可知，如果我们想把数据全部找回，我们需要借助到归档日志18.我们看一下这些first_change#和next_change#有什么特色？
归档日志11的next_change#是归档日志12的first_change#。以此类推，所以，这么多的归档日志，其实，逻辑上就只是一个归档日志。因此，归档日志必须连续！如果，你归档日志13坏了，那么只能恢复到12的next_change#。后面再多的归档也是徒然。
接下来，我们开始恢复。
SQL> recover datafile 1;
ORA-00279: change 583375 generated at 07/17/2012 19:59:23 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_11_%u_.ar
c
ORA-00280: change 583375 for thread 1 is in sequence #11
Specify log: {=suggested | filename | AUTO | CANCEL} oracle告诉我们，583375 对于实例是需要的。并且，归档日志11在闪回区。如果敲回车，则采纳oracle的建议，oracle会自己到闪回区里面去找。我们敲一下回车键采纳oracle的建议。第二个选项，是不在默认路径里面，由你来告诉oracle，归档日志身在何处。你只要告诉oracle，归档日志的绝对路径+名称，就可以了。第三个选项，如果归档日志很多，一个个挨着去找，显得很麻烦，那么我们就去auto。第四个选项，如果恢复到一半，或者，没有了归档日志，那么你可以敲cancel。
ORA-00279: change 586090 generated at 07/18/2012 09:35:40 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_12_%u_.ar
c
ORA-00280: change 586090 for thread 1 is in sequence #12
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_11_80d4q
dmh_.arc' no longer needed for this recovery
Specify log: {=suggested | filename | AUTO | CANCEL} 这时，oracle会再告诉我们，日志12是实例所需要的。我们先把这事给搁着。先去数据文件文件头，把scn给取出来瞧瞧。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 586090
2 0
3 0
4 0
5 587004发现没？file 1 的scn变成了586090。而586090是归档日志12的first_change#。难怪oracle告诉我们日志12是实例必须的。接下来，我们敲auto。
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 586181 generated at 07/18/2012 09:39:21 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_13_%u_.ar
c
ORA-00280: change 586181 for thread 1 is in sequence #13
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_12_80d4y
9fp_.arc' no longer needed for this recovery
ORA-00279: change 586656 generated at 07/18/2012 09:42:06 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_14_%u_.ar
c
ORA-00280: change 586656 for thread 1 is in sequence #14
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_13_80d53
g42_.arc' no longer needed for this recovery
ORA-00279: change 586676 generated at 07/18/2012 09:42:59 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_15_%u_.ar
c
ORA-00280: change 586676 for thread 1 is in sequence #15
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_14_80d55
41h_.arc' no longer needed for this recovery
ORA-00279: change 586704 generated at 07/18/2012 09:44:03 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_16_%u_.ar
c
ORA-00280: change 586704 for thread 1 is in sequence #16
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_15_80d57
315_.arc' no longer needed for this recovery
Log applied.
Media recovery complete. 发现没？oracle只运用了归档日志到16。接下来的17,18就没有再提示了。为什么？我们先去数据文件的文件头把file 1的scn再取来看看。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 587003
2 0
3 0
4 0
5 587004587003是不是比归档日志18的next_change#(586816)来得大呢。我们再来看看，当前日子组是哪一组。
SQL> select group#,sequence#,status,first_change# from v$log;
GROUP# SEQUENCE# STATUS FIRST_CHANGE#
---------- ---------- ---------------- -------------
1 17 INACTIVE 586734
3 19 CURRENT 586816
2 18 INACTIVE 586762可以看出，归档日志19的first_change#为586816。而数据文件头的scn是587003。当我们敲recover datafile 1时，oracle在做完全恢复。完全恢复的起点和终点是已经确定了。起点在数据文件的文件头，终点在控制文件里获取。因为，归档重做日志文件17,18是从联机重做日志文件1,2里面读出来的。oracle会优先去找联机重做日志文件。或者说，完全恢复时，oracle会自己去找联机重做日志文件；不完全恢复，我们可以把online redo log file的绝对路径和名称输进去。当前日志组是3，它的first_change#为586816，而587003比这个数大。可见，oracle也将当前日志文件给用上了。
接着恢复。这次，我们把剩余的数据文件全部拷回。然后大家一起往前走，直到步伐一致时，才能够同时停下来，这样子，oracle就处于一致的状态了。
SQL> recover database;
ORA-00279: change 583375 generated at 07/17/2012 19:59:23 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_11_%u_.ar
c
ORA-00280: change 583375 for thread 1 is in sequence #11
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 586090 generated at 07/18/2012 09:35:40 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_12_%u_.ar
c
ORA-00280: change 586090 for thread 1 is in sequence #12
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_11_80d4q
dmh_.arc' no longer needed for this recovery
ORA-00279: change 586181 generated at 07/18/2012 09:39:21 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_13_%u_.ar
c
ORA-00280: change 586181 for thread 1 is in sequence #13
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_12_80d4y
9fp_.arc' no longer needed for this recovery
ORA-00279: change 586656 generated at 07/18/2012 09:42:06 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_14_%u_.ar
c
ORA-00280: change 586656 for thread 1 is in sequence #14
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_13_80d53
g42_.arc' no longer needed for this recovery
ORA-00279: change 586676 generated at 07/18/2012 09:42:59 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_15_%u_.ar
c
ORA-00280: change 586676 for thread 1 is in sequence #15
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_14_80d55
41h_.arc' no longer needed for this recovery
ORA-00279: change 586704 generated at 07/18/2012 09:44:03 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_16_%u_.ar
c
ORA-00280: change 586704 for thread 1 is in sequence #16
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_07_18/o1_mf_1_15_80d57
315_.arc' no longer needed for this recovery
Log applied.
Media recovery complete. 接下来，我们就可以打开数据库了。
SQL> alter database open;
Database altered.总结，这篇博客里，我利用SCN和正常关机下数据文件损坏的完全恢复来帮助自己和大家一起理解oracle备份与恢复的原理。如果有足，希望走过路过的网友，给力批评。oracle的备份与恢复是门艺术。大家一起成长。go for it。