从ＳＣＮ看热备份的原理

前言

　　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

　　 本文来自：http://www.linuxpk.com/49677.html