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 件のコメント:
コメントを投稿