1. はじめに
本番の Autonomous AI Database Serverless（以下 ADB-S）に、TB 級のデータをまとめて入れる場面を考えます。Data Pump のインポート（impdp）や大きな表の作り直しのように、REDO を大量に出す処理です。東京のデータベースの DR 用に、大阪にスタンバイ（クロスリージョンの Autonomous Data Guard）を置いていると、その間に大阪のスタンバイがどれだけ遅れるのかが気になります。
このスタンバイは、ADB-S の公式ドキュメントでは「リモート・ピア」や「ディザスタ・リカバリ・ピア（DR ピア）」と呼ばれ、指標や課金の説明でも「ピア」と書かれています。この記事では「大阪のスタンバイ」と書き、公式の文を引くところだけ「ピア」を使います。以下、東京のプライマリを「東京」、大阪のスタンバイを「大阪」と書きます。
遅れを見る指標として、OCI Monitoring には PeerLag があります。指標の一覧には次のように書かれています1。
The total time in seconds by which the Disaster Recovery peer lags behind its Primary database.
（DR ピアがプライマリより遅れている合計の秒数）
試しに、impdp で約 120 GB の REDO を出すインポートを実行すると、大阪の PeerLag は最初から最後まで 0 秒でした。この 0 秒が「大阪が東京に追いついている」ことを意味するのかを、大阪の適用を意図的に止めたり、大阪の中のデータを読んだりして確かめました。
1.1. 結論（先出し）
-
PeerLagは、大阪の適用を止めて約 120 GB の REDO を未適用にした時点でも 0 秒だった。0 秒は、大阪が追いついている根拠にならない - 大阪のリカバリの記録の適用速度は毎秒 約 550〜590 MB で、東京の REDO が最も速かった約 1 分（毎秒 約 600〜660 MB）とほぼ同じだった
- 適用を止めて溜めた約 120 GB は、通常のスタンバイに戻した直後に始まったリカバリが、実働 約 4 分で適用し終えた
- 大阪を開いて中のデータを読む方法では、インポート中の遅れは測れなかった。開くまでの変換に 6〜15 分かかり、適用が止まった時刻も分からない
1.2. 検証ゴール
| # | 確かめること | 確認できれば OK の条件 |
|---|---|---|
| 1 |
PeerLag は、大阪の適用の遅れを表すか |
大阪の適用を止めたときに PeerLag が伸びるかが分かる |
| 2 | 大阪の適用速度は、東京の REDO の生成に追いつけるか | 大阪の適用速度と東京の REDO の生成速度を並べて比べられる |
| 3 | 溜まった REDO に、大阪はどれだけで追いつくか | 適用を再開してから、溜めた分を適用し終えるまでの時間が分かる |
2. 検証環境
| 項目 | 内容 |
|---|---|
| 東京（プライマリ） | ADB-S（ATP）・ap-tokyo-1・26ai・16 ECPU・ECPU の自動スケールなし |
| 大阪（スタンバイ） | ap-osaka-1・クロスリージョンの Autonomous Data Guard・16 ECPU（東京と同じ値になる） |
| データ | 共有サンプルの SSB.LINEORDER から切り出した 20 表（表 約 82 GB・索引 約 40 GB）。impdp の並列度 16 で 1 回あたり約 120 GB の REDO が出る |
大阪のスタンバイは、基本の ECPU 数と東京の 2 倍のストレージの分が課金されます。東京を止めると、東京と大阪のどちらも ECPU は課金されません2。
3. 構成と確かめ方
3.1. 構成
図 1: 全体の構成
東京へ手元の PC から impdp でインポートし、東京は REDO を大阪へ送ります。大阪は 1 つのデータベースで、通常のスタンバイとスナップショット・スタンバイを切り替えて使いました。計測スクリプトは東京の REDO 量（GV$SYSSTAT の redo size の全インスタンスの合計）と、大阪の PeerLag を約 1 分ごとに記録します。
3.2. 確かめ方
大阪の遅れは次の 3 つの方法で見ました。
| 方法 | 何が分かるか | 試した章 |
|---|---|---|
通常のスタンバイのまま PeerLag を見る |
公式の指標で遅れが見えるか | 4.1 章 |
大阪の適用を止めて PeerLag を見る |
指標が遅れに反応するか | 4.2 章 |
| 大阪を読み書きで開き、中の記録とデータを読む | 適用速度、溜めた分を適用し終えるまでの時間、中のデータで遅れが測れるか | 4.2 章・4.3 章 |
大阪のスタンバイには、通常は接続できません。スナップショット・スタンバイに変えると読み書きで開けますが、その間は REDO を受け取るだけで、通常のスタンバイに戻すまで適用しません34。3 つ目の方法はこの仕組みを使います。
4. 試したこと
4.1. 通常のスタンバイのままインポートする
図 2: 通常のスタンバイのままインポートする
大阪を通常のスタンバイにしたまま、並列度 16 でインポートしました。インポートには約 14 分かかり、REDO の大半は最初の約 6 分に出ました。この間、大阪の PeerLag を 1 分ごとに見ました。
4.2. 大阪のスタンバイの適用を止めてインポートする
図 3: 大阪のスタンバイの適用を止めてインポートする
4.1 章で PeerLag が 0 秒のままだったので、大阪の適用を止めたときに PeerLag が伸びるかを確かめました。インポートの前に大阪をスナップショット・スタンバイに変え、同じインポートを実行し、終わってから通常のスタンバイに戻しました。戻したあと、大阪が溜まった REDO をどれだけの時間で適用し終えたかを、大阪の中のリカバリの記録（v$recovery_progress）で読みました。
大阪をスナップショット・スタンバイに変えるコマンド
# 大阪のスタンバイをスナップショット・スタンバイに変える（戻すときは false）
oci db autonomous-database change-disaster-recovery-configuration \
--profile ADMIN --region ap-osaka-1 \
--autonomous-database-id <大阪のスタンバイの OCID> \
--is-snapshot-standby true
変換が終わったかは、get の lifecycle-state と role を数秒ごとに読んで確かめます。--wait-for-state に STANDBY を含めると、変換を始める前の状態がすでに STANDBY なので、コマンドはすぐに返ります。
4.3. インポート中に大阪のスタンバイを開いて中のデータを読む
図 4: インポート中に大阪のスタンバイを開いて中のデータを読む
PeerLag のほかに遅れを確かめる手段として、大阪の中のデータを読む方法を試しました。東京に小さな表（以下、ハートビート表）を作り、1 秒ごとにその時点の時刻を 1 行書いてコミットし続けます。インポートの開始と同時に大阪をスナップショット・スタンバイに変え、開いたら大阪のハートビート表の最大の時刻を読みます。比べるために、負荷をかけないときにも同じ手順で変換しました。
ハートビート表に書き続ける PL/SQL と、読む流れ
-- 東京で書き続けるハートビート（時刻は UTC）
-- 止めるときは別のセッションで admin.hb_stop に 1 行入れてコミットする
declare
n number;
begin
for i in 1 .. 3600 loop
insert into admin.hb values (sys_extract_utc(systimestamp));
commit;
select count(*) into n from admin.hb_stop;
exit when n > 0;
dbms_session.sleep(1);
end loop;
end;
/
図 5: ハートビート表で大阪に入っていたデータの時刻を読む流れ
5. 分かったこと
5.1. PeerLag は大阪の適用を止めても 0 秒のまま
図 6: 東京の REDO の速さと大阪の PeerLag。上は通常のスタンバイのまま、下は大阪の適用を止めた回
通常のスタンバイのままでは、インポート中も PeerLag は 0 秒のままでした。大阪の適用を止めた回でも、PeerLag は伸びませんでした。止めている間は PeerLag が記録されない時間帯があり、記録された点はすべて 0 秒でした。約 120 GB の REDO をまだ適用していない時点の点も 0 秒です（付録 7.1）。
Oracle の高可用性の手引き（Maximum Availability Architecture）の ADB-S の章には、適用の遅れはコンソールの Peer Lag で見ると書かれています。同じ節には、この値は「POD 全体のもので、自分の Autonomous Database だけのものではない」とも書かれています5。
5.2. 大阪の適用速度は東京の REDO の山とほぼ同じ
図 7: 大阪の適用速度（v$recovery_progress）と、東京の REDO が最も速かった約 1 分
通常のスタンバイのままインポートした回で、大阪のリカバリの記録から読んだ適用速度は、平均で毎秒 553.5 MB、最大で毎秒 587.5 MB でした。東京の REDO が最も速かった約 1 分は、4 回で毎秒 600.1〜663.1 MB です。東京の REDO が毎秒 600 MB を超えたのは、どの回も開始から 1〜2 分後の約 1 分だけでした。
5.3. 溜めた約 120 GB は戻してから約 4 分で適用し終えた
適用を止めた回では、通常のスタンバイに戻す処理が 06:56:03 に終わり、06:56:40 に大阪のリカバリが始まりました。このリカバリは REDO のファイル 31 本を実働 242 秒で適用し、最後に適用した REDO の時刻は 06:58:03 でした。インポートが終わったのは 06:53:58 なので、止めている間に溜めた REDO は、このリカバリで適用し終えています（付録 7.1）。
5.4. 大阪の中のデータでは遅れを測れなかった
ハートビート表で読んだ結果は次のとおりです。
| 回 | 変換の依頼から、大阪に入っていた最後のハートビートまで | 変換の作業の所要時間 |
|---|---|---|
| 負荷なし（2 回） | 65.0 秒・111.9 秒 | 5 分 41 秒・7 分 37 秒 |
| インポート中（2 回） | 51.7 秒・301.3 秒 | 7 分 2 秒・14 分 51 秒 |
大阪で適用が止まった時刻は、今回取った記録からは分かりません。そのため、最後のハートビートの時刻から遅れを出すことはできませんでした。負荷をかけないときでも、依頼から最後のハートビートまでの秒数は 65.0 秒と 111.9 秒に分かれました。変換の作業には 5 分 41 秒〜14 分 51 秒かかりました。
インポート中の 2 回目（付録 7.1.4 の変換を挟んだ回 2）では、インポートの開始から約 5 分後（09:14:36.9）までの東京のデータが大阪に入っていました。東京の REDO が最も速かった区間（開始から 1〜2 分後）の分は、この時点までに適用されていたことになります。
大阪の中のデータを読む方法は、今回試した範囲ではスナップショット・スタンバイに変える方法しか見つかりませんでした（2026 年 10 月時点）。変換の間と開いている間は適用が止まるので、本番の DR の監視には使えません。
6. まとめ
ADB-S の東京で約 120 GB の REDO を出すインポートを実行し、大阪のスタンバイが追いついているかを確かめました。PeerLag は大阪の適用を止めても 0 秒のままで、0 秒は大阪が追いついている根拠になりませんでした。大阪のリカバリの適用速度は東京の REDO の最も速い区間とほぼ同じで、適用を止めて溜めた約 120 GB は、戻してから実働 約 4 分で適用し終えました。大阪の中のデータを読んで遅れを測る方法は、変換に時間がかかり、適用が止まった時刻も分からないため、遅れは測れませんでした。今回測ったのは、16 ECPU・約 120 GB の REDO までです。
7. 付録
7.1. 計測値
時刻はすべて 2026 年 10 月 25 日の日本時間です。
7.1.1. インポートの各回と東京の REDO
REDO 量は GV$SYSSTAT の redo size を全インスタンスで合計した差分、REDO が最も速かった区間は約 1 分ごとの差分の最大です。
| 回 | 大阪の状態 | インポートの時間 | REDO 量 | REDO が最も速かった区間 |
|---|---|---|---|---|
| 通常のスタンバイの回 | 通常のスタンバイ | 06:11:31〜06:26:02（871 秒） | 120,933,235,556 バイト | 毎秒 651.4 MB |
| 適用を止めた回 | スナップショット・スタンバイ | 06:40:28〜06:53:58（810 秒） | 120,917,832,144 バイト | 毎秒 642.8 MB |
| 変換を挟んだ回 1 | 通常 → 変換中 | 08:19:32〜08:34:03（871 秒） | 120,924,717,792 バイト | 毎秒 600.1 MB |
| 変換を挟んだ回 2 | 通常 → 変換中 | 09:09:35〜09:24:05（870 秒） | 120,924,031,404 バイト | 毎秒 663.1 MB |
4 回とも impdp のエラーは 0 件でした。REDO が毎秒 600 MB を超えたのは、どの回も開始から約 80〜140 秒後の 1 区間だけです。通常のスタンバイの回では、開始から約 6 分後以降の約 8 分は毎秒 12〜34 MB で、impdp のログではこの時間は制約 20 個の作成でした。OCI Monitoring の RedoGenerated は、通常のスタンバイの回で合計 158,030,903,433 バイトと、GV$SYSSTAT の差分の約 1.31 倍でした。差の理由は確かめていないので、本文の REDO 量は GV$SYSSTAT の値で書いています。
7.1.2. 大阪の PeerLag
| 回 |
PeerLag（1 分ごとの最大値） |
|---|---|
| 通常のスタンバイの回 | 06:02〜06:31 の 30 点がすべて 0 秒 |
| 適用を止めた回 | 変換の依頼は 06:32:55。06:30〜06:36 の 7 点と 06:53〜06:57 の 5 点がすべて 0 秒で、06:37〜06:52 は記録なし。06:53 は約 120 GB を適用していない時点（戻す依頼は 06:54:44） |
| 変換を挟んだ回 1・2 | それぞれ 19 点・24 点がすべて 0 秒 |
7.1.3. 大阪のリカバリの記録
スナップショット・スタンバイにした大阪で v$recovery_progress を読み、MEDIA RECOVERY の記録のうちインポートに対応する 2 件を並べます。経過時間は Elapsed Time、実働時間は Active Time です。
| リカバリの開始 | 対応するインポート | 適用した REDO | 経過時間 | 実働時間 | 平均の適用速度 | 最大の適用速度 | 最後に適用した REDO の時刻 |
|---|---|---|---|---|---|---|---|
| 06:27:17 | 通常のスタンバイの回 | 57.0 GB | 103 秒 | 99 秒 | 毎秒 553.5 MB | 毎秒 587.5 MB | 06:25:17 |
| 06:56:40 | 適用を止めた回（戻した直後） | （記録なし） | 251 秒 | 242 秒 | （記録なし） | （記録なし） | 06:58:03 |
-
Redo Applied（Megabytes）とAverage Apply Rate・Maximum Apply Rate（KB/sec）は、1024 単位とみなして 10 進の GB・MB に直した（公式に単位の定義は無く、10 進とみなすと約 5% 小さくなる） - 06:56:40 の記録は通常のスタンバイに戻す処理（06:54:51〜06:56:03）の直後に始まり、REDO のファイル 31 本を適用した
7.1.4. ハートビート表で読んだ時刻
| 回 | 負荷 | 変換の依頼 | 大阪に入っていた最後のハートビート | 依頼から最後のハートビートまで | 大阪が開いた時刻（v$pdbs.open_time） |
変換の作業の所要時間 |
|---|---|---|---|---|---|---|
| 負荷なしの回 A | なし | 08:06:58.720 | 08:08:50.640 | 111.9 秒 | （取っていない） | 7 分 37 秒 |
| 負荷なしの回 B | なし | 08:55:31.905 | 08:56:36.895 | 65.0 秒 | 09:00:10.378 | 5 分 41 秒 |
| 変換を挟んだ回 1 | インポート中 | 08:19:32.561 | 08:20:24.297 | 51.7 秒 | 08:25:33.621 | 7 分 2 秒 |
| 変換を挟んだ回 2 | インポート中 | 09:09:35.631 | 09:14:36.926 | 301.3 秒 | 09:23:30.144 | 14 分 51 秒 |
東京のハートビートは、どの回も 1.5 秒を超える空きがありませんでした。変換の作業の所要時間は OCI の作業リクエストの開始から完了までです。
7.2. 手順の詳細
7.2.1. impdp のパラメータファイル
ダンプファイルは東京の Object Storage のバケットに発行した事前認証リクエスト（PAR）の URL で読みました。impdp のクライアントでは、PAR の URL を指定するときに credential=NULL を書きます6。
userid=admin/"<パスワード>"@<サービス名>_high
credential=NULL
directory=DATA_PUMP_DIR
dumpfile=<PAR の URL>r2/impsrc_r2_%L.dmp
remap_schema=IMPSRC:<インポート先のスキーマ>
parallel=16
logtime=all
metrics=yes
7.2.2. 東京の REDO 量
約 1 分おきに実行して差を取ります。SQL*Plus では 12 桁の数値が指数表記になるので、to_char で文字列にして取ります。
select to_char(sum(value)) from gv$sysstat where name = 'redo size';
7.2.3. 大阪のリカバリの記録
-- 大阪（スナップショット・スタンバイ）で実行
select start_time, type, item, units, sofar, total, timestamp, comments
from v$recovery_progress
order by start_time, item;
参考
-
Autonomous Database の指標の一覧（PeerLag・RedoGenerated の定義。ローカルのピアはプライマリ側、クロスリージョンのピアはピア側に出る） ↩
-
Autonomous Database の機能の課金（クロスリージョンのピアは基本の ECPU 数とプライマリの 2 倍のストレージの分を課金。プライマリを止めると、どちらも ECPU は課金されない） ↩
-
クロスリージョン・スタンバイの概要（スタンバイとして動いている間は接続できず、読み取り専用でも使えない） ↩
-
スナップショット・スタンバイ（スナップショット・スタンバイの間も更新は送られ、ピアに戻すまで適用されない） ↩
-
Autonomous Database Serverless の高可用性（Oracle の高可用性の手引きの ADB-S の章。適用ラグの監視の節に、データは POD 全体のもの） ↩
-
Data Pump によるインポートの手順（PAR の URL を指定するときは credential が必要で、値は NULL でよい） ↩