Oracle Database 11g Oracle Real Application Testing検証 … · 応じてOracle Database 11g の機能を使用したより詳細な調査や対策が可能である。図2-4. Database

Oracle Database 11g

Oracle Real Application Testing 検証結果

ホワイトペーパー

第 1.0 版 2008.8.25

はじめに

日本電気株式会社（以降、NEC）は、2006 年 7 月、次世代 IT 基盤を実現するため、IT プラットフォ

ーム製品の開発指針およびロードマップを策定し、IT プラットフォームビジョン「REAL IT

PLATFORM」を発表しており、この「REAL IT PLATFORM」では、NEC の仮想化技術、高信頼技術、

統合化技術とシンプルな運用技術を利用し、「柔軟」「安心」「快適」なシステムをお客様に提供す

ることを目指している。

一方、日本オラクル株式会社(以降、日本オラクル)は、Oracle Database 10g を発表した数年前よ

りグリッドコンピューティングを実現する「Oracle GRID」技術を提供している。さらに 2006年11月、

グリッドをベースとした次世代のビジネス・ソリューション構築を目的に、世界最大級規模の検証

施設「 Oracle GRID Center （オラクル・グリッド・センター）」

(http://www.oracle.co.jp/solutions/grid_center/index.html)を開設した。

本資料では、Oracle Database 11g リリースに伴い、注目されている新機能 Oracle Real

Application Testing (以降、RAT) を NEC と日本オラクルの共同で「Oracle GRID Center」の環境を

利用し、検証した結果を記載する。

目次

................................................................................................................................2 はじめに

1. .......................................................................................................4 本検証の背景と目的

2. ...............................................................................................................5 製品・機能紹介

2.1. SIGMABLADE-M......................................................................................................5 2.2. ........................................................................................................5 iStorage D3-10

2.3. ..................................................................................6 WebSAM SigmaSystemCenter

2.4. ......................................................................7 Oracle Real Application Testing (RAT)

2.5. ..........................................................................9 Transparent Data Encryption (TDE)

2.6. ....................................................................9 Oracle Real Application Clusters (RAC)

3. ......................................................................................................................10 検証内容

4. ...................................................................................................................... 11 検証環境

4.1. ......................................................................................................... 11 システム概要

4.2. ............................................................................................. 11 使用したハードウェア

4.3. ...............................................................................................13 使用したソフトウェア

4.4. ....................................................................................................13 ネットワーク構成

5. ...............................................................................15 Database Replay負荷再現性の確認

5.1. ...............................................................................................................15 検証項目

5.2. ...............................................................................................................15 検証方法

5.3. ...............................................................................................................19 検証結果

5.4. ....................................................................................................................29 まとめ

6. ...........30 Database Replayと他機能との組み合わせ時の動作確認 1 (TDEとの組み合わせ)

6.1. ...............................................................................................................30 検証項目

6.2. ...............................................................................................................30 検証方法

6.3. ...............................................................................................................31 検証結果

6.4. ....................................................................................................................35 まとめ

7. ...........37 Database Replayと他機能との組み合わせ時の動作確認 2 (RACとの組み合わせ)

7.1. ...............................................................................................................37 検証項目

7.2. ...............................................................................................................37 検証方法

7.3. ...............................................................................................................41 検証結果

7.4. ....................................................................................................................46 まとめ

8. ......................................................................47 SQL Performance Analyzer有効性の確認

8.1. ...............................................................................................................47 検証項目

8.2. ...............................................................................................................49 検証方法

8.3. ...............................................................................................................51 検証結果

8.4. ....................................................................................................................56 まとめ

9. 本検証を終えて.............................................................................................................57

3

1. 本検証の背景と目的

以下、本検証の背景と目的を示す。

背景：

運用管理・維持コストは、IT 投資額の 7 割から 8 割を占めると言われている。これらのコストを削

減し、新規サービスなどの戦略的投資を行っていくことが、システム管理者（部門）では、急務と

なっている。

このような背景を踏まえ、Oracle Database 11g では、運用管理コストを削減する様々な機能が

実装された。今回検証する Oracle Real Application Testing (以降 RAT) もその機能の一つであ

る。

目的：

Oracle Database 11g の新機能である RAT による運用管理コストの大幅削減を技術的な側面

から裏付けるため、以下の２点の目的に検証を実施した。

• システム変更リスクを低減させるために、RAT の各機能（Database Replay や SQL

Performance Analyzer）が確実に動作し、負荷再現性の観点において利用可能な品質で

あること確認する

• RAT 使用時のリソース使用状況およびデータを取得し、実際に使用する際のリソース・サ

イジングを可能にする

4

2. 製品・機能紹介

以下に今回の検証で使用した製品・機能を紹介する。

2.1. SIGMABLADE-M

NEC ブレードシステム「SIGMABLADE（シグマブレード）」は、高密度実装を重視したモジュラーア

ーキテクチャの採用により、サーバ増設が容易で、必要な時に必要な枚数を簡単に追加すること

が可能である。また、電源や FAN、メディアなどのデバイスを全て共通化することにより部品数を

削減し、低消費電力化を実現するとともに、各種スイッチモジュール（FibreChannel及びLAN）が内

蔵可能で、省スペース化を実現している。分散していたシステムをひとつにするサーバ統合に最

適なプラットフォームとして、IT 管理業務の簡素化と高次元の可用性を実現できる。

図 2-1. SIGMABLADE-M の構成

2.2. iStorage D3-10

iStorage D3-10 は、ハイエンドストレージの先進技術を投入し、高性能・高信頼でありながら、リー

ズナブルな価格設定と専門知識のいらない簡単な導入・運用性を実現しており、以下の特徴があ

る。

- シンプルでミスのない導入設定

ストレージ装置を設置してから、サーバで利用するまでのプロセスが徹底的に簡素化されて

おり、専門の知識がなくても、初期設定ウィザードに沿って必要項目を入力していくことで設

定できる。

- 徹底した冗長化による高信頼設計

可用性にこだわりすべてのコンポーネントを冗長化している。

- ビジュアルな表示画面で一元管理・操作

Web ブラウザ画面で、ストレージの容量情報やディスクの負荷状況、システムの稼働状況な

どを一元的に監視したり、レプリケーション設定などを操作したりできる。初めてストレージを

利用する方でも理解しやすく、操作ミスを防ぐことができる。

- オンライン業務に影響を与えない無停止バックアップ

変更のある部分(更新差分)だけを効率よく保持するスナップショット機能、無停止で業務ボ

リュームの完全複製を作成するレプリケーション機能を使用できる。

また、無停止バックアップシステムの構築に対して、対象リソースの自動検出機能や、わか

りやすい対話形式のスクリプト作成機能などのサポートで、従来と比べ容易に無停止バック

5

アップシステムを構築できる。

- ニーズに合わせた効率的なストレージ運用

最新の仮想化技術により、業務を止めずに論理ディスクの容量拡張、追加ができる。物理

ディスクを仮想的なダイナミックプールとして管理することでニーズに合わせて効率よくスト

レージを使用できる。（ダイナミックプールは、RAID-6、RAID-TM構成時のみ利用可能）ま

た、業務を停止することなく動的に同一ストレージ内ディスクの再配置、性能の最適化が

可能である。

注）本検証では、上記機能を使用しておりません。

図 2-2. 無停止で業務ボリュームを拡張 (イメージ)

2.3. WebSAM SigmaSystemCenter

SigmaSystemCenter (シグマシステムセンター) は、NEC ミドルウェアの豊富な実績で培った技術

を結集し、柔軟性、可用性、保守性を備えた次世代のシステム管理・運用基準を提供、プラットフ

ォームの統合管理ソフトウェアであり、サーバ、ストレージ、ネットワークの統合管理を実現する。

マルチプラットフォーム、マルチ OS を同一の管理画面・同一の操作性で簡単に管理することがで

き、システム管理者の TCO 削減に役立つ。以下の特徴を持っている。

- ソフトウェアの一括配布

OS やアプリケーションをネットワーク経由で一括リモートインストールできる。煩雑なパッチ適

用なども管理コンソールから一元管理でき、導入時に大きな負担となる OS やアプリケーショ

ンのインストール、各種設定の手間を大幅に軽減する。本検証において、検証環境を構築す

る際、8 台のサーバに対してホスト名のマシン固有情報以外は全て同一の環境を配布する必

要があり、本ソフトウェアの使用により環境構築にかかる工数が大幅に減少した。

- 可用性向上とコスト削減を両立

複数台の業務サーバに対して、最少 1 台の予備サーバを用意しておけば、障害時に予備サ

6

http://www.nec.co.jp/products/istorage/product/san/pool.html

ーバにより自律復旧できる。低コストで可用性の高いシステムを構築することが可能である。

- リソースの効率運用

GUI からの簡単な操作で、サーバの構成を変更できる。また、スケジュール運転による計画変

更も可能なため、繁忙期にあわせたシステム構成の変更も容易。リソースの効率活用とシス

テム管理者の負担軽減を同時に実現できる。

- システム内のサーバを統合管理

Windows、Linux、HP-UX などのサーバ OS のほか、クライアント OS として Windows XP にも対

応している。また、SIGMABLADE だけでなく既存サーバ環境、さらにネットワークやストレージ

の構成まで管理できる。高度な機能でシステム基盤を統合的に管理し、運用の効率化を実現

できる。

図 2-3. SSC ソフトウェア一括配布（イメージ）

2.4. Oracle Real Application Testing (RAT)

本検証の主目的となるOracle Real Application Testing(RAT)が開発された背景には、実環境に近

い負荷をテスト環境において網羅的に再現するためのテストツールの不在が挙げられる。これは、

システムの変更に伴いしばしば散見される、動作上や性能上の問題を未然に防ぐことを目的とし

ている。Oracle Real Application Testingオプションは2つの機能より構成されている。一つは

Database Replayと呼ばれる機能であり、もう一方はSQL Performance Analyzerである。Database

Replayは本番環境において実行されているワークロードを収集し、収集されたワークロードをテス

ト環境にて実行する機能である。これにより変更後のシステムに対する影響度を本番環境への適

用以前に計ることができる。ワークロードはバイナリ・ファイルとして収集され、Database Replay

が提供するワークロード・リプレイ・クライアントによってリプレイされる。

リプレイ時には以下のパラメータを設定する事により、動作の制御が可能である。

(1) synchronizationパラメータ

・リプレイ時に、取得したワークロードのTransaction順序を保障するかどうかを制御する。

trueの時は保障し、falseの時は保障しない(デフォルトはtrue)。

7

(2) connect_time_scaleパラメータ

・リプレイ時に、セッションの接続間隔のスケールを％で指定する。デフォルト値は100(スケール

の変更が無い状態)。

(3) think_time_scaleパラメータ

・リプレイ時に、同一のセッションにおいて実行されるSQLの発行間隔のスケールを％で指定

する。デフォルト値は100(スケール変更は無い状態)。

(4) think_time_auto_correct パラメータ

・リプレイ時のSQLの実行時間が取得時よりも長い場合にSQLの発行間隔を自動的に調節す

る。trueの場合は調節し、falseの場合は調節しない(デフォルトはtrue)。

リプレイの実行後は、Oracle Enterprise Manager より詳細なレポートが参照可能である。レポート

からは、ワークロード取得時とリプレイ時のパフォーマンスや実行結果の差異が確認でき、必要に

応じて Oracle Database 11g の機能を使用したより詳細な調査や対策が可能である。

図 2-4. Database Replay レポート出力例

一方、SQL Performance Analyzer は、システム変更に伴い影響を受ける個々の SQL 文の実行計

画や統計から得られる性能情報を、アプリケーションの特定の SQL にブレークダウンした形で事

前に確認することが可能となる機能である。Database Replay 同様、Oracle Enterprise Manager

より参照可能なレポートによって、SQL への影響を確認でき、必要に応じてチューングから実行計

画の固定までをスムーズに行うことが可能である。

8

図 2-5. SQL Performance Analyzer レポート出力例

2.5. Transparent Data Encryption (TDE)

Transparent Data Encryption (以下、TDE) は、Oracle Database 10g Release 2 (10.2) より

Oracle Advanced Securityの一機能として提供されている格納データ暗号化の機能である。TDE

によって暗号化するデータは表の列単位で指定することができ、暗号化/復号化はOracle

Database内部で、機密データへのアクセス権を所有するデータベースユーザーからは透過的に行

われる。このため、クライアントやアプリケーションを変更し、新規に暗号化ロジックを組み込むこと

なく、システム内の機密データのみに暗号化を導入することが可能である。暗号化キーには、対

象データを暗号化するための列暗号キーと、列暗号キーを暗号化するためのマスター・キーの二

種類があり、列暗号キーは表毎に自動生成され、マスター・キーはOracle Wallet内で安全に格納

される。このため、クライアントやアプリケーションにおいて煩雑な鍵の管理を考慮する必要もない。

さらに、Oracle Database 11g Release 1 (11.1) からは表領域単位の暗号化の設定も可能となっ

た。

TDE は、簡単かつセキュアなデータベース環境を提供する機能として、データ暗号化のニーズ増

加に伴い今後の使用拡大が期待されている。

2.6. Oracle Real Application Clusters (RAC)

Oracle Real Application Clusters (以下、RAC) は、高可用性とリニアなスケーラビリティを両立さ

せた、共有ディスク・クラスタ型のクラスタ・データベースである。グリッドコンピューティングを実現

するためのワークロード管理機能が実装されている。これは、アプリケーションをサービスとして定

義し、処理リソースを必要に応じて割り当てることが可能である。また、データの再配置やアプリケ

ーションの変更無しに、クラスタのノード追加が可能であり、システムの成長に合わせて、処理能

力を拡張させることができる。Oracle Grid Computing を支える基盤技術である。RAC は Oracle

Real Application Clusters オプションによって提供される。

9

3. 検証内容 SIGMABLADE に搭載した 8 台の CPU ブレードを使用して RAT 機能について、以下の点の検証を

行った。

１． Database Replay 負荷再現性の確認

トランザクション負荷量を変えながら、キャプチャ有無によるハードウェアリソース使用量の増分やキャプ

チャ時やリプレイ時でのスループット、ハードウェアリソース使用量の差分を確認、考察

２．Database Replay と他機能との組み合わせ時の動作確認

・Transparent Data Encryption（TDE）を使い、一部のデータを暗号化した状態で項番１.の検証

・Oracle Real Application Clusters（RAC）環境を想定した、キャプチャ時とリプレイ時の接続再マップの動

作検証

３．SQL Performance Analyzer 有効性の確認

・SQL Tuning Set 取得によるハードウェアリソース使用量とスループットの変化の確認

・Oracle Database のバージョンアップやデータサイズ変更のシナリオを想定した基本動作検証

図 3-1. キャプチャ有無によるハードウェアリソース量確認検証 (イメージ)

図 3-2. キャプチャ時やリプレイ時でのスループットやハードウェアリソース使用量の差分確認検証 (イメージ)

10

4. 検証環境

4.1. システム概要

本検証環境のシステム構成の概要は以下の通り。

図 2-1. システム構成

（参考）各検証にて使用したサーバ[ホスト名]は、以下の通り。

表 2-1. 各検証で使用したサーバ一覧

Replay Client Database 検証名 Test Program

(Single or RAC) (Client)

１．Database Replay 動作検証

n0c-13 n0c-11 n0c-13 Transparent Data

Encryption（TDE）

２．Database Replay と他

機能との組み合わせ検証

Real Application

Clusters (RAC) n0c-12 n0c-15～18 n0c-15

n0c-12 n0c-14 N/A ３．SQL Performance Analyzer 動作検証

4.2. 使用したハードウェア

本検証で使用したサーバ、ストレージは以下の通り。

11

・データベースサーバ

表 2-2. 使用したデータベースサーバ

ブレードシステム SIGMABLADE-M

CPU ブレード Express5800 120Bb-6 × 8 ブレード

CPU デュアルコアインテル(R)Xeon(R)プロセッサー

5160 3GHz 2 ソケット/CPU ブレード

メモリ 8GB/CPU ブレード

・ストレージ

表 2-3. 使用したストレージ

モデル名 iStorage D3-10

ホストインタフェースファイバチャネル（最大 400MB/s）× 2

キャッシュメモリ 4GB

ディスクドライブ SAS 147GB(15,000rpm) × 12

図 2-2. LUN の構成とストレージの使用用途（その 1）

図 2-2 のように iStorage D3-10 のストレージにおいて、147GB のハードディスクの 10 台から

RAID50 グループと RAID1 を構成し、LUN を作成している。各 LUＮの用途を以下に記す。

表 2-4 . LUN の構成とストレージの使用用途（その２）

12

Oracle を構成するデータファイル、REDO ログファイル等はすべてこのディスク・グループ内に作成

し、全て ASM で管理している。

4.3. 使用したソフトウェア

本検証で使用したソフトウェアは以下の通り。

表 2-5. 使用したソフトウェア

OS Red Hat Enterprise Linux Version4 Update5 Advanced Server

（Kernel 2.6.9-55.EL）

クラスタウェア Oracle Clusterware 11g Release 1 (11.1.0.6)

Oracle Database 11g Release 1 (11.1.0.6) Enterprise Edition

Oracle Real Application Clusters Option

Oracle Advanced Security Option

Oracle Real Application Testing Option

データベース

WebSAM SigmaSystemCenter 1.1 運用管理ソフトウェア

Oracle Enterprise Manager 11g Database Control (11.1.0.6)

4.4. ネットワーク構成

本検証環境のネットワーク構成は以下の通り。

13

WebSAM SigmaSystemCenterOracle Enterprise Manager 10g

Grid Control

管理サーバ DB管理サーバ

BLADE

L2 SWITCH#0

図 2-3. ネットワーク構成

SIGMABLADE に搭載した 8 台の CPU ブレードには、ネットワーク・インターフェースが 4 つずつあ

り、SIGMABLADE 筐体に内蔵されている 4 台の L2 スイッチに内部的に接続されている。初期状態

で、4 つある NIC がスイッチに連結されており、今回は 1 枚の NIC(Eth0)をパブリックネットワークと

して使用し、2 枚の NIC(Eth1、Eth2)を Active-Standby で bonding し、Oracle Real Application

Clusters で使用するプライベートネットワークとしている。

Public LAN(eth0): 1000Base-TX×1Private LAN(eth1,2): 1000BaseTX×2(Act-Standbyでbonding)

L2 SWITCH#2 L2 SWITCH#1

BLADE

BLADE

BLADE

BLADE

BLADE

BLADE

BLADE

14

5. Database Replay 負荷再現性の確認

以下、Database Replay の検証内容を示す。

5.1. 検証項目

以下の６項目で検証を実施した。

項目①

・ワークロードのキャプチャを行わず、テスト単体のみ実行時とキャプチャ実行時のハードウェア

リソース（user および system の CPU 使用率）使用状況の差異

項目②

・キャプチャ時とリプレイ時のトランザクションの実行時間とスループット*の差異、及び

synchronization パラメ-タの違いによる挙動の変化

項目③

・SQL の発行間隔の違いによる、キャプチャ時とリプレイ時のトランザクションの実行時間とスル

ープット* の変化

項目④

・think_time_scale パラメータの違いによる、キャプチャ時とリプレイ時のトランザクションの実行

時間とスループット*の変化

項目⑤

・think_time_auto_correctパラメータの違いによる、キャプチャ時とリプレイ時のトランザクショ

ンの実行時間とスループット*の変化

項目⑥

・セッション数とキャプチャファイルのサイズの変化、ならびにキャプチャ時間とキャプチャファイ

ルのサイズの変化

*以降、実行時間とスループットをまとめて「挙動」と記述する

5.2. 検証方法

■検証方法

以下に、キャプチャファイル取得からリプレイまでの手順を示す。

①クライアントマシンより、シングルインスタンスの Oracle Database に対してトランザクションを

実行する。その際、DB サーバ側でワークロードの取得を行う。

②キャプチャ処理終了後、キャプチャファイルに前処理を施し、それをクライアントマシンにコピ

ーする。

③DB サーバ上のデータベースに対してフラッシュバック・データベースを実行した後、クライア

ントマシンより、DB サーバに対して、リプレイ処理を実行し、キャプチャ時とリプレイ時の挙動

の変化を確認する。

＊具体的な構成イメージに関しては、「3.検証内容」の「図 3-1.キャプチャ時やリプレイ時でのスル

ープットやハードウェアリソース使用量の差分確認検証」を参照

15

各検証項目の検証方法は以下の通り。

項目①

・テスト単体の実行時間とスループット値、キャプチャ時のトランザクションの実行時間とスループ

ット値を調査する。SQL の実行間隔は 0ms とする。テストプログラムは JPetStore*と StressDWH*

を使用した。

*テストプログラムの詳細は次ページに記述

項目②

・4～40 セッションまで負荷量を変化させ(4 セッションずつセッション数を増やす)、各々のセッション

数でのキャプチャ時のトランザクションの実行時間とスループット、および、リプレイ時のトランザク

ションの実行時間とスループットを調査する。このとき、SQL の実行間隔は 100ms とする。また、リ

プレイ処理時、synchronization パラメータに関しては、true と false の 2 種類のパターンで検証を

行う。リプレイ時、synchronization 以外のパラメータはデフォルトとする。テストプログラムは

JPetStore と StressDWH を使用した。

項目③

・セッション数を 12 セッション、および、40 セッションの 2 通りで固定し、SQL の実行間隔を変化さ

せて、キャプチャ時のトランザクションの実行時間とスループット、および、リプレイ時のトランザク

ションの実行時間とスループットを調査する。セッション数が 12 の時は、SQL の実行間隔を 0ms、

50ms、100ms の 3 通り、セッション数が 40 の時は、100ms、250ms、500ms の 3 通りで検証を行う。

リプレイ時、すべてのパラメータをデフォルトとする。テストプログラムは JPetStore を使用した。

項目④

・セッション数を 4 として、think_time_scale の値を変化させ、挙動の変化を確認する。

リプレイ時、think_time_scale 以外に connect_time_scale を変化させる(詳細については、項目④の

検証結果を参照)。それ以外のパラメータはデフォルトとする。テストプログラムは JPetStore と

StressDWH を使用した。

項目⑤

・セッション数を 4 として、think_time_auto_correct の値を変化させ、挙動の変化を確認する。

リプレイ時、think_time_auto_correct 以外のパラメータはデフォルトとする。

テストプログラムは JPetStore と StressDWH を使用した。

項目⑥

・4～40 セッションまで負荷量を変化させ(4 セッションずつセッション数を増やす)、各々のセッシ

ョン数でのキャプチャファイルのサイズを測定する。また、セッション数を 4 で固定して、キャプチャ

時間を 10 分、30 分、60 分と変化させ、各々の時間でのキャプチャファイルのサイズを確認する。

リプレイ時、すべてのパラメータをデフォルトとする。テストプログラムは JPetStore を使用した。

■検証アプリケーションの説明

16

本検証のテストプログラムとして以下の２つのアプリケーションを使用した。

１．オンライン・トランザクション処理系のアプリケーション(JPetStore)

２．データウェアハウス系のアプリケーション（Stress DWH）

各々のアプリケーションの概要を説明する。

・オンライン・トランザクション処理系のアプリケーション

このアプリケーションはJava言語で記述され、Oracle JDBC OCI Driver 11gを利用してOracleイ

ンスタンスに接続します。接続する同時セッション数、SQLを実行する間隔（Think Time）を調整

して任意のSQLを実行することが可能で、SQL実行後のスループットとレスポンス・タイムを計測

することができる。

データベース・スキーマとSQLは、Webショッピング・サイトを想定した汎用的なOLTP処理を実

装、今回の検証では、Spring Framework で提供されているサンプル・アプリケーションの

JPetStoreを利用した。実行されるアクセス・パターンとそのSQLを本カスタム・アプリケーション

を使って再現させている。

JPetStoreは、Webショッピングを想定したJ2EE Webアプリケーションである。あるユーザーがサ

イト上で商品を検索し、特定の商品を選択し商品カートに追加する。その後注文を確定する。具体

的には以下のシナリオでアプリケーションを作成している。

①ユーザー・サインオン

任意のユーザーIDをランダムに選択し、ユーザー情報を検索。

select … from account, profile, signon

where account.userid=? and signon.password = ? and …;

②商品検索

ランダムに商品検索用のキーワードを生成し、商品を検索。検索結果が平均で100件になる

ように調整。

select … from category where catid = ?;

select … from product where（lower（name）like ?）;

③商品選択

検索してヒットした商品の中から一つのアイテムを選択。

select … from item, product

where i.itemid = ? and …

④在庫数チェック

選択したアイテムの在庫数をチェック。

select … from inventory where itemid = ?

⑤注文

指定した商品の注文データを発行。

insert into orders …;

insert into orderstatus …;

insert into lineitem …;

17

注文した商品アイテムを在庫管理表から注文数の在庫数を減らす。

Update inventory set qty=qty-1 where itemid = ?;

⑥注文確定

Commit;

上記で特筆すべきことは、単一行検索だけではなく、「②商品検索」にあるように100件の

データをフェッチするような複数行検索を含んでいることである。また、更新文もINSERT文が3

つ、UPDATE文が1つで構成されており、トランザクションとしては適度な重さであるといえる

（以降、説明の便宜上 JPetStoreのSQLを使用した本アプリケーションを JPetStore と記述する）

・データウェアハウス系のアプリケーション（Stress DWH）

NEC が作成したカスタム・アプリケーション。このアプリケーションはシェルスクリプト言語で記述し

ている。前処理でテストに必要な環境(ユーザー、表等)を全て作成し、本テストではパラメータで定

めたセッション数を起動する。大規模なミッションクリティカル環境を想定した大量のデータ参照処

理を多重連続*実行している。

*並列度は 20 セッション、SQL 間でのタイムラグなし

SELECT・・・

FROM

(SELECT

・・・・

FROM

テーブル名

WHERE (

・・・・・

)

GROUP BY・・・・・・

WHERE・・・・

パラメータで設定した時間になると、シェルによるテストを自動的に停止する。

18

5.3. 検証結果

項目①

JPetStore を利用してテスト単体のみ実行時（図 5-1）とキャプチャ実行時のハードウェア使用状況

(図 5-2)を以下の２つの図で示す。テスト単体のみ実行した場合と、キャプチャ実行時のハードウ

ェアリソースの使用状況を比較すると、ハードウェアリソースの使用量に殆ど違いがなった。

図 -1 スの PU 図 4-2 キャプチャ時の CPU 使用率 4 テト時 C 使用率

JPetStore を利用してテスト単体のみ実行時とキャプチャ実行時に、DB 領域においてのディスク

I/O 使用状況(図 5-3 並びに図 5-4 参照)とキャプチャファイル生成領域においてのディスク I/O 使

用状況(図 5-5 並びに図 5-6 参照)を以下の 4 つの図で示す。DB 領域のディスク使用量において、

テスト単体のみ実行時とキャプチャ実行時で I/O 使用状況に違いはなかった。一方、キャプチャフ

ァイル生成領域では、キャプチャファイルの生成により、ディスク I/O 使用量が大幅に増加してい

ることがわかる。しかし、図 5-1 並びに図 5-2 から、CPU I/O wait 量に殆ど差が見られないことか

ら、本検証では CPU に対する性能の影響はないものと考えられる。

なお、使用するトランザクション量やキャプチャファイルが作成されるディスクの性能などによって

は、キャプチャファイルを作成によるディスク I/O によって CPU 使用率における I/O wait の割合

が増加し、CPU に対する性能に影響する可能性があることに注意が必要である。

0102030405060708090

100

00 00 4:00 6:00 00 0:00

time(ss:mm)

cpu

usa

ge(%

)

00: 02: 0 0 08: 1

%idle

%iowait

%user%system

0102030405060708090

100

00 2:00 4:00 00 08:00 10:00

time(mm:ss)

cpu

usa

ge(%

) %idle

%iowait

%user%system

00: 0 0 06:

図 5-1 テスト単体のみの CPU 使用率図 5-2 キャプチャ時の CPU 使用率

19

また、キャプチャ時、キャプチャファイルを生成するサーバプロセス（今回は４つ）によるハードウェ

アリソースの使用量を確認すると、テスト単体のみ実行時に比べキャプチャ実行時のハードウェア

リソース使用量は若干増加していることがわかった。

一方、図 5-9 ならびに図 5-10 より、StressDWH を利用したテスト検証では、キャプチャ時に、

I/Owait が発生していることがわかる。StressDWH は JPetStore に比べ、高負荷なため、キャプチ

ャファイル生成のための I/Owait が多発し、user と system 領域の CPU の使用率が低下している

と考えられる。

0

10000

20000

30000

40000

50000

60000

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

rd_sec/s

wr_sec/s

0

10000

20000

30000

40000

50000

60000

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

rd_sec/s

wr_sec/s

図 5-3. テスト単体のみのディスク I/O（DB 領域）図 5-4. キャプチャ時のディスク I/O（DB 領域）

0

2000

4000

6000

8000

10000

12000

14000

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

rd_sec/s

wr_sec/s

0

2000

4000

6000

8000

10000

12000

14000

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

rd_sec/s

wr_sec/s

図 5-5. テスト単体のみのディスク I/O

（キャプチャファイル生成領域）図 5-6. キャプチャ時のディスク I/O

（キャプチャファイル生成領域）

図 5-7 各サーバプロセスによる

CPU 使用量（テスト時）

0

2

4

6

8

10

12

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

CPU

usa

ge (

%)

process1

process2

process3

process4

図 5-8 各サーバプロセスによる

CPU 使用量（キャプチャ時）

0

2

4

6

8

10

12

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

CPU

usa

ge (

%)

%process1

%process2

%process3

%process4

20

010

2030

4050

6070

8090

100

00:00 02:00 04:00 06:00 08:00 10:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

図 5-9 テスト時の CPU 使用率

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00

time(mm:ss)

CPU

usa

ge (

%) %idle

%iowait

%user%system

図 5-10 キャプチャ時の CPU 使用率

項目②

・キャプチャ時とリプレイ時のトランザクションの実行時間とスループットの差異、及び

synchronization パラメータの違いによる挙動の変化

図 5-11 に、synchronization=true でのキャプチャ時のトランザクションの実行時間とスループット、

および、リプレイ時のトランザクションの実行時間とスループットを示す。また、図 5-12 に、

synchronization=falseでのキャプチャ時のトランザクションの実行時間とスループット、および、リプ

レイ時のトランザクションの実行時間とスループットを示す。Synchronization パラメータが true であ

ればキャプチャ時のトランザクション順序をリプレイ時にも保障し、false であれば保障しない。

図 5-11 より、synchronization=true のとき、セッション数が少ない状態では、キャプチャとリプレイ

の実行時間とスループットはほぼ同じ値を示したが、セッション数が増加するに従って、キャプチャ

とリプレイの実行時間とスループットは大きく異なる値を示した。一方、図 5-12 より、

synchronization=false とすると、synchronization=true の場合とは異なり、セッション数が増加して

も、キャプチャ時とリプレイ時の実行時間とスループットに関しては、同程度の値となった。

また、以下に、28 セッションでのキャプチャ時の CPU 使用率(図 5-13)とネットワークのデータ転送

量(図 5-14)、および、28 セッションで、synchronization=true としてリプレイしたときの CPU 使用率

(図 5-15)とネットワークのデータ転送量(図 5-16)、さらに、28 セッションで、synchronization=false と

してリプレイしたときの CPU 使用率(図 5-17)とネットワークのデータ転送量(図 5-18)を示す。

図 5-13 ～図 5-18 のデータより、 synchronization=true でリプレイした場合と、

synchronization=false でリプレイした場合のハードウェアリソースの使用状況を比較すると、

図 5-11. 実行時間とスループット

(synchronization=true)

図 5-12. 実行時間とスループット

(synchronization=false)

0:002:244:48

129:36

12:0014:2416:4819:1221:36

4 8 12 16 20 24 28 32 36 40

session number

tim

e (

mm

:ss)

thro

ugh

put(

tps)

7:

capture time

replay time

capture tps

replay tps

0:002:244:487:129:36

12:0014:2416:4819:1221:36

4 8 12 16 20 24 28 32 36 40

session number

tim

e (

mm

:ss)

thro

ugh

put(

tps)

capture time

replay time

capture tps

replay tps

21

synchronization=false でリプレイを行ったときの方が、キャプチャ時のハードウェアリソースの使用

状況に近いものとなった。

0

5000

10000

15000

20000

25000

30000

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

receiv

e a

mou

nt

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

図 5-14. キャプチャ時のデータ転送量図 5-13. キャプチャ時の CPU 使用

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

0

5000

10000

15000

20000

25000

30000

00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00

time (mm:ss)

receiv

e a

mount

図 5-15. リプレイ時の CPU 使用率図 5-16. リプレイ時のデータ転送量

(synchronization=true) (synchronization=true)

0

5000

10000

15000

20000

25000

30000

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

rece

ive

amoun

t

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

図 5-17. リプレイ時の CPU 使用率図 5-18. リプレイ時のデータ転送量

(synchronization=false) (synchronization=false)

一方、StressDWH では、高負荷な処理を行うため、キャプチャとリプレイの挙動は、

synchronization=true で大きく異なり、synchronization= false で同じになった。以下、キャプチャ

時とリプレイ時（Synchronization パラメータ ture ならびに false の２通り）の実行時間（表 5-1）

ならびにスループット（表 5-2）の結果を示す。尚、以降のスループットは全て係数化された

TPS 値である。

22

表 5-1 実行時間

Capture(mm:ss) Replay(mm:ss)

Synchronization=true Synchronization=false 10:17

37:48 10:27

表 5-2 スループット

Capture(tps) Replay(tps)

Synchronization=true Synchronization=false 100

27.43989 98.81121

以上、項目②の結果として、以下の 2 点が挙げられる。

・セッション数が少ない（データベースへの負荷が小さい）状態では、キャプチャとリプレイの挙

動は同じ

・セッション数が多い（データベースへの負荷が大きい）状態では、キャプチャとリプレイの挙動

は異なる

項目③

図 5-19 にセッション数が 12 で SQL の発行間隔を 0 ms、50 ms、100ms と変化させた時のキャプ

チャ時の実行時間、スループット、および、リプレイ時の実行時間、スループットを示す。

また、図 5-20 に、セッション数が 40 で SQL の発行間隔を 100 ms、250 ms、500 ms と変化させた

時のキャプチャ時の実行時間、スループット、および、リプレイ時の実行時間、スループットを示

す。

これらの図より、12 セッション、40 セッション、共に、SQL の発行間隔が長くなると、トランザクション

時間、スループットに関してキャプチャとリプレイの値が同程度になる傾向が見られた。

図 5-19. 12 セッションでの実行時間と

スループット

0:00

2:24

4:48

7:12

9:36

12:00

14:24

16:48

19:12

0 50 100

SQL think-time (ms)

tim

e (

mm

:ss)

thro

ughp

ut (t

ps)

capture timereplay time

capture tpsreplay tps

0:00

2:24

4:48

7:12

9:36

12:00

14:24

16:48

19:12

100 250 500

SQL think-time (ms)

tim

e (

mm

:ss)

thro

ughp

ut (t

ps)

capture time

replay time

capture tpsreplay tps

図 5-20. 28 セッションでの実行時間と

スループット

23

また、以下に 12 セッションで SQL の発行間隔を 0ms とした時のキャプチャ時の CPU 使用率（図

5-21）とネットワークのデータ転送量(図 5-22)、および、リプレイ時の CPU 使用率(図 5-23)とネット

ワークのデータ転送量(図 5-24)を示す。

これらの図より、CPU 使用率、データ転送量、共に、キャプチャ時とリプレイ時では、

ハードウェアリソースの使用状況が大きく異なっている事がわかる。

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

0

10000

20000

30000

40000

50000

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)re

ceiv

e a

mou

nt

図 5-21. 12 セッションでのキャプチャ時 CPU 使用率図 5-22. 12 セッションでのキャプチャ時データ転送量

(SQL の発行間隔=0ms) (SQL の発行間隔=0ms)

0

20

40

60

80

100

00:00 04:00 08:00 12:00 16:00

time (mm:ss)

CP

U u

sage

(%) %idle

%iowait

%user%system

0

10000

20000

30000

40000

50000

00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00

time (mm:ss)

receiv

e a

mount

図 5-23. 12 セッションでのリプレイ時 CPU 使用率図 5-24. 12 セッションでのリプレイ時データ転送量

(SQL の発行間隔=0ms) (SQL の発行間隔=0ms)

さらに、12セッションでSQLの発行間隔を100msとしたときのキャプチャ時のCPU使用率(図5-25)

とネットワークのデータ転送量(図 5-26)、および、リプレイ時の CPU 使用率(図 5-27)とネットワーク

のデータ転送量(図 5-28)を以下に示す。

これらの図から、SQL の発行間隔が 100ms の場合、SQL の発行間隔が 0ms の場合を比較する

と、キャプチャ時とリプレイ時のハードウェアリソースの使用状況に関しては、若干の差異は存在

するものの、同じような使用状況となっている。

24

図 5-25. 12 セッションでのキャプチャ時

CPU 使用率(SQL の発行間隔=100ms)

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CPU

usa

ge (

%) %idle

%iowait

%user%system

図 5-26. 12 セッションでのキャプチャ時

データ転送量(SQL の発行間隔=100ms)

0

2000

4000

6000

8000

10000

12000

14000

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

recei

ve a

mount

図 5-27. 12 セッションでのリプレイ時

CPU 使用率(SQL の発行間隔=100ms)

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CPU

usa

ge (

%) %idle

%iowait

%user%system

図 5-28. 12 セッションでのリプレイ時

データ転送量(SQL の発行間隔=100ms)

0

2000

4000

6000

8000

10000

12000

14000

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

rece

ive

amoun

t

以上、項目③の結果として、以下の点が挙げられる。

12 セッション、40 セッション、共に、SQL の発行間隔が短くなるとキャプチャとリプレイの挙動が異

なる

※synchronization=true の場合、起動したセッション数に関係無く、データベースへの負荷が高

くなると、キャプチャとリプレイの挙動が異なる

項目④

think_time_scale パラメータの違いによる、キャプチャ時とリプレイ時のトランザクション時間とスル

ープットの変化

think_time_scaleは、リプレイ時に同一のセッションにおいて実行されるSQL発行間隔のスケール

を％で制御するパラメータである。以下に、4 セッションでキャプチャを行い、think_time_scale=100、

および、think_time_scale=0 としてリプレイしたときの実行時間(表 5-3)とスループット(表 5-4)を示す。



think_time_scale=100 think_time_scale=0 11:29

11:42 11:42

25



think_time_scale=100 think_time_scale=0 100

98.3524 98.3524

この結果より、実行時間、スループット、ともに、think_time_scale=100、think_time_scale=0 のリプレ

イ結果が同一のものとなった。

ここで、図 5-29 にthink_time_scale=100 でのCPU使用率を、図 5-30 にthink_time_scale=0 でのCPU

使用率を示す。

図 5-29 においては、リプレイ時間(11 分 42 秒)に対してCPU使用時間が、ほぼ同一であるのに対

し、図 5-30 においては、リプレイ時間(11 分 42 秒)に比べて、CPU使用時間が約 8～9 分と短くな

っている。これは、think_time_scale=0 の場合、トランザクション自体は約 8～9 分で終了した後、セ

ッションの新規接続が発生したために、リプレイが終了しなかったと考えてられているが、現在、詳

細は調査中である。

そこで、think_time_scale=0 でconnect_time_scale=0、および、connect_time_scale=100 としてリプレ

イを行った場合の実行時間を表 5-5、スループットを表 5-6 に示す。connect_time_scaleは、リプレ

イ時にセッションの接続間隔のスケールを％で指定するパラメータである。

この結果より、think_time_scale=0 でconnect_time_scale=0 とすることにより、リプレイ時間が短縮さ

れ、それに伴ってスループットも増加したことがわかる。

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CPU

usa

ge (

%) %idle

%iowait

%user%system

0

20

40

60

80

100

00:00 02:00 04:00 06:00 08:00 10:00 12:00

time (mm:ss)

CPU

usa

ge (

%) %idle

%iowait

%user%system

図 5-29. think_time_scale=100 での CPU 使用率図 5-30. think_time_scale=0 での CPU 使用率



connect_time_scale=100 connect_time_scale=0

(think_time_scale=0) (think_time_scale=0) 11:29

11:42 8:03

26



connect_time_scale=100 connect_time_scale=0

(think_time_scale=0) (think_time_scale=0) 100

98.3524 142.6545

一方、StressDWH では、think_time_scale パラメータの違いによる、キャプチャ時とリプレイ時のトラ

ンザクションの実行時間とスループットの差異はなかった。StressDWH の SQL の発行間隔は非常

に短いため、think_time_scale パラメータの調整による効果が見られなかったと考えられる。以下、

キャプチャ時とリプレイ時（think_time_scale パラメータ 0 ならびに 100 の２通り）の実行時間（表

5-7）ならびにスループット（表 5-8）の結果を示す。



think_time_scale=0 think_time_scale=100 10:17

37:44 37:48



think_time_scale=0 think_time_scale=100 100

27.48399 27.43989

項目⑤

think_time_auto_correctパラメータの違いによる、キャプチャ時とリプレイ時におけるトランザクショ

ンの実行時間の変化

以下の表に、4 セッションでthink_time_auto_correct=trueとして実行したときの実行時間(表 5-9)と

スループット(表 5-1０)を示す。

think_time_auto_correct=trueの場合、キャプチャ時間が 11 分 29 秒に対して、リプレイ時間は 11

分 42 秒であり、think_time_auto_correct=falseの場合、キャプチャ時間が１1 分 29 秒に対してリプレ

イ時間は、12 分 7 秒となった。

また、スループットに関しては、キャプチャ時のTPSが 100 に対して、リプレイ時のTPSは、

think_time_auto_correct=trueの場合、98.3524 であり、think_time_auto_correct=falseの場合は、

94.87414 となる。

27

以上の結果、think_time_auto_correctがtrueとfalseの場合を比較すると、trueの方が若干SQLの発

行間隔が自動調節された結果全体のリプレイ時間が短くなり、キャプチャ時間との差が小さくなっ

ていると考えられる。



think_time_auto_correct=true think_time_auto_correct=false11:29

11:42 12:07



think_time_auto_correct=true think_time_auto_correct=false100

98.3524 94.87414

一方、StressDWHでは、think_time_auto_correctパラメータの違いによる、キャプチャ時とリプレイ

時のトランザクションの実行時間とスループットの大きな差異はなかったが、

think_time_auto_correct が ture の場合の方が false の場合よりリプレイの実行時間が若干長く

なっている。分析の結果、これはStressDWHのSQL発行間隔が非常に短いことに起因した動作と

判明した。この様な特性をもつワークロードに対しても think_time_auto_correctパラメータを利用し

た場合に、より忠実度の高いリプレイを行うため、将来のパッチセットに改良が含予定となってい

る。以下、キャプチャ時とリプレイ時（think_time_auto_correctパラメータ trueならびに falseの２通

り）の実行時間（表 5-11）ならびにスループット（表 5-12）の結果を示す。



think_time_auto_correct=true think_time_auto_correct=false10:17

37:48 36:36



think_time_auto_correct=true think_time_auto_correct=false100

27.43989 28.33531

28

項目⑥

セッション数とキャプチャファイルのサイズの変化、ならびにキャプチャ時間とキャプチャファイル

のサイズの変化

図 5-31 に、セッション数とファイルサイズの関係を示す。この図より、セッション数が増加する、即

ち、負荷量が増加するに従って、キャプチャ時のファイルサイズも増加している事がわかる。

また、図 5-32 に、実行時間とファイルサイズの関係を示す(セッション数は 4 で固定)。この図より、

実行時間の増加と共に、ファイルサイズも大きくなっている。

図 5-31 で 36 セッションから 40 セッションの伸びが小さいのは、36 セッション実行時点におい

て CPU をほぼ消費しきっていいたためと考えられる。

これらの結果より、ファイルサイズは負荷量と実行時間に比例して増加していると言える。

図 4-32. 実行時間とファイルサイズの関係

0

200

400

600

800

1000

1200

1400

0 10 20 30 40 50 60 70

time (minute)

file

size

(M

byte

)

0

500

1000

1500

2000

4 8 12 16 20 24 28 32 36 40

session number

file

size

(M

byte

)

図 4-31. セッション数とファイルサイズの関係

5.4. まとめ

項目①の結果より、キャプチャファイルの生成により I/Owait が発生することが確認できた。また、

トランザクションの負荷量が大きい場合、I/Owait の割合が増加すると考えられる。

項目②と項目③の結果より、キャプチャ時とリプレイ時の挙動の変化について、差異が発生する

原因となるのは、実行されるトランザクションの負荷量であると考えられる。

項目④、項目⑤の結果より、リプレイ時にパラメータを変化させる事によって、リプレイの状態を任

意に変化させる事が可能と考えられる。

項目⑥の結果より、キャプチャファイルは、負荷量、および、トランザクションの実行時間が増加す

るに従ってファイルサイズが大きくなる。またファイルサイズは、今回の検証に関して、数百 Mbyte

から数 Gbyte となるため、ディスクの空き容量を十分に確保する必要がある。

29

6. Database Replay と他機能との組み合わせ時の動作確認 1 (TDE との組み合わせ)

本章では、TDE による暗号化機能と、Database Replay によるキャプチャ・リプレイを組み合わせた

際に、ハードウェアリソースの使用量に想定外の性能劣化が起こっていないかどうかを確認する

ことを目的とした検証の結果について報告する。

Database Replay の特性については前章で述べた通りだが、本機能と TDE を組み合わせた場合、

本章で述べた結果を踏まえ、TDE を使用する際の指針になればと考える。

6.1. 検証項目

下記のパターンで、ワークロードのキャプチャ・リプレイを行い、リプレイ時間、スループット、CPU

使用率、ディスク I/O の値を採取し、比較を行う。

項目①

非暗号化状態でキャプチャ

1-1 表を非暗号化状態にしてリプレイ

1-2 暗号化を行った状態でリプレイ

項目②

TDE によるデータの暗号化を行った状態でキャプチャ

2-1 表を非暗号化状態にしてリプレイ

2-2 暗号化した状態でリプレイ

6.2. 検証方法

・本検証での検証方法は、「4. Database Replay 動作検証」での検証方法と同様に、JPetStore ス

クリプトによるトランザクションを実行し、キャプチャファイルの取得を行う。サーバ側でキャプチャ

ファイルの前処理を行い、フラッシュバック・データベースを実行した後、リプレイを行う。

「4. Database Replay 動作検証」と異なる点は、キャプチャの取得前、または、リプレイ前に TDE に

よるデータの暗号化を行うことである。

項目①の検証方法

・JPetStore でアクセスされる ORDERS 表の特定の列を TDE により暗号化する。今回は実際の運

用で暗号化されることが多いと考えられる、顧客のクレジットカード番号を保持する CREDITCARD

列を暗号化した。項目①ではキャプチャ時に暗号化を行わず、JPetStore によるトランザクションを

セッション数 12、実行間隔 100ms で実行し、キャプチャファイルの取得を行った。リプレイケースは

(1-2) 非暗号化状態でリプレイ

(1-1) 表を暗号化してリプレイ

の 2 つのケースで検証を行った。4 章と同様にキャプチャ時、リプレイ時のスループットを採取し、

TDE による影響が出る可能性のある CPU 使用率、ディスク I/O の値を sar コマンドで取得し、比較

した。ディスク I/O の値は、データファイルの格納してあるディスク領域の値を取得した。

30

リプレイパラメータは全て、デフォルト値に設定し、暗号化アルゴリズムはデフォルトの AES192 を

使用した。

項目②の検証方法

・項目②では、キャプチャ時に暗号化を行い、リプレイパターンとして

(2-1) 非暗号化状態でリプレイ

(2-2) 表を暗号化してリプレイ

の 2 つのケース(2-1、2-2)でリプレイを行った。キャプチャ時、リプレイ時のスループット、CPU 使用

率、ディスク I/O の値を採取し、比較した。なお、リプレイパラメータは、全てデフォルト値に設定し

実行した。

6.3. 検証結果

項目①の結果

キャプチャ、リプレイ(1-1、1-2)の実行時間を表 6-1 に、スループットの比較を表 6-2 に示す。尚、

以降のスループットは全て係数化された TPS 値である。

表 6-1. リプレイ時間（キャプチャ時非暗号化）

Replay (mm:ss) Capture (mm:ss)

1-1 no encrypt 1-2 encrypt

11:35 12:01 11:51

表 6-2. スループット（キャプチャ時非暗号化）

Replay (tps) Capture (tps)


100 96.39135 97.63571

表 6-1 より、キャプチャ時間に比べ、リプレイ時間が 1-1 のケースでは、26 秒、1-2 のケースでは

16 秒増加している。また、表 6-2 より、スループットは、キャプチャ時に 100、リプレイ 1-1 で

96.39135、1-2 では 97.63571 という結果になった。

リプレイケース 1-1 では、キャプチャ・リプレイ時共に、暗号化を行っていないため、Database

Replay のみを実行した際の性能を計測することができる。そのため、以降の検証パターンと比較

し、組み合わせによる性能変化を調べる際の基準とすることができる。

暗号化を行った環境でリプレイを実行した 1-2 の結果では、キャプチャ時に比べ、リプレイ時間が

増加し、それに伴いスループットの低下が見られる。しかし、これはキャプチャ・リプレイ時に TDE

による暗号化を行っていないケース 1-2 と比較しても、ほぼ同程度の時間増加、スループット減少

量であるため、上記結果が TDE との組み合わせによる影響でないことがわかる。また、ここで見ら

れるリプレイ時の性能劣化は、Database Replay 固有の現象で、4 章図 5-12 のグラフで多重度 12

以前でもわずかにリプレイ時間が延びていることに相当する。

31

図 6-1、6-2、6-3 にそれぞれ、キャプチャ時、非暗号化状態のリプレイ時(1-1)、暗号化したリプレ

イ時（1-2）の CPU 使用率を示す。

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-1. CPU 使用率（キャプチャ時非暗号化）

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-2. CPU 使用率（1-1 リプレイ時非暗号化）

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-3. CPU 使用率（1-2 リプレイ時暗号化）

図 6-1、と 6-2 を比較すると、キャプチャ時に比べ、リプレイ時のグラフは、CPU 使用率が、時々大

きく低下する現象(例：図 6-2 2:00 あたり)が確認できる。これは、4 章項目②で確認された

Database Replay 固有の挙動であることがわかる。図 6-2、6-3 を比較するとリプレイ同士のグラフ

傾向に大きな差異がないことが確認できた。

ディスク I/O については、図 6-4、6-5、6-6 のようになり、リプレイ時、キャプチャ時でのグラフ傾向

に差は見られなかった。

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:0 12:0

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-4.ディスク使用量（キャプチャ時非暗号化）

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-6.ディスク使用量（1-2 リプレイ時暗号化）

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-5.ディスク使用量（1-1 リプレイ時非暗号化）

32

リソースの消費量については、CPU 使用率、ディスク I/O の read/write の平均値*を表 6-7、6-8

にそれぞれ示した。

*平均は、JPetStore の開始を確認してから 180 秒後を起点とし、300 秒間の値を採用した。

表 6-3. CPU 使用率の平均値（キャプチャ時非暗号化）

Replay (%) Capture (%)


41.03 40.29 42.55

表 6-4. ディスク使用量の平均値（read/write）（キャプチャ時非暗号化）

Replay (sec/s) Capture (sec/s)


8943.49 / 1285.78 7789.56 / 1208.41 7971.20 / 1255.53

表 6-3 より、ケース 1-1、1-2 の CPU 使用率の差を見ると 2.26%であり、表 6-4 よりディスク使用量

の差は、read は 183.44、write は 47.12 で、それぞれ全体の 2.3%、3.7%とごく小さく、誤差の範囲で

あると言える。

また、表 6-4 のキャプチャ時の値と 1-1 の値を比較すると、キャプチャ時に比べてリプレイ時のディ

スク I/O の値が下がっていることがわかるが、1-1 は TDE を利用していないケースであるため、こ

の結果より、リプレイ時にディスク I/O の値が低下する現象は Database Replay 固有の現象である

と言え、キャプチャ時と比べ、リプレイ 1-2 で見られる値の低下も TDE との組み合わせによる値の

低下でないことがわかる。

項目②の結果

リプレイ時間と、スループットを比較した表を以下に示す。

表 6-5. リプレイ時間（キャプチャ時暗号化）

Replay (mm:ss) Capture (mm:ss)


11:36 11:57 12:02

表 6-6. スループット（キャプチャ時暗号化）

Replay (tps) Capture (tps)


100 97.05606 96.46101

33

表 6-5 より、暗号化を解除した 2-1 のケースでは、キャプチャ時間に比べてリプレイ時間が 21 秒

増加している。暗号化状態でリプレイを行った 2-2 のケースでは 26 秒増加している。

また、表 6-6 より、リプレイ時間の増加により、スループットは、キャプチャ時の 100 に対して、リプ

レイ 2-1 では 97.05606、リプレイ 2-2 では 96.46101 と、どちらもスループットが減少していることが

わかる。

このキャプチャ・リプレイ間の時間増加、スループットの減少は、項目①で述べた、Database

Replay 固有の現象であると考えられる。また、2-1、2-2 のリプレイ同士を比較した場合にも、リプ

レイ時間、スループットに顕著な差は見られなかった。

図 6-7、6-8、6-9 にそれぞれ、キャプチャ時、非暗号化状態のリプレイ（2-1）、暗号化状態のリプ

レイ(2-2)の CPU 使用率を示す。

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-7. CPU 使用率（キャプチャ時暗号化）

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-8. CPU 使用率（2-1 リプレイ時非暗号化）

図 6-9. CPU 使用率（2-2 リプレイ時暗号化）

0%

20%

40%

60%

80%

100%

0:00 2:00 4:00 6:00 8:00 10:00 12:00

time(mm:ss)

%idle

%iowait

%user%system

図 6-7、6-8、6-9 についてそれぞれ、CPU 使用率を比較したところ、キャプチャ時に比べ、リプレイ

時(2-1、2-2)の CPU 使用率に、ところどころ大きく落ち込む現象が見られたが、これは、項目①で

も述べた Database Replay 固有の現象であると考えられる。

また、図 6-10、6-11、6-12 より、キャプチャ時、リプレイ時のディスク使用量を示すグラフは以下の

ようになっており、キャプチャ・リプレイ時で同じ傾向を示していることがわかる。

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:0 12:0

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-10.ディスク I/O（キャプチャ時暗号化）

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:0 12:0

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-11.ディスク I/O（2-1 リプレイ時非暗号化）

34

0

10000

20000

30000

40000

50000

60000

0:00 2:00 4:00 6:00 8:00 10:0 12:0

time(mm:ss)

rd_sec/s

wr_sec/s

図 6-12.ディスク I/O（2-2 リプレイ時暗号化）

CPU 使用率、ディスク I/O のブロック数の平均値*を算出したところ表 6-7、6-8 のようになった。

*平均は、JPetStore の開始を確認してから 180 秒後を起点とし、300 秒間の値を採用した。

表 6-7. CPU 使用率の平均値（キャプチャ時暗号化）

Replay (%) Capture (%)


39.30 40.59 41.58

表 6-8. ディスク使用量の平均値 (read/write) （キャプチャ時暗号化）

Replay (sec/s) Capture (sec/s)


7550.31 / 1294.29 7377.27 / 1279.27 7430.70 / 1211.95

表 6-7 より、CPU 使用率は、キャプチャ時、リプレイ時共に 40%程度で、それぞれの差は誤差の範

囲内と言える。ディスクの使用量については、表 6-8 より、リプレイ時に比べ、キャプチャ時の使用

量が read、write 共に、2-1、2-2 のケースでどちらも低くなっている。

表 6-7 より、リプレイ時（1-1、1-2）の CPU 使用率を比較した場合、値の差は 0.99%であった。表

6-8 より、ディスク使用量の差も read が 53.43、write が 67.32 であり、それぞれ全体の 0.7%、5.2%

程度となっており、CPU 使用率、ディスク使用量の差異は誤差の範囲内であると言える。

6.4. まとめ

■TDE 固有の負荷量増加について

通常、TDE で列の暗号化を行った場合、非暗号化の状態でアクセスした場合に比べて CPU 負荷

量の増加が発生する。しかし、TDE を用いることによる性能劣化は、トランザクションの特性、暗号

化する列数、暗号化アルゴリズムなどの条件によって異なってくる。参考までに、NEC で TDE の性

能検証を行った際の、CPU 使用率の比を表すグラフを図 6-12 に示す。図 6-12 は非暗号化時の

CPU 使用率に対して、暗号化時の CPU 使用率の割合を示している。

35

0.00

1.00

2.00

3.00

4.00

INSERT

SELECT

UPDATE

DELETE

20

2000

4000

AES192

+ salt

AES128

+ salt

3DES168

+ salt

AES192

+ no salt

varchar2

raw

1列 2列 5列

倍率

（暗

号化

/非

暗号

化）

SELECT処理における結果

SQL文カラムサイズ[byte] 暗号化アルゴリズムデータ型列数

図 6-12. CPU 使用率の比

今回検証で使用した JPetStore のトランザクションでは、INSERT、SELECT、UPDATE、DELETE が

混在した状態で発行され、アルゴリズムは AES192＋salt を用い、暗号化した列数は 1 列であった。

今回の条件では、TDE の暗号化にかかる負荷としては非常に小さく、誤差の範囲に吸収される。

そのため、純粋に TDE と Database Replay を組み合わせたときに性能劣化が発生しているかを確

認することができる。

■総括

項目①の結果より、暗号化されていない表を持つ DB で、ワークロードのキャプチャを行い、

Database Replay 機能を用い暗号化された DB でリプレイを行った際に、組み合わせによる性能劣

化は起こらないことが確認できた。

項目②の結果より、TDE により暗号化された DB でキャプチャを行い、Database Replay 機能でワ

ークロードのリプレイを行っても、組み合わせによる性能劣化は起こらないことが確認できた。

本検証によって、Database Replay と TDE を組み合わせたことによる、想定外の挙動、顕著な性能

劣化は起こらないことが確認できた。よって、テスト環境を使い TDE による暗号化、非暗号化をテ

ストする際も Database Replay を利用することができると考える。

今回は、TDE による負荷が小さい場合での組み合わせによる性能差を検証したが、今後の課題

として、TDE での負荷が大きいとき、Database Replay によるリプレイ時に与える影響を検証する必

要があると考える。

36

7. Database Replay と他機能との組み合わせ時の動作確認 2 (RAC との組み合わせ)

Database Replay の使用において、ワークロードをキャプチャする環境とリプレイする環境が別の

データベースであれば、リプレイ時にはテスト環境を接続先として再指定する必要がある。特に

Oracle Real Application Clusters 環境では、ノード数の変更や各 Oracle インスタンスへの接続配

分への考慮が必要な場合も考えられる。Database Replay では、これらの接続の制御操作が再マ

ップ機能として提供されている。本検証では再マップの動作確認のため、Oracle Real Application

Clusters（以下 RAC）環境で、サーバー・サイド・ロード・バランシングが設定された状態でワークロ

ードをキャプチャし、リプレイするとどのインスタンスへ接続するのかを以下２つの仮説を立て検証

した。

• ワークロードのキャプチャ時と同一 Oracle インスタンスへ接続

• 各インスタンスへランダムに接続

7.1. 検証項目

以下の３点の検証を実施した。

1. 全ての接続に対し単一の接続記述子、または TNS ネット・サービス名を再マップ

2. ワークロードでキャプチャ済の各クライアント接続記述子に対して、個別の接続記述子また

は、ネット･サービス名を使用して再マップ

3. 接続の再マップを行わない

7.2. 検証方法

各ホスト上の Oracle インスタンス、クライアントマシンの対応は、下表に示す通りである。キャプチ

ャ時の負荷生成は n0c-12 から行い、リプレイ・クライアントとしては n0c-15 を使用した。

ホスト名インスタンス名内容

(INST_ID)

n0c-12 N/A 負荷生成ツールのクライアントマシン

rat1 (1) n0c-15 クラスタ・データベース rat を構成するインスタンスリプレイ・クライアント

rat2 (2) n0c-16 クラスタ・データベース rat を構成するインスタンス



表 7-1. 使用ホストの Oracle インスタンスおよびクライアントマシンの対応

検証手順は、次に示す通りである。

1. ワークロードのキャプチャ

2. リプレイ・データの初期化

3. 接続の再マップ

4. ワークロードのリプレイ

37

2.～4.の手順はワークロードのリプレイには、Oracle Enterprise Manager 11g Database Control (以

降、Oracle Enterprise Manager) を用いる方法と DBMS_WORKLOAD_REPLAY プロシージャを用い

る方法の２つがある。今回の検証では双方を用いた。以下、各手順について記述する。

1. ワークロードのキャプチャ

負荷生成ツールを起動させるクライアントマシン n0c-12 より 4 つのセッションを作成し、

RAC を構成する 4 つの Oracle インスタンスのうちどの Oracle インスタンスへ接続するのか

を gv$session ビューより確認した。tnsnames.ora ファイルには、接続記述子 RAT1 につい

て以下のように記述されている。この RAT1 を用いて、クライアントマシンから RAC へ接続

する。

RAT1 =

(DESCRIPTION =

(ADDRESS_LIST =(LOAD_BALANCE = yes)

(ADDRESS = (PROTOCOL = TCP)(HOST = n0c-15-vip)(PORT = 1521))




)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = rat))

)

クライアントからのリクエストは ADDRESS_LIST 下の 4 つのリスナーへランダムに振り分

けられた後、サービス rat へ登録済みのいずれかの Oracle インスタンスへリダイレクト

される。

2. リプレイの初期化

リプレイの初期化を行う。

3. 接続の再マップ

接続の再マップでは、リプレイ時のデータベースへの接続の制御を行う。

ここで行う操作には大きく分けて次の 3 つがある。

• 全ての接続に単一の接続記述子、または TNS ネット・サービス名を再マップ。

リプレイ時のセッションは全て単一の接続情報を元に作成される。接続情報は、接続

記述子を直接入力する方法と TNS ネット・サービス名を指定する方法がある。本検証

では、以下の接続記述子、 TNS ネット・サービス名を使用する再マップを実施した。

38

rat =

(DESCRIPTION =






)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = rat))

)

SV2 =

(DESCRIPTION =






)

(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = sv2))

)

• 各々の接続に対し、接続記述子、または TNS ネット・サービス名を再マップする。

リプレイの初期化を行うと、ワークロードのキャプチャ中に本番システムに接続された

各ユーザー・セッションに ID が振られ、接続した Oracle インスタンスへの接続文字列

と共に DBA_WORKLOAD_CONNECTION_MAP ビューに格納される。これらの接続文

字列をユーザーセッションごとに明示的に指定して接続記述子、または TNS ネット・サ

ービス名を再マップすることが可能である。本検証では、この機能を使用して、キャプ

チャ時とリプレイ時で同一の Oracle インスタンスに接続するように再マップを行った。

• 再マップを行わない。つまり、再マップを行わずに次の「ワークロードのリプレイ」に進

む。DBMS_WORKLOAD_REPLAY パッケージを用いるときのみ、再マップを行わない

リプレイを行うことができる。

4. ワークロードのリプレイ

リプレイを開始し、作成されたセッションの接続先インスタンスを gv$session ビューより

確認した。

以降、再マップ方法を変えながら、項番 3 ならびに 4 を繰り返し実施した。

また、検証の際、リスナーが検知していたサービスの内容は次に示す通りである。サービス

RAT にはインスタンス rat1 ～ rat4 が登録されており、サービス SV2 には rat3 , rat4 が

登録されていることが分かる。図 7-1.にて概要（イメージ図）を示す。

39

09:45:49 oracle@n0c-15(rat1)$ lsnrctl services

LSNRCTL for Linux: Version 11.1.0.6.0 - Production on 12-12 月-2007 09:45:53

Copyright (c) 1991, 2007, Oracle. All rights reserved.

(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))に接続中

サービスのサマリー...

...(中略)...

サービス"rat"には、4件のインスタンスがあります。

インスタンス"rat1"、状態 READY には、このサービスに対する 2 件のハンドラがあります...

ハンドラ:

"DEDICATED" 確立:0 拒否:0 状態:ready

REMOTE SERVER

(ADDRESS=(PROTOCOL=TCP)(HOST=n0c-15)(PORT=1521))


LOCAL SERVER


ハンドラ:


REMOTE SERVER



ハンドラ:


REMOTE SERVER



ハンドラ:


REMOTE SERVER


...(中略)...

サービス"sv2"には、2件のインスタンスがあります。


ハンドラ:


REMOTE SERVER



40

ハンドラ:


REMOTE SERVER


コマンドは正常に終了しました。

rat4R

AT

SV2

rat1

rat3

rat2

n0c-15

n0c-16

n0c-17

n0c-18

n0c-15

図 7-1. マシン構成とサービス配置

7.3. 検証結果

1. 全ての接続に対し単一の接続記述子、または TNS ネット・サービス名を再マップ

全ての接続に対し、単一の接続記述子を再マップしてリプレイを行った結果は次の通り

である。リプレイの時に使用した接続記述子はワークロードキャプチャ時と同一だが、

サーバー・サイド・ロード・バランシングの動作によって、ワークロードのキャプチャ時とリ

プレイ時で Oracle 接続するインスタンスは同一になっていないことが分かる。

41

SELECT INST_ID, SID, SERIAL#, USERNAME, LOGON_TIME, PROGRAM, MACHINE FROM GV$SESSION

WHERE USERNAME ='JPETSTORE' ORDER BY INST_ID, USERNAME, LOGON_TIME;

（ワークロードキャプチャ時）

INST_ID SID SERIAL# USERNAME LOGON_TIME PROGRAM MACHINE

------- --- ------- ---------- -------------- ----------------------- -------

1 106 2386 JPETSTORE 19:42:57 12/10 java@n0c-12 (TNS V1-V3) n0c-12




（ワークロードのリプレイ時）


------- ----- ------- ---------- -------------- ---------------------- --------

1 95 18429 JPETSTORE 16:59:40 12/11 wrc@n0c-15 (TNS V1-V3) n0c-15




次に、TNS ネット・サービス SV2 を再マップしてリプレイを行った結果は以下の通りであ

る。





------- --- ------- ---------- -------------- ----------------------- -------







------- ----- ------- ---------- -------------- ---------------------------- --------





42

以上より、単一のサービス名を指定すると、そのサービスへ登録済みのインスタンスへ

接続されることが分かる。また、ワークロードのキャプチャ時に接続したインスタンスが、

再マップ時に指定したサービスに含まれていなくても、エラーにはならないことが確認で

きた。なお、Oracle Enterprise Manager を用いる方法と DBMS_WORKLOAD_REPLAY プ

ロシージャを用いる方法で結果は同じであった。

2. ワークロードでキャプチャ済の各クライアント接続記述子に対して、個別の接続記述子または

ネット･サービス名を使用

リプレイ・クライアントが各接続に対し、ワークロードのキャプチャ時と同じ接続記述子を

それぞれ再マップした。ワークロードキャプチャ時に用いられた接続記述子は

DBA_WORKLOAD_CONNECTION_MAP ビューより取得した。リプレイ初期化後の

DBA_WORKLOAD_CONNECTION_MAP ビューの出力は以下の通りである。REPLAY_ID

列はリプレイ操作に対して固有な ID を、CONN_ID 列はリプレイ時に作成される各接続に

固有の ID を、CAPTURE_CONN 列はワークロードキャプチャ時に用いた接続記述子を、

REPLAY_CONN 列はリプレイで使用すべき接続記述子を示す。REPLAY_CONN 列は再

マップ実行後に値が入る。

43

REPLAY_ID CONN_ID CAPTURE_CONN REPLAY_CONN

--------- ------- -------------------------------------------------- -----------

528 1 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=n0c-15-v

ip)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SE

RVICE_NAME=rat)(CID=(PROGRAM=java@n0c-12)(HOST=n0c

-12)(USER=oracle))))



RVICE_NAME=rat)(CID=(PROGRAM=java)(HOST=n0c-12)(US

ER=oracle))(INSTANCE_NAME=rat1)))













DBA_WORKLOAD_CONNECTION_MAP ビューの出力と同等の情報は Oracle

Enterprise Manager の画面からも取得可能である。結果は次に示すとおりでワークロー

ドキャプチャ時と同一の接続記述子を再マップしたところワークロードのキャプチャ時と

同一のインスタンスへリプレイ時も接続された。また、Oracle Enterprise Manager を用い

る方法と DBMS_WORKLOAD_REPLAY プロシージャを用いる方法では結果は同じであっ

た。

44





------- --- ------- ---------- -------------- ----------------------- -------







------- ----- ------- ---------- -------------- ---------------------------- --------





3. 接続の再マップを行わない場合

DBMS_WORKLOAD_REPLAY パッケージを用いるときのみ、接続の再マップを行わず

リプレイすることができる。この場合は次に示すとおり、DBMS_WORKROAD_REPLAY パ

ッケージを実行しリプレイ・クライアントを起動したマシン上の Oracle インスタンスに接続

する。

45





------- --- ------- ---------- -------------- ----------------------- -------







------- ----- ------- ---------- -------------- ---------------------- -------





7.4. まとめ

本検証により、サーバー・サイド・ロード・バランシングが有効になった状態でワークロードをキャ

プチャしリプレイを行うと、リプレイ時もロードバランシングの設定に基づき接続先 Oracle インスタ

ンスは分散されることがわかった。

接続の再マップを行うことにより、リプレイ時に任意の接続先 Oracle インスタンスを指定できる。

リプレイ時の接続先 Oracle インスタンスの指定方法として、単一の Oracle インスタンスを指定でき

ることはもちろん、複数の Oracle インスタンスが登録されているサービスを指定することもできる。

前者は、リプレイ時もワークロードのキャプチャ時と同一の Oracle インスタンスへ接続させたいと

きに便利である。後者は、4 ノードでキャプチャしたワークロードを、２ノードでサーバー・サイド・ロ

ード・バランシングが有効な環境でリプレイしたいなど、ワークロードのキャプチャ環境とリプレイ環

境のノード数が異なる場合などに便利である。

46

8. SQL Performance Analyzer 有効性の確認

本章では、 Oracle Real Application Testing のもう一つの機能である SQL Performance

Analyzer(以下、SPA)の検証結果について報告する。SPA を利用することで、構成変更の前後に

おける実行計画や SQL の性能の変化を確認することが可能となる。また、SPA を実行する際には

SQL Tuning Set(以下、STS)を使って取得された SQL を利用することにより、本番環境で実行され

ているリアルな SQL をテスト環境で再実行することが可能となる。

本検証では、STS 取得における性能特性と、SPA の機能の特長を、Oracle GRID Center で利用さ

れるアプリケーションを使って確認した。

8.1. 検証項目

以下の３点の検証を実施した。

1. SQL Tuning Set 取得のオーバーヘッド

SPA で利用される STS とは、ある環境で指定された期間中に実行される SQL 文やその実行

時の統計情報等を含むオブジェクトである。STS は Oracle Database 10g Release 2 より実装

された機能で、STS を本番環境で取得することにより、簡単に実行計画や統計情報を確認す

ることが可能となる。SPA では、STS に格納されている SQL を利用し、テスト環境で同じ SQL

を再生することができる。

STS の取得期間中は、実行された SQL 文や統計情報を保存する処理により、データベース

サーバに対して H/W リソース使用量やスループットに対するオーバーヘッドが発生する可能

性が考えられる。そこで、まずはこのオーバーヘッドが存在するのかどうかについて検証し

た。


SPA を利用することで、テスト環境において構成変更適用の前後で SQL の実行計画や性能

の変化を確認することが可能である。テスト可能な構成変更には、初期化パラメータの変更、

索引作成やパーティショニング適用などのスキーマ変更、H/W の構成変更データベースのア

ップグレード等が含まれる。SPA 有効性確認の検証では、初期化パラメータの変更とスキー

マの変更について検証を行った。

初期化パラメータの変更については、Oracle Enterprise Manager 11g Database Control（以

下、Oracle Enterprise Manager）を利用することで、変更適用前テスト、初期化パラメータの変

更、変更適用後テスト、レポーティングの作業を全て自動化することが可能である。

スキーマの変更等のテストについては、Oracle Enterprise Manager でテストをステップ実行す

ることが可能である。ステップ実行の場合には、変更前テストと変更後テストを任意のタイミン

グで実行することができるため、その間に環境変更を手動で実施する。

■使用アプリケーション

SPA は Database Replay に比べると、SQL 単体の実行における実行計画と性能の比較

検証に重きが置かれた機能である。これまでの検証で使用していた JPetStore は大量

47

オンライン・トランザクションを想定しているため、一つ一つの SQL 文は単純で、検索処

理はほとんどが索引検索によるものである。そのため、環境により実行計画に違いが出

にくいアプリケーションとなっている。

本検証では、比較的環境により実行計画に違いが出やすいと考えられる DWH 系のサイ

トシステムを想定したクエリを発行するアプリケーションを利用した。

■初期化パラメータ変更試験

SPA の基礎検証として、初期化パラメータを変更した際の SQL 実行比較テストを実施し

た。Oracle Enterprise Manager を利用し、任意の初期化パラメータの値を変更する前後

での性能検証を行った。試験パターンとしてアップグレード検証を選択した。この試験で

は、Oracle 8i、Oracle9i Database、Oracle Database 10g といったバージョンから上位の

バージョンにアップグレードした際に SQL 実行計画がどう変わるかといったことをシミュ

レーションすることができる。具体的には、optimizer_features_enable パラメータを利用し

て、オプティマイザの動作モードが指定されたバージョンのものになるように設定する。

例えば、Oracle9i Database Release 2 から Oracle Database 11g Release 1 へのバージョ

ンアップによる影響をシミュレートする場合には、Oracle Enterprise Manager により

optimizer_features_enable=9.2.0 と optimizer_features_enable=11.1.0.6 が設定された状態

でそれぞれ SQL を実行し、実行計画や統計情報を取得する。

3. データサイズ変更試験

SPA では、初期化パラメータの変更以外の構成変更テストも実施することが可能である。

この場合には、一回目テストの完了後に手動で構成変更を行い、二回目のテストを実施

する。構成変更について、基本的にはデータベースサーバに関する変更がサポートされ

る。構成変更には、データベースサーバの H/W 変更アップグレードや、索引の作成、テ

ーブルのパーティション化などのスキーマ構成変更などが含まれる。SPA では、SQL の

実行がデータベースサーバ上のみで実行されるため、クライアントやアプリケーションサ

ーバの構成を変更するテストで利用することはできない。SPA の有効性を確認するため

に、スキーマ構成の適用範囲について検証を行った。

本検証では、スキーマ構成変更のうちテーブル・データのサイズを変更するパターンを

実施した。本検証は次の項目を確認する目的で行っている。

・一回目と二回目のテストの間に Oracle インスタンスの再起動を行うことができるか？

⇒再起動前後の SPA 実行の比較レポートが作成可能であれば再起動を行っても

SPA の実行を継続性が確認できれば、Oracle インスタンスの再起動が必要な構成

変更への SPA の有効性が実証される。

・テーブルを削除し再作成しても SQL が実行されるか？

⇒テーブルを削除し再作成されたのであれば、そのテーブルは一回目と二回目では

物理的には同一ではなくなる。論理的に同一であれば SPA が有効であれば、本番

48

環境のコピーをテスト環境に移行できない場合でも、試験を実施することが可能と

なる。

・データサイズが異なっても SQL が実行されるか？

⇒データサイズを変更することで、テーブルに格納されるデータは同一ではなくなる。

データが異なっても SPA が有効であれば、本番環境のコピーをテスト環境に移行

できない場合に、ダミーデータの作成などで試験を実施することが可能となる。

なお、本検証では、Oracle 初期化パラメータについては、必要最低限以外のものは明示

的に設定せず、デフォルト値が設定されるようにしている。またテストアプリケーションは

DWH 系のアプリケーションであるため、パラレル化やパーティション化などの設定を行う

ことにより性能改善を図るが、今回はチューニングを全く実施していない。これは、アプ

リケーションの性能を確認することが目的ではなく、SPA の有効性を確認することを目的

としているためである。

8.2. 検証方法


本検証では、Database Replay 検証と同様に JPetStore を利用した。JPetStore を使ってデー

タベース・サーバーに対して負荷をかける。STS の取得の設定を行った場合と行っていない

場合で CPU 使用率やスループットの変化を計測する。もし STS 取得の設定により変化があ

れば、その差が STS 取得による影響と考えられる。

以下、検証の流れを具体的に記述する。

① STS 取得を行わずに JPetStore により一定期間負荷をかける

OS の統計情報、Oracle Database 統計情報などを取得。

② Oracle インスタンスを STS 取得モードに変更

本検証では、10 秒ごとにカーソル・キャッシュを読み込んで取得するように設定

③ STS を取得している状態で JPetStore により一定期間負荷をかける

OS の統計情報、Oracle Database 統計情報などを取得。

④ ①と③の結果を比較


本検証では、アップグレードのシナリオを想定するため、Oracle Database 10g Release 2

(10.2.0.3)で取得した STS を利用した。Oracle Database 10g Release 2 の環境を本番環

境と想定し、負荷をかけ取得された STS をテスト環境と想定する Oracle Database 11g

Release 1 に移行し、SPA を実行する。以下、具体的に手順を記述する。

① SQL Tuning Set の取得モード開始

本番環境想定の本番環境想定の Oracle Database 10g Release 2 データベースを STS 取得モー

ドに変更する。STS 取得モードになっている間に実行された SQL が STS に保存されるようにな

49

る。

② アプリケーションを実行

STS で SQL をキャプチャするために、アプリケーションを実行する。本検証では、22 の SQL

（SELECT）をスクリプト化し、SQL*Plus からデータベースに接続しスクリプトを実行した。

③ SQL Tuning Set の取得モード終了

本番環境想定 Oracle Database 10g Release 2 データベース上の STS 取得モードを終了する。

④ SQL Tuning Set の移行

Oracle Database 10g Release 2 本番環境想定データベースで取得された STS をエクスポートし、

テスト環境想定の Oracle Database 11g Release 1 データベースにインポートする。

⑤ 一回目テスト

テスト環境想定データベース上で Oracle Enterprise Manager を使い SPA を実行する。SPA が実

行されることにより、Oracle Database 10g Release 2 データベース本番環境想定で取得された

SQL を実行する。

⑥ 構成変更

テスト環境の構成を変更する。本検証では、初期化パラメータの変更およびデータサイズの変更

である。なお、初期化パラメータ変更は二回目の SPA 実行時に Oracle Enterprise Manager によ

り自動で実施される。

⑦ 二回目テスト

構成変更後、再度Oracle Database 11g Release 1データベーステスト環境想定データベース上で

SPA を実行する。

⑧ レポーティング・分析

一回目テストと二回目テストの比較分析を行う。Oracle Enterprise Manager によるレポーテ

ィング画面の確認。

上記のうち、①から④までは全体のテストで一度だけ実施し、テストパターンごとに⑤から⑧

を繰り返し実行した。


実施したデータサイズの変更を行う手順は以下の通りである。

① Oracle インスタンスを停止

データサイズを変更する上ではインスタンス停止は必要な手順ではないが、インスタンス停止を

跨る SPA の有効性を確認する目的で実施。

② Oracle インスタンスを起動

③ テスト用スキーマのテーブルを削除

④ テスト用スキーマのテーブルを再作成

⑤ テスト用スキーマのデータロード

データのサイズを一回目テスト時の 2 倍に増加（1GB から 2GB）。事前にサイズを増加した

CSV ファイルを作成し、外部表を使いデータを移行。

50

8.3. 検証結果


図 8-1.は、STS を取得せず負荷をかけている状態と、STS を取得する設定を行った

上で負荷をかけている状態で CPU 使用率を比較したグラフである。

0

10

20

30

40

50

60

70

80

90

100

0 120 240 360 480 600

time (s)

CP

U%

STS取得なし STS取得あり

図 8-1. STS 取得有無による CPU 使用率の違い

負荷をかけ始め、負荷が安定した時点から終了までの CPU 使用率の推移を平均す

ると、STS を取得していない場合には平均 CPU 使用率が 81.6%であった。この負荷にお

いて、STS を取得する設定を行った場合の平均 CPU 使用率は 81.7%であり、CPU リソー

スにおける変化は殆どないことを確認できた。

今回の検証では、10 秒ごとにカーソル・キャッシュを読み込む設定を行ったが、10 秒

ごとに CPU 使用率にスパイク出て、瞬間的に上がる動きも確認できなかった。このこと

から、STS 取得におけるオーバーヘッドは非常に小さいことがわかる。

スループットについても着眼してみたい。次の図は、負荷が安定してかかり始めたと

ころから、負荷が終了するまでの期間の秒間あたりの SQL 実行回数を比較したもので

ある。

51

1.000 0.997

0.000

0.200

0.400

0.600

0.800

1.000

1.200

STS取得なし STS取得あり

スル

ープ

ット

比

図 8-2. STS 取得有無によるスループットの違い

STS 取得なしの場合のスループットを 1.000 としたときに STS 取得時のスループットは

0.997となり、差は非常に小さく、スループットの面からもSTS取得におけるオーバーヘッ

ドは殆ど影響ないと判断できる。


・Oracle9i Database Release 2 から Oracle Database 11g への移行を想定した検証

SPA を使い、Oracle Database 11g Release 1 上で optimizer_features_enable パラメータ

を使用し、オプティマイザ動作モードを Oracle9i Database Release 2 と Oracle Database

11g Release 1 に変化させた検証結果を報告する。図 8-3.は、一回目に Oracle9i

Database Release 2 のオプティマイザ動作モード、二回目に Oracle Database 11g

Release 1 を設定し、アプリケーションの SQL をテストした結果の Oracle Enterprise

Manager の画面である。

図 8-3. SPA 実行結果/経過時間の比較

52

今回のアプリケーション実行では、全体で SQL の実行時間が 47%改善となった。Oracle

Enterprise Manager を使用すればアプリケーションから実行された SQL すべてのサマリ

ー情報や 1 つ 1 つの SQL についての詳細情報の確認が可能である。図 8-4. は、実行

された SQL についての画面である。

図 8-4. SQL の詳細画面/パフォーマンス比較

ここでは、SQL 実行の統計情報が表示されている。一回目テストと二回目テストにお

ける「経過時間」、「解析時間」、「CPU 時間」、「バッファ読取り」、「オプティマイザ・コス

ト」、「ディスク読取り」、「ダイレクト書込み」、「処理された行」が確認できる。

これらの値が大きく異なる場合、実行計画に変更が影響を与えた可能性がある。同じ

画面上で実行計画を比較して確認することが可能である。パフォーマンスが悪い SQL

がある場合には、Oracle Enterprise Manager の同じ画面上より SQL 実行計画ベースラ

インを使用して 1 回目実行時の実行計画に固定するか、SQL チューニング・アドバイザ

を使用したチューニングを即座に行うことが可能である。

次に同様の試験を Oracle Database 10g Release 2 のオプティマイザ動作モードと Oracle

Database 11g Release 1 の比較で行った結果を報告する。

・Oracle Database 10g Release 2 から Oracle Database 11g Release 1 への移行を想定した

検証

SPA を使い、Oracle Database 11g Release 1 上で optimizer_features_enable パラメー

タを使用し、オプティマイザ動作モードを Oracle Database 10g Release 2 と Oracle

Database 11g Release 1 に変化させた検証を行った。図 8-5.は、一回目に Oracle

Database 10g Release 2 のオプティマイザ動作モード、二回目に Oracle Database 11g

Release 1 を設定し、アプリケーションの SQL をテストした結果の Oracle Enterprise

Manager の画面である。

53

図 8-5. SPA 実行結果/経過時間の比較

全体の性能比較では、SQL の実行時間が 27%改善となった。Oracle9i Database Release

2 のオプティマイザ動作モードと Oracle Database 11g Release 1 の比較試験に比べて小

さい値となっている。これは、Oracle Database 10g Release 2 オプティマイザ動作モード

の実行時間が Oracle9i Database Release 2 オプティマイザ動作モードの実行時間に比

べて短くなったため、Oracle Database 11g Release 1 との差が小さくなったからである。こ

のように、SPA を使用することにより、Oracle データベースのバージョンをアップグレード

したときの影響を事前にテスト環境で効率的に試験できるメリットは大きいと考えられる

だろう。

オプティマイザ動作モードの変更テストについては、Oracle Enterprise Manager により

すべて自動化することが可能であるが、オプティマイザの変更だけではなくまた、

optimizer_features_enable 以外の初期化パラメータの変更テストについても Oracle

Enterprise Manager よりすべて自動化することが可能である。

次に、Oracle Enterprise Manager によりステップ実行する構成変更のテストについて報告する。


二回目のテスト時にデータサイズを 2 倍にして SPA を実行した結果を報告する。一回目

のテストのデータサイズは 1GB、二回目のデータサイズは 2GB である。

Oracle インスタンスの再起動、テーブルの再作成、件数の異なるデータのロードを実施

したが、全ての SQL が正常に実行され、テストが完了した。図 8-6. は、テスト完了後の

結果画面である。

54

図 8-6. SPA 実行結果/データサイズ変更試験

今回の環境では、データサイズを2倍にしたら変更した後のSPA実行では、実行時間が

22 倍にまで延びている（左の棒グラフがデータサイズ 1GB 時、右の棒グラフがデータサ

イズ 2GB 時）。その原因について、Oracle Enterprise Manager の画面上から確認してい

く。SPA 実行結果の比較レポートに表示された 2222 の SQL からのうち性能劣化が見ら

れた 1 つの SQL を選択し、その統計情報が表示したされている画面が、図 8-7. であ

る。

図 8-7. SPA 実行結果/データサイズ変更試験

ある SQL では、アクセスするデータのサイズが 2 倍になったことにより、バッファ読取りブ

ロック数が約 2.2 倍、オプティマイザ・コストが約 2.8 倍に悪化したことがわかる。今回性能

が大きく変わった要因はディスク読取りの増大で、約 20 倍に増えている。これは、今回の

環境ではSGAサイズがデフォルト値の約1.5GBに設定されており、データサイズが増大し

たことにより、二回目テストでは SQL を実行するたびにデータがキャッシュ･アウトされた

ためである。このように、構成変更による SQL パフォーマンスの影響ついても、SPA を使

用することによって迅速なテストと結果解析が可能なことを確認できた。さらに、Oracle

55

Tuning Pack の機能を使用すれば、SPA 実行後に必要に応じた SQL チューニングをすぐ

に行うことが可能である。

8.4. まとめ

SPA を利用するには本番環境などで STS を取得しなければならないが、この処理にはオーバー

ヘッドが見られないことが確認できた。この結果より、負荷の高いシステムで性能分析や構成変

更のテストを実施するために STS を取得する場合においても、性能面での影響を最小限に抑えら

れると判断できる。また、テスト環境においては構成変更前テスト、構成変更、構成変更後テスト

という手順となるが、構成変更においては論理的にテーブル構造が同一であれば試験できること

がわかった。従って、テスト可能な構成変更の要件には非常に柔軟に対応できると考えられる。こ

のことは、本番環境のデータベースをコピーすることが困難であるシステムにおいても有用にテス

トできることを意味する。

SPA は本番環境で実行された SQL を順次実行し、SQL 単位でのその性能、統計情報、実行計画

を比較することができる機能である。対して、Database Replay は本番環境で実行された SQL を同

一の実行順序、多重度で実行し、本番環境と同等の負荷をテスト環境にかける機能である。テス

トの目的に合わせてそれぞれの機能を使い分けることで、様々なテストが迅速に簡単に実行でき

ることが期待される。

56

9. 本検証を終えて

Oracle Database 11g の新機能である Oracle Real Application Testing (以降 RAT)を使用すること

によるメリットは、以下の２点があると考える。

１．Database 運用(メンテナンス)の設計ならびに構築（SI）コストの大幅削減

SI フェーズでは、設計時に RAT の機能特性を把握した上でテスト方法の確立をしておくだけで

良い。設計に基づき、パッチ受け入れテストの作成、実装等を行う必要がないため、SI コストは

大幅に削減されると考える。

２．Database 運用(メンテナンス)コストの大幅な削減

例えば、某製造系の基幹系システムでは、業務に即したテストプログラムを持っておらず。

(工数面から作成するには、莫大の時間と費用が必要なため)

本番環境にOracle Databaseの個別パッチ(PSR等)を適用する際、２ヶ月前にテスト環境にパッ

チを適用、その間に行われるテスト環境でのテスト(例：新規業務 AP 動作テスト)を通して問

題有無を確認している。

※問題ない場合、本番環境へ適用。問題ありの場合、問題点を改修後、同様の方法で２ヶ月間テストを行う

以下の２点の課題あり

・パッチ受け入れ評価に時間（本例では２ヶ月）がかかる

・テスト環境で行ったテスト内容の網羅度が低い

※本番環境で流れているすべてのトランザクションを忠実に再現し、テストしていないため

RAT を使用することで上記課題を解消でき、Oracle Database 11g へ最新パッチ適用、バー

ジョンアップ(例：10.2.0.4→11.1.0.6)やデータベースサーバの HW リプレイスに伴う、事前テストと

して RAT は非常に有効な機能と考える。

本検証を通して、上記２点のメリットを享受できる機能であるかを確認するため、Oracle Real

Application Testing (RAT)動作の特性を把握した。まず、Database ReplayにおいてもSQL

Performance Analyzer (SPA) においても従来の性能にほとんど影響なく本番ワークロードのキャ

プチャが行えることがわかった。これは、RAT導入にあたっての大きなポイントであると言える。

実際のテスト実施時においても有効性が確認できた。実行SQLごとの性能を比較するSPAでは、

データベースの構成変更時にOracle Enterprise Managerを使用した効率的なテスト実施や分析が

行えることが確認できた。本番環境のワークロード全体をリプレイする Database Replayでは、リ

プレイ時のパラメータ設定による挙動の変化について詳細に確認した。この検証結果を活用する

ことで、例えばトランザクション順序の再現性やスループットの再現性などの要件に合わせて

synchronization パラメータを設定するといった、要件に合わせたテストの実施が可能になる。検

証によって明らかになったその他のTipsについても同様に本資料に記載している。

また、Database ReplayとTransparent Data Encryption (TDE) を組み合わせた場合の挙動やRAC

と組み合わせた場合のリプレイ時の接続についても確認も行った。今後追加検証（例：RAT+TDE

で暗号化するデータ列を増やした場合の検証）を行うことで、RATとその他機能の組み合わせ使

用時のさらなるベストプラクティスを確立できると考える。

本資料が、RATを検討・使用する多くの運用現場で活用されることを期待したい。

57

日本オラクル株式会社日本電気株式会社

〒102-0094 東京都千代田区紀尾井町4-1 〒108-8001東京都港区芝5-7-1

ニューオータニガーデンコート NEC本社ビル

Copyright © 2008 Oracle Corporation Japan. All Rights Reserved.

Copyright © 2008 NEC Corporation. All Rights Reserved

無断転載を禁ず

このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があります。このド

キュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙示的な保証や条件

を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オラクル株式会社ならび

に日本電気株式会社は、このドキュメントについていかなる責任も負いません。また、このドキュメ

ントによって直接又は間接にいかなる契約上の義務も負うものではありません。このドキュメントを

形式、手段（電子的又は機械的）、目的に関係なく、日本オラクル株式会社ならびに日本電気株

式会社の書面による事前の承諾なく、複製又は転載することはできません。

Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及びその子会

社、関連会社の登録商標です。その他の名称は、日本電気株式会社ならびにその子会社、関連

会社の商標または登録商標です。

58

Documents

Oracle Database 11g Oracle Real Application Testing検証 … · 応じてOracle Database 11g の機能を使用したより詳細な調査や対策が可能である。 図2-4. Database

Oracle Database 11g Oracle Real Application Testing検証 … · 応じてOracle Database 11g の機能を使用したより詳細な調査や対策が可能である。図2-4. Database