从ＳＣＮ看热备份的原理

前言
　　
　　Oracle有四种备份方法：冷备份、热备份、ＲＭＡＮ备份、逻辑备份。其中冷备份和热备份都是用操作系统命令对Oracle文件直接进行拷贝，不同的是冷备份是把数据库关闭后再备份，而热备份则是在数据库打开的时候就直接进行拷贝。由于热备份是在线的备份，势必对生产系统有一定的影响，这影响有多大？另外热备份的同时，数据文件的写操作是不间断的，oracle如何在保障用户的正常操作下，对数据文件进行备份？备份出来的数据文件内部又是否是一致的？要解决上面的问题，我们需要知道热备份的工作原理，而本文主要是从ＳＣＮ的角度去分析热备份的原理。
　　
　　ＳＣＮ（SYSTEM CHANGE NUMBER）是一个流水号，ＳＣＮ做为oracle的系统改变号，用于记录Oracle的更改。它存在于控制文件、数据文件、数据块中。根据数据库状态的不同，这几个位置的ＳＣＮ号也不一样。在正常的运行情况下，控制文件和数据文件的ＳＣＮ号是一致的，当然排除了数据文件是只读或者offline的状态，这些ＳＣＮ号只会随检查点而更新，而数据块的ＳＣＮ号记录着oracle的最新的更改，随用户的对数据的操作而更新。
　　
　　实验
　　
　　我们的实验是在热备份的过程中和结束后，把各种ＳＣＮ号读出来，从而得出热备份的过程中，oracle到底对数据文件做了哪些改变。下面，我们就来开始我们的实验
　　
　　对users表空间进行热备份：
　　
　　SQL> alter tablespace users begin backup;
　　
　　Ｄump控制文件的信息
　　
　　alter system set events 'immediate trace name controlf level 10';
　　
　　这个方法不适用于windows平台，因为windows平台dump出来的trc文件是乱码，而在UNIX上面就可以看到很详细的信息。另外，这个命令的显示结果包含了文件头的内容。它和alter system set events 'immediate trace name file_hdrs level 10';　trace结果一样。
　　
　　Dump文件包含了数据文件、重做日志、归档日志等信息。下面只是截取一些重要的内容，结果如下：
　　
　　***************************************************************************
　　DATABASE ENTRY
　　***************************************************************************
　　(blkno = 0x1, size = 192, max = 1, in-use = 1, last-recid= 0)
　　DF Version: creation=0x9200000 compatible=0x8000000, Date　05/31/2005 14:04:55
　　DB Name "ORCL"
　　Database flags = 0x00404001
　　Controlfile Creation Timestamp　05/31/2005 14:04:55
　　Incmplt recovery scn: 0x0000.00000000
　　Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp　05/31/2005 14:04:55
　　Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp　01/01/1988 00:00:00
　　Redo Version: creation=0x9200000 compatable=0x9200000
　　#Data files = 5, #Online files = 5
　　Database checkpoint: Thread=1 scn: 0x0000.000ab401　//可以看到控制文件中的数据库ＳＣＮ号是ab401。这个值随checkpoint的触发而更改。
　　
　　Threads: #Enabled=1, #Open=1, Head=1, Tail=1
　　enabled　threads:　01000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　Max log members = 3, Max data members = 1
　　Arch list: Head=3, Tail=3, Force scn: 0x0000.000a52bbscn: 0x0000.000a52c0
　　Controlfile Checkpointed at scn:　0x0000.000ab401 10/12/2005 16:16:32　这个值通常会比database　checkpoint高一些，我不太清楚这个值记录什么的?
　　thread:0 rba:(0x0.0.0)
　　enabled　threads:　00000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　
　　***************************************************************************
　　CHECKPOINT PROGRESS RECORDS
　　***************************************************************************
　　(blkno = 0x4, size = 104, max = 1, in-use = 1, last-recid= 0)
　　THREAD #1 - status:0x2 flags:0x0 dirty:11
　　low cache rba:(0x8c.3818.0) on disk rba:(0x8c.3826.0)
　　on disk scn: 0x0000.000a5040 10/11/2005 18:54:24　　　//在磁盘上的ＳＣＮ号，这个值随ＤＢＷＮ的写入而更改
　　resetlogs scn: 0x0000.00000001 05/31/2005 14:04:55
　　heartbeat: 571458711 mount id: 1099251256
　　MTTR statistics status: 3
　　Init time: Avg: 6791202, Times measured: 3
　　File open time: Avg: 2051, Times measured: 19
　　Log block read time: Avg: 17, Times measured: 8193
　　Data block handling time: Avg: 8611, Times measured: 14
　　
　　***************************************************************************
　　DATA FILE RECORDS
　　
　　DATA FILE #5:
　　(name #9) /oracle/oradata/orcl/users01.dbf
　　creation size=3200 block size=8192 status=0xe head=9 tail=9 dup=1
　　tablespace 5, index=6 krfil=5 prev_file=0
　　unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
　　Checkpoint cnt:294 scn: 0x0000.000a5a1b 10/11/2005 20:51:28　　//数据文件的ＳＣＮ号，这个号是开始备份的ＳＣＮ号，很明显比当前的数据库的ＳＣＮ号ab401要小。
　　Stop scn: 0xffff.ffffffff 06/22/2005 09:40:13
　　Creation Checkpointed at scn:　0x0000.0000169a 05/31/2005 14:05:29
　　thread:1 rba:(0x2.566.10)
　　enabled　threads:　01000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　Offline scn: 0x0000.00000000 prev_range: 0
　　Online Checkpointed at scn:　0x0000.00000000
　　thread:0 rba:(0x0.0.0)
　　enabled　threads:　00000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　Hot Backup end marker scn: 0x0000.00000000
　　aux_file is NOT DEFINED
　　
　　数据文件：
　　
　　Checkpoint cnt:294 scn: 0x0000.000a5a1b 10/11/2005 20:51:28　　//这个ＳＣＮ号也一样给lock了。远小于当前数据库的ＳＣＮ号
　　
　　数据块的信息
　　
　　这里，我们建立一个简单的表，以观察在备份的过程中数据块的变化。
　　
　　SQL> create table test (id number);
　　
　　Table created.
　　
　　SQL> exec show_space('TEST','auto');
　　Total Blocks............................8
　　Total Bytes.............................65536
　　Unused Blocks...........................5
　　Unused Bytes............................40960
　　Last Used Ext FileId....................5
　　Last Used Ext BlockId...................16
　　Last Used Block.........................3
　　
　　PL/SQL procedure successfully completed.
　　SQL> alter system dump datafile 5 block 20;
　　
　　System altered.
　　
　　SQL> insert into test values(3);
　　
　　1 row created.
　　
　　SQL> alter system dump datafile 5 block 20;
　　
　　System altered.
　　
　　SQL> commit;
　　
　　Commit complete.
　　
　　SQL>　alter system dump datafile 5 block 20;
　　
　　System altered.
　　
　　SQL>
　　/oracle/admin/orcl/udump/orcl_ora_11302.trc
　　Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
　　With the Partitioning, OLAP and Oracle Data Mining options
　　JServer Release 9.2.0.4.0 - Production
　　ORACLE_HOME = /oracle/product/9.2.0
　　System name:　　　　Linux
　　Node name:　　　　idsserver
　　Release:　　　　2.4.21-15.ELsmp
　　Version:　　　　#1 SMP Thu Apr 22 00:18:24 EDT 2004
　　Machine:　　　　i686
　　Instance name: orcl
　　Redo thread mounted by this instance: 1
　　Oracle process number: 10
　　Unix process pid: 11302, image: oracle@idsserver (TNS V1-V3)
　　
　　*** 2005-10-11 20:51:50.837
　　*** SESSION ID:(9.153)
　　Start dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　buffer tsn: 5 rdba: 0x01400014 (5/20)
　　scn: 0x0000.000a5a2d seq: 0x01 flg: 0x06 tail: 0x5a2d0601　　　//可以看出，block 的scn号要比control的大，它记录了当前块的最新ＳＣＮ号，对此块的任何操作都会导致ＳＣＮ增加。
　　frmt: 0x02 chkval: 0xe010 type: 0x06=trans data
　　Block header dump:　0x01400014
　　Object id on Block? Y
　　seg/obj: 0x189d　csc: 0x00.a57ff　itc: 2　flg: E　typ: 1 - DATA
　　brn: 0　bdba: 0x1400011 ver: 0x01
　　inc: 0　exflg: 0
　　
　　Itl　　　　　 Xid　　　　　　　　　Uba　　　　 Flag　Lck　　　　Scn/Fsc
　　0x01　 0x000a.003.0000003f　0x008000a4.0017.0d　--U-　　1　fsc 0x0000.000a5818
　　0x02　 0x0002.01b.00000041　0x008003a4.002c.1f　--U-　　1　fsc 0x0000.000a58a0
　　
　　data_block_dump,data head