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