oracle進程-資料下載頁
2025-02-18 03:20本頁面
【正文】 為離線狀態(tài)或者為熱備份狀態(tài)等 ， oracle還專門引入了文件隊列 （ file queue） 。 文件隊列的原理與檢查點隊列是一樣的 ， 只不過每個數據文件會有一個文件隊列 ， 該數據文件所對應的臟數據塊會被串在同一個文件隊列上； 同時為了能夠盡量減少實例崩潰后恢復的時間 ， oracle還引入了增量檢查點（ incremental checkpoint） ， 從而增加了檢查點啟動的次數 。 如果每次檢查點啟動的間隔時間過長的話 ， 再加上內存很大 ， 可能會使得恢復的時間過長 。 因為前一次檢查點啟動以后 ， 標識出了這個起點 。 然后在第二次檢查點啟動的過程中 ， DBWR可能已經將很多臟數據塊已經寫入了數據文件 ， 而假如在第二次檢查點啟動之前發(fā)生實例崩潰 ， 導致在日志文件中 ， 所標識的起點仍然是上一次檢查點啟動時所標識的 ， 導致 oracle不知道這個起點以后的很多重做條目所對應的臟數據塊實際上已經寫入了數據文件 ， 從而使得 oracle在實例恢復時再次重復的處理一遍 ， 效率低下 ， 浪費時間 。 DBWR和 CKPT協(xié)作 上面所描述的概念 ， 用一句話來概括 ， 其實就是 DBWR負責寫檢查點隊列上的臟數據塊 ， 而 CKPT負責記錄當前檢查點隊列的第一個數據塊所對應的的重做條目在日志文件中的地址 。 到底應該寫哪些臟數據塊 ， 寫多少臟數據塊 ， 是要到檢查點隊列上才能確定的 。 DBWR和 CKPT協(xié)作 我們用一個簡單的例子來描述這個過程。假設系統(tǒng)中發(fā)生了一系列的事務，導致日志文件如下所示： 事務號 數據文件號 block號 行號 列 值 RBA T1 8 25 10 1 10 101 T1 7 623 12 2 a 102 T3 8 80 56 3 b 103 T3 9 98 124 7 e 104 T5 7 623 13 3 abc105 Commit SCN timestamp 106 T123 8 876 322 10 89 107 這時，對應的檢查點隊列則類似如圖所示。我們可以看到， T1事務最先發(fā)生，所以位于檢查點隊列的首端，而事務 T123最后發(fā)生，所以位于靠近尾端的地方。同時，可以看到事務 T1和 T5都更新了 7號數據文件的 623號數據塊。而在檢查點隊列上只會記錄該數據塊的第一次被更新時的 RBA，也就是事務 T1對應的 RBA102，而事務 T5對應的 RBA105并不會被記錄。因為根本就不需要在檢查點隊列上記錄。當 DBWR寫數據塊的時候，在寫RBA102時，自然就把 RBA105所修改的內容寫入數據文件了。 日志文件中所記錄的提交標記也不會體現在檢查點隊列上，因為提交本身只是一個標記而已，不會涉及到修改數據塊。 DBWR和 CKPT協(xié)作 這時，假設發(fā)生三秒鐘超時，于是增量檢查點啟動。增量檢查點會將檢查點隊列的第一個臟數據塊所對應的 RBA記錄到控制文件中去。在這里，也就是RBA101會作為 checkpointposition記錄到控制文件中。 然后， DBWR后臺進程被某種條件觸發(fā)而啟動。 DBWR根據一系列參數及規(guī)則，計算出應該寫的臟數據塊的數量，從而將 RBA101到 RBA107之間的這 5個臟數據塊寫入數據文件，并在寫完以后將這 5個臟數據塊從檢查點隊列上摘除，而留下了 4個臟數據塊在檢查點隊列上。如果在寫這 5個臟數據塊的過程中發(fā)生實例崩潰，則下次實例啟動時， oracle會從 RBA101開始應用日志文件中的重做條目。 這時，又發(fā)生三秒鐘超時，于是增量檢查點啟動。這時它發(fā)現checkpointposition為 RBA109，于是將 RBA109寫入控制文件。如果接著發(fā)生實例崩潰，則 oracle在下次啟動時，就會從 RBA109開始應用日志。 謝謝！ 演講完畢，謝謝觀看！
電大資料相關推薦
鄂ICP備17016276號-1