Oracle Real Application Testing

Transcript

1. Real Application Testing 概要 日本オラクル株式会社 クラウド・エンジニアリング統括 COE本部 データベース・ソリューション部 山田 恭平 2024年11月22日
2. 1. Real Application Testing (RAT) とは 2. SQL Performance Analyzer 3. Database Replay 4. お客様事例 5. Appendix Agenda Copyright © 2024, Oracle and/or its affiliates 2
3. 1. Real Application Testing (RAT) とは 2. SQL Performance Analyzer 3. Database Replay 4. お客様事例 5. Appendix Agenda Copyright © 2024, Oracle and/or its affiliates 3
4. • Upgradeやパッチ適用の適用時に使用することで、高品質かつ低作業コストでテストするための機能 • システム変更前後でのSQLの実行計画や性能を比較するレポートを生成 • 大きく分けて２種類の機能を使ってテスト工数を大幅に削減可能 Real Application Testing (RAT)とは Real Application Testing SQL Performance Analyzer (SPA) • SQL単体テスト(性能/非互換検出) • 基本的にデータの更新処理は実行せず、 SQL単体でエラーや実行計画の変化を確認 • テストデータやクライアントなしでも実行できるなど 実行のハードルが低い Database Replay (DB Replay) • システム全体のテスト • データの更新処理を行い、 本番環境でのデータの動きを再現 • 本番環境でのデータの断面やクライアントが必要 など実行のハードルは高い Copyright © 2024, Oracle and/or its affiliates 4
5. • 非互換の発生 • SQL構文確認の厳格化など、バージョンが変わっ た影響を受けて実行できなくなるSQLが発生する 可能性がある • オプティマイザの挙動の変化 • オプティマイザの挙動が変わり、アップグレードする ことで性能が変わる可能性がある • 新機能の自動起動 • Oracle Databaseは各バージョンごとに新しい 機能を追加しており、場合によっては新機能が デフォルトでONとなり、データベースの挙動が 変わることがある アップグレード時に問題を引き起こす可能性がある事象 ※これらの変化は恩恵も非常に高く、適切な使い方をすることで問題になることはありません。 Upgrade前にこれらの変化が発生する可能性を把握し、適切に使うことが重要となります。 アップグレード オプティマイザ12c オプティマイザ19c ------------------------------------------------ | Id | Operation | Name | ------------------------------------------------ | 0 | SELECT STATEMENT | | |* 1 | HASH JOIN | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | TABLE_A | | 4 | MERGE JOIN CARTESIAN| | |* 5 | TABLE ACCESS FULL | TABLE_B | | 6 | BUFFER SORT | | |* 7 | TABLE ACCESS FULL | TABLE_C | | 8 | INDEX FULL SCAN | TABLE_D_PK | ------------------------------------------------ ------------------------------------------------ | Id | Operation | Name | ------------------------------------------------ | 0 | SELECT STATEMENT | | |* 1 | HASH JOIN | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | TABLE_A | | 4 | MERGE JOIN CARTESIAN| | |* 5 | TABLE ACCESS FULL | TABLE_B | | 6 | BUFFER SORT | | |* 7 | TABLE ACCESS FULL | TABLE_C | | 8 | INDEX FULL SCAN | TABLE_D_PK | ------------------------------------------------ 異なる実行計画による 性能劣化が発生 Copyright © 2024, Oracle and/or its affiliates 5
6. • Upgrade時のSQL互換性チェック • SPAを使用し、数万本のSQLからエラーの発生するSQLを発見 • Upgrade時/RU適用時の性能試験 • SPAを使用し、数万本のSQLから実行計画や性能が変化するSQLを発見 • 定期パッチ適用による安定運用 • SPAにより、定期パッチ(セキュリティ、修正)の適用に必要なテストをルーティン化 • データの更新を含むワークロード全体の影響調査 • DB Replayにより一連のデータの流れまで再現して影響を調査 • 将来的な性能影響の調査 • DB Replayにより、既存のワークロードが将来的に増加した場合の影響を調査 ユースケース Copyright © 2024, Oracle and/or its affiliates 6
7. リアルに実行されているSQLをテストする • SPAの場合、STSの取得期間、タイミング、フィルター条 件に応じてSQLが取得される • 100%のSQLを対象としてテストするのではなく、STSに 取得したSQLがテスト対象となる • 低コストで密度の高いテストができる RAT利用におけるテスト密度について テスト網羅率 品質 ユーザ 満足度 コスト コスト 過剰な品質領域 品質 ユーザ満足度 【テスト網羅率と品質・コスト・ユーザ満足度の関係（イメージ）】 Copyright © 2024, Oracle and/or its affiliates 7
8. 1. Real Application Testing (RAT) とは 2. SQL Performance Analyzer 3. Database Replay 4. お客様事例 5. Appendix Agenda Copyright © 2024, Oracle and/or its affiliates 8
9. 本番環境で取得されたSQLをもとに2回のSPA試行を比較するレポートを出力 本番環境 テスト環境 SPAの利用イメージ STS SPA STS 5. SPA試行2回分 の結果を比較する レポートを出力 3. SPA試行1回目の実行で STSから本番環境での 実行統計を抽出 Data Pump 4. SPA試行2回目の実行で STSからSQLを抽出し テスト環境にて実行 2.STSを テスト環境へコピー 1.SQLチューニングセット (STS)を取得 Copyright © 2024, Oracle and/or its affiliates 9
10. • Oracle Database Enterprise Editionで取得可能な下記の情報を含むデータベース・オブジェクト • SQL • 実行コンテキスト（スキーマ、アプリケーション・モジュール名、バインド値など） • 実行統計（実行時間、CPU時間、バッファ読み取り量、ディスク読み取り量など） • 実行計画 • SYSAUXに格納され格納先の変更はできない • ステージングテーブルに格納することでexpdmp可能 • SPAで使用する場合、網羅性の高いカーソル・キャッシュからの取得を推奨 SQLチューニングセットとは カーソル・キャッシュ AWR SQLトレース 他のSTS SQL Performance Analyzer SQL Tuning Advisor SQL Access Advisor SQL Plan Management STS Copyright © 2024, Oracle and/or its affiliates 10
11. Enterprise Managerを利用した場合 SPAレポート Copyright © 2024, Oracle and/or its affiliates 11 • テスト概要 • SQL文の数 • エラーのあるSQL分の数 • 比較軸 • 結果のサマリ • 1回目と2回目の試行における 差異のサマリを表示 • SQL単体の差異 • 1回目と2回目の施行における SQL単体の差異を表示
12. APIを利用した場合 SPAレポート Enterprise Managerからの操作のほか、 API(DBMS_SQLTUNEなど)からの操作、HTMLやテキスト 形式でのレポート出力も可能 Copyright © 2024, Oracle and/or its affiliates 12
13. 判断できること • エラーの有無 • エラーSQLの数、エラーコードごとのSQL数 • SQLIDごとのエラー内容 • 実行計画の変化 • 実行計画が同じSQLの数 • 実行計画が改善、劣化したSQLの数 • SQL IDごとの実行計画の内容 • 性能の変化 • 比較メトリックに応じた全体性能の差異 • 比較メトリックに応じたSQL IDごとの性能差異 • 検索結果の違い • 行数の違い • 結果の違い SPAレポート The number of returned rows in execution 'first trial' is different than in execution 'second trial'. The result set in execution 'first trial' is different than in execution 'second trial'. Error in execution 'second trial': ORA-00942: table or view does not exist ※結果の違いについては2回の試行がどちらも18c以上でTest Execute (後述)にて実行される必要があり、テスト環境と本番環境のデータを完全一致させることが望ましい Copyright © 2024, Oracle and/or its affiliates 13
14. テスト目的に応じた環境準備 • ３段階の目的でテスト可能 • SQL互換性 • 実行計画の変化 • パフォーマンスの差異 • 段階に応じてSPA実行に 必要な環境が変化する STS取得元の検討 • インプット情報として カーソル・キャッシュやAWRなど、 どの情報をもとに取得するか STS取得時の負荷と 表領域使用量 • STSを取得する場合のリソース 負荷はどれくらいか • SYSAUX表領域の増加量は どれくらいか SPA実行時の考慮ポイント Copyright © 2024, Oracle and/or its affiliates 14
15. SPAを実行するために必要な環境 • テスト目的に応じて必要な環境が変化する • テスト目的に応じて構成や実行の仕方も変化する 次ページ以降でテスト目的に応じた構成について紹介 テスト目的に応じた環境準備 テスト目的 オブジェクト定義 オプティマイザ統計 実データ SQL互換性 ◯ SQL互換性 実行計画 ◯ ◯ SQL互換性 実行計画 パフォーマンス ◯ ◯ ◯ Copyright © 2024, Oracle and/or its affiliates 15
16. 本番環境 テスト環境 テスト目的：SQL互換性 STS SPA STS 5. SPA試行2回分 の結果を比較する レポートを出力 3. SPA試行1回目の実行で STSから本番環境での 実行統計を抽出 Data Pump 4. SPA試行2回目の実行で STSからSQLを抽出し 実行計画の生成まで実行 2.STSを テスト環境へコピー 1.SQLチューニングセット (STS)を取得 0.定義情報のみの expdp/impdpで データベースの器を作成 Copyright © 2024, Oracle and/or its affiliates 16
17. 本番環境 テスト環境 テスト目的：実行計画の変化 STS SPA STS 5. SPA試行2回分 の結果を比較する レポートを出力 3. SPA試行1回目の実行で STSから本番環境での 実行統計を抽出 Data Pump 4. SPA試行2回目の実行で STSからSQLを抽出し 実行計画の生成まで実行 1.SQLチューニングセット (STS)を取得 統計情報 統計情報 0-2.統計情報のインポート 2.STSを テスト環境へコピー 0-1.定義情報のみの expdp/impdpで データベースの器を作成 Copyright © 2024, Oracle and/or its affiliates 17
18. 本番環境 テスト環境 テスト目的：パフォーマンスの変化 STS SPA STS 5. SPA試行2回分 の結果を比較する レポートを出力 3. SPA試行1回目の実行で STSから本番環境での 実行統計を抽出 Data Pump 4. SPA試行2回目の実行で STSからSQLを抽出し SQLを実行 1.SQLチューニングセット (STS)を取得 実データ 実データ 0.実データのインポート 2.STSを テスト環境へコピー Copyright © 2024, Oracle and/or its affiliates 18
19. • DBMS_SQLPA.EXECUTE_ANALYSIS_TASK ファンクションにてSPAを実行する際にパラメータとして指定 • 2回の試行それぞれでファンクションを実行しレポートを出力する 実行方法の指定 BEGIN DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( task_name => 'SPATASK01’, execution_type => 'EXPLAIN PLAN’, execution_name => 'first trial’ ); END; / execution_type 内容 CONVERT SQLSET STSから本番環境での実行統計を抽出 EXPLAIN PLAN STSからSQLを抽出し実行計画の生成まで実行 TEST EXECUTE STSからSQLを抽出しSQLを実行 Copyright © 2024, Oracle and/or its affiliates 19
20. 最も精緻なテストを行いたい場合 本番環境 テスト環境 テスト目的：パフォーマンスの変化 STS 3. SPA試行1回目の実行で STSからSQLを抽出し SQLを実行 Data Pump 2.STSを テスト環境へコピー 1.SQLチューニングセット (STS)を取得 実データ SPA STS 実データ 実データ 旧バージョン 旧バージョン 新バージョン DB Link 4. SPA試行2回目の実行で STSからSQLを抽出し DB Link経由でSQLを実行 5. SPA試行2回分 の結果を比較する レポートを出力 STSから実行統計を抽出するのではなく、旧バージョンのテスト環境で SQLを実行することで無風状態でのテストが可能 Copyright © 2024, Oracle and/or its affiliates 20
21. • Test Executeを指定した場合、SQLは最低2回、最大10回実行される • 最初の実行はバッファ・キャッシュの準備のためにのみ実行され、実行統計には含まれない • 2回目以降の実行結果における平均が実行統計となる • SQLが実行される回数は、SQLの実行時間の長さによって変化する • 実行時間が長いSQLは2回だけ実行され、 実行時間が短いSQLは実行タイムアウトが発生するまで最大10回実行される Test ExecuteにおけるSQLの実行回数について Copyright © 2024, Oracle and/or its affiliates 21
22. ３パターンから検討 取得元 メリット デメリット・注意点 カーソル・キャッシュ • 実施に本番環境上で実行されているSQLを キャッシュから収集することが可能 • SQLの網羅性が高い • 本番環境上のカーソル・キャッシュ からの取得となるため、少なからず 負荷がかかる AWR • 本番環境に負荷を与えずSQLを収集可能 • AWRに保存されるSQLのみが対象 となるため網羅性が低い • 網羅性を上げるために取得間隔を 小さくしてSQL収集を topnsql=MAXIMAMに設定すると、 負荷が増大しSYSAUX表領域を大 量に使用 SQLトレース • 実際に本番環境上で実行されているSQLを収集する ことが可能 • SQLの網羅性が高い • SEでも取得可能 • SQLトレースを有効化することによる 本番環境への負荷が高い STS取得元の検討 Copyright © 2024, Oracle and/or its affiliates 22
23. • STS取得時の負荷 日本電気株式会社と日本オラクル株式会社で実施したベンチマーク事例 参考URL： http://jpn.nec.com/soft/oracle/files/gc_11gRAT_WP.pdf サマリ（｢8.3.検証結果 1.SQL Tuning Set取得のオーバヘッド｣より抜粋) • 検証内容 10秒間隔でカーソル・キャッシュからSQL Tuning Set(SQL情報)を取得 • 検証環境DB Oracle Database 10g Release 2(※) • 検証結果 • STS取得時のCPU平均使用率は、0.1%の誤差 (取得なし：81.6%、取得あり：81.7%) • CPU使用率にスパイクが出て、瞬間的に上がる動きもなし • スループット比較でもSTS取得時のオーバーヘッドはほとんどなし（取得なし：1.000、取得あり：0.997） ※ Oracle Database 11gR2以降 においても同様に性能面への影響は軽微であると想定 STS取得時の負荷と表領域使用量 Copyright © 2024, Oracle and/or its affiliates 23
24. • STSはSYSAUX表領域に格納される • 多くのSQLを格納すると、SYSAUXが肥大化するため、事前にサイジングを行う必要がある • 目安として、1SQLあたり5～20KB程度を使用 （※あくまで事例ベースの目安となりシステム特性によって前後する可能性があります） • 現在のサイズはDBA_SEGMENTSで確認可能（WRI$_SQLSETから始まるセグメントが対象） STS取得時の負荷と表領域使用量 -- 現在のサイズ確認例 SQL> select SUM(BYTES)/1024 as "SPACE_USAGE_KBYTES" from DBA_SEGMENTS where SEGMENT_NAME like 'WRI$_SQLSET%'; SPACE_USAGE_KBYTES ------------------ 4992 -- STSに含まれるSQL数の確認例 SQL> select sum(STATEMENT_COUNT) from DBA_SQLSET; SUM(STATEMENT_COUNT) -------------------- 726 Copyright © 2024, Oracle and/or its affiliates 24
25. STS格納時のフィルタ • SQL情報をSTSへ格納する際、不要なSQLを除外するため、フィルタリングの設計を行うことが重要 • DBMS_SQLTUNEパッケージ使用時に、”Basic Filter”機能を使用してフィルタリングが可能 • STSへ格納する際に件数を指定することも可能 STS使用のTIPS 項目 Filtering目的 モジュール DataPump処理を対象外とする スキーマ APの実行スキーマのみ対象とする PLAN_HASH_VALUE “0”のものは実行計画がないので取得しない SQL_テキスト 特定のキーワードを持つSQLを取得対象しない ▪フィルタリング設計例 ※11.2.0.4から再帰SQLを除外するパラメータ”recursive_sql”が追加されています Copyright © 2024, Oracle and/or its affiliates 25
26. システムが管理するSQLチューニングセット • STSを利用するにはDBAにより手動設定する必要があり、メンテナンスの手間もかかる（それを解決するためにOracle Database 19c RU 19.7 より提供された） • 19cの自動インデックス (Automatic Indexing) をサポートするために作成され、 19.7でインフラストラクチャ・コンポーネントとして公開された • Enterprise Edition ではすべてのプラットフォームで使用可能（追加のライセンスは必要ない） • 自動バックグラウンド・タスクで 15 分おきに実行される（SQL文の保存時間は 53 週間） • この値は変更できない • SQLのワークロードを収集し、SYS_AUTO_STS という SQL チューニング・セットに格納 • STSと同じように SYSAUX の表領域に格納 • SPAで利用する場合は、本番データとテストデータの断面をどう揃えるかの検討が必要 • 詳細は以下資料で確認 https://speakerdeck.com/oracle4engineer/oracle-database-technology-night-number-64-automatic-sql-plan- management-hashi-erunoka?slide=40 自動SQLチューニング・セット (ASTS) とは Copyright © 2024, Oracle and/or its affiliates 26
27. SPAのテスト対象外SQLについて SPAにおける制限事項 SQL 評価可否 • SQL実行計画が作成される問い合わせSQL • INSERT文(SELECT文を含むものは実行計画が作成される 為、評価可能) • DDL文(TABLE/INDEX作成、TABLE LOCK等) • Private DB Link経由のSQL • Export/Import処理 • パラレルDML • Mview Refresh • オプティマイザ統計情報収集 • Dynamic SamplingのSQL 調査/評価の要否を検討。 必要な場合は、別途単体テ ストを検討する。 SPA単体性能テスト実施 Copyright © 2024, Oracle and/or its affiliates 27
28. 本番環境 テスト環境 SPAにおけるライセンスの考え方 STS SPA STS STSはEnterprise Edition 標準機能のためライセンスは必要ない SPA試行、レポート出力のために Oracle Real Application Testingのライセンスが必要 OCI の場合Enterprise Edition以上でOK Copyright © 2024, Oracle and/or its affiliates 28 ※テスト環境側に新バージョンと旧バージョンの二つの環境を利用する場合は2環境にライセンスが必要
29. 1. Real Application Testing (RAT) とは 2. SQL Performance Analyzer 3. Database Replay 4. お客様事例 5. Appendix Agenda Copyright © 2024, Oracle and/or its affiliates 29
30. 本番環境 テスト環境 Database Replay の利用イメージ クライアント APサーバー DBサーバー / ストレージ リプレイ・ クライアント DBサーバー / ストレージ キャプチャ・ファイル リプレイ・ファイル 1.ワークロードを取得し キャプチャ・ファイルを生成 2.キャプチャ・ファイルを リプレイファイルに変換 3.リプレイファイルを使用して ワークロードを再現 データの更新も実施 4.分析レポートを出力 実データ 実データ Copyright © 2024, Oracle and/or its affiliates 30
31. ワークロード・リプレイ・レポート • キャプチャとリプレイのサマリを比較 しテストの妥当性を判断 AWR期間比較レポート • キャプチャとリプレイのリソース使用 量や待機イベントなどを比較 ASHレポート • キャプチャとリプレイの差異を セッションレベルで分析 Database Replay実行後の分析に利用できるレポート Copyright © 2024, Oracle and/or its affiliates 31
32. ワークロード・リプレイ・レポート • キャプチャとリプレイのサマリを比較しテストの 妥当性を判断 • Replay Statistics • User callsが同等になっていることを確認し キャプチャとリプレイで • Replay Divergence Summary • Divergence Typeそれぞれの相違の割合が 大きくないことを確認 • エラーやSession Failuresが大きい場合、データが キャプチャ時と同等になっているかを確認 レポート分析 Copyright © 2024, Oracle and/or its affiliates 32
33. • エラーの違い • リプレイ時に発生した新規エラー • キャプチャ時に発生していたがリプレイ時に発生しなかったエラー • キャプチャ時に発生していたがリプレイ時に変異したエラー • データの違い • キャプチャ時と異なる行数が変更されたDML • キャプチャ時と異なる件数が返されたSELECT • キャプチャ時とリプレイ時でデータを比較することによるデータの中身の違い (レポートでは表示されないため別途確認が必要) • パフォーマンスの違い • AWR、ASHレポートで比較 Database Replayの結果から判断できること Copyright © 2024, Oracle and/or its affiliates 33
34. DBMS_WORKLOAD_CAPTURE.START_CAPTUREで取得 • クライアントからの全リクエストをキャプチャ・ファイルに取得 • セッションを指定し、特定のワークロードの取得/除外が可能 • セッションごとに***.recというファイルを作成 • キャプチャ時のオーバーヘッドはCPU使用率3~5%程度 • キャプチャ・ファイルのサイズ見積もりはAWRレポート SQL*Net bytes from clientの2 ~ 3倍程度 • Oracle Database 19c以降であればPDBごとに取得可能 • ワークロード取得の開始前に進行中のトランザクションを確実に完了するためにデータベースの再起動を推奨 キャプチャ・ファイル取得について BEGIN DBMS_WORKLOAD_CAPTURE.START_CAPTURE ( name => 'BASIC_CAPTURE1’, dir => 'CAP_DIR’, default_action => 'EXCLUDE’, capture_sts => TRUE, sts_cap_interval => 10); END; / Copyright © 2024, Oracle and/or its affiliates 34
35. DBMS_WORKLOAD_REPLAY.PROCESS_CAPTUREで変換 • キャプチャ・ファイルをリプレイ可能なフォーマットに変換 • 負荷のかかる処理となり、時間もかかるためテスト環境での実行を推奨 • RAC 環境でキャプチャした場合は、全インスタンスで生成されたキャプチャ・ファイルを一か所に集め、プリプロセスを実施 リプレイ・ファイルへの変換 BEGIN DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE( capture_dir => 'CAP_DIR’); END; / Copyright © 2024, Oracle and/or its affiliates 35
36. • 本番環境で取得されたワークロードの実行時間、並列度、コミット順を再現してリプレイ • リプレイ・クライアントがリクエストをDBサーバに送信 • クライアントはスレッドで実行されるため、1プロセスで複数並列度を再現可能。しかし負荷が大きい場合には必要に応 じてクライアントを複数プロセス起動する（1プロセス最大50セッション） • リプレイ・オプションを指定することで負荷の増大などリプレイのカスタマイズが可能 ワークロードのリプレイ Copyright © 2024, Oracle and/or its affiliates 36
37. • リプレイ・ファイルが格納されたディレクトリの指定 • リプレイをする際にユーザー・セッションが接続しにいくデータベースをマッピング • リプレイ実行時のパラメータを指定 • リプレイ・クライアント起動後にリプレイを開始 ワークロードのリプレイ DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => 'BASIC_REPLAY1', replay_dir => 'CAP_DIR'); DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION(connection_id => 1, 3 replay_connection => 'pdb1' ); BEGIN DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY (synchronization => TRUE, connect_time_scale => 100, think_time_scale => 100, think_time_auto_correct => TRUE, capture_sts => FALSE); END; / DBMS_WORKLOAD_REPLAY.START_REPLAY; Copyright © 2024, Oracle and/or its affiliates 37
38. リプレイ・オプションの指定 • PREPARE_REPLAYプロシージャのパラメータ • その他のパラメータはドキュメントを確認 https://docs.oracle.com/cd/F19136_01/arpls/DBMS_WORKLOAD_REPLAY.html#ARPLS-GUID-BC0B5C38-7C34- 481B-B1E1-FE32E4D0640A パラメータ 説明 synchronization リプレイの同期モードを設定 キャプチャ時の実行時間に基づく同期やコミット順序での同期などを指定可能 scale_up_multiplier リプレイ中にワークロードを倍増して実行 connect_time_scale ワークロードが取得されてから、セッションが接続されるまでの経過時間を変更 Copyright © 2024, Oracle and/or its affiliates 38
39. 多重度を上げることで将来的な負荷を再現 scale_up_multiplierの利用イメージ リプレイ開始 キャプチャ時に取得したワークロード 2倍に増大されたワークロード DMLはクエリ部分のみ実行 リプレイ終了 Copyright © 2024, Oracle and/or its affiliates 39
40. • SQL*Loaderなどのユーティリティを使用する、外部ファイルからのデータのダイレクト・パス・ロード • PL/SQL以外のアドバンスト・キューイング(AQ) • フラッシュバック問合せ • Oracle Call Interface(OCI)ベースのオブジェクト・ナビゲーション • SQL以外のオブジェクト・アクセス • 分散トランザクション • 取得された分散トランザクションはすべてローカル・トランザクションとしてリプレイされる • XAトランザクション • XAトランザクションは取得もリプレイもされないすべてのローカル・トランザクションは取得される Database Replayにおける制限事項 Copyright © 2024, Oracle and/or its affiliates 40
41. • JAVA_XAトランザクション • ワークロードでJAVA_XAパッケージが使用される場合、JAVA_XAファンクション・コールおよびプロシージャ・コールは 通常のPL/SQLワークロードとして取得される • ワークロード・リプレイ中の問題を回避するには、リプレイを正常に完了できるように、リプレイ・システム上の JAVA_XAパッケージの削除を検討 • データベース常駐接続プーリング(DRCP) • OUTバインドを使用したワークロード • 同期モードをOBJECT_IDに設定したマルチスレッド・サーバー(MTS)および共有サーバーのセッション • 移行されたセッション • 移行されたセッションのワークロードは取得される • ただし、ユーザーのログインやセッションの移行操作は取得されない • ユーザー・ログインやセッションの移行が有効でない場合、ワークロードが不正なユーザーによってリプレイされる可能 性があるため、リプレイでエラーが発生する可能性がある Database Replayにおける制限事項 Copyright © 2024, Oracle and/or its affiliates 41
42. 本番環境 テスト環境 Database Replay におけるライセンスの考え方 実データ 実データ キャプチャ・ファイル、リプレイ、レポート出力のために Oracle Real Application Testingのライセンスが必要 OCI の場合Enterprise Edition以上でOK Copyright © 2024, Oracle and/or its affiliates 42
43. 1. Real Application Testing (RAT) とは 2. SQL Performance Analyzer 3. Database Replay 4. お客様事例 5. Appendix Agenda Copyright © 2024, Oracle and/or its affiliates 43
44. Oracle Consultingの支援実績より SPA活用による SQL単体テスト の工数削減の例 顧客 国内保険業A社 サービス業B社 小売業C社 小売業D社 小売業E社 製造業F社 金融業G社 SQL数 280,000 5,700,000 100,000 70,000 10,000 8,600,000 110,000 従来手法工 数(人月) 175 105 63 44 6 200 69 RAT使用時 工数(人月) 4.0 1.5 1.0 1.4 1.6 3.0 1.0 削減工数 (人月) 171 103.5 62 42.6 4.4 197 68 ※従来手法工数の情報がない案件については以下方式で概算 • 1トランザクションは平均5つのSQLから構成されている • 1トランザクションのテストを実施するのに30分かかる Copyright © 2024, Oracle and/or its affiliates 44
45. オープン系共通基盤のハードウェアEOSLに伴う更改を実施 お客様事例： 国内大手保険会社様 400万円 オープン系共通基盤DB Migration（保険の契約・支払、Web関連システム） •画面数 ：約740画面 •バッチジョブ数：約200ジョブ 合計：約28万SQLのテストを実施する必要あり • テスト計画 ： 2人月 • アプリ解析 ： 4人月 • 検証環境の構築 ： 2人月 • テスト・検証 ：175人月 • チューニング ： 5人月 • テスト計画 ： 1人月 • アプリ解析 ： 0人月 • 検証環境の構築 ： 1人月 • テスト・検証 ： 1人月 • チューニング ： 1人月 400万円 1.88億円 28万SQL÷5トランザクション×0.5時間 ＝28,000時間(175人月) 28万SQLの10分の1のテストだと30.5人月。3,050万円 テスト・検証は、6人で、たった3日で完了 パフォーマンス変動なし ：94.38％ 改善 ： 5.37％ 劣化 ： 0.01％ SQL構文エラー ： 0.24％ RATを利用したアップグレードテスト 従来のアップグレードテスト テスト効率&精度の向上とプロジェクトのコスト&リスクの大幅削減に成功 高い効果が認められ標準プロセスに • 1回目： 11gR1 → 11gR2 • 2回目： 11gR2 → 12cR2 • 3回目： 12cR2 → 19c Copyright © 2024, Oracle and/or its affiliates 45
46. ハードウェアの更新やデータベースのアップグレードを 定常的なメンテナンス作業レベルに近づけ、 システム基盤更改という概念自体をなくしていきたい システム基盤更改は、システムを継続利用するために、５ 年サイクルで莫大なコストと人材リソースを投入せざるを得 ないという、まったくもったいない話 これをなくすことは、IT部門にとって悲願 テスト自動化ツール「Real Application Testing」を使うこと により、人手を介さずに本番環境で日々実行されている 処理をそのまま再現することができる https://special.nikkeibp.co.jp/atclh/ONB/22/oracle1226 /p2/index.html お客様事例：三井住友銀行様の取り組みについて 5年サイクルでの大規模基盤更改のコストよりも 定期的なアップデートの方がコスト削減につながる 高品質テストの自動化 ※テスト自動化ツール(RAT)を活用 ランニングコストとシステム更改コストを最大限抑制し、サス テイナブルな巨大データベース基盤に進化させ、戦略的な システム投資力の確保に貢献 システム要件 ソリューション ご評価 Copyright © 2024, Oracle and/or its affiliates 46
47. 1年目 2年目 3年目 4年目 5年目 6年目 コ ス ト 基盤運用 アップデート 基盤アップデート作業の定常作業化とテストの自動化による効果 • 5年毎のアップデートを行うよりも定常的なアップデートを行うこ とで作業毎のリスクの範囲を限定し、リスク及びコストの平準 化とコスト削減が可能(5年に1度DB/HW/アプリケーションを同 時に刷新することは大きなリスクとコストが発生する) • 基盤が常にアップデートされることでシステム基盤の品質/セ キュリティを維持(パッチが適用されないことによる運用リスクは コストとなる) • 定常作業として運用担当者がアップデートを実施(優秀な人 材リソースを生産性の高い業務に投入可能) 5年毎のアップデート • 5年毎に大きなリスクとコストが発生 • システム基盤の品質/セキュリティが保てない（不具合/セキュ リティホールが次回アップデートまで未修正） • 5年毎に優秀な人材確保が困難/優秀な人材をアップデート 作業に投入 1年目 2年目 3年目 4年目 5年目 6年目 コ ス ト 基盤運用 アップデート アップデートの定常作業化 Copyright © 2024, Oracle and/or its affiliates 47
48. 無償お試し環境のご紹介 • Oracle LiveLabsのワークショップの一つである、 Real Application Testing : SQL Performance Analyzer-Database Replayで無償でのお試し 実行が可能 • お客様のOCIテナント上にComputeを用意していただく か、Oracleの用意している一時環境(Sandbox)を利用 可能 • お客様ご自身でOCIテナント上に環境を構築する場 合、ComputeやBlock Storageなどの費用が発生 • Sandboxを利用する場合、構築から3時間で 環境が自動削除され、5時間まで延長可能 環境作成のためにOracleアカウントが必要 Real Application Testing LiveLabs Copyright © 2024, Oracle and/or its affiliates 48
49. Copyright © 2024, Oracle and/or its affiliates 49 • Oracle Database Testing ガイド https://docs.oracle.com/cd/F19136_01/ratug/index.html • SQLチューニング・ガイド - SQLチューニング・セットの管理 https://docs.oracle.com/cd/F19136_01/tgsql/managing-sql-tuning-sets.html#GUID-91D1B886-A6D7-40B8- 93D5-112B8C6E6AFE • Mandatory Patches for Database Testing Functionality for Current and Earlier Releases (Doc ID 560977.1) ドキュメント