Oracle Exadata Database Service on Exascale Infrastructureでのデータベースのバックアップおよびリカバリの管理

Oracle Exadata Database Service on Exascale Infrastructureで提供されるバックアップおよびリカバリ機能を使用する方法について学習します。

バックアップ操作およびリカバリ操作を実行するためのOracle推奨オプション

Oracle Databaseのバックアップおよびリカバリ操作用に次のオプションが用意されています。これらのオプションは相互に排他的です。

ノート

ハイブリッド構成、つまりオプションの混在はサポートされていません。オプションを混在させると自動化できなくなります。2025年8月6日以降、FRA、PHXまたはNRTリージョンで作成されたテナンシの場合、データベースで自動バックアップを有効にすると、Autonomous Recovery Serviceが唯一のバックアップ先になります。

オプション1: Oracle管理バックアップ

Oracle管理バックアップは、1回かぎりの構成に基づいて、Exadata Cloud Infrastructure (ExaDB-D)またはExadata Cloud@Customer (ExaDB-C@C)によって完全に管理されます。これらのバックアップは、ExaDB-DまたはExaDB-C@Cクラウド・サービスのコントロール・プレーンに完全に統合されるだけでなく、OCI APIを介してアクセスすることもできます。このアプローチをお薦めします。

  • dbaascli database backupおよびdbaascli database recoverコマンドは、特定の操作のために自動バックアップと組み合せて使用できます。詳細は、dbaascli database backupおよびdbaascli database recoverを参照してください。
  • 顧客は、RMANビューを問い合せたり、表、データファイル、表領域のリカバリ・コマンドなどのRMANのリストアおよびリカバリ・コマンドを発行したりできます。
    ノート

    RMAN構成を使用して、チューニング済のクラウドRMAN設定を変更しないでください。

オプション2: ユーザー構成バックアップ

dbaascli database backupおよびdbaascli database recoverコマンドを使用して、ホストからのバックアップを構成することもできます。ただし、これらのバックアップはコントロール・プレーンと同期されず、OCI APIと統合されません。また、これらのバックアップの管理およびライフサイクル操作は、サービス・コントロール・プレーン・コンソールからはサポートされていません。そのため、この方法はお薦めしません。

この方法は、特定のタスクを実行するためにバックアップの保存先への直接アクセスが必要な場合に役立ちます。たとえば、リージョン間でバックアップをレプリケートしたり、バックアップの保存先をモニターするために、OSSバケットにアクセスします。

OCIコントロール・プレーンまたはOCI APIを使用せずにRMANを使用してオブジェクト・ストレージへのバックアップを構成する場合、お客様はTDE Walletバックアップを手動で構成する必要があります。デフォルトでは、Oracleクラウド自動化はアーカイブ・ログ・ファイルを24時間ごとにクリーンアップします。RMANを使用して手動バックアップを実行すると、アーカイブ・ログが削除されるリスクがあります。アーカイブ・ログのクリーンアップの構成方法の詳細は、dbaascli database backupを参照してください。Oracle管理バックアップを使用することをお薦めします。

詳細は、ユーザー構成バックアップを参照してください。

オプション3: RMANを使用したバックアップ

顧客が所有するカスタマイズされたスクリプトでRMANを使用してバックアップを直接作成できます。ただし、このアプローチはお薦めしません。

RMANバックアップをOracle管理バックアップまたはユーザー構成バックアップとともに使用することはお薦めしません。

このオプションを使用する可能性のある人:
  • 既存のRMANバックアップ/リストア・スクリプトを維持する必要のある顧客。
  • Data Guard環境のスタンバイ・データベースからバックアップを構成して、バックアップ・ワークロードをスタンバイにオフロードする必要のある顧客。

RMANを使用してバックアップする場合は、バックアップの自動化からデータベースの登録を解除する必要があります。詳細は、手動バックアップおよびリカバリ管理を容易にするための自動バックアップの無効化を参照してください。

Exadata Databaseバックアップの管理

自動Exadataデータベース・バックアップは、Oracle Cloud Infrastructureによって管理されます。これは、コンソールまたはAPIを使用して構成します。

管理対象外バックアップについては、dbaascliを使用したExadata Databaseバックアップの管理を参照してください。

自動Exadataデータベース・バックアップには、Autonomous Recovery ServiceまたはOracle Object Storageの2つの宛先を使用できます。

Oracle管理の自動バックアップ機能は、コンソールを使用してバックアップ設定を簡単に構成できるため、Oracle Cloudデータベースをバックアップするための推奨方法です。自動バックアップ機能では、リカバリ・サービスおよびオブジェクト・ストレージがバックアップの保存先としてサポートされ、同じコストで完全に自動化されたクラウド・バックアップ・ソリューションが提供されます。手動バックアップまたはバックアップ・ストレージ管理タスクを実行する必要はありません。また、バックアップをローカル・ストレージに格納することもできます。次に示す各バックアップ保存先のメリットと要件を考慮する必要があります。

リカバリ・サービス(推奨)

Oracle Databasesの最新のサイバーセキュリティ保護を提供する、オンプレミスのOracleのZero Data Loss Recovery Applianceテクノロジに基づくフルマネージド・サービスです。独自の自動機能により、Oracle Databaseの変更をリアルタイムで保護し、本番データベースのオーバーヘッドなしでバックアップを検証し、任意の時点への高速で予測可能なリカバリを実現します。

バックアップが現在Object Storageで構成されている場合、リカバリ・サービスにシームレスに移行して、同じコストで高度な機能を実現できます。

リカバリ・サービスの詳細は、Oracle Database Autonomous Recovery Serviceについてを参照してください。

オブジェクト・ストレージ

データベースのためのセキュアでスケーラブルなオンデマンド・ストレージ・ソリューション。

ノート

以前にdbaascliを使用してバックアップを構成していた場合、バックアップ用のコンソールまたはAPIの使用に切り替えます:

  • 新規バックアップ構成が作成され、データベースに関連付けられます。このため、データベースを保護するために、以前に構成した管理されていないバックアップを使用できなくなります。

管理されたバックアップのタイプおよび使用情報

自動Exadataデータベース・バックアップには、Autonomous Recovery ServiceとOracle Object Storageの2つのタイプがあります。

バックアップ操作を成功させるには、データベースとインフラストラクチャ(VMクラスタまたはDBシステム)が使用可能状態である必要があります。バックアップ操作の進行中に可用性を妨げる可能性のあるアクション(パッチ適用操作など)を実行しないことをお薦めします。自動バックアップ操作が失敗した場合、データベース・サービスは、翌日のバックアップ・ウィンドウで操作を再試行します。Oracle Exadata Database Service on Exascale Infrastructureインスタンスおよびデータベースの可用性をリストアすると、オンデマンドのフル・バックアップが失敗した場合、操作を再試行できます。

自動バックアップ機能を有効にすると、どちらのサービスでも、選択したバックアップ保存先へのデータベースの増分バックアップが毎日作成されます。

自動バックアップを有効にする場合は、保存期間を制御できます。割り当てられた保存期間の期限が切れると、バックアップが自動的に削除されます。

オブジェクト・ストレージ・バックアップ保持期間

保存期間(日数)は、7、15、30、45、60です。デフォルト: 30日

自動バックアップ・プロセスは、日次バックアップ・ウィンドウ内の任意の時間に開始されます。ユーザーは、データベースの自動バックアップ・プロセスが開始される2時間のスケジュール・ウィンドウを、オプションで指定できます。偶数時に開始される12のスケジューリング・ウィンドウから選択できます(たとえば、1つ目のウィンドウを午前4時から6時まで、その次のウィンドウを午前6時から8時までに指定できます)。スケジュール・ウィンドウ内にバックアップ・ジョブが完了するとはかぎりません

ウィンドウを指定しない場合、Exadata Cloud Infrastructureインスタンスのリージョンのタイム・ゾーンの00:00から06:00までのデフォルトのバックアップ・ウィンドウがデータベースに割り当てられます。デフォルトのバックアップ・スケジュール・ウィンドウは6時間ですが、指定するバックアップ・ウィンドウは2時間です。

Autonomous Recovery Serviceの保護ポリシー

  • ブロンズ:14日
  • シルバー: 35日
  • ゴールド: 65日
  • Platinum: 95日
  • ユーザーが定義したカスタム
  • デフォルト: シルバー- 35日

自動バックアップ・プロセスは、いつでも、または割り当てられたウィンドウ内で開始されます。

ノート

  • Data Guard: ただし、そのデータベースの自動バックアップは、そのデータベースがプライマリ・ロールを引き継ぐまでは作成されません。
  • バックアップ保持の変更:今後、データベースのバックアップ保持期間または保護ポリシーを短くすると、更新された保持期間外の既存のバックアップはシステムによって削除されます。
  • バックアップ・ストレージ・コスト:自動バックアップでは、選択したバックアップの保存先に応じて、Autonomous Recovery ServiceまたはObject Storageのストレージ使用コストが発生します。

どちらのサービスを使用しても、いつでもデータベースの全体バックアップを作成できます。

Exadata Cloud Serviceインスタンス・データベースを終了すると、そのすべてのリソースが削除されます。オブジェクト・ストレージの宛先を使用する管理対象バックアップは削除され、Autonomous Recovery Serviceを使用する管理対象バックアップは、選択した削除オプションに従って削除されます。オブジェクト・ストレージで作成されたスタンドアロン・バックアップは、データベースの終了後に残るため、手動で削除する必要があります。スタンドアロン・バックアップを使用して、新しいデータベースを作成できます。

バックアップおよびリカバリ操作でSYSBACKUP管理権限を使用するというOracle推奨プラクティスに準拠するため、クラウド自動化によって、CDB$ROOTコンテナ・レベルでSYSBACKUPロールを持つ共通の管理ユーザーC##DBLCMUSERが作成されます。そのため、バックアップおよびリカバリ操作は、最小限必要な権限を持つユーザーを使用して実行されます。このユーザーの資格証明は、クラウド自動化によってランダムに生成され、安全に管理されます。ユーザーが見つからないか、LOCKEDおよびEXPIREDである場合、クラウド自動化によって、バックアップまたはリカバリ操作中にこのユーザーが再作成またはロック解除されます。このクラウド自動化の変更は、dbaastoolsバージョン21.4.1.1.0から行われました。

OCIコンソールを使用した自動バックアップおよびスタンドアロン・バックアップの有効化時のバックアップの保存先の動作

自動バックアップ

2025年8月6日より、OCIコンソールで自動バックアップを有効にすると、次の条件下でAutonomous Recovery Serviceが使用可能な唯一のバックアップ保存先になります。

  • テナンシは、2025年8月6日以降に作成されました。
  • データベースは、OCIリージョンのフランクフルト(FRA)、フェニックス(PHX)および東京(NRT)にデプロイされます。
  • Oracle Databaseのバージョンが19.18または23.4より後です。
  • リージョンに使用可能な容量およびバックアップの制限があります。

    ノート: 制限または容量が使用できない場合は、制限の引上げリクエストを送信するように求められます。

OCIオブジェクト・ストレージがバックアップ・オプションとして使用可能な場合

次のシナリオでは、OCI Object Storageがバックアップの保存先として引き続き表示されます。

  • テナンシは、2025年8月6日より前に作成されました。
  • データベースのバージョンが19.18または23.4より前です。
  • リージョンはFRA、PHXまたはNRTではありません。
  • データベース・サイズをサポートするためのリージョン容量が不足しているため、Autonomous Recovery Serviceのオンボーディングが失敗します。

その他のシナリオ

  • リージョン間のData Guard構成:プライマリ・データベースがFRA、PHXまたはNRTの外部のリージョンにあり、スタンバイ・データベースがこれらのリージョンのいずれかにある場合、Autonomous Recovery Serviceを使用してバックアップできるのはスタンバイのみです。OCI Object Storageは、新しいテナンシではFRA、PHXまたはNRTではサポートされていません。
  • 混合テナンシ・リージョン: 2つのリージョン(1つは既存のテナンシ(FRA、PHXまたはNRT以外)で、もう1つはFRA、PHXまたはNRTの新しいテナンシ)で操作する場合、既存のリージョンにOCIオブジェクト・ストレージ、新しいリージョンにAutonomous Recovery Serviceを使用した分割バックアップ構成が発生します。
  • 2025年8月6日以降のマルチリージョン・デプロイメント: 2025年8月6日より後に作成された新しいテナンシで、FRA、PHX、NRTおよびIADでのデプロイメントでは、バックアップ構成が異なります。FRA、PHXおよびNRTではAutonomous Recovery Serviceが使用されますが、IADでは引き続きOCI Object Storageがサポートされます。

スタンドアロン・バックアップ

FRA、PHXおよびNRTリージョンで作成された新しいテナンシの場合、スタンドアロン・バックアップの既存の動作は、OCIコンソールとOCI APIの両方で変更されません。

動作は次のとおりです。

  • 自動バックアップがOCI Object Storageに構成されている場合、スタンドアロン・バックアップはOCI Object Storageに格納されます。
  • 自動バックアップがAutonomous Recovery Serviceに構成されている場合、スタンドアロン・バックアップはAutonomous Recovery Serviceに格納されます。
  • 自動バックアップが構成されていない場合、スタンドアロン・バックアップはデフォルトでOCI Object Storageに設定されます。

リカバリ・サービスを使用した長期保存バックアップ

長期保存バックアップ(LTR)では、完全なLTRライフサイクル管理と不変性により、コンプライアンス、規制またはその他のビジネス・ニーズに対して最大10年間の完全バックアップを格納できます。

リカバリ・サービスを使用するLTRの場合、保存期間は、バックアップが作成された日から日数(90 - 3,650)または年数(1 - 10)である必要があります。

必要な保存期間でLTRバックアップを作成するために、Recovery Serviceでは、新しい完全本番バックアップを作成する必要はありませんが、ポリシーの定義済リカバリ・ウィンドウ内でシステム内の既存の運用バックアップを使用して作成します。詳細は、データベースのオンデマンド・バックアップを作成するにはを参照してください。

特定の既存のLTRバックアップの保存期間は、保存期間内に変更できます。詳細は、「リカバリ・サービスを使用したLTRバックアップの保存期間を変更するには」を参照してください。

LTRバックアップをリストアして、保存期間内に新しいデータベースを作成できます。詳細は、バックアップからデータベースを作成するにはを参照してください。

データベースの終了時に、LTRバックアップは「データベース終了後の削除オプション」の値に従って削除されます。

  • 72時間でのバックアップの削除: 長期バックアップを含むすべてのバックアップが削除されます。
  • ポリシーに基づいて削除: LTRバックアップは、各LTRバックアップの保存ポリシーに従って保持されます。

ノート: Oracleでは、長期バックアップが保持されるように、データベースの終了時に「ポリシーに基づいて削除」オプションを選択することをお薦めします。

長期バックアップでは、次の追加の要因を考慮します。

  • LTRバックアップは、データベースで構成されている自動バックアップとは独立して存在し続けます。
  • LTRバックアップは、指定した保存期間の終了後に自動的に削除されます。
  • インプレース・リストアはLTRではサポートされていません。
  • Data Guard構成のデータベースの場合、長期バックアップはリクエストされたデータベースに対してのみ作成されます。
  • LTRを作成するには、データベースがAVAILABLE状態である必要があります。
  • LTRは、ファイルベースのTDEまたはKMSベースのキーストアを持つデータベースでサポートされています。
  • 暗号化キーは、LTRの保持期間全体にわたって保持されます。
  • LTRバックアップは、'作成'状態の間は取り消すことができます。
  • LTRバックアップは、作成後いつでも削除できます。
  • リストア中:
    • バックアップがサポートされているDBHomeメジャー・バージョンの場合、そのバージョンの最新RUにリストアされます。
    • バックアップがサポートされていないDBHomeメジャー・バージョンの場合は、サポートされているメジャー・バージョンにリストアされ、その後、サポートされているメジャー・バージョンのいずれかにデータベースをアップグレードする必要があります。

デフォルト・バックアップ・チャネルの割当て

これらは、「Oracle管理バックアップ」または「ユーザー構成バックアップ」を使用する場合のデータベース・バックアップ・チャネルのデフォルト設定です。

データベースが「Oracle管理バックアップ」または「ユーザー構成バックアップ」を使用するバックアップ用に構成されている場合、ツールではバックアップ・チャネルに「デフォルト」が使用されます。デフォルトが使用されると、割り当てるチャネルの数は、バックアップまたはリストア・コマンドの実行時にdbaasによって決定されます。割り当てられるチャネルの数は、ノードのコア数によって決まります。次の表に、使用される値およびコア範囲を示します。コアとチャネル値は両方ともノード単位です。リストア操作が優先されます。クラスタ全体の合計チャネル数は、ノード当たりの値にノード数を掛けた数です。自動化では、SCANを使用して、クラスタ内のすべてのノードにRMANチャネルを分散します。

各ノードのコア ノード当たりのバックアップ・チャネルの割当て ノード当たりのリストア・チャネルの割当て
以下 12 コア<= 12 2 4
12より大きく、24以下 コア> 12およびコア<= 24 4 8
24より大きい コア> 24 8 16

必要に応じて、DBAASCLI getConfig/configureを使用してbckup cfgファイルを生成し、パラメータbkup_channels_nodeを必要なノード当たりのチャネル数に設定することで、静的なノード単位の値を設定できます。

有効な値は1から32です: 合計チャネル数は、ノード数を掛けた値です。この値は、255チャネルの制限を超えることはできません。bkup_channels_nodedefaultの値によって、コア・チャネル・ベースの割当てが設定されます。

Exascaleインフラストラクチャ上のOracle Exadata Database Serviceのバックアップの前提条件

リカバリ・サービス

リカバリ・サービスを使用するようにテナンシが構成されていることを確認します。

表5-4リカバリ・サービスを自動バックアップの保存先として使用する前に前提条件タスクを確認する

タスク 詳細情報 必須またはオプション

IAMポリシーの作成

リカバリ・サービスを使用するためにOCIのOracle Databasesに必要な権限

必須

ネットワーク・リソースを構成し、リカバリ・サービス・サブネットを登録します

データベースVCNでのリカバリ・サービス・サブネットを作成します

必須

保護ポリシーの作成

保護ポリシーを作成する

オプションです

リカバリ・サービスの詳細は、Oracle Database Autonomous Recovery Serviceの概要を参照してください。

オブジェクト・ストレージ

  • Exadata Cloud Serviceでは、Oracle Cloud Infrastructure Object Storageにアクセスする必要があります。VCNでサービス・ゲートウェイを使用してこのアクセスを有効にすることをお薦めします。詳細は、Exascaleインフラストラクチャ・インスタンス上のOracle Exadata Database Serviceのネットワーク設定を参照してください。そのトピックでは、特に次のことに注意してください:
  • バックアップの保存先として使用する既存のオブジェクト・ストレージ・バケット。コンソールまたはオブジェクト・ストレージAPIを使用してバケットを作成できます。詳細は、バケットの管理を参照してください。
  • Oracle Cloud Infrastructureによって生成された認証トークン。コンソールまたはIAM APIを使用してパスワードを生成できます。詳細は、認証トークンの作業を参照してください。
  • バックアップ構成ファイルで指定されるユーザー名には、オブジェクト・ストレージへのテナンシレベルのアクセス権が必要です。これを行うための簡単な方法は、ユーザー名を管理者グループに追加することです。ただし、これにより、すべてのクラウド・サービスに対するアクセスが許可されます。そうせずに、管理者は、データベースのバックアップとリストアに必要なオブジェクト・ストレージ内のリソースにのみアクセスできるようにする、次のようなポリシーを作成する必要があります:
    Allow group <group_name> to manage objects in compartment <compartment_name> where target.bucket.name = '<bucket_name>'
    Allow group <group_name> to read buckets in compartment <compartment_name>

    グループへのユーザーの追加の詳細は、グループの管理を参照してください。ポリシーの詳細は、ポリシーの開始を参照してください。

コンソールを使用したバックアップの管理

コンソールを使用して、データベースに対して自動増分バックアップの有効化、オンデマンドでのフル・バックアップの作成、管理されたバックアップのリストの表示を行うことができます。コンソールを使用して、手動(オンデマンド)でバックアップを削除することもできます。

ノート

  • すべてのバックアップは、Transparent Data Encryption (TDE)ウォレット暗号化に使用されたものと同じマスター・キーで暗号化されます。
  • 特定のデータベースのバックアップは、そのデータベースの詳細ページにリストされます。独自の暗号化キーを使用してデータベースを保護している場合、「暗号化キー」列には「Oracle管理キー」またはキー名が表示されます。詳細は、ボールトおよびキーのバックアップを参照してください。
ノート

ボールトから必要な暗号化キーを削除しないでください。削除すると、キーで保護されているデータベースおよびバックアップが使用できなくなります。

データベースの自動バックアップを構成するには

データベースのオンデマンド・バックアップを作成するには

ノート

リカバリ・サービスによって増分バックアップが作成されるときに、オブジェクト・ストレージによってデータベースの完全バックアップが作成されます。
  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Exascaleインフラストラクチャ上のExadata Database Service」をクリックします
  2. コンパートメントを選択します。
  3. バックアップするデータベースを含むクラウドVMクラスタに移動します:

    「エクサスケール・インフラストラクチャ上のOracle Exadata Database Service」で、「Exadata VMクラスタ」をクリックします。VMクラスタのリストで、アクセスするVMクラスタを検索し、強調表示された名前をクリックしてクラスタの詳細ページを表示します。

  4. データベースのリストで、オンデマンドのフル・バックアップを作成するデータベースを検索し、その名前をクリックしてデータベース詳細を表示します。
  5. 「リソース」で、「バックアップ」をクリックします。

    バックアップのリストが表示されます。

  6. 「バックアップの作成」をクリックします。
  7. 表示されるバックアップの作成ウィンドウで、次の手順を実行します。
    • 名前: バックアップのわかりやすい名前を指定します。
    • 「バックアップ保持」オプションを選択します:
      • バックアップ保持期間ごとのバックアップの保持: このオプションを選択して、このバックアップの保護ポリシー保持期間を使用します。
      • 長期バックアップ保持期間の指定: 自律リカバリ・サービスでLTR期間を指定するには、このオプションを選択します。保存期間は、バックアップが作成された日から日数(90 - 3,650)または年数(1 - 10)で入力する必要があります。
    • 「作成」をクリックします。

バックアップ・ステータスを表示するには

バックアップを取り消すには

オブジェクト・ストレージからフル・バックアップを削除するには

スタンドアロン・バックアップをオブジェクト・ストレージから削除するには

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「リソース」の下の「スタンドアロン・バックアップ」をクリックします。
  2. スタンドアロン・バックアップのリストで、削除するバックアップを検索します。
  3. 対象のバックアップの「アクション」メニューをクリックし、「削除」をクリックします。
  4. 「削除」ダイアログで、「削除」をクリックしてバックアップの削除を確認します。

リカバリ・サービスを使用してLTRバックアップの保持期間を変更するには

  1. ナビゲーション・メニューを開きます。「Oracle Database」を選択し、「Exascaleインフラストラクチャ上のExadata Database Service」を選択します。
  2. コンパートメントを選択します。
  3. バックアップ保存期間を変更するデータベースを含むクラウドVMクラスタまたはDBシステムに移動します:

    「Exascaleインフラストラクチャ上のExadata Database Service」で、「Exadata VMクラスタ」をクリックします。VMクラスタのリストで、アクセスするVMクラスタを検索し、強調表示された名前をクリックしてクラスタの詳細ページを表示します。

  4. データベースのリストで、保存期間を変更するデータベースの名前をクリックします。
  5. 「リソース」で、「バックアップ」をクリックします。

    バックアップのリストが表示されます。

  6. バックアップのリストで、保存期間を変更する「長期バックアップ」タイプのバックアップの「アクション」メニューをクリックします。
  7. 「保持期間の変更」をクリックします。
  8. 結果の保存期間の変更で、保存期間を変更します。
    ノート

    保存期間は、バックアップが作成された日から日数(90 - 3,650)または年数(1 - 10)で入力する必要があります。
  9. 「保存」をクリックします。

Autonomous Recovery Serviceを既存のデータベースのバックアップ保存先として指定するには

バックアップ保存先からのExadata Databaseのリカバリ

このトピックでは、コンソールまたはAPIを使用して、オブジェクト・ストレージまたはAutonomous Recovery Serviceに格納されているバックアップからExadataデータベースをリカバリする方法について説明します。

  • オブジェクト・ストレージ・サービスは、Exadata Cloud Infrastructureの安全で拡張可能なオンデマンド・ストレージ・ソリューションです。
  • OracleDatabase Autonomous Recovery Serviceは、Oracle Cloud Infrastructure(OCI)データベース向けの一元化されたフルマネージドのスタンドアロン・バックアップ・ソリューションです。

オブジェクト・ストレージへのデータベースのバックアップの詳細は、Exadata Databaseバックアップの管理を参照してください。

コンソールを使用したデータベースのリストア

コンソールを使用して作成されたバックアップ保存先のバックアップからデータベースをリストアするには、コンソールを使用できます。

ノート

LTRバックアップは、データベースの単一ポイント・イン・タイムを表すため、リストア時に次のオプションはサポートされていません。

次のようにリストアできます。

  • 最新の状態にリストア: 可能なかぎりデータ損失の多い、最後に検証された正常な状態にデータベースをリストAします。
  • タイムスタンプにリストア: 指定されたタイムスタンプにデータベースをリストアします。
  • SCNにリストア: 指定したSCNを使用してデータベースをリストアの処理を行います。このSCNは有効である必要があります。
    ノート

    データベース・ホストにアクセスして問い合せるか、オンラインまたはアーカイブ・ログにアクセスすることで、使用するSCN番号を決定できます。
ノート

コンソールに表示されるバックアップのリストには、管理されていないバックアップ(dbaascliを使用して直接作成されたバックアップ)はありません。

データベースをリストアするには

この手順を使用して、Exascale Infrastructure Oracle Database上のExadata Database Serviceをリストアします。

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Exascaleインフラストラクチャ上のExadata Database Service」をクリックします
  2. 「Exadata VMクラスタ」をクリックします。
  3. VMクラスタのリストで、リストアするデータベースを構成するVMクラスタを検索し、強調表示された名前をクリックしてクラスタの詳細ページを表示します。
  4. データベースのリストで、リストアするデータベースを検索し、その名前をクリックしてそれに関する詳細を表示します。
  5. 「リストア」をクリックします。
  6. 次のいずれかのオプションを選択し、「データベースのリストア」をクリックします:
    • 最新の状態にリストア: 可能なかぎりデータ損失の少ない、最後に確認された正常な状態にデータベースをリストアします。
    • タイムスタンプにリストア: データベースを指定したタイムスタンプにリストアします。
    • システム変更番号(SCN)にリストア: 指定したSCNを使用してデータベースをリストアします。このSCNは有効である必要があります。

      ノート

      データベース・ホストにアクセスして問い合せるか、オンラインまたはアーカイブ・ログにアクセスすることで、使用するSCN番号を決定できます。
  7. 要求されたら、確認します。

    リストア操作が失敗すると、データベースは「リストアに失敗しました」状態になります。別のリストア・オプションを使用してリストアを再試行できます。ただし、データベースのリストアを再試行する前に、ホスト上のRMANログを確認し、問題を修正することをお薦めします。これらのログ・ファイルは、/var/opt/oracle/logディレクトリのサブディレクトリにあります。

dbaascliを使用したExadata Databaseバックアップの管理

Exadataのバックアップ・ユーティリティdbaascliを使用して、Exascaleインフラストラクチャ上のOracle Exadata Database Service上のデータベースをOracle Object Storageサービスの既存のバケットにバックアップできます。

Oracle Cloud Infrastructureによって管理されるバックアップについては、Exadata Databaseバックアップの管理を参照してください。

このトピックでは、次の方法について説明します:

  • デフォルトのバックアップ構成ファイルを作成し、データベースをオブジェクト・ストレージ・サービスにバックアップするための要件に合せてパラメータを変更します。
  • バックアップ構成ファイルとデータベースを関連付けます。構成が成功すると、データベースはスケジュールどおりにバックアップされるか、タグを使用してオンデマンド・バックアップを作成できます。

デフォルトのバックアップ構成

デフォルトのバックアップ構成に関するOracleのベスト・プラクティス・ガイドライン。

デフォルトのバックアップ構成は、Oracleベストプラクティス・ガイドラインのセットに従います。

  • 暗号化:オブジェクト・ストレージへのすべてのバックアップが暗号化されます。
  • バックアップの圧縮: LOW
  • アーカイブ・ログのデフォルト圧縮: false
  • RMAN暗号化アルゴリズム: AES256
  • バックアップの最適化: ON

バックアップ構成ファイルを作成するには

ノート

次の手順は、Exadata Cloud Infrastructure VMクラスタの最初のコンピュート・ノードで実行する必要があります。最初のコンピュート・ノードを決定するには、任意のコンピュート・ノードにgridユーザーとして接続し、次のコマンドを実行します:
$ $ORACLE_HOME/bin/olsnodes -n

最初のノードは、番号1がノード名の横にリストされます。

  1. SSHを使用して、VMクラスタ内のデータベース構成済ノードの1つに接続します。
    ssh -i <private_key_path> opc@<node_1_ip_address>
  2. opcとしてログインし、sudorootユーザーに切り替えます。
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. dbaascli database backup --getConfigコマンドを使用して、データベース・デプロイメントの現在のバックアップ設定を含むファイルを生成します:
    # dbaascli database backup --getConfig [--configFile <file_name>] --dbname <database_name>
  4. 要件を満たすように、ファイル内のパラメータを変更します。
    ノート

    2025年8月6日以降、FRA、PHXまたはNRTリージョンで作成されたテナンシの場合、データベースで自動バックアップを有効にすると、Autonomous Recovery Serviceが唯一のバックアップ先になります。

    リカバリ・サービスを使用したOracle Cloudデータベースのバックアップおよびリカバリについて

    パラメータ 説明
    bkup_disk=[yes|no] ローカルでディスク(Fast Recovery Area)にバックアップするかどうか。
    bkup_oss=[yes|no] オブジェクト・ストレージにバックアップするかどうか。はいの場合、パラメータbkup_oss_urlbkup_oss_userbkup_oss_passwdおよびbkup_oss_recovery_windowも指定する必要があります。
    bkup_oss_url=<swift_url>

    bkup_oss=yesの場合は必須です。

    使用するテナントおよびバケットを含むオブジェクト・ストレージURL。URLは次のとおりです:

    https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<tenant>/<bucket>

    説明:

    • <tenant> - コンソールにサインインするときに指定する小文字のテナント名(大文字を含む場合も)
    • <bucket> - バックアップに使用する既存のバケットの名前。
    bkup_oss_user=<oci_user_name>

    bkup_oss=yesの場合は必須です。

    Oracle Cloud Infrastructureユーザー・アカウントのユーザー名。これは、Oracle Cloud Infrastructureコンソールへのサインインに使用するユーザー名です。

    たとえば、ローカル・ユーザーの場合はjsmith@example.com、フェデレーション・ユーザーの場合は<identity_provider>/jsmith@example.comです。

    ユーザーのタイプを判別するには、次のトピックを参照してください:

    ユーザーは、管理者グループのメンバーである必要があります。

    bkup_oss_passwd=<auth_token>

    bkup_oss=yesの場合は必須です。

    コンソールまたはIAM APIを使用して生成される認証トークン(前提条件を参照

    これは、Oracle Cloud Infrastructureユーザーのパスワードではありません。

    bkup_oss_recovery_window=n

    bkup_oss=yesの場合は必須です。

    バックアップおよびアーカイブREDOログがオブジェクト・ストレージ・バケットに保持される日数。7日から90日を指定します。

    bkup_daily_time=hh:mm 24時間形式の時間と分(hh:mm)で指定された、日次バックアップがスケジュールされる時刻。
    bkup_archlog_cron_entry=[yes|no] dbaastoolsを使用してバックアップが構成されていない場合、bkup_archlog_cron_entry=noを設定すると、crontabからアーカイブ・ログのクリーンアップ・ジョブが削除されます。デフォルト値は"yes"です。
  5. dbaascli database backup --configureを使用して、このバックアップ構成をデータベース名に関連付けます。
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  6. dbaascli database backup --statusを使用して、このコマンドに対して生成されたUUIDのステータスを確認します。
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>
    ノート

    バックアップ構成ファイルには、オブジェクト・ストレージ・バケットにアクセスするための資格証明を含めることができます。このため、バックアップを正常に構成した後で、ファイルを削除することが必要な場合があります。

次のパラメータを変更して、バックアップ構成をカスタマイズできます:

ノート

Compatible with Console Automatic Backups=Yesは、コンソールベースの自動バックアップを使用する場合でも、パラメータを安全に変更できます。Compatible with Console Automatic Backups=Noのパラメータを使用する場合は、コンソールからバックアップを有効にしないでください。

表5-5バックアップ構成パラメータ- dbaascliへのスケジュール・パラメータ

パラメータ 説明 コンソール自動バックアップとの互換性*

旧名: bkup_cron_entry

新しい名前: scheduleBackups

自動バックアップ構成を有効にします。

有効な値は、yesおよびnoです。

いいえ

旧名: bkup_archlog_cron_entry

新しい名前: manageArchivelogs

アーカイブ・データベース・ログ・ファイルの自動バックアップを有効にします。

有効な値は、yesおよびnoです。

manageArchivelogsをnoに設定すると、自動アーカイブ・ログ・クリーンアップ・ジョブが無効になります。この設定は、関連付けられたデータベースに自動データベース・バックアップが構成されていない場合にのみ有効です。

いいえ

旧名: bkup_l0_day

新しい名前: L0BackupDay

このパラメータは、レベル0の曜日を制御します。

レベル0のバックアップが取得される曜日。

有効な値は、montuewedthufrisatsunです。より長い形式のMondayTuesdayなどもサポートされています。

デフォルト: sun

いいえ

表5-6バックアップ構成パラメータ- 一般的なRMAN構成パラメータ(ローカル・ストレージ(FRA)以外のすべてのバックアップの保存先に対して有効)

パラメータ 説明 コンソール自動バックアップとの互換性*

旧名: bkup_rman_compression

新しい名前: compressionLevel

自動バックアップに適用される圧縮のレベル。

有効な値は、NONEbasiclowmediumおよびhighです。

デフォルト値はlowです。

NONEを指定すると、RMAN圧縮が無効になります。

RMAN圧縮が有効な場合、TDE暗号化データファイルは、復号化、圧縮およびRMAN暗号化されます。

はい

旧名: bkup_section_size

新しい名前: sectionSize

自動バックアップに使用されるRMANセクション・サイズ。

デフォルト値は64Gです。

はい

旧名: bkup_channels_node

新しい名前: channelsPerNode

自動バックアップに使用されるノードごとのRMANチャネルの数。

有効な値は、1から32までです。

デフォルト値は2です。

はい

旧名: bkup_daily_time

新しい名前: autoBackupTime

24時間形式で表された自動日次バックアップの開始時間(hh:mm)。

はい

旧名: bkup_archlog_frequency

新しい名前: backupFrequencyAL

アーカイブ・データベース・ログ・ファイルの自動バックアップの間隔(分)。

有効な値は、15、20、30、60、120、1440 (分単位で表された1時間間隔)です。

ExaDB-Dのデフォルト値は30です。

はい

旧名: bkup_type

新しい名前: backupDestination

バックアップが存在する場所のタイプ。OSSをバックアップの保存先として指定します。これはデフォルトであり、唯一のオプションです。

はい

旧名: bkup_filesperset_regular

新しい名前: filesPerSet

通常のバックアップ/アーカイブ・バックアップのバックアップ・セットに含めることができるデータファイルの最大数を指定します。 はい

旧名: bkup_filesperset_al

新しい名前: filesPerSetAL

アーカイブ・ログ・バックアップのバックアップ・セットに含めることができるアーカイブ・ログ・ファイルの最大数を指定します。 はい

旧名: bkup_encryption

新しい名前: encryption

暗号化では、バックアップを暗号化するかどうかを指定します。

デフォルトでは、OSSおよびリカバリ・サービスに対して暗号化が有効になっており、この設定は変更できません。

はい

旧名: rmanBackupOptimization

新しい名前: optimization

最適化は、バックアップ、転送およびリストアが必要なデータの量を減らす機能です。推奨値はONです。 はい

旧名: rmanFraCleanupChannels

新しい名前: numberOfChannelsForFraCleanup

FRAクリーンアップ・ジョブに使用されるチャネルの数を指定します。 はい

旧名: Compress_Archive_Logs

新しい名前: compressionAL

アーカイブ・ログ・バックアップを圧縮するかどうかを指定します。

リカバリ・サービスには適用されません。

はい

旧名: bkup_archlog_fra_retention

新しい名前: archivelogRetentionDays

FRAに保持されるアーカイブ・ログの日数を指定します。 はい

表5-7バックアップ構成パラメータ- オブジェクト・ストレージ・サービス(OSS)パラメータ

パラメータ 説明 コンソール自動バックアップとの互換性*
backupDestination=oss

クラウド・ストレージへのバックアップを有効にします。

有効な値は、yesおよびnoです。

いいえ

旧名: bkup_oss_recovery_window

新しい名前: ossRecoveryWindow

最大90までの日数で表される、クラウド・ストレージ上のバックアップの保持期間。

bkup_ossyesに設定されているか、backupdestinationOSSに設定されている場合にのみ適用できます

デフォルト値は30です。

いいえ

旧名: bkup_oss_url

新しい名前: ossURL

クラウド・ストレージへのバックアップに使用されるストレージ・コンテナの場所。

bkup_ossyesに設定されているか、backupdestinationOSSに設定されている場合にのみ適用できます

いいえ

旧名: bkup_oss_user

新しい名前: ossUserName

bkup_oss_urlに指定されたクラウド・ストレージ・コンテナへの書込み権限を持つOracle Cloudユーザーのユーザー名。

bkup_ossyesに設定されているか、backupdestinationOSSに設定されている場合にのみ適用できます

いいえ

旧名: bkup_oss_passwd

新しい名前: ossAuthToken

bkup_oss_urlに指定されたクラウド・ストレージ・コンテナへの書込み権限を持つOracle Cloudユーザーのパスワード。

bkup_ossyesに設定されているか、backupdestinationOSSに設定されている場合にのみ適用できます

いいえ

表5-8バックアップ構成パラメータ- RMANカタログ・サポート・パラメータ

パラメータ 説明 コンソール自動バックアップとの互換性*

旧名: bkup_use_rcat

新しい名前: useCatalog

既存のRMANリカバリ・カタログの使用を有効にします。

有効な値は、yesおよびnoです。

はい

旧名: bkup_rcat_user

新しい名前: catalogUserName

リカバリ・カタログのユーザー名。

bkup_use_rcatyesに設定されている場合にのみ適用できます。

はい

旧名: bkup_rcat_passwd

新しい名前: catalogPassword

指定したリカバリ・カタログ・ユーザーのパスワード
bkup_rcat_user
.

bkup_use_rcatyesに設定されている場合にのみ適用できます。

はい

旧名: bkup_rcat_conn

新しい名前: catalogConnectionString

RMANリカバリ・カタログの接続文字列。

bkup_use_rcatyesに設定されている場合にのみ適用できます。

はい


コンソールベースの自動バックアップと組み合せて安全に変更できるのは、Compatible with Console Automatic Backups = Yesで示されている前述のパラメータだけです。その他のパラメータを変更する場合は、コンソールからバックアップを有効にしないでください。

オンデマンド・バックアップを作成するには

dbaascliを使用して、データベースのオンデマンド・バックアップを作成できます。

  1. VMクラスタまたはDBシステム・リソース内のデータベース構成済ノードの1つにSSHを実行します。
    ssh -i <private_key_path> opc@<node_1_ip_address>

    最初のコンピュート・ノードを決定するには、任意のコンピュート・ノードにgridユーザーとして接続し、次のコマンドを実行します:

    $ $ORACLE_HOME/bin/olsnodes -n

    最初のノードは、番号1がノード名の横にリストされます。

  2. opcとしてログインし、sudorootユーザーに切り替えます。
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. バックアップが現在の保持ポリシーに従うようにすることも、削除するまで保持される長期バックアップを作成することもできます:
    • 現在の保持ポリシーに従ったバックアップを作成するには、次のコマンドを入力します:
      # dbaascli database backup --start --dbname <database_name>
    • 長期バックアップを作成するには、次のコマンドを入力します:
      # dbaascli database backup --start --archival --dbname --tag <archival_tag>
  4. rootユーザー・コマンド・シェルを終了し、コンピュート・ノードから切断します:
    # exit
    $ exit
  5. dbaascli database backup --statusを使用して、バックアップ・コマンドに対して生成されたUUIDのステータスを確認します
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

バックアップ構成を削除するには

  1. VMクラスタまたはDBシステム・リソース内のデータベース構成済ノードの1つにSSHを実行します。
  2. opcとしてログインし、sudorootユーザーに切り替えます。
  3. 次のパラメータを使用してtempファイルを作成します。
    • bkup_oss=no
    • bkup_cron_entry=no
    • bkup_archlog_cron_entry=no
  4. 前述のファイルをdbaascli database backup --configureとともに使用して、データベースのバックアップ構成を削除します。
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  5. dbaascli database backup --statusを使用して、このコマンドに対して生成されたUUIDのステータスを確認します。
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

これにより、すべての自動バックアップが無効になります。

ローカル・バックアップを削除するには

オブジェクト・ストレージのバックアップを削除するには

アーカイブまたは長期バックアップは、オブジェクト・ストレージから削除できます。

# dbaascli database backup --delete --backupTag --dbname <database_name>

説明:

  • --dbname - Oracle Database名を指定します
  • --delete - アーカイブ・バックアップを削除します。
  • --backupTag - 削除するバックアップ・タグを指定します。

ポリシー・ベースのバックアップは、スケジュールされた日次バックアップで削除されます。または、RMAN delete backupコマンドを使用して、オブジェクト・ストアからバックアップを削除できます。

APIを使用したバックアップおよびリカバリの管理

APIを使用したバックアップの管理

Exascaleインフラストラクチャ上のOracle Exadata Database Serviceでデータベース・バックアップにAPIを使用する方法について学習します。

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

次のAPI操作を使用して、データベース・バックアップを管理します:

データベース・サービスのAPIの完全なリストは、データベース・サービスAPIを参照してください。

代替バックアップ方法

OCIコンソールに加えて使用可能な代替バックアップ方法について学習します。

Exadata Cloud Infrastructure上のデータベースのバックアップは、コンソールで構成された自動バックアップに加えて、いくつかの方法を使用して実行できます。一般的に、コンソール(またはそれに対応するOCI API/CLI)は、最も簡単で最も自動化された方法を提供するため、推奨される方法です。通常は、代替の管理方法よりもOCIコンソール、OCI APIまたはOCIコマンドラインを利用することをお薦めします。ただし、推奨される方法で必要なアクションを完了できない場合、バックアップを手動で構成するために他の2つのオプション(dbaascliおよびOracle Recovery Manager (RMAN))を使用できます。

ノート

dbaascli database backupdbaascli pdb backupdbaascli database recoverおよびdbaascli pdb recoverコマンドを使用して、コンテナ・データベースとプラガブル・データベースをバックアップおよびリカバリします。詳細は、バックアップ操作およびリカバリ操作を実行するためのOracle推奨オプションユーザー構成バックアップを参照してください。

RMANは、Oracle Databaseに含まれているバックアップ・ツールです。RMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』(リリース19)を参照してください。RMANを使用してExadata Cloud Infrastructureでデータベースをバックアップすると、バックアップ・オプションに関して最も柔軟性が高くなりますが、最も複雑になります。

ノート

ここで説明した方法でバックアップされたデータベースをリストアするためのRMANの使用は安全であるとみなされますが、バックアップの設定にコンソール(およびOCI API/CLI)またはdbaascliとともに使用しないでください。RMANを利用してバックアップを手動で調整する場合は、コンソール自動バックアップもdbaascliも使用しないでください。最初に、コンソール・ベースの自動バックアップを完全に無効にする必要があります。詳細は、手動バックアップおよびリカバリ管理を容易にするための自動バックアップの無効化を参照してください。

dbaascliの方法は、柔軟性および簡易性という点で、RMANとコンソール自動バックアップの中間に位置します。dbaascliは、コンソール自動バックアップで必要な機能がサポートされていないが、RMANを直接使用する複雑性を回避する場合に使用します。特定のケースでは、dbaascliを使用してコンソール自動バックアップ構成を変更できますが、これは一般的なケースではありません。一般的には、コンソールでバックアップを有効にするのではなく、dbaascliを使用する必要があります。

手動バックアップおよびリカバリ管理を容易にするための自動バックアップの無効化

Exadata Cloud Serviceコンソール、APIまたはbkup_apiで構成されたバックアップは、様々なバックアップおよびリカバリのユースケースで動作します。

Oracle Exadata Database Service on Exascale Infrastructureコンソール、APIまたはbkup_apiで構成されたバックアップは、様々なバックアップおよびリカバリのユースケースで動作します。クラウド管理バックアップでサポートされていないユースケースが必要な場合は、Oracle Recovery Manager (RMAN)ユーティリティを使用してデータベースのバックアップおよびリカバリを手動で管理できます。RMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Exascaleインフラストラクチャ上のOracle Exadata Database ServiceでRMANを使用してバックアップおよびリカバリを管理するには、データベース・バックアップとアーカイブ・ログ・バックアップの両方の完全な所有権を取得する必要があります。クラウド管理バックアップは使用できなくなります。手動バックアップを開始する前に、クラウド管理バックアップ機能を無効にする必要があります。これは、手動バックアップの前にクラウド・バックアップ・ジョブがアーカイブ・ログをパージせず、手動バックアップと競合しないようにするために必要です。

bkup_apiユーティリティを使用して、次の手順に従うことで、自動アーカイブ・ログ・パージ・ジョブを無効にするなど、クラウド管理バックアップを無効にできます:

ノート

これらのステップを実行すると、データベースのFRAのアーカイブ・ログは、自動でパージ/バックアップされなくなります。
  1. opcユーザーとして最初のコンピュート・ノードに接続します。

    詳細な手順は、SSHを使用したコンピュート・ノードへの接続を参照してください。

  2. rootユーザー・コマンド・シェルを起動します:
    sudo -s
  3. bkup_api get configコマンドを使用して、データベース・デプロイメントの現在のバックアップ設定を含むファイルを生成します:
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    説明:
    • filenameは、生成されるファイルの名前を指定するために使用されるオプションのパラメータです
    • dbnameは、操作するデータベースのデータベース名です
  4. 生成されたファイルのパラメータ値を編集して、次のパラメータを変更します。
    これにより、バックアップのcrontabエントリが削除され、すべての自動バックアップが無効になります。値がyesに設定されている場合は、noに設定します。
    bkup_cron_entry=no
    bkup_archlog_cron_entry=no
    bkup_nfs=no
    bkup_oss=no
    bkup_local=no
  5. bkup_api set configコマンドを使用して、更新されたバックアップ設定を含むファイルを使用してバックアップ設定を更新します:
    /var/opt/oracle/bkup_api/bkup_api set config --file=filename --dbname=dbname
    説明:
    • filenameは、生成されるファイルの名前を指定するために使用されるオプションのパラメータです
    • dbnameは、操作するデータベースのデータベース名です

    構成を設定するジョブは、完了するまで数分かかります。

  6. bkup_api configure_statusコマンドを使用して、構成の更新のステータスを確認できます:
    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=dbname
    説明:
    • dbnameは、操作するデータベースのデータベース名です

    Configure backup statusは、runningとして開始し、完了時にfinishedに移行します。

  7. bkup_api get configコマンドを再度実行し、前述の設定がnoに設定されていることを確認します。
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    説明:
    • filenameは、生成されるファイルの名前を指定するために使用されるオプションのパラメータです
    • dbnameは、操作するデータベースのデータベース名です
    ノート

    これらの変更を行った後、アーカイブ・ログ・バックアップを含むバックアップは、クラウド自動化によって作成されません。アーカイブ・ログの場所がいっぱいにならないように、手動のRMANバックアップが適切に配置されることを確認してください。
    ノート

    bkup_apiコマンドを使用して行った変更は、Oracle Exadata Database Service on Exascale Infrastructureコンソールに反映されません。
  8. rootユーザー・コマンド・シェルを終了します:
    exit

Oracle Recovery Manager (RMAN)を使用したデータベースのリカバリ

bkup_apiを使用してデータベースをバックアップした場合は、Oracle Recovery Manager (RMAN)ユーティリティを使用して、そのデータベース・バックアップを手動でリストアできます。

bkup_apiを使用してデータベースをバックアップした場合は、Oracle Recovery Manager (RMAN)ユーティリティを使用して、そのデータベース・バックアップを手動でリストアできます。RMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

ノート

RMANを使用したリカバリは安全ですが、バックアップの開始やバックアップ設定の編集でbackup_apiの使用と組み合せたり、自動コンソール・バックアップと組み合せてRMANを使用しないでください。そうすると、条件の競合や設定の上書きが発生し、バックアップが正常に実行されない可能性があります。