1.dictionary cache作用2.如何查看dictionary cache里面的运行时数据内容方式一、转储dictionary cache我们可以使用如下命令对dictionary cache进行转储。 ALTER SESSION SET EVENTS 'immediate trace name row_cache level N'; 这里的N可以取的值分别为： 1 转储dictionary cache的统计信息 ; 2 转储hash表的汇总信息 ; 8 转储dictionary cache中的对象的结构信息; 如果对level 1进行转储，可以看到转储出来的内容，很明显，就是v$rowcache里的内容。每一种数据字典都有一行记录来表示。比如有tablespace相关的数据字典等。 如果以level 2转储的话，可以看到类似如下的内容。这里有23个hash表对dictionary cache中的对象进行管理，每个hash表都对应了一种数据字典，同时有一个名为row cache objects的latch来控制并发访问。可以看到，v$latch_children里名为“row cache objects”的记录数量也是23。 ROW CACHE HASH TABLE: cid=0 ht=66BD90B0 size=32 ………… ROW CACHE HASH TABLE: cid=1 ht=66BD78B0 size=256 ………… ROW CACHE HASH TABLE: cid=22 ht=66DA5590 size=512 3.统计信息V$ROWCACHE常用列 l PARAMETER：缓存名 l COUNT：缓存项总数 l USAGE：包含有效数据的缓存项数 l GETS：请求总数 l GETMISSES：请求失败数 l SCANS：扫描请求数 l SCANMISSES：扫描请求失败次数 l MODIFICATIONS：添加、修改、删除操作数 l DLM_REQUESTS：DLM请求数 l DLM_CONFLICTS：DLM冲突数 l DLM_RELEASES：DLM释放数
使用V$ROWCACHE数据 1>.确认数据字典缓存是否拥有适当的大小。如果shared pool过小，那数据字典缓存就不足以拥有合适的大小以缓存请求信息。 2>.确认应用是否有效访问缓存。如果应用设计未能有效使用数据字典缓存(比如，大数据字典缓存并不有助于解决性能问题)。例如，DC_USERS缓存在过去某段时期内出现大量GETS，看起来像是数据库中创建了大量的不同用户，并且应用记录下用户频繁登陆和注销。通过检查logon比率以及系统用户数可以验证上述数据。同时解析比率也会很高，如果这是一个大型的OLTP系统的中间层，它可能在中间层更有效的管理个别帐户，允许中间层以单用户登陆成为应用所有者。通过保持活动连接来减少logon/logoff比率也同样有效。 3>.确认是否发生动态空间分配。DC_SEGMENTS, DC_USED_EXTENTS,以及DC_FREE_EXTENTS大量的类似大小修改将指出存在大量动态空间分配。可行的解决方案包括指定下一个区大小或者使用本地管理表空间。如果发生空间分配的是临时的表空间，则可以为其指定真正的临时表空间(If the space allocation is occurring on the temp tablespace, then use a true temporary tablespace for the temp. )。 4>.dc_sequences值的变化指出是否大量sequence号正在产生。 5>.搜集硬解析的证据。硬解析常表现为大量向DC_COLUMNS, DC_VIEWS以及DC_OBJECTS caches的gets。 示例： 1.分组统计数据字典统计项 SELECTparameter,sum("COUNT"),sum(usage),sum(gets),sum(getmisses),sum(scans),sum(scanmisses),sum(modifications),sum(dlm_requests),sum(dlm_conflicts),sum(dlm_releases) FROMV$ROWCACHEGROUPBYparameter; 2.检查数据字典的命中率 select1-sum(getmisses) /sum(gets) "data dictionary hitratio" fromv$rowcache; |
|
|
