使用例8: ターゲットPDBへのフェイルオーバー
計画的なロール遷移が不可能な場合は、スイッチオーバーではなくフェイルオーバーを実行できます。フェイルオーバーは、通常は、ソースPDBに障害が発生したかアクセスできないという緊急の状況で実行されます。フェイルオーバー中に、指定されたターゲットPDBがソース・ロールに変更されます。元のソースPDBが使用不可またはアクセス不可であるがコンテナ・データベースやその他のPDBがすべて正常に機能している場合、フェイルオーバー操作は、コンテナ内の元のソースPDBが変換されてフィジカル・スタンバイとしてマークされるという意味では、スイッチオーバー操作と非常によく似ています。ただし、リカバリは開始されず、新しいソースPDBからのREDOを適用するにはそのPDBをターゲットPDBとして回復する必要があります。
次のコマンドでは、
前のソースPDBの問題を解決できない場合は、そのPDBを削除し、使用例1から7の手順に従って新しいターゲットPDBを作成して新しいソースPDBを保護します。
nyc_sales
からbos_sales
へのフェイルオーバーが実行され、nyc_sales
が、bos_sales
のターゲットPDBとして回復されます。
DGMGRL> FAILOVER TO PLUGGABLE DATABASE bos_sales AT boston;
Verifying conditions for Failover...
Source pluggable database is 'NYC_SALES' at database 'newyork'
Performing failover NOW, please wait...
Closing pluggable database 'NYC_SALES'...
Converting 'NYC_SALES' to standby role...
Waiting for 'BOS_SALES' to recover all redo data...
Stopping recovery at 'BOS_SALES'...
Converting 'BOS_SALES' to primary role...
Opening new primary 'BOS_SALES'...
Waiting for redo data from new primary 'BOS_SALES'...
Failover succeeded, new primary is "BOS_SALES"
フェイルオーバーの完了後、障害が発生した(元のソース)PDBでリカバリが開始されることはありません。これは、コンテナ・データベースが再起動された場合や、ENABLE DATABASE
コマンドがコンテナ・データベース・レベルで発行された場合も同様です。元のソースPDBはプライマリ・ロールからフィジカル・スタンバイ・ロールに変換されます。それが新しいソースPDBのターゲット・スタンバイとして回復された後にのみ、リカバリを再開できます。フェイルオーバーが正常に完了したことと、各PDBの状態が想定どおりになっていることを確認するには、次のコマンドを発行します:
DGMGRL> SHOW PLUGGABLE DATABASE bos_sales AT boston;
Pluggable database - bos_sales at boston
Data Guard Role: Primary
Con_ID: 3
Active Target: con_id 3 at newyork needs to be reinstated
Pluggable Database Status:
DGM-17450: not protected
DGMGRL> SHOW PLUGGABLE DATABASE nyc_sales AT newyork;
Pluggable database - NYC_SALES at newyork
Data Guard Role: Physical Standby
Con_ID: 3
Source: (unknown)
Pluggable Database Status:
ORA-16661: The standby database must be reinstated.
前のソース(プライマリ) PDBの問題が解決されたら、そのPDBのリカバリを開始してそれをターゲット・ロールに戻すことで新しいソースPDBに保護を提供します: DGMGRL> EDIT PLUGGABLE DATABASE nyc_sales AT newyork SET STATE=APPLY-ON;
Succeeded.
ノート:
PDBの削除の詳細は、PDBの削除を参照してください。