機械翻訳について

ベース・データベース・サービスでのバックアップおよびリカバリ

データベースのバックアップは、データの安全を確保するために重要です。 Oracleには、データベースをバックアップするための複数のメソッドが用意されています。

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

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

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

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

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

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

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

オブジェクト・ストレージの詳細は、「オブジェクト・ストレージの概要」を参照してください。

Local Storage

• バックアップは、DBシステムのFast Recovery Areaにローカルに格納されます。
• 永続性: 低
• 可用性: 中
• バックアップおよびリカバリ率: 高
• 長所: バックアップの最適化と迅速なポイント・イン・タイム・リカバリ。
• 短所: DBシステムが使用できなくなった場合、バックアップも使用できません。

現在、OracleではDBシステムにブロック・ストレージ・ボリュームをアタッチする機能が提供されていないため、ネットワークにアタッチされたボリュームにバックアップすることはできません。

管理対象外バックアップの場合は、RMANまたはdbcliを使用でき、バックアップ用の独自のオブジェクト・ストレージ・バケットを作成して管理する必要があります。

ノート:

以前にRMANまたはdbcliを使用してバックアップを構成した後、コンソールまたはAPIを使用してバックアップに切り替えると、新しいバックアップ構成が作成され、データベースに関連付けられます。 このため、以前に構成された管理対象外バックアップを使用できなくなります。

バックアップを作成する詳細な手順は、次を参照してください:

• コンソールを使用したデータベースのバックアップ
• RMANを使用したオブジェクト・ストレージへのデータベースのバックアップ

バックアップからのリカバリの詳細な手順は、次を参照してください:

• コンソールを使用したデータベースのリカバリ
• RMANバックアップを使用したオブジェクト・ストレージからのデータベースのリカバリ
• OCI Classic Object Storeからのデータベースのリカバリ

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者によってポリシーでセキュリティ・アクセス権が付与されている必要があります。 コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。 権限がない、または認可されていないというメッセージが表示された場合は、アクセス権のタイプと作業するコンパートメントを管理者に確認してください。

ポリシーを初めて使用する場合は、ポリシーの開始および共通ポリシーを参照してください。

前提条件

バックアップおよびリカバリ操作について、次の前提条件が満たされていることを確認します:

リカバリ・サービス

リカバリ・サービスの前提条件の詳細は、「リカバリ・サービスの構成」を参照してください。

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

• DBシステムには、該当するSwiftエンドポイントへの接続を含むオブジェクト・ストレージへのアクセスが必要です。 Oracleでは、このアクセスを有効にするために、VCNでサービス・ゲートウェイを使用することをお薦めします。 「VCNとサブネット」を参照してください。
• バックアップの保存先として使用する既存のオブジェクト・ストレージ・バケット。 コンソールまたはObject Storage APIを使用してバケットを作成できます。 「バケットの管理」を参照してください。
• OCIによって生成された認証トークン。 コンソールまたはIAM APIを使用してパスワードを生成できます。 「ユーザー資格証明の管理」を参照してください。

• バックアップ構成ファイルで指定されるユーザー名には、オブジェクト・ストレージへのテナンシ・レベルのアクセス権が必要です。 これを行う簡単な方法は、ユーザー名をAdministratorsグループに追加することです。 ただし、これにより、すべてのクラウド・サービスに対するアクセスが許可されます。 かわりに、管理者は、次のようなポリシーを作成し、データベースのバックアップおよびリストアに必要なオブジェクト・ストレージのリソースにのみアクセスを制限する必要があります:

  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システムが「使用可能」状態である必要があります。 Oracleでは、バックアップ操作の進行中に可用性(パッチ適用や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ログ・バックアップ

データベースに対してObject Storageバックアップ機能を有効にすると、サービスによって継続的に次のものが作成されます:

• 週次レベル0のバックアップ。通常は指定した週末に作成されます。 レベル0のバックアップは、完全バックアップと同等です。 コンソールでは、日次レベル1のバックアップと同様に、バックアップ・タイプが「増分」のバックアップのリストに、週次レベル0のバックアップが表示されることに注意してください。
• 日次レベル1のバックアップ。レベル0のバックアップ日から6日間、毎日作成される増分バックアップです。
• レベル0およびレベル1のバックアップはオブジェクト・ストアに格納され、OCIDが割り当てられます。
• 進行中のアーカイブREDOログ・バックアップ(最小頻度は60分ごと)。 OCIコンソールのデータベース詳細ページの「最終バックアップ時間」フィールドには、最後のアーカイブREDOログの時間が表示されます。 このバックアップは、ログ・データに基づいており、OCIDが割り当てられていないという点で、レベル0およびレベル1の自動バックアップとは異なります。 最後のアーカイブREDOログ・バックアップを使用すると、新しいデータベースを作成したり、データ損失を最小限に抑えてデータベースをリカバリできます。

バックアップ保持

自動バックアップを有効にする場合は、指定された保存期間のいずれかまたはカスタム・ポリシーから選択できます。 増分バックアップは、選択した保持期間の最後に自動的に削除されます。

「リカバリ・サービス」には、次の保存期間を使用できます。 保存期間(日数)は、リカバリ・サービスの保護ポリシーで定義されます。

• ブロンズ(14日)
• シルバー(35日) (デフォルト)
• ゴールド(65日)
• プラチナ(95日)
• カスタム(ユーザー定義の保護ポリシー)

「オブジェクト・ストレージ」には、次の保存期間を使用できます。

• 7 days
• 15 days
• 30日 (デフォルト)
• 45 days
• 60 days

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

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

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

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

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

LTRバックアップをリストアして、保持期間内に新しいデータベースを作成できます。 詳細なステップは、「コンソールを使用したバックアップからのDB Systemの作成」を参照してください。

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

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

ノート:

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

LTRバックアップには、次の追加のファクタを考慮してください:

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

復元オプション

次のリストア・オプションがデータベースで使用可能です。 これはLTRではサポートされていません。

• 最新にリストア: データ損失の可能性が最も低い最新の正常な状態にデータベースをリストアします。
• タイムスタンプに戻す: 指定したタイムスタンプにデータベースをリストアします。

• SCNにリストア: 指定されたシステム変更番号(SCN)を使用してデータベースをリストアします。 このSCNは有効である必要があります。

  ノート:

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

保護ポリシー

Recovery Serviceでは、保護ポリシーを使用して、Oracle Cloudのデータベース・バックアップ保存を制御します。

保護ポリシーは、規制された環境の要件を満たす、保護されたデータベースの自動保存管理を提供します。 各保護されたデータベースは、1つの保護ポリシーに関連付ける必要があります。

保護ポリシーは、リカバリ・サービスによって作成されたバックアップを保持できる最大期間(日数)を決定します。 ビジネス要件に基づいて、保護されているデータベースごとに個別のポリシーを割り当てるか、VCN内のすべての保護されているデータベースに対して単一のポリシーを使用できます。

詳細は、「保護ポリシーの管理」を参照してください。

保護されたデータベース

保護されたデータベースは、バックアップ操作にリカバリ・サービスを使用するOracle Cloudデータベースを参照します。

詳細は、「保護されたデータベースの管理」を参照してください。

リアルタイムのデータ保護

Recovery Serviceではリアルタイムのデータ保護が提供されるため、データベース障害の数秒未満でデータベースをリカバリできます。

リアルタイム保護は、保護されたデータベースから「リカバリ・サービス」へのREDO変更の継続的な転送です。 これにより、データ損失が減少し、リカバリ・ポイント目標(RPO)が0近くになります。 これは追加料金オプションです。

詳細は、「リアルタイムのデータ保護」を参照してください。

データベース終了後のバックアップ削除オプション

データベースを終了すると、そのすべてのリソースと自動バックアップが削除されます。 「リカバリ・サービス」および「オブジェクト・ストレージ」宛先を使用した管理対象バックアップは、選択した保存ポリシー・オプションに従って削除されます。

次のオプションを使用すると、データベースの終了後に管理対象データベースのバックアップを保持できます。 これらのオプションは、データベースに偶発的または悪意のある障害が発生した場合にバックアップからデータベースをリストアする場合にも役立ちます。

• 保存期間に従ってバックアップを保持: データベースが終了すると、終了したデータベースとそのすべてのリソースに関連付けられた自動データベース・バックアップは、指定された保存期間の終了時に削除されます。
• バックアップを72時間保持してから削除: データベースが終了すると、終了したデータベースとそのすべてのリソースに関連付けられた自動データベース・バックアップが72時間保持され、その後削除されます。 ユーザーによる偶発的な削除から保護するために、バックアップは72時間保持されます。

バックアップ・スケジューリング

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

Object Storageバックアップの場合、レベル0およびレベル1のバックアップの作成に使用される自動バックアップ・プロセスは、日次バックアップ・ウィンドウ(午前0時から午前6時まで)内でいつでも実行できます。 オプションで、自動バックアップ・プロセスが開始されるデータベースに対して2時間のスケジュール・ウィンドウを指定できます。 12のスケジュール・ウィンドウから選択でき、それぞれ偶数時に開始します(たとえば、1つのウィンドウは午前4:00から6:00まで実行され、次のウィンドウは午前6:00から8:00まで実行されます)。 バックアップ・ジョブは、必ずしもスケジュール・ウィンドウ内に完了するわけではありません

Object Storageバックアップの場合、ウィンドウを指定しない場合、DBシステムのリージョンのタイム・ゾーンの00:00から06:00のデフォルト・バックアップ・ウィンドウがデータベースに割り当てられます。 デフォルトのバックアップのスケジュール・ウィンドウは6時間で、指定したウィンドウは2時間であることに注意してください。

バックアップをスケジュールする際は、次のファクタを考慮してください。

• バックアップ・ウィンドウのタイム・ゾーン : 任意のデータベースで、2018年11月20日より後に初めて有効にされた自動バックアップは、DBシステムのリージョンのタイム・ゾーンにおける午前0時から午前6時の間に実行されます。 この日付より前にデータベースで自動バックアップを有効にした場合、データベースのバックアップ・ウィンドウは午前0時から午前6時UTCまで継続されます。 My Oracle Supportサービス・リクエストを作成して、選択したバックアップ・ウィンドウで自動バックアップを実行できます。
• Data Guard: Data Guard関連付けでは、自動バックアップを構成し、プライマリ・データベースのバックアップを作成できます。 ただし、自動バックアップを構成したり、スタンバイ・データベースのバックアップを作成することはできません。 また、スイッチオーバー操作の後、Data Guard関連付けでプライマリ・ロールを引き受けたデータベースの自動バックアップを再度構成する必要があります。
• 保持期間の変更: 将来、データベースの自動バックアップ保持期間を短縮すると、更新された保持期間外にある既存のバックアップはシステムによって削除されます。
• Object Storageのコスト: 自動バックアップでは、オブジェクト・ストレージの使用コストがかかります。

オンデマンド完全バックアップ

データベースがData Guard関連付けのスタンバイ・ロールを想定していないかぎり、いつでもデータベースの完全バックアップを作成できます。

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

DBシステムまたはデータベースを終了すると、そのすべてのリソースが自動バックアップとともに削除されます。 リカバリ・サービスおよびオブジェクト・ストレージの宛先を使用する管理対象バックアップは、選択した保持ポリシー・オプションに従って削除されます。 完全バックアップは、スタンドアロン・バックアップとしてObject Storageに残ります。 スタンドアロン・バックアップを使用して新規データベースを作成できます。

ノート:

• コンソールに表示されるバックアップのリストには、管理対象外のバックアップ(RMANまたはdbcliを使用して直接作成されたバックアップ)は含まれません。
• すべてのバックアップは、透過的データ暗号化(TDE)ウォレット暗号化に使用される同じマスター・キーで暗号化されます。

実行中の全体バックアップまたは増分バックアップの取消し

進行中のバックアップを取り消して、システム・リソースを解放できます。 データベースの作成ワークフローの一部として、(データベースの作成後に)独立して、自動バックアップを有効にし、必要なバックアップの保存先を選択できます。 選択したバックアップの保存先によっては、1つ以上の完全バックアップと複数の増分バックアップがある場合があります。 これらのバックアップのいずれかが開始されると、途中で取り消すオプションがあります。 コンソールまたはAPIから、実行中のバックアップ(自動またはスタンドアロン)を取り消すことができます。 Create backupボタンをクリックするとトリガーされる手動バックアップを取消できます。 取り消された手動バックアップを削除することもできます。

Data Guard関連付けのスタンバイ・データベースからのバックアップおよびリストア

Data Guard関連付けのスタンバイ・データベースからバックアップおよびリストアできます。 この機能を使用すると、バックアップをスタンバイ・データベースにオフロードできるため、プライマリ・データベースのリソースが解放されます。

開始する前に、次の点に注意してください。

• リカバリ・サービスまたはオブジェクト・ストレージを使用して、スタンバイ・データベースをバックアップできます。
• 自動バックアップをスケジュールし、スタンバイ・データベースで保存期間およびバックアップ・スケジュールを構成できます。
• データベースは、同じリージョン内の別の可用性ドメイン(AD)に作成することも、スタンバイ・データベースのバックアップとは別のリージョンに作成することもできます。
• バックアップは、プライマリ・データベースのみ、スタンバイ・データベースのみ、またはプライマリ・データベースとスタンバイ・データベースの両方で構成できます。 ただし、構成した場合、プライマリ・データベースとスタンバイ・データベースの両方に同じバックアップ保存先が必要です。
• リカバリ・サービスのバックアップの場合、プライマリ・データベースは、スタンバイ・データベースまたはプライマリ・データベースのバックアップからリストアまたはリカバリできます。 同様に、スタンバイ・データベースは、プライマリ・データベースまたはスタンバイ・データベースのバックアップからリストアまたはリカバリできます。
• オブジェクト・ストレージ内のバックアップの場合、プライマリ・データベースおよびスタンバイ・データベースは、それぞれのバックアップからのみリストアまたはリカバリできます。
• Data Guard関連付けのプライマリ・データベースとスタンバイ・データベースのバックアップ先は同じである必要があります。 たとえば、プライマリ・データベースのバックアップ保存先がリカバリ・サービスである場合、スタンバイ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。 同様に、スタンバイ・データベースのバックアップ保存先がリカバリ・サービスである場合、プライマリ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。
• バックアップの保存先は、Data Guard関連付けのプライマリ・データベースまたはスタンバイ・データベースでバックアップを無効にした後にのみ変更できます。 たとえば、プライマリ・データベースとスタンバイ・データベースの両方のバックアップ保存先がオブジェクト・ストレージで、プライマリ・データベースのバックアップ保存先をリカバリ・サービスに変更する場合は、まずスタンバイ・データベースのバックアップを無効にする必要があります。
• 自動バックアップがプライマリに構成されていた場合、スイッチオーバー時に、バックアップは新しいスタンバイ・データベースで続行されます。
• 自動バックアップがスタンバイで構成されている場合、フェイルオーバー時にバックアップは新しいプライマリ・データベースで続行され、バックアップは新しいスタンバイ・データベースで無効になります。

コンソールを使用して自動バックアップを構成する詳細なステップは、「スタンバイ・データベースの自動バックアップの構成」を参照してください。

クロス・リージョン・リストア

既存のバックアップを使用してリストアし、Object StorageまたはAutonomous Recovery Serviceで作成されたバックアップを使用して、同じリージョンまたは別のリージョン内の可用性ドメイン間でデータベース(アウト・オブ・プレース・リストア)を作成できます。

ホスト・ベースのウォレット(ローカル・ウォレット)またはOCI Vaultを使用して構成されたデータベースに対して作成されたバックアップをリストアすることもできます。 データベース暗号化キーの詳細は、「暗号化キーの管理」を参照してください。

Oracle Database Autonomous Recovery Serviceのクロス・リージョン・リストア(同じテナンシ内)には、次の前提条件が必要です。

1. VCNピアリング: ローカル・リージョンとリモート・リージョンの両方のVCNは、リージョン間でピアリングする必要があります。

2. ソースおよびターゲットのVCNにセキュリティ・ルールを追加します。

   1. ソースにイングレス・ルールを追加します。

      1. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、どこからでもHTTPSトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 8005
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

      2. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 2484
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

      3. 「Add Ingress Rule」をクリックし、次の詳細を追加して、どこからでもHTTPSトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: ターゲットVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 8005
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

      4. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: ターゲットVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 2484
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。
   2. ターゲットにエグレス・ルールを追加します。 これらは、すべてのIPおよびポートに対してエグレス・トラフィックが開いている場合はオプションです。

      1. 「エグレス・ルールの追加」をクリックし、次の詳細を追加して、どこからでもHTTPSトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: ソースVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 8005
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

      2. 「エグレス・ルールの追加」をクリックし、次の詳細を追加して、どこからでもSQLNetトラフィックを許可するルールを設定します:

         • ソース・タイプ: CIDR
         • ソースCIDR: ソースVCNのCIDRを指定します。
         • IPプロトコル: TCP
         • ソース・ポート範囲: All
         • 宛先ポート範囲: 2484
         • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

   ノート:

   リカバリ・サービス・サブネットがソース・リージョンに存在し、ソースVCNにアタッチされていることを確認します。 詳細は、「データベースVCNでのリカバリ・サービス・サブネットの作成」を参照してください。
3. ローカルとリモートの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」を参照してください。

---

タイトルおよび著作権情報

Copyright ©2023,2025,

Oracle and/or its affiliates.