データベースのバージョンアップはなぜ「大変」なのか──「SQLテスト」の3大課題とは：【12c対応】とにかく苦労しない「RAT」簡単攻略テクニック（1）（2/2 ページ）

データベースのバージョンアップに立ちふさがる「SQLテスト」の課題。この工数がかかる工程を自動化し、手間やコストの大きな軽減も期待できる方法があります。本連載では、Oracle Databaseのオプション機能である「Oracle Real Application Testing（RAT）」と、その一機能である「SQL Performance Analyzer」の攻略方法を紹介していきます。

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

SQLテストを自動化する「RAT」

　RATは、現行の本番環境でSQLやワークロードをキャプチャーし、それらを新バージョンの環境で再現することで、「新バージョンでの実行計画や性能情報」を収集します。続いて、現行環境と新バージョン環境とでそれらの情報を照らし合わせて、「一括レポートとして出力する」までが自動で行われます。

　本番環境で実際に流れるSQLをデータベース層でキャプチャーし、テスト環境で実行するので、正確性も高くなります。またアプリケーションの準備が不要となるので、テストの準備時間や手間もかなり省けます。

Oracle RATの概要

RATの2大機能は「SQL Performance Analyzer」と「Database Replay」

　RATは、「SQL Performance Analyzer」（以下、SPA）と「Database Replay」と呼ばれる2つの機能を組み合わせて利用します（図2）。

図2　SPAとDatabase Replayの違い

　SPAは「SQLの性能テスト（単体テスト）」を行う機能です。本番環境で実行されるSQLの情報を記録し、テスト環境で1本ずつ実行します。システム変更（バージョンアップやパッチ適用、パラメーター変更や索引の作成などデータベースやソフトウェアに対する変更）の前後で、SQLの実行計画や性能、エラーの有無を比較できます。

　一方のDatabase Replayは「システムテスト（負荷テスト）」を行う機能です。本番環境で実行されるワークロードを記録し、テスト環境で再現します。システム変更（主にハードウェアリソースなどのプラットフォームの変更）の前後で、スループットやリソース使用量を比較できます。

　それぞれの基本的な使い方を順に説明します。

SPAの基本的な使い方

　「ハードウェアのリプレースタイミングで、Oracle Databaseのバージョンアップも行う」シーンを例にしたSPAテストの流れは以下の図の通りです（図3）。

図3　SPAテストの流れ

　まず、現行の本番環境でSQLの情報を取得します（図3の1）。このSQL情報を格納したデータを「STS」（SQLチューニングセット）と呼びます。

　STSは、「カーソルキャッシュ」やOracle Databaseの稼働情報を収集してレポート化する機能である「AWR」（Auto Workload Repository：自動ワークロードリポジトリ）から取得できます。STSにはSQLテキストだけでなく、そのSQLの実行計画や実行統計（コストや経過時間など）も含まれます。SQLの網羅率を高めるために、カーソルキャッシュから一定期間（例えば、10分間隔で24時間分など）のSQLを取得するのが一般的です。

　続いて、新環境へデータセットを準備します（図3の2）。SQLの性能はデータ量に左右されるため、性能比較を含めた精度の高いテスト結果を求めるならば、適切なデータセットが必要になります。もしデータセットの準備が難しい場合は、データの定義情報やオプティマイザ統計を移行する方法もあります。性能比較はできませんが、実行計画の変化の有無は確認できます。

　現行の本番環境で取得したSTSをエクスポートし、新環境へインポートします（図3の3）。

　ここからは新環境でのSPAテストの手順となります。まずSPAで、STSの中にある本番環境の各SQLの実行計画や性能情報を抽出します（図3の4）。

　次に、抽出したSQLを1本ずつ新環境で実行し、新環境での実行計画や性能情報を記録します（図3の5）。このときに実行対象となるのは、「SELECT文とDML文の問い合わせ部分」のみです。DML文の実行、コミット、ロールバックは行わないため、SPAテストの実行前後でデータセットの変化はありません。

　図3の4の手順で抽出した本番環境での情報と、図3の5の手順で記録した新環境での情報をSQLごとに突き合わせます。「実行計画が変化したSQL」「新環境でエラーとなったSQL」「性能が劣化したSQL」の結果がSPAレポートとして出力されます（図3の6）。

　このようにSPAを活用することで、バージョンアップで影響を受けるSQLのリストアップ作業がとても楽になります。より実践的なチェック内容は次回以降で紹介する予定です。

Database Replayの基本的な使い方

　「ハードウェアリプレース後のスループットを確認したい」場合のDatabase Replayの実行例は以下の図の通りです（図4）。

図4　Database Replayの実行例

　まず、現行の本番環境でセッション情報を取得します（図4の1）。この情報を格納したファイルを「キャプチャ・ファイル」と呼びます。

　続いて、新環境へデータセットを準備します。Database ReplayではDMLのデータ更新も含めて実行されるため、キャプチャー開始時点に“極力近い”データセットを準備します（図4の2）。

　キャプチャ・ファイルに前処理を施し、「プレイクライアント」と「新環境」へキャプチャ・ファイルを配置します（図4の3）。プレイクライアントとは「Oracle Database Client」がインストールされた端末のことで、ここからキャプチャ・ファイルの内容を再現実行（リプレイ）します。

　配置したキャプチャ・ファイルをプレイクライアントで実行します（図4の4）。

　リプレイ完了後、スループットやリソース消費量の情報が「リプレイレポート」や「AWRレポート」に出力されます（図4の5）。

SPAとDatabase Replayの実行順序

　RATの2つの機能は、SPA→Database Replayの順で使うのがよいでしょう。

　RATを効果的に活用できる代表的なシーンとなる「ハードウェアのリプレースタイミングで、Oracle Databaseのバージョンアップも行う」場合、Database Replayを先に実行して、新環境は「スループットが低下する」と分かったとしても、その原因が「一部のSQLの実行計画にある」のか、「新しいハードウェアのリソース不足」なのかを判断できないためです（図5）。ですから、SPAで個々のSQLの問題を解決するのが先決です。

図5　RATの2つの機能は、SPA→Database Replayの順で使う

SPAとDatabase Replayでは、「ライセンスの考え方」が少し違う

　これまでセットで説明してきたSPAとDatabase Replayですが、両者はライセンスの考え方が少し異なるので注意してください（図6）。

図6　SPAとDatabase Replayの必要なライセンス

　SPAは、「STS取得環境」にはオプションライセンスが不要、「SPAを実行する環境」にはRATのオプションライセンスが必要です。STS取得環境については2017年3月1日にルールが変わり、Enterprise Editionの標準機能でSTSを取得できるようになりました（これまでは、STS取得環境にも、RATもしくは「Tuning Pack」のオプションライセンスが必要でした）。

　一方のDatabase Replayは、キャプチャー取得環境にも、リプレイ実行環境にもRATのオプションライセンスが必要です（プレイクライアントにはライセンス不要です）。

　RATの2機能でライセンスの考え方が違うのはやや困惑してしまいますが、まずはこういうことと理解しておきましょう。

RAT初心者は、まず「SPA」から始めてみる

　初めてRATを使う場合には、「まずSPAを使いこなせるようになる」から始めることをお勧めします。理由は以下の通りです。

1. Database Replayはキャプチャー開始時点に極めて近いデータセットを必須とするのに対し、SPAならばDatabase Replayほど厳しい要求がない（実行計画が変わるほどデータ量が異なる環境となると許容されないが）
2. SPAで「個々のSQLの問題を解決」してから次のステップを踏むのが望ましい
3. SPAはDatabase Replayよりオプションライセンスのハードルが低い

---

　今回は、RATの概要と、RATの2大機能「SPA」「Database Replay」の基礎を解説しました。

　次回はSPAの具体的な活用方法を紹介する予定です。お楽しみに。

筆者紹介

長内麻記（おさない まき）

株式会社アシスト所属　入社以来、Oracle Database一筋。2017年現在はOracle Databaseのお役立ち機能を分かりやすく、楽しく伝えることを目標に活動中。10代の頃の夢は動画クリエーター。当時の知識を生かし、機能解説動画を自作することもある。好きなOracleオプションはReal Application Testing。好きな食べ物はギョーザ。