本篇內(nèi)容介紹了“Oracle RAC DRM中怎么關(guān)閉DRM”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
米林ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！查看DRM默認(rèn)值
重慶分公司
重慶分公司
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
關(guān)閉方法：需要停掉所有實(shí)例，才能啟動(dòng)實(shí)例
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
如果修改完參數(shù)，只想重啟其中一個(gè)實(shí)例，會(huì)報(bào)錯(cuò)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
此時(shí),重啟節(jié)點(diǎn)2后，節(jié)點(diǎn)1也可以啟動(dòng)了
---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.
如果想只關(guān)閉其中一個(gè)節(jié)點(diǎn)的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 相關(guān)的一些概念進(jìn)行介紹。
Buffer: 對于RAC 數(shù)據(jù)庫，當(dāng)一個(gè)數(shù)據(jù)塊被讀入到buffer cache后，我們就稱其為buffer , cache fusion 會(huì)將這個(gè)buffer作為resource來管理。 Master：在RAC 數(shù)據(jù)庫的世界里，每一個(gè)resource都會(huì)有一個(gè)master實(shí)例，這個(gè)master實(shí)例會(huì)在shared pool 中（例如：gcs resource 和ges resource 部分）分配一些空間來存放和這個(gè)資源相關(guān)的信息，例如：哪一個(gè)實(shí)例擁有了這個(gè)buffer的最新版本，哪一個(gè)實(shí)例擁有了這個(gè)buffer的什么級別的lock等等。并且，負(fù)責(zé)維護(hù)和這個(gè)資源的狀態(tài)。 接下來，我們對RAC 環(huán)境中，訪問一個(gè)buffer的過程進(jìn)行簡單的描述。我們以一個(gè)4節(jié)點(diǎn)的RAC 數(shù)據(jù)庫為例。注意，我們只會(huì)列出比較典型的一種情況，不會(huì)把所有可能的情況都一一列出，而且只是把步驟進(jìn)行了簡單的介紹。
步驟1：實(shí)例3需要以X(exclusive)方式訪問buffer1, 向master實(shí)例（1） 發(fā)出了請求。 步驟2：master實(shí)例（1）發(fā)現(xiàn)實(shí)例2 以X方式持有buffer1，之后通知實(shí)例2釋放X lock，并把buffer1發(fā)送給實(shí)例3。 步驟3: 實(shí)例2釋放X lock，并把最新版本的buffer1發(fā)送給實(shí)例3。 步驟4：實(shí)例3獲得buffer1, 并通知master 實(shí)例（1）更新資源buffer1的最新狀態(tài)。
從上面的步驟，我們不難看出，在RAC 數(shù)據(jù)庫中，當(dāng)我們訪問一個(gè)buffer的時(shí)候，最多會(huì)有3個(gè)實(shí)例參與其中，master實(shí)例，holder（持有者）實(shí)例 和requestor(申請者) 實(shí)例。2種數(shù)據(jù)傳輸會(huì)出現(xiàn)，message:用于和lock相關(guān)的信息傳輸，data：用于傳輸buffer。同時(shí)，根據(jù)上面的步驟我們也自然會(huì)想到，如果master和requestor在同一個(gè)實(shí)例上，那么就可以減少實(shí)例之間message的傳輸并且訪問的代碼路徑（code path）會(huì)更短，從而提高性能，但是每個(gè)buffer在被讀取到buffer cache時(shí)，master節(jié)點(diǎn)的選擇是隨機(jī)的。基于這種考慮， oracle從10g開始，推出了一個(gè)新特性DRM（Dynamic Resource management）。
DRM的主要功能是，根據(jù)一段時(shí)間內(nèi)（默認(rèn)10分鐘），每個(gè)實(shí)例，對某一個(gè)數(shù)據(jù)庫對象的 (10gR1以數(shù)據(jù)文件為單位)的訪問次數(shù)和方式，來決定數(shù)據(jù)庫對象對應(yīng)的buffer應(yīng)該被mastering 到哪一個(gè)實(shí)例。在指定時(shí)間內(nèi)，如果某一個(gè)實(shí)例訪問某個(gè)數(shù)據(jù)庫對象次數(shù)高于其他實(shí)例一定倍數(shù)（默認(rèn)50倍），則oracle 會(huì)把這個(gè)對象所有的buffer的master信息，轉(zhuǎn)移到對應(yīng)實(shí)例（注意：不是轉(zhuǎn)移buffer）。當(dāng)然，轉(zhuǎn)移的過程是漸進(jìn)式的。當(dāng)oracle 決定將一個(gè)buffer的master實(shí)例確定到本地實(shí)例后，會(huì)對這個(gè)buffer上加上affinity lock，來實(shí)現(xiàn)快速的訪問。這也是我們經(jīng)常提到的object affinity 的由來。
接下來，我們對DRM的基本步驟進(jìn)行介紹。
1． Oracle停止所有在需要進(jìn)行remastering的buffer上的操作。注意：DRM是漸進(jìn)的，也就是說以windows 為單位，每次對一部分的buffer 進(jìn)行remastering 操作。 2． Lmon 通知所有實(shí)例，準(zhǔn)備進(jìn)行remastering 3． 在舊的master實(shí)例清除對應(yīng)buffer的master信息 4． 將master信息傳遞給新的master實(shí)例 5． 在新的master實(shí)例構(gòu)建資源的最新狀態(tài) 6． 結(jié)束，并釋放所有之前所有步驟占用的資源。
然后，我們對DRM相關(guān)的一些參數(shù)進(jìn)行簡單的介紹。
_gc_policy_time ：單位為分鐘，控制DRM統(tǒng)計(jì)實(shí)例訪問buffer次數(shù)的時(shí)間間隔，默認(rèn)為是10分鐘。
_gc_affinity_ratio：控制進(jìn)行remastering所需要達(dá)到的最小比例（閥值），默認(rèn)為50。也就是說，如果某個(gè)實(shí)例在10分鐘（_gc_policy_time）之內(nèi)，訪問某個(gè)數(shù)據(jù)庫對象的次數(shù)大于其他所有實(shí)例50倍時(shí)(注意：是50倍，而不是50次)，對該數(shù)據(jù)庫對象的buffer進(jìn)行remastering。
注意：請不要修改以上參數(shù)的值，除非您很清楚自己在做什么，或者是根據(jù)oracle 工程師的建議。
最后，如果您遇到了和DRM相關(guān)的問題，建議您查看以下的信息。
1. Lmon，lmd，lms和diag進(jìn)程的 trace file，來確認(rèn)問題出現(xiàn)在DRM的哪一步和lms,lmon,lmd進(jìn)程的狀態(tài)。 2. AWR 和ASH report，確認(rèn)那些等待事件持續(xù)了很長時(shí)間，以及l(fā)mon,lms 和lmd的狀態(tài)。 3. 參照note 1492990.1 獲取 DMR 診斷腳本輸出。
“Oracle RAC DRM中怎么關(guān)閉DRM”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
