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

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

SPA利用に最適なクラウド環境は？

　Oracle Databaseは、Oracle CloudやAmazon Web Services（以降、AWS）、Microsoft Azure（以降、Azure）でも利用可能です。要件に応じて適切なクラウド環境を選択できます。SPAを使う場合、どのクラウド環境が最適でしょうか。

　設計・計画工程でクラウド環境を作成してSPAを使う場合、数カ月間だけ利用することになるでしょう。AWSやAzureでライセンスコストを最低限に抑えたいのならば、Oracle Database Enterprise Edition（以降、Oracle DB EE）とOracle Real Application Testing（RAT）をTerm License（1年〜5年の期間限定ライセンス）で利用する方法があります。ただし、最低でも1年間のライセンス費が必要になります（2017年11月時点）。

　これに対してOracle Cloudでは、Oracle DB EEとRATを従量制で利用できます。使った時間の分だけ費用を支払えばよいので、1年以内の短期間利用ではコストメリットが大きくなります。Oracle Cloudでは、Oracle DB EEにプラスして複数のオプションを含んだ形で、エディションを設けています（図4）。Database Cloud Serviceの「Enterprise Edition」には、RATに加えてTuning Packも含まれています。テストに加えてSQLチューニングを実行したい場合、追加のオプションライセンスが不要なことも利点です。

図4　Oracle CloudのDatabase Cloud Serviceの特徴

　Oracle Databaseの最新バージョンを移行先として想定している場合も、Oracle Cloudが有利です。最新バージョンを最も早く提供するからです（Oracle Database 12c Release2以降）。いち早く最新バージョンのテストを開始したい場合は、オンプレミス版のリリースを待たずに、Oracle Cloudで試すことが可能です。

テスト・チューニング工程でSPAを活用し、低コストで高精度のテストを完遂

　テスト・チューニング工程では本来、全てのSQLをテストして問題を特定すべきです。チューニング後に再テストを繰り返すことで安全性を高めていきます。

　しかし、テスト・チューニング工程は手作業が主体となることに加え、SQLの量が膨大で全てをテストできないことも珍しくありません（図5）。技術者の経験を頼りに抜粋したSQLをアプリケーションから実行し、性能が大きく低下するものだけ検知する、これで精いっぱいというのが実情ではないでしょうか。

　極端に遅くなるSQLに限って追加テストで実行計画や実行統計を取得し原因を分析、チューニングを行ったとしても問題が残ります。チューニングが他のSQLに悪影響を及ぼさないか再テストをする時間が足りず、実施できない、という話をよく耳にします。

図5　テスト・チューニング工程での課題

　このような場合は、SPAとTuning Packを使って効率的に問題の特定と解決を行う、ユースケース2が適します。ユースケース2には、さらに2パターンが考えられます。新本番環境のみ利用するパターン1（図6）と、新本番環境＋検証環境を利用するパターン2です。

図6　SPAとTuning Packを使って効率的に問題を特定（ユースケース2、パターン1）

　パターン1では、テストモードとしてConvert SQLSETとTest Executeを使うため、SPA実行環境の数が新本番環境の1つだけで済みます。つまりライセンス費用を抑えることができます。ただし、Convert SQLSETを使用しているため、外的要因の影響を受ける可能性があります。性能値を評価する際には考慮が必要です（詳細は連載第5回）。

　パターン2では、新しいバージョンの新本番環境に加え、旧本番環境と同じバージョンの検証環境を利用します（図7）。その後、それぞれの環境でTest Executeを利用します。Test ExecuteはSQLを1本1本シリアルに実行しますから、他の処理の影響がなく、新環境と旧環境の結果を純粋に比較可能です。より精度の高い性能評価となります。

図7　新旧の実環境を用意してSQLの性能を高精度評価（ユースケース2、パターン2）

　パターン2の欠点はコスト。検証環境にもOracle DB EEとRATのライセンスが必要なため、ライセンスコストはパターン1に比べて高くなります。

　どちらのパターンを選択したとしても、SQLチューニング・セット（以降、STS）によってSQLを網羅的に取得し、テストは全て自動で行えるため、工数をかけずに精度の高いテストが可能です。さらにチューニング・アドバイザを利用することで効率よくチューニングを進め、繰り返しのテストも容易です。こうして正確性の高いテスト・チューニングが実現できます。