最近12.1.0.2にアップグレードした後、私はいくつかのパフォーマンスの問題に取り組んできました。このような問題の多くはSQLの質の悪さに関連しており、私が解決した多くの問題は、古い11.2.0.4リリースの問題でした。これは、それが常に問題であったことを意味します。しかし、人々はアップグレードの機会を利用して、かなり長い間壊れていたものを修正してくれます。
パフォーマンスの問題を見ていると、システムで問題になっている2つのSQLステートメントに出くわしました。 Lightyに表示される2つのSQLステートメントのスクリーンショットは次のとおりです。
最初のSQLステートメント（SQL ID 4b4wp0a8dvkf0）がCPUを消費し、制御ファイルからの読み取りを待機していることがわかります。 2番目のSQLステートメント（SQL ID frjd8zfy2jfdq）は、多くのCPUを使用しており、他にも多数の待機イベントがあります。これらのステートメントのSQLテキストは次のとおりです。
SQL ID：frjd8zfy2jfdq
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions) AS executions
,SUM (
CASE
WHEN px_servers_executions > 0
THEN px_servers_executions
ELSE executions
END
) AS px_servers
,SUM (end_of_fetch_count) AS end_of_fetch_count
,SUM (elapsed_time) AS elapsed_time
,SUM (cpu_time) AS cpu_time
,SUM (buffer_gets) AS buffer_gets
FROM
gv$sql
WHERE
executions > 0
AND sql_id = : 1
AND parsing_schema_name = : 2
SQL ID：4b4wp0a8dvkf0
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions_delta) AS EXECUTIONS
,SUM (
CASE
WHEN px_servers_execs_delta > 0
THEN px_servers_execs_delta
ELSE executions_delta
END
) AS px_servers
,SUM (end_of_fetch_count_delta) AS end_of_fetch_count
,SUM (elapsed_time_delta) AS ELAPSED_TIME
,SUM (cpu_time_delta) AS CPU_TIME
,SUM (buffer_gets_delta) AS BUFFER_GETS
FROM
DBA_HIST_SQLSTAT s
,V$DATABASE d
,DBA_HIST_SNAPSHOT sn
WHERE
s.dbid = d.dbid
AND bitand (
nvl (
s.flag
,0
)
,1
) = 0
AND sn.end_interval_time > (
SELECT
systimestamp AT TIME ZONE dbtimezone
FROM
dual
) - 7
AND s.sql_id = : 1
AND s.snap_id = sn.snap_id
AND s.instance_number = sn.instance_number
AND s.dbid = sn.dbid
AND parsing_schema_name = : 2
)
)
これらは両方とも、現在12cにある新しいアダプティブクエリ最適化機能の一部です。より具体的には、これらはこの機能の自動動的統計部分に関連しています。 SQL ID frjd8zfy2jfdqは、GV$SQLからSQLステートメントのパフォーマンスに関する情報を取得するOracleです。 SQL ID 4b4wp0a8dvkf0は、アクティブセッション履歴テーブルからSQLステートメントのパフォーマンスに関する同じ情報を取得するOracleです。
Bertand Drouvotは、こちらのブログでこれについて説明しています：https://bdrouvot.wordpress.com/2014/10/17/watch-out-for-optimizer_adaptive_features-as-it-may-have-a-huge-negative-impact/
さらに、Oak Table World2015でのChristianAntogniniによるセッションに参加し、彼がこれらのSQLステートメントについて言及しました。 OTWからの彼のスライドは、これらとほとんど同じです：
http://www.soug.ch/fileadmin/user_upload/SIGs/SIG_150521_Tuning_R/Christian_Antognini_AdaptiveDynamicSampling_trivadis.pdf
上記のリンクと以下で参照するMOSノートは、ここで提示する情報の多くの基礎を提供しました。
すべてのアダプティブクエリ最適化機能は、DBAの生活をより良くすることになっています。これらは、SQLステートメントの実行が開始された後でも、オプティマイザーがより適切な決定を下すのに役立つはずです。この特定のケースでは、これらのクエリは、統計が欠落している場合でも、CBOがより良い統計を取得するのに役立つはずです。これはSQLのパフォーマンスを向上させるのに役立ちますが、私の場合、システム全体のパフォーマンスを妨げています。
アダプティブクエリ最適化の詳細については、ノート2031605.1を参照してください。これにより、他のメモが表示されますが、特にこのディスカッションでは、メモ2002108.1自動動的統計が表示されます。
さらに悪いことに、この動作を確認している本番システムはOracleRACです。 SQL IDfrjd8zfy2jfdqがOracleRACシステムで実行される場合、並列クエリが使用されます。これは、enq：PS –競合および「PX％」待機イベントのスクリーンショットから明らかです。
次のように動的サンプリングをオフにすることができます：
システムセットの変更optimizer_dynamic_sampling=0 scope =both;
このパラメータのデフォルト値は2です。
私にとって、これらのクエリはリソースを消費し、データベース全体のパフォーマンスに影響を与えています。ただし、これらの機能は改善するように設計されています パフォーマンス。ある領域でのパフォーマンスを向上させるためにこの機能をオフにすると、別の領域でのパフォーマンスが低下するリスクが常にあります。しかし、optimizer_dynamic_sampling <> 11を使用しているので、その機能を最大限に活用していないため、すべてのメリットを享受できていません。また、私たちのコードは、動的サンプリングの発生に依存していません。したがって、これをオフにしても安全です。
パラメータを変更すると、次のようにすぐに変更されます。
赤い線は、変更を加えた時刻を示しています。このクエリのASHバージョンが実行されていないことは明らかです。 V $ SQLバージョンはまだ実行中ですが、並列クエリ待機イベントは表示されなくなりました。現在はほとんどCPUを消費しています。私はこの進歩を考慮していますが、完全な解決策ではありません。
ちなみに、次の方法ですべてのアダプティブクエリ最適化機能をオフにすることもできます。
alter system set optimizer_adaptive_features=false scope=both;
しかし、アダプティブジョイン最適化を「楽しんでいる」クエリがあることは知っています。すべてをオフにするのではなく、動的サンプリングだけをオフにします。
では、SQL ID frjd8zfy2jfdqをどうするか？残りの問題を解決できるかどうか見てみましょう。上でリンクしたMOSノートの1つから、この非表示のパラメーターを設定できることがわかります。
alter system set "_optimizer_dsdir_usage_control"=0 scope=both;
この非表示パラメータのデフォルト値は、私の12.1.0.2システムでは126でした。次のようなデフォルト設定が見つかりました：
select a.ksppinm name, b.ksppstvl value, b.ksppstdf deflt,を選択します
from
sys.x$ksppi a,
sys.x$ksppcv b
where a.indx = b.indx
and a.ksppinm like '\_%' escape '\'
and a.ksppinm like '%dsdir%'
order by name;
この値は、ダウンタイムが必要になるSPFILEからパラメーターを取り出さずに元に戻したい場合に重要です。
これで、この非表示のパラメーターを変更してゼロに設定することができます。変更後のLightyでのSQLステートメントの外観は次のとおりです。
これらの2つのSQLステートメントの実行を停止することで「ミッション達成」のように見えます。
Oracle RACで12.1.0.2を実行している場合は、これら2つのSQLステートメントが独自のパフォーマンスの問題を引き起こしていないことを確認する必要があります。
これは、パフォーマンスを向上させるはずの機能が実際には逆の場合の1つと思われます。