从9i开始学习的朋友一定习惯了v$sgastat视图中 一系列的sim项,主要包括各种 kglsim,sim cache segment trace等等。如下例:
SQL> select * from v$sgastat where lower(name) like '%sim%' order by name; shared pool kglsim count of pinned he 1920 shared pool kglsim free heap list 96 shared pool kglsim free obj list 96 shared pool kglsim hash table 8208 shared pool kglsim hash table bkts 4194304 shared pool kglsim heap 782208 shared pool kglsim main lru count 76800 shared pool kglsim main lru size 151040 shared pool kglsim object batch 1163520 shared pool kglsim pin list arr 288 shared pool kglsim recovery area 1920 shared pool kglsim sga 30552 shared pool kglsim size of pinned mem 3776 shared pool ksim client list 168 shared pool log_simultaneous_copies 800 shared pool sim cache nbufs 640 shared pool sim cache sizes 640 shared pool sim kghx free lists 8 shared pool sim lru segments 1280 shared pool sim segment hits 1280 shared pool sim segment num bufs 640 shared pool sim state object 40 shared pool sim trace buf 5144 shared pool sim trace buf context 200 shared pool sim_knlasg 1280 shared pool simulator hash buckets 131328 shared pool simulator hash latch 5120 shared pool simulator latch/bucket st 2816 28 rows selected. 有时你也会发现存在sim相关的latch, SQL> select name from v$latch where name like '%sim%'; sim partition latch simulator hash latch simulator lru latch
显然Oracle实例中存在着这许多的模拟器(simulator),他们是 干啥的?
这些模拟器帮助Oracle实例获知当拥有更大的内存容量(涉及buffer_cache,shared_pool_size等)时可以节省多少时间和功。这些信息被汇总到几个常用视图中,如 V$SHARED_POOL_ADVICE, V$MTTR_TARGET_ADVICE, V$DB_CACHE_ADVICE等等。模拟器特性从9i开始被引入,也就是这些视图第一次出现的时候。
MMAN进程也利用这些信息作为SGA动态调整的基本依据(在sga_target或memory_target启用的情况下)。
KGL simulator会跟踪共享池内存分配并扮演模拟器引擎的角色。
KGL是 kernel general Library cache manager,它管理library cache中的对象 包括游标,PL/SQL存储过程,表的定义等等。
KGL simulator 评估当缓存大于目前情况的获益。 其通过将flush out出library cache的object的hash code保存至kgl simulator的 hash 列表中,以造成object似乎仍在缓存中的假象,方便其统计相关的数据。
当有对象被读入library cache中时,Oracle检查kgl simulator中的hash列表,若命中说明历史hash列表中的对象对当前实例仍有用,即更大的内存空间对实例来说是有益的。
EXCESSIVE GETS FOR SHARED POOL SIMULATOR LATCH causing hang/performance problem
Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.1.0.6 – Release: 10.2 to 11.1
Oracle Server – Standard Edition – Version: 10.2.0.1 to 11.1.0.6 [Release: 10.2 to 11.1]
Information in this document applies to any platform.
***Checked for relevance on 04-Aug-2010***
Oracle Real Application Cluster instances
Symptoms
This issue can cause hangs or Performance issues.
Performance Issue Symptoms
AWR/statspack shows high number of shared pool simulator latch gets. For example 577 million “shared pool simulator” latch gets in one hour
Hang Issue Symptoms
Hanganalyze or Systemstate dumps with short stacks shows If kglsim_scan_lru or kghscan_sim_lru in the stack
Changes
None
Cause
This is caused by Unpublished bug 6966286
Solution
Check if the fix for unpublished bug 6966286 is available. Customer can also use workaround of setting _library_cache_advice = false.
Bug 6879763 – Excessive gets for “shared pool simulator” latch
Description
With library cache advice enabled very high gets of the
“shared pool simulator” latch may be seen compared to
the number of gets of the “shared pool” latch.
Workaround:
Set “_library_cache_advice” = false at instance level,
or
use STATISTICS_LEVEL=BASIC (which implicity disables library
cache advice but also disables other metrics also)
Note: This fix introduces the problem described in bug 6966286.If this patch is needed ensure that you also have the fix for bug 6966286 .