総まとめ！ SPAのユースケース――データベース移行で重視するのはコスト、時間、それとも精度：【12c対応】とにかく苦労しない「RAT」簡単攻略テクニック（6）（1/3 ページ）

とにかく大変なデータベースバージョンアップ時の「SQLテスト」。本連載では、この課題を解決するOracle Databaseのオプション機能である「Oracle Real Application Testing（RAT）」と、その一機能である「SQL Performance Analyzer（SPA）」の攻略方法を紹介してきました。最終回では、SPAのニーズが多いシーンごとに3つの「ユースケース」を取り上げます。

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

　前回は、SPA実行時に重要な「テストモード」や「比較メトリック」の違いについて解説しました。今回は3つのユースケースに落とし込んで説明します。連載最終回として、SPAをコマンド操作する方法についても簡単に紹介します。

データベースバージョンアップ時の工程

　ハードウェアのリプレースに伴ってデータベースをバージョンアップする場合、図1のような工程をたどるのが一般的でしょう。

図1　ハードウェアをリプレースしつつデータベースをバージョンアップする場合の全工程

　図1中の設計・計画工程では、新環境のハードウェアやデータベースのバージョン検討などを経て、本番切り替えまでの工数検討とスケジュール作成を進めます。

　新環境の構築工程では、調達したハードウェアにOSやミドルウェア、データベースを導入し、現在稼働中の環境からデータをリストアします（データのテスト移行）。

　次にSPAが活躍します。テスト・チューニング工程では、実際にアプリケーションを稼働させたり、SPAによるテストなどを進めたりします。その結果、問題が見つかったSQLをこの時点でチューニングします。その後、データの本番移行を経て最終チェックを実施、アプリケーションを切り替え、晴れてカットオーバーとなります。

　このような工程にどのような課題があるのか、SPAのユースケースを示しながら、順番に紹介しましょう。

設計・計画工程でSPAを使い、アプリケーション改修範囲を特定

　設計・計画工程では、「テスト・チューニング期間をどの程度設けるか」を決めなければなりません。そのためには、「何本のSQLをテストしなければならないか」「そのうちチューニング対象のSQLは何本になるのか」を見積もる必要があります。

　これらの数字を机上の計算で特定するのは至難の業。とはいえ実機を用意してテストすると、工数やコストが難しくなります（図2）。

図2　設計・計画工程での課題

　これまでの経験を頼りにスケジュールを決めると、テスト・チューニング工程で思いもよらぬエラーが発見されたり、想定以上にチューニング対象のSQLが多かったりしてプロジェクトが遅延する、となりがちです。

　このような場合は、SPAをクラウドで活用する手法（ユースケース1）をお勧めします（図3）。

図3　クラウドを利用して低コスト・迅速さを重視したテスト（ユースケース1）

　テスト環境としてクラウドを採用することで、ハードウェアの調達、構築時間を削減し、「すぐに、ちょっとだけ利用」を実現します。

　この方法では、データを持ち込めないことが多いでしょう。しかしSPAならスキーマ定義とオプティマイザ統計だけをリストアして、テストすることが可能です（テストモードとしてExplain Planを選択）。

　性能を確認できなくても、非互換のSQLと実行計画が変わるSQLを短時間で網羅的に確認できます。結果に基づいた確度の高いスケジュールを立てることができるでしょう。