Oracle AI Database 移行・アップグレード勉強会 - RAT活用編

Oracle AI Database 移行・アップグレード勉強会 RAT活用編日本オラクル株式会社クラウド事業統括製品事業統括 AI Data
Platform COE本部データベース・ソリューション部

1. Real Application Testing (RAT) とは 2. お客様事例 3. SQL
Performance Analyzer (SPA) とは 4. Database Replay とは 5. Appendix Agenda Copyright © 2026, Oracle and/or its affiliates 2

Real Application Testing (RAT) とは

◼ Oracle AI Database自身によるテスト機能(*) ◼ 移行・アップグレード・新機能導入などインフラ変更に伴うテストを自動化 ◼ 実SQL・ワークロードに基づくテストにより高い網羅度とテストの正確性を実現
◼ アプリケーションチームのテスト作業負荷を大幅に軽減 Real Application Testing (RAT)とは (*) Enterprise Editionのオプション機能現行環境(本番環境) テスト環境 AP DB SQL・ワークロードを取得 AP不要取得したSQL・ワークロード実SQL・ワークロードを取得することで、高い網羅度と正確性を実現 DB機能による自動化テストにより、低作業負荷で効率的にテスト Copyright © 2026, Oracle and/or its affiliates RATはデータベースに特化したテストツールです 4

• Upgradeやパッチ適用の適用時に使用することで、高品質かつ低作業コストでテストするための機能 • システム変更前後でのSQLの実行計画や性能を比較するレポートを生成 • 大きく分けて２種類の機能を使ってテスト工数を大幅に削減可能 Real Application Testing (RAT)とは
Real Application Testing SQL Performance Analyzer (SPA) • SQL単体テスト(性能/非互換検出) • 基本的にデータの更新処理は実行せず、 SQL単体でエラーや実行計画の変化を確認 • テストデータやクライアントなしでも実行できるなど実行のハードルが低い Database Replay (DB Replay) • システム全体のテスト • データの更新処理を行い、本番環境でのデータの動きを再現 • 本番環境でのデータの断面やクライアントが必要など実行のハードルは高い Copyright © 2026, Oracle and/or its affiliates 5

Copyright © 2026, Oracle and/or its affiliates 本番環境から SQL、ワークロードを取得評価
SPA 実行チューニング Database Replay 実行チューニング評価移行先環境へ適用 OK NG OK NG SPAレポートリプレイレポート/ AWRレポート STS キャプチャファイル SPAでSQL単体レベルの問題を解決してから Database Replayスループットのテストを行う (SPAだけ利用するケースも多い) SPA Database Replay SQL Performance Analyzer(SPA) と Database Replay 6

• 非互換の発生 • SQL構文確認の厳格化など、バージョンが変わった影響を受けて実行できなくなるSQLが発生する可能性がある • オプティマイザの挙動の変化 • オプティマイザの挙動が変わり、アップグレードすること
で性能が変わる可能性がある • 新機能の自動起動 • Oracle AI 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 © 2026, Oracle and/or its affiliates 7

• Upgrade時のSQL互換性チェック • SPAを使用し、数万本のSQLからエラーの発生するSQLを発見 • Upgrade時/RU適用時の性能試験 • SPAを使用し、数万本のSQLから実行計画や性能が変化するSQLを発見 • 定期パッチ適用による安定運用
• SPAにより、定期パッチ(セキュリティ、修正)の適用に必要なテストをルーティン化 • データの更新を含むワークロード全体の影響調査 • DB Replayにより一連のデータの流れまで再現して影響を調査 • 将来的な性能影響の調査 • DB Replayにより、既存のワークロードが将来的に増加した場合の影響を調査ユースケース Copyright © 2026, Oracle and/or its affiliates 8

お客様事例

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 © 2026, Oracle and/or its affiliates 10

オープン系共通基盤のハードウェア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 © 2026, Oracle and/or its affiliates 11

ハードウェアの更新やデータベースのアップグレードを定常的なメンテナンス作業レベルに近づけ、システム基盤更改という概念自体をなくしていきたいシステム基盤更改は、システムを継続利用するために、５年サイクルで莫大なコストと人材リソースを投入せざるを得ないという、まったくもったいない話これをなくすことは、IT部門にとって悲願テスト自動化ツール「Real Application Testing」を使うこと
により、人手を介さずに本番環境で日々実行されている処理をそのまま再現することができる https://special.nikkeibp.co.jp/atclh/ONB/22/oracle1226 /p2/index.html お客様事例：三井住友銀行様の取り組みについて 5年サイクルでの大規模基盤更改のコストよりも定期的なアップデートの方がコスト削減につながる高品質テストの自動化 ※テスト自動化ツール(RAT)を活用ランニングコストとシステム更改コストを最大限抑制し、サステイナブルな巨大データベース基盤に進化させ、戦略的なシステム投資力の確保に貢献システム要件ソリューションご評価 Copyright © 2026, Oracle and/or its affiliates 12

1年目 2年目 3年目 4年目 5年目 6年目コスト基盤運用
アップデート基盤アップデート作業の定常作業化とテストの自動化による効果 • 5年毎のアップデートを行うよりも定常的なアップデートを行うことで作業毎のリスクの範囲を限定し、リスク及びコストの平準化とコスト削減が可能(5年に1度DB/HW/アプリケーションを同時に刷新することは大きなリスクとコストが発生する) • 基盤が常にアップデートされることでシステム基盤の品質/セキュリティを維持(パッチが適用されないことによる運用リスクはコストとなる) • 定常作業として運用担当者がアップデートを実施(優秀な人材リソースを生産性の高い業務に投入可能) 5年毎のアップデート • 5年毎に大きなリスクとコストが発生 • システム基盤の品質/セキュリティが保てない（不具合/セキュリティホールが次回アップデートまで未修正） • 5年毎に優秀な人材確保が困難/優秀な人材をアップデート作業に投入 1年目 2年目 3年目 4年目 5年目 6年目コスト基盤運用アップデートアップデートの定常作業化 Copyright © 2026, Oracle and/or its affiliates 13

Copyright © 2026, Oracle and/or its affiliates • 一般的なSQL単体性能テストの場合一般的なテストとSPAを使用したSQL単体性能テストの違い（1/2）
テスト計画テスト対象アプリケーションの解析環境構築＆データ・アプリ準備テスト実施チューニング＆再テスト • テスト方式の検討 • テスト範囲の検討 • テスト粒度の検討 • テスト環境の検討 • テストデータの検討 • スケジュールの検討 • 判定基準の検討 • テスト対象アプリの選定 • テスト対象アプリの分析 • テストシナリオの作成 • テスト環境の構築(AP) • テスト環境の構築(DB) • 環境設定 • データ移行 • アプリ準備 • アプリの実行 • 実行計画の確認 • 性能変動の確認 • 非互換の確認 • チューニング対象絞り込み • チューニングの実施 • SQLの修正 • アプリの再実行 • 実行計画の確認 • 性能変動の確認一般的なSQL単体性能テストのプロセス全てエンジニアによる手作業で行われるためコストが掛かる。テスト計画時にはチューニング量が見えないため、SIerはリスク工数を乗せざるを得ず、工数見積もりが増加しがちアプリ解析とテスト実施には膨大な工数が掛かる 14

Copyright © 2026, Oracle and/or its affiliates 一般的なテストとSPAを使用したSQL単体性能テストの違い（2/2）テスト計画テスト対象アプリ
ケーションの解析環境構築＆データ・アプリ準備テスト実施チューニング＆再テスト • テスト方式の検討 • テスト範囲の検討 • テスト粒度の検討 • テスト環境の検討 • テストデータの検討 • スケジュールの検討 • 判定基準の検討 • テスト対象アプリの選定 • テスト対象アプリの分析 • テストシナリオの作成 • テスト環境の構築(AP) • テスト環境の構築(DB) • 環境設定 • データ移行 • アプリ準備 • アプリの実行 • 実行計画の確認 • 性能変動の確認 • 非互換の確認 • チューニング対象絞り込み • チューニングの実施 • SQLの修正 • アプリの再実行 • 実行計画の確認 • 性能変動の確認 SPAを利用したSQL単体性能テストのプロセス SPAを利用することで作業を大幅に削減でき、コスト削減ができた。テスト実施までを短期間で行えるため、アップグレードの影響を素早く確認可能工数を大幅に削減可能 ※薄グレー：SPAで削減できる作業 ※オレンジ：SPAで簡素化できる作業 ※グリーン：Tuning Advisorで簡素化できる作業 (別途Tuning Packが必要) SPAを活用した場合 15

クラウド環境を活用したRATによるテスト自動化 Copyright © 2026, Oracle and/or its affiliates BaseDB想定ケース ▸
前提事項（事前準備） ① 実行サーバ環境セットアップ ② パッチ適用前後の各ソフトウェアイメージ作成 ③ STS取得 (スクリプトで半自動化) ▸ テスト自動化スコープ ① 商用DB（BaseDBインスタンス前提）のオンデマンド・バックアップを取得 ② VCN/Subnetなどのテスト用NW環境作成 ③ バックアップからパッチ適用前バージョンの BaseDBインスタンス作成 ④ バックアップからパッチ適用後バージョンの BaseDBインスタンス作成 ⑤ パッチ適用前バージョンのDBに対してSPA実行 ⑥ パッチ適用後バージョンのDBに対してSPA実行 ⑦ 実行結果比較、レポート出力 X ▸ システム構成 OCI Region VCN（本番） Subnet Database System （商用DB） Subnet 実行サーバ Object Storage VCN（テスト自動化） Subnet Database System Database System バックアップ取得 SPA実行プロビジョニングプロビジョニング SPA実行（DBLINK）パッチ適用前バージョンパッチ適用後バージョン Ansible & Terraform 16

SQL Performance Analyzer (SPA) とは

本番環境で取得された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 © 2026, Oracle and/or its affiliates 18

Enterprise Managerを利用した場合 SPAレポート Copyright © 2026, Oracle and/or its affiliates
• テスト概要 • SQL文の数 • エラーのあるSQL分の数 • 比較軸 • 結果のサマリ • 1回目と2回目の試行における差異のサマリを表示 • SQL単体の差異 • 1回目と2回目の施行における SQL単体の差異を表示 19

APIを利用した場合 SPAレポート Enterprise Managerからの操作のほか、 API(DBMS_SQLTUNEなど)からの操作、HTMLやテキスト形式でのレポート出力も可能 Copyright © 2026, Oracle
and/or its affiliates 20

判断できること • エラーの有無 • エラー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 © 2026, Oracle and/or its affiliates 21

テスト目的に応じた環境準備 • ３段階の目的でテスト可能 • SQL互換性 • 実行計画の変化 • パフォーマンスの差異 •
段階に応じてSPA実行に必要な環境が変化する STS取得元の検討 • インプット情報としてカーソル・キャッシュやAWRなど、どの情報をもとに取得するか STS取得時の負荷と表領域使用量 • STSを取得する場合のリソース負荷はどれくらいか • SYSAUX表領域の増加量はどれくらいか SPA実行時の考慮ポイント Copyright © 2026, Oracle and/or its affiliates 22

SPAを実行するために必要な環境 • テスト目的に応じて必要な環境が変化する • テスト目的に応じて構成や実行の仕方も変化する次ページ以降でテスト目的に応じた構成について紹介テスト目的に応じた環境準備テスト目的オブジェクト定義オプティマイザ統計
実データ SQL互換性 ◯ SQL互換性実行計画 ◯ ◯ SQL互換性実行計画パフォーマンス ◯ ◯ ◯ Copyright © 2026, Oracle and/or its affiliates 24

本番環境テスト環境テスト目的：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 © 2026, Oracle and/or its affiliates 25

本番環境テスト環境テスト目的：実行計画の変化 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 © 2026, Oracle and/or its affiliates 26

本番環境テスト環境テスト目的：パフォーマンスの変化 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 © 2026, Oracle and/or its affiliates 27

• 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 © 2026, Oracle and/or its affiliates 28

最も精緻なテストを行いたい場合本番環境テスト環境テスト目的：パフォーマンスの変化 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 © 2026, Oracle and/or its affiliates 29

• Test Executeを指定した場合、SQLは最低2回、最大10回実行される • 最初の実行はバッファ・キャッシュの準備のためにのみ実行され、実行統計には含まれない • 2回目以降の実行結果における平均が実行統計となる • SQLが実行される回数は、SQLの実行時間の長さによって変化する •
実行時間が長いSQLは2回だけ実行され、実行時間が短いSQLは実行タイムアウトが発生するまで最大10回実行される Test ExecuteにおけるSQLの実行回数について Copyright © 2026, Oracle and/or its affiliates 30

• Oracle AI 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 © 2026, Oracle and/or its affiliates 32

３パターンから検討取得元メリットデメリット・注意点カーソル・キャッシュ • 実施に本番環境上で実行されているSQLをキャッシュから収集することが可能 • SQLの網羅性が高い
• 本番環境上のカーソル・キャッシュからの取得となるため、少なからず負荷がかかる AWR • 本番環境に負荷を与えずSQLを収集可能 • AWRに保存されるSQLのみが対象となるため網羅性が低い • 網羅性を上げるために取得間隔を小さくしてSQL収集を topnsql=MAXIMAMに設定すると、負荷が増大しSYSAUX表領域を大量に使用 SQLトレース • 実際に本番環境上で実行されているSQLを収集することが可能 • SQLの網羅性が高い • SEでも取得可能 • SQLトレースを有効化することによる本番環境への負荷が高い STS取得元の検討 Copyright © 2026, Oracle and/or its affiliates 33

共有SQL領域から直接STSにロード DBMS_SQLSET. CAPTURE_CURSOR_CACHE() • 一定の間隔、期間共有SQL領域内の情報をキャプチャし、STSに記録 • 引数 • sqlset_name
: STS名 • time_limit : 情報取得総時間。デフォルト1800(秒) • repeat_interval : 情報取得間隔。デフォルト300(秒) • capture_option : 以下のいずれかを指定 • INSERT : 新規SQL文のみ取得 • UPDATE : 既存のSQL文のみ取得 • MERGE : 新規・既存両方のSQL文を取得(デフォルト) 情報取得の負荷は軽微定期的に複数回取得する方法 Copyright © 2026, Oracle and/or its affiliates 共有プール上のカーソル・キャッシュ DBMS_SQLSET. CAPTURE_CURSOR_CACHE() STS 34

SQLカーソルを介してSTSにロード基本手順 1. 入力ソースからDBMS_SQLSET. SELECT_*()ファンクションでSQLカーソルを作成 • DBMS_SQLSET. SELECT_*()ファンクションは表関数 •
ファンクションの戻り値がSQLカーソル 2. 1.のSQLカーソルを入力としてDBMS_SQLSET. LOAD_SQLSET()プロシージャを使用してSTSに情報を格納入力ソースと対応プロシージャ • 共有SQL領域 : SELECT_CURSOR_CACHE() • AWR : SELECT_WORKLOAD_REPOSITORY() • SPAの比較タスク : SELECT_SQLPA_TASK() • SQLトレース : SELECT_SQL_TRACE() • 他のSTS : SELECT_SQLSET() コマンド実行時に一括取得する方法 Copyright © 2026, Oracle and/or its affiliates 各種ソース情報 DBMS_SQLSET. SELECT_*() SQLカーソル DBMS_SQLSET. LOAD_SQLSET() STS 35

キャプチャー時の負荷の考慮 • カーソルキャッシュからSQLをSTSに取得する場合、一度に多数のSQLをSTSにキャプチャする方式では、キャプチャしている時間でプロセッサコアを1つ占有することになります。カーソルキャッシュからの「一括取得(SELECT_CURSOR_CACHE／LOAD_SQLSET) 」で課題になるケースがあります。対処として「定期的な取得(DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET)」
を使うことを検討します。取得インターバル内に実行されたSQLの増分取得を行うことで1回あたりのSTSキャプチャ本数を減らし、かつSQLの網羅性を高めることが可能です。 STS取得方法の選定比較項目定期的に複数回取得コマンド実行時に一括取得本番負荷影響あり・CPU使用率への影響【低】あり・CPU使用率への影響【一定時間1コア占有】 (コア占有時間は共有プールのサイズ/対象SQL本数 /抽出フィルタ条件に依存) 収集期間長い (方針次第) 月次バッチや年次バッチなど、特定日に実行される処理も収集する場合は長い期間が必要となる。短い即時収集が可能。 SQL収集網羅性高い (方針次第) 定期的に取得件数をモニタリングすることでSQL本数の収束傾向が確認可能低い (方針次第) 実行時点でカーソル・キャッシュに存在するSQLのみが取得対象となる。 Copyright © 2026, Oracle and/or its affiliates 36

負荷 • 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 © 2026, Oracle and/or its affiliates 38

表領域使用量 • 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 © 2026, Oracle and/or its affiliates 39

STS格納時のフィルタ • SQL情報をSTSへ格納する際、不要なSQLを除外するため、フィルタリングの設計を行うことが重要 • DBMS_SQLTUNEパッケージ使用時に、”Basic Filter”機能を使用してフィルタリングが可能 • STSへ格納する際に件数を指定することも可能 STS使用のTIPS 項目
Filtering目的モジュール Data Pump処理を対象外とするスキーマ APの実行スキーマのみ対象とする PLAN_HASH_VALUE “0”のものは実行計画がないので取得しない SQL_テキスト特定のキーワードを持つSQLを取得対象しない ▪フィルタリング設計例 ※11.2.0.4から再帰SQLを除外するパラメータ”recursive_sql”が追加されています Copyright © 2026, Oracle and/or its affiliates 40

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 © 2026, Oracle and/or its affiliates 41

本番環境テスト環境 SPAにおけるライセンスの考え方 STS SPA STS STSはEnterprise Edition 標準機能のためライセンスは必要ない SPA試行、レポート出力のために
Oracle Real Application Testingのライセンスが必要 OCI の場合Enterprise Edition以上でOK Copyright © 2026, Oracle and/or its affiliates ※テスト環境側に新バージョンと旧バージョンの二つの環境を利用する場合は2環境にライセンスが必要 42

Database Replay とは

本番環境テスト環境 Database Replay の利用イメージクライアント APサーバー DBサーバー / ストレージ
リプレイ・クライアント DBサーバー / ストレージキャプチャ・ファイルリプレイ・ファイル 1.ワークロードを取得しキャプチャ・ファイルを生成 2.キャプチャ・ファイルをリプレイファイルに変換 3.リプレイファイルを使用してワークロードを再現データの更新も実施 4.分析レポートを出力実データ実データ Copyright © 2026, Oracle and/or its affiliates 44

ワークロード・リプレイ・レポート • キャプチャとリプレイのサマリを比較しテストの妥当性を判断 AWR期間比較レポート • キャプチャとリプレイのリソース使用量や待機イベントなどを比較 ASHレポート •
キャプチャとリプレイの差異をセッションレベルで分析 Database Replay実行後の分析に利用できるレポート Copyright © 2026, Oracle and/or its affiliates 45

ワークロード・リプレイ・レポート • キャプチャとリプレイのサマリを比較しテストの妥当性を判断 • Replay Statistics • キャプチャとリプレイでUser callsが同等になっている
ことを確認 • Replay Divergence Summary • Divergence Typeそれぞれの相違の割合が大きくないことを確認 • エラーやSession Failuresが大きい場合、データがキャプチャ時と同等になっているかを確認レポート分析 Copyright © 2026, Oracle and/or its affiliates 46

• エラーの違い • リプレイ時に発生した新規エラー • キャプチャ時に発生していたがリプレイ時に発生しなかったエラー • キャプチャ時に発生していたがリプレイ時に変異したエラー • データの違い
• キャプチャ時と異なる行数が変更されたDML • キャプチャ時と異なる件数が返されたSELECT • キャプチャ時とリプレイ時でデータを比較することによるデータの中身の違い (レポートでは表示されないため別途確認が必要) • パフォーマンスの違い • AWR、ASHレポートで比較 Database Replayの結果から判断できること Copyright © 2026, Oracle and/or its affiliates 47

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 © 2026, Oracle and/or its affiliates 48

DBMS_WORKLOAD_REPLAY.PROCESS_CAPTUREで変換 • キャプチャ・ファイルをリプレイ可能なフォーマットに変換 • 負荷のかかる処理となり、時間もかかるためテスト環境での実行を推奨 • RAC 環境でキャプチャした場合は、全インスタンスで生成されたキャプチャ・ファイルを一か所に集め、プリプロセスを実施リプレイ・ファイルへの変換 BEGIN
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE( capture_dir => 'CAP_DIR’); END; / Copyright © 2026, Oracle and/or its affiliates 49

• 本番環境で取得されたワークロードの実行時間、並列度、コミット順を再現してリプレイ • リプレイ・クライアントがリクエストをDBサーバに送信 • クライアントはスレッドで実行されるため、1プロセスで複数並列度を再現可能。しかし負荷が大きい場合には必要に応じてクライアントを複数プロセス起動する（1プロセス最大50セッション） • リプレイ・オプションを指定することで負荷の増大などリプレイのカスタマイズが可能ワークロードのリプレイ
Copyright © 2026, Oracle and/or its affiliates 50

• リプレイ・ファイルが格納されたディレクトリの指定 • リプレイをする際にユーザー・セッションが接続しにいくデータベースをマッピング • リプレイ実行時のパラメータを指定 • リプレイ・クライアント起動後にリプレイを開始ワークロードのリプレイ 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 © 2026, Oracle and/or its affiliates 51

リプレイ・オプションの指定 • 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 © 2026, Oracle and/or its affiliates 52 ※ Autonomous AI Databaseでは、synchronizationのみ利用可能

Autonomous AI DatabaseでのDatabase Replayの利用 Autonomous AI Database上でDatabase Replayを実行できます • GUIもしくはコマンド操作で実行可能
実行できる主なテスト内容: • Autonomous AI Database間のワークロード比較 • 非Autonomous AI DatabaseとAutonomous AI Database間のワークロード比較 • Autonomous AI Databaseのリフレッシュ可能クローンを活用した異なるバージョン間でのワークロード比較 • Autonomous AI Database間のリアルタイムでのワークロード比較(ライブ・ワークロード・リプレイ) 54 Copyright © 2026, Oracle and/or its affiliates BEGIN DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD ( capture_name ‘test’ --リプレイに使用するワークロード取得の名前 END; / 詳細についてはマニュアルをご確認ください: https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/autonomous-real-application-testing.html GUI操作画面 (Database Actions): コマンド操作で使用するDBMS_CLOUD_ADMINプロシージャ: DBMS_CLOUD_ADMINプロシージャのマニュアル: https://docs.oracle.com/ja-jp/iaas/autonomous-database- serverless/doc/dbms-cloud-admin.html

通常のパッチタイプ環境のワークロードを自動取得し、早期パッチ環境でそのワークロードを自動再生早期パッチ環境（ソースのリフレッシュ可能クローン）で週次パッチが適用されると、ソースでキャプチャされたワークロードが自動的に実行される ※早期パッチレベルが利用できるリージョンのみ(日本国内では東京リージョンで可能) 2026年2月時点自動ワークロード・リプレイ機能の有効化手順 1. リフレッシュ可能クローンをパッチレベルを早期パッチに設定して作成 2. ソース・データベースで以下を実行し、自動ワークロードリプレイの有効化とワークロードのキャプチャ設定を実施
55 Copyright © 2026, Oracle and/or its affiliates 自動ワークロード・リプレイ - パッチに対するワークロード・テストの自動化 Documentation: Test Workloads Against an Upcoming Patch blog: Safeguard Your Workloads Against Upcoming Patches in Autonomous Database BEGIN DBMS_CLOUD_ADMIN.ENABLE_FEATURE( feature_name => 'WORKLOAD_AUTO_REPLAY', params => JSON_OBJECT( 'target_db_ocid' VALUE 'OCID1.TENANCY.REGION..ID1', --リフレッシュ可能クローンのOCID（必須） 'capture_duration' VALUE 120, --ワークロードがキャプチャされる期間（1分～720分） 'capture_day' VALUE 'MONDAY', -- キャプチャをする曜日 'capture_time' VALUE '15:00')); -- キャプチャをスタートする時間 END; / Autonomous AI DatabaseでのDatabase Replayの利用

シンプルなGUI操作でDatabase Replayを実行 Copyright © 2026, Oracle and/or its affiliates 56
Database Actions※の機能として提供 ※ Database ActionsはAutonomous AI Databaseの開発、データ・ツール、管理、および監視機能を提供するWebベースのインターフェースです詳しくは、以下をご参考ください: https://speakerdeck.com/oracle4engineer/autonomous-database-database-actions-ji-neng-gai-yao Autonomous AI DatabaseでのDatabase Replayの利用

無償お試し環境のご紹介 • 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 © 2026, Oracle and/or its affiliates 58

Copyright © 2026, Oracle and/or its affiliates • Oracle Database
Testing ガイド https://docs.oracle.com/cd/G47991_01/ratug/index.html • SQLチューニング・ガイド - SQLチューニング・セットの管理 https://docs.oracle.com/cd/G47991_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) • PL/SQLプロシージャ DBMS_SQLTUNEのマニュアル https://docs.oracle.com/cd/G47991_01/arpls/DBMS_SQLTUNE.html#GUID-821462BF-1695-41CF-AFF7- FD23E9999C6A • PL/SQLプロシージャ DBMS_STATSのマニュアル https://docs.oracle.com/cd/G47991_01/arpls/DBMS_STATS.html#GUID-01FAB8ED-E4A3-4C3E-8FE2- 88717DCDDA06 ドキュメント 59

Oracle AI Database 移行・アップグレード勉強会 - RAT活用編

Oracle AI Database 移行・アップグレード勉強会 - RAT活用編

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

Oracle AI Database移行・アップグレード勉強会 - RAT活用編