Autonomous AI Database Serverlessにおけるワークロードリプレイの活用について

目次

1.はじめに
2.本文
3.纏め

1. はじめに

Autonomous AI Database Serverless（ADB）は週次の自動メンテナンスで常に最新・安全な環境を保てる一方、「毎週の変更が本番に与える影響を事前に把握したい」という運用上の懸念があります。

本記事では、「自動ワークロードリプレイ」と「ライブワークロードリプレイ」によるパッチ影響の事前検証手法を解説します。

これにより、実ワークロードを早期パッチ環境で正確に再現し、エラーやパフォーマンス差分を自動的に検証できます。

2. 本文

(2-1) Autonomous AI Database Serverlessのパッチ・メンテナンスの課題について

Autonomous AI Database Serverlessでは、週次で自動的にメンテナンスウィンドウが設定され、パッチ適用が実施されるという特性があります。この仕組みにより常に最新かつ安全な環境を維持できる一方で、以下のような運用上の懸念が指摘されることが多くあります。

☞メンテナンス影響を低減する運用ガイドラインとして、自動ワークロードリプレイやライブワークロードリプレイを使った安全なパッチ検証プロセスの提案をさせて頂きます。

(2-1-1) Autonomous AI Database Serverlessにおける早期パッチ（Early Patch）とは

●目的について
☞ADBにおけるパッチ適用方式の一つで、通常パッチよりも1週間早くパッチを適用できます。これにより、開発環境やテスト環境で本番環境への通常パッチ適用前に新しいパッチをテストし、影響を事前に確認することができます。

●適用について
☞お客様が適用させるパッチを選択できます。（早期パッチ or 定期パッチ）

(2-1-2) Autonomous AI Database Serverlessのパッチ・メンテナンスに関するよくある質問

(2-2) 自動ワークロードリプレイの活用方法

自動ワークロードリプレイとは、通常のパッチタイプ環境のワークロードを自動取得し、早期パッチ環境でそのワークロードを自動再生する自動ワークロードリプレイ機能が提供されました。早期パッチ環境（ソースのリフレッシュ可能クローン）で週次パッチが適用されると、ソースでキャプチャされたワークロードが自動的に実行されます。※早期パッチレベルが利用できるリージョンのみ(東京/大阪は可能)

☞自動ワークロードリプレイはプロシージャ実行につきスケジュール通りに繰り返しワークロードリプレイを行う。

(2-2-1) 自動ワークロードリプレイ機能の有効化手順

１．リフレッシュ可能クローンをパッチレベルを早期パッチに設定して作成
２．ソース・データベースで以下を実行し、有効化とオプションでワークロードのキャプチャ設定を実施

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;
/

Documentation: Test Workloads Against an Upcoming Patch(https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/autonomous-real-application-testing.html#GUID-0B11E425-1216-4B17-837D-5929FD13C86F)

blog: Safeguard Your Workloads Against Upcoming Patches in Autonomous Database(https://blogs.oracle.com/datawarehousing/post/auto-workload-testing-autonomous-database)

(2-2-2) 自動ワークロードリプレイのメリットや動作仕様について

●自動ワークロードリプレイを使うことのメリット

☞早期パッチ適用後に本番環境と同じワークロードをリフレッシュ可能クローンへ流して動作確認がとれる。
☞大規模システムであっても毎週のメンテナンスがあっても事前に動作確認ができる。
☞自動でテストができるため、大幅な工数削減と短期間でのテストができる。

●動作条件

☞リフレッシュ可能クローンで早期パッチを選択すること
☞週次パッチ適用済みであること
☞リフレッシュ可能クローンがリフレッシュ済みであること
☞ソースデータベースと同リージョンにリフレッシュ可能クローンがあること
☞DBMS Scheduler経由で実行されたワークロードは「ジョブ/バックグラウンド活動」と見なされ、キャプチャ対象外になります。

(2-2-3) 自動ワークロードリプレイの設定方法(CUI)

●Database Actionsの[開発]-[SQL]-[ワークシート]から以下のSQLを実行することで設定できます。
（設定コマンド例）

（設定確認コマンド例）

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

※実行スケジュール設定時に「金曜日」と「土曜日」は設定不可です。週次メンテナンス前後となるためです。
※nls_session_parametersのNLS_DATE_LANGUAGEがJAPANESEの場合には、ALTER SESSION SET NLS_DATE_LANGUAGE = ‘AMERICAN’で設定ください。

(2-2-4) 自動ワークロードリプレイの設定方法(GUI)

●Database Actionsの[管理]ー[ワークロードの取得/リプレイ]ー[自動取得/リプレイ]-[自動取得/リプレイのスケジュール]から設定できます。
（設定例）

(2-2-5) 自動ワークロードリプレイの動作確認

●Database Actionsの[開発]-[SQL]-[ワークシート]から以下のSQLを実行することで動作状態を確認できます。

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

(2-2-6) 自動ワークロードリプレイ実行後に再現されたワークロードの確認方法

●ADBからのイベントメッセージをメール受信することで以下の通り自動ワークロードの正常終了確認ができます。

※メッセージ受信設定の方法は以下より確認ください。
https://oracle-japan.github.io/ocitutorials/adb/adb503-monitoring/

☞キャプチャの開始

☞キャプチャの終了

☞リプレイの開始

☞リプレイの終了

●自動ワークロードリプレイ実行後に出力されたレポート（adb_replay_report.html）より、CaptureとReplayが正常終了したかを確認することができます。

●自動ワークロードリプレイ実行後に出力されるレポート（adb_replay_report.html）より、レポート対象期間に実行されたワークロードが記録されていることを確認できます。

サンプルで実行したプロシージャ”run_mixed_workload”
(※特定テーブルに対してDELETE,UPDATE,INSERT,SELECTを実行)が記録されています。
レポートの各項目（経過時間、消費したCPU時間、ユーザーI/O待機時間、論理読み取り、ディスク読み取りなど）においても同様です。
Capture側(ソースデータベース)、Replay側(リフレッシュ可能クローン)にも同じくレポートに記録されているので、正常にワークロードが動作していると判断できます。

※レポート（adb_replay_report.html）はDatabase Actionsの[管理]ー[ワークロードの取得/リプレイ]ー[実行したジョブ名]ー[レポート]からも取得できます。

●自動ワークロードリプレイ実行後に出力されたレポート（adb_replay_report.html）より、エラーが発生したかを確認することができます。

上記サンプルでは、WRC$のエラーが出力されています。
WRC$は、「Workload Replay Client（wrc）」が起動したリプレイ用セッションに自動で付与されるモジュール名です。

ORA-01031（権限不足）：リプレイ用ユーザにキャプチャ時と同等の権限がない、PDB/サービス切替やパッケージ実行権限の不足など
ORA-00001（一意制約違反）：リプレイ時点のデータがキャプチャ時と一致していない、同一主キーへの重複挿入、シーケンス/同時実行の差など
ORA-01008（バインド変数未設定）：パース差異で別実行計画/別SQLに化けた、NLSや環境差によるカーソル共有不可、モジュール側の条件分岐差など
ORA-06502（数値/値エラー）： NLS設定、文字コード、バッファ長、暗黙変換の差

☞システム環境によって、出力されるエラーは変わりますので随時エラーの発生原因調査や解消の対応をしてください。

(2-3) ライブワークロードリプレイの活用方法

ライブワークロードリプレイとは、本番環境で発生しているワークロード（SQL 実行やトランザクションの流れ）を、その場でリアルタイムにキャプチャし、指定したクローン環境へ即時再生できるライブワークロードリプレイ機能です。任意のタイミングでワークロードの収集を開始し、パッチ適用の事前検証などに活用できます。キャプチャされたワークロードは対象クローン上で正確に再現されます。

☞ライブワークロードリプレイはプロシージャ実行につき１回限りで即時ワークロードリプレイを行う。

(2-3-1) ライブワークロードリプレイ機能の有効化手順

１．リフレッシュ可能クローンをパッチレベルを早期パッチに設定して作成
２．ソース・データベースで以下を実行し、有効化とオプションでワークロードのキャプチャ設定を実施

BEGIN 
   DBMS_CLOUD_ADMIN.START_LIVE_WORKLOAD_REPLAY (
   capture_replay_name =>'LiveReplayTest',
   target_db_ocid      =>'OCID1.TENANCY.REGION..ID1',　--リフレッシュ可能クローンのOCID（必須）
   capture_duration    =>120,　--ワークロードがキャプチャされる期間（1分～720分）
   reconnect_target    =>TRUE
  );     
END;
/

(2-3-2) ライブワークロードリプレイのメリットや動作仕様について

●ライブワークロードリプレイを使うことのメリット

☞早期パッチ適用後に本番環境と同じワークロードをリフレッシュ可能クローンへ流して動作確認がとれる。
☞大規模システムであっても毎週のメンテナンスがあっても事前に動作確認ができる。
☞自動でテストができるため、大幅な工数削減と短期間でのテストができる。

●動作条件

☞リフレッシュ可能クローンで早期パッチを選択すること
☞週次パッチ適用済みであること
☞リフレッシュ可能クローンがリフレッシュ済みであること
☞ソースデータベースと同リージョンにリフレッシュ可能クローンがあること
☞DBMS Scheduler経由で実行されたワークロードは「ジョブ/バックグラウンド活動」と見なされ、キャプチャ対象外になります。

(2-3-3) ライブワークロードリプレイの設定方法(CUI)

●Database Actionsの[開発]-[SQL]-[ワークシート]から以下のSQLを実行することで設定できます。
（設定コマンド例）

※nls_session_parametersのNLS_DATE_LANGUAGEがJAPANESEの場合には、ALTER SESSION SET NLS_DATE_LANGUAGE = ‘AMERICAN’で設定ください。

(2-3-4) ライブワークロードリプレイの設定方法(GUI)

※現状設定方法なし

(2-3-5) ライブワークロードリプレイの動作確認

●Database Actionsの[開発]-[SQL]-[ワークシート]から以下のSQLを実行することで動作状態を確認できます。

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

(2-3-6) ライブワークロードリプレイ実行後に再現されたワークロードの確認方法

●ADBからのイベントメッセージをメール受信することで以下の通りライブワークロードの正常終了確認ができます。

※メッセージ受信設定の方法は以下より確認ください。
https://oracle-japan.github.io/ocitutorials/adb/adb503-monitoring/

☞キャプチャの開始

☞キャプチャの終了

☞リプレイの開始

☞リプレイの終了

●ライブワークロードリプレイ実行後に出力されるレポート（awr_live_replay_report.html）より、レポート対象期間に実行されたワークロードが記録されていることを確認できます。

サンプルで実行したプロシージャ”run_mixed_workload”
(※特定テーブルに対してDELETE,UPDATE,INSERT,SELECTを実行)が記録されています。
レポートの各項目（経過時間、消費したCPU時間、ユーザーI/O待機時間、論理読み取り、ディスク読み取りなど）においても同様です。
Capture側(ソースデータベース)、Replay側(リフレッシュ可能クローン)にも同じくレポートに記録されているので、正常にワークロードが動作していると判断できます。

※レポート（awr_live_replay_report.html）はDatabase Actionsの[管理]ー[ワークロードの取得/リプレイ]ー[実行したジョブ名]ー[レポート]からも取得できます。

●ライブワークロードリプレイ実行後に出力されたレポート（live_replay_report.txt）より、エラーが発生したかを確認することができます。

上記サンプルでは、以下のエラーが出力されています。

ORA-00932（型不一致）：キャプチャ/リプレイ間でバインド配列（owa.vc_arr）の型・長さ・NULL性が異なるなど
ORA-01403（データが見つかりません）：PL/SQLコードが期待するデータを取得できなかったなど
ORA-01024（OCI 呼び出しのデータ型不正）：引数のバインド型メタデータが不一致など

☞システム環境によって、出力されるエラーは変わりますので随時エラーの発生原因調査や解消の対応をしてください。

3. 纏め

Autonomous AI Database Serverlessにおけるワークロードリプレイの活用について纏め

Autonomous AI Database Serverlessでは週次で自動適用されるパッチにより常に最新・安全な環境を維持できますが、その影響を事前に把握したいという運用上の懸念が存在します。

本資料で紹介した 自動ワークロードリプレイ および ライブワークロードリプレイ を活用することで、本番環境の実ワークロードを早期パッチ環境で正確に再現し、早期パッチの影響によるパフォーマンスやエラー有無を自動かつ継続的に検証できます。

これにより、

☞パッチ適用前の影響把握とリスク低減
☞テスト工数削減と検証プロセスの標準化
☞安心して本番パッチを受け入れられる運用体制の確立

が実現します。

今後のパッチ・メンテナンス運用において、ワークロードリプレイを積極的に取り入れることで、より安全で持続可能なデータベース運用が可能になります。