Oracle RAC DRM介紹和關閉DRM

chenoracle發表於2020-06-21

檢視DRM預設值

SQL>
SELECT x.ksppinm  as name,
       y.ksppstvl as value,
       y.ksppstdf as isdefault,
       x.ksppdesc describ
  FROM SYS.x$ksppi x, SYS.x$ksppcv y
 WHERE x.inst_id = USERENV('Instance')
   AND y.inst_id = USERENV('Instance')
   AND x.indx = y.indx
   AND x.ksppinm in ('_gc_policy_time', '_gc_undo_affinity');

         NAME VALUE ISDEFAULT DESCRIB

1 _gc_undo_affinity TRUE TRUE if TRUE, enable dynamic undo affinity

2 _gc_policy_time 10         TRUE how often to make object policy decisions in minutes

關閉方法:需要停掉所有例項,才能啟動例項

SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*';
SQL> alter system set "_gc_undo_affinity"=FALSE scope=spfile sid='*';

[oracle@rac01 ~]$ srvctl stop database -d cjcdb
[oracle@rac01 ~]$ srvctl start database -d cjcdb
[oracle@rac01 ~]$ srvctl status database -d cjcdb -v
Instance cjcdb1 is running on node rac01. Instance status: Open.
Instance cjcdb2 is running on node rac02. Instance status: Open.

檢視修改後的值

SELECT x.ksppinm  as name,
       y.ksppstvl as value,
       y.ksppstdf as isdefault,
       x.ksppdesc describ
  FROM SYS.x$ksppi x, SYS.x$ksppcv y
 WHERE x.inst_id = USERENV('Instance')
   AND y.inst_id = USERENV('Instance')
   AND x.indx = y.indx
   AND x.ksppinm in ('_gc_policy_time', '_gc_undo_affinity');

    NAME VALUE ISDEFAULT DESCRIB

1 _gc_undo_affinity FALSE FALSE if TRUE, enable dynamic undo affinity

2 _gc_policy_time 0 FALSE how often to make object policy decisions in minutes

如果修改完引數,只想重啟其中一個例項,會報錯ORA-01105和ORA-01606

---cjcdb1

SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*';
SQL> alter system set "_gc_undo_affinity"=FALSE scope=spfile sid='*';
SQL> shutdown immediate
SQL> startup
ORACLE instance started.
Total System Global Area 1023004672 bytes
Fixed Size    2259640 bytes
Variable Size  704644424 bytes
Database Buffers  310378496 bytes
Redo Buffers    5722112 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-01606: parameter not identical to that of another mounted instance

此時,重啟節點2後,節點1也可以啟動了

---cjcdb2

SQL> shutdown immediate
SQL> startup

---cjcdb1

SQL> shutdown immediate
SQL> alter database mount;
SQL> alter database open;
[oracle@rac01 ~]$ srvctl status database -d cjcdb -v
Instance cjcdb1 is running on node rac01. Instance status: Open.
Instance cjcdb2 is running on node rac02. Instance status: Open.

如果想只關閉其中一個節點的DRM,顯然是和DRM原理衝突的,此方法也是行不通的。

SQL> alter system set "_gc_policy_time"=10 scope=spfile sid='cjcdb1';
SQL> alter system set "_gc_undo_affinity"=TRUE scope=spfile sid='cjcdb1';
[oracle@rac01 ~]$ srvctl stop instance -d cjcdb -i cjcdb1 -o immediate
[oracle@rac01 ~]$ srvctl start instance -d cjcdb -i cjcdb1 -o open
PRCR-1013 : Failed to start resource ora.cjcdb.db
PRCR-1064 : Failed to start resource ora.cjcdb.db on node rac01
CRS-5017: The resource action "ora.cjcdb.db start" encountered the following error: 
ORA-01105: mount is incompatible with mounts by other instances
ORA-01606: parameter not identical to that of another mounted instance
. For details refer to "(:CLSN00107:)" in "/u01/app/11.2.0/grid/log/rac01/agent/crsd/oraagent_oracle/oraagent_oracle.log".
CRS-2674: Start of 'ora.cjcdb.db' on 'rac01' failed

DRM原理

https://blogs.oracle.com/database4cn/drm

首先,我們對和DRM 相關的一些概念進行介紹。

Buffer: 對於RAC 資料庫,當一個資料塊被讀入到buffer cache後,我們就稱其為buffer , cache fusion 會將這個buffer作為resource來管理。
Master:在RAC 資料庫的世界裡,每一個resource都會有一個master例項,這個master例項會在shared pool 中(例如:gcs resource 和ges resource 部分)分配一些空間來存放和這個資源相關的資訊,例如:哪一個例項擁有了這個buffer的最新版本,哪一個例項擁有了這個buffer的什麼級別的lock等等。並且,負責維護和這個資源的狀態。
接下來,我們對RAC 環境中,訪問一個buffer的過程進行簡單的描述。我們以一個4節點的RAC 資料庫為例。注意,我們只會列出比較典型的一種情況,不會把所有可能的情況都一一列出,而且只是把步驟進行了簡單的介紹。

Oracle RAC DRM介紹和關閉DRM

步驟1:例項3需要以X(exclusive)方式訪問buffer1, 向master例項(1) 發出了請求。
步驟2:master例項(1)發現例項2 以X方式持有buffer1,之後通知例項2釋放X lock,並把buffer1傳送給例項3。
步驟3: 例項2釋放X lock,並把最新版本的buffer1傳送給例項3。
步驟4:例項3獲得buffer1, 並通知master 例項(1)更新資源buffer1的最新狀態。

從上面的步驟,我們不難看出,在RAC 資料庫中,當我們訪問一個buffer的時候,最多會有3個例項參與其中,master例項,holder(持有者)例項 和requestor(申請者) 例項。2種資料傳輸會出現,message:用於和lock相關的資訊傳輸,data:用於傳輸buffer。同時,根據上面的步驟我們也自然會想到,如果master和requestor在同一個例項上,那麼就可以減少例項之間message的傳輸並且訪問的程式碼路徑(code path)會更短,從而提高效能,但是每個buffer在被讀取到buffer cache時,master節點的選擇是隨機的。基於這種考慮, oracle從10g開始,推出了一個新特性DRM(Dynamic Resource management)。

DRM的主要功能是,根據一段時間內(預設10分鐘),每個例項,對某一個資料庫物件的 (10gR1以資料檔案為單位)的訪問次數和方式,來決定資料庫物件對應的buffer應該被mastering 到哪一個例項。在指定時間內,如果某一個例項訪問某個資料庫物件次數高於其他例項一定倍數(預設50倍),則oracle 會把這個物件所有的buffer的master資訊,轉移到對應例項(注意:不是轉移buffer)。當然,轉移的過程是漸進式的。當oracle 決定將一個buffer的master例項確定到本地例項後,會對這個buffer上加上affinity lock,來實現快速的訪問。這也是我們經常提到的object affinity 的由來。

接下來,我們對DRM的基本步驟進行介紹。

1. Oracle停止所有在需要進行remastering的buffer上的操作。注意:DRM是漸進的,也就是說以windows 為單位,每次對一部分的buffer 進行remastering 操作。
2. Lmon 通知所有例項,準備進行remastering
3. 在舊的master例項清除對應buffer的master資訊
4. 將master資訊傳遞給新的master例項
5. 在新的master例項構建資源的最新狀態
6. 結束,並釋放所有之前所有步驟佔用的資源。

然後,我們對DRM相關的一些引數進行簡單的介紹。

_gc_policy_time :單位為分鐘,控制DRM統計例項訪問buffer次數的時間間隔,預設為是10分鐘。

_gc_affinity_ratio:控制進行remastering所需要達到的最小比例(閥值),預設為50。也就是說,如果某個例項在10分鐘(_gc_policy_time)之內,訪問某個資料庫物件的次數大於其他所有例項50倍時(注意:是50倍,而不是50次),對該資料庫物件的buffer進行remastering。

注意: 請不要修改以上引數的值,除非您很清楚自己在做什麼,或者是根據oracle 工程師的建議。

最後,如果您遇到了和DRM相關的問題,建議您檢視以下的資訊。

1. Lmon,lmd,lms和diag程式的 trace file,來確認問題出現在DRM的哪一步和lms,lmon,lmd程式的狀態。
2. AWR 和ASH report,確認那些等待事件持續了很長時間,以及lmon,lms 和lmd的狀態。
3. 參照note 1492990.1 獲取 DMR 診斷指令碼輸出。

希望以上的介紹對理解DRM有些幫助。

歡迎關注我的微信公眾號"IT小Chen",共同學習,共同成長!!!

Oracle RAC DRM介紹和關閉DRM

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

相關文章