從ＳＣＮ看熱備份的原理
2024-07-21 02:33:52
供稿：網(wǎng)友
前言
Oracle有四種備份方法：冷備份、熱備份、ＲＭＡＮ備份、邏輯備份。其中冷備份和熱備份都是用操作系統(tǒng)命令對Oracle文件直接進(jìn)行拷貝，不同的是冷備份是把數(shù)據(jù)庫關(guān)閉后再備份，而熱備份則是在數(shù)據(jù)庫打開的時候就直接進(jìn)行拷貝。 由于熱備份是在線的備份，勢必對生產(chǎn)系統(tǒng)有一定的影響，這影響有多大？另外熱備份的同時，數(shù)據(jù)文件的寫操作是不間斷的，oracle如何在保障用戶的正常操作下，對數(shù)據(jù)文件進(jìn)行備份？備份出來的數(shù)據(jù)文件內(nèi)部又是否是一致的？要解決上面的問題，我們需要知道熱備份的工作原理，而本文主要是從ＳＣＮ的角度去分析熱備份的原理。
ＳＣＮ（SYSTEM CHANGE NUMBER）是一個流水號，ＳＣＮ做為oracle的系統(tǒng)改變號，用于記錄Oracle的更改。它存在于控制文件、數(shù)據(jù)文件、數(shù)據(jù)塊中。根據(jù)數(shù)據(jù)庫狀態(tài)的不同，這幾個位置的ＳＣＮ號也不一樣。在正常的運(yùn)行情況下，控制文件和數(shù)據(jù)文件的ＳＣＮ號是一致的，當(dāng)然排除了數(shù)據(jù)文件是只讀或者offline的狀態(tài)，這些ＳＣＮ號只會隨檢查點(diǎn)而更新，而數(shù)據(jù)塊的ＳＣＮ號記錄著oracle的最新的更改，隨用戶的對數(shù)據(jù)的操作而更新。
實(shí)驗(yàn)
我們的實(shí)驗(yàn)是在熱備份的過程中和結(jié)束后，把各種ＳＣＮ號讀出來，從而得出熱備份的過程中，oracle到底對數(shù)據(jù)文件做了哪些改變。下面，我們就來開始我們的實(shí)驗(yàn)
對users表空間進(jìn)行熱備份：
SQL> alter tablespace users begin backup;
Ｄump控制文件的信息
alter system set events 'immediate trace name controlf level 10';
這個方法不適用于windows平臺，因?yàn)閣indows平臺dump出來的trc文件是亂碼，而在UNIX上面就可以看到很具體的信息。另外，這個命令的顯示結(jié)果包含了文件頭的內(nèi)容。它和alter system set events 'immediate trace name file_hdrs level 10'; trace結(jié)果一樣。
Dump文件包含了數(shù)據(jù)文件、重做日志、歸檔日志等信息。下面只是截取一些重要的內(nèi)容，結(jié)果如下：
***************************************************************************
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 //可以看到控制文件中的數(shù)據(jù)庫ＳＣＮ號是ab401。這個值隨checkpoint的觸發(fā)而更改。
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 //數(shù)據(jù)文件的ＳＣＮ號，這個號是開始備份的ＳＣＮ號，很明顯比當(dāng)前的數(shù)據(jù)庫的ＳＣＮ號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
數(shù)據(jù)文件：
Checkpoint cnt:294 scn: 0x0000.000a5a1b 10/11/2005 20:51:28 //這個ＳＣＮ號也一樣給lock了。遠(yuǎn)小于當(dāng)前數(shù)據(jù)庫的ＳＣＮ號
數(shù)據(jù)塊的信息
這里，我們建立一個簡單的表，以觀察在備份的過程中數(shù)據(jù)塊的變化。
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的大，它記錄了當(dāng)前塊的最新ＳＣＮ號，對此塊的任何操作都會導(dǎo)致ＳＣＮ增加。
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
