从ＳＣＮ看热备份的原理

前言
　　
　　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)
　　 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 header at 0xad7be64
　　===============
　　tsiz: 0x1f98
　　hsiz: 0x16
　　pbl: 0x0ad7be64
　　bdba: 0x01400014
　　76543210
　　flag=--------
　　ntab=1
　　nrow=2
　　frre=-1
　　fsbo=0x16
　　fseo=0x1f8c
　　avsp=0x1f70
　　tosp=0x1f70
　　0xe:pti[0]　　　　nrow=2　　　　offs=0
　　0x12:pri[0]　　　　offs=0x1f92
　　0x14:pri[1]　　　　offs=0x1f8c
　　block_row_dump:
　　tab 0, row 0, @0x1f92
　　tl: 6 fb: --H-FL-- lb: 0x1　cc: 1
　　col　0: [ 2]　c1 02
　　tab 0, row 1, @0x1f8c
　　tl: 6 fb: --H-FL-- lb: 0x2　cc: 1
　　col　0: [ 2]　c1 03
　　end_of_block_dump
　　End dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　
　　Start dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　buffer tsn: 5 rdba: 0x01400014 (5/20)
　　scn: 0x0000.000 a5c2e　seq: 0x01 flg: 0x00 tail: 0x5a290601
　　frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
　　Block header dump:　0x01400014
　　Object id on Block? Y
　　seg/obj: 0x189d　csc: 0x00.a5a29　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　 0x0005.01e.00000041　0x00800054.0017.08　----　　1　fsc 0x0000.00000000
　　0x02　 0x0002.01b.00000041　0x008003a4.002c.1f　C---　　0　scn 0x0000.000a58a0
　　
　　data_block_dump,data header at 0xad7be64
　　===============
　　tsiz: 0x1f98
　　hsiz: 0x18
　　pbl: 0x0ad7be64
　　bdba: 0x01400014
　　76543210
　　flag=--------
　　ntab=1
　　nrow=3
　　frre=-1
　　fsbo=0x18
　　fseo=0x1f86
　　avsp=0x1f65
　　tosp=0x1f65
　　0xe:pti[0]　　　　nrow=3　　　　offs=0
　　0x12:pri[0]　　　　offs=0x1f92
　　0x14:pri[1]　　　　offs=0x1f8c
　　0x16:pri[2]　　　　offs=0x1f86
　　block_row_dump:
　　tab 0, row 0, @0x1f92
　　tl: 6 fb: --H-FL-- lb: 0x0　cc: 1
　　col　0: [ 2]　c1 02
　　tab 0, row 1, @0x1f8c
　　tl: 6 fb: --H-FL-- lb: 0x0　cc: 1
　　col　0: [ 2]　c1 03
　　tab 0, row 2, @0x1f86
　　tl: 6 fb: --H-FL-- lb: 0x1　cc: 1
　　col　0: [ 2]　c1 04
　　end_of_block_dump
　　End dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　Start dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　buffer tsn: 5 rdba: 0x01400014 (5/20)
　　scn: 0x0000.000 a6c51 seq: 0x01 flg: 0x02 tail: 0x5a2d0601
　　frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
　　Block header dump:　0x01400014
　　Object id on Block? Y
　　seg/obj: 0x189d　csc: 0x00.a5a29　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　 0x0005.01e.00000041　0x00800054.0017.08　--U-　　1　fsc 0x0000.000a5a2d
　　0x02　 0x0002.01b.00000041　0x008003a4.002c.1f　C---　　0　scn 0x0000.000a58a0
　　
　　data_block_dump,data header at 0xad7be64
　　===============
　　tsiz: 0x1f98
　　hsiz: 0x18
　　pbl: 0x0ad7be64
　　bdba: 0x01400014
　　76543210
　　flag=--------
　　ntab=1
　　nrow=3
　　frre=-1
　　fsbo=0x18
　　fseo=0x1f86
　　avsp=0x1f65
　　tosp=0x1f65
　　0xe:pti[0]　　　　nrow=3　　　　offs=0
　　0x12:pri[0]　　　　offs=0x1f92
　　0x14:pri[1]　　　　offs=0x1f8c
　　0x16:pri[2]　　　　offs=0x1f86
　　block_row_dump:
　　tab 0, row 0, @0x1f92
　　tl: 6 fb: --H-FL-- lb: 0x0　cc: 1
　　col　0: [ 2]　c1 02
　　tab 0, row 1, @0x1f8c
　　tl: 6 fb: --H-FL-- lb: 0x0　cc: 1
　　col　0: [ 2]　c1 03
　　tab 0, row 2, @0x1f86
　　tl: 6 fb: --H-FL-- lb: 0x1　cc: 1
　　col　0: [ 2]　c1 04
　　end_of_block_dump
　　End dump data blocks tsn: 5 file#: 5 minblk 20 maxblk 20
　　
　　结论：
　　
　　热备份对数据块不会有任何影响。数据依然照常写入。数据块的ＳＣＮ号的改变随着insert 和commit的操作而增加。
　　
　　另外，我还做了一个实验。把表空间置于备份状态后，不断的对这个表空间进行写入，可以看到这个表空间的数据文件在不断的增长。这也说明了热备份的时候并没有lock数据文件。也就是说，在备份的时候不但只不同文件是不一致的。同一个文件内部也是不一致的。
　　
　　这就出现一个问题了。如果备份的时候。数据文件内部都是不一样的话。如何进行恢复？其实，在备份的时候，如果block更改了，oracle会把整个block都在online redo中，在恢复的时候，会从begin hot backup scn号开始，如果两边的scn不一致。就会进行覆盖。
　　
　　结束热备份
　　
　　SQL> alter tablespace users end backup;
　　
　　Tablespace altered.
　　
　　ＤＵＭＰ控制文件
　　
　　SQL> alter system set events 'immediate trace name controlf level 10';
　　
　　System altered.
　　
　　ＤＵＭＰ的内容：
　　
　　***************************************************************************
　　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.000abd23 10/12/2005 18:13:55
　　thread:0 rba:(0x0.0.0)
　　enabled　threads:　00000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　
　　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:295 scn: 0x0000.000ab401 10/12/2005 16:16:32　　//这个进行热备份的数据文件。此时它的ＳＣＮ号已更新，并等于当前数据库的ＳＣＮ号
　　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
　　
　　ＤＵＭＰ数据文件头：
　　
　　SQL> alter system set events 'immediate trace name file_hdrs level 10';
　　
　　System altered.
　　
　　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:295 scn: 0x0000.000ab401 10/12/2005 16:16:32　　//已等于当前数据库的ＳＣＮ号
　　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
　　FILE HEADER:
　　Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
　　Db ID=1087530631=0x40d26687, Db Name='ORCL'
　　Activation ID=0=0x0
　　Control Seq=1302=0x516, File size=6400=0x1900
　　File Number=5, Blksiz=8192, File Type=3 DATA
　　Tablespace #5 - USERS　rel_fn:5
　　Creation　 at　 scn: 0x0000.0000169a 05/31/2005 14:05:29
　　Backup taken at scn: 0x0000.000a5a1b 10/11/2005 20:51:28 thread:1　　　//备份开始的ＳＣＮ号
　　reset logs count:0x215d1b07 scn: 0x0000.00000001 recovered at 10/11/2005 13:31:40
　　status:0x4 root dba:0x00000000 chkpt cnt: 295 ctl cnt:294
　　begin-hot-backup file size: 6400
　　Checkpointed at scn:　0x0000.000ab401 10/12/2005 16:16:32
　　thread:1 rba:(0xea.63d.10)
　　enabled　threads:　01000000 00000000 00000000 00000000 00000000 00000000
　　00000000 00000000
　　Backup Checkpointed at scn:　0x0000.000ab401 10/12/2005 16:16:32　　//备份结束的ＳＣＮ号
　　thread:1 rba:(0xea.63d.10)
　　
　　结论：
　　
　　在开始热备份的时候，Oracle只是把处于热备份的那个文件的checkpoint ＳＣＮ号lock了，不会把数据文件中所有的数据块的scn号也给lock了。用户对数据文件的读写依旧，不会影响用户对这个数据文件的操作。
　　
　　数据块ＳＣＮ不管是否处于备份状态，在insert 和commit的时候都会做更改。代表最近的更新。
　　
　　数据文件的scn只有在checkpoint的时候才会更改。但如果这个数据文件处于备份、离线和只读状态，就不会被更新
　　
　　在备份结束的时候，oracle会把数据文件头和control文件中关于这个数据文件的ＳＣＮ号更新为数据库的ＳＣＮ号，
　　
　　另外在热备份过程中，所有的操作信息将会以数据块的形式存放在redo　log中。也就是说，只要对某个块中的一行数据做了更改，整个块都会存储到redo log中。在恢复的时候，一旦发现block scn　不一致的时候，就把redo中的block覆盖备份中的block。这也是为什么在备份期间。重做日志增长得很快的原因。