
平臺論壇博客文庫

› 論壇 › 數(shù)據(jù)庫技術(shù) › Oracle › 晶晶實驗十之再論檢查點篇

晶晶實驗十之再論檢查點篇 [復制鏈接]

晶晶小妹

稍有積蓄

論壇徽章:: 0

電梯直達

1樓 [收藏(0)] [報告]

發(fā)表于 2008-10-03 16:55 |只看該作者 |倒序瀏覽

晶晶實驗十之再論檢查點篇

  在晶晶實驗九中,主要講述了增量檢查點,他屬于檢查點的一種,除了增量檢查點之外,還有完全檢查點和切換日志檢查點.下面分別論述一下.

  1,增量檢查點,
增量檢查點所涉及的主要概念,是一個隊列一個進程.隊列是檢查點隊列,進程是CKPT進程.CKPT進程有兩項任務,一個是在一定的時機觸發(fā)DBWR并告知DBWR的Target RBA,另一個任務是每3秒一次將DBWR的寫進度更新到控制文件中.CKPT的這兩個任務合在一起,叫做--增量檢查點.通常所說的觸發(fā)增量檢查點,是指CKPT進程通知DBWR刷新臟塊這個操作.
在10g中把 log_checkpoint_to_alert設置為真,可以在告警日志中觀察到增量檢查點的觸發(fā).在9I中看不到增量檢查點,可以看到其他檢查點的觸發(fā)信息.

觀察增量檢查點:
步驟1:
SQL> alter system set log_checkpoints_to_alert=true;

系統(tǒng)已更改。

步驟2:將增量檢查點的切換頻率定為300秒.
SQL> alter system set log_checkpoint_timeout=300;[單位是秒]

系統(tǒng)已更改。

步驟3:查看告警日志中的增量檢查點信息.
...
Incremental checkpoint up to RBA [0x2b9.747.0], current log tail at RBA [0x2b9.848.0]
Mon Mar 03 14:51:40 2008
Incremental checkpoint up to RBA [0x2b9.855.0], current log tail at RBA [0x2b9.876.0]
Mon Mar 03 14:56:43 2008
Incremental checkpoint up to RBA [0x2b9.877.0], current log tail at RBA [0x2b9.8f0.0]
Mon Mar 03 15:01:43 2008
Incremental checkpoint up to RBA [0x2b9.8f5.0], current log tail at RBA [0x2b9.d70.0]
Mon Mar 03 15:06:43 2008
Incremental checkpoint up to RBA [0x2b9.d74.0], current log tail at RBA [0x2b9.fd9.0]
Mon Mar 03 15:11:44 2008
...
注:Incremental checkpoint(增量檢查點的意思)/第1個RBA(增量檢查點發(fā)生時當前的檢查點位置)/第2個RBA(檢查點發(fā)生時的當前的on disk rba);

可以看到每5分鐘一次檢查點.

另外可以通過v$kcccp視圖觀察當前的檢查點位置.
SQL> select CPDRT,to_char(CPLRBA_SEQ,'xxxx')||'.'||to_char(CPLRBA_BNO,'xxxxx')||'.'||CPLRBA_BOF "Low 16",CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "Low RBA",CPODR_SEQ||'.'||CPODR_BNO||'.'||CPODR_BOF "On disk RBA",CPODS,CPODT,CPHBT from x$kcccp where cphbt<>0;

   CPDRT Low 16             Low RBA       On disk RBA    CPODS          CPODT                CPHBT
---------- -------------------- --------------- --------------- ---------------- -------------------- ----------
      26 2ba. 9d.0    698.157.0    698.307.0    2363076       03/03/2008 15:23:07 648336376
為了便于觀察:Low 16 是Low RBA 的16進制.

注:在x$kcccp中看到的是DBWR的寫進度.當把 log_checkpoints_to_alert這個參數(shù)設置為true后,可以在告警日志中看到增量檢查點的觸發(fā)信息.

  2,日志切換時的檢查點.
當發(fā)生日志切換時,也會觸發(fā)檢查點.在數(shù)據(jù)庫并不繁忙的情況下，日志切換的檢查點并不急于完成.之所以在日志切換的時候觸發(fā)一次檢查點,是為了保證重做日志文件所對應的臟塊都被寫進磁盤文件.如果寫臟塊的速度比較慢,日志文件循環(huán)一圈后,又該覆蓋此日志文件時,而此日志文件的檢查點還沒有完成,那么覆蓋操作將等待.等待事件名:log file switch(checkpoint incomplete).如果出現(xiàn)該等待事件,解決方法:1,可以增加日志文件組的數(shù)量.2,觀察下增量檢查點的間隔時間.如果是因為增量檢查點間隔時間太長,導致積攢的臟塊過多.可以把增量檢查點參數(shù)設置的頻繁點.

  日志切換檢查點除了會觸發(fā)DBWR寫臟塊外，CKPT進程還要將切換時的SCN寫進數(shù)據(jù)文件頭和控制文件中的數(shù)據(jù)庫信息節(jié),還有數(shù)據(jù)文件節(jié).另外還要將新的連機重做日志文件中第一條重做記錄的RBA寫進數(shù)據(jù)文件頭.

日志切換檢查點寫進數(shù)據(jù)文件頭的SCN,可以通過v$datafile_header視圖查看.
日志切換檢查點寫進控制文件中數(shù)據(jù)庫信息節(jié)的SCN,可以通過v$database查看.
日志切換檢查點寫進控制文件中的數(shù)據(jù)文件節(jié)中的SCN,可以通過v$datafile查看.

先把log_checkpoints_to_alert這個參數(shù)設置為真,以便可以在告警日志中看到日志切換檢查點的相關(guān)信息.
alter system set log_checkpoints_to_alert=true;

實驗:驗證下當觸發(fā)了日志切換檢查點后, 數(shù)據(jù)文件頭,控制文件中的日志切換檢查點信息都是什么:

步驟一:查看當前數(shù)據(jù)文件頭的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;

CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
         2372527 03-3月 -08                646
         2372527 03-3月 -08                609
         2372527 03-3月 -08                646
         ......
已選擇11行。

步驟二:查看當前控制文件中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
         2372527

步驟三:查看當前控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;

CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME    SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- -------------------------------------------
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         ......
已選擇11行。

步驟四:查看當前SCN
SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
               2373997

步驟五:手動觸發(fā)日志切換檢查點

SQL> alter system switch logfile;

系統(tǒng)已更改。

步驟六:查看日志切換后的數(shù)據(jù)文件頭的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;

CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
         2372527 03-3月 -08                646
         2372527 03-3月 -08                609
         2372527 03-3月 -08                646
         ......
已選擇11行。

步驟七:查看日志切換后控制文件中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
         2372527

步驟八:查看日志切換后控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;

CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME    SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- -----------------------------------------------
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2372527 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         ......
已選擇11行。

**由于普通測試機的I/O并不繁忙,看到的數(shù)據(jù)很有可能是沒有發(fā)生變化的,這個時候可以查看告警日志.發(fā)現(xiàn)
Mon Mar 03 19:50:35 2008
Beginning log switch checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
Thread 1 advanced to log sequence 704
  Current log# 9 seq# 704 mem# 0: E:\LOG9A.RDO
此時的日志切換還為完成,數(shù)據(jù)文件頭的日志切換的檢查點和控制文件的日志切換檢查點還沒來的急更新.少等一會就會完成.oracle會根據(jù)機器的繁忙程度來決定什么時候完成日志切換的檢查點.通常如果機器比較繁忙,oracle趨向于更急切的完成日志切換檢查點.

少等一會再次查看告警日志:
Mon Mar 03 19:50:35 2008
Beginning log switch checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
Thread 1 advanced to log sequence 704
  Current log# 9 seq# 704 mem# 0: E:\LOG9A.RDO
Mon Mar 03 19:53:58 2008
Completed checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
可以發(fā)現(xiàn)除了beginning log switch chenkpoint外,多了一個completed checkpoint.日志切換的檢查點到此才真正的完成.由于我的實驗環(huán)境并不繁忙,oracle拖了3分鐘才去真正的完成日志切換檢查點.

此時再查看日志切換后的數(shù)據(jù)文件頭的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;

CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
         2374009 03-3月 -08                647
         2374009 03-3月 -08                610
         2374009 03-3月 -08                647
         ......
再查看日志切換后控制文件中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
         2374009

再查看日志切換后控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;

CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME    SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- ----------------------------------------------
         2374009 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2374009 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
         2374009 03-3月 -08                               E:\ORACLE\PRODUCT\10.2.0\ORADA
            ......

****從結(jié)果可以看出日志切換時的SCN是2373997,而視圖中所顯示的2374009比2373997大了12.這是因為手動查看SCN和手動切換日志這兩個命令間有個時間差.(忽略不計).由此可以證明,在日志切換時,CKPT寫進數(shù)據(jù)文件和控制文件中的SCN,是切換命令開始時的SCN.

  在日志切換時,被寫進數(shù)據(jù)文件頭的并不只有SCN信息,還有RBA信息.這個RBA是新的連機重做日志文件第一條重做記錄的RBA.根據(jù)告警日志中的信息,此處是RBA [0x2c0.2.10].上面所介紹的幾個視圖中,沒有顯示RBA信息.我們可以通過轉(zhuǎn)儲查看到這個RBA.
轉(zhuǎn)儲命令如下:
SQL> alter session set events 'immediate trace name file_hdrs level 10';

會話已更改。

轉(zhuǎn)儲數(shù)據(jù)文件頭的結(jié)果:
DATA FILE #1:
  (name #7) E:\ORACLE\PRODUCT\10.2.0\ORADATA\ONE10G\SYSTEM01.DBF
...
Checkpointed at scn:  0x0000.00243979 03/03/2008 19:50:35 [這些信息對應v$datafile_header]
thread:1 rba0x2c0.2.10)
...
****在轉(zhuǎn)儲文件中的每個數(shù)據(jù)文件相關(guān)信息中,都可以找到如上兩行,這其中檢查點SCN和時間戳,我們都已經(jīng)在視圖中看到了.
RBA信息,告警日志中顯示的有,上述3個視圖中并未顯示出來.

轉(zhuǎn)儲控制文件的結(jié)果:

這是控制文件中數(shù)據(jù)庫信息節(jié)中的日志切換檢查點信息:
***************************************************************************
DATABASE ENTRY
***************************************************************************
...
Database checkpoint: Thread=1 scn: 0x0000.00243979[這些信息對應v$database]
...
這是控制文件中的數(shù)據(jù)文件記錄節(jié),可以看到日志切換檢查點SCN.
DATA FILE #1:
  (name #7) E:\ORACLE\PRODUCT\10.2.0\ORADATA\ONE10G\SYSTEM01.DBF
...
Checkpoint cnt:647 scn: 0x0000.00243979 03/03/2008 19:50:35  [這些信息對應v$datafile]
...
****在控制文件中,只記錄日志切換時的SCN,不記錄RBA.

3,完全檢查點.
完全檢查點,將會寫出所有的臟塊,完全檢查點發(fā)生時,將不能有新的臟塊產(chǎn)生,直到完全檢查點完成,以非shutdown abort關(guān)閉數(shù)據(jù)庫時就會發(fā)生完全檢查點,還有就是手動發(fā)布命令:alter system checkpoint;
完全檢查點也將會在數(shù)據(jù)文件頭,控制文件中數(shù)據(jù)庫信息節(jié),數(shù)據(jù)文件節(jié)中寫入當前SCN.
查看告警日志信息如下:
Mon Mar 03 15:38:11 2008
Beginning global checkpoint up to RBA [0x2ba.285.10], SCN: 2363568
Completed checkpoint up to RBA [0x2ba.285.10], SCN: 2363568

*****小結(jié):日志切換所觸發(fā)的檢查點,1,要通知DBWR寫臟塊.2,要向數(shù)據(jù)文件頭和控制文件中寫入切換時的SCN.3,把新的連機重做日志的第一重做記錄的RBA寫進數(shù)據(jù)文件頭.******

為什么要記錄寫入時的SCN和RBA呢??

如果現(xiàn)在數(shù)據(jù)文件頭和控制文件中的SCN是2374009,假如說現(xiàn)在發(fā)生了介質(zhì)故障,數(shù)據(jù)庫宕機,將兩星期前備份的某一個數(shù)據(jù)文件還原過來覆蓋當前的已損壞的數(shù)據(jù)文件.這個備份的數(shù)據(jù)文件頭SCN是2370000,當啟動數(shù)據(jù)庫時,oracle會發(fā)現(xiàn)數(shù)據(jù)文件頭的SCN和控制文件中的SCN 不匹配,此時會要求完成介質(zhì)恢復.當 recover datafile 時,oracle會根據(jù)數(shù)據(jù)文件頭所記載的RBA,到相應的日志文件中尋找重做信息,進行恢復.