そろそろ12cに移行する？ 課題はアップグレード時のDBテスト Oracle RATとOracle DBCSで手間とコストのリスクを最小限に！：新日鉄住金ソリューションズのエキスパートも太鼓判（1/4 ページ）

Oracle Databaseのアップグレードでは、移行前後でSQLの性能がどう変化するかを検証するテストが大きな関門になる。Oracle RATとOracle DBCSを使えば、このテストにかかる手間とコスト、リスクを最小限に抑え、アップグレードしやすい運用／保守体制を作れる。[運用管理効率化][Oracle Enterprise Manager]

[PR／＠IT]

PR

Oracle RATとOracle DBCSでデータベースアップグレード時のテストを省力化／低コスト化

　「Oracle Database 12c R2」の提供が開始された2017年1月現在、「当社のデータベース環境も、そろそろ12cへのアップグレードを検討する時期だ」と考える担当者は多いだろう。データベースのアップグレードはハードウェアの入れ替えやアプリケーションの改修を伴うことが多く、アップグレード前後の環境でパフォーマンスがどう変わるのかを確認するテストが不可欠となる。ただし、このテストには多くの手間とコストがかかるため、これがアップグレードの負担を増やす要因の1つとなっているようだ。

　そうした企業に試していただきたいのが、データベーステストツール「Oracle Real Application Testing（以下、Oracle RAT）」とOracle DatabaseのPaaS（Platform as a Service）である「Oracle Database Cloud Service（以下、Oracle DBCS）」を用いたアップグレードテストである。テスト工程の多くを自動化するOracle RATと従量課金で利用できるOracle DBCSを使えば、一時的に必要となるテスト環境を最小限の手間とコストで調達し、迅速にテストが行える。その意義とメリットを、日本オラクルと新日鉄住金ソリューションズのエキスパートに聞いた。

これからのデータベースは“塩漬け”ではなく“ぬか漬け”で運用すべし

日本オラクル クラウド・テクノロジー事業統括　Cloud/Big Data/DISプロダクト本部の小幡創氏

　読者の会社には、“塩漬け”にされたデータベースシステムがどれくらいあるだろうか？　企業システムの世界で“塩漬け”と言えば、インフラやアプリケーションの構成を変えず、長期間にわたって安定的な運用を図るアプローチを指す。もちろん、これにはさまざまな事情があるだろうが、日本オラクルの小幡創氏（クラウド・テクノロジー事業統括 Cloud/Big Data/DISプロダクト本部）は、「常に最新版のソフトウェアを使い続けることが大きなメリットをもたらすようになった今日では、“塩漬け”による運用の考え方から脱却し、“ぬか漬け”による運用に移行すべきです」と話す。

　小幡氏が言う“ぬか漬け運用”とは、漬け物のぬか漬けのように短いサイクルで定期的に保守を行いながらデータベース環境をよりよい状態に保ち、安定的な運用を続けることで、データベースをアップグレードしやすくすることを指す。

　例えばOracle Databaseに関して言えば、12c R1でマルチテナント機能（Oracle Multitenant）やOracle Database In-Memoryなどの新機能が導入され、多数のデータベースを集約してコスト効率や利用効率を高めるデータベース統合基盤、あるいはOLTPシステムとデータウェアハウスを統合したリアルタイムデータ活用基盤の構築が容易となった。また、2017年1月現在の現行バージョンである12c R2では、これらの機能がさらに強化／洗練され、多様な用途で利用可能になった。“ぬか漬け運用”によってこうした新機能を取り入れやすいデータベース環境を保てば、Oracle Databaseを使うメリットを最大化し続けられるという提案だ。

　とはいえ、「好んで“塩漬け”にしているわけではない」と反論する向きもあるだろう。実際、「データベースアップグレードには相応の手間とコスト、そしてリスクが伴う。それらを避けるために、やむなく“塩漬け”にしているのだ」という企業は少なくない。

　「データベースのアップグレードにより、アプリケーションの性能や挙動が意図せず変わってしまうのは避けたいところです。これを防ぐには入念なテストが不可欠ですが、手作業で網羅的に行った場合、それこそ果てしない工数とコストがかかる恐れがあります」（小幡氏）

　一般に、データベースをアップグレードする際には次の内容についてテストを行い、アップグレードの影響を把握して事前に対策を施すことが必要とされる。

• SQLの実行性能の変化
• SQLの実行計画の変化

　前者に関しては、アップグレード前後の環境におけるSQLの実行性能を計測し、両者を比較する行程だ。その結果、アップグレード後の環境で性能が低下している場合にはチューニングなどを行うことになる。

　また、後者についてはEXPLAIN PLANを用いる方法が思い浮かぶかもしれないが、これは実際に使用される実行計画とは異なることがあるために注意が必要だ。それとは別の手段として、バインド値をセットして実行し、PLAN_HASH_VALUEを比較するというものがあるが、いずれの場合にも実際のシステムと同じバインド値を使わないと正確なテストができないことに留意されたい。実環境と近似のバインド値を使うには、それをアプリケーション担当者に提供してもらう方法の他に、DBMS_XPLAN.DISPLAY_CURSORや、V$SQL_BIND_CAPTUREによって本番環境から取得する方法などが考えられる。

　これらいずれのテストでも鍵となるのが、テストの「網羅率」と「自動化」「テスト環境の準備」である。

　テストの「網羅率」とは、アプリケーションで使われているSQLについて、より多くの数をテストすることだ。

　「全てのSQLをテストするのが理想ですが、それが難しいことも多いでしょう。アプリケーションで使われているSQLを調べるには、アプリケーションのソースコードを調べるという手間のかかる方法の他に、本番環境で実行されているSQLの情報がディクショナリに記録されているので、それを一定期間にわたって収集してSQLリポジトリを作り、その中のSQLをテストする方法が一般的です。Oracle Databaseのオプションである『Oracle Tuning Pack』を使っている場合は、同ツールによって本番環境のアプリケーションで実行されているSQL文や実行計画、実行統計を収集できます」（小幡氏）

Oracle Real Application Testingによるテスト自動化

　一方、テストの「自動化」とは、アプリケーションで使用しているSQLの収集やテスト実行、結果の比較やレポート生成などの作業を自動化することを指す。これを実現するツールとしてオラクルが提供しているのがOracle RATだ。同ツールは、大きく次の2つの機能を提供する。

• SQL Performance Analyzer：本番環境のデータベースにおけるSQLをSQL Tuning Setとしてキャプチャーし、テスト対象のデータベースでの実行計画の変化やSQLの性能／互換性の比較を行う。付帯するツールとして、本番環境が用意できない場合でもいくつかのテストが行えるSPA Quick Checkを提供する。
• Database Replay：本番環境でキャプチャーしたワークロードをテスト対象のデータベースに対して実行（リプレイ）し、その性能やリソース使用量を計測する。付帯するツールとして、複数のキャプチャーを1つのデータベースに対して実行できるConsolidated Replayを提供する

　これらのツールを使うことで、前述したテスト作業の多くが自動化される。

　「通常規模のシステムでは、実行されているSQLの数は数千に上るでしょう。SQL Performance Analyzerを使うことで、それらのSQLをアップグレード前後のデータベース環境で一気に実行し、その結果を比較したレポートを出力できます。Oracle RATはOracle Enterprise Managerの画面で操作できるほか、Oracle DatabaseのAPIを介してDBMS＿SQLTUNEなどからも操作可能なため、Oracle Enterprise Managerがない環境でもSQLを使える方ならテストを実施できます」（小幡氏）

　なお、SQL Performance Analyzerではデータベースワークロードをキャプチャーする際、SQLのバインド値も記録する。テスト環境では、その値を使ってSQLが実行されるため、本番環境に近い条件でテストが行えるというメリットもある。