SPA実行準備編──本番環境で流れるSQLを丸ごと取り出して「STS」を作成する：【12c対応】とにかく苦労しない「RAT」簡単攻略テクニック（3）（2/3 ページ）

[長内麻記，株式会社アシスト]

STEP 2：データセットの準備

　続いて、SPA実行環境へのデータセットの準備を行います。ハードウェアリプレースとOracle Databaseのバージョンアップを想定した今回の例では、本番移行と切り替え作業前のテストのために新環境へデータを移行する工程となります。

　なおSPAは、オプティマイザ統計とスキーマ構造情報のみをインポートするだけでもテストはできます。例えば、テスト環境へ本番データを持ち込めないシーンや、クラウド環境などでSPAを実行したいシーンに有効です。ただしデータセットがなければ、得られるテスト結果は少なくなります。これについては別の回でも解説予定ですが、SPA実行環境のSQL性能として、バッファー読み取り量や経過時間などの値が必要な場合は、必ずデータセットが必要になります（表1）。

表1　SPAで確認できる内容

　SPAのテストを開始してSQLを実行するとしても、データ自体がなければ経過時間などの値が得られないことにも注意してください。その一方で、その他のコストや実行計画はパースの段階で得られます。これらはデータセットがないとしても、オプティマイザ統計やオブジェクトの定義情報があれば確認できます。

オプティマイザ統計のリストアでSPAを使うときの注意事項

　データセットなしでSPAを実行したい場合には、もう1つ注意してほしいことあります。それは「リストアするオプティマイザ統計は、リストア先と同じバージョンでの取得が必要」ということです。

　オプティマイザ統計を取得した環境（本番環境）のバージョンと、リストア先（SPA実行環境）のバージョンが同じならば問題はありません（図6の1）。しかしそれぞれのバージョンが異なる場合には、オプティマイザが適切な統計を使用できず、本来選択される実行計画が適切に再現されません（図6の2）。このパターンでSPAを実行する場合には、非互換SQLのチェックしか行えません。

　この回避策としては、「統計取得用の環境をSPA実行環境と同バージョンで準備し、データ移行の後でオプティマイザ統計を取得し、それをSPA実行環境へリストアする手段」があります。こうすることで、実行計画の変更も含めてSPAでチェックが可能になります（図6の3）。

図6　統計情報をリストアする場合の3つのパターン