1。增量检查点
触发增量检查点条件：按oracle的文档所说，日志切换触发增量检查点，每三秒触发增量检查点。
实验如下：
查看日志，获得日志状态信息：
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 20 52428800 1 YES INACTIVE 1684127 11-SEP-10
2 1 21 52428800 1 NO CURRENT 1684790 11-SEP-10
3 1 19 52428800 1 YES INACTIVE 1684088 11-SEP-10
当前日志文件为group#2
查看控制文件记录的checkpoint SCN:
SQL> select FILE#,CHECKPOINT_CHANGE# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1686179
2 1686179
3 1686179
4 1686179
5 1686179
6 1686179
7 1686179
8 1686179
9 1686179
10 1686179
11 1686179
控制文件记录的各数据文件头部的SCN为1686179
查看各数据文件头部记录的checkpoin SCN:
SQL> select FILE#,CHECKPOINT_CHANGE# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1686179
2 1686179
3 1686179
4 1686179
5 1686179
6 1686179
7 1686179
8 1686179
9 1686179
10 1686179
11 1686179
查看各数据文件自己头部记录的checkpoin SCN为1686179
说明控制文件记录的checkpiont SCN 与数据文件头部记录的checkpoint SCN是一致的。只有它们是一致的状态，数据库才能成功打开.
首先来转储控制文件，来看一下控制文件内部的一些记录：
alter session set events 'immediate trace name CONTROLF level 8';
*********************控制文件转储文件信息*****************************
/oracle/admin/dbaix/udump/dbaix_ora_11536.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: linux-001
Release: 2.6.18-128.el5
Version: #1 SMP Wed Dec 17 11:42:39 EST 2008
Machine: i686
Instance name: dbaix
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 11536, image: (TNS V1-V3)
*** 2010-09-11 19:39:42.821
*** SERVICE NAME:(SYS$USERS) 2010-09-11 19:39:42.821
*** SESSION ID:(544.3) 2010-09-11 19:39:42.821
DUMP OF CONTROL FILES, Seq # 33897 = 0x8469
V10 STYLE FILE HEADER:
Compatibility Vsn = 169869568=0xa200100
Db ID=3711118592=0xdd332d00, Db Name='DBAIX'
Activation ID=0=0x0
Control Seq=33897=0x8469, File size=450=0x1c2
File Number=0, Blksiz=16384, File Type=1 CONTROL
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
09/08/2010 09:46:12
DB Name "DBAIX"
Database flags = 0x00404001 0x00001000
Controlfile Creation Timestamp 09/08/2010 09:46:12
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.001908d2 Resetlogs Timestamp 09/11/2010 13:20:32
Prior resetlogs scn: 0x0000.001905a4 Prior resetlogs Timestamp 09/11/2010 12:40:00
Redo Version: compatible=0xa200100
#Data files = 11, #Online files = 11
Database checkpoint: Thread=1 scn: 0x0000.0019baa3 当前数据库的SCN
reads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Max log members = 3, Max data members = 1
Arch list: Head=2, Tail=2, Force scn: 0x0000.0019b278scn: 0x0000.0019b536
Activation ID: 3712664239
Controlfile Checkpointed at scn: 0x0000.0019bc2e 09/11/2010 19:39:41
thread:0 rba:(0x0.0.0)
***************************************************************************
CHECKPOINT PROGRESS RECORDS 记录检查点
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:284
low cache rba:(0x15.14a7f/84607/.0) on disk rba:(0x15.14c8b/85131/.0)检查点记录
### 85131~84607=524个rba，就是下面的133日志块的存储的物理内存地址.
###low cache rba是数据恢复的起点，之后的数据已经写出到日志磁盘，
###on disk rba是数据恢复的终点.再往前，就是buffer cache了。
###换算成10进制后，恢复数据库需要的日志是在84607~85131之间。
on disk scn: 0x0000.0019bbb2/1686450 09/11/2010 19:39:40 要恢复终点SCN为1686450，
###目前数据文件头部及控制文件头部记录的最新SCN为1686179，而需要恢复的SCN终点是16886450，
###那么1686179~1686450之间的133个日志块就是需要应用日志块。
resetlogs scn: 0x0000.001908d2 09/11/2010 13:20:32
heartbeat: 729430453 mount id: 3712639691
THREAD #2 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #3 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 16,
last-recid= 9, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
(name #1) /oracle/oradata/dbaix/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000014 hws: 0x3 bsz: 512 nab: 0x17d32 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0019b278
Low scn: 0x0000.0019b29f/1684127 09/11/2010 19:05:15
Next scn: 0x0000.0019b536/1684790 09/11/2010 19:10:37
LOG FILE #2:
(name #3) /oracle/oradata/dbaix/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x00000015 hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0019b29f
Low scn: 0x0000.0019b536/1684790 09/11/2010 19:10:37
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
(name #2) /oracle/oradata/dbaix/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000013 hws: 0x3 bsz: 512 nab: 0x3e flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0019b169
Low scn: 0x0000.0019b278/1684088 09/11/2010 19:04:27
Next scn: 0x0000.0019b29f/1684127 09/11/2010 19:05:15
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 428, compat size = 428, section max = 100, section in-use = 11,
last-recid= 36, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
(name #12) /oracle/oradata/dbaix/system01.dbf
creation size=0 block size=8192 status=0xe head=12 tail=12 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:584 scn: 0x0000.0019baa3 09/11/2010 19:34:40 数据文件头部SCN
Stop scn: 0xffff.ffffffff 09/11/2010 19:34:13
Creation Checkpointed at scn: 0x0000.00000009 06/30/2005 19:10:11
thread:0 rba:(0x0.0.0)
aux_file is NOT DEFINED
DATA FILE #2:
(name #11) /oracle/oradata/dbaix/app1_01.dbf
creation size=0 block size=8192 status=0xe head=11 tail=11 dup=1
tablespace 10, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:75 scn: 0x0000.0019baa3 09/11/2010 19:34:40数据文件头部SCN
Stop scn: 0xffff.ffffffff 09/11/2010 19:34:13
Creation Checkpointed at scn: 0x0000.0017bac6 09/08/2010 08:25:47
thread:0 rba:(0x0.0.
从控制文件的转储来看，SCN是一致的，都是0019baa3/1686179
再来看看数据文件头部转储文件：
SQL> alter session set events 'immediate trace name file_hdrs level 10';
Session altered.
SQL> @$ORACLE_HOME/rdbms/admin/gettrcname.sql
TRACE_FILE_NAME
--------------------------------------------------------------------------------
/oracle/admin/dbaix/udump/dbaix_ora_12127.trc
************************数据文件头部转储文件信息***********************************
/oracle/admin/dbaix/udump/dbaix_ora_12127.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: linux-001
Release: 2.6.18-128.el5
Version: #1 SMP Wed Dec 17 11:42:39 EST 2008
Machine: i686
Instance name: dbaix
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 12127, image: (TNS V1-V3)
*** SERVICE NAME:(SYS$USERS) 2010-09-11 19:48:36.167
*** SESSION ID:(533.158) 2010-09-11 19:48:36.167
DUMP OF DATA FILES: 11 files in database
DATA FILE #1:数据文件1#
(name #12) /oracle/oradata/dbaix/system01.dbf
creation size=0 block size=8192 status=0xe head=12 tail=12 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:584 scn: 0x0000.0019baa3 09/11/2010 19:34:40控制文件记录的SCN
Stop scn: 0xffff.ffffffff 09/11/2010 19:34:13
Creation Checkpointed at scn: 0x0000.00000009 06/30/2005 19:10:11
thread:0 rba:(0x0.0.0)
enabled threads: 0
V10 STYLE FILE HEADER:数据文件头部记录的信息
Compatibility Vsn = 169869568=0xa200100
Db ID=3711118592=0xdd332d00, Db Name='DBAIX'
Activation ID=0=0x0
Control Seq=33893=0x8465, File size=61440=0xf000
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000009 06/30/2005 19:10:11
Backup taken at scn: 0x0000.00159b37 09/04/2010 06:19:52 thread:1
reset logs count:0x2b7a52a0 scn: 0x0000.001908d2 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x2b7a4920 scn: 0x0000.001905a4 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 09/11/2010 19:01:50
status:0x2004 root dba:0x00400179 chkpt cnt: 584 ctl cnt:583
begin-hot-backup file size: 61440
Checkpointed at scn: 0x0000.0019baa3 09/11/2010 19:34:40数据文件头部记录的SCN信息
thread:1 rba:(0x15.14a7e/84606.10)
DATA FILE #2:数据文件2#
(name #11) /oracle/oradata/dbaix/app1_01.dbf
creation size=0 block size=8192 status=0xe head=11 tail=11 dup=1
tablespace 10, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:75 scn: 0x0000.0019baa3 09/11/2010 19:34:40控制文件记录SCN信息
Stop scn: 0xffff.ffffffff 09/11/2010 19:34:13
Creation Checkpointed at scn: 0x0000.0017bac6 09/08/2010 08:25:47
thread:0 rba:(0x0.0.0)
V10 STYLE FILE HEADER:
Compatibility Vsn = 169869568=0xa200100
Db ID=3711118592=0xdd332d00, Db Name='DBAIX'
Activation ID=0=0x0
Control Seq=33893=0x8465, File size=1280=0x500
File Number=2, Blksiz=8192, File Type=3 DATA
Tablespace #10 - APP1 rel_fn:2
Creation at scn: 0x0000.0017bac6 09/08/2010 08:25:47
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x2b7a52a0 scn: 0x0000.001908d2 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x2b7a4920 scn: 0x0000.001905a4 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 09/11/2010 19:01:50
status:0x4 root dba:0x00000000 chkpt cnt: 75 ctl cnt:74
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.0019baa3 09/11/2010 19:34:40数据文件头部记录SCN信息
thread:1 rba:(0x15.14a7e/84606/.10)
从数据文件头部的转储来看，SCN也是一致的。即0019baa3.换算成十进制单位是1686179，刚好与上面的数据吻合。
这说明数据库始终是保持一致的状态。
***************************************见下一篇**********************************
