連載
» 2017年11月24日 05時00分 公開

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。