Autonomous AI Databaseのワークロードリプレイ運用に向けて

いきなりまとめ

本blogの内容を Nano Banana にまとめてもらいました、若干微妙なとこもありますが、イメージはつかめるかなと思いますので冒頭に載せてみます。

はじめに

Autonomous AI Databaseでは週次のメンテナンスで自動的にパッチが適用される、という機能があります。

• パッチおよびメンテナンス・ウィンドウ情報の表示、パッチ・レベルの設定

この週次メンテナンスの自動パッチ適用において、ユーザ側はパッチの適用を止める、などの制御をおこなう事はできません（パッチ適用の停止リクエストをあげることは可能）。

そのため、Oracle側は「Real Application Testing」という本番のワークロードをテスト環境などで再現させる機能を提供しています。

Real Application Testingには様々な機能があり、メインの機能である「自動ワークロードリプレイ」や「ライブワークロードリプレイ」の機能は Autonomous AI Database Serverlessにおけるワークロードリプレイの活用について にて解説されています。

上記で紹介されている「自動ワークロードリプレイ」は、基本的に本番データベースでキャプチャしたワークロードが早期パッチ適用後に自動でクローンDBでリプレイされる、という形になります。
それはそれでよいのですが、どちらかというとジョブ的な形で管理したい、という場合もあると思います。そのような場合にどうやってマネージするか、という点についてまとめてみました。

基本的な流れは次のガイドを参照して下さい。

• 自律型AIデータベース・インスタンス間の取得とリプレイ

ワークロードリプレイ運用

前提としては「リフレッシュ可能クローンが早期パッチモードで準備されている」という点になります。
今回は次のような構成です

• 本番データベース（想定）：adbtest02
• 早期パッチクローン（想定）：adbclone2（リフレッシュ可能クローン）

さて、流れとしては以下になります。

1. 本番データベースでワークロードをキャプチャする
2. 早期パッチクローンをリプレイ用に変更する
3. 早期パッチクローンでワークロードをリプレイする

1．本番データベースでワークロードをキャプチャする

• START_WORKLOAD_CAPTUREプロシージャによるキャプチャの実行
  • 次のように期間で取得することも、期間を区切らずに取得することも可能

10分のキャプチャ実行例

ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
ALTER SESSION SET NLS_LANGUAGE = 'AMERICAN';
BEGIN 
   DBMS_CLOUD_ADMIN.START_WORKLOAD_CAPTURE(
        capture_name => 'CAPTEST01',
        duration     => 10);
   END;
/

• 負荷掛け（ワークロード）の実行

  • 負荷掛けSQLなどを実行

• キャプチャの終了

  • DBA_CAPTURE_REPLAY_HISTORY などで確認

キャプチャ終了確認

select name, status, type, start_time, end_time, database_name 
 from DBA_CAPTURE_REPLAY_HISTORY where name='CAPTEST01';

ここまで完了すると、本番データベース側でのワークロードキャプチャが完了し、内部的にはワークロードファイルが作成されてワークロードリプレイが実行できるようになります。

2．早期パッチクローンをリプレイ用に変更する

「早期パッチクローンをリプレイ用に変更」は ワークロード・リプレイ用のリフレッシュ可能クローンの自動準備 によると、DBMS_CLOUD_ADMIN.PREPARE_REPLAY というプロシージャを利用すると自動で準備できるようなのですが、ORA-4045エラーが出てしまい解決できなかったため、手動で準備をしました。
※ 推測ですが、リフレッシュ可能クローンが「読み取り専用（Read-Only）」モードのまま、プロシージャが内部的に書き込みを行おうとして権限エラー等が発生した可能性があります。一方で切り離してからPREPAREを実行すると、スタンドアロンでは実行できない、というエラーが発生しました（ワークロード前に戻す必要があるので、切り離すとPREPAREができないことは当然と言えば当然ですが）。

リプレイの実施には早期パッチクローン(adbclone2)が「キャプチャの開始と同じ状態」になっている必要があります。
今回の場合だと、CAPTEST01を開始した時刻になります。

• クローンのリフレッシュを行い、早期パッチクローン環境(adbclone2)を「CAPTEST01が開始された時刻」に合わせます

• クローン(adbclone2)を本番データベース(adbtest02)から切り離します

  • 本番データベース(adbtest02)側からでもクローン(adbclone2)側からでも、どちらからでも実行できますが、次の例は本番データベース側からの実行です
    

• リフレッシュ可能クローンが「更新中」の状態になります
  

• リフレッシュ可能クローンが「独立」状態になります（adbtest02から独立します）
  

補足：「切り離し」を行うと通常の独立したデータベースとなりますが、切断後24時間以内であれば、再度「リフレッシュ可能クローン」の状態に戻す（Reconnectする）ことが可能です。
これにより、一度Read-Writeにしてリプレイ試験を行った後、再び本番との同期が可能な状態に戻して翌週のパッチに備える、といった柔軟な運用も可能です。
※ただし、24時間を経過すると完全に独立したDBとなり、戻せなくなる点に注意してください。

3. 早期パッチクローンでワークロードをリプレイする

これで、早期パッチクローン(adbclone2)側でワークロードをリプレイする準備が整いました。DBMS_CLOUD_ADMIN.REPLAY_WORKLOADプロシージャをクローン側で実行すると、リプレイが実行されます。オブジェクトストレージ上のワークロードファイル等を実行することも可能です。

CAPTEST01としてキャプチャしたワークロードによるリプレイの実行

BEGIN 
  DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD(
      capture_name => 'CAPTEST01',
      replay_name => 'REPTEST01'
      );
END;
/

ワークロードの状況も、キャプチャ時と同じように DBA_CAPTURE_REPLAY_STATUS や DBA_CAPTURE_REPLAY_HISTORY で確認できます。
ワークロードが完了すると、リプレイレポートなどがオブジェクトストレージ上に作成されます。オブジェクトストレージのURLは DBA_CAPTURE_REPLAY_HISTORY の report_url を確認することで参照できます。URLは7日間有効となる、と記載されています。

まとめ

今回は PREPARE_REPLAY がうまく動作せずに時間がかかりましたが、基本的には分かりやすい流れになると思います。そのため、それぞれの環境の運用に組み込むことも難しくないのかな、と思いました。
GUIで実装した個所は、全部は確認していませんが OCICLI で実行することができると考えています。

なお、取得したレポートはGemini 3.0 Proに評価してもらいました、特に問題なさそうです！

リプレイはステータスCOMPLETEDで正常に終了しています。キャプチャされた50件のユーザーコールはすべて再現され、セッション失敗やエラーの発生も皆無であり、リプレイの忠実度は非常に高いと評価できます。
性能面では、リプレイ時のDB時間が約9分32秒（キャプチャ時10分50秒）となり、全体的に処理が高速化しました。主な待機イベントはCPUと、テーブルフルスキャン（SQL ID: csrpd6bumfnh6）に伴うdb file scattered readに集中しています。データの乖離もSELECT結果が1件（2%）のみであり、本番環境のワークロードを極めて正確に再現できています。

参考

早期パッチモードでリフレッシュ可能クローンの作成は、次のような手順で実施します。

• 本番データベースの「その他のアクション」から「クローンの作成」を実行
  

• 「リフレッシュ可能クローン」スイッチをONに
  

• メンテナンスのパッチ・レベルを「早期」に
  

• プロビジョニングが開始されます