Oracle Database 11g
Oracle Real Application Testing
•
価値
•
テクノロジの迅速な導入
•
テスト品質の向上
•
ビジネス上の利点
•
低コスト
•
低リスク
機動的なビジネスのためのソリューション
テスト テスト 配置 配置 修正 修正変更
Database Replayの必要性
•
ビジネスに相応しい価値を付加する新しいテクノロジの導入
•
時間がかかり高コストの、広範囲にわたるテストおよび評価
•
高コストにもかかわらず低い成功率のテスト
• 多数の問題が検知されない • システム可用性およびパフォーマンスにマイナスの影響を及ぼす•
成功率の低さの原因
• 現行のツールは不適切なテストを提供する • 実際の本番ワークロードを再生するかわりに、合成ワークロードを シミュレート • ワークフローの一部分が対象Database Replayにより実際のテストが可能に
Database Replay
•
テスト環境で本番データベースのワークロードを
再生
•
本番環境へ変更を適用する前に、潜在的な不安定性を
特定、分析、修正
• 本番環境でのワークロードの取得
• 実際の負荷、タイミング、同時実行性の特性を用いて、 完全な本番ワークロードを取得 • 取得したワークロードをテスト・システムに移動• テストでのワークロードの再生
• テスト・システムでの必要な変更の実施 • 完全な本番環境特性を用いてワークロードを再生 • コミット順序の順守• 分析とレポート
• エラー外部クライアント・ リクエストの 記録 クライ アント クライ アント クライ アント 中間層 ストレージ サポートされない 変更 サポートされる変更 •データベースのアップグレード、パッチ •スキーマ、パラメータ •RACノード、インターコネクト •OSプラットフォーム、OSアップグレード •CPU、メモリー •ストレージ •その他
Database Replay:サポートされる変更
LoadRunnerとDB Replayの比較
Oracle E-Business Suiteのテスト
時間（日数） インストール および セットアップ アプリケー ション使用法 の把握 主要なトランザクション の識別 ワークロードの 生成 テスト実行 DB Replay LoadRunner
テスト総時間
DB Replay:2週間
150
日
10
日
なぜDatabase Replayなのか
導入前：
導入後：
人為的ワークロード
本番ワークロード
部分的なワークフロー
完全なワークフロー
月単位の開発
日単位の開発
手動中心
自動化
高リスク
低リスク
Database Replayのワークフロー
テスト（11.1）
本番（10.2.0.4）
中間層 クライ アント Replay Driver 取得 処理 再生 レポート分析とストレージ
ストレージ
Step 1：ワークロードの取得
• すべての外部クライアントの要求を バイナリ・ファイルに取得 • システム・バックグラウンドでは、 内部アクティビティは除外 • 最小のパフォーマンス・オーバーヘッド で取得• Oracle Real Application Clusters 向けの、共有およびローカル・ファイル・ システムのサポート
• ピーク・ワークロード、月末処理など、
取得のための期間を指定
• Oracle Database Release 10.2.0.4上 での取得およびOracle Database 11g 上での再生が可能 本番システム ファイル・システム クライ アント 中間層 ストレージ クライ アント クライ アント ファイル1 ファイル2 ファイルn
取得オプション
•
ワークロードのフィルタリングにより、取得した内容のカスタマイズが可能
• フィルタの種類 • 包含フィルタ:取得すべきセッションを指定 • 除外フィルタ:取得すべきでないセッションを指定 • フィルタの属性:次のいずれかのセッション属性を使用して、ワークロードの取得の フィルタリングが可能 • ユーザー • プログラム • モジュール • アクション • サービス • セッションID•
ワークロードの取得は、オンデマンドでの実行、または後で実行するための
スケジュールが可能
ステップ2：ワークロード・ファイルの処理
• テスト・システムのセットアップ
• テスト・データベースは、本番環境の
取得前と同じ時点のもの
• Oracle Recovery Managerを使用し、バッ クアップから本番データベースを 物理的にリストア • スナップショット・スタンバイの使用 • imp/exp、Data Pumpなどの使用 • 取得データを再生可能フォーマットに 変換処理 • 処理後は、ワークロードの再生が何度 でも可能
• Oracle Real Application Clusters向け に、すべての取得ファイルを処理用の 単一ロケーションにコピー
テスト・システム
取得ファイル 再生ファイル ファイル1 ファイル2 ファイルn ファイル1 ファイル2 ファイルn メタデータステップ3：ワークロードの再生
•
取得システムのタイミング、同時実行性、
依存性を維持しながら、ワークロードを
再生
•
特別なクライアント・プログラムである
Replay Driverにより、処理済みワー
クロードを取り込み、再生システムに
リクエストを送信
•
Replay Driverは、1つまたは複数
のクライアントから構成される。
同時実行性の高いワークロードの
ためには、複数のクライアントに
ワークロードの実行を開始させる
ことが必要
再生ファイルテスト・システム
Replay Driver ファイル1 ファイル2 ファイルn メタデータ再生オプション
•
同期再生（デフォルト）
• ワークロードを完全な同期モードで再生 • 本番環境のワークロードとまったく同じ同時実行性およびタイミング • トランザクションのコミット順序の順守 • データの最小の相違を保証•
非同期再生
• ワークロードを非同期モードで再生 • 負荷/ストレス・テストに有益 • データの大きな相違 • 3つのパラメータにより、同期の程度を制御 • 思考時間の同期 • 接続（ログオン）時間の同期 • コミット順序の同期再生オプション
•
非同期再生パラメータ
• 思考時間の同期 • データベース・コール間の思考時間を制御 • 自動（デフォルト）:取得されたリクエスト率を維持するように思考時間を調整 • パーセンテージ • 0%思考時間ゼロ、最大限のリクエスト率 • 100%未満 高リクエスト率 • 100% 厳密な思考時間 • 100%超 低リクエスト率 • 接続（ログオン）時間の同期 • セッションが作成される時期を制御 • 0%: すべてのセッションが即時に接続 • 100%（デフォルト）:取得システムと同じ時間でセッションが接続 • コミット順序の同期 • トランザクション間のコミット順序を制御再生オプション
•
再生クライアントの数
•
ユーザーによる設定が可能
•
Client Calibration Advisorは、特定のワークロードに必要とされる
再生クライアントの数を推奨
•
再生クライアントは、複数のワークロード・セッションをそれぞれ実行
分析とレポート
•
分析目的の包括的なレポート
•
3種類の相違をレポート
• データの相違：各コールによって返される行数を比較し、 相違をレポート • エラーの相違：各コールに対するエラーの相違をレポート • New:取得中には見られなかったが、再生中に発見 されたエラー • Not Found:再生中には見られなかったが、取得中に 発見されたエラー • Mutated:再生中に生成された、取得中とは異なるエラー • パフォーマンスの相違 • 取得および再生レポート：高水準のパフォーマンス情報 を提供 • ADDMレポート：詳細なパフォーマンス分析を提供現在の制限
•
Database Replayが現行のリリースでサポートしていない機能
•
ダイレクト・パス・ロード、インポート/エクスポート
•
OCIベースのオブジェクト・ナビゲーション（ADT）およびREFバインド
•
ストリーム、非PL/SQLベースAQ
•
分散トランザクション、リモート・ディスクライブ/コミット・オペレーション
•
フラッシュバック
•
共有サーバー
ベスト・プラクティス
• 取得
• 取得ワークロード（バイナリ・ファイル）用に適切なディスク領域を提供する • データベースの再開（オプション）:相違の最小化が推奨される
• Oracle Real Application Clustersのために共有ファイル・システムを使用する
• テスト・システムのセットアップ
• 再生中のデータの相違を最小限に抑えるため、テスト・データは、取得の開始時点の本番 データと同一のものにする
• Oracle Recovery Managerバックアップ/リストアまたはスナップショット・スタンバイを使用 して、テスト・システムをセットアップする • パフォーマンス分析のために、テスト・システムの能力は本番システムの能力と同様にする • アプリケーション・ロジックにSYSDATE使用が含まれている場合は、システム・クロックを 本番システムと同じ時間にリセットする • ワークロードの処理 • ワークロードの処理にはパフォーマンス・オーバーヘッドがかかるため、長時間を要する 可能性がある • ワークロードの処理は、本番システムではなくテスト・システムで実施 • 再生
• Client Calibration Advisorを使用し、ワークロードの正確な再生に必要な再生クライアント の数を特定
SQL Performance
Analyzer（SPA）
SQL Performance Analyzer（SPA）の必要性
•
ビジネス現場では、高パフォーマンスかつSLAに対応できるシステム
が求められている
•
SQLのパフォーマンス・リグレッションが、低システム・パフォーマンス
の最大の原因
•
変更に起因する
すべての
SQLリグレッションを積極的に検出する
ソリューションが存在しない
•
DBAは、非効率的で時間のかかるマニュアル・スクリプトを用いて
問題を特定している
SPAにより、ユーザーに影響が及ぶ前に、SQLパフォーマンスの
すべての変更を識別
なぜSQL Performance Analyzerなのか
導入前：
導入後：
手動でのワークロード作成
ワークロード取得の自動化
合成ワークロード
本番ワークロード
数か月を要する手動での分析
数分の自動分析
部分的なワークロード
完全なワークロード
高リスク
低リスク
SQL Performance Analyzer
•
SQL問合せパフォーマンスに対する変更の影響をテスト
•
統計情報やバインド変数を含むSQLワークロードを
本番環境で取得
•
テスト環境でSQL問合せを再実行
•
パフォーマンスの変化（改善とリグレッション）の分析
クライ アント クライアント クライアント 中間層 ストレージ Oracle DB SQLの取得 SQL問合せの再実行 SQL Tuning Advisorを使用して リグレッションを修正 本番 テストSPAの利点
•
エンドユーザーが影響を受ける
前に
、SQLのパフォーマンス・
リグレッションの識別が可能
•
SPAは、SQL実行プランに影響を与えるあらゆる変更に有益
• データベースのアップグレード • オプティマイザ統計情報のリフレッシュ • 新規索引、マテリアライズド・ビュー、パーティションなど•
手動では不可能な、何十万ものSQL文のSQLパフォーマンス
の追跡を自動化
•
少ないオーバーヘッドでSQLワークロードを取得
SQL Performance Analyzerのワークフロー
テスト（11.1）
クライ アントストレージ
中間層本番（10.2）
ストレージ
SQLの 取得 SQLの 転送 SQLの実行 変更前 SQLの実行 変更後 パフォーマンス の比較ステップ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
ステップ2：SQLワークロードのテスト・システムへ
の移動
• SQL Tuning Setをステージング表にコピー（"パック"）
• ステージング表をテスト・システムに転送（Data Pump、DB LINKなど）
• ステージング表からSQL Tuning Setをコピー（"アンパック"）
本番データベース テスト・データベース
エクスポート/インポート
カーソル・キャッシュ
ステップ3：変更実行前のSQLの実行
• SQLワークロードのパフォーマンス・ ベースラインの確立 • SQL実行計画および統計情報の 取得 • SQLの連続的な実行（同時実行性なし） • 各SQLの実行は一度のみ • DDL/DMLのスキップ • 分析のみにEXPLAIN PLANを実行する オプション SQL Tuning Set 次のSQLをフェッチ テスト実行 実行計画および 統計情報 結果を保存 変更前SQL Tuning Set 次のSQLをフェッチ テスト実行 実行計画および 統計情報 結果を保存 変更前 SQL Performance Analyzer 変更後 完了 • 計画した変更の手動による実装 • データベースのアップグレード、パッチ • オプティマイザ統計情報のリフレッシュ • スキーマ変更 • データベース・パラメータ変更 • チューニング・アクション（例：SQL Profileの作成） • 変更後にSQLを再実行 • 新規のSQL実行計画および統計情報の収集
ステップ4：変更実行後のSQLの実行
分析レポート 変更前 変更後 完了 完了 SQLパフォーマンス の比較 • さまざまな基準を使用してパフォーマンス を比較（以下、例） • 経過時間 • CPU時間 • オプティマイザ・コスト • バッファ取得 • SPAレポートが各SQLに対する変更の 影響を表示 • 改善したSQL • 回帰したSQL • 変更されていないSQL • SQL Tuning AdvisorまたはSQL
ステップ5：比較および分析パフォーマンス
ベスト・プラクティス
•
ワークロードの取得
•
増分STS取得を使用
•
このメカニズムにより、ピーク・ワークロードまたは典型的なワークロードの
より正確な取得が可能
•
テスト・システム
•
分析がリソース集中型になるため、SPAを本番システムではなくテスト・
システム上で実行
•
テスト・システムが本番システムと同様の構成および同程度のオプティマ
イザ統計情報を持つようにする
•
パフォーマンス比較
•
信頼性の高い結果を得るため、経過時間やCPU時間などのいくつかの
異なる基準を使用して、変更前と変更後のパフォーマンスを比較する
•
リグレッションの修正
•
SQL Tuning AdvisorおよびSQL Plan Baselinesを使用してリグレッション
を修正
Oracle Real Application Testingのまとめ
•
本番システムでの変更の影響を評価する、コスト効率が高く使いやすい
ソリューションを提供
• 低リスクで、実際の全体的なワークロード・テスト結果 • テスト・サイクルを月単位から日単位に削減 • テスト・システムの中間層およびアプリケーション・セットアップの必要性を 排除することによる、ハードウェア・コストの削減• リグレッションの修正にOracle Diagnostics PackおよびOracle Tuning Pack
を利用することによる、ROIの最大化
•
Oracle Real Application Testingの使用によるビジネス上の利点
• 競争力の維持
• 収益性の向上
