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

データベースアップグレードでは、旧環境のSQLが新環境で期待通りに動作するか、また性能が劣化しないかをテストする作業に多くの工数が掛かる。これをアップグレードプロジェクトの最大の関門と考える読者も多いだろう。実は、この作業を大幅に早く、簡単に行えるツールがある。[プライベートクラウド/データベース統合][Oracle Database 12c][Oracle Multitenant]

[PR／＠IT]

　本連載では第1回でOracle Databaseにおけるプライベートクラウド構築の特徴的な技術とその利点を紹介、第2回では、プライベートクラウド構築に向けた具体的なアップグレード手法を解説してきた。

　第3回の今回は、アップグレードの際に避けては通れないSQLのテスト手法について、最新の情報を紹介する。

データベースアップグレードの最大の関門は「SQLテスト」

　Oracle Databaseをアップグレードする際、多くの企業が気に掛けるのが、SQLの実行計画の変更に伴う影響だ。読者の中にも、「SQLの実行速度が低下した」「旧バージョンで動作していたSQLがエラーになる」「実行結果が以前と変わってしまった」という経験をした方がおられるかもしれない。

　アプリケーションで使われているSQLを全て把握するのは難しいという根本的な問題もある。小規模なアプリケーションでもない限り、実際にどれだけのSQLが使われているのかを正確に把握するのは困難だろう。機能単位、モジュール単位ならば、使われているSQLを数え上げることができるかもしれない。しかし、アプリケーション全体となると、その調査だけでも相当な工数を要し、全てを洗い出すのは現実的ではない。さらに、該当する大量のSQLを1つずつテストし、その結果を前バージョンと比較するためには、さらに膨大な工数が必要となる。まさに気の遠くなるような話だ。

　アップグレード時のSQLテストに関するこれらの問題を解消するために、オラクルがデータベーステストツール「Oracle Real Application Testing」の1機能として提供しているのが「SQL Performance Analyzer（SPA）」だ。これは本番環境で実行されているSQLをキャプチャー（抽出）し、それをテスト環境などでリプレイ（実行）することのできるツールであり、既に先進的な企業でアップグレード時のSQLテストの効率化に活用されている。

効率的なSQLテストを実現するSQL Performance Analyzer

　従来のテスト方法とSQL Performance Analyzerを用いたテストでは、何が違うのだろうか？

　まず、アプリケーションのソースコードから全てのSQLを洗い出す従来の手法は、網羅性は高いものの、現実には割ける工数に限りがあるため、実現性に乏しい。そのため、実際のプロジェクトでは性能要件が厳しい代表的な機能や頻繁に使われる機能に絞ってSQLを調査し、テストを実施するケースが多い。網羅性を犠牲にすることで、テスト工数を削減しているわけだ。

　一方、SQL Performance Analyzerを利用する場合は、「キャプチャーを実行している間にどれだけのSQLが実行されたか」に網羅性が左右される。全てのSQLが実行されれば網羅性は100％となるが、実際のアプリケーションでは全体の画面の8割程度しか使われないといったケースが少なくない。そのため、SQL Performance Analyzerでも100％を網羅するのは難しいが、使われない画面のSQLならば優先度が低いとも考えられる。

　なお、網羅性の観点でSQL Performance Analyzerの利点となるのは、同じSQLであっても入力値が異なれば、それぞれ別にテストできる点だ。Oracle Databaseでは、同じSQLでも入力値が違えば実行計画が変わることがある。したがって、本来ならば入力値ごとにテストを行う必要があるが、人手によるテストでは入力値のバリエーションまで把握するのは極めて困難だ。一方、SQL Performance Analyzerでは、入力値によって実行計画が異なる場合はそれぞれの入力値をSQLと同時にキャプチャーしてテストできるため、より網羅的にテストが行えるということになる。

　コストと期間についても比較してみよう。人手によるテストでは当然、ソースコードの調査からテストまで相当な作業量となるため、工数も積み上がる。一方、SQL Performance Analyzerであれば、本番環境でSQLをキャプチャーし、テスト環境で実行するだけであり、人手が掛からない上に期間も短くなる。これによってコストを大幅に抑えられる点がSQL Performance Analyzerを使う大きなメリットである。

　ただし、前述したようにSQL Performance Analyzerでは全てのSQLをキャプチャーできない可能性がある。そのため、人命に関わるようなシステムや、システムトラブルが多額の損失につながるような金融系システムなど「コストを度外視し、品質を最優先」にするシステムの場合、システムを網羅的に総点検してSQLを特定し、全てをテストするという方法を採るべきだろう。

　しかし、企業で使われているシステムの大半は、「コストと品質のバランスを重視」、あるいは「コスト最優先で品質は妥協可」といったものだと思われる。こうしたシステムについては、SQL Performance Analyzerによってテストの負担を軽減し、コストを削減することを考えるべきではないだろうか。