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

1、晶晶實驗十之再論檢查點篇上一篇/下一篇 2008-03-03 21:10:39 /個人分類：晶晶oracle實驗系列查看(2707 ) /評論(45 ) 晶晶實驗十之再論檢查點篇在晶晶實驗九中，主要講述了增量檢查點，他屬于檢查點的一種，除了增量檢查點之外，還有 完全檢查點和切換日志檢查點下面分別論述一下1,增量檢查點，增量檢查點所涉及的主要概念，是一個隊列一個進程隊列是檢查點隊列，進程是CKPT進 程.CKPT進程有兩項任務，一個是在一定的時機觸發(fā)DBWR并告知DBWR的Target RBA,另一個任務是每3秒一次將DBWR的寫進度更新到控制文件中.CKPT的這兩個任務合在一 起，叫做-增量檢

2、查點通常所說的觸發(fā)增量檢查點，是指CKPT進程通知DBWR刷新臟塊這個操作.在10g中把log_checkpoint_to_alert 設置為真，可以在告警日志中觀察到增量檢查點的 觸發(fā)在9I中看不到增量檢查點，可以看到其他檢查點的觸發(fā)信息觀察增量檢查點：步驟1:SQL> alter system set log_checkpo in ts_to_alert=true;系統(tǒng)已更改。步驟2:將增量檢查點的切換頻率定為300秒SQL> alter system set log_checkpoint_timeout=300;單位是秒系統(tǒng)已更改。步驟3:查看告警日志中的增量檢查點信息In

3、creme ntal checkpoi nt up to RBA 0x2b9.747.0，curre nt log tail at RBA 0x2b9.848.0Mon Mar 03 14:51:40 2008In creme ntal checkpoi nt up to RBA 0x2b9.855.0，curre nt log tail at RBA 0x2b9.876.0Mon Mar 03 14:56:43 2008In creme ntal checkpoi nt up to RBA 0x2b9.877.0，curre nt log tail at RBA 0x2b9.8f0.0Mon

4、 Mar 03 15:01:43 2008In creme ntal checkpoi nt up to RBA 0x2b9.8f5.0, curre nt log tail at RBA 0x2b9.d70.0Mon Mar 03 15:06:43 2008In creme ntal checkpoi nt up to RBA 0x2b9.d74.0, curre nt log tail at RBA 0x2b9.fd9.0Mon Mar 03 15:11:44 2008注:In creme ntal checkpoi nt( 增量檢查點的意思 ”第1個RBA(增量檢查點發(fā)生時當前的檢 查點

5、位置)/第2個RBA(檢查點發(fā)生時的當前的on disk rba);可以看到每5分鐘一次檢查點.另外可以通過v$kcccp視圖觀察當前的檢查點位置.SQL> selectCPDRT,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.&#

6、39;|CPODR_BOF "On disk RBA",CPODS,CPODT,CPHBT from x$kcccp where cphbt<>0;CPDRT Low 16Low RBAOn disk RBACPODSCPODTCPHBT26 2ba.9d.0698.157.0698.307.0236307603/03/2008 15:23:07648336376為了便于觀察：Low 16是Low RBA 的16進制.注:在x$kcccp中看到的是 DBWR的寫進度.當把log_checkpoints_to_alert這個參數(shù)設置為true后，可以在告警日志中看

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

8、查點參數(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ù)設置為真，以便可以在告警日志中看到日志切換檢查點的

9、相關信息.alter system set log_checkpo in ts_to_alert=true;實驗:驗證下當觸發(fā)了日志切換檢查點后，數(shù)據(jù)文件頭，控制文件中的日志切換檢查點信息都是什么：步驟一：查看當前數(shù)據(jù)文件頭的SCNSQL> select checkpo in t_cha nge#,checkpo in t_time,checkpo in t_co unt from v$datafile_header;CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT2372527 03-3月-086462372527 03-3月-086

10、092372527 03-3月-08646已選擇11行。步驟二：查看當前控制文件中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息SQL> select checkpo in t_cha nge# from v$database;CHECKPOINT_CHANGE#2372527步驟三：查看當前控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息SQL> selectcheckpo in t_cha nge#,checkpo in t_time,last_cha nge#,last_time,substr( name,1,30) from v$datafile;CHECKPOINT_CHANGE# CH

11、ECKPOINT_TIM LAST_CHANGE# LAST_TIME SUBSTR(NAME,1,30)2372527 03-3 月-08E:ORACLEPRODUCT1020ORADA2372527 03-3 月-08E:0RACLEPR0DUCT10200RADA2372527 03-3 月-08E:0RACLEPR0DUCT10200RADA已選擇11行。步驟四：查看當前SCNSQL> select dbms_flashback.get_system_cha nge_nu mber from dual;GET_SYSTEM_CHANGE_NUMBER2373997步驟五：手動觸發(fā)

12、日志切換檢查點SQL> alter system switch logfile;系統(tǒng)已更改。步驟六：查看日志切換后的數(shù)據(jù)文件頭的SCNSQL> select checkpo in t_cha nge#,checkpo in t_time,checkpo in t_co unt from v$datafile_header;CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT2372527 03-3 月-086462372527 03-3 月-086092372527 03-3 月-08646已選擇11行。步驟七：查看日志切換后控制文件

13、中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息SQL> select checkpo in t_cha nge# from v$database;CHECKPOINT_CHANGE#2372527步驟八：查看日志切換后控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息SQL> selectcheckpo in t_cha nge#,checkpo in t_time,last_cha nge#,last_time,substr( name,1,30) from v$datafile;CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME S

14、UBSTR(NAME,1,30)2372527 03-3 月-08E:0RACLEPR0DUCT10200RADA2372527 03-3 月-08E:0RACLEPR0DUCT10200RADA2372527 03-3 月-08E:0RACLEPR0DUCT10200RADA已選擇11行。*由于普通測試機的I/O并不繁忙，看到的數(shù)據(jù)很有可能是沒有發(fā)生變化的，這個時候可以查看告警日志發(fā)現(xiàn)Mon Mar 03 19:50:35 2008Begi nning log switch checkpoi nt up to RBA 0x2c0.2.10, SCN: 2374009Thread 1 adva

15、 need to log seque nee 704Curre nt log# 9 seq# 704 mem# 0: E:LOG9A.RDO此時的日志切換還為完成，數(shù)據(jù)文件頭的日志切換的檢查點和控制文件的日志切換檢查點還 沒來的急更新少等一會就會完成.oracle會根據(jù)機器的繁忙程度來決定什么時候完成日志切 換的檢查點通常如果機器比較繁忙，oracle趨向于更急切的完成日志切換檢查點.少等一會再次查看告警日志：Mon Mar 03 19:50:35 2008Begi nning log switch checkpoi nt up to RBA 0x2c0.2.10, SCN: 2374009T

16、hread 1 adva need to log seque nee 704Curre nt log# 9 seq# 704 mem# 0: E:LOG9A.RDOMon Mar 03 19:53:58 2008Completed checkpoi nt up to RBA 0x2c0.2.10, SCN: 2374009可以發(fā)現(xiàn)除了 beginning log switch chenkpoint夕卜,多了一個 completed checkpoint. 日志切換的檢查點到此才真正的完成.由于我的實驗環(huán)境并不繁忙,oracle拖了 3分鐘才去真正的完 成日志切換檢查點.此時再查看日志切換后的數(shù)

17、據(jù)文件頭的SCNSQL> select checkpo in t_cha nge#,checkpo in t_time,checkpo in t_co unt from v$datafile_header;CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT2374009 03-3月-086472374009 03-3月-086102374009 03-3月-08647再查看日志切換后控制文件中的數(shù)據(jù)庫信息節(jié)的日志切換檢查點信息SQL> select checkpo in t_cha nge# from v$database;CHEC

18、KPOINT_CHANGE#2374009再查看日志切換后控制文件中的數(shù)據(jù)文件節(jié)中的日志切換檢查點信息SQL> selectcheckpo in t_cha nge#,checkpo in t_time,last_cha nge#,last_time,substr( name,1,30) from v$datafile;CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIMESUBSTR(NAME,1,30)2374009 03-3 月-08E:ORACLEPRODUCT1020ORADA2374009 03-3 月-08E:0RA

19、CLEPR0DUCT10200RADA2374009 03-3 月-08E:0RACLEPR0DUCT10200RADA*從結(jié)果可以看出日志切換時的SCN是2373997,而視圖中所顯示的2374009比2373997大了 12.這是因為手動查看 SCN和手動切換日志這兩個命令間有個時間差.(忽略不計).由此可以證明，在日志切換時,CKPT寫進數(shù)據(jù)文件和控制文件中的SCN,是切換命令開始時的SCN.在日志切換時，被寫進數(shù)據(jù)文件頭的并不只有SCN信息，還有RBA信息這個RBA是新的連機重做日志文件第一條重做記錄的RBA.根據(jù)告警日志中的信息，此處是RBA0x2c0.2.10.上面所介紹的幾個視圖

20、中，沒有顯示RBA信息我們可以通過轉(zhuǎn)儲查看到這個 RBA.轉(zhuǎn)儲命令如下：SQL> alter sessi on set events 'immediate trace n ame file_hdrs level 10'會話已更改。轉(zhuǎn)儲數(shù)據(jù)文件頭的結(jié)果：DATA FILE #1:(n ame #7) E:0RACLEPR0DUCT10200RADATA0NE10GSYSTEM01.DBFCheckpo inted at scn:0x0000.00243979 03/03/2008 19:50:35這些信息對應v$datafile_headerthread:1 rba 0x2

21、c0.2.10)*在轉(zhuǎn)儲文件中的每個數(shù)據(jù)文件相關信息中，都可以找到如上兩行，這其中檢查點SCN和時間戳,我們都已經(jīng)在視圖中看到了RBA信息，告警日志中顯示的有，上述3個視圖中并未顯示出來轉(zhuǎn)儲控制文件的結(jié)果：這是控制文件中數(shù)據(jù)庫信息節(jié)中的日志切換檢查點信息：*DATABASE ENTRY*Database checkpo int: Thread=1 sen: 0x0000.00243979這些信息對應 v$database這是控制文件中的數(shù)據(jù)文件記錄節(jié)，可以看到日志切換檢查點SCN.DATA FILE #1:(n ame #7) E:ORACLEPRODUCT1020ORADATAONE10GSYSTEM01.DBFCheckpoi nt cnt:647 sen: 0x0000.00243979 03/03/