ダイナミックサンプリング12cで私を殺す

11日前に、AdaptiveDynamicStatsが本番RACデータベースのリソースをどのように消費していたかについてブログを書きました。

その火を消した後、私は、テストおよびその他の非本番データベースでQA担当者によって報告されたパフォーマンスの低いクエリを調査しました。私は、OracleDBAが行うのと同じように行いました。問題を再現するストアドプロシージャ呼び出しを収集しました。私のセッションでは、SQLトレースを開始し、ストアドプロシージャを実行しました。 11.2.0.4から12.1.0.2にアップグレードする前に5秒以下かかっていたのに、完了するのに50秒かかりました。このストアドプロシージャには多数のSQLステートメントが含まれており、SQLトレースを開始するのは論理的な場所のように見えました。プロシージャ内のどのSQLステートメントが問題の原因であるかを知る必要がありました。

SQLトレースファイルをTKPROFで実行したところ、その結果に驚いていました。ストアドプロシージャのSQLステートメントは非常に高速に実行されているようです。しかし、私は次のような多くの声明に迎えられました：

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
 optimizer_features_enable(default) no_parallel */ SUM(C1)
FROM
 (SELECT /*+ qb_name("innerQuery") INDEX_FFS( "XXX"
 "INDEX_NAME") */ 1 AS C1 FROM
 "OWNER"."TABLE_NAME" SAMPLE BLOCK(71.048, 8) SEED(1)
 "XXX") innerQuery

これは、動作中の動的サンプリングです。トレースファイルで実行されているすべての動的サンプリングステートメントを確認したところ、これらが実行時間全体の45秒を占めていることがわかりました。 Yikes！

ダイナミックサンプリングは私を助けることになっています。一部のサンプル統計の取得に費やされる時間は、より優れた統計を使用してSQLステートメントを実行することで節約される時間よりもはるかに短いと想定されます。そうでない場合は、私の場合と同様に、SQLステートメントのパフォーマンスが低下する可能性があります。

興味深いと思ったのは、これらの動的サンプリングクエリがテーブルごとに1回、インデックスごとに1回実行されたことです。クエリに含まれるテーブルの1つに7つのインデックスがあるため、その1つのテーブルに対して8つの動的サンプリングクエリがありました。

11日前のブログ投稿で、optimizer_dynamic_samplingパラメーターを0に設定しました。これにより、これらのクエリの実行が停止されます。その変更をまだテスト環境に加えていなかったので、そうする必要がありました。するとすぐに、クエリのパフォーマンスは通常に戻りました。私のデータベースのこのパラメーターのデフォルト値は2です。デフォルト値は、optimizer_features_enable設定の値によって異なる場合があります。このブログ投稿によると、値2は、テーブルの少なくとも1つに統計がない場合に動的サンプリングが開始されることを意味します。しかし、正直なところ、動的サンプリングは私に何の利益ももたらさず、私に害を及ぼすだけです。ですから、今は完全に省略します。