11gR2RACDynamicremastering
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.empSYS> 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';
SQL>select empno, dbms_rowid.rowid_relative_fno(rowid), dbms_rowid.rowid_block_number(rowid) from scott.emp where empno in (7788, 7369);
[oracle@host01 ~]$ srvctl stop database -d racdb srvctl start database -d racdb srvctl status database -d racdb
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);
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 ;
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;
SYS@NODE2>oradebug lkdebug -m pkey 74625
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 ;
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;
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;
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';
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(+) = a.ksppinm AND UPPER(a.ksppinm) LIKE UPPER('%¶meter%') ORDER BY a.ksppinm; Enter value for parameter: gc_policy old 11: AND UPPER(a.ksppinm) LIKE UPPER('%¶meter%') new 11: AND UPPER(a.ksppinm) LIKE UPPER('%gc_policy%')
SYS>alter system set "_gc_policy_minimum" = 10 scope=spfile; alter system set "_gc_policy_time" = 1 scope=spfile;
[oracle@host01 ~]$ srvctl stop database -d racdb srvctl start database -d racdb srvctl status database -d racdb
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(+) = a.ksppinm AND UPPER(a.ksppinm) LIKE UPPER('%¶meter%') ORDER BY a.ksppinm; old 11: AND UPPER(a.ksppinm) LIKE UPPER('%¶meter%') new 11: AND UPPER(a.ksppinm) LIKE UPPER('%gc_policy%') Enter value for parameter: gc_policy
SYS@NODE1>oradebug lkdebug -m pkey 74626 SCOTT@NODE1>select * from scott.test;
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 ;
will be remastered to node3
SCOTT@NODE3>insert into scott.test select * from test;
SYS@NODE1>select inst_id, sopens, xopens from x$object_policy_statistics where object=74626;
SYS@NODE1>/
SYS@NODE1>/
SYS@NODE1>/
– 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>/
16:12:24 SYS@NODE2>/
root@node3#init 6
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 ;
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

熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

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

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

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

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

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

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

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

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

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

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