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