1

Oracle Database 11g Real Application Testing

2

Oracle Real Application Testing

• 価値

• テクノロジの迅速な導入

• テスト品質の向上

• ビジネス上の利点

• 低コスト

• 低リスク

機動的なビジネスのためのソリューション

テストテスト

配置配置

修正修正

変更

3

Database Replay

4

Database Replayの必要性

• ビジネスに相応しい価値を付加する新しいテクノロジの導入

• 時間がかかり高コストの、広範囲にわたるテストおよび評価

• 高コストにもかかわらず低い成功率のテスト

• 多数の問題が検知されない

• システム可用性およびパフォーマンスにマイナスの影響を及ぼす

• 成功率の低さの原因

• 現行のツールは不適切なテストを提供する

• 実際の本番ワークロードを再生するかわりに、合成ワークロードをシミュレート

• ワークフローの一部分が対象

Database Replayにより実際のテストが可能に

5

Database Replay• テスト環境で本番データベースのワークロードを再生

• 本番環境へ変更を適用する前に、潜在的な不安定性を特定、分析、修正

• 本番環境でのワークロードの取得

• 実際の負荷、タイミング、同時実行性の特性を用いて、完全な本番ワークロードを取得

• 取得したワークロードをテスト・システムに移動

• テストでのワークロードの再生

• テスト・システムでの必要な変更の実施

• 完全な本番環境特性を用いてワークロードを再生

• コミット順序の順守

• 分析とレポート

• エラー

• データの相違

• パフォーマンスの相違

分析とレポート

6

外部クライアント・リクエストの

記録

クライアント

クライアント

クライアント

中間層

ストレージ

サポートされない

変更

サポートされる変更

•データベースのアップグレード、パッチ

•スキーマ、パラメータ

•RACノード、インターコネクト

•OSプラットフォーム、OSアップグレード

•CPU、メモリー

•ストレージ

•その他

Database Replay:サポートされる変更

7

LoadRunnerとDB Replayの比較Oracle E-Business Suiteのテスト

時間（日数）

インストールおよび

セットアップ

アプリケーション使用法

の把握

主要なトランザクションの識別

ワークロードの生成

テスト実行

DB Replay

LoadRunner

テスト総時間

DB Replay:2週間

LoadRunner:30週間

8

150日

10日

なぜDatabase Replayなのか

導入前： 導入後：

人為的ワークロード 本番ワークロード

部分的なワークフロー 完全なワークフロー

月単位の開発 日単位の開発

手動中心 自動化

高リスク 低リスク

9

Database Replayのワークフロー

テスト（11.1）本番（10.2.0.4）

中間層

クライアント Replay Driver

取得 処理 再生分析と

レポート

ストレージストレージ

10

Step 1：ワークロードの取得

• すべての外部クライアントの要求をバイナリ・ファイルに取得

• システム・バックグラウンドでは、内部アクティビティは除外

• 最小のパフォーマンス・オーバーヘッドで取得

• Oracle Real Application Clusters向けの、共有およびローカル・ファイル・システムのサポート

• ピーク・ワークロード、月末処理など、取得のための期間を指定

• Oracle Database Release 10.2.0.4上での取得およびOracle Database 11g上での再生が可能

本番システム

ファイル・システム

クライアント

中間層

ストレージ

クライアント

クライアント

ファイル1

ファイル2

ファイルn

11

取得オプション

• ワークロードのフィルタリングにより、取得した内容のカスタマイズが可能

• フィルタの種類

• 包含フィルタ:取得すべきセッションを指定

• 除外フィルタ:取得すべきでないセッションを指定

• フィルタの属性:次のいずれかのセッション属性を使用して、ワークロードの取得の

フィルタリングが可能

• ユーザー

• プログラム

• モジュール

• アクション

• サービス

• セッションID

• ワークロードの取得は、オンデマンドでの実行、または後で実行するためのスケジュールが可能

12

ステップ2：ワークロード・ファイルの処理

• テスト・システムのセットアップ

• テスト・データベースは、本番環境の取得前と同じ時点のもの

• Oracle Recovery Managerを使用し、バッ

クアップから本番データベースを物理的にリストア

• スナップショット・スタンバイの使用

• imp/exp、Data Pumpなどの使用

• 取得データを再生可能フォーマットに変換処理

• 処理後は、ワークロードの再生が何度でも可能

• Oracle Real Application Clusters向け

に、すべての取得ファイルを処理用の単一ロケーションにコピー

テスト・システム

取得ファイル 再生ファイル

ファイル1

ファイル2

ファイルn

ファイル1

ファイル2

ファイルn

メタデータ

13

ステップ3：ワークロードの再生

• 取得システムのタイミング、同時実行性、依存性を維持しながら、ワークロードを再生

• 特別なクライアント・プログラムであるReplay Driverにより、処理済みワー

クロードを取り込み、再生システムにリクエストを送信

• Replay Driverは、1つまたは複数

のクライアントから構成される。同時実行性の高いワークロードのためには、複数のクライアントにワークロードの実行を開始させることが必要 再生ファイル

テスト・システム

Replay Driver

ファイル1

ファイル2

ファイルn

メタデータ

14

再生オプション

• 同期再生（デフォルト）

• ワークロードを完全な同期モードで再生

• 本番環境のワークロードとまったく同じ同時実行性およびタイミング

• トランザクションのコミット順序の順守

• データの最小の相違を保証

• 非同期再生

• ワークロードを非同期モードで再生

• 負荷/ストレス・テストに有益

• データの大きな相違

• 3つのパラメータにより、同期の程度を制御

• 思考時間の同期

• 接続（ログオン）時間の同期

• コミット順序の同期

15

再生オプション

• 非同期再生パラメータ

• 思考時間の同期

• データベース・コール間の思考時間を制御

• 自動（デフォルト）:取得されたリクエスト率を維持するように思考時間を調整

• パーセンテージ

• 0%思考時間ゼロ、最大限のリクエスト率

• 100%未満 高リクエスト率

• 100% 厳密な思考時間

• 100%超 低リクエスト率

• 接続（ログオン）時間の同期

• セッションが作成される時期を制御

• 0%: すべてのセッションが即時に接続

• 100%（デフォルト）:取得システムと同じ時間でセッションが接続

• コミット順序の同期

• トランザクション間のコミット順序を制御

• 非同期モードでは、コミット順序は順守されず、トランザクションはコミット・コールが実行されるとすぐにコミットされる

16

再生オプション

• 再生クライアントの数

• ユーザーによる設定が可能

• Client Calibration Advisorは、特定のワークロードに必要とされる

再生クライアントの数を推奨

• 再生クライアントは、複数のワークロード・セッションをそれぞれ実行できるマルチスレッド・クライアント

17

分析とレポート

• 分析目的の包括的なレポート

• 3種類の相違をレポート

• データの相違：各コールによって返される行数を比較し、

相違をレポート

• エラーの相違：各コールに対するエラーの相違をレポート

• New:取得中には見られなかったが、再生中に発見

されたエラー

• Not Found:再生中には見られなかったが、取得中に

発見されたエラー

• Mutated:再生中に生成された、取得中とは異なるエラー

• パフォーマンスの相違

• 取得および再生レポート：高水準のパフォーマンス情報を提供

• ADDMレポート：詳細なパフォーマンス分析を提供

• AWR, ASHレポート：比較または偏りの分析を支援

18

Database Replayサマリー・レポート

19

現在の制限

• Database Replayが現行のリリースでサポートしていない機能

• ダイレクト・パス・ロード、インポート/エクスポート

• OCIベースのオブジェクト・ナビゲーション（ADT）およびREFバインド

• ストリーム、非PL/SQLベースAQ• 分散トランザクション、リモート・ディスクライブ/コミット・オペレーション

• フラッシュバック

• 共有サーバー

20

ベスト・プラクティス

• 取得

• 取得ワークロード（バイナリ・ファイル）用に適切なディスク領域を提供する

• データベースの再開（オプション）:相違の最小化が推奨される

• Oracle Real Application Clustersのために共有ファイル・システムを使用する

• テスト・システムのセットアップ

• 再生中のデータの相違を最小限に抑えるため、テスト・データは、取得の開始時点の本番データと同一のものにする

• Oracle Recovery Managerバックアップ/リストアまたはスナップショット・スタンバイを使用

して、テスト・システムをセットアップする

• パフォーマンス分析のために、テスト・システムの能力は本番システムの能力と同様にする

• アプリケーション・ロジックにSYSDATE使用が含まれている場合は、システム・クロックを

本番システムと同じ時間にリセットする

• ワークロードの処理

• ワークロードの処理にはパフォーマンス・オーバーヘッドがかかるため、長時間を要する可能性がある

• ワークロードの処理は、本番システムではなくテスト・システムで実施

• 再生

• Client Calibration Advisorを使用し、ワークロードの正確な再生に必要な再生クライアント

の数を特定

21

SQL Performance Analyzer（SPA）

22

SQL Performance Analyzer（SPA）の必要性

• ビジネス現場では、高パフォーマンスかつSLAに対応できるシステム

が求められている

• SQLのパフォーマンス・リグレッションが、低システム・パフォーマンス

の最大の原因

• 変更に起因するすべての SQLリグレッションを積極的に検出する

ソリューションが存在しない

• DBAは、非効率的で時間のかかるマニュアル・スクリプトを用いて

問題を特定している

SPAにより、ユーザーに影響が及ぶ前に、SQLパフォーマンスのすべての変更を識別

23

なぜSQL Performance Analyzerなのか

導入前： 導入後：

手動でのワークロード作成 ワークロード取得の自動化

合成ワークロード 本番ワークロード

数か月を要する手動での分析 数分の自動分析

部分的なワークロード 完全なワークロード

高リスク 低リスク

24

SQL Performance Analyzer• SQL問合せパフォーマンスに対する変更の影響をテスト

• 統計情報やバインド変数を含むSQLワークロードを

本番環境で取得

• テスト環境でSQL問合せを再実行

• パフォーマンスの変化（改善とリグレッション）の分析

クライアント

クライアント

クライアント

中間層

ストレージ

Oracle DB

SQLの取得

SQL問合せの再実行

SQL Tuning Advisorを使用してリグレッションを修正

　　 本番　 　　 テスト

25

SPAの利点

• エンドユーザーが影響を受ける前に、SQLのパフォーマンス・

リグレッションの識別が可能

• SPAは、SQL実行プランに影響を与えるあらゆる変更に有益

• データベースのアップグレード

• オプティマイザ統計情報のリフレッシュ

• 新規索引、マテリアライズド・ビュー、パーティションなど

• 手動では不可能な、何十万ものSQL文のSQLパフォーマンス

の追跡を自動化

• 少ないオーバーヘッドでSQLワークロードを取得

• SQL Tuning AdvisorおよびSQL Plan Baselinesと統合して

リグレッションを修正

26

SQL Performance Analyzerのワークフロー

テスト（11.1）

クライアント

ストレージ

中間層

本番（10.2）

ストレージ

SQLの取得

SQLの転送

SQLの実行変更前

SQLの実行

変更後パフォーマンス

の比較

27

ステップ1：SQLワークロードの取得

• SQL Tuning Set（STS）を使用してSQLワーク

ロードを保存

• STSの内容：

• SQLテキスト

• バインド変数

• 実行計画

• 実行統計情報

• 増分取得を使用して、長期にわたるカーソル・キャッシュからSTSを移入

• SQL Tuning Setのフィルタリングおよびランキング機能により、望まないSQLを除外

• Oracle Database Release 10.2.0.1以降で取得されたSQLワークロードは、Oracle Database 11gのSPAタスクで使用可能

増分取得

本番データベース

カーソル・キャッシュ

SQL Tuning Set

28

ステップ2：SQLワークロードのテスト・システムへの移動

• SQL Tuning Setをステージング表にコピー（"パック"）• ステージング表をテスト・システムに転送（Data Pump、DB LINKなど）

• ステージング表からSQL Tuning Setをコピー（"アンパック"）

本番データベース テスト・データベース

エクスポート/インポート

カーソル・キャッシュ

SQL Tuning Set SQL Tuning Set

29

ステップ3：変更実行前のSQLの実行

• SQLワークロードのパフォーマンス・

ベースラインの確立

• SQL実行計画および統計情報の

取得

• SQLの連続的な実行（同時実行性なし）

• 各SQLの実行は一度のみ

• DDL/DMLのスキップ

• 分析のみにEXPLAIN PLANを実行する

オプション

SQL Tuning Set

次のSQLをフェッチ

テスト実行

実行計画および

統計情報

結果を保存

変更前

SQL Performance Analyzer

30

SQL Tuning Set

次のSQLをフェッチ

テスト実行

実行計画および

統計情報

結果を保存

変更前

SQL Performance Analyzer

変更後

完了

• 計画した変更の手動による実装

• データベースのアップグレード、パッチ

• オプティマイザ統計情報のリフレッシュ

• スキーマ変更

• データベース・パラメータ変更

• チューニング・アクション（例：SQL Profileの作成）

• 変更後にSQLを再実行

• 新規のSQL実行計画および統計情報の収集

ステップ4：変更実行後のSQLの実行

31

分析レポート

変更前

SQL Performance Analyzer

変更後

完了 完了

SQLパフォーマンス

の比較

• さまざまな基準を使用してパフォーマンスを比較（以下、例）

• 経過時間

• CPU時間

• オプティマイザ・コスト

• バッファ取得

• SPAレポートが各SQLに対する変更の

影響を表示

• 改善したSQL

• 回帰したSQL

• 変更されていないSQL

• SQL Tuning AdvisorまたはSQL Plan Baselinesを使用し、回帰したSQLを修正

ステップ5：比較および分析パフォーマンス

32

SPAレポート

33

SPAレポート回帰したSQL文

34

ベスト・プラクティス

• ワークロードの取得• 増分STS取得を使用

• このメカニズムにより、ピーク・ワークロードまたは典型的なワークロードのより正確な取得が可能

• テスト・システム• 分析がリソース集中型になるため、SPAを本番システムではなくテスト・システム上で実行

• テスト・システムが本番システムと同様の構成および同程度のオプティマイザ統計情報を持つようにする

• パフォーマンス比較• 信頼性の高い結果を得るため、経過時間やCPU時間などのいくつかの異なる基準を使用して、変更前と変更後のパフォーマンスを比較する

• リグレッションの修正• SQL Tuning AdvisorおよびSQL Plan Baselinesを使用してリグレッションを修正

35

Oracle Real Application Testingのまとめ

• 本番システムでの変更の影響を評価する、コスト効率が高く使いやすいソリューションを提供

• 低リスクで、実際の全体的なワークロード・テスト結果

• テスト・サイクルを月単位から日単位に削減

• テスト・システムの中間層およびアプリケーション・セットアップの必要性を排除することによる、ハードウェア・コストの削減

• リグレッションの修正にOracle Diagnostics PackおよびOracle Tuning Packを利用することによる、ROIの最大化

• Oracle Real Application Testingの使用によるビジネス上の利点

• 競争力の維持

• 収益性の向上

• 対応性

36