| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
ロジカル・スタンバイ・データベースの作成の詳細は、次の各項を参照してください。
関連項目:
サーバーのパラメータ・ファイルの作成と使用の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Data Guard Brokerグラフィカル・ユーザー・インタフェース(GUI)を使用したロジカル・スタンバイ・データベースの自動作成の詳細は、Oracle Enterprise Manager Cloud Controlオンライン・ヘルプ・システムを参照してください。
注意:
マルチテナント・コンテナ・データベース(CDB)環境で作業している場合、非CDB環境との動作の違いの詳細は、「CDBのロジカル・スタンバイの作成」を参照してください。たとえば、CDB環境では、DBAビューの多くに代替として使用する必要のある類似のCDBビューがあります。たとえば、ビューCDB_LOGSTDBY_NOT_UNIQUEには、DBA_LOGSTDBY_NOT_UNIQUEビューに示されるデータと同じデータが含まれますが、PDB名を含む追加の列があります。
ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースで次の準備作業を実行します。
ロジカル・スタンバイ・データベースでは、スタンバイREDOログ(SRL)をプライマリ・データベースから受信したREDOに使用しますが、スタンバイ・データベースに変更を適用するため、オンラインREDOログ(ORL)にも書き込みます。そのため、ロジカル・スタンバイ・データベースには、SRLおよびORLを同時にアーカイブするために追加のARCnプロセスが必要になることがあります。さらに、ORLのアーカイブはSRLのアーカイブに優先するため、ワークロードが非常に高いときは、ロジカル・スタンバイにより多くのSRLが必要になる可能性があります。
ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表を保持できることを確認する必要があります。サポートされていないデータ型またはストレージ属性があるかどうかを判断するのに使用できる特定のSQL問合せの詳細は、「サポートされない表」を参照してください。
ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーから作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・データベースの構成とは異なります。そのため、プライマリ・データベースによって生成されたREDOレコードに含まれているROWIDは、ロジカル・スタンバイ・データベース内の対応する行を識別するためには使用できません。
Oracleでは、ロジカル・スタンバイ・データベース内の変更された行を論理的に識別するために、主キーまたは一意制約/索引サプリメンタル・ロギングを使用します。また、データベース全体の主キーおよび一意制約/索引サプリメンタル・ロギングが使用可能になると、各UPDATE文により、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列の値が書き込まれます。
表に主キーが定義されている場合、その主キーが、変更された行を識別するためにUPDATE文の一部として変更された列とともにログに記録されます。
主キーがない場合は、一番短く、NULL値が許容されていない一意制約/索引が、変更された行を識別するためにUPDATE文の一部として変更された列とともにログに記録されます。
主キーもNULL値が許容されていない一意制約/索引もない場合、4000バイトの最大長が宣言されたすべての列が、変更された行を識別するためにUPDATE文の一部としてログに記録されます。サポートされるデータ型に関する要件と制限がいくつかあります。詳細は、次の各項を参照してください。
ファンクション索引は、一意として宣言されている場合でも、変更された行を一意に識別するためには使用できません。しかし、ロジカル・スタンバイ・データベースでは、変更された行を一意に識別できるかぎり、ファンクション索引が定義された表をレプリケーションできます。
SQL Applyで、REDOデータの更新をロジカル・スタンバイ・データベースに効率的に適用できるように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたはNULL値が許容されていない一意索引を追加することをお薦めします。
ロジカル・スタンバイ・データベース内のレプリケートされている各表の行をSQL Applyによって一意に識別できるかどうかを確認するには、次の手順を実行します。
プライマリ・データベース表で無効化されたRELY制約を作成するには、ALTER TABLE文をRELY DISABLE句と一緒に使用します。次の例では、無効化されたRELY制約がmytabという表に作成されます。各行は、id列とname列を使用して一意に識別されます。
SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;
RELY制約を指定すると、システムでは行が一意であると仮定されます。システムに対して情報に依存するように指示を出していますが、表が変更されるたびに検証は行わないため、表内の各行を一意に識別するRELY制約が無効化されている場合は、十分に注意して列を選択する必要があります。このような一意性が存在しない場合、SQL Applyによる表のメンテナンスが正しく行われません。
SQL Applyのパフォーマンスを改善するには、ロジカル・スタンバイ・データベースで行を識別するために一意制約/索引を列に追加します。追加できない場合は、SQL Applyによって表上でUPDATEまたはDELETE文を実行中に、全表スキャンが実行されます。
関連項目:
DBA_LOGSTDBY_NOT_UNIQUEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ALTER TABLE文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
RELY制約およびロジカル・スタンバイ・データベース上でパフォーマンスを向上させるために行うことができる処理の詳細は、「主キーRELY制約の作成」を参照してください。
この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクを示します。
表4-1 ロジカル・スタンバイ・データベースの作成
| タスク | データベース |
|---|---|
プライマリ |
|
スタンバイ |
|
プライマリ |
|
スタンバイ |
|
スタンバイ |
|
スタンバイ |
ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。「フィジカル・スタンバイ・データベースの作成」の指示に従ってフィジカル・スタンバイ・データベースを作成します。
ロジカル・スタンバイ・データベースに変換する前に、実行時間に関係なく、新規フィジカル・スタンバイ・データベースでREDO Applyを実行できます。ただし、ロジカル・スタンバイ・データベースに変換する前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。REDO Applyの停止は、LogMinerディクショナリを含むREDOの後に変更が適用されることを避けるために必要です(「REDOデータでのディクショナリの構築」を参照)。
REDO Applyを停止するには、フィジカル・スタンバイ・データベースで次の文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
この項は、次の項目で構成されています。
「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数のスタンバイ・ロールの初期化パラメータを設定しました。
注意:
この手順は、スイッチオーバーを実行する予定の場合のみ必要です。
プライマリ・データベースをロジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更しなくてもよいように、例4-1に太字で示すパラメータを変更する必要もあります。
元のLOG_ARCHIVE_DEST_1宛先のVALID_FOR属性を、スタンバイREDOログからではなく、オンラインREDOログからのみREDOデータをアーカイブするように変更します。
LOG_ARCHIVE_DEST_3宛先をプライマリ・データベースに含めます。このパラメータは、プライマリ・データベースがロジカル・スタンバイ・ロールに推移したときにのみ有効になります。
次の表に、例4-1に示した変更後の初期化パラメータで定義されるアーカイブ・プロセスを示します。
| LOG_ARCHIVE_DEST_n | シカゴのデータベースがプライマリ・ロールで稼働している場合 | シカゴのデータベースがロジカル・スタンバイ・ロールで稼働している場合 |
|---|---|---|
|
|
|
|
無視。 |
|
例4-1 プライマリ・データベース: ロジカル・スタンバイ・ロールの初期化パラメータ
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/chicago/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_3=ENABLE
これらの初期化パラメータを動的に設定するには、SQL ALTER SYSTEM SET文を使用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するようにSCOPE=BOTH句を指定します。
LogMinerディクショナリは、SQL ApplyのLogMinerコンポーネントによってREDOでの変更が適切に解釈できるように、REDOデータに構築される必要があります。LogMinerディクショナリの構築の一部として、主キーおよび一意制約/索引列を記録するサプリメンタル・ロギングが自動的に設定されます。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行を論理的に識別するための十分な情報が含まれていることが保証されます。
LogMinerディクショナリを構築するには、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
DBMS_LOGSTDBY.BUILDプロシージャでは、既存のトランザクションがすべて完了するのを待機します。プライマリ・データベースで長時間実行されているトランザクションは、このコマンドの適時性に影響を与えます。
注意:
Oracle Database 11gリリース2 (11.2)以上を使用して作成されたデータベースでは、サプリメンタル・ロギング情報は、既存のフィジカル・スタンバイ・データベースすべてに自動的に伝播されます。ただし、それより前のリリースのデータベースの場合や、それより前のリリースを使用してデータベースを作成してから11.2にアップグレードした場合、サプリメンタル・ロギングがプライマリ・データベースで有効化されているときは、それがフィジカル・スタンバイでも有効化されているかどうかを確認する必要があります。それがフィジカル・スタンバイで有効化されていない場合、スイッチオーバーまたはフェイルオーバーを実行する前に、すべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。これを実行するには、各フィジカル・スタンバイで次のSQL文を発行します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
これを行わないと、フィジカル・スタンバイ・データベースの1つに対してスイッチオーバーまたはフェイルオーバーが行われた場合に、同じOracle Data Guard構成内のすべてのロジカル・スタンバイが使用できません。スイッチオーバーやフェイルオーバーがすでに発生しており、サプリメンタル・ロギングが有効化されていない場合、すべてのロジカル・スタンバイ・データベースを再作成する必要があります。
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY.BUILD PL/SQLパッケージ
『Oracle Databaseリファレンス』のUNDO_RETENTION初期化パラメータ
この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この付録には、次の項があります。
REDOログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。
注意:
Oracle RACフィジカル・スタンバイ・データベースがある場合、1つのインスタンス以外はすべて停止して、CLUSTER_DATABASEをFALSEに設定し、次のようにしてスタンバイ・データベースをMOUNT EXCLUSIVEモードで単一インスタンスとして起動します。
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE; SQL> SHUTDOWN ABORT; SQL> STARTUP MOUNT EXCLUSIVE;
ロジカル・スタンバイ・データベースへの変換準備が完了するまでREDOデータをフィジカル・スタンバイ・データベースに適用し続けるには、次のSQL文を発行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;
db_nameには、新しいロジカル・スタンバイ・データベースを識別するために、プライマリ・データベースとは異なるデータベース名を指定します。この文を発行するときにサーバー・パラメータ・ファイル(spfile)を使用する場合は、新しいロジカル・スタンバイ・データベースの情報でファイルを適切に更新します。spfileを使用していない場合は、データベースの停止後にDB_NAMEパラメータの名前を設定するよう求めるメッセージが発行されます。
注意:
フィジカル・スタンバイ・データベースでOracleソフトウェアのローリング・アップグレードを実行する状況で、ロジカル・スタンバイ・データベースを作成するとき、次のコマンドをかわりに発行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
KEEP IDENTITY句で作成されたロジカル・スタンバイ・データベースには、プライマリ・データベースと同じDB_NAMEおよびDBIDが含まれています。このようなロジカル・スタンバイ・データベースは、1回のスイッチオーバー操作にしか使用できないため、フィジカル・スタンバイ・データベースでローリング・アップグレードを実行する状況でのみ作成する必要があります。
KEEP IDENTITY句は、アップグレードするデータベースでOracle Databaseリリース11.1以降が稼働している場合にのみ、使用できます。
この文では、ログ・ファイル内にLogMinerディクショナリが見つかるまで、REDOデータを適用しながら待機します。「REDOデータでのディクショナリの構築」で生成されたREDOがスタンバイ・データベースに推移されるのにかかる時間と、適用する必要のあるREDOデータの量にもよりますが、この作業には数分かかります。プライマリ・データベースでディクショナリ構築が正常に実行されるまで、このコマンドは完了しません。SQL文を取り消すには、別のSQLセッションからALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL文を発行します。
注意:
Oracle Database 11g以前のリリースでは、ロジカル・スタンバイ・データベースをオープンする前に新しいパスワード・ファイルを作成する必要がありました。現在は、その必要はありません。ロジカル・スタンバイ・データベースに新しいパスワード・ファイルを作成すると、REDO転送サービスは正常に機能しません。
注意:
Oracle RACフィジカル・スタンバイ・データベースで開始した場合、次のようにCLUSTER_DATABASEの設定をTRUEに戻します。
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;
ロジカル・スタンバイ・データベース上でインスタンスをシャットダウンし、STARTUP MOUNT文を発行してデータベースの起動とマウントを行います。データベースは開かないでください。作成手順の後半まで閉じておき、ユーザー・アクセスは行わないでください。次に例を示します。
SQL> SHUTDOWN; SQL> STARTUP MOUNT;
LOG_ARCHIVE_DEST_nパラメータを変更する必要があります。これは、フィジカル・スタンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースはREDOデータを生成するオープン・データベースであり、複数のログ・ファイル(オンラインREDOログ・ファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル)があるためです。次のものに対しては、別なローカル宛先を指定することをお薦めします。
ロジカル・スタンバイ・データベースで生成されたREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston宛先として構成されています。
プライマリ・データベースから受信したREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston宛先として構成されています。
例4-2に、ロジカル・スタンバイ・データベース用に変更された初期化パラメータを示します。各パラメータは、ボストンのロジカル・スタンバイ・データベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。
注意:
データベースの互換性を11.1以降に設定した場合、高速リカバリ領域を使用してリモート・アーカイブ・ログを格納することができます。そのためには、次のパラメータを設定する必要があります(すでにDB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEパラメータが設定されているとします)。
LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=boston'
高速リカバリ領域を使用しているため、VALID_FORパラメータを指定する必要はありません。デフォルト値は(ALL_LOGFILES,ALL_ROLES)で、この場合の適切な動作です。LOG_ARCHIVE_DEST_1が、オンライン(プライマリ)およびスタンバイの両方の、全ログ・ファイルに使用されます。
次の表に、例4-2に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。
| LOG_ARCHIVE_DEST_n | ボストンのデータベースがプライマリ・ロールで稼働している場合 | ボストンのデータベースがロジカル・スタンバイ・ロールで稼働している場合 |
|---|---|---|
|
|
|
|
リモート・ロジカル・スタンバイ・データベース |
無視。 |
|
無視。 |
|
注意:
DB_FILE_NAME_CONVERT初期化パラメータは、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換された後は考慮されません。必要な場合は、スキップ・ハンドラを登録し、プライマリ・データベースのデータ・ファイルのパス名をスタンバイ・データファイルのパス名に変換することで、実行対象のかわりとなるDDL文字列をSQL Applyに提供します。SKIPプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBYパッケージを参照してください。
例4-2 ロジカル・スタンバイ・データベース用の初期化パラメータの変更
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/boston/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE
新しいロジカル・スタンバイ・データベースをオープンするには、次の文を使用します(KEEP IDENTITYオプションを使用してロジカル・スタンバイを作成した場合、RESETLOGSは指定しません)。
SQL> ALTER DATABASE OPEN RESETLOGS;
注意:
Oracle RACフィジカル・スタンバイ・データベースで開始した場合、その他のすべてのスタンバイ・インスタンスをこの時点で開始できます。
注意:
ロジカル・スタンバイ・データベースをプライマリ・データベースと同じコンピュータ・システム上に配置している場合、SQL Applyを初めて開始する前に次のSQL文を発行し、SQL Applyがプライマリ・データベースで実行されるファイル操作をスキップするようにする必要があります。この文の発行が必要な理由は、SQL Applyはプライマリ・データベースと同じディレクトリ構造にアクセスできるので、特定のファイル固有の操作を再実行しようとした場合に、プライマリ・データベースに属するデータファイルが破損する可能性があるためです。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE');
フィジカル・データベースをプライマリ・データベースと同じシステム上に配置する際に設定したDB_FILENAME_CONVERTパラメータは、SQL Applyでは無視されます。DBMS_LOGSTDBY.SKIPおよびロジカル・スタンバイ・データベースのコンテキストでの同等な動作の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
データベースがオープンされるのはこれが初回であるため、データベースのグローバル名は、新しいDB_NAME初期化パラメータと一致するように自動的に調整されます。(KEEP IDENTITYオプションを使用してロジカル・スタンバイを作成した場合、これは当てはまりません。)
注意:
Oracle Databaseソフトウェアのローリング・アップグレードを実行するためにロジカル・スタンバイ・データベースを作成する場合、SQL Applyではサポートされないオブジェクトに対する更新に関心があるときは、DBMS_LOGSTDBY PL/SQLプロシージャを使用することをお薦めします。ロジカル・スタンバイ・データベースで、次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS表のイベントとして記録します。
EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',
DBMS_LOGSTDBY.MAX_EVENTS);
EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');
このプロシージャは、ロジカル・スタンバイではサポートされない、プライマリで実行中のトランザクションに関する情報を取得します。アップグレードが完了し、本番を新しいバージョンに切り替える前に、この表を確認します。何も記録されていない場合は、すべてレプリケートされたことになります。何か記録されている場合は、修正処理を実行するか、アップグレードを破棄するかのいずれかを選択できます。
関連項目:
DBA_LOGSTDBY_EVENTSビューの詳細は、「DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ」を参照してください
DBMS_LOGSTDBYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の文を発行して、ロジカル・スタンバイ・データベースに対するREDOデータの適用を開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
注意:
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換は、次のように2段階で行われます。
ALTER DATABASE RECOVER TO LOGICAL STANDBY文(KEEP IDENTITY句を指定した場合を除く)の処理の一部として、データベースのDBIDが変更されます。
ALTER DATABASE START LOGICAL STANDBY APPLY文が最初に正常に実行されたとき、処理の一部として制御ファイルが更新され、新たに作成されたロジカル・スタンバイ・データベースの制御ファイルと一致するようになります。
ALTER DATABASE START LOGICAL STANDBY APPLY文の起動に成功した後、ロジカル・スタンバイ・データベースの全体バックアップを作成します。ロジカル・スタンバイ・データベースをリストアする際には、プライマリ・データベースから作成したバックアップを使用できないためです。
この時点で、ロジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。
データ保護モードのアップグレード
Oracle Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。
フラッシュバック・データベースの有効化
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Oracle Data Guard環境でのフラッシュバック・データベースの使用例は、「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」および「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。
通常のプライマリ・データベースのロジカル・スタンバイ・データベースを作成できるように、マルチテナント・コンテナ・データベース(CDB)のロジカル・スタンバイ・データベースを作成できます。CDBのロジカル・スタンバイの作成および使用時に注意する動作の違いの一部を次に示します。
データベース・ロールは、プラガブル・データベース(PDB)コンテナ・レベルではなく、CDBレベルで定義されます。
スイッチオーバー操作またはフェイルオーバー操作を実行する場合、CDB全体でロールが変化します。
ロールの変更に関連するDDLは、CDBのルート・コンテナへの接続中に実行される必要があります。
通常のロジカル・スタンバイと同様に、CDBのロジカル・スタンバイは、REDOストリームを一度マイニングするプロセスの単一プールを操作しますが、すべてのPDBとCDBのルート・コンテナの更新の職責は共有されます。
プライマリとスタンバイでPDBのセットが同じである必要はありません。しかし、プライマリとスタンバイの両方で同じコンテナに存在する表のみをレプリケートする必要があります。
通常、グローバル構成属性を変更するロジカル・スタンバイPL/SQLインタフェース(DBMS_LOGSTDBY.APPLY_SETなど)はルート・コンテナで実行されます。しかし、DBMS_LOGSTDBY.INSTANTIATE_TABLEは対象の表が存在するコンテナ内で呼び出される必要があり、DBMS_LOGSTDBY.SKIPプロシージャは対象のコンテナ内で呼び出される必要があります。
ロジカル・スタンバイ・ビューは適切なコンテナ名を指定するように強化されました。多くのDBAビューには、名前がCDBで始まる類似のCDBビューがあります。たとえば、ビューCDB_LOGSTDBY_NOT_UNIQUEには、DBA_LOGSTDBY_NOT_UNIQUEビューに示されるデータと同じデータが含まれますが、PDB名を含む追加の列があります。CDB_LOGSTDBY_NOT_UNIQUEビューがルートで問い合せられると、CDB内のすべてのデータベースのデータが示されます。
CDBのロジカル・スタンバイで、SQL文の構文は通常、コンテナでないデータベースと同じです。しかし、次に示すものを含む、一部の文の影響は異なる場合があります。
ALTER DATABASE RECOVER TO LOGICAL STANDBYはCDBでのみ機能し、PDBでは使用できません。
1つのロールはCDB全体に関連します。個別のPDBには固有のロールはありません。そのため、ロジカル・スタンバイに関連する次のロール変更DDLはCDB全体に影響します。
ALTER DATABASE [PREPARE|COMMIT] TO SWITCHOVER
ALTER DATABASE ACTIVATE LOGICAL STANDBY
ALTER DATABASE [START|STOP] LOGICAL STANDBY APPLYはルート・コンテナでのみ機能し、CDB全体に影響します。この文はPDBでは使用できません。
ALTER DATABASE GUARDはルート・コンテナでのみ機能し、CDB全体に影響します。たとえば、ALTER DATABASE GUARD ALL文が発行されると、ルートおよびすべてのPDB内のユーザー・アクティビティは制限されます。
マルチテナント環境を管理するには、CDB_DBAロールが必要です。
関連項目:
CDBの詳細は、『Oracle Database概要』を参照してください。
コンテナでのDBMS_LOGSTDBY.SKIPプロシージャの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
CDBおよびPDBでの権限とロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
