https://blogs.oracle.com/PerformanceDiagnosis/entry/more_parses_in_12c
12.1では多くのパースをするのでしょうか。
11.2.0.3から12.1へアップグレードすると、解析回数の総数が急増しているために不安に思われるお客様がいらっしゃるかもしれません。
でもご心配にはおよびません。12.1の問題ではなく、11.2.0.3の問題です。
以下のサンプルを見てみましょう。
クエリから結果を得て、各バージョンの結果を並べてみました。
select
a.
name
, b.value
from
v$statname a, v$mystat b
where
a.statistic# = b.statistic#
and
( a.
name
like
'%parse count%'
or
a.
name
like
'session cursor cache%'
)
and
value>0;
begin
for
n
in
1..100 loop
begin
execute
immediate
'alter session set optimizer_goal=choose'
;
exception
when
others
then
null
;
end
;
end
loop;
end
;
/
select
a.
name
, b.value
from
v$statname a, v$mystat b
where
a.statistic# = b.statistic#
and
( a.
name
like
'%parse count%'
or
a.
name
like
'session cursor cache%'
)
and
value>0;
11.2の解析回数(合計)が解析回数(ハード)以下であることにご注目下さい。解析回数(合計)には、ハード、ソフト、失敗の解析回数が含まれるべきなので、この値には意味がありません。
NAME
11.1 VALUE 11.2 VALUE 12.1 VALUE
----------------------------- ---------- ---------- ----------
session
cursor
cache hits 2 3 1
session
cursor
cache
count
3 10 10
parse
count
(total) 12 11 12
parse
count
(hard) 1
PL/SQL
procedure
successfully completed.
NAME
11.1 VALUE 11.2 VALUE 12.1 VALUE
----------------------------- ---------- ---------- ----------
session
cursor
cache hits 3 3 1
session
cursor
cache
count
4 11 11
parse
count
(total) 114 13 114
parse
count
(hard) 100 101 100
parse
count
(failures) 100
これは極端な例のように思えるかもしれませんが、この奇妙な振る舞いを再現する別のソフト解析シナリオがあります。
11.1から11.2.0.3へ移行するお客様にとっては、解析回数の総数が少なくなっているために改善していると思われるかもしれません。その後、11.2.0.3から12.1へ移行すると、急上昇に気付いて、おそらく心配されることでしょう。
そのため、ご心配なさらずに。12.1はたくさん解析をしているわけでもありませんし、11.2.0.3が少ない解析をしているわけでもありません。単に統計情報の計装上のバグです。具体的には以下のリンクをご覧下さい。
Bug 13837105 statistics "parse count (total)" and "session cursor cache hits" miscounted [ID 13837105.8]
https://support.oracle.com/epmos/faces/DocContentDisplay?id=13837105.8
0 件のコメント:
コメントを投稿