Cursor Cache Hit Ratio超過100%
這種Ratio超過100的是正常的嗎?
目前我們的監控對這種超過的處理有點問題
11g到19c各個版本都有這個情況。
這是正常現象, Cursor Cache Hit Ratio 指標的來源是: session cursor cache hits / (parse count (total) - parse count (hard)) 。其中 session cursor cache hits 是指在 在 session cursor cache 中找到 cursor 的次數,這個可能會比較大。例如我們迴圈查詢某條 sql ,每一次從 session cursor cache 找到一次便是增加一次,而解析次數是不用再增加的。因此得到的 session cursor cache hits / (parse count (total) - parse count (hard)) 值是可能超過 100% 的。
SQL> select m.*, n.NAME 2 from v$mystat m, v$statname n 3 where m.STATISTIC# = n.STATISTIC# 4 and (n.name in ('session cursor cache hits','session cursor cache count','parse count (total)')) ;
SID STATISTIC# VALUE CON_ID NAME ---------- ---------- ---------- ---------- ------------------------------ 1 643 0 0 session cursor cache hits 1 644 1 0 session cursor cache count 1 694 3 0 parse count (total)
declare c number ; begin for i in 1 .. 10000 loop execute immediate 'select count(*) from dba_objects' into c ; end loop ; end ; /
PL/SQL procedure successfully completed.
select m.*, n.NAME from v$mystat m, v$statname n where m.STATISTIC# = n.STATISTIC# and (n.name in ('session cursor cache hits','session cursor cache count','parse count (total)')) ;
SID STATISTIC# VALUE CON_ID NAME ---------- ---------- ---------- ---------- ------------------------------ 1 643 10000 0 session cursor cache hits 1 644 3 0 session cursor cache count 1 694 7 0 parse coun |
當前這個資料庫中的總體命中率也是達到 314.79% 的。(這個指標是指例項啟動以來的總體指標統計,與 sysmetric 不同的是, sysmetric 是每一個間隔時間內的統計)
select a.value cache_hits, b.value total_parses, c.value hard_parses, (b.value - c.value) soft_parses, round((a.value / (b.value - c.value))*100,2)||'%' ratio from v$sysstat a, v$sysstat b, v$sysstat c where a.name = 'session cursor cache hits' and b.name = 'parse count (total)' and c.name = 'parse count (hard)';
CACHE_HITS TOTAL_PARSES HARD_PARSES SOFT_PARSES RATIO ---------- ------------ ----------- ----------- ----------------------------------------- 4333516791 1444991516 68350276 1376641240 314.79%
|
參考: (Bug ID 6200422)
文件中開發已說明這是正常行為。
** NLEE 07/09/08 04:00 pm ***
@ I see the same behavior in 11.2.0 (label 'RDBMS_MAIN_LINUX_080708')
@ and am currently investigating.
*** NLEE 07/15/08 07:21 pm *** (CHG: Sta->32)
*** NLEE 07/15/08 07:21 pm ***
@
I spoke with base development and they confirmed that this
@ is the expected behavior.
This is because the cache hit count
@ now includes kqd cursors but the parse count does not include
@ them. The documentation will need to be updated. Please
@ open a 'doc' bug for this.
@ .
@ Since this is the expected behavior, I am now closing this
@ bug with status 32.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29863023/viewspace-2783934/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Buffer Cache Hit Ratio
- [Oracle Script] Buffer Cache Hit RatioOracle
- why Buffer Cache Hit Ratio < 0
- Keeping the Library Cache Reload Ratio at 0 and the Hit Ratio Above 95 Percent
- Keeping the Data Dictionary Cache Hit Ratio at or above 95 Percent
- Hit Ratio For ORACLEOracle
- [Oracle Script] Library Cche Hit RatioOracle
- SESSION_CURSOR_CACHE open_cursorsSession
- 'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'型別的等待事件Mutex型別事件
- MySQL:Table_open_cache_hits/Table_open_cache_misses/Table_open_cache_overflowsMySql
- Hitwise:超過3/4的搜尋都算是成功的
- mysql例項cpu超過100%分析MySql
- db_cache hitratio sql and v$db_cache_advice and create table with storageSQL
- 索尼PS Vita日本銷量超過100萬臺
- library cache lock和cursor: pin S wait on X等待AI
- ERROR:maximum cursor open,ORA-01000Error
- 超過100萬谷歌帳戶被Gooligan黑了谷歌Go
- sql version count引發cursor:pin s wait x及library cache latch library cache lockSQLAI
- 儲存過程中使用cursor儲存過程
- blog的訪問量超過3000,日誌數超過100,謹此記錄
- Google Play渠道超過100M?嘗試APK分包!GoAPK
- Oracle Exadata在全球部署超過1000臺Oracle
- latch: row cache objects 和cursor: pin S wait on X共同出現ObjectAI
- 關於計算buffer cache hit rate的精確演算法演算法
- 2013年App Store總銷量超過100億美元APP
- Appsfire:蘋果認證應用已超過100萬APP蘋果
- oracle 10049 event之library cache lockOracle
- 通過Cache::Memcached::Fast方式AST
- Polyfill JS 攻擊影響超過 100,000 個網站JS網站
- 遞迴儲存過程中使用cursor遞迴儲存過程
- Architecture 1001: x86-64 Assembly 彙編
- zt_如何使用event 10049分析定位library cache lock and library cache pin
- guava cache過期方案實踐Guava
- 彭博社:全球有14位超級富豪的資產總額超過了1000億美元
- 微信資料包告:日運動量不超過100步,2100萬人宅出新境界
- 設定事件10049跟蹤遊標上的library cache lock/pin獲取過程事件
- 等待事件Cursor: Pin S Wait On X和Library Cache Load Locks可能意味著過度的記憶體調整事件AI記憶體
- EskyFun資料洩露,超過100萬Android玩家受到影響Android