Oracle RAC Past Image(PI) 說明

一.  PI 說明

轉自

       Oracle RAC Concept of Past Image (PI)

       http://www.remote-dba.net/t_rac_concept_past_image_pi.htm

 

       The past image concept was introduced in the RAC version of Oracle 9i to maintain data integrity. In an Oracle database, a typical data block is not written to the disk immediately, even after it is dirtied. When the same dirty data block is requested by another instance for write or read purposes, an image of the block is created at the owning instance, and only that block is shipped to the requesting instance. This backup image of the block is called the past image (PI) and is kept in memory. In the event of failure, Oracle can reconstruct the current version of the block by reading PIs. It is also possible to have more than one past image in the memory depending on how many times the data block was requested in the dirty stage.

 

       A past image copy of the data block is different from a CR block, which is needed for reconstructing a read-consistent image.A CR version of a block represents a consistent snapshot of the data at a point in time. It is constructed by applying information from the undo/rollback segments. The PI image copy helps the recovery process and aids in maintaining data integrity.

       

 

       For example, suppose user A of Instance 1 has updated row 2 on block 5. Later, user B of Instance 2 intends to update row 6 on the same block 5. The GCS transfers block 5 from Instance A to Instance B. At this point, the past image (PI) for block 5 is created on Instance A.

 

Lock Modes

 

       From the examination of resource roles, resource modes, and past images, the next step is to consider the possible resource access modes as shown in Table 2.2.

       There are three characters that distinguish lock or block access modes. The first letter represents the lock mode, the second character represents the lock role, and the third character (a number) indicates any past images for the lock in the local instance.

-- 介紹LOCK_MODE 各個欄位的含義。

  

LOCK MODE	DESCRIPTION
NL0	Null Local and No past images
SL0	Shared Local with no past image
XL0	Exclusive Local with no past image
NG0	Null Global – Instance owns current block image
SG0	Global Shared Lock – Instance owns current image
XG0	Global Exclusive Lock – Instance own current image
NG1	Global Null – Instance owns the past image block
SG1	Shared Global – Instance owns past image
XG1	Global Exclusive Lock – Instance owns past image.

 

       When a block is brought into the local cache of an instance, it is acquired with the local role. But if a dirty buffer for the same data block is present in a remote instance, a past image is created in the remote instance before the data block is sent to the requesting instance’s cache. Therefore, the data block resource acquires a global role.

       For recovery purposes, instances that have past images will keep those past images in their buffer cache until the master instance prompts the lock to release them. When the buffers are discarded, the instance holding the past image will write a block written redo (BWR) to the redo stream. The BWR indicates that the block has already been written to disk and is not needed for recovery by the instance. Buffers are discarded when the disk write is initiated on the master instance. The master instance is where the current status and position of the data block is maintained.

       This has been a review of how a GCS resource maintains its access mode and its role. There is another feature called the buffer state, which is covered in the next section.

 

 

二.  PI 示例

 

轉自：http://blogs.oracle.com/toddbao/entry/past_imagepi

 

      Past Image是一種RAC環境中髒緩衝塊的狀態，是叢集中不同例項對同一個資料緩衝塊寫而又寫後的間接結果。簡而言之，Past Image是一種特殊的髒資料塊，它保留了前一次更改後的樣子。 對於同一個block，每一個例項最多隻能有一個Past Image。PI 也稱殘像。 例項間爭奪、修改熱塊很容易觀察到Past Image。

       當前環境是這樣的：HR.EMPLOYEES中的100號員工和101號員工都在5號檔案的88號資料塊中。

       每個資料塊可以包含多條row記錄。 可以將block dump出來，檢視trace 內容。如：alter system dump datafile 4 block 32;

 

在我的blog裡有一個示例：

       Oracle rdba和 dba 說明

       http://blog.csdn.net/tianlesoftware/archive/2011/06/07/6529346.aspx

 

 

將設稱此資料塊為球，讓兩個例項爭奪這個球。

# 觀測1： 球不在任何節點上。
SYS@RAC1//scripts> select inst_id,status from gv$bh where file#=5 and block#=88;
no rows selected

＃ 節點1要球。
SYS@RAC1//scripts> update hr.employees set salary=1 where employee_id=100;
1 row updated.

# 觀測2： 球在節點1上。xcur表示寫呼叫的當前資料緩衝，即排他當前資料塊。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + xcur
1 row selected.

# 節點2要球。
SYS@RAC2//scripts> update hr.employees set salary=2 where employee_id=101;
1 row updated.

# 觀測3： 球在節點2上，殘像在節點1上。pi表示Past Image，也就是殘像。它保留了資料塊前一次更改後的樣子。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + pi
2 + Y + xcur
2 rows selected.

＃ 節點1要球。
SYS@RAC1//scripts> update hr.employees set salary=3 where employee_id=100;
1 row updated.

# 觀測4： 球在節點1上，殘像在節點2和節點1上都存在。節點2上的殘像比節點1上的殘像更新。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + pi
1 + Y + xcur
2 + Y + pi
3 rows selected.

# 節點2又要球。
SYS@RAC2//scripts> update hr.employees set salary=4 where employee_id=101;
1 row updated.

# 觀測5： 球在節點2上，很不巧這時候發生了增量檢查點，DBWR醒了，想到要工作了，殘像（pi）變成了陳舊的一致性讀快取塊（cr）。它們完全可以被覆蓋。坑爹的我辛苦產生的殘像都沒了。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + N + cr
1 + N + cr
2 + Y + xcur
3 rows selected.

＃ 重來。節點1要球。
SYS@RAC1//scripts> update hr.employees set salary=5 where employee_id=100;
1 row updated.

# 觀測6： 球在節點1上，殘像在節點2上。陳舊的一致性讀快取塊不用理會，它們隨時可以消失。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + xcur
1 + N + cr
1 + N + cr
2 + Y + pi
4 rows selected.

# 節點2要球。
SYS@RAC2//scripts> update hr.employees set salary=6 where employee_id=101;
1 row updated.

# 觀測7： 球在節點2上，殘像在節點1和2上。節點1上的殘像比節點2上的殘像更新。回顧一下觀測4，很相似。兩節點上的殘像都出現了。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + pi
2 + Y + pi
2 + Y + xcur
3 rows selected.

# 節點1要球。
SYS@RAC1//scripts> update hr.employees set salary=7 where employee_id=100;
1 row updated.

# 觀測8： 球在節點1上，殘像在節點2和1上。節點2上的殘像比節點1上的殘像更新。原來在節點2上的殘像變成了陳舊的一致性讀快取塊。沒有破壞每一個例項最多隻能有一個殘像（針對同一個資料塊）的規則。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88;
INST_ID + D + STATUS
---------- + - + -------
1 + Y + pi
1 + Y + xcur
2 + Y + pi
2 + N + cr
4 rows selected.

       不考慮任何檢查點的話， 當xcur塊移動到另一個節點時：原來節點上的xcur塊轉變成pi塊、原來的pi塊（如果有的話）轉變為cr塊，結果是cr塊越來越多，pi則最多和節點數一樣多。

接下來讓兩個節點進行一次彈珠球大戰：同時在兩個節點上執行匿名塊A和B。

A：
SYS@RAC1//scripts> run
1 begin
2 for i in 1..100000 loop
3 update hr.employees set salary=i where employee_id=100;
4 end loop;
5* end;

B：
SYS@RAC2//scripts> run
1 begin
2 for i in 1..100000 loop
3 update hr.employees set salary=i where employee_id=101;
4 end loop;
5* end;

       等到它們執行完畢後，看一下5號檔案88號資料塊在buffer cache中佔了幾個位置:
SYS@RAC2//scripts> select count(*) from gv$bh where file#=5 and block#=88;
COUNT(*)
----------
412
1 row selected.

其中409個是一致性讀塊緩衝（cr）：
SYS@RAC2//scripts> select count(*) from gv$bh where file#=5 and block#=88 where status='cr';
COUNT(*)
----------
409
1 row selected.

1個排他當前塊緩衝（xcur）：
SYS@RAC2//scripts> select count(*) from gv$bh where file#=5 and block#=88 where status='xcur';
COUNT(*)
----------
1
1 row selected.

還有...2個我們的主角－－殘像緩衝（pi）。分別在兩個節點上。
SYS@RAC1//scripts> select inst_id,dirty,status from gv$bh where file#=5 and block#=88 and status='pi';
INST_ID + D + STATUS
---------- + - + -------
1 + Y + pi
2 + Y + pi
2 rows selected.

       某些時候，當你在RAC環境中發現大量的一致性讀緩衝（cr）時，可能你看到的是例項間爭奪熱塊的搏鬥痕跡。這是一個xcur到pi再到cr的過程。

PI至少有兩個作用:

一，需要時節點可以從本地的pi塊製造cr塊，避免從其他節點請求cr塊。
二，當擁有xcur塊的例項崩潰後，pi塊重新轉變為xcur塊，提高了例項恢復的速度。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15880878/viewspace-722999/，如需轉載，請註明出處，否則將追究法律責任。