ExaDB-XSでは、Oracle Data Guardで使用しているPhysical Standbyを、一時的にSnapshot Standbyへ変換できます。
通常、Standby DatabaseはPrimary Databaseの予備機です。Primaryで発生した更新を受け取り、同じ状態を維持する役割を持つため、自由にデータを変更することはできません。
Snapshot Standbyに変換すると、このStandby Databaseを一時的にRead Writeで利用できます。つまり、Primaryには影響を与えずに、実データに近い状態でアプリケーションの変更テストや障害調査を行えます。
検証が終わったらPhysical Standbyへ戻します。このとき、Snapshot Standby上で行ったテスト用の更新は破棄されます。その後、Snapshot中にPrimaryから届いていた更新情報が適用されるため、Standbyは再びPrimaryと同期した状態に戻ります。
この記事では、ExaDB-XS上の2ノードRAC構成で、この一連の動作を確認した記録を紹介します。
本記事のDB名、接続先、ユーザー名は匿名化しています。既存の本番Data Guard構成を対象にするのではなく、検証専用のPrimary/Standbyペアを用意して実施してください。
この記事で確認したこと
- 変換前にData Guardが正常に動作していること
- Physical StandbyをSnapshot Standbyへ変換できること
- Snapshot Standbyでテスト用の更新を実行できること
- Snapshot中もPrimaryからの更新情報を受け取れること
- Snapshot中は受け取った更新を反映しないこと
- Physical Standbyへ戻すと、更新情報の反映が再開すること
先に結論
今回の検証では、次の動作を確認できました。
- Snapshot StandbyをRead Writeで開き、テスト用のテーブル作成・データ登録・COMMITが成功した
- Snapshot中もPrimaryからの更新情報（redo）がStandbyへ届いた
- 届いたredoはSnapshot中には反映されず、
APPLIED = NOと表示された - Physical Standbyへ戻すとredoの反映が再開し、Data Guard Brokerの状態は
SUCCESSになった - Broker上の転送遅延・反映遅延はともに0秒になった
Snapshot Standbyの仕組み
まず、この記事で使う言葉を簡単に整理します。
- Primary Database: 普段アプリケーションが更新を行う本番側のデータベース
- Standby Database: Primaryの予備として、同じデータを保持するデータベース
- redo: Primaryで行われた更新内容を記録したログ。Data GuardはこのログをStandbyへ送る
- Redo Apply: Standbyが受け取ったredoを自分のデータへ反映する処理
Snapshot Standbyの動きは次のとおりです
ExaDB-XSでは、OCI Console、API、SDK、Terraformから変換操作を実行できます。Snapshot Standbyはredoを受信・保存しますが、Physical Standbyへ戻すまでデータへ反映しません。
ExaDB-XSの新機能
検証環境
| 項目 | 内容 |
|---|---|
| サービス | Oracle Exadata Database Service on Exascale Infrastructure（ExaDB-XS） |
| DBバージョン | Oracle AI Database 26ai 23.26.3.0.0 |
| 構成 | Primary RAC 2ノード / Physical Standby RAC 2ノード |
| Protection Mode | Maximum Performance |
| Redo transport | ASYNC |
| 変換操作 | OCI Console |
| 状態確認 | DGMGRL、SQL*Plus |
1. 変換前に「安全に始められる状態か」を確認する
Snapshot Standbyへ変換する前に、まずData Guardが正常に同期していることを確認します。ここを確認せずに始めると、Snapshot化による影響なのか、もともとのData Guard障害なのかを切り分けにくくなります。
Data Guard Brokerの状態を確認する
Data Guard Brokerは、Data Guardの構成や状態をまとめて管理・監視する機能です。Primary側で環境変数を設定し、DGMGRLへ接続します。
. PRIMARY_DB.env
dgmgrl /
SHOW CONFIGURATION VERBOSE;
SHOW DATABASE VERBOSE 'PRIMARY_DB';
SHOW DATABASE VERBOSE 'STANDBY_DB';
SHOW FAST_START FAILOVER;
VALIDATE DATABASE VERBOSE 'STANDBY_DB';
検証時の主な結果です。
Configuration Status : SUCCESS
Primary : PRIMARY / TRANSPORT-ON
Standby : PHYSICAL STANDBY / APPLY-ON
Fast-Start Failover : Disabled
Ready for Switchover : Yes
Ready for Failover : Yes
ここで重要なのは、構成全体がSUCCESSであり、StandbyがAPPLY-ONになっていることです。APPLY-ONは「StandbyがPrimaryから届いた更新を反映できる状態」を意味します。
元に戻すための準備：Flashback DatabaseとFRA
Snapshot StandbyからPhysical Standbyへ戻すときには、Flashback Databaseが使われます。これは、データベースを過去の時点へ戻すためのOracle Database機能です。
また、Flashbackの情報や受信したアーカイブログを保管する領域をFRA/Fast Recovery Areaと呼びます。Snapshot中はこの領域の使用量が増えるため、空き容量を確認します。
select db_unique_name, database_role, open_mode, log_mode, flashback_on
from v$database;
show parameter db_recovery_file_dest
show parameter db_recovery_file_dest_size
select name,
round(space_limit/1024/1024/1024, 2) as fra_limit_gb,
round(space_used/1024/1024/1024, 2) as fra_used_gb,
round((space_limit-space_used)/1024/1024/1024, 2) as fra_free_gb
from v$recovery_file_dest;
検証時はFlashback Databaseが有効で、FRAは240GB中224GBが空いていました。FRAに十分な空きがない場合は、Snapshot変換を開始しない方が安全です。
更新の転送・反映に遅れがないか確認する
次にStandby側で、Primaryからの更新が届くまでの遅れと、届いた更新が反映されるまでの遅れを確認します。
- transport lag: Primaryで発生した更新がStandbyへ届くまでの遅れ
- apply lag: Standbyに届いた更新が実際のデータに反映されるまでの遅れ
select name, value, unit, time_computed
from v$dataguard_stats
where name in ('transport lag', 'apply lag')
order by name;
select * from v$archive_gap;
V$ARCHIVE_GAP に行が表示されていないことを確認し、現在認識されている archive gap がないことを確認します。検証時はtransport lagが0秒、apply lagが0～数秒で、Broker上でもRedo ApplyがRunning、転送状態がSuccessでした。
2. OCI ConsoleでSnapshot Standbyへ変換する
変換操作そのものはOCI Consoleで行いました。
- 対象のData Guardグループを開く
- 変換するStandby Databaseの … メニューから スナップショットに変換 を選択する
- 対象DBとData Guardグループが正しいことを確認して実行する
- Work Request完了後、ロールが
スナップショットスタンバイになったことを確認する
変換後、Standby側でSQLを実行して状態を確認します。
select db_unique_name, database_role, open_mode, log_mode, flashback_on
from v$database;
DB_UNIQUE_NAME : STANDBY_DB
DATABASE_ROLE : SNAPSHOT STANDBY
OPEN_MODE : READ WRITE
FLASHBACK_ON : YES
SNAPSHOT STANDBYかつREAD WRITEであることから、Standbyを更新可能な状態で開けていることが分かります。
3. Snapshot Standbyでテスト用の更新を行う
Snapshot Standbyが本当に更新できるかを確認するため、専用の検証スキーマでテーブルを作成し、1行だけデータを登録します。
create table snapshot_local_only (
run_id varchar2(40) primary key,
created_at timestamp default systimestamp not null,
note varchar2(200)
);
insert into snapshot_local_only (run_id, note)
values ('SNAP-YYYYMMDD-01', 'must disappear after conversion back');
commit;
select * from snapshot_local_only
where run_id = 'SNAP-YYYYMMDD-01';
以下の操作が成功すれば、Snapshot StandbyをRead Writeで利用できています。
-
CREATE TABLE: テーブル作成 -
INSERT: データ登録 -
COMMIT: 更新内容の確定 -
SELECT: 登録結果の確認
検証用のDDL/DMLはPDB内の専用スキーマで実施することをおすすめします。SYSスキーマやCDB Rootをテストデータの置き場にすることは避けましょう。
Snapshot中もPrimaryの更新情報は届いているか
Snapshot Standbyは、Primaryから送られる更新情報を受け取り続けます。ただし、受け取った更新をデータベースへ反映する処理は止めています。
ここでは「更新情報は届いているが、まだ反映されていない」ことを確認します。
まず用語を整理する
- sequence（シーケンス番号）: redoログに付く通し番号。番号が増えていれば、新しい更新ログを受信したと判断できる
- RFS: Primaryから送られたredoをStandby側で受け取るプロセス
- APPLIED:Standby側で受信したアーカイブログが適用済みかを示す値。ここでは NO なら「受信しているが、まだ適用されていない」と判断します。
受信済みredoの番号を記録する
Snapshot Standby側で、RFSが受け取ったredoの最新番号を確認します。
select thread#, max(sequence#) as last_received
from v$archived_log
where registrar = 'RFS'
group by thread#
order by thread#;
今回の環境はRAC構成のため、2つのredoログの流れ（thread）がありました。変換直後の結果は次のとおりです。
thread 1 : 6
thread 2 : 7
Primaryで新しいredoを生成する
Primary側で、現在使用中のredoログを区切ってアーカイブします。
Primary側で ALTER SYSTEM ARCHIVE LOG CURRENT を実行し、redoのアーカイブを促します。その後、Standby側で各threadのsequence#を比較し、新しいredoが受信されたことを確認します。
Standbyで「受信済み・未反映」を確認する
30～60秒後に、Snapshot Standby側で再確認します。
select thread#, max(sequence#) as last_received
from v$archived_log
where registrar = 'RFS'
group by thread#
order by thread#;
select thread#, sequence#, registrar, applied, completion_time
from v$archived_log
where registrar = 'RFS'
order by thread#, sequence# desc fetch first 10 rows only;
結果は次のとおりでした。
受信後の最新sequence
thread 1 : 7
thread 2 : 8
新規受信redo
thread 1 / sequence 7 : RFS / APPLIED = NO
thread 2 / sequence 8 : RFS / APPLIED = NO
sequence番号が増えているため、新しい更新情報がSnapshot Standbyまで届いていることが分かります。一方でAPPLIED = NOなので、受信した更新はまだデータへ反映されていません。
つまり、Snapshot StandbyはPrimaryの更新情報を受信・保存しながら、自身をRead Writeで利用するために、Redo Applyを停止していることを確認できました。
5. Physical Standbyへ戻し、更新情報の反映を再開する
検証が終わったら、OCI Consoleで対象Standbyに対して スタンバイに変換 を実行します。
Work Request完了後、Primary側からBrokerの状態を確認します。
SHOW CONFIGURATION;
SHOW DATABASE 'STANDBY_DB';
Configuration Status : SUCCESS
Role : PHYSICAL STANDBY
Intended State : APPLY-ON
Transport Lag : 0 seconds
Apply Lag : 0 seconds
APPLY-ONは、受信した更新情報を再び反映できる状態に戻ったことを示します。
Standby側でも確認します。
select db_unique_name, database_role, open_mode, flashback_on
from v$database;
DATABASE_ROLE : PHYSICAL STANDBY
OPEN_MODE : MOUNTED
FLASHBACK_ON : YES
Snapshot中に受信したredoは、次のように反映されました。
thread 1 / sequence 7 : APPLIED = YES
thread 2 / sequence 8 : APPLIED = IN-MEMORY
YESは反映が完了したことを意味します。IN-MEMORYは、そのログの変更がStandby Databaseへ適用されているものの、データファイルへの反映状況を含めてYESと判断される段階にはまだ達していない状態です。Redo Applyが動作中であれば見られる正常な状態です。
Physical Standbyへの復帰では、Snapshot中に行ったテスト用のローカル更新はFlashbackで破棄され、保存されていたredoが適用されます。これによりStandbyはPrimaryと同期した状態に戻ります。
運用時の注意点
- Snapshot中は、Standbyを通常のswitchover/failover先として扱わない。必要なら先にPhysical Standbyへ戻す
- Snapshot中は自動バックアップが停止するため、検証を必要以上に長期化させない
- FRAの使用量を監視する。Snapshot中はFlashbackの情報と受信したアーカイブログの両方が増える
- Snapshot中はPrimary/StandbyでPDBを追加しない
- ExaDB-XSの変換操作はOCI Console、API、SDK、Terraformを利用し、DGMGRLとSQL*Plusは状態確認・証跡採取に使う
- 標準Physical StandbyはMOUNT状態のため、復帰直後にユーザー表を直接SELECTできない。ローカル更新の消滅をSQLで直接確認したい場合は、apply収束後に短時間の追加Snapshot変換で確認する
まとめ
ExaDB-XSのSnapshot Standbyを使うと、Physical Standbyを一時的に更新可能な検証環境として利用できます。Primaryへ影響を与えずにテストでき、終了後はPhysical Standbyへ戻すことで、Primaryとの同期状態に復帰できます。
安全に利用するポイントは3つです。
- 変換前にData Guardの状態、Flashback Database、FRA空き容量、遅延を確認する
- Snapshot中はFRA使用量を監視し、必要以上に長く利用しない
- 復帰後はBrokerの
SUCCESS、Redo Applyの再開、lagの収束を確認する