Autonomous Database Replay (2024/01/31)
Autonomous Database Replay (2024/01/31)
https://blogs.oracle.com/coretec/post/adb-database-replay
投稿者： Ulrike Schwinn | Distinguished Data Management Expert
「Oracle Real Application Testingデータベース・リプレイを使用して、オンプレミスまたは他のクラウド・サービス・データベースからワークロードを取得し、Autonomous Databaseインスタンスでリプレイできます。これにより、オンプレミス・データベースまたは他のクラウド・サービス・データベースとAutonomous Databaseの間でワークロードを比較できます。」これは、Autonomous Databaseでワークロードをテストすることを検討する際に重要な文章です。
Oracle Real Application Testingの使用目的がわからないすべてのユーザーのために、短いintroduction.Real Application Testingを使用して投稿を開始すると、次のような質問に回答できます。
オンプレミス・データベースまたは任意のクラウド・データベースからATP-SやADW-SなどのAutonomous Databaseに移行する場合、一般的なデータベース・パフォーマンスをどのように検証または保証できますか。テストスクリプトなどを手動で実装せずに、現実的でない人工的なテストをどのように簡単に実現できますか?
Oracle Real Application Testingには、移行リスクの軽減に役立つ2つのテクノロジ(SQLパフォーマンス・アナライザ(SPA)とデータベース・リプレイ(DBリプレイ)が含まれています。どちらもオンプレミス・インストールとOracle Cloudデータベース製品で使用できます。Autonomous Databaseでは、これまではSQLパフォーマンス・アナライザのみがサポートされていました。SQLパフォーマンス・アナライザは、定義されたSQLワークロードの詳細な文分析に重点を置いています。SQLワークロードは、SQLチューニング・セット(STS)を介して使用可能になるSELECT文またはDML文で構成できます。ワークロードは2回実行されます。1回は変更前、その後は変更後です。結果は、経過時間、cpu_timeなどの様々なメトリックで測定された、個々の文の詳細な比較分析(変更前および変更後)です。しばらく前にこれらのテーマに関するブログ投稿を公開した機能を示すために、たとえば、Autonomous DatabaseでのSQLパフォーマンス・アナライザの使用をカバーするAutonomous DatabaseのSPA SQLパフォーマンス・アナライザを使用したAutonomous Databaseへのスムーズな移行のブログ投稿などです。
データベース・リプレイは、Autonomous Databaseで使用できます。記録(取得)されたワークロードをAutonomous Databaseのオンプレミスまたはクラウド・インストールからリプレイするために使用できます。リプレイするには1つの(!)文のみが必要です。これは、この新機能に関するディスカッション中に同僚からの提案に代わって、ブログのタイトル「Autonomous」データベース・リプレイにつながりました。:)
ノート: ADB-Dでのデータベース・リプレイ(専用インフラストラクチャ上のAutonomous Database)は、ADB-S (Autonomous Databaseサーバーレス)とは異なることに注意してください。Oracle Autonomous Database on Dedicated Exadata Infrastructureのドキュメントで「データベース・リプレイ」の章を参照してください。
このブログ投稿では、取得および取得したファイルのコピーからAutonomous Databaseサーバーレスでのリプレイまで、ワークロードのリプレイに必要なすべてのステップの概要を説明したいと思います。さらに、いくつかのレポートを追加して、結果を分析および比較しました。データベース・リプレイおよびOracle Database Cloudの経験がある場合は、Oracle Autonomous Database Serverlessの使用に関する章「Oracle Real Application Testingを使用したワークロードのテスト」で、必要なすべての情報が記載されている場合があります。
ノート: Autonomous Databaseインスタンスでワークロードを取得し、別のAutonomous Databaseインスタンスでリプレイできます。取得したワークロードは、フル・クローンまたはリフレッシュ可能クローンでリプレイできます。取得およびリプレイ・ターゲットは、一貫性のある論理状態である必要があります。詳細は、「Autonomous Databaseインスタンスでのワークロードの取得」の章を参照してください。
全体像を把握するには、次のステップが必要です。新しいデータベース・リプレイ機能のみに関心がある場合は、3番目のステップをお読みください。
- Capture/record a workload on a non-Autonomous Database
- Copy the capture files to the Object Store
- Replay a workload on Autonomous Database
- Monitor the replay and analyze the results
この例では、クラウドVM、Oracle SQL Developerでデータベース・ワークロードを使用して必要なデータをインポートし、プロセスおよびOracle Cloud Shellを監視して、取得したファイルを一括ロードし、レポート・ファイルを生成しました。
Autonomous Database以外のワークロードの取得/記録
本番システムでは、1回のコールで記録が開始されます。必須は、データベースの空の論理ディレクトリです(この例ではCAPDIR)。記録されるコマンドには特定の制限があります。これらは、マニュアルで事前に確認する必要があります。また、データベース・リンク、Webサービスなどの外部サービスに対する依存性を考慮し、明確にする必要があります。また、低負荷で取得を開始し、処理中のトランザクションをできるだけ少なくします。もちろん、最適なオプションはデータベースを停止することですが、これはほとんどの環境ではオプションではありません。
したがって、ワークロードの取得を開始する前に、まずデータベース・ワークロードを取得するための前提条件を完了する必要があります。前提条件は、データベース・ワークロードを取得するための前提条件で説明されています。ワークロード取得オプションの説明に従って、ワークロード取得オプションも確認する必要があります。
ワークロードの取得中に、接続文字列、SQLテキスト、バインド値などの様々な情報が格納されます。ワークロードの取得を開始すると、Oracle Databaseに転送される外部クライアントからのすべてのリクエストが追跡され、取得ファイルと呼ばれるバイナリ・ファイルに格納されます。
-- CREATE OR REPLACE DIRECTORY capdir as '<directory>';
-- grant read, write on directory capdir;
execute DBMS_WORKLOAD_CAPTURE.START_CAPTURE(name=>'C3', dir=>'CAPDIR');取得(ここではC3という名前)は、次のコマンドで手動で終了するか、またはSTART_CAPTUREコールで追加の期間引数を指定して自動的に終了します。
execute DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();ワークロード取得では、取得ファイルを含む2つのサブディレクトリcapおよびcapfileが作成されます。
取得システムでの最後のアクションは、対応するAWRスナップショットのエクスポートで、パフォーマンス・データ情報も取得ディレクトリに保存します。次のコマンドは、AWRスナップショットのエクスポートを開始します。
execute DBMS_WORKLOAD_CAPTURE.EXPORT_AWR(capture_id =>'CAPDIR');取得ファイルのオブジェクト・ストアへのコピー
リプレイを開始する前に、取得中に作成された取得ファイルを含むcapおよびcapfilesサブディレクトリをオブジェクト・ストレージの場所にアップロードする必要があります。capおよびcapfilesサブディレクトリは、オブジェクト・ストレージにアップロードするときに、そのディレクトリ構造を維持する必要があります。OCIコマンドライン・インタフェース(CLI)と一括アップロード・コマンドを使用して、特定のディレクトリおよびすべてのサブディレクトリ内のすべてのファイルをアップロードしました。OCI Cloud Shellにはすでにインストール済のOCI CLI環境があるため、一括アップロード用に決定しました。ネームスペース(-ns) (ここではmynamespace)、バケット名(-bn) (ここではbucketus)およびソース・ディレクトリ(--src-dir) (ここでは/home/ulrike_sch/rat_dir)のみを指定する必要があります。その後、次のコマンドを使用してすべてのファイルをコピーできます。
oci os object bulk-upload -ns mynamespace -bn bucketus --src-dir /home/ulrike_sch/rat_dirヒント: 次の名前空間があります。
oci os ns get詳細は、OCI CLIのドキュメントを参照してください。
Autonomous Databaseでのワークロードのリプレイ
リプレイを実行するには、まずテスト・システムを作成して設定する必要があります。取得およびリプレイ・システム上のデータベースの一貫性ステータスが同じであることが重要です。MV2ADBツールまたはその他の方法を使用して、データをAutonomous Databaseに移行できます。私のケースでは、Data Pumpエクスポートで十分でした。SQL Developerインポート・ウィザードを使用して、必要なデータをAutonomous Databaseにインポートしました。データベース・アフターワードをリセットするには、Data PumpインポートまたはAutonomous Databaseのポイント・イン・タイム・リカバリ機能を使用できます。
リプレイを実行するには、1つのコマンドのみが必要です。個別の前処理コマンドおよびリプレイ・クライアントの開始などは必要ありません。DBMS_CLOUD_ADMIN.REPLAY_WORKLOADを実行して、Autonomous Databaseでワークロード・リプレイを開始するだけです。このステップでは、Oracle Cloud Shellも使用しました。もちろん、SQL*Plusインスタント・クライアントまたはSQL Developerも使用できます。
Oracle Cloud Shellを介してAutonomous Databaseに接続する方法がわからない場合は、Kris Riceのブログ投稿SQLclおよびOCI Cloud Shellで概説されているステップに従うことができます。
私の場合は、次のようにWallet_DB19c.zipという名前のウォレットzipファイルを生成しました。
oci db autonomous-database generate-wallet --autonomous-database-id --file Wallet_DB19c.zip --password 'xxxxxxx'次に、次のようにSQLclと接続しました。
sql -cloudconfig Wallet_DB19c.zip admin@db19c_lowこれで、replayコマンドを実行する準備ができました。
BEGIN
DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD(
location_uri => 'https://objectstorage.eu-frankfurt 1.oraclecloud.com/n/mynamespace/b/bucketus/o/',
credential_name => 'CRED_TEST',
synchronization => TRUE,
process_capture => TRUE);
END;
/credential_nameパラメータは、Object Storageバケットにアクセスするための資格証明を指定します。credential_name値を指定しない場合は、DEFAULT_CREDENTIALが使用されます。同期パラメータは、ワークロード・リプレイ時に使用される同期方法を指定します。TRUE値は、同期がSCNベースであることを示し、Falseは、リプレイが時間に基づいていることを意味します。process_captureは、process_capture値を指定する必要があるかどうかを指定します。TRUE値は、リプレイにprocess_captureが含まれていることを示します。必要なのは
一度やった。詳細は、ドキュメントを参照してください。
これで終わりです。結果を監視または分析するための追加のステップは新規ではないため、Oracle Testingのドキュメントを参照してください。この投稿の完全な例を提供するために、私は次のセクションでこれらのステップを追加しました。
リプレイの監視と結果の分析
次の問合せは、取得メトリックおよび前処理ステータスの詳細をリストします。これは、ワークロードを取得した本番システム、またはAutonomous Databaseのリプレイ・システム上で使用できます。次に例を示します。
col status format a11
col name format a10
select id, name, status, errors, awr_exported, duration_secs, LAST_PROCESSED_VERSION, dbtime, user_calls, user_calls_unreplayable, capture_size/1024/1024 capsize
from dba_workload_captures;
ID NAME STATUS ERRORS AWR_EXPORTED DURATION_SECS LAST_PROCESSED_VERSION DBTIME USER_CALLS USER_CALLS_UNREPLAYABLE CAPSIZE
_____ _______ ____________ _________ _______________ ________________ _________________________ _______________ _____________ _____________ _____________ __________________________
21 C3 COMPLETED 298 YES 2346 19.16.0.1.0 1381157902 1381157902 34798 8285 24.73380947113037109375 リプレイ中およびリプレイ後に、次の問合せを実行して、一部のリプレイ統計に関する情報を取得できます。
alter session set nls_date_format='dd.mm.yyyy hh24:mi';
select name, id, dbversion, status, pdb_level, user_calls,
awr_exported, awr_begin_snap, AWR_end_snap, awr_dbid, start_time, end_time
from dba_workload_replays;
NAME ID DBVERSION STATUS PDB_LEVEL USER_CALLS AWR_EXPORTED AWR_BEGIN_SNAP AWR_END_SNAP AWR_DBID START_TIME END_TIME
____________________ _____ ______________ ____________ ____________ _____________ _______________ _________________ _______________ ____________ ___________________ ___________________
REPLAY_1658417914 2 19.16.0.1.0 COMPLETED Y 34728 YES 82 85 932641089 21.07.2022 15:41 21.07.2022 18:41
REPLAY_1658754270 12 19.16.0.1.0 COMPLETED Y 34728 YES 176 177 932641089 25.07.2022 13:05 25.07.2022 13:38 SQL Developerを使用する場合は、SQLワークシートを使用して問合せを実行できます。
リプレイ後、レポートを生成してリプレイに関する情報を取得し、取得と比較したり、replays.Theと呼ばれる追加のワークロード・リプレイ・レポートと比較したりできます。このレポートには、取得システムとリプレイ・システム間のパフォーマンスの差異を測定するために使用できる情報が含まれます。
ワークロード・リプレイ・レポートを生成するには、Oracle Cloud ShellでSQLclを使用しました。
variable c clob
set long 1000000 heading off pagesize 0
spool replayreport.html rep
select dbms_workload_replay.report(replay_id=>12, format=>'HTML') from dual;
spool offその後、生成されたHTMLレポートを自分のPCにダウンロードして、ブラウザで開きます。
リプレイ・レポートのセクションを次に示します。
次に、いわゆる比較期間レポートを生成し、パフォーマンス特性に関するより詳細なインサイトも提供しました。たとえば、リプレイをその取得または同じ取得の別のリプレイと比較できます。このレポートでは、ワークロード・リプレイのパフォーマンスと、取得した元のsystem.Throughoutのパフォーマンスを比較します。レポート「取得」は取得した元のシステムを参照し、「リプレイ」はリプレイしたワークロードを参照します。最も信頼性の高い実験では、2つのリプレイを比較します。最初のリプレイでは、システムを変更せずに、取得したシステムを可能なかぎり模倣しようとします。2番目のリプレイは最初のリプレイと似ていますが、1つの変更をテスト変数として適用します。
最初に、取得実行からのAWRスナップショットを使用可能にする必要があります。次のコマンドは、EXPORT_AWRプロシージャを使用して元の取得システムから以前にエクスポートされたAWRスナップショットが、指定された取得IDに関連付けられたAWRスナップショット(ここでは21)をインポートします。ステージング・スキーマは、現在のデータベース内の有効なスキーマである必要があります。このスキーマは、リプレイ・ディレクトリからSYS AWRスキーマへのAWRスナップショットのインポート中にステージング領域として使用できます。SYSスキーマは有効な入力ではありません。
select dbms_workload_capture.import_awr(capture_id => 21, staging_schema => 'DWH_DATA') from dual;
DBMS_WORKLOAD_CAPTURE.IMPORT_AWR(CAPTURE_ID=>21,STAGING_SCHEMA=>'DWH_DATA')
______________________________________________________________________________
196792466 これにより、AWRスナップショットのインポートに使用された、ランダムに生成された新しいデータベースIDが返されます。同じ値が、DBA_WORKLOAD_REPLAYSビューのAWR_DBID列にあります。
比較期間レポートを生成し、再度ダウンロードできます。
variable report_bind clob
begin DBMS_WORKLOAD_REPLAY.COMPARE_PERIOD_REPORT (
replay_id1 => 12,
replay_id2 => null, -- comparition with the capture run
format => DBMS_WORKLOAD_CAPTURE.TYPE_HTML,
result => :report_bind);
end;
/
set heading off long 1000000 longc 1000000 pagesize 0
spool comparereport.html rep
print report_bind
spool offパラメータreplay_id1およびreplay_id2は、リプレイがリクエストされる様々なリプレイIDを指定するために使用されます。2番目のIDがNULLの場合、比較は取得実行で行われます。formatパラメータは、レポート形式を指定します。有効な値は、DBMS_WORKLOAD_CAPTURE.TYPE_HTMLおよびDBMS_WORKLOAD_CAPTURE.TYPE_XMLです。結果パラメータは、レポートの出力(CLOB)に使用されます。バインド変数report_bindを使用して、出力を格納し、後で出力しました。
次に、期間比較レポートのセクションを示します。
分析の詳細情報が必要な場合は、SQL DeveloperのDBAウィンドウを使用してAWRレポートを生成できます。
まとめ
Oracle Real Application Testingの機能を使用すると、Oracle Databaseの実際のテストを実行できます。本番ワークロードを取得し、本番デプロイメントの前にこれらのワークロードに対するシステム変更の影響を評価することで、Oracle Real Application Testingは、システム変更に関連する不安定性のリスクを最小限に抑えます。SQLパフォーマンス・アナライザおよびデータベース・リプレイは、Oracle Real Application Testingの主要なコンポーネントです。テストされるシステム変更の性質と影響、およびテストが実行されるシステムのタイプに応じて、どちらかまたは両方のコンポーネントを使用してテストを実行できます。新しい拡張機能により、両方のコンポーネントがAutonomous Databaseで使用できるようになりました。ワークロードをリプレイするには、1つの(!)コマンドのみが必要です。Autonomous Database環境で取得したワークロードをリプレイするために、リプレイ・クライアントの個別の前処理、調整および開始、初期化および準備コマンドは必要ありません。これにより、Autonomous Databaseでのワークロードのテストが非常に簡単かつ簡単になります。
興味深いリンク
- Documentation Using Oracle Autonomous Database Serverless chapter "Test Workloads with Oracle Real Application Testing"
- General Database Documentation: Part II Database Replay
- Documentation DBMS_CLOUD_ADMIN
- Documentation Oracle Autonomous Database on Dedicated Exadata Infrastructure chapter "Database Replay"
- Blog Posting: Smooth transition to Autonomous Database using SPA
- Blog Posting SQLcl and OCI Cloud Shell
- OCI CLI command reference
コメント
コメントを投稿