Special
» 2015年12月07日 07時00分 公開

Oracle DBアップグレード時のSQLテストの手法を知るデータベース運用管理をクラウド化する方法(3)(3/3 ページ)

[PR/@IT]
PR
前のページへ 1|2|3       

出力されるリポートから、問題のあるSQLを特定

 SQL Performance AnalyzerによるSQL単体性能テストで、最初のステップとなるのは本番環境でのSQLのキャプチャーだ。キャプチャーした内容はSQL Tuning Set(STS)と呼ばれる領域に蓄積されるので、これをテスト環境に転送して実行する。新旧それぞれのバージョンに対してテスト環境を用意した場合、両環境でSQLを実行し、その実行計画や性能を比較したリポートを出力できる。

 テスト環境が1つしかない場合でも、SQL単体性能テストを実施することは可能だ。まずテスト環境に旧バージョンのOracle Databaseをインストールしてテストを実施し、その後アップグレードして再度テストを行えばよい。

 また、1つの環境に新旧バージョンのOracle Databaseをインストールする方法もある。本番環境と若干構成は異なることになるが、性能への影響はそれほど大きくないと考えられる。もし、テスト環境を1つしか用意できないのなら、この方法もご検討いただきたい。

 実行計画を比較したリポートでは、トータルのSQL数や実行計画が変化したSQL数、エラーが発生したSQL数を確認できる他、実行計画が変化した個々のSQL文や新旧の実行計画なども表示されるので、実行計画の妥当性を確認することができる。

 一方、性能比較では、「性能が変化していないSQL」「性能が改善したSQL」「性能が劣化したSQL」の3つに分類された比較リポートが出力される。具体的な性能比較結果も明記されるので、そこからチューニング対象とするSQLをピックアップしていくことになる。

 なお、一概に「性能」と言っても、これにはさまざまな指標がある。例えば、レスポンスタイムやCPU使用時間、I/O時間などだ。そのため、SQL Performance Analyzerでは複数の性能項目で比較できるようになっている。それらの中でも比較項目としてお勧めしたいのが「buffer_gets」である。これはバッファ読み取りブロック数で比較するというものだが、ハードウエアの性能やOS、Oracle Databaseの状態に影響を受けにくく、安定した比較が行える。実際に評価する際には「buffer_gets」と「elapsed_time(レスポンスタイム)」を組み合わせて比較するのがよいだろう。

SQL Performance Analyzerでテスト工数を97%削減したケースも

 最後に、実際にSQL Performance Analyzerを活用して大きな成果を挙げた事例として、ある大手保険会社のプロジェクトを紹介しよう。

 このプロジェクトで対象となったのは、「新規契約」と「保険支払い」「業務端末管理」という3つのシステムである。SQLの数は、それぞれ2万5000、25万、1600であった。リテラルを使用したSQLが多いため、このように膨大な数となるが、実際のSQLの数は、これらの10分の1程度だと思われる。

 プロジェクトの内容は、Oracle Database 11.1.0.7を11.2.0.4にアップグレードするというものである。この中で課題となったのが、SQLの数を把握できないことと、性能変動がどの程度起きるのか判断できないため、チューニング工数を見積もれないことであった。

 そこで、同社はSQL Performance Analyzerを導入し、SQLのテストを行うことにした。実際の検証結果を見ると、テスト対象となった3システムの合計約28万のSQLのうち、文法エラーが発生したSQLは0.24%、正常に実行されたもののうち、実行計画が変化しなかったSQLが91.73%、実行計画が変化したのは8.03%で、そのうち5.37%のSQLの性能が向上し、0.62%は性能が変わらなかった。性能が低下したSQLは0.04%だったが、許容できないレベルだったのは、そのうちのわずか0.01%である。この結果から、アップグレードしても意外と性能劣化は起きないことが分かるだろう。

 SQL Performance Analyzerを導入した成果として、この企業では工数を97%削減できたとしている。当初、テストに188人月を見込んでいたが、SQL Performance Analyzerを利用したことにより、わずか4人月で同じテストを実施できたのである。

 ここまでに解説した通り、SQL Performance Analyzerを使えば、アプリケーション内に散在するSQLを見える化し、SQLを把握できていないシステムであっても本番環境でキャプチャーすることによって実際に使われているSQLを明らかにすることができる。

 また、それらのSQLを新旧環境で比較することにより、アップグレードによる性能面の影響を容易に確認することが可能であり、テスト工数の大幅な削減につながる。アップグレードプロジェクトで活用できるのはもちろん、索引の追加やパラメーターの変更などを行った際、SQLへの影響を調査するためのツールとして使える点も大きなポイントだ。

 アップグレードプロジェクトの成否を分けるSQLテストの効率化と精度向上に、ぜひこうしたツールもご活用いただきたい。

 以上、本企画では3回にわたり、Oracle Database 12cによるプライベートクラウド構築に向けたベストプラクティスを紹介した。Oracle Databaseには、クラウド技術を利用してデータベース環境を効率的に構築/運用することのできる実績のある手だてが、既に豊富に用意されている。これらをいち早く活用し、コスト効率と運用性に優れたプライベートクラウド環境を実現していただきたい。

前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.


提供:日本オラクル株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2016年1月6日

関連情報

驚異的なパフォーマンス、優れた運用効率、最高の可用性とセキュリティ、クラウド対応を実現するOracle Exadataとの統合、クラウド、可用性や運用管理など、次世代データベース基盤構築のために参考になる必見資料をまとめてご紹介いたします。

RSSについて

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

メールマガジン登録

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