<form id="tznrh"><form id="tznrh"><th id="tznrh"></th></form></form>

            前面的章節我們介紹了Oracle為實現Cache Fusion引入的各種改變和新的概念。本節我們從RAC環境中可能發生的場景對Oracle Cache Fusion的實現進行更近一步的探討。


            從磁盤中讀一個塊


            實例C希望讀取塊,這時需要通過主實例D(塊的master)獲得共享模式鎖。


            1.實例C的FG(Foreground Process)進程通過向實例D的LMS進程發送數據塊(需要共享鎖)請求來獲得塊的訪問權限。


            2.實例D發現塊從未被讀取到集群中的任何實例的緩沖區緩存中,并且也未被鎖定。實例D的LMS進程將PR(x$kjbl的kjblgrant列顯示KJUSERPR。)鎖授予實例C,授予的鎖為sl0(Shared-Local-noPI)。


            3.實例C將塊從共享磁盤讀取到它的緩沖區緩存中(buffer cache),假設這個時候塊的SCN為1000。


            4.實例C在共享模式下有塊,最后鎖管理器更新資源目錄(GRD)。


            注:這時如果用10046跟蹤會話那么你會發現等待事件如下:


            WAIT #19446741324875049632: nam="gc cr grant 2-way" ela= 49 p1=7 p2=6867 p3=1 obj#=3214
               tim=4597940025
            WAIT #19446741324875049632: nam="db file sequential read" ela= 56 file#=7 block#=6867 blocks=1 obj#=3214 tim=4597941129




            從內存中讀一個塊


            繼續第一個場景,實例B希望讀取緩存在實例C緩沖區中的數據塊塊。


            1.實例B的FG進程向主實例D的LMS進程發送數據塊請求


            2.實例D的LMS進程知道該塊在實例C上以共享模式持有,實例D的LMS進程緊接著向實例C的LMS進程轉發這個請求。(gc cr grant 3-way


            3.實例C的LMS進程通過私網將塊發送到實例B的FG,同時實例C通知實例B采用與實例C一樣的鎖定模式和角色,而實例C保留塊的副本(CR Block)。


            4.實例B向實例D發送一條消息,表明它現在持有了該塊的SL鎖。因為這條消息對于鎖管理器來說不是必要信息,所以這條消息可以異步發送。




            獲取緩存塊進行更新


            繼續上面的場景,實例A想要修改已經緩存在實例B和C中的同一塊。


            1.實例A向塊的master實例D發送獨占鎖請求。


            2.實例D知道塊在實例B內存中以scur模式持有和在實例C中以cr模式持有。這時lock master實例D向共享鎖持有者實力B發送ping消息。


            3.實例B通過私網將塊發送給實例A,并且釋放它持有的共享鎖。塊仍在實例B的緩沖區中以CR形式存在,只是所持有的鎖都被釋放了。


            4.實例A現在在該塊上持有獨占鎖,并向實例D發送一條消息,表明它現在持有了該塊的XL0(exclusive-LOCAL-noPI)鎖。


            5.實例A修改緩沖區緩存中的塊,但是未提交更改,因此塊未寫入磁盤,因此SCN保持在1000。




            獲取緩存中已經被修改的塊以進行更新和提交


            繼續上面的場景,實例C現在想要修改相同塊的不同行。


            1.實例C向lock master實例D發送獨占鎖請求。


            2.實例D知道實例A持有請求塊的獨占鎖,因此向實例D向實例A發送ping消息。


            3.實例A通過私網將臟塊發送到實例C,并且實例A將鎖從xcr降級為空。但是它會保留塊的PI版本。在發送塊之前,實例A必須創建一個PI鏡像并刷入塊更改的任何操作條目到redo日志中,實例A上的塊模式現在是NG1(null-GLobal-1PI)


            4.實例C向實例D發送一條消息,表明它持有的塊處于獨占模式。如果需要將塊寫入磁盤,它必須與具有該塊的過去鏡像(PI)的其他實例進行協調。實例C修改塊并發出提交,SCN現在是1001。




            提交修改塊的操作


            繼續上面的場景操作,實例A現在發出commit,以釋放它持有的行級鎖,并將重做日志信息刷入到redo log。


            1.實例A想要提交更改,這時提交操作不需要對塊進行任何同步的操作(只需日志持久化即可)。


            2.塊的鎖定狀態與以前的狀態沒有變化,提交的更改向量將寫入redo log。


            由于增量檢查點的發生,需將臟緩沖區寫入磁盤


            繼續上面的場景,實例B由于增量檢查點的更新需要從緩沖區緩存中將臟塊寫入。


            1.實例B向塊的master實例D發送寫塊請求。


            2.實例D知道實例C上有塊的最新副本,因此實例D會向實例C發送一條消息,請求刷臟塊。


            3.實例C啟動磁盤寫入并將對應的BWR寫入redolog文件中。


            4.LGWR通知實例C日志寫入操作完成。


            5.實例C通知master實例D,臟塊的寫入操作已完成。


            6.在收到通知后,實例D通知所有PI持有者它們所持有的PI塊。


            7.以前修改過此塊的所有實例同樣也需寫BWR。實例C的寫請求已經全部完成,實例B最后向磁盤中寫入其增量檢查點。




            主實例崩潰


            繼續上面的場景


            1.主實例D崩潰


            2.全局資源目錄GRD凍結,主實例D所持有的資源將平均分布在幸存的節點中,也稱為remaster。


            從實例A中查詢一行數據


            從上面的示例繼續,現在實例A查詢該表中的行以獲取最新的數據。


            1.實例A向新的主實例C發送請求共享鎖操作。


            2.根據GRD信息實例C知道塊的最新副本在實例C中,并要求持有實例C將CR塊發送給實例A。


            3.實例C通過私網將CR塊發送給實例A。


            可能上面的實例讀起來有點繞,我們通過下面的表格可以更加容易的閱讀每個場景。






            沃趣科技,讓客戶用上更好的數據庫技術!
            三分快3