首頁 資料庫 mysql教程 11gR2RACDynamicremastering

11gR2RACDynamicremastering

Jun 07, 2016 pm 04:06 PM

In this post, I will demonstrate dynamic remastering of the resources in RAC .In RAC, every data block is mastered by an instance. Mastering a block simply means that master instance keeps track of the state of the block until the next reco

In this post, I will demonstrate dynamic remastering of the resources in RAC . In RAC, every data block is mastered by an instance. Mastering a block simply means that master instance keeps track of the state of the block until the next reconfiguration event .When one instance departs the cluster, the GRD portion of that instance needs to be redistributed to the surviving nodes. Similarly, when a new instance enters the cluster, the GRD portions of the existing instances must be redistributed to create the GRD portion of the new instance. This is called dynamic resource reconfiguration. In addition to dynamic resource reconfiguration, This is called dynamic remastering. The basic idea is to master a buffer cache resource on the instance where it is mostly accessed. In order to determine whether dynamic remastering is necessary, the GCS essentially keeps track of the number of GCS requests on a per-instance and per-object basis. This means that if an instance, compared to another, is heavily accessing blocks from the same object, the GCS can take the decision to dynamically migrate all of that object’s resources to the instance that is accessing the object most. LMON, LMD and LMS processes are responsible for Dynamic remastering. – Remastering can be triggered as result of – Manual remastering – Resource affinity – Instance crash – CURRENT SCENARIO - - 3 node setup - name of the database – racdb — SETUP – – Get data_object_id for scott.emp
SYS>  col owner for a10
            col data_object_id for 9999999 
            col object_name for a15 
            select owner, data_object_id, object_name 
           from dba_objects 
           where owner = 'SCOTT' 
             and object_name = 'EMP';
登入後複製
OWNER DATA_OBJECT_ID OBJECT_NAME ———- ————– ————— SCOTT 73181 EMP – Get File_id and block_id of emp table
SQL>select empno, dbms_rowid.rowid_relative_fno(rowid), 
                  dbms_rowid.rowid_block_number(rowid) 
          from scott.emp 
           where empno in (7788, 7369);
登入後複製
EMPNO DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ———- ———————————— ———————————— 7369 4 151 7788 4 151 – MANUAL REMASTERING – You can manually remaster an object with oradebug command : oradebug lkdebug -m pkey – NODE1 – shutdown the database and restart
[oracle@host01 ~]$ srvctl stop database -d racdb 
                  srvctl start database -d racdb
                  srvctl status database -d racdb
登入後複製
– Issue a select on the object from NODE2
SCOTT@NODE2> select * from  emp;
登入後複製

– Find the GCS resource name to be used in the query x$kjbl.kjblname = resource name in hexadecimal format([id1],[id2],[type] x$kjbl.kjblname2 = resource name in decimal format Hexname will be used to query resource in V$gc_element and v$dlm_rss views get_resource_name
SYS@NODE2>col hexname for a25 
             col resource_name for a15 
             select b.kjblname hexname, b.kjblname2 resource_name, 
                     b.kjblgrant, b.kjblrole, b.kjblrequest  
           from x$le a, x$kjbl b 
             where a.le_kjbl=b.kjbllockp 
              and a.le_addr = (select le_addr 
                                from x$bh 
                               where dbablk = 151 
                                and obj    = 73181 
                               and class  = 1 
                                and state   <> 3);
登入後複製
HEXNAME RESOURCE_NAME KJBLGRANT KJBLROLE KJBLREQUE ————————- ————— ——— ———- ——— [0x97][0x4],[BL] 151,4,BL KJUSERPR 0 KJUSERNL – Check the current master of the block – – Note that current master of scott.emp is node1 (numbering starts from 0) – Previous master = 32767 is a place holder indicating that prior master was not known, meaning first remastering of that object.hat index happened. Now the master is 0 which is instance 1. – REMASTER_CNT = 1 indicating the object has been remastered only once
SYS>select o.object_name, m.CURRENT_MASTER, 
                   m.PREVIOUS_MASTER, m.REMASTER_CNT 
          from   dba_objects o, v$gcspfmaster_info m
           where o.data_object_id=73181
           and m.data_object_id = 73181 ;
登入後複製
OBJECT CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT —— ————– ————— ———— EMP 0 32767 1 – Use following SQL to show master and owner of the block. This SQL joins x$kjbl with x$le to retrieve resource name. – Note that current master is node1(KJBLMASTER=0) and current owner of the block is node2(KJBLOWNER = 1)
SYS@NODE2> select kj.kjblname, kj.kjblname2, kj.kjblowner, 
                       kj.kjblmaster
            from (select kjblname, kjblname2, kjblowner, 
                         kjblmaster, kjbllockp         
                  from x$kjbl
                   where kjblname = '[0x97][0x4],[BL]'
                  ) kj, x$le le
            where le.le_kjbl = kj.kjbllockp
            order by le.le_addr;
登入後複製
KJBLNAME KJBLNAME2 KJBLOWNER KJBLMASTER —————————— —————————— ———- ———- [0x97][0x4],[BL] 151,4,BL 1 0 – Manually master the EMP table to node2 –
SYS@NODE2>oradebug lkdebug -m pkey 74625
登入後複製
– Check that the current master of the block has changed to node2 (numbering starts from 0) – Previous master = 0 (Node1) – REMASTER_CNT = 2 indicating the object has been remastered twice
SYS>select o.object_name, m.CURRENT_MASTER, 
                   m.PREVIOUS_MASTER, m.REMASTER_CNT 
          from   dba_objects o, v$gcspfmaster_info m 
           where o.data_object_id=74625
            and m.data_object_id = 74625 ;
登入後複製
OBJECT CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT —— ————– ————— ———— EMP 1 0 2 – Find master and owner of the block. – Note that current owner of the block is Node2 (KJBLOWNER=1) from where query was issued) – current master of the block has been changed to node2 (KJBLMASTER=1)
SYS> select kj.kjblname, kj.kjblname2, kj.kjblowner, 
             kj.kjblmaster 
           from (select kjblname, kjblname2, kjblowner, 
                         kjblmaster, kjbllockp 
                 from x$kjbl
                  where kjblname = '[0x97][0x4],[BL]'                                ) kj, x$le le 
           where le.le_kjbl = kj.kjbllockp   
           order by le.le_addr;
登入後複製
KJBLNAME KJBLNAME2 KJBLOWNER KJBLMASTER —————————— —————————— ———- ———- [0x97][0x4],[BL] 151,4,BL 1 1 ————————————————————————————— – REMASTERING DUE TO RESOURCE AFFINITY –
GCS masters a buffer cache resource on the instance where it is mostly accessed. In order to determine whether dynamic remastering is necessary, the GCS essentially keeps track of the number of GCS requests on a per-instance and per-object basis. This means that if an instance, compared to another, is heavily accessing blocks from the same object, the GCS can take the decision to dynamically migrate all of that object’s resources to the instance that is accessing the object most. X$object_policy_statistics maintains the statistics about objects and OPENs on those objects.LCK0 process maintains these object affinity statistics. Following parameters affect dynamic remastering due to resource affinity : _gc_policy_limit : If an instance opens 50 more opens on an object then the other instance (controlled by _gc_policy_limit parameter), then that object is a candidate for remastering. That object is queued and LMD0 reads the queue and initiates GRD freeze. LMON performs reconfiguration of buffer cache locks working with LMS processes. All these are visible in LMD0/LMON trace files. _gc_policy_time : It controls how often the queue is checked to see if the remastering must be triggered or not with a default value of 10 minutes. _gc_policy_minimum: This parameter is defined as “minimum amount of dynamic affinity activity per minute” to be a candidate for remastering. Defaults to 2500 and I think, it is lower in a busy environment. To disable DRM completely, set _gc_policy_limit and _gc_policy_minimum to much higher value, say 10Million. Setting the parameter _gc_policy_time to 0 will completely disable DRM, but that also means that you can not manually remaster objects. Further, $object_policy_statistics is not maintained if DRM is disabled. — SETUP –-
SYS>drop table scott.test purge; 
     create table scott.test as select * from sh.sales; 
     insert into scott.test select * from scott.test; 
    commit; 
     insert into scott.test select * from scott.test; 
     commit; 
    insert into scott.test select * from scott.test; 
     commit; 
     insert into scott.test select * from scott.test; 
     commit;
登入後複製
– Get data_object_id for scott.test
SYS> col data_object_id for 9999999 
         col object_name for a15 
         select owner, data_object_id, object_name, object_id  
         from dba_objects 
         where owner = 'SCOTT' 
           and object_name = 'TEST';
登入後複製
OWNER DATA_OBJECT_ID OBJECT_NAME OBJECT_ID —————————— ————– ————— ———- SCOTT 74626 TEST 74626 – Check the initial values of the parameters _gc_policy_minimum and _gc_policy_time – Enter name of the parameter when prompted
SYS> 
 SET linesize 235 
 col Parameter FOR a20 
 col Instance FOR a10 
 col Description FOR a40 word_wrapped 

 SELECT a.ksppinm  "Parameter", 
       c.ksppstvl "Instance", 
        a.ksppdesc "Description" 
 FROM x$ksppi a, x$ksppcv b, x$ksppsv c, v$parameter p 
 WHERE a.indx = b.indx AND a.indx = c.indx 
   AND p.name(&#43;) = a.ksppinm 
   AND UPPER(a.ksppinm) LIKE UPPER('%&parameter%') 
 ORDER BY a.ksppinm; 

 Enter value for parameter: gc_policy 
 old  11:   AND UPPER(a.ksppinm) LIKE UPPER('%&parameter%') 
 new  11:   AND UPPER(a.ksppinm) LIKE UPPER('%gc_policy%')
登入後複製
Parameter Instance Description ——————– ———- —————————————- _gc_policy_minimum 1500 dynamic object policy minimum activity per minute _gc_policy_time 10 how often to make object policy decisions in minutes – Set _gc_policy_minimum and _gc_policy_time to very small values so that we can demonstrate remastering
SYS>alter system set "_gc_policy_minimum" = 10 scope=spfile; 
          alter system set "_gc_policy_time" = 1 scope=spfile;
登入後複製
– NODE1 – shutdown the database and restart
[oracle@host01 ~]$ srvctl stop database -d racdb 
                   srvctl start database -d racdb 
                   srvctl status database -d racdb
登入後複製
– Check that parameter values have been changed to the minimum allowed by oracle although these values are not the ones we specified – Enter name of the parameter when prompted
SYS>
SET linesize 235

col Parameter FOR a20

col Instance FOR a10

col Description FOR a40 word_wrapped

SELECT a.ksppinm  "Parameter", c.ksppstvl "Instance",       a.ksppdesc "Description" 
FROM x$ksppi a, x$ksppcv b, x$ksppsv c, v$parameter p 
WHERE a.indx = b.indx 
AND a.indx = c.indx   
AND p.name(&#43;) = a.ksppinm   
AND UPPER(a.ksppinm) LIKE UPPER('%&parameter%') 
ORDER BY a.ksppinm; 

old  11:   AND UPPER(a.ksppinm) LIKE UPPER('%&parameter%')
new  11:   AND UPPER(a.ksppinm) LIKE UPPER('%gc_policy%')
Enter value for parameter: gc_policy
登入後複製
Parameter Instance Description ——————– ———- —————————————- _gc_policy_minimum 20 dynamic object policy minimum activity per minute _gc_policy_time 4 how often to make object policy decisions in minutes - Assign TEST to node1 manually – Issue a select on scott.test from node1 –
SYS@NODE1>oradebug lkdebug -m pkey 74626 
     SCOTT@NODE1>select * from scott.test;
登入後複製
– check the current master of scott.test – – Note that current master of scott.test is node1 (numbering starts from 0) – Previous master = 2 (node3) – REMASTER_CNT = 3 because while I was doing this demonstartion, remastering was initated 2 times earlier also.
SYS@NODE1>select o.object_name, m.CURRENT_MASTER, 
                         m.PREVIOUS_MASTER, m.REMASTER_CNT 
                  from   dba_objects o, v$gcspfmaster_info m 
                  where o.data_object_id=74626 
                   and m.data_object_id = 74626 ;
登入後複製
OBJECT_NAME CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT ————— ————– ————— ———— TEST 0 2 3 – Issue an insert statement on scott.test from node3 so that scott.test
will be remastered to node3
SCOTT@NODE3>insert into scott.test select * from test;
登入後複製
– check repeatedly that opens are increasing on scott.test with time
SYS@NODE1>select inst_id, sopens, xopens 
           from x$object_policy_statistics 
           where object=74626;
登入後複製
INST_ID SOPENS XOPENS ———- ———- ———- 1 3664 0
SYS@NODE1>/
登入後複製
登入後複製
登入後複製
INST_ID SOPENS XOPENS ———- ———- ———- 1 7585 1305 . . .
SYS@NODE1>/
登入後複製
登入後複製
登入後複製
INST_ID SOPENS XOPENS ———- ———- ———- 1 12788 17000
SYS@NODE1>/
登入後複製
登入後複製
登入後複製
INST_ID SOPENS XOPENS ———- ———- ———- 1 35052 39297 – check repeatedly if remastering has been initiated –
– Note that after some time . current master changes from node1CURRENT_MASTER =0) to node3 (CURRENT_MASTER =2) . Previous master changes from node3 ( PREVIOUS_MASTER=2) to node1( PREVIOUS_MASTER=0) – Remaster count increases from 3 to 4. .
SYS@NODE2>select o.object_name, m.CURRENT_MASTER, 
                         m.PREVIOUS_MASTER, m.REMASTER_CNT 
          from   dba_objects o, v$gcspfmaster_info m
           where o.data_object_id=74626 
             and m.data_object_id = 74626 ;
登入後複製
16:09:16 SYS@NODE2>/
登入後複製
OBJECT_NAME OBJECT_NAME CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT —————– ————– ————— ———— TEST 0 2 3 . . . .
16:12:24 SYS@NODE2>/
登入後複製
OBJECT_NAME CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT ——————————————————————————– TEST 2 0 4 —- REMASTERING DUE TO INSTANCE CRASH – Presently node3 is the master of SCOTT.TEST Let us crash node3 and monitor the remastering process
root@node3#init 6
登入後複製
– check repeatedly if remastering has been initiated – – Note that scott.test has been remastered to node2 (CURRENT_MASTER=1) – PREVIOUS_MASTER =2 and REMASTER_CNT has increased from 4 to 5
SYS@NODE2>select o.object_name, m.CURRENT_MASTER, 
                          m.PREVIOUS_MASTER, m.REMASTER_CNT
                   from   dba_objects o, v$gcspfmaster_info m 
                   where o.data_object_id=74626 
                   and m.data_object_id = 74626 ;
登入後複製
OBJECT_NAME CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT ————— ————– ————— ———— TEST 1 2 5 — CLEANUP —
SYS@NODE1>drop table scott.test purge; 
 SYa@NODE1S>
     alter system reset "_gc_policy_minimum" = 10 scope=spfile; 
     alter system reset "_gc_policy_time" = 1 scope=spfile; 

 [oracle@host01 ~]$ srvctl stop database -d racdb 
                    srvctl start database -d racdb 
                    srvctl status database -d racdb
登入後複製
References:
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

<🎜>:泡泡膠模擬器無窮大 - 如何獲取和使用皇家鑰匙
4 週前 By 尊渡假赌尊渡假赌尊渡假赌
北端:融合系統,解釋
4 週前 By 尊渡假赌尊渡假赌尊渡假赌
Mandragora:巫婆樹的耳語 - 如何解鎖抓鉤
3 週前 By 尊渡假赌尊渡假赌尊渡假赌

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

熱門話題

Java教學
1671
14
CakePHP 教程
1428
52
Laravel 教程
1331
25
PHP教程
1276
29
C# 教程
1256
24
MySQL的角色:Web應用程序中的數據庫 MySQL的角色:Web應用程序中的數據庫 Apr 17, 2025 am 12:23 AM

MySQL在Web應用中的主要作用是存儲和管理數據。 1.MySQL高效處理用戶信息、產品目錄和交易記錄等數據。 2.通過SQL查詢,開發者能從數據庫提取信息生成動態內容。 3.MySQL基於客戶端-服務器模型工作,確保查詢速度可接受。

說明InnoDB重做日誌和撤消日誌的作用。 說明InnoDB重做日誌和撤消日誌的作用。 Apr 15, 2025 am 12:16 AM

InnoDB使用redologs和undologs確保數據一致性和可靠性。 1.redologs記錄數據頁修改,確保崩潰恢復和事務持久性。 2.undologs記錄數據原始值,支持事務回滾和MVCC。

MySQL與其他編程語言:一種比較 MySQL與其他編程語言:一種比較 Apr 19, 2025 am 12:22 AM

MySQL与其他编程语言相比,主要用于存储和管理数据,而其他语言如Python、Java、C 则用于逻辑处理和应用开发。MySQL以其高性能、可扩展性和跨平台支持著称,适合数据管理需求,而其他语言在各自领域如数据分析、企业应用和系统编程中各有优势。

MySQL索引基數如何影響查詢性能? MySQL索引基數如何影響查詢性能? Apr 14, 2025 am 12:18 AM

MySQL索引基数对查询性能有显著影响:1.高基数索引能更有效地缩小数据范围,提高查询效率;2.低基数索引可能导致全表扫描,降低查询性能;3.在联合索引中,应将高基数列放在前面以优化查询。

初學者的MySQL:開始數據庫管理 初學者的MySQL:開始數據庫管理 Apr 18, 2025 am 12:10 AM

MySQL的基本操作包括創建數據庫、表格,及使用SQL進行數據的CRUD操作。 1.創建數據庫:CREATEDATABASEmy_first_db;2.創建表格:CREATETABLEbooks(idINTAUTO_INCREMENTPRIMARYKEY,titleVARCHAR(100)NOTNULL,authorVARCHAR(100)NOTNULL,published_yearINT);3.插入數據:INSERTINTObooks(title,author,published_year)VA

MySQL與其他數據庫:比較選項 MySQL與其他數據庫:比較選項 Apr 15, 2025 am 12:08 AM

MySQL適合Web應用和內容管理系統,因其開源、高性能和易用性而受歡迎。 1)與PostgreSQL相比,MySQL在簡單查詢和高並發讀操作上表現更好。 2)相較Oracle,MySQL因開源和低成本更受中小企業青睞。 3)對比MicrosoftSQLServer,MySQL更適合跨平台應用。 4)與MongoDB不同,MySQL更適用於結構化數據和事務處理。

解釋InnoDB緩衝池及其對性能的重要性。 解釋InnoDB緩衝池及其對性能的重要性。 Apr 19, 2025 am 12:24 AM

InnoDBBufferPool通過緩存數據和索引頁來減少磁盤I/O,提升數據庫性能。其工作原理包括:1.數據讀取:從BufferPool中讀取數據;2.數據寫入:修改數據後寫入BufferPool並定期刷新到磁盤;3.緩存管理:使用LRU算法管理緩存頁;4.預讀機制:提前加載相鄰數據頁。通過調整BufferPool大小和使用多個實例,可以優化數據庫性能。

MySQL:結構化數據和關係數據庫 MySQL:結構化數據和關係數據庫 Apr 18, 2025 am 12:22 AM

MySQL通過表結構和SQL查詢高效管理結構化數據,並通過外鍵實現表間關係。 1.創建表時定義數據格式和類型。 2.使用外鍵建立表間關係。 3.通過索引和查詢優化提高性能。 4.定期備份和監控數據庫確保數據安全和性能優化。

See all articles