前言
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, Date05/31/2005 14:04:55
DB Name "ORCL"
Database flags = 0x00404001
Controlfile Creation Timestamp05/31/2005 14:04:55
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp05/31/2005 14:04:55
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp01/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
enabledthreads: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这个值通常会比databasecheckpoint高一些，我不太清楚这个值记录什么的?
thread:0 rba:(0x0.0.0)
enabledthreads: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)
enabledthreads: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)
enabledthreads: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.
SQLalter 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: 0x189dcsc: 0x00.a57ffitc: 2flg: Etyp: 1 - DATA
brn: 0bdba: 0x1400011 ver: 0x01
inc: 0exflg: 0
Itl XidUba FlagLckScn/Fsc
0x01 0x000a.003.0000003f0x008000a4.0017.0d--U-1fsc 0x0000.000a5818
0x02 0x0002.01b.000000410x008003a4.002c.1f--U-1fsc 0x0000.000a58a0
data_block_dump,
data head
