AWR報(bào)告中Execute to Parse %:比例太低,如下所示:
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %:
|
97.33
|
Redo NoWait %:
|
100.00
|
Buffer Hit %:
|
96.59
|
In-memory Sort %:
|
100.00
|
Library Hit %:
|
84.65
|
Soft Parse %:
|
93.10
|
Execute to Parse %:
|
2.60
|
Latch Hit %:
|
99.32
|
Parse CPU to Parse Elapsd %:
|
75.73
|
% Non-Parse CPU:
|
99.03
|
Execute to Parse %
表示SQL語句解析后被重復(fù)執(zhí)行命中率 計(jì)算公式=100*(1-Parses/Executions)
如果該值偏小,說明分析(硬解析與軟解析 )的比例較大,快速解析(即軟軟解析)較少。
關(guān)于session_cached_cursors參數(shù)的調(diào)整:
open_cursors:該參數(shù)含義是同一個(gè)session同時(shí)打開最多在使用的游標(biāo)數(shù)。在Oracle10.2.0.1.0版本中默認(rèn)為300。
session_cached_cursors:SESSION_CACHED_CURSORS,就是說的是一個(gè)session可以緩存多少個(gè)cursor,讓后續(xù)相同的SQL語句不再打開游標(biāo),從而避免軟解析的過程來提高性能。(綁定變量是解決硬解析的問題),軟解析同硬解析一樣,同樣消耗資源.所以這個(gè)參數(shù)非常重要。在Oracle10.2.0.1.0版本中默認(rèn)為20。
現(xiàn)在需要改大這個(gè)參數(shù),以便于進(jìn)行更多的軟軟解析,這樣可以省去open一個(gè)新的session cursor和close一個(gè)現(xiàn)有session cursor所需要消耗的資源和時(shí)間。
通過下面語句查看驗(yàn)證了session_cached_cursors的使用率確實(shí)為100%,(這是我當(dāng)時(shí)查看驗(yàn)證的)
SQL> Select 'session_cached_cursors' Parameter,
Lpad(Value, 5) Value,
Decode(Value, 0, ' n/a', To_Char(100 * Used / Value, '990') || '%') Usage
From (Select Max(s.Value) Used
From V$statname n, V$sesstat s
Where n.Name = 'session cursor cache count'
And s.Statistic# = n.Statistic#),
(Select Value From V$parameter Where Name = 'session_cached_cursors')
Union All
Select 'open_cursors',
Lpad(Value, 5),
To_Char(100 * Used / Value, '990') || '%'
From (Select Max(Sum(s.Value)) Used
From V$statname n, V$sesstat s
Where n.Name In
('opened cursors current', 'session cursor cache count')
And s.Statistic# = n.Statistic#
Group By s.Sid),
(Select Value From V$parameter Where Name = 'open_cursors');
PARAMETER VALUE USAGE
---------------------- ---------- -----
session_cached_cursors 50 100%
open_cursors 300 22%
再次驗(yàn)證session_cached_cursors是否合理:
session_cached_cursors的值也不是越大越好,我們可以通過下面兩條語句進(jìn)一步驗(yàn)證該參數(shù)是否合理:
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%cursor%';
NAME VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative 1075158364
opened cursors current 1578
pinned cursors current 458
session cursor cache hits 140287938
session cursor cache count 20425458
cursor authentications 18472351
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%parse%';
NAME VALUE
---------------------------------------------------------------- ----------
ADG parselock X get attempts 0
ADG parselock X get successes 0
parse time cpu 13211356
parse time elapsed 19331036
parse count (total) 1020611015
parse count (hard) 83024992
parse count (failures) 504137
parse count (describe) 20927
Session cursor cache hits就是系統(tǒng)在高速緩存區(qū)中找到相應(yīng)cursors的次數(shù),parse count(total)就是總的解析次數(shù),二者比值越高,性能越好。如果比例比較低,并且有較多剩余內(nèi)存的話,可以考慮加大該參數(shù)。如下所示二者的比例比較低,
SQL> select 140289159/1020611015*100 from dual;
140289159/1020611015*100
------------------------
13.745605
通過下面的語句來判斷open_cursors的大小是否合理,如下所示,我的是合理的。
SQL>SELECT MAX(A.VALUE) AS HIGHEST_OPEN_CUR, P.VALUE AS MAX_OPEN_CUR FROM V$SESSTAT A, V$STATNAME B, V$PARAMETER P WHERE A.STATISTIC# = B.STATISTIC# AND B.NAME = 'opened cursors current' AND P.NAME = 'open_cursors' GROUP BY P.VALUE;
HIGHEST_OPEN_CUR MAX_OPEN_CUR
--------------------------------------------------------------------------------
34 300
綜上所述可以確定需要加大參數(shù)session_cached_cursors來提高oracle數(shù)據(jù)庫的性能,但是參數(shù)session_cached_cursors并不是越大越好,太大會引起pga緩存碎片,消耗內(nèi)存,然后session cursor cache的管理也是使用LRU。
網(wǎng)頁名稱:關(guān)于ExecutetoParse%:比例太低的優(yōu)化思路
標(biāo)題URL:http://www.rwnh.cn/article30/psghso.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供App設(shè)計(jì)、靜態(tài)網(wǎng)站、域名注冊、全網(wǎng)營銷推廣、搜索引擎優(yōu)化、網(wǎng)站設(shè)計(jì)公司
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源:
創(chuàng)新互聯(lián)