Oracle RAC DRM中怎么關閉DRM

本篇內容介紹了“Oracle RAC DRM中怎么關閉DRM”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

查看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');

         NAMEVALUEISDEFAULTDESCRIB

1_gc_undo_affinityTRUETRUEif TRUE, enable dynamic undo affinity

2_gc_policy_time10        TRUEhow 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');

   NAMEVALUEISDEFAULTDESCRIB

1_gc_undo_affinityFALSEFALSEif TRUE, enable dynamic undo affinity

2_gc_policy_time0FALSEhow 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 數據庫為例。注意，我們只會列出比較典型的一種情況，不會把所有可能的情況都一一列出，而且只是把步驟進行了簡單的介紹。

步驟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 診斷腳本輸出。

“Oracle RAC DRM中怎么關閉DRM”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！