1. Oracle Globally Distributed Databaseガイド
  2. Oracle Globally Distributed Databaseの管理
  3. Oracle Globally Distributed Databaseのバックアップおよびリカバリ

Oracle Globally Distributed Databaseのバックアップおよびリカバリ

GDSCTLユーティリティを使用すると、Oracle Globally Distributed Databaseのバックアップ・ポリシーを定義し、1つ以上のシャード、またはOracle Globally Distributed Database全体を同じ時点にリストアできます。構成済バックアップは自動的に実行され、オフピーク時にバックアップを実行するスケジュールを定義できます。

Oracle Globally Distributed DatabaseのGDSCTLコマンドを使用すると、Oracle MAAベスト・プラクティスを使用したシャード・データベースのバックアップ・ポリシーの集中管理が可能になり、簡略化されます。Oracleジョブ・スケジューラを利用する増分スキームを使用して、バックアップ・スケジュールを作成できます。Oracle Recovery Manager (RMAN)は、実際のバックアップおよびリストア操作を実行します。

GDSCTLの一元化されたバックアップおよびリストア操作を使用すると、次のことができます。

バックアップおよびリストアの用語

Oracle Globally Distributed Databaseのバックアップおよびリストア手順で発生するいくつかの用語を次に示します。

  • ターゲット・データベース - データベースRMANはバックアップを行います。

  • グローバルSCN - シャード・データベース全体のリストアがサポートされているすべてのターゲット・データベースに共通の時点。リストア・ポイントはこのグローバルSCNで取得され、リストア・ポイントはシャード・データベース(シャード・カタログを含む)をリストアできるポイントです。

    シャード・カタログまたは特定のシャードを任意の時点にリストアすることは禁止されていません。ただし、これを行うと、そのターゲットが残りのシャード・データベースと一貫性のない状態になる可能性があり、リストア操作の外部で修正処理を実行する必要がある場合があります。

  • 増分バックアップ - 前回の増分バックアップ後に行われたデータベースへのブロックレベルの変更を取得します。

  • レベル0の増分バックアップ(レベル0のバックアップ) - データベース内のブロックをバックアップする増分バックアップ計画の開始点。このバックアップの内容は全体バックアップと同じですが、全体バックアップとは異なり、レベル0のバックアップは増分バックアップ計画の一部とみなされます。

  • レベル1の増分バックアップ(レベル1の増分バックアップ) - レベル1の増分バックアップには、前回の増分バックアップ後に変更されたブロックのみが含まれます。現行または親のデータベース・インカネーションにレベル0のバックアップが存在せず、レベル1のバックアップを実行する場合、RMANはレベル0のバックアップを自動的に作成します。レベル1の増分バックアップは、累積または差分のいずれかにできます。

自動バックアップとオンデマンド・バックアップ

Oracle Globally Distributed Databaseには、自動バックアップとオンデマンド・バックアップの2種類のバックアップがあります。

  • 自動バックアップは、ジョブ・スケジュールに基づいてOracle Schedulerジョブによって開始され、データベース・サーバー上でバックグラウンドで実行されます。

  • オンデマンド・バックアップは、ユーザーがGDSCTLから開始します。

    内部的には、オンデマンド・バックアップもデータベース・サーバー上のOracle Schedulerジョブによって開始されます。オンデマンド・バックアップ・コマンドが発行されると、ジョブがオンデマンド・バックアップ・コマンドで作成されます。これらは一時ジョブであり、バックアップの終了後に自動的に削除されます。

関連項目: Oracle Schedulerを使用したジョブのスケジュール

サポートされているバックアップ先

Oracle Globally Distributed Databaseでサポートされるバックアップの保存先は次のとおりです。

  • 共通ディスク/ディレクトリ構造(NFSマウント)。シャード・カタログ・データベース・ホストを含む任意の場所に配置できます。

  • Zero Data Loss Recovery Appliance(利点は連続バックアップであり、Data Guard Brokerを使用してREDO転送を管理およびモニターできます)

  • Oracle Object Storage

  • Amazon S3 (Amazon Simple Storage Service)

制限事項

GDSCTLを使用したOracle Globally Distributed Databaseのバックアップおよびリストアでは、次の制限に注意してください。

  • Microsoft Windowsはサポートされません。

  • Clusterwareがデプロイされている場合、Clusterwareリポジトリのバックアップを提供する必要があります

一元化されたバックアップおよびリストアの構成の前提条件

Oracle Globally Distributed Databaseのバックアップを構成する前に、次の前提条件が満たされていることを確認してください。

  • 専用データベースに1つ以上のリカバリ・カタログを作成します。リカバリ・アプライアンスがバックアップに使用されている場合は、リカバリ・アプライアンスのリカバリ・カタログが使用されます。

    GDSCTLを使用してシャード・データベースをバックアップまたはリストアするには、専用データベースで作成されたリカバリ・カタログへのアクセス権が必要です。このリカバリ・カタログは、シャード・カタログ・データベースおよびすべてのシャード・データベースの集中管理されたRMANリポジトリとして機能します。

    次の点に注意してください。

    • RMANにはRMANクライアント、ターゲット・データベースおよびリカバリ・カタログ・スキーマの互換性要件があるため、リカバリ・カタログ・データベースのリカバリ・カタログ・スキーマのバージョンは、シャード・データベース・バージョンと互換性がある必要があります。詳細は、次の相互参照のOracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

    • シャード・カタログ・データベースはシャード・データベース・バックアップ構成のいずれかのターゲット・データベースであり、RMANではリカバリ・カタログをターゲット・データベースに配置できないため、リカバリ・カタログはシャード・カタログとホスト・データベースを共有しないでください。

    • 適切なベスト・プラクティスに従って、リカバリ・カタログのバックアップを定期的にバックアップすることをお薦めします。

    • シャード・カタログ・データベースとすべてのシャード・データベースは、同じリカバリ・カタログを使用するか、様々なリカバリ・カタログ間で分割するように構成できます。

  • シャード・カタログ・データベースおよびすべてのシャード・データベースのバックアップ先を構成します。

    バックアップの保存先タイプはDISKまたはテープへのシステム・バックアップです。サポートされているDISK宛先は、NFSおよびOracle ASMファイル・システムです。

    Oracle Object Storage、Recovery ApplianceまたはAmazon S3をバックアップ保存先として使用している場合、RMANは内部的にテープとして扱います。重要なバックアップ・モジュールをターゲット・データベース・ホストにインストールする必要があります。

    テープ宛先へのシステム・バックアップでは、データベース・ホストに追加のソフトウェア・モジュールをインストールする必要があります。RMANと連携するように適切に構成する必要があります。

    シャード・データベース・バックアップの保存先としてリカバリ・アプライアンスを使用するのは特別な場合です。リカバリ・アプライアンスには、組込みのリカバリ・カタログが付属しています。データベースは単一のリカバリ・カタログを持つターゲット・データベースとしてのみ登録できるため、リカバリ・アプライアンスをバックアップの保存先として使用してシャード・データベース・バックアップを構成する場合、組込みのリカバリ・カタログがシャード・データベースのバックアップおよびリストアに使用されます。

    シャード・カタログ・データベースとすべてのシャード・データベースは、バックアップの保存先と同じリカバリ・アプライアンスを使用するように構成する必要があります。

    シャード・カタログ・データベースまたはシャード・データベースがData Guard構成にある場合は、プライマリ・データベースとスタンバイ・データベースのどちらをバックアップするかを選択できます。

    関連項目:

  • RMANは、シャード・カタログを除き、特定の内部ユーザーとしてターゲット・データベースに接続し、データベースのバックアップおよびリストアを実行します。

    シャード・カタログの場合、シャード・カタログPDBをホストするCDBの共通ユーザーは、シャード・データベース・バックアップが構成された時点で指定する必要があります。このユーザーには、SYSDGおよびSYSBACKUP権限が付与されている必要があります。CDBがそのPDBにローカルUNDOを使用するように構成されている場合は、SYSBACKUP権限も共通に付与されている必要があります。

    シャード・データベースでは、内部CDB共通ユーザーGSMROOTUSERが使用されます。このユーザーは、シャードCDBルート・データベースでロックを解除し、GSMROOUSERに必要な他の権限に加えて、SYSBACKUP権限を付与する必要があります。CDBがそのPDBにローカルUNDOを使用するように構成されている場合は、SYSBACKUP権限をGSMROOTUSERに共通に付与する必要があります。つまり、SYSBACKUP権限を付与するときにCONTAINER=ALL句を使用する必要があります。

  • シャード・データベースのバックアップおよびリストア操作のすべてのGDSCTLコマンドでは、シャード・カタログ・データベースをオープンする必要があります。シャード・カタログ・データベース自体をリストアする必要がある場合は、手動でリストアする必要があります。
  • バックアップをテープまたはその他の長期ストレージ・メディアにオフロードし、適切なデータ保存のベスト・プラクティスに従う必要があります。

ノート:

Oracle Databaseバックアップおよびリカバリ・リファレンスのRMANの互換性に関する項を参照してください

自動バックアップの構成

自動バックアップを構成するには、GDSCTL CONFIG BACKUPコマンドを使用します。

GDSCTLバックアップ・コマンドを実行するには、シャード・ディレクタ(GSM)ホストに接続する必要があります。コマンドを別の場所から実行する場合、GDSCTL CONNECTコマンドを使用してシャード・カタログ・データベースに明示的に接続する必要があります。

GDSCTLバックアップ構成を実行する場合、次の入力を指定できます。

  • データベースのリスト

    データベースは、シャード・カタログ・データベースおよびシャード・データベースです。バックアップ構成では、指定したデータベースのプライマリ・データベースが読取りおよび書込み用にオープンされている必要がありますが、スタンバイ・データベースはマウントまたはオープンできます。

    データベースがバックアップ用に構成されているときにData Guard構成内にある場合、Data Guard構成内のすべてのデータベースがバックアップ用に構成されます。Data Guard構成のシャードの場合、プライマリおよびすべてのスタンバイ・シャードのバックアップ先および開始時間を指定する必要があります。

    これはシャード・カタログ・データベースでは異なります。シャード・カタログ・データベースとすべてのシャード・カタログ・スタンバイ・データベースは、バックアップの保存先と開始時間を共有します。

  • リカバリ・カタログ・データベースへの接続文字列

    接続文字列には、RECOVERY_CATALOG_OWNERロールなど、RMANの権限を持つユーザー・アカウントが必要です。

  • RMANバックアップ保存先パラメータ

    これらのパラメータには、バックアップ・デバイスおよびチャネル構成が含まれます。シャードごとに異なるバックアップ先を使用できます。

    以下の点に注意してください。

    • スタンバイ・データベースから作成されたバックアップを使用してプライマリ・データベースをリストアし、逆にリストアできるように、Data Guard構成のシャードのバックアップ先を適切に定義する必要があります。Data Guard RMANサポートについては、Oracle Data Guard概要および管理のRMANを使用したファイルのバックアップおよびリストアに関する説明を参照してください。

    • シャード・カタログ・データベースに指定された同じ宛先が、シャード・カタログ・スタンバイ・データベースのバックアップ先として使用されます。

    • テープ・デバイスへのシステム・バックアップの場合、RMANがデバイスに対してデータの読取りおよび書込みを行うチャネルを作成するには、テープ・デバイスへの特定のシステム・バックアップのメディア・マネージャが必要です。メディア・マネージャがインストールされ、適切に構成されている必要があります。

    関連項目:

  • バックアップ・ターゲット・タイプ

    バックアップ・ターゲット・タイプは、シャード・カタログ・データベースおよびシャードのバックアップをプライマリ・データベースで実行するか、スタンバイ・データベースのいずれかで実行するかを定義します。PRIMARYまたはSTANDBYのいずれかを指定できます。デフォルトのバックアップ・ターゲット・タイプはSTANDBYです。Data Guard構成にないシャード・カタログ・データベースまたはシャードの場合、バックアップ・ターゲット・タイプがSTANDBYの場合でも、バックアップはシャード・カタログ・データベースまたはシャード自体で実行されます。

  • バックアップ保持ポリシー

    バックアップ保存ポリシーでは、バックアップのデータベース・リカバリ期間を指定します。日数で指定されます。

    不要なバックアップは自動的に削除されませんが、手動で削除するためのGDSCTLコマンドが提供されています。

  • バックアップ・スケジュール

    バックアップ・スケジュールでは、レベル0およびレベル1の増分バックアップの自動バックアップ開始時間および繰返し間隔を指定します。シャード・カタログ・データベースおよび個々のシャードには、異なる自動バックアップ開始時間を使用できます。

    時間は、シャード・カタログ・データベースまたはシャードが配置されているタイムゾーンのローカル時間です。レベル0およびレベル1の増分バックアップのバックアップ繰返し間隔は、シャード・カタログ・データベースとシャード・データベース内のすべてのシャードで同じです。

  • シャード・カタログ・データベースのCDBルート・データベース接続文字列

    指定するユーザー・アカウントは、指定されたCDBで共通のSYSBACKUP権限を持っている必要があります。

CONFIG BACKUPコマンドにパラメータが指定されない場合、GDSCTLは現在のシャード・データベースのバックアップ構成を表示します。コマンドを使用してバックアップ構成を表示するときにバックアップがまだ構成されていない場合は、バックアップが構成されていないことが表示されます。

バックアップを構成するには、次の例に示すように、GDSCTL CONFIG BACKUPを実行します。構文、コマンド・オプションおよび使用上のノートの詳細は、HELP CONFIG BACKUPを実行してください。

次の例では、シャード・カタログ・データベースに対してDISKタイプのバックアップ・チャネルを構成し、シャードごとにDISKタイプの2つのパラレル・チャネルを構成し(シャード領域dbs1およびdbs2がシャード・リストで使用されます)、バックアップ保存ウィンドウを14日に設定し、レベル0およびレベル1の増分バックアップ繰返し間隔を7および1日に設定し、バックアップ開始時間を12:00 AMに設定し、増分バックアップ・タイプをデフォルトのDIFFERENTIAL、バックアップ・ターゲット・タイプをデフォルトのSTANDBYのままにします。 

GDSCTL> config backup -rccatalog rccatalog_connect_string 
-destination "CATALOG::configure channel device type disk format '/tmp/rman/backups/%d_%U'" 
-destination "dbs1,dbs2:configure device type disk parallelism 2:configure channel 1 device type disk format '/tmp/rman/backups/1/%U';configure channel 2 device type disk format '/tmp/rman/backups/2/%U'" 
-starttime ALL:00:00 -retention 14 -frequency 7,1 -catpwd gsmcatuser_password -cdb catcdb_connect_string;

GDSCTLが入力を取得すると、構成操作の現在のステータスに関連する、次のような出力が表示されます。

Configuring backup for database "sales_catalog" ...

Updating wallet ...
The operation completed successfully
 
Configuring RMAN ...
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/tmp/rman/backups/%d_%u';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
 
new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
...

Creating RMAN backup scripts ...
replaced global script full_backup 
replaced global script incremental_backup
...
Creating backup scheduler jobs ...
The operation completed successfully
 

Creating restore point creation job ...
The operation completed successfully

Configuring backup for database "sales_east" ...
 
Updating wallet ...
The operation completed successfully
 
Configuring RMAN ...
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
 
new RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/tmp/rman/backups/1/%u';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
...
 
Configuring backup for database "sales_west" ... 
Updating wallet ...
The operation completed successfully
 
Configuring RMAN ...
...

Recovery Manager complete.

前述のCONFIG BACKUPコマンドの出力に示すように、GDSCTLは次のステップを実行します。

  1. GDSCTLはシャード・ウォレットを更新します。

    更新されたウォレットには、次のものが含まれます。

    • RMANカタログ・データベースへの接続文字列および認証資格証明。

    • RMAN TARGETデータベースへの接続文字列および認証資格証明。

    • 自動バックアップ・ターゲット・タイプおよび開始時間。

  2. GDSCTLは、データベースのRMANバックアップ環境を設定します。

    これには、次のタスクが含まれます

    • リカバリ・カタログ内のターゲットとしてのデータベースの登録。

    • バックアップ・チャネルの設定。

    • バックアップ保持ポリシーの設定。

    • 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化。

    • すべてのターゲット・データベースのブロック変更トラッキングの有効化。

  3. シャード・カタログで、GDSCTLは、レベル0およびレベル1の増分バックアップ用のグローバルRMANバックアップ・スクリプトを作成します。

  4. シャード・カタログで、GDSCTLはグローバル・リストア・ポイント作成ジョブを作成します。

  5. シャード・カタログおよび各プライマリ・データベースで、GDSCTLは次の操作を実行します

    • レベル0およびレベル1の増分バックアップ用のDBMSスケジューラ・データベース・バックアップ・ジョブを作成します

    • 構成したバックアップ繰返し間隔に基づいてジョブをスケジュールします。

複数のリカバリ・カタログの指定

バックアップを構成する場合は、異なるリカバリ・カタログと異なるシャード、またはコマンドの各実行で指定されたシャード・カタログでGDSCTL CONFIG BACKUPを複数回実行することで、異なるシャードおよびシャード・カタログに異なるリカバリ・カタログを指定できます。

たとえば:

CONFIG BACKUP –shard shard_east -rccatalog rcadmin/rman@rc_east
CONFIG BACKUP –shard shard_west -rccatalog rcadmin/rman@rc_west

前述の2つのコマンドを実行した後、シャード"shard_east"はリカバリ・カタログとして"rc_east"を使用し、後続のすべての手動および自動バックアップ・ジョブおよびLIST/DELETE/VALIDATE/RESTORE BACKUPコマンドに対して"shard_west"は"rc_west"を使用します。

パラメータ-rccatalogが指定されていない場合は、前に指定したリカバリ・カタログ資格証明および接続識別子が使用されます。たとえば、前述の2つのコマンドを実行した後、パラメータ-rccatalogを指定せずに次のコマンドを発行するとします。 

CONFIG BACKUP –shard catalog ...

その後、シャード・カタログはリカバリ・カタログとして"rc_west"を使用します。

シャード・データベースに対してCONFIG BACKUPを-rccatalogなしで初めて実行した場合、このコマンドはエラー・メッセージを出力する以外に何も行わないことに注意してください。

バックアップ・セットの暗号化

Oracle Object Storeに格納するバックアップ・セットは暗号化する必要があります。次の手順を使用して、シャード・データベースのすべてのシャードおよびシャード・カタログで暗号化を設定します。

暗号化は、バックアップの保存先としてOracle Object Storeを使用しない場合でも使用できます。これは、データベースに機密データがある場合や、Amazon S3などのサードパーティのクラウド・ストレージを使用している場合にお薦めします。

タスク1: TDE暗号化の構成

バックアップ・セットの暗号化を有効にするには、ADMINISTER KEY MANAGEMENT権限またはSYSKM権限を持つユーザーが、シャードおよびシャード・カタログのルート・レベルですべてのコンテナ・データベース(CDB)に対して次のアクションを実行する必要があります。

  1. WALLET_ROOTおよびTDE_CONFIGURATION初期化パラメータを設定して、キーストアの場所とタイプを構成します。

    1. 最初に、WALLET_ROOTが既存のファイルの場所を指しているかどうかを確認します。

      必要に応じて、次のSQL*Plus文を使用して変更できます。

      ALTER SYSTEM SET WALLET_ROOT=wallet-root-location SCOPE=BOTH

    2. キーストアのタイプを指定します。

      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH;

    3. データベースを再起動します。

    次の点に注意してください。

    • WALLET_ROOTパラメータは、多数の異なるソフトウェア・キーストア(TDE、Oracle Enterprise User Security (EUS)、TLSなど)の最上位ディレクトリを指定します。TDEの場合、自動検出のディレクトリはWALLET_ROOT/tdeです。

    • 19cより前のリリースでは、SQLNET.ENCRYPTION_WALLET_LOCATIONパラメータを使用してキーストア・ディレクトリの場所を定義していました。このパラメータは非推奨となっています。かわりに、WALLET_ROOT静的初期化パラメータおよびTDE_CONFIGURATION動的初期化パラメータを使用することをお薦めします。
    • パラメータTDE_CONFIGURATIONの値がKEYSTORE_CONFIGURATION=FILEの場合、ソフトウェア・キーストアが使用されます。2つの代替キーストア・タイプ値は、Oracle Key Vaultまたはハードウェア・セキュリティ・モジュール・キーストアの場合はKEYSTORE_CONFIGURATION=OKV|HSMです。

  2. パスワード保護されたソフトウェア・キーストアを作成します。

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'wallet-root-location/tde'
 IDENTIFIED BY keystore_password;

    wallet-root-locationは、初期化パラメータWALLET_ROOTと同じ値である必要があることに注意してください。

  3. ソフトウェア・キーストアを開きます。

    ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
 IDENTIFIED BY keystore_password CONTAINER=ALL;

  4. TDE暗号化マスター・キーを設定します。

    ADMINISTER KEY MANAGEMENT SET KEY
 IDENTIFIED BY keystore_password WITH BACKUP CONTAINER=ALL;

関連項目: ソフトウェア・キーストアの構成(Oracle Database Advanced Securityガイド)

タスク2: 暗号化の有効化

バックアップ・セットの暗号化を有効にするには、GDSCTL CONFIG BACKUPコマンドでオプション-encryptionを使用して暗号化アルゴリズムを指定します。たとえば: 

GDSCTL> CONFIG BACKUP … -encryption shard-list:encryption-algorithm

サポートされているアルゴリズムのリストは、V$RMAN_ENCRYPTION_ALGORITHMSの列ALGORITHM_NAMEから取得できます。アルゴリズムが指定されると、CONFIG BACKUPコマンドは、リカバリ・カタログにバックアップ・ターゲット・データベースを登録した後、次のRMANスクリプトを起動します。 

CONFIGURE ENCRYPTION FOR DATABASE ON; 
CONFIGURE ENCRYPTION ALGORITHM TO encryption_algorithm;

ノート:

暗号化が必要なシャードおよびシャード・カタログにTransparent Data Encryptionを構成する必要があります。そうしないと、手動および自動のバックアップ・ジョブまたはVALIDATE/RESTORE BACKUPコマンドは失敗します。

バックアップ・セット暗号化の無効化

暗号化を無効にするには、CONFIG BACKUP -encryptionオプションをOFFに設定します。

OFFを指定すると、shard-listのシャードまたはシャード・カタログ(あるいはその両方)の暗号化が無効になります。たとえば: 

GDSCTL> CONFIG BACKUP … -encryption shard-list:OFF

その後、GDSCTLは次のRMANスクリプトを起動します。 

CONFIGURE ENCRYPTION FOR DATABASE OFF;

ノート:

暗号化が無効になっている場合、暗号化されたバックアップ・セットを使用してデータベースをリストアすることはできません。

バックアップの保存先としてのOracle Object Storageの使用

Oracle Object Storageは、ファイルを格納できるOracle Cloud Infrastructure上の便利な場所です。Oracle Recovery Manager (RMAN)には、GDSCTL CONFIG BACKUPコマンドを使用してオブジェクト・ストレージをシャード・データベースのバックアップの保存先として設定できるメディア・ライブラリがあります。

Oracle Object Storeをシャード・データベース・バックアップのリポジトリとして使用するには、次の前提条件を満たし、次に説明するようにCONFIG BACKUP保存先を指定します。

Oracle Object Storeのバックアップの保存先の前提条件

  1. 「バックアップ・セットの暗号化」の説明に従って、シャード・カタログおよびバックアップの保存先がオブジェクト・ストレージになるシャードを含めて、すべてのバックアップ・ターゲット・データベースで透過的データ暗号化(TDE)を構成します。

    これには、次のものが含まれます。

    • 初期化パラメータWALLET_ROOTおよびTDE_CONFIGURATIONを設定して、キーストアの場所とタイプを構成します。

    • TDEで使用されるソフトウェア・キーストアを作成します。

  2. 「バックアップ・セットの暗号化」の説明に従って、バックアップ・セットの暗号化を有効にします。

  3. 次のOracle Cloud関連のアカウントおよびIDを取得します。

    • Oracle Cloud Infrastructure Object Storageへのアクセス権を持つOracle Cloudアカウント
    • Oracle Cloud Infrastructure API署名キー、テナントOCIDおよびユーザーOCID

  4. バックアップの保存先として使用するOracle Object Storageバケットを作成します。

  5. シャード・カタログおよびすべてのシャードにOracle Cloud Infrastructureバックアップ・モジュールをインストールします。

    インストール時に次を指定します。

    • Oracle Cloudコンソールの資格証明 - インストーラはこれらの資格証明をウォレットに格納します。
    • バケット名およびエンドポイントURL
    • Oracle Cloud Infrastructure API署名キー、テナントOCIDおよびユーザーOCID

    詳細は、Oracle Database Backup Cloud Serviceの使用のOracle Database Cloud Backup Module for OCIのインストールを参照してください。

シャード・データベース・バックアップ構成でのバックアップの保存先の設定

次の例では、オブジェクト・ストレージがシャード領域dbs1のバックアップの保存先として設定されます。

GDSCTL> config backup
 –shard dbs1
 -rccatalog rccatalog_connect_string
 -catpwd password
 -cdb catcdb_connect_string
 -encryption dbs1:AES256 
 -destination dbs1:”CONFIGURE DEFAULT DEVICE TYPE TO SBT”:”CONFIGURE CHANNEL DEVICE TYPE SBT
 PARMS='SBT_LIBRARY=/orclhome/lib/libopc.so,SBT_PARMS=(OPC_PFILE=/orclhome/dbs/opct1.ora)’”

前述のように、オブジェクト・ストレージには、標準オプションに加えて、次のCONFIG BACKUPパラメータ設定が必要です。

  • オプション-encryptionを使用して、シャード領域で暗号化を有効にします。Oracle Object Storageをバックアップの保存先としてサポートするには、バックアップ・セットを暗号化する必要があります。

  • RMANデバイス構成およびチャネル構成文を使用して、オプション-destinationで次を指定します。

    • バックアップのデフォルト・デバイスとしてSBT_TAPE

    • 次のテンプレートを使用した、バックアップ・チャネル・パラメータ内のSBTライブラリ・ファイルおよびOPC構成ファイルの場所:
      CONFIGURE CHANNEL DEVICE TYPE sbt 
   PARMS='SBT_LIBRARY=location-of-SBT-library-for-backup-module, 
   SBT_PARMS=(OPC_PFILE=location-of-configuration-file)';

バックアップの保存先としてのリカバリ・アプライアンスの使用

リアルタイムREDOトランスポート用に構成されたZero Data Loss Recovery Appliance (リカバリ・アプライアンス)は、保護されたデータベースからREDOデータを直接トランスポートし、リカバリ・アプライアンスに格納します。これにより、連続するアーカイブ・ログ・バックアップ間に存在する潜在的なデータ損失の期間が最小限に抑えられます。

リカバリ・アプライアンスをシャード・データベース・バックアップのリポジトリとして使用するには、次の前提条件を満たし、次に説明するようにCONFIG BACKUP保存先を指定します。

前提条件

  1. 共有ライブラリlibra.soをリカバリ・アプライアンス・バックアップ・モジュールから、シャード・カタログおよび各シャードが配置されているホストにコピーします。

    このライブラリ・ファイルは、リカバリ・アプライアンスの$ORACLE_HOME/libディレクトリにあります。

  2. (リアルタイムREDOトランスポートを構成する場合にのみ必須)シャード・カタログおよびシャードのルート・レベルでREDOトランスポート・ユーザーを作成し、このユーザーにCREATE SESSIONおよびSYSOPER権限を付与します。 

    create user c##rman1 identified by rman1; 
grant create session, sysoper to rman1;

    次の点に注意してください

    • このユーザーは、シャード・カタログまたはシャードの共通ユーザーである必要があります。

    • このユーザーのユーザー名とパスワードは、シャード・カタログまたはシャードに割り当てられたリカバリ・アプライアンスの仮想プライベート・カタログ・ユーザーと同じである必要があります。

    • Data Guard構成では、プライマリ・データベースでのみこのユーザーを作成すると、そのユーザーはスタンバイ・データベースに伝播されます。

これにより、保護されたデータベースにリカバリ・アプライアンス・バックアップ・モジュールをインストールする必要がなくなります。さらに、保護されたデータベースをDBMS_RAパッケージに登録する必要はありません。CONFIG BACKUPコマンドにより、設定が自動化されます。

必要な情報の収集

  • シャード・カタログおよび各シャード上の共有ライブラリlibra.soの場所

  • リカバリ・アプライアンス・カタログへの接続文字列

  • RMANコマンドCONNECT CATALOGで使用するカタログ所有者のユーザー名とパスワード

  • リカバリ・アプライアンスの仮想プライベート・カタログ(VPC)アカウントのユーザー名とパスワード

    このユーザーに対してHTTP Digestアクセス認証を有効にする必要があります。

    たとえば:

    create user vpc_user1 identified by vpc;
grant create session to vpc_user1 identified by vpc; 
# enable HTTP digest access authentication
alter user vpc_user1 identified by vpc digest enable;

  • リカバリ・アプライアンスに作成された保護ポリシーの名前

  • シャード・カタログおよび各シャード用に予約されたリカバリ・アプライアンスのディスク領域の量

  • (リアルタイムREDOトランスポートを構成する場合にのみ必要)シャード・カタログまたはシャードによってリアルタイムREDOトランスポートに使用される自動ログイン・ウォレットの場所GDSCTL CONFIG BACKUPコマンドは、この場所にウォレットを作成します。

シャード・データベース・バックアップ構成でのバックアップの保存先の設定

次の例は、リカバリ・アプライアンス"ra_east"をシャード・データベースのバックアップの保存先として使用してバックアップ構成を設定するために、GDSCTLコマンドCONFIG BACKUPを発行する方法を示しています。 

GDSCTL> config backup
 –shard ALL
 -cdb catcdb_connect_string
 -zdlra_catalog username@ra_east
 -zdlra_vpc CATALOG:catalog_vpc_username
 -zdlra_vpc SH1:shard_vpc_username 
 -zdlra_policy CATALOG:catalog_protection_policy_name
 -zdlra_policy SH1:shard_protection_policy_name
 -zdlra_space CATALOG:20G
 -zdlra_space SH1:2T
 -zdlra_lib_dir CATALOG:?/lib
 -zdlra_lib_dir SH1:/u01/app/oracle/product/19.0.0/dbhome_1/lib

ノート:

-destinationおよび-rccatalogパラメータは、リカバリ・アプライアンスをバックアップの保存先として構成する場合には使用されません。

次に、例で使用されている-zdlra_*パラメータについて説明します。

パラメータ 説明/使用上のノート/例
-zdlra_catalog username[/password]@connect-string

このパラメータは、-rccatalogと相互に排他的です。

指定した場合、パラメータ-shardにリストされているすべてのシャードまたはシャード・カタログ(あるいはその両方)が、指定されたリカバリ・アプライアンスをバックアップの保存先として使用することを示します。

RASYS権限が必要なリカバリ・アプライアンス管理者のユーザー名および接続文字列を指定します。

たとえば:

-zdlra_catalog cat_username@ra_east

ノート:

  • パスワードが指定されていない場合は、パスワードを入力するように要求されます。
  • このパラメータに指定するユーザー名は、RASYS権限を持つリカバリ・アプライアンスの管理者です。パラメータ-zdlra_vpcで指定された仮想プライベート・カタログ・ユーザーとは異なります。
-zdlra_vpc(ALL|CATALOG|shard-list):username[/password]

-zdlra_catalogが指定されている場合は必須です。

指定されたシャード、シャードグループ、シャード領域またはリージョンのリカバリ・アプライアンスVPC (仮想プライベート・カタログ)ユーザーのユーザーを指定します。

たとえば:

-zdlra_vpc CATALOG:catalog_vpc_username

-zdlra_vpc SH1:shard_vpc_username

ノート:

  • このパラメータは、1つのコマンドラインで複数回指定して、異なるシャードに対して異なるVPCユーザーを許可できます。
  • シャード・リストは、シャード識別子のカンマ区切りリストを指定します。シャード領域、シャードグループ、リージョンまたはシャード名です。
  • パスワードが指定されていない場合は、パスワードを入力するように要求されます。

このユーザーは、パラメータ-zdlra_catalogに指定されているリカバリ・アプライアンス管理者(RASYSユーザー)とは異なります。

-zdlra_policy (ALL|CATALOG|shard-list):protection-policy-name

-zdlra_catalogが指定されている場合は必須です。

リカバリ・アプライアンスで定義された保護ポリシーの名前を指定します。

たとえば:

-zdlra_policy CATALOG:brzone_dev

-zdlra_policy SH1:silver_dev

ノート:

  • このパラメータは、1つのコマンドラインで複数回指定して、異なるシャードに対して異なる保護ポリシーを許可できます。
  • シャード・リストは、シャード識別子のカンマ区切りリストを指定します。シャード領域、シャードグループ、リージョンまたはシャード名です。
-zdlra_space (ALL|CATALOG|shard-list):(0-9)+(K|M|G|T|P|E|Z|Y)

-zdlra_catalogが指定されている場合は必須です。

各シャードおよびシャード・カタログのリカバリ・アプライアンスに割り当てられるディスク領域の量を指定します。

たとえば:

-zdlra_space CATALOG:20G

-zdlra_space SH1:2T

ノート:

  • このパラメータは、異なるシャードに対して領域要件が異なる場合に、1つのコマンドラインで複数回指定できます。
  • シャード・リストは、シャード識別子のカンマ区切りリストを指定します。シャード領域、シャードグループ、リージョンまたはシャード名です。
  • 末尾の文字は、次のリストの単位指定子です。

    K: キロバイト

    M: メガバイト

    G: ギガバイト

    T: テラバイト

    P: ペタバイト

    E: エクサバイト

    Z: ゼッタバイト

    Y: ヨタバイト
-zdlra_lib_dir (ALL|CATALOG|shard-list):library-location

-zdlra_catalogが指定されている場合は必須です。

リカバリ・アプライアンス・バックアップ・モジュールの共有ライブラリlibra.soの場所を指定します。この場所には、指定されたシャードまたはシャード・カタログからアクセスできる必要があります。

たとえば:

-zdlra_lib_dir CATALOG:?/lib

-zdlra_lib_dir SH1:/u01/app/oracle/product/23.1.0/dbhome_1/lib

ノート:

  • このパラメータは、異なるシャード上のライブラリの場所が異なる場合に、1つのコマンドラインで複数回指定できます。
  • 疑問符(?)を使用して、ORACLE_HOME環境変数を表すことができます。アットマーク記号(@)は、ORACLE_SID環境変数を表します。これは、異なるシャードに対してOracleインストール・フォルダが異なる場合に、設定を簡略化するのに役立ちます。

    たとえば、ライブラリ・ファイルの場所が$ORACLE_HOME/lib/フォルダにある場合、ユーザーは次のパラメータを使用して、すべてのシャードのライブラリ・ファイルの場所を指定できます。

    -zdlra_lib_dir ALL:?/lib
-zdlra_redo_wallet (ALL|CATALOG|shard-list):wallet-location

省略可能です。

リカバリ・アプライアンスにログインするためにREDOトランスポート・レイヤーで使用される自動ログイン・ウォレットの場所を指定します。

指定すると、CONFIG BACKUPコマンドにより、パラメータ-shardで指定されたデータベースのリアルタイムREDOトランスポートが構成され、保護されたデータベースごとに自動ログイン・ウォレットが作成されます。

たとえば:

-zdlra_redo_wallet CATALOG:?/wallet

-zdlra_redo_wallet SH1:/u01/app/oracle/product/23.1.0/dbhome_1/wallet

ノート:

  • このパラメータは、異なるシャード上のウォレットの場所が異なる場合に、1つのコマンドラインで複数回指定できます。
  • 疑問符(?)およびアットマーク記号(@)を使用して、それぞれORACLE_HOMEおよびORACLE_SID環境変数を表すことができます。これは、異なるシャードに対してOracleインストール・フォルダが異なる場合に、設定を簡略化するのに役立ちます。
  • 次のエントリが自動ログイン・ウォレットに追加されます。

    (connect-string-specified-in-parameter-zdlracatalog, VPC-username, VPC-user-password)

    VPCのユーザー名とパスワードは、パラメータ-zdlra_vpcから取得されます。前提条件で説明したように、保護されたデータベースで、VPCユーザーと同じユーザー名を持つREDOトランスポート・ユーザーを作成する必要があります。

その他のCONFIG BACKUPパラメータの詳細は、『Global Data Services概要および管理ガイド』の「Global Data Services制御ユーティリティ(GDSCTL)コマンド・リファレンス」を参照してください。

リアルタイムREDOトランスポートの構成後要件

リアルタイムREDOトランスポートが必要な場合は、CONFIG BACKUPの実行後に次の処理を実行します。

  • REDOトランスポートで使用されるウォレットの場所をsqlnet.oraに追加し、SQLNET.WALLET_OVERRIDEをTRUEに設定します。 

    WALLET_LOCATION= 
 (SOURCE=(METHOD=FILE)(METHOD_DATA= 
 (DIRECTORY= wallet_location))) 
SQLNET.WALLET_OVERRIDE=TRUE

  • シャード・カタログおよびシャードのプライマリ・データベースを再起動すると、sqlnet.oraへの変更を有効にできます。

  • シャード・カタログおよびシャード(すべてのプライマリ・データベースおよびスタンバイ・データベース)で、初期化パラメータREDO_TRANSPORT_USERをREDOトランスポート・ユーザー(仮想プライベート・カタログ(VPC)ユーザーと同じユーザー名を使用する)に変更します。

    たとえば:

    alter system set "redo_transport_user"=" c##rman1";

  • 手動バックアップを1回実行するか、最初の自動バックアップが実行されるまで待機すると、リアルタイムREDOトランスポートがアクティブになります。

    アクティブな場合、リカバリ・アプライアンスの次の問合せはTRUEを返します: 

    select NZDL_ACTIVE
from DBMS_RA. RA_DATABASE 
where DB_UNIQUE_NAME='DB_UNIQUE_NAME-of-the-protected-database'

バックアップの保存先としてのAmazon S3の使用

Amazon S3 (Amazon Simple Storage Service)は、クラウドベースのストレージ・サービスです。OracleのSecure Backup Cloud Moduleは、Oracle Recovery Manager (RMAN)を使用してバックアップ・セットをAmazon S3ストレージに格納できます。

Amazon S3をシャード・データベース・バックアップのリポジトリとして使用するには、次の前提条件を満たし、次に説明するようにCONFIG BACKUP保存先を指定します。

Amazon S3のバックアップの保存先の前提条件

Oracle Secure Backup Cloud Moduleは、シャード・カタログ、およびバックアップ・セットがAmazon S3クラウド・ストレージに送信されるシャードにインストールする必要があります。

インストール中に、次のいくつかのパラメータを指定する必要がありますが、これに限定されません。

  • (必須) AWSID: Amazon S3クラウド・ストレージ・サービスのアクセス・キーID
  • (必須) AWSKey: 前述のIDのパスワード
  • (オプション) awsEndpoint: バックアップ・セットが送信されるホスト名
  • (オプション) awsPort: HTTP/HTTPS接続ポート番号
  • (オプション) location: Amazon S3の場所
  • (オプション) walletDir: Amazon S3資格証明を格納するOracleウォレットのディレクトリ、およびプロキシ情報(該当する場合)
  • (オプション) configFile: RMANで使用されるパラメータ(Oracleウォレット・ディレクトリを含む)を含む構成ファイル。
  • (オプション) libDir: ダウンロードしたOracle Secure Backup Cloud Moduleライブラリを格納するディレクトリ

インストール中に、Amazon S3資格証明およびプロキシ情報(該当する場合)を格納するウォレットを作成し、構成ファイルを作成して、Oracle Secure Backup Cloud Moduleライブラリをダウンロードします。

バックアップ・モジュールのインストールの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の「Amazon S3でのOracle Secure Backup Cloud Moduleの使用」を参照してください。

Amazon S3ストレージを宛先とするバックアップ・セットを暗号化することもお薦めします。詳細は、「バックアップ・セットの暗号化」を参照してください。

シャード・データベース・バックアップ構成でのバックアップの保存先の設定

次の例は、Amazon S3をシャード領域DBS1のバックアップの保存先として使用し、バックアップ・セットの暗号化を有効にしてバックアップ構成を設定するために、GDSCTLコマンドCONFIG BACKUPを発行する方法を示しています。 

GDSCTL> config backup
 –shard dbs1
 -rccatalog rccatalog_connect_string
 -catpwd password
 -cdb catcdb_connect_string
 -encryption dbs1:AES256 
 -destination dbs1: "CONFIGURE DEFAULT DEVICE TYPE TO SBT":
"CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' 
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/19.0.0/dbhome_1/lib/libosbws.so 
ENV=(OSB_WS_PFILE=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/osbwssales.ora)'"

Amazon S3をバックアップの保存先として使用するには、オプション-destinationでチャネル構成文を記述する際に次の情報を指定する必要があります。

  • 共有ライブラリlibra.soへのパス
  • RMANで使用される構成ファイルの場所

    CONFIGURE CHANNELコマンドのテンプレートは次のとおりです。 

    CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
   PARMS 'SBT_LIBRARY=secure-backup-library-location 
   ENV=(OSB_WS_PFILE=configuration-file-location)'

    Amazon S3に関連するRMANチャネル設定の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』のリカバリ・アプライアンス用のRMAN SBTチャネルの構成を参照してください。

自動バックアップの有効化および無効化

すべてのシャード、または特定のシャード、シャード領域またはシャードグループでバックアップを有効または無効にできます。

すべてのバックアップ・ジョブは最初は無効になっています。これらは、GDSCTL ENABLE BACKUPコマンドを実行することで有効にできます。 

GDSCTL> ENABLE BACKUP

指定しない場合、ENABLE BACKUPはすべてのシャードでバックアップを有効にします。オプションで、バックアップを有効にする特定のシャード、シャード領域またはシャードグループをリストできます。 

GDSCTL> ENABLE BACKUP -shard dbs1

DISABLE BACKUPコマンドは、有効なバックアップを無効にします。 

GDSCTL> DISABLE BACKUP -shard dbs1

バックアップ・ジョブ操作

バックアップ・ジョブを構成して有効にすると、プライマリ・シャード・カタログ・データベースおよびプライマリ・シャードでスケジュールどおりに実行されます。

バックアップ・ジョブは、構成後、最初は無効化されます。バックアップ・ジョブをスケジュールどおりに実行するには、バックアップ・ジョブを有効にする必要があります。GDSCTLコマンドのENABLE BACKUPおよびDISABLE BACKUPを使用して、ジョブを有効または無効にします。

バックアップ・ジョブは、レベル0およびレベル1の増分バックアップ用に構成したバックアップ繰返し間隔、およびシャード・カタログ・データベースとシャードのバックアップ開始時間に基づいてスケジュールされます。

レベル0とレベル1の増分バックアップ用に2つの個別ジョブが作成されます。ジョブの名前は、AUTOMATED_SDB_LEVEL0_BACKUP_JOBおよびAUTOMATED_SDB_LEVEL1_BACKUP_JOBです。両方のジョブで完全ロギングが有効です。

バックアップ・ジョブを実行すると、構成済のバックアップ・ターゲット・タイプ(PRIMARYまたはSTANDBY)が検出され、バックアップ・ターゲット・タイプに基づいて適切なターゲット・データベースが検出された後、RMANを起動してターゲット・データベースをバックアップします。RMANは、データベース接続認証のバックアップ構成中に更新されたシャード・ウォレットを使用します。

シャード・データベース・チャンクの移動によって自動バックアップが遅延されることはありません。

バックアップ・ステータスのモニタリング

自動バックアップ・ジョブおよびオンデマンド・バックアップ・ジョブのステータスを監視するには、いくつかの方法があります。

自動バックアップ・ジョブの監視

自動バックアップ・ジョブでは完全ロギングが有効になっているため、DBMSスケジューラはジョブ・ログおよびビューにジョブ処理の詳細を書き込みます。スケジューラのジョブ・ログおよびビューは、自動バックアップを監視するための基本的なリソースと開始点です。DBMSスケジューラでは、ジョブの状態変更イベントのリストを電子メール通知サブスクリプションに使用できることに注意してください。この機能は、シャード・データベースの自動バックアップには使用されません。

GDSCTLコマンドLIST BACKUPを使用して、バックアップを表示し、構成されたバックアップ・ジョブの繰返し間隔でバックアップが作成されているかどうかを確認できます。

自動バックアップはシャード・データベースでのチャンク移動によって遅延されないため、バックアップ作成時間は構成済のバックアップ繰返し間隔およびバックアップ開始時間に近い必要があります。

オンデマンド・バックアップ・ジョブの監視

内部的には、オンデマンド・バックアップ・ジョブもデータベース・サーバー上のDBMSスケジューラ・ジョブによって開始されます。一時ジョブの名前には、タグMANUAL_BACKUP_JOB_が接頭辞として付きます。オンデマンド・バックアップは、GDSCTLがデータベース・サーバーとの通信に使用するセッションと常に同じセッションで実行されます。ジョブの障害は、クライアントに直接送信されます。

DBMSスケジューラ・ジョブ・ビューの使用

自動バックアップ・ジョブは、プライマリ・シャード・カタログ・データベースおよびプライマリ・シャードでのみ実行されます。特定のターゲット・データベースのバックアップ・ジョブの詳細を確認するには、SQL*PLUSを使用して、データベースまたはそのプライマリ・データベース(データベースがData Guard構成内にある場合)に接続し、ジョブ名に基づいてDBMSスケジューラ・ビュー*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILSを問い合せます。

2つの自動バックアップ・ジョブの名前は、AUTOMATED_SDB_LEVEL0_BACKUP_JOBおよびAUTOMATED_SDB_LEVEL1_BACKUP_JOBです。

GDSCTLコマンドのSTATUS BACKUPを使用して、ジョブの状態を取得し、これらのビューから詳細を実行することもできます。STATUS BACKUPの実行の詳細は、バックアップ・ジョブ・ステータスの表示を参照してください。

ジョブ・ビューには、ジョブに関する上位レベルの情報のみが含まれます。ジョブ障害診断の場合、RDBMSトレース・ファイルでジョブ名を増やすことで、ジョブの詳細を確認できます。

ジョブでエラーが見つからず、まだバックアップが作成されていない場合は、トレース・ファイル内のバックアップに対してRMANを実行するためにジョブによって作成されたプロセスのPIDを検索し、PIDに関連付けられたトレース・ファイルで有用な情報を検索できます。

バックアップ・コマンド出力の使用

このオプションは、オンデマンドバックアップにのみ使用できます。

GDSCTL RUN BACKUPを使用してオンデマンド・バックアップを開始するときに、-syncコマンド・オプションを指定できます。これにより、すべてのバックアップ・タスクが強制的にフォアグラウンドで実行され、データベース・サーバーで内部的に起動されたRMANからの出力がGDSCTLコンソールに表示されます。

フォアグラウンドでバックアップ・タスクを実行するメリットは、タスクが順番に実行されるため、バックアップ全体の完了に時間がかかることです。

コマンド構文およびオプションの詳細は、Oracle Database Global Data Services概要および管理ガイドのGDSCTLのリファレンスを参照してください。

既存のバックアップ構成の表示

GDSCTL CONFIG BACKUPにパラメータが指定されていない場合、現在のバックアップ構成が表示されます。

パラメータ-destinationおよび-starttimeは、異なるシャードのCONFIG BACKUPコマンドラインに複数回出現する可能性があり、バックアップ構成は複数回実行できるため、「バックアップ先」および「バックアップ開始時間」の各セクションに複数のアイテムをリストできます。項目はCONFIG BACKUPコマンドラインで指定されたのと同じ順序でリストされ、コマンドが繰り返し実行されます。

既存のバックアップ構成を表示するには、次に示すようにCONFIG BACKUPを実行します。 

GDSCTL> CONFIG BACKUP;

シャード・データベース・バックアップがまだ構成されていない場合、コマンド出力に示されます。それ以外の場合、出力は次のようになります。

GDSCTL> config backup
Recovery catalog database user: rcadmin
Recovery catalog database connect descriptor: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=den02qxr)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=cdb6_pdb1.example.com)))
Catalog database root container user: gsm_admin
Catalog database root container connect descriptor: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=den02qxr)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=v1908.example.com)))
Backup retention policy in days: 14
Level 0 incremental backup repeat interval in minutes: 10080
Level 1 incremental backup repeat interval in minutes: 1440
Level 1 incremental backup type : DIFFERENTIAL
Backup target type: STANDBY
Backup destinations:
catalog::channel device type disk format '/tmp/rman/backups/%d_%u'
dbs1,dbs2:device type disk parallelism 2:channel 1 device type disk format '/tmp/rman/backups/1/%u';channel 2 device type disk format '/tmp/rman/backups/2/%u'
catalog::configure channel device type disk format '/tmp/rman/backups/%d_%u'
dbs1,dbs2:configure device type disk parallelism 2:configure channel 1 device type disk format '/tmp/rman/backups/1/%u';configure channel 2 device type disk format '/tmp/rman/backups/2/%u'
Backup start times:
all:00:00

複数のリカバリ・カタログのCONFIG BACKUP出力

複数のリカバリ・カタログがある構成でパラメータなしで発行されたCONFIG BACKUPの出力には、異なるシャードおよびシャード・カタログのリカバリ・カタログ・ユーザーおよび接続識別子が出力されます。最後に使用したリカバリ・カタログも出力されます。たとえば: 

GDSCTL> config backup
...  
Recovery catalog database user:  
last::rcadmin_west 
shard_east::rcadmin_east 
shard_west::rcadmin_west  
Recovery catalog databaseconnect identifier:   
last::<theconnect identifier of rc_west> 
shard_east::<theconnect identifier of rc_east> 
shard_west::<theconnect identifier of rc_west> 
...

ノート:

  • 前述の例の実際の出力では、3つの実際のコネクタ識別子が出力されます。
  • この例は、リカバリ・カタログ設定に関連する部分のみを示しています。

オンデマンド・バックアップの実行

GDSCTL RUN BACKUPコマンドを使用すると、シャード・カタログ・データベースおよびシャードのリストのバックアップを開始できます。

すべてのオンデマンド・バックアップはレベル0の増分バックアップです。オンデマンド・バックアップは、シャード・カタログ・データベースおよびシャードに構成された自動バックアップ・スケジュールには影響しません。

内部的には、オンデマンド・バックアップはデータベース・サーバー上のDBMSスケジューラ・ジョブによって開始されます。ジョブは、オンデマンド・バックアップ・コマンドRUN BACKUPの実行時にオンザフライで作成されます。

オンデマンド・バックアップ・ジョブは一時ジョブであり、バックアップの終了後に自動的に削除されます。

一時ジョブの名前には、タグMANUAL_BACKUP_JOB_が接頭辞として付きます。

RUN BACKUPを使用するには、CONFIG BACKUPコマンドを使用してバックアップ構成を設定しておく必要があります。

RUN BACKUPコマンドでは、シャード・カタログ・データベースとプライマリ・シャードをオープンしてバックアップする必要があります。 

GDSCTL> RUN BACKUP -shard dbs1

-shardオプションを使用すると、バックアップを実行するシャード、シャード領域またはシャードグループのセットを指定できます。シャード領域dbs1でオンデマンド・バックアップを実行するには、前述の例に示すように、RUN BACKUPを実行します。

コマンド構文およびオプションの詳細は、Oracle Database Global Data Services概要および管理ガイドのGDSCTLのリファレンスを参照してください。

バックアップ・ジョブのステータスの表示

GDSCTLコマンドSTATUS BACKUPを使用して、指定したシャードのスケジュール済バックアップ・ジョブの詳細な状態を表示します。コマンド出力には、ジョブの状態(有効または無効)とジョブ実行の詳細が含まれます。

デフォルトでは、このコマンドは、指定されたシャードで自動バックアップ・ジョブが30日前から保持していたすべての実行のジョブ実行詳細を表示します。異なる期間のジョブ実行詳細が必要な場合は、-start_timeオプションおよび-end_timeオプションを使用する必要があります。

次の例に示すように、STATUS BACKUPを実行します。

次のSTATUS BACKUPコマンドの例では、SDBカタログおよびプライマリ・シャード「rdbmsb_cdb2_pdb1」からジョブの状態およびすべてのジョブ実行の詳細をリストします。 

GDSCTL> status backup -catpwd -shard catalog,rdbmsb_cdb2_pdb1;
"GSMCATUSER" password:***
 
Retrieving scheduler backup job status for database "rdbms" ...
Jobs:
  Incremental Level 0 backup job is enabled
    Job schedule start time: 2020-07-27 00:00:00.000 -0400
    Job repeat interval: freq=daily;interval=1
  Incremental Level 1 backup job is enabled
    Job schedule start time: 2020-07-27 00:00:00.000 -0400
    Job repeat interval: freq=minutely;interval=60
  Global restore point create job is enabled
    Job schedule start time: 2020-07-27 23:59:55.960 -0400
    Job repeat interval: freq=hourly
 
Run Details:
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 14:00:00.177 -0400
    Job run slave process ID: 9023
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 22:00:01.305 -0400
Job run slave process ID: 59526
…
Global restore point create job status: SUCCEEDED
    Job run actual start time: 2020-07-27 15:28:37.603 -0400
    Job run slave process ID: 44227
  …
  Global restore point create job status: SUCCEEDED
    Job run actual start time: 2020-07-27 17:28:38.251 -0400
    Job run slave process ID: 57611
  
Retrieving scheduler backup job status for database "rdbmsb_cdb2_pdb1" ...
Jobs:
  Incremental Level 0 backup job is enabled
    Job schedule start time: 2020-07-28 00:00:00.000 -0400
    Job repeat interval: freq=daily;interval=1
  Incremental Level 1 backup job is enabled
    Job schedule start time: 2020-07-28 00:00:00.000 -0400
    Job repeat interval: freq=minutely;interval=60
 
Run Details:
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 14:00:00.485 -0400
    Job run slave process ID: 9056
  …
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-27 14:33:42.702 -0400
    Job run slave process ID: 9056
  Incremental Level 0 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-27 00:00:01.469 -0400
    Job run slave process ID: 75176

次のコマンドは、SDBカタログおよびプライマリ・シャード"rdbmsb_cdb2_pdb1"から2020/07/26 12:00:00から07/27 00:00までの時間枠におけるスケジューラ・バックアップ・ジョブの状態およびジョブ実行の詳細をリストします。

GDSCTL> status backup -start_time "2020-07-26 12:00:00" -end_time "2020-07-27 00:00:00" -catpwd -shard catalog,rdbmsb_cdb2_pdb1;
"GSMCATUSER" password:***

Retrieving scheduler backup job status for database "rdbms" ...
Jobs:
  Incremental Level 0 backup job is enabled
    Job schedule start time: 2020-07-27 00:00:00.000 -0400
    Job repeat interval: freq=daily;interval=1
  Incremental Level 1 backup job is enabled
    Job schedule start time: 2020-07-27 00:00:00.000 -0400
    Job repeat interval: freq=minutely;interval=60
  Globa1 restore point create job is enabled
    Job schedule start time: 2020-07-27 23:59:55.960 -0400
    Job repeat interval: freq=hourly
 
Run Details:
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 14:00:00.177 -0400
    Job run slave process ID: 9023
  …
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 23:50:00.293 -0400
    Job run slave process ID: 74171
  Globa1 restore point create job status: SUCCEEDED
    Job run actual start time: 2020-07-26 14:28:38.263 -0400
    Job run slave process ID: 11987
  …
  Globa1 restore point create job status: SUCCEEDED
    Job run actual start time: 2020-07-26 23:28:37.577 -0400
    Job run slave process ID: 69451
 
Retrieving scheduler backup job status for database "rdbmsb_cdb2_pdb1" ...
Jobs:
  Incremental Level 0 backup job is enabled
    Job schedule start time: 2020-07-28 00:00:00.000 -0400
    Job repeat interval: freq=daily;interval=1
  Incremental Level 1 backup job is enabled
    Job schedule start time: 2020-07-28 00:00:00.000 -0400
    Job repeat interval: freq=minutely;interval=60
 
Run Details:
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 14:00:00.485 -0400
    Job run slave process ID: 9056
  Incremental Level 1 backup job status: SUCCEEDED
    Job run actual start time: 2020-07-26 22:11:50.931 -0400
    Job run slave process ID: 9056

バックアップの表示

GDSCTL LIST BACKUPを使用して、シャード・データベースまたはシャードのリストを特定のグローバル・リストア・ポイントにリストアするために使用できるバックアップをリストします。

このコマンドではシャード・カタログ・データベースをオープンする必要がありますが、シャードはnomount、mountまたはopenのいずれかの開始状態にできます。

コマンドで、バックアップをリストするシャードのリストを指定できます。リストされたデータベースの制御ファイルをリストアするために使用可能なバックアップをリストし、スタンバイ・シャードのバックアップをリストすることもできます。

次の例は、コマンドを使用して、リストア・ポイントBACKUP_BEFORE_DB_MAINTENANCEにリカバリ可能なシャードcdb2_pdb1からバックアップをリストする方法を示しています。 

GDSCTL> LIST BACKUP -shard cdb2_pdb1 -restorepoint BACKUP_BEFORE_DB_MAINTENANCE

オプション-controlfileが使用されている場合、LIST BACKUPSは、指定されたシャードの制御ファイルのリストアに使用可能なバックアップのみをリストします。オプション-summaryを使用すると、バックアップはサマリー形式でリストされます。 

GDSCTL> list backup -shard shd1,shd2 -controlfile -summary

バックアップの検証

GDSCTL VALIDATE BACKUPコマンドを実行して、シャード・データベース・バックアップをシャードのリストの特定のグローバル・リストア・ポイントに対して検証します。検証により、指定したリストア・ポイントまでデータベースをリストアするためのバックアップが使用可能で破損していないことが確認されます。

シャード・カタログ・データベースはオープンしている必要がありますが、シャード・データベースはマウント済またはオープンのいずれかにできます。バックアップ検証がデータベース制御ファイルに対するものである場合、シャードはマウントなしで開始できます。

次の例では、リストア・ポイントBACKUP_BEFORE_DB_MAINTENANCEにリカバリ可能なシャード・カタログ・データベースからの制御ファイルのバックアップを検証します。 

GDSCTL> VALIDATE BACKUP -shard shd1,shd2 -controlfile -restorepoint BACKUP_BEFORE_DB_MAINTENANCE

シャードのバックアップ検証は、連続して1つのシャードに対して実行されます。

バックアップの削除

リカバリ・リポジトリからバックアップを削除するには、GDSCTL DELETE BACKUPコマンドを使用します。

DELETE BACKUPコマンドは、特定のタグで識別されたシャード・データベース・バックアップをリカバリ・リポジトリから削除します。提供されたタグで識別されるバックアップのリカバリ・データベース内のレコードが削除され、ファイルが配置されているメディアにアクセスできる場合は、それらのバックアップから物理ファイルがバックアップ・セットから削除されます。これは、各ターゲット・データベースに対して実行されます。実際の削除を開始する前に、確認を求められます。

このコマンドを実行するには、シャード・カタログ・データベースがオープンしている必要がありますが、シャード・データベースはマウントまたはオープンできます。

次に、タグodb_200414205057124_0400を含むバックアップをシャードcdb2_pdb1から削除する例を示します。 

GDSCTL> DELETE BACKUP -shard cdb2_pdb1 -tag ODB_200414205057124_0400
"GSMCATUSER" password:

This will delete identified backups, would you like to continue [No]?y

Deleting backups for database "cdb2_pdb1" ...

グローバル・リストア・ポイントの作成およびリスト

グローバル・リストア・ポイントをコールするシャード・データベースのリストア・ポイント。実際には、シャード・データベース内の個々のプライマリ・データベースの通常のリストア・ポイントのセットにマップされます。

これらのリストア・ポイントは、シャード・データベース内のすべてのプライマリ・データベースの共通SCNで作成されます。プライマリ・データベースで作成されたリストア・ポイントは、Data Guardスタンバイ・データベースに自動的にレプリケートされます。データベースがこの共通SCNにリストアされると、リストアされたシャード・データベースは一貫性のある状態であることが保証されます。

グローバル・リストア・ポイントの作成は、シャード・データベース・チャンクの移動と相互排他的である必要があります。ジョブが実行されると、最初にチャンク移動が進行中かどうかがチェックされ、完了するまで待機します。チャンクの移動には長時間かかる場合があります。また、前のチャンク移動が終了する前に、新しいチャンク移動を開始できます。その場合、グローバル・リストア・ポイント作成ジョブは、共通SCNを生成してグローバル・リストア・ポイントを作成する機会が生じる前に、非常に長い時間待機する可能性があります。したがって、グローバル・リストア・ポイントが毎時作成されることは保証されません。

グローバル・リストア・ポイントを作成するには、次に示すように、GDSCTLコマンドCREATE RESTOREPOINTを実行します。 

GDSCTL> CREATE RESTOREPOINT

グローバル・リストア・ポイント作成ジョブは、シャード・カタログ・データベースで構成されます。ジョブの名前はAUTOMATED_SDB_RESTOREPOINT_JOBです。このジョブの完全ロギングが有効です。

次に示すように、-nameオプションを使用して、リストア・ポイントの名前をオプションで入力できます。 

GDSCTL> CREATE RESTOREPOINT -name CUSTOM_SDB_RESTOREPOINT_JOB

ジョブは最初は無効になっているため、GDSCTL ENABLE BACKUPを使用してジョブを有効にする必要があります。ジョブは毎時実行され、スケジュールは構成できません。

すべてのグローバル・リストア・ポイントをリストするには、LIST RESTOREPOINTを実行します。 

GDSCTL> LIST RESTOREPOINT

このコマンドは、(-start_timeおよび-end_timeオプションを使用して)指定したSCN間隔で(-start_scnおよび-end_scnオプションを使用して) SCNを使用して、指定した期間中に作成されたシャード・データベース内の使用可能なすべてのグローバル・リストア・ポイントをリストします。

次のコマンドは、2600000から2700000の間のSCNを持つシャード・データベース内の使用可能なリストア・ポイントをリストします。

GDSCTL> LIST RESTOREPOINT -start_scn 2600000 -end_scn 2700000

次のコマンドは、2020/07/27 00:00:00から2020/07/28 00:00:00までの時間枠で作成されたシャード・データベース内の使用可能なリストア・ポイントをリストします。

GDSCTL> LIST RESTOREPOINT -start_time "2020-07-27 00:00:00" -end_time "2020-07-28 00:00:00"

バックアップからのシャードのリストア

GDSCTL RESTORE BACKUPコマンドを使用すると、シャード・データベースを特定のグローバル・リストア・ポイントにリストアできます。

このコマンドは、シャード・データベースを特定のグローバル・リストア・ポイントにリストアするために使用します。シャード・データベースの制御ファイルのみをリストアするために使用することもできます。

シャード・データベースをリストアする一般的な手順は次のとおりです。

  1. 使用可能なリストア・ポイントをリストします。
  2. リストア・ポイントを選択してバックアップを検証します。
  3. 選択したリストア・ポイントにデータベースをリストアします。

シャードのリストア・ポイントへのリストアを開始する前に、選択したリストア・ポイントに対してシャードのバックアップを検証し、必要なすべてのバックアップが使用可能であることを確認する必要があります。

シャード・カタログまたは特定のシャードを任意の時点にリストアすることは禁止されていません。ただし、これを行うと、そのターゲットが残りのシャード・データベースと一貫性のない状態になる可能性があり、リストア操作の外部で修正処理を実行する必要がある場合があります。

リストアするデータベースはNOMOUNT状態である必要があります。このコマンドは、制御ファイルをリストアした後、データベースをMOUNT状態に変更します。

RESTORE BACKUPコマンドでは、シャード・カタログ・データベースがオープンされている必要があります。

データファイルのリストアの場合、シャードはMOUNT状態である必要がありますが、制御ファイルをリストアするコマンドの場合、シャード・データベースはNOMOUNT状態で起動する必要があります。データベースを適切な状態にするには、手動のステップを実行します。

シャード・データベースの制御ファイルをリストアするには、データベースをマウントなしモードで起動する必要があります。制御ファイルは自動バックアップからリストアされます。データベース・データファイルをリストアするには、データベースがマウントされている必要があります。このコマンドを機能させるには、シャード・カタログ・データベースがオープンしている必要があります。

次の例では、シャードcdb2_pdb1の制御ファイルをリストア・ポイントBACKUP_BEFORE_DB_MAINTENANCEにリストアします。 

GDSCTL> RESTORE BACKUP -shard cdb2_pdb1 -restorepoint BACKUP_BEFORE_DB_MAINTENANCE –controlfile

リストア操作は、シャードに対してパラレルに実行できます。シャードのリストアがパラレルで行われる場合、リストア操作を中断するとデータベースが破損したり、シャード・データベースが一貫性のない状態になる可能性があるため、コマンドの実行が完了するまでGDSCTLをクローズしないでください。

バックアップの検証ではデータベースのみが論理的にリストアされ、RESTORE BACKUPでは物理データベースのリストアとデータベースのリカバリの両方が実行されます。したがって、RESTORE BACKUPの実行後は、通常、リストアされたデータベースをresetlogsオプションを使用してオープンする必要があります。

データベースのリストアが完了したら、データベースをオープンし、データベースが意図したとおりにリストアされ、良好な状態であることを確認する必要があります。

バックアップからのシャード・カタログのリストア

バックアップからリストアするシャード・カタログを構成するには:

  • シャード・データベースは、バックアップおよびリストア用に構成されている必要があります。
  • CDBは、制御ファイルのリストアの場合はNOMOUNT状態で、シャード・カタログのリストアの場合はMOUNTまたはOPEN状態で起動する必要があります。

GDSCTLがRESTORE BACKUPコマンドを実行してシャード・データベース制御ファイルおよびシャード・カタログPDBをリストアするために、シャード・カタログへのデータベース接続は必要ありません。

シャード・カタログ・リストアでは、次の構文に示すように、シャードのリストアに使用されるいくつかの異なるパラメータとともにGDSCTL RESTORE BACKUPを使用します。 

GDSCTL> RESTORE BACKUP -shard CATALOG
    -cdb connect-string
    -catalog_name pdb-name
    -catalog_dbid dbid
    [-scn scn]
    [-controlfile]
    [-restore_only | -recover_only]

シャード・カタログ・データベースはリストア時にオープンしていない必要があり、データベースのリストアに必要なカタログから取得できる一部の情報は自動的に使用できないため、RESTORE BACKUPコマンドで指定する必要があります。これには、次のものが含まれます。

  • ルート・コンテナにSYSDG権限を持ち、シャード・カタログCDBとそのパスワード内のすべてのコンテナに対するSYSBACKUP権限を持つ共通ユーザー
  • シャード・カタログCDBルートへの接続識別子(-cdb connect-string)
  • シャード・カタログPDBの名前(-catalog_name pdb-name)
  • シャード・カタログDBID (-catalog_dbid dbid)
  • シャード・カタログを特定のグローバル・リストア・ポイントにリストアする必要がある場合は、グローバル・リストア・ポイントの名前のかわりに、関連するSCNをコマンドに指定する必要があります(-scn scn)

シャードからのバックアップ構成の削除

シャード・データベース構成からシャードを削除すると、一部のバックアップ・アーティファクトがデータベースに残ります。これらのアーティファクトは、GDSCTL CONFIG BACKUPオプションの-REMOVEを使用して削除できます。

シャードがシャード・データベース構成から削除されると、シャードは自動バックアップ・ジョブに含まれなくなりますが、シャードがバックアップ用に構成されたときにデータベース・ホストで作成されたアーティファクト(バックアップ・ウォレットやバックアップ・ジョブなど)は削除されません。

シャード・データベースから削除する前にこれらのアーティファクトをシャードから削除するには、次に示すように、-REMOVEオプションを指定してCONFIG BACKUPを実行し、削除するシャードのリストを指定します。 

GDSCTL> CONFIG BACKUP -remove -shard shard_list

コマンドによって次のタスクが実行されます。

  • シャードPDBコンテナ・レベルのバックアップ・ウォレットを削除します。
  • シャード・データベースからDBMSスケジューラ・バックアップ・ジョブを削除します。
  • CDBが他のシャード・データベースによる共有ターゲット・データベースではない場合(同じCDBセット内に複数のシャード・データベースが配置された場合に発生します)、CDBルート・コンテナ・レベルのバックアップ・ウォレットを削除します。

このコマンドは、シャードが削除され、同じシャード・データベースに戻される予定がない場合にのみ使用してください。

GDSCTLからのRMANコマンドの実行

RMANコマンドは、GDSCTL CLIから発行して、複数のシャードおよびシャード・カタログに対してシリアルまたはパラレルで実行できます。

前提条件

GDSCTL CLIからRMANコマンドを実行するには、GDSCTL CONFIG BACKUPコマンドを使用して、シャード・データベースがバックアップおよびリストア用に構成されている必要があります。

一部のRMANコマンドでは、OPEN、MOUNTまたはNOMOUNTの特定の状態のターゲット・データベースも実行可能である必要があります。また、一部のRMANコマンドは、RMANがターゲット・データベースとしてCDBルートに接続されている場合にのみ実行できます。したがって、シャードに対して実行するRMANコマンドを発行する前に、ターゲット・シャードとそのCDBがコマンドで必要な特定の状態であることを確認してください。

GDSCTL RMANコマンドの使用

GDSCTLには、GDSCTLセッションでRMANコマンドを実行できるRMANコマンドが用意されています。

RMANコマンドを渡すには、ファイルを参照するか、またはGDSCTL RMANコマンドにRMAN文を含めます。

  • 各RMAN文の後にセミコロンを入力します。

    GDSCTL> RMAN -shard cdb1_pdb1 rman-stmt1;rman-stmt2;

    指定したRMANコマンドに空白および引用符が含まれている場合は、RMAN文を一重引用符または二重引用符に含める必要があります。

    GDSCLT> RMAN -shard cdb1_pdb1 'rman-stmt1;rman-stmt2;'

  • RMANコマンド・ファイルのファイル・パスを指定します。

    GDSCTL> RMAN -shard cdb2_pdb1 -cmd_file file-path

次のオプションを使用できます。

   
-async

このコマンドを実行するために作成されたすべてのタスクがバックグラウンドで実行されることを指定します。

デフォルトでは、これらのタスクはフォアグラウンドで実行されます。
-catpwd password

ユーザーGSMCATUSERのパスワードを指定します。指定しない場合は入力を求められます。

GDSCTLセッション全体に対して1回のみ指定する必要があります。
-check_syntax

RMANコマンド構文の検証としてコマンドを実行します。
-from_cdb userid/password

シャードCDBルートの共通ユーザーとそのパスワードを指定できます。

このオプションは、指定されたRMANコマンドをCDBルートから実行する必要がある場合に必要です。つまり、RMANコマンドを実行するためにRMANがターゲット・データベースとしてCDBルートに接続されます。

指定されたユーザーにはSYSBACKUP権限が必要です。

デフォルトでは、指定されたRMANコマンドはシャードPDBから実行されます。
-shard shard-list

シャード識別子のカンマ区切りリストを指定できます。

各識別子は、シャード領域、シャードグループまたはシャード名です。

デフォルトは"no shards"です。

自動バックアップ操作のエラー処理

自動バックアップのエラー処理

RMANのBACKUPコマンドが完了すると、スケジューラ・ジョブの実行が続行されます。RMAN出力でエラーを確認します。エラーが見つからない場合、ファイルは削除され、ジョブは続行されて正常に完了すると予測されます。RMAN出力ファイルにエラーが見つかった場合は、次のように処理されます。

  • RMAN出力ファイルは保持されます。
  • ジョブ実行エラー・ステータスは、表ALL_SCHEDULER_JOB_RUN_DETAILSに記録されます。
  • RMANの出力ファイル名は、元のRMAN出力ファイルへのパスとともに、ALL_SCHEDULER_JOB_RUN_DETAILS表のADDITIONAL_INFO列に格納されます。

バックグラウンド・タスクのエラー処理

コマンドがバックグラウンドで実行されると、フェッチされたRMAN出力がメモリーに保持されます。コマンドが完了すると、タスクはRMAN出力にエラーがないかを確認します。エラーが検出された場合は、RMAN出力の最後の1024文字がGDSCTLコンソールに表示されます。

この場合、RMAN出力全体が、コマンドCONFIGURE -LOG_FILEを使用して指定されたGDSCTLログ・ファイルにも記録されます。