バージョンアップはオプティマイザとの戦い?
12cが国内で出荷されてからおよそ1年が経ち、新規システムでの採用や既存システムのバージョンアップを本格的に検討しているという声を多く耳にするようになりました。Oracle Multitenantをはじめとする新機能や、Oracle Open World 2013で発表されたインメモリの機能には、非常に高い期待が寄せられています。
その一方で、バージョンアップの話題になると「オプティマイザの動作に変更はありましたか?」というご質問をいただくことが多々あります。これは期待というよりも、むしろ不安の方が大きいようです。Oracle Database 10gR1でルール・ベース・オプティマイザがサポートされなくなって以来、コスト・ベース・オプティマイザと賢く付き合うことが性能安定の必須条件になりましたが、実行計画が意図しない方向に変わらないか心配だという声が多く、これがバージョンアップを躊躇する理由の1つとなっています。
どうしてもマイナス面の影響を心配してしまうコスト・ベース・オプティマイザですが、本来はデータの偏りや量に基づいて最適な実行計画を選択するために実装された機能なので、バージョンが上がれば当然その精度も上がるはずです。通常はデータベースのバージョンアップとハードウェアの更改を同時に行うことが多いため、SQLのレスポンスが良くなってもオプティマイザが注目されることは少ないのですが、見えないところで確実に進化を続けています。
以下の表は、12cにおけるオプティマイザ関連の新機能と、非推奨の機能をまとめたものです。新機能には、以前「連載:徹底解説!Oracle Database 12cのすべて」の中で解説した適応計画や自動再最適化をはじめ、より最適な実行計画が選択されやすくなる機能が多く実装されています。非推奨となった機能に注意しつつ、これらの新機能を活用していけば、以前のバージョンよりも安定した実行計画でデータベースを運用できるはずです。
機能名 | 概要 |
適応計画 (*1) | 問合せ実行時に収集した統計を基に、プランの一部を実行時の条件に適したサブ・プランに切り替えられる。 |
自動再最適化 | 問合せ実行時に収集した統計が見積りと大きく異なる場合、カーソルに情報を記録。次回の問合せ実行時に記録した統計を使用してプランを作成できる。 |
SQL計画ディレクティブ | 問合せ実行時にカーディナリティが誤って見積もられた場合、SYSAUX表領域に情報を記録。この情報を基に、DBMS_STATSプロシージャで拡張統計が収集できる。 |
動的統計の拡張 | すべてのSQLに対して使用する動的統計レベルを自動的に決定できる。 |
バルク・ロードのオンライン統計収集 | バルク・ロードの操作の中で統計を自動的に収集できる。 |
オプティマイザ統計の自動収集 | 複数の表、パーティション、サブ・パーティションに対して統計情報を並行して収集できる。 |
グローバル一時表のセッション固有統計 | グローバル一時表の統計を共有するか、セッション固有のものにするか選択できる。 |
新しいヒストグラム | 上位頻度ヒストグラム、ハイブリッド・ヒストグラムを作成できる。 |
SPM展開アドバイザ | SQL計画管理(SPM)の検証と承認を日次メンテナンス・ウィンドウで実行できる。 |
(*1)マニュアルによって「適合計画」や「適用計画」と表記されている場合もありますが、本稿では『SQLチューニング・ガイド』に従って「適応計画」とします。
機能名 | 代替手段 |
ストアド・アウトライン | SQL計画管理を使用する。 |
初期化パラメータCURSOR_SHARING=SIMILAR | 同パラメータの値をFORCEに設定する(*2) |
(*2)ただし、ソフト解析時に共有プール内で類似文を検索するというオーバーヘッドが生じるので、使用にあたっては注意が必要です。
今回は、動的統計の拡張と新しいヒストグラムに着目し、12c以前のバージョンとの違いについて説明していきます。