とにかく大変なデータベースバージョンアップ時の「SQLテスト」。本連載では、この課題を解決するOracle Databaseのオプション機能である「Oracle Real Application Testing(RAT)」と、その一機能である「SQL Performance Analyzer(SPA)」の攻略方法を紹介していきます。今回はSPAの準備段階で重要なステップとなる「SQLチューニング・セットを作成してテスト環境へ持っていく」までの手順を解説します。
前回は、「SQL Performance Analyzer(以下、SPA)」利用時の全体像を紹介しました。今回は、具体例である「ハードウェアリプレースとOracle Databaseのバージョンアップ時に必要となる、本番環境で流れているSQLを丸ごと取り出す」という工程を想定し、SPAの実行ステップと準備方法を順に解説していきます(図1)。
STEP 1では、本番環境に流れるSQLと関連情報をひとまとめにした「SQLチューニング・セット(以下、STS)」を作成します。
まずは、Enterprise ManagerからSTSを作成するまでの解説動画をご覧ください(動画1)。
動画1のシステム構成図は以下の通りです(図2)。
ここでは、模擬ベンチマークアプリケーション「Swingbench」のSOEスキーマを使用して一定期間、SQLを自動発行しつつ、APPSスキーマを使って一時的にSQLを発行するシェルスクリプトを実行するようにしています。
STSの作成前にこれらのアプリケーションの稼働状況を確認したら、Enterprise ManagerからSTSを作成します。参考までに、今回の動画1では3分間、30秒間隔でカーソルキャッシュからSQLをロードしています。この期間のアプリケーションの稼働状況は、STS作成前の状況と比べてどうでしたか。「STSの作成は本番環境で実行するが、その負荷は大丈夫か」といった問い合わせはよくありますが、その負荷は少ないことがお分かりいただけたと思います。
では、実際にSTSを作成していきましょう。Enterprise Managerの「SQLチューニング・セット」メニューから、5ステップで作成できます。
まずSTSの名称を決めます(図3の画面1)。続いて、SQLのロード元を選択します(図3の画面2)。この画面で「24時間/10分間隔」といったようにカーソルキャッシュをスキャンする期間と頻度を指定します。「24時間/10分間隔」とは、10分間隔でスキャンを行い、スキャン時点でカーソルキャッシュにあるSQL情報をロードする工程を24時間繰り返すという設定を意味します。
その後、STSへ格納するSQLの条件設定を行います(図3の画面3)。ここに何も設定しなければ、SYSやSYSTEMが実行する再帰SQLを含めた全てのSQLがSTSに格納されます。
1つ大事なポイントがあります。STSはSYSAUX表領域に格納されるということです。格納先の表領域変更はできません。そのため、STSによってストレージ領域の圧迫が懸念される場合には、STSの取得対象からSYSやSYSTEMスキーマを除いたり、特定のスキーマで絞り込むなどの設定をしておくと良いでしょう。なお、1度取得したSTSにフィルターをかけて、新しいSTSを作成することも可能です。
次はスケジュールの設定を行います(図4の画面4)。即座にSQLのロードを開始するのか、設定した日時に開始するのかを設定できます。例えば、夜間帯のみ、月末月初のみなどを対象にしたい場合に使います。
最後に作成設定の内容を確認して「発行」ボタンを押せば、STSの作成が開始されます(図4の画面5)。
Swingbenchの実行画面から、データベースサーバのCPU使用率やTPS(Transactions Per Second:トランザクション毎秒)の状況を確認すると、STS作成中の負荷状況を確認できます(図5)。
STSの作成中も、CPU使用率、TPSともに大きな変化がないことが図5で分かります。STSの作成による負荷は小さく、本番環境への影響も少ないと考えてよいでしょう。負荷の影響がどうしても不安な場合には、「カーソルキャッシュから1度だけロード」の設定にして試してみてください。もう1つ、安全性を特に重視するのであれば、STSが格納されるSYSAUX表領域の使用率の監視も行っておくと良いでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.