ベース・データベース・サービスでのバックアップおよびリカバリ
データベースのバックアップは、データの安全を確保するために重要です。Oracleには、データベースをバックアップするための複数の方法が用意されています。
Oracle管理の自動バックアップ機能は、コンソールを使用してバックアップ設定を簡単に構成できるため、Oracle Cloudデータベースをバックアップするための推奨方法です。自動バックアップ機能では、リカバリ・サービスおよびオブジェクト・ストレージがバックアップの保存先としてサポートされ、同じコストで完全に自動化されたクラウド・バックアップ・ソリューションが提供されます。手動バックアップまたはバックアップ・ストレージ管理タスクを実行する必要はありません。また、バックアップをローカル・ストレージに格納することもできます。次に示す各バックアップ保存先のメリットと要件を考慮する必要があります。
リカバリ・サービス(推奨)
Oracle Databasesの最新のサイバーセキュリティ保護を提供する、オンプレミスのOracleのZero Data Loss Recovery Applianceテクノロジに基づくフルマネージド・サービスです。独自の自動機能により、Oracle Databaseの変更をリアルタイムで保護し、本番データベースのオーバーヘッドなしでバックアップを検証し、任意の時点への高速で予測可能なリカバリを実現します。
バックアップが現在Object Storageで構成されている場合、リカバリ・サービスにシームレスに移行して、同じコストで高度な機能を実現できます。
リカバリ・サービスの詳細は、Oracle Database Autonomous Recovery Serviceについてを参照してください。
ローカル記憶域
- バックアップは、DBシステムのFast Recovery Areaにローカルに格納されます。
- 耐久性: 低
- 可用性: 中
- バックアップとリカバリ率: 高
- メリット: 最適化されたバックアップおよび高速のポイントインタイム・リカバリ。
- デメリット: DBシステムが使用できなくなった場合、バックアップも使用できません。
現在、OracleではDBシステムにブロック・ストレージ・ボリュームをアタッチする機能が提供されていないため、ネットワークにアタッチされたボリュームにバックアップすることはできません。
管理対象外バックアップの場合は、RMAN
またはdbcli
を使用でき、バックアップ用に独自のオブジェクト・ストレージ・バケットを作成して管理する必要があります。
ノート:
以前にRMAN
またはdbcli
を使用してバックアップを構成したが、コンソールまたはバックアップ用のAPIの使用に切り替えた場合は、新しいバックアップ構成が作成され、データベースに関連付けられます。このため、以前に構成した管理対象外のバックアップを使用して作業することはできなくなります。
バックアップを作成する詳細な手順は、次を参照してください:
バックアップからのリカバリの詳細は、次を参照してください:
前提条件
バックアップおよびリカバリ操作について、次の前提条件が満たされていることを確認します:
リカバリ・サービス
リカバリ・サービスの前提条件の詳細は、リカバリ・サービスの構成を参照してください。
オブジェクト・ストレージ
- DBシステムは、該当するSwiftエンドポイントへの接続を含むオブジェクト・ストレージへのアクセスを必要とします。VCNでサービス・ゲートウェイを使用してこのアクセスを有効にすることをお薦めします。VCNおよびサブネットを参照してください。
- バックアップ保存先として使用する既存のオブジェクト・ストレージ・バケット。コンソールまたはオブジェクト・ストレージAPIを使用してバケットを作成できます。バケットの管理を参照してください。
- OCIによって生成された認証トークン。コンソールまたは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>
グループへのユーザーの追加の詳細は、グループの管理を参照してください。
オブジェクト・ストレージの詳細は、オブジェクト・ストレージの概要を参照してください。
一般情報
バックアップ操作を成功させるには、データベースとDBシステムが「使用可能」状態になっている必要があります。バックアップ操作の進行中は、可用性を妨げる可能性のあるアクション(パッチ適用やData Guard操作など)の実行を避けることをお薦めします。自動バックアップ操作が失敗した場合、データベース・サービスは、翌日のバックアップ・ウィンドウ中に操作を再試行します。オンデマンド完全バックアップが失敗した場合は、DBシステムおよびデータベースの可用性がリストアされたときに操作を再試行できます。
バックアップの失敗を避けるために、リストされている前提条件の他に、次の条件を満たしていることを確認してください:
- データベースのアーカイブ・モードは
ARCHIVELOG
に設定されています(デフォルト)。 - データベース・ホスト・ファイル・システムの
/u01
ディレクトリに、バックアップ・プロセスを実行するのに十分な空き領域があります。 - oracleユーザーの.bash_profileファイルに、対話型コマンド(
oraenv
や、エラーまたは警告メッセージを生成する可能性のあるコマンドなど)は含まれていません。 - (自動バックアップ用) sqlnet.oraファイルのデフォルトの
WALLET_LOCATION
エントリは変更されていません。 - 標準の
RMAN
コマンドを使用してRMAN
バックアップ設定が変更されていません。
これらのガイドラインに従わないと発生する可能性のある問題の詳細は、バックアップの失敗のトラブルシューティングを参照してください。
管理対象バックアップ機能
次の情報は、コンソールまたはAPIを使用して構成された管理対象バックアップに適用されます。
ノート:
セキュリティ・ゾーン・コンパートメント内のデータベースで自動バックアップが有効になっている必要があります。ベース・データベース・サービス・リソースに影響を与えるポリシーの完全なリストについては、セキュリティ・ゾーン・ポリシーを参照してください。現在、次の2つのタイプの自動バックアップがサポートされています:
- リカバリ・サービス: データベース用の集中管理された完全管理型のスタンドアロン・バックアップ・ソリューション。
- オブジェクト・ストレージ: データベース用のセキュアでスケーラブルなオンデマンド・ストレージ・ソリューション。
バックアップおよびリカバリ操作でSYSBACKUP管理権限を使用するというOracle推奨プラクティスに準拠するため、クラウド自動化によって、CDB$ROOTコンテナ・レベルでSYSBACKUPロールを持つC##DBLCMUSERという共通の管理ユーザーが作成されます。そのため、バックアップおよびリカバリ操作は、最小限必要な権限を持つユーザーを使用して実行されます。このユーザーの資格証明は、クラウド自動化によってランダムに生成され、安全に管理されます。ユーザーが見つからないか、LOCKEDおよびEXPIREDである場合、クラウド自動化によって、バックアップまたはリカバリ操作中にこのユーザーが再作成またはロック解除されます。
自動増分バックアップとアーカイブREDOログ・バックアップ
データベースのオブジェクト・ストレージ・バックアップ機能を有効にすると、サービスによって継続的に次のものが作成されます:
- 週次のレベル0バックアップ。通常は指定した週末に作成されます。レベル0バックアップは完全バックアップに相当します。コンソールでは、週次のレベル0バックアップは、日次のレベル1バックアップと同様に、バックアップ・タイプが「増分」のバックアップのリストに表示されます。
- 日次のレベル1バックアップ。これは、レベル0バックアップの日から6日間、毎日作成される増分バックアップです。
- レベル0およびレベル1のバックアップはオブジェクト・ストアに格納され、OCIDが割り当てられます。
- 進行中のアーカイブREDOログのバックアップ(最小頻度は60分ごと)。OCIコンソールのデータベース詳細ページの「最終バックアップ時間」フィールドに、最後のアーカイブREDOログの時間が表示されます。このバックアップは、レベル0およびレベル1の自動バックアップとは異なり、ログ・データに基づいており、OCIDが割り当てられません。最後のアーカイブREDOログのバックアップを使用して、新しいデータベースを作成したり、最小限のデータ損失でデータベースをリカバリすることができます。
バックアップの保持
自動バックアップを有効にする場合は、提供されている保持期間のいずれかまたはカスタム・ポリシーから選択できます。増分バックアップは、選択した保持期間の終わりに自動的に削除されます。
- ブロンズ(14日)
- シルバー(35日) (デフォルト)
- ゴールド(65日)
- プラチナ(95日)
- カスタム(ユーザー定義の保護ポリシー)
- 7日
- 15日
- 30日(デフォルト)
- 45日
- 60日
リカバリ・サービスを使用した長期保存バックアップ
長期保存バックアップ(LTR)を使用すると、完全なLTRライフサイクル管理と不変性により、コンプライアンス、規制、その他のビジネス・ニーズに最大10年間のフル・バックアップを保存できます。
リカバリ・サービスを使用するLTRの場合、保存期間は、バックアップが作成されてからの日数(90 - 3650)または年数(1 - 10)にする必要があります。
必要な保持期間でLTRバックアップを作成するために、Recovery Serviceでは、新しい完全本番バックアップを作成する必要はありませんが、ポリシーで定義されたリカバリ・ウィンドウ内にシステム内にすでに存在する運用バックアップを使用して作成します。詳細なステップは、データベースのオンデマンド・バックアップの作成を参照してください。
保持期間内の特定の既存のLTRバックアップの保存期間を変更できます。詳細なステップは、リカバリ・サービスを使用した長期保存バックアップの保存期間の変更を参照してください。
LTRバックアップをリストアして、保持期間内に新しいデータベースを作成できます。詳細なステップは、コンソールを使用したバックアップからのDB Systemの作成を参照してください。
- 72時間でバックアップを削除: LTRバックアップを含むすべてのバックアップが削除されます。
- ポリシーに基づいて削除: LTRバックアップは、各LTRバックアップの保存ポリシーに従って保持されます。
ノート:
Oracleでは、LTRバックアップが保持されるようにDBシステムを終了する際に、「ポリシーに基づいて削除」オプションを選択することをお薦めします。LTRバックアップには、次の追加の要因を考慮してください。
- LTRバックアップは、データベースで構成された自動バックアップとは無関係に存続します。
- LTRバックアップは、指定した保存期間の終了後に自動的に削除されます。
- インプレース・リストアはLTRではサポートされていません。
- Data Guard構成内のデータベースの場合、LTRバックアップはリクエストされたデータベースに対してのみ作成されます。
- LTRを作成するには、データベースがAVAILABLE状態である必要があります。
- LTRは、ファイルベースのTDEまたはKMSベースのキーストアを持つデータベースでサポートされています。
- すべての暗号化キーは、LTRの保持期間全体にわたって保持されます。
- LTRが「作成中」状態の場合は取り消すことができます。
- LTRバックアップは、作成後いつでも削除できます。
- リストア時に、リストアされるLTRバックアップがサポートされているDB Homeメジャー・バージョンの場合、そのバージョンの最新RUにリストアされます。
- リストア時に、リストアされるLTRバックアップがサポートされるDB Homeメジャー・バージョンではない場合、そのバックアップはサポートされているメジャー・バージョンにリストアされ、そのメジャー・バージョンでは、サポートされているメジャー・バージョンにデータベースをアップグレードする必要があります。
リストア・オプション
次のリストア・オプションがデータベースで使用できます。これはLTRではサポートされていません。
- 最新の状態にリストア: 可能なかぎりデータ損失の少ない、最後に確認された正常な状態にデータベースをリストアします。
- タイムスタンプにリストア: 指定されたタイムスタンプにデータベースをリストアします。
-
SCNにリストア: 指定されたシステム変更番号(SCN)を使用してデータベースをリストアします。このSCNは有効である必要があります。
ノート:
使用するSCN番号は、データベース・ホストにアクセスして問い合せるか、オンライン・ログまたはアーカイブ・ログにアクセスすることで確認できます。
保護ポリシー
リカバリ・サービスでは、保護ポリシーを使用してOracle Cloudでのデータベース・バックアップの保持を制御します。
保護ポリシーは、規制された環境の要件を満たす、保護されたデータベースの自動保持管理を提供します。保護された各データベースは1つの保護ポリシーに関連付ける必要があります。
保護ポリシーは、リカバリ・サービスによって作成されたバックアップを保持できる最大期間(日数)を決定します。ビジネス要件に基づいて、保護されているデータベースごとに個別のポリシーを割り当てるか、VCN内のすべての保護されているデータベースに単一のポリシーを使用できます。
詳細は、保護ポリシーの管理を参照してください。
保護対象データベース
保護されたデータベースとは、バックアップ操作にリカバリ・サービスを使用するOracle Cloudデータベースのことです。
詳細は、保護されたデータベースの管理を参照してください。
リアルタイム・データ保護
リカバリ・サービスではリアルタイムのデータ保護が提供されるため、データベース障害から数秒以内にデータベースをリカバリできます。
リアルタイム保護は、保護されたデータベースからリカバリ・サービスへのREDO変更の継続的な転送です。これにより、データ損失が少なくなり、リカバリ・ポイント目標(RPO)が0に近くなります。これは追加料金のオプションです。
詳細は、リアルタイム・データ保護を参照してください。
データベース終了後のバックアップ削除オプション
データベースを終了すると、そのすべてのリソースと自動バックアップが削除されます。リカバリ・サービスおよびオブジェクト・ストレージの宛先を使用する管理対象バックアップは、選択した保持ポリシー・オプションに従って削除されます。
次のオプションを使用して、データベースの終了後に管理対象データベースのバックアップを保持できます。これらのオプションは、データベースに偶発的または悪意のある損傷が発生した場合にバックアップからデータベースをリストアする場合にも役立ちます。
- 保持期間に従ってバックアップを保持: データベースが終了すると、終了したデータベースおよびそのすべてのリソースに関連付けられた自動データベース・バックアップは、指定した保持期間の終了時に削除されます。
- 72時間バックアップを保持した後、削除: データベースが終了すると、終了したデータベースおよびそのすべてのリソースに関連付けられた自動データベース・バックアップは72時間保持され、その後削除されます。ユーザーによる偶発的な削除から保護するために、バックアップは72時間保持されます。
バックアップ・スケジューリング
リカバリ・サービスのバックアップの場合、自動バックアップ・プロセスは、いつでも、または割り当てられたウィンドウ内で開始されます。
オブジェクト・ストレージ・バックアップの場合、レベル0およびレベル1のバックアップの作成に使用される自動バックアップ・プロセスは、日次バックアップ・ウィンドウ内(午前0時から午前6時の間)でいつでも実行できます。ユーザーは、データベースの自動バックアップ・プロセスが開始される2時間のスケジュール・ウィンドウを、オプションで指定できます。偶数時に開始される12のスケジューリング・ウィンドウから選択できます(たとえば、1つ目のウィンドウを午前4時から6時まで、その次のウィンドウを午前6時から8時までに指定できます)。スケジュール・ウィンドウ内にバックアップ・ジョブが完了するとはかぎりません
オブジェクト・ストレージ・バックアップの場合、DBシステム・リージョンのタイム・ゾーンの午前0時から午前6時までのデフォルトのバックアップ・ウィンドウがデータベースに割り当てられます(ウィンドウを指定しない場合)。デフォルトのバックアップ・スケジューリング・ウィンドウは6時間ですが、指定するウィンドウは2時間です。
バックアップをスケジュールする際は、次の要因を考慮してください。
- バックアップ・ウィンドウのタイム・ゾーン: 任意のデータベースで2018年11月20日以降に初めて有効化された自動バックアップは、DBシステムのリージョンのタイムゾーンで午前0時から午前6時までの間に実行されます。この日付より前にデータベースの自動バックアップを有効にしていた場合、データベースのバックアップ・ウィンドウは引き続きUTCの夜中の0時から午前6時までになります。選択したバックアップ・ウィンドウで自動バックアップが実行されるように、My Oracle Supportサービス・リクエストを作成できます。
- Data Guard: Data Guardアソシエーションでは、自動バックアップを構成し、プライマリ・データベースのバックアップを作成できます。ただし、自動バックアップを構成したり、スタンバイ・データベースのバックアップを作成することはできません。また、スイッチオーバー操作の後、Data Guardアソシエーションでプライマリ・ロールを引き受けたデータベースの自動バックアップを再度構成する必要があります。
- 保持期間変更: 将来、データベースの自動バックアップの保持期間を短くすると、更新された保持期間外の既存のバックアップはシステムによって削除されます。
- オブジェクト・ストレージのコスト: 自動バックアップによってオブジェクト・ストレージの使用コストが発生します。
スタンドアロン・バックアップ
DBシステムまたはデータベースを終了すると、そのすべてのリソースと自動バックアップが削除されます。宛先にリカバリ・サービスおよびオブジェクト・ストレージを使用する管理対象バックアップは、選択した保持ポリシー・オプションに従って削除されます。完全バックアップは、スタンドアロン・バックアップとしてオブジェクト・ストレージに残ります。スタンドアロン・バックアップを使用して、新しいデータベースを作成できます。
ノート:
- コンソールに表示されるバックアップのリストには、管理対象外のバックアップ(
RMAN
またはdbcli
を使用して直接作成されたバックアップ)は含まれません。 - すべてのバックアップは、Transparent Data Encryption (TDE)ウォレット暗号化に使用されるのと同じマスター・キーで暗号化されます。
実行中の完全または増分バックアップの取消
進行中のバックアップを取り消して、システム・リソースを解放できます。データベースの作成ワークフローの一部として、また(データベースの作成後に)単独で、自動バックアップを有効にし、必要なバックアップの保存先を選択できます。選択したバックアップの保存先によっては、1つ以上の完全バックアップと複数の増分バックアップがある場合があります。これらのバックアップのいずれかの開始後、途中で取り消すことができます。コンソールまたはAPIから、実行中のバックアップ(自動またはスタンドアロン)を取り消すことができます。「バックアップの作成」ボタンをクリックするとトリガーされる手動バックアップを取り消すことができます。取り消された手動バックアップを削除することもできます。
Data Guardアソシエーションのスタンバイ・データベースからのバックアップおよびリストア
Data Guardアソシエーションのスタンバイ・データベースからバックアップおよびリストアできます。この機能を使用すると、バックアップをスタンバイ・データベースにオフロードできるため、プライマリ・データベースのリソースが解放されます。
始める前に、次のことに注意してください:
- リカバリ・サービスまたはオブジェクト・ストレージを使用して、スタンバイ・データベースをバックアップできます。
- 自動バックアップをスケジュールし、スタンバイ・データベースで保存期間およびバックアップ・スケジュールを構成できます。
- データベースは、同じリージョン内の別の可用性ドメイン(AD)に作成することも、スタンバイ・データベースのバックアップとは異なるリージョンに作成することもできます。
- バックアップは、プライマリ・データベースのみ、スタンバイ・データベースのみ、またはプライマリおよびスタンバイ・データベースの両方で構成できます。ただし、構成した場合、プライマリ・データベースとスタンバイ・データベースの両方に同じバックアップ保存先が必要です。
- リカバリ・サービスのバックアップの場合、プライマリ・データベースは、スタンバイ・データベースまたはプライマリ・データベースのバックアップからリストアまたはリカバリできます。同様に、スタンバイ・データベースは、プライマリ・データベースまたはスタンバイ・データベースのバックアップからリストアまたはリカバリできます。
- オブジェクト・ストレージ内のバックアップの場合、プライマリ・データベースおよびスタンバイ・データベースは、それぞれのバックアップからのみリストアまたはリカバリできます。
- Data Guardアソシエーションのプライマリ・データベースとスタンバイ・データベースのバックアップ先は同じである必要があります。たとえば、プライマリ・データベースのバックアップ保存先がリカバリ・サービスである場合、スタンバイ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。同様に、スタンバイ・データベースのバックアップ保存先がリカバリ・サービスである場合、プライマリ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。
- バックアップの保存先は、Data Guardアソシエーションのプライマリ・データベースまたはスタンバイ・データベースでバックアップを無効にした後にのみ変更できます。たとえば、プライマリ・データベースとスタンバイ・データベースの両方のバックアップ保存先がオブジェクト・ストレージで、プライマリ・データベースのバックアップ保存先をリカバリ・サービスに変更する場合は、最初にスタンバイ・データベースのバックアップを無効にする必要があります。
- 自動バックアップがプライマリに構成されている場合、スイッチオーバー時にバックアップは新しいスタンバイ・データベースで続行されます。
- 自動バックアップがスタンバイで構成されている場合、フェイルオーバー時にバックアップは新しいプライマリ・データベースで続行され、バックアップは新しいスタンバイ・データベースで無効になります。
コンソールを使用して自動バックアップを構成する詳細なステップは、スタンバイ・データベースの自動バックアップの構成を参照してください。
クロス・リージョン・リストア
既存のバックアップを使用してリストアし、Object StorageまたはAutonomous Recovery Serviceで作成されたバックアップを使用して、同じリージョン内の複数のアベイラビリティ・ドメイン間、または別のリージョン内のデータベース(アウトオブプレース・リストア)を作成できます。
ホストベースのウォレット(ローカル・ウォレット)またはOCI Vaultを使用して構成されたデータベースで作成されたバックアップをリストアすることもできます。データベース暗号化キーの詳細は、暗号化キーの管理を参照してください。
Oracle Database Autonomous Recovery Serviceのクロス・リージョン・リストア(同じテナンシ内)には、次の前提条件が必要です。
- VCNピアリング:ローカル・リージョンとリモート・リージョンの両方のVCNをリージョン間でピアリングする必要があります。
-
ソースおよびターゲットのSCNにセキュリティ・ルールを追加します。
- ソースにイングレス・ルールを追加します。
-
「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのHTTPSトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: データベースが存在するVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 8005
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: データベースが存在するVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 2484
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのHTTPSトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: ターゲットVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 8005
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: ターゲットVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 2484
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
- ターゲットにエグレス・ルールを追加します。これらは、すべてのIPおよびポートでエグレス・トラフィックがオープンされている場合にオプションです。
-
「エグレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのHTTPSトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: ソースVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 8005
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
「エグレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するルールを設定します:
- ソース・タイプ: CIDR
- ソースCIDR: ソースVCNのCIDRを指定します。
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 2484
- 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
-
ノート:
リカバリ・サービス・サブネットがソース・リージョンに存在し、ソースVCNにアタッチされていることを確認します。詳細は、データベースVCNでのリカバリ・サービス・サブネットの作成を参照してください。 - ソースにイングレス・ルールを追加します。
- ローカルVCNとリモートVCN間で DNSピアリングを実行します。
自動バックアップを使用したデータベースの監査ファイルおよびトレース・ファイルの保持
Oracle Databaseは、監査ファイルおよびトレース・ファイルをデータベースのローカル・ストレージの/u01
ディレクトリに書き込みます。これらのファイルはデフォルトで30日間保持されますが、この間隔は変更できます。1日に1回、30日(または、該当する場合はユーザーが指定した間隔)を経過した監査ファイルおよびトレース・ファイルは、Oracle Schedulerジョブによって破棄されます。これらのファイルを永続的に保持する場合は、スケジューラ・ジョブを無効にすることもできます。このスケジューラ・ジョブを変更するには、次のdbcli
コマンドを使用します。
-
保持期間をデフォルト設定の30日から変更するには:
dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>
例:
dbcli update-database -in inventorydb -lr 15
-
古い監査ファイルおよびトレース・ファイルを破棄する日次のスケジューラ・ジョブを無効にするには:
dbcli update-schedule -i <schedulerID> -d
例:
dbcli update-schedule -i 5678 -d
APIの使用
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
データベース・バックアップを管理するには、次のAPI操作を使用します:
- ListBackups
- GetBackup
- CreateBackup
- DeleteBackup
- RestoreDatabase
- UpdateDatabase - 自動バックアップを有効および無効にします。
- CreateDbHome - スタンドアロン・バックアップからDBシステム・データベースを作成する場合。
データベース・サービスのAPIの完全なリストは、データベース・サービスAPIを参照してください。