機械翻訳について
  1. Oracle Exadata Database Service on Cloud@Customer管理者ガイド
  2. Exadata Cloud@Customer上のAutonomous Database
  3. Exadata Cloud@CustomerでのAutonomous Data GuardとAutonomous Databaseの使用

Exadata Cloud@CustomerでのAutonomous Data GuardとAutonomous Databaseの使用

データベース間のData Guard関連付けを有効にする方法、スイッチオーバーまたはフェイルオーバー操作を使用してData Guard関連付け内のデータベースのロールを変更する方法、および障害が発生したデータベースを回復する方法について説明します。

親トピック: Exadata Cloud@Customer上のAutonomous Database

Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Data Guardを有効にすると、プライマリおよびスタンバイ・データベースに対して個別のData Guard関連付けが作成されます。

ノート:

データのレプリケーションは、クライアント・ネットワークを介してのみ行われます。

関連トピック

親トピック: Exadata Cloud@CustomerでのAutonomous Data GuardとAutonomous Databaseの使用

Autonomous Data Guard対応Autonomous Container Databaseの作成

Oracle Exadata Cloud@CustomerシステムでAutonomous Data Guard対応Autonomous Container Databaseを作成するには、次のステップに従います。

ノート:

基礎となるSGA/メモリー・リソースの管理および共有を改善するために、Oracleでは、インメモリー用に構成されているすべてのAutonomous Databasesを同じAutonomous Container Databaseにすることをお薦めします。

最小リソース要件

Autonomous Container Databaseを1つ作成するには、少なくとも次が必要です:

  • 2 OCPUまたは8 ECPU
  • 50 GBローカル・ストレージ
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. 「Autonomous Container Databaseを作成」をクリックします。
    Autonomous Container Databaseの作成ページが表示されます。
  4. 次の基本情報を指定します:
    • コンパートメント: 自律型コンテナ・データベースを作成するコンパートメントを選択します。
    • 表示名: 自律型コンテナ・データベースの識別に役立つわかりやすい説明またはその他の情報を入力します。 表示名は一意である必要はありません。 機密情報の入力は避けてください。
  5. 自律型コンテナ・データベースの作成に使用するAutonomous Exadata VMクラスタを選択します。

    ノート:

    選択したAutonomous Exadata VMクラスタに、ノード当たり2つの使用可能なOCPUまたは8つの使用可能なECPU (Autonomous Container Databaseを作成するための最小要件)がない場合、このフィールドはグレー表示されます。 自律型コンテナ・データベースを作成するのに十分なリソースがあるAutonomous Exadata VMクラスタを選択します。

  6. コンテナDBソフトウェア・バージョンの選択
    • ベース・イメージからバージョンを選択: Oracle Databaseバージョンが選択されたデータベースを作成します。
      • ベース・イメージの選択: デフォルトでは、最新バージョンが選択されています。 必要に応じて、データベース・バージョン(N、N-1)を選択します。
  7. 「Autonomous Data Guardの構成」で、「Autonomous Data Guardの有効化」チェック・ボックスを選択し、次の詳細を指定します。
    • ピアAutonomous Container Databaseコンパートメント: スタンバイ自律型コンテナ・データベースが作成されるコンパートメントを選択します。
    • 表示名: 自律型コンテナ・データベースの識別に役立つわかりやすい説明またはその他の情報を入力します。 表示名は一意である必要はありません。 機密情報の入力は避けてください。
    • ピアAutonomous Exadata VMクラスタの選択 : スタンバイに次の値を指定します:
      • ピア・リージョン: ピア・リージョンを選択します。
      • ピアExadata: スタンバイ・データベースが作成されるExadata Cloud@Customerインフラストラクチャを選択します。 CHANGE COMPARTMENTハイパーリンクをクリックしてコンパートメントを選択します。
      • ピアAutonomous Exadata VMクラスタ: スタンバイACDを作成する必要があるAutonomous VMクラスタを選択します。 CHANGE COMPARTMENTハイパーリンクをクリックしてコンパートメントを選択します。

        プライマリおよびスタンバイのAutonomous Container Databasesは、同じExadataインフラストラクチャまたは異なるExadataインフラストラクチャ上の2つの異なるAutonomous VMクラスタ上に存在する必要があります。

        ノート:

        選択したAutonomous Exadata VMクラスタに、ノード当たり2つの使用可能なOCPUがない場合(Autonomous Container Databaseの作成の最小要件)、このフィールドはグレー表示されます。 Autonomous Container Databaseを作成するための十分なリソースがあるAutonomous Exadata VMクラスタを選択します。
    • データ保護モード: このData Guard関連付けに使用される保護モードを指定します。
      • 最大パフォーマンス: プライマリ・データベースの可用性を損なうことなく可能な最高レベルのデータ保護を提供します。
      • 最大可用性: プライマリ・データベースのパフォーマンスに影響を与えずに可能な最高レベルのデータ保護を提供します。 これはデフォルトの保護モードです。

        「Oracle Data Guardの保護モード」の詳細は、「Oracle Data Guardコンセプトと管理」を参照してください。

    • 自動フェイルオーバーの有効化: 自動フェイルオーバーを有効にしてFSFOラグ制限を設定するには、このチェック・ボックスを選択します。

      ファスト・スタート・フェイルオーバー(FSFO)ラグの制限: ファスト・スタート・フェイルオーバー(FSFO)のラグ制限を1単位で設定します。 最小: 5および最大: 3600秒。 デフォルト: 30 seconds.

      ノート:

      FSFOラグ制限は、最大パフォーマンス保護モードにのみ適用できます。
  8. オプションで、自動メンテナンス・スケジュールを構成できます。
    1. 「メンテナンス作業環境の編集」をクリックします。
    2. コンテナ・データベース・メンテナンス・バージョンの構成
      • 次のリリース更新(RU): 次のメンテナンス・サイクルで次のリリース更新に更新します。
      • 最新リリース更新(RU): 次のメンテナンス・サイクルで最新のリリース更新に更新します。

      詳細は、「管理操作」を参照してください。

    3. メンテナンス・スケジュールを構成するには、「スケジュールの指定」を選択します。

      自律型コンテナ・データベース・メンテナンスの優先する月、週、平日および開始時間を選択します。

      • 「該当月の週」で、メンテナンスを実行する月の週を指定します。 週は月の1日目、8日目、15日目、22日目から始まり、期間は7日です。 週は、曜日ではなくカレンダの日付に基づいて開始および終了します。 28日を超える月の5週目のメンテナンスはスケジュールできません。
      • 「曜日」で、メンテナンスを実行する曜日を指定します。
      • 「開始時間」で、メンテナンス実行を開始する時間を指定します。
    4. 「変更の保存」をクリックします。
  9. 自動バックアップの有効化

    デフォルトでは、自動バックアップはACDに対して有効です。 オプションで、「自動バックアップの有効化」チェック・ボックスの選択を解除することで、これらを無効にすることを選択できます。

    Autonomous Data GuardでACDをプロビジョニングしている間は、自動バックアップを無効にできません。

    ノート:

    ACDに対して無効になっている場合、「Autonomous Container Databaseバックアップ設定の編集」で説明されているステップに従って、Oracle Cloud Infrastructure (OCI)コンソールからいつでも自動バックアップを有効にできます。 ただし、一度有効にすると、ACDの自動バックアップを無効にできません。

    自動バックアップの有効化がなんらかの理由で失敗した場合、ACDプロビジョニングもエラー・メッセージで失敗します。 回避策として、自動バックアップを無効にしてACDをプロビジョニングし、後で「ACDの詳細」ページから有効にできます。

  10. バックアップ先タイプを選択します:

    ノート:

    バックアップ保存先タイプは、ACDで自動バックアップを有効にしている場合にのみ設定でき、後で変更できません。
    次のオプションから選択可能です。
    • オブジェクト・ストレージ: Oracle Cloud InfrastructureのOracle管理オブジェクト・ストレージ・コンテナにバックアップを格納します。

      タイプとして「オブジェクト・ストレージ」を選択した場合は、オプションで、ストレージ・コンテナへの接続時に使用するインターネットHTTPプロキシを指定できます。 Oracleでは、セキュリティを強化するために、可能な場合はプロキシを使用することをお薦めします。

    • ネットワーク・ファイル・システム(NFS): バックアップをネットワーク・ファイル・システム(NFS)ストレージの場所に格納します。

      タイプとして「ネットワーク・ファイル・システム(NFS)」を選択した場合は、ネットワーク・ファイル・システム(NFS)ストレージを使用する、以前に定義したバックアップ保存先を選択します。

    • リカバリ・アプライアンス: Oracle Zero Data Loss Recovery Applianceを使用する、以前に定義したバックアップ保存先の1つにバックアップを格納します。

      タイプとして「リカバリ・アプライアンス」を選択した場合は、Oracle Zero Data Loss Recovery Appliance、Autonomous Container DatabaseのDB_UNIQUE_NAMEおよびVPCユーザー名パスワードを使用する、以前に定義したバックアップ保存先を選択します。

      リカバリ・アプライアンスに接続する接続文字列を、Oracleの簡易接続文字列形式(<host>:<port>/<service name>)で指定します。<host>は、Zero Data Loss Recovery ApplianceのSCANホスト名です。

  11. 次の拡張オプションを使用できます:
    • バックアップ保存期間: ニーズを満たすバックアップ保持期間値を指定します。 7日から95日のいずれかの値を選択できます。

      オブジェクト・ストレージおよびネットワーク・ファイル・システム(NFS)のバックアップ保存先タイプの場合、バックアップ保存ポリシーの値はデフォルトで30日になります。

      リカバリ・アプライアンスのバックアップ保存先タイプの場合、この値はリカバリ・アプライアンス保護ポリシーによって制御されます。

      バックアップの保存期間が経過すると、すべてのバックアップが自動的に削除されます。

    • 暗号化キー: Oracle管理キーを使用した暗号化または顧客管理キーを使用した暗号化の暗号化オプションを選択します。 デフォルトのオプションは、Oracle管理キーです。

      顧客管理キーを使用するには、「顧客管理キーを使用した暗号化」オプションを選択し、キー・ストアを作成したコンパートメントを選択して、キー・ストアを選択します。 CDB作成の一環として、Oracle Key Vault (OKV)のCDBに新しいウォレットが作成されます。 また、CDBのTDEマスター・キーが生成され、OKVのウォレットに追加されます。

      ノート:

      • Autonomous Container DatabasesおよびAutonomous Databasesでは、256ビットのハードウェア・セキュリティ・モジュール(HSM) Vaultキーのみがサポートされます。
      • 再起動後のOKVキー暗号化の検証: OKV TDEマスター・キーは、ACDを起動または再起動するたびに検証されます。 キーが検証されていない場合、起動または再起動は失敗します。 作業リクエストおよびライフ・サイクルの状態は、失敗の理由を示します。
      • データベース・リストア後のOKVキーの表示: CDBをリストアすると、そのバックアップに関連付けられているマスター・キーもリストアされます。
      • ウォレット名を取得するためのCDBバックアップの有効化: CDBは、バックアップに関連付けられたウォレットに関する情報をバックアップします。
      • CDB削除時のOKVウォレットまたはTDEマスター・キー: CDBを削除すると、ウォレットおよびTDEマスター・キーはOKVに残り、削除されません。
    • 管理: ドロップダウン・リストから文字セットおよび国別文字を選択します。
    • データベース・インメモリー:
      • データベース・インメモリーの有効化: インメモリーを有効にするには、少なくとも4つのOCPUと、システム・グローバル領域(SGA)の割合が必要です。 インメモリーを有効にする場合は、IM列ストアに割り当てるSGAの割合を選択します。 大量のメモリーが割り当てられている場合、または無効になっている場合、インメモリーは自律型データベースのパフォーマンスに影響する可能性があります。

        ノート:

        Data Guardが有効なプライマリ・データベースでインメモリーを有効にした場合、構成は読取り専用としてスタンバイ・データベースにレプリケートされます。

    • タグ: オプションで、タグを適用できます。 リソースを作成する権限がある場合は、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用するかどうか不明な場合は、このオプションをスキップする(タグを後から適用できます)か、管理者に問い合せてください。 機密情報の入力は避けてください。

      テナンシには、ほとんどのリソースに適用される標準タグのライブラリが付属しています。 これらのタグは現在、ガバナンス管理者がデプロイできるタグ・ネームスペースのセットとして使用可能です。 OCIのベスト・プラクティスでは、これらのタグをすべてのリソースに適用することをお薦めします。 OCIサービス自動化では、レポートとガバナンスの他に、標準のタグ値に基づいてワークロード固有の最適化を提供できます。

      たとえば、PeopleSoftアプリケーションのデータベース・デプロイメントには特定の構成が必要です。 Autonomous Databaseのデプロイ中にOracle-ApplicationNameタグ・ネームスペースに適切なアプリケーション・タグ・キーを設定すると、データベースが特定のアプリケーションに対して構成され、準備が整っていることを確認できます(例: PeopleSoft)。

      詳細は、「Oracle Exadata Database Service on Cloud@Customerリソースのタグ付け」を参照してください。

  12. 「Autonomous Container Databaseを作成」をクリックします。

関連トピック

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なプライマリまたはスタンバイAutonomous Container Databaseの詳細の表示

Oracle Exadata Database Service on Cloud@CustomerシステムのプライマリまたはスタンバイAutonomous Container Databaseに関する詳細情報を表示するには、次のステップに従います。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、詳細を表示するデータベースの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページで、Autonomous Data Guardの関連付けステータスおよびピア・データベースの状態を確認します。
  5. プライマリ・データベースの保護モードおよびファスト・スタート・フェイルオーバー(FSFO)のラグ制限を変更するには、「その他のアクション」ドロップダウン・リストから「Autonomous Data Guardの更新」を選択します。
    1. 表示される「Autonomous Data Guardの更新」ダイアログで、変更を行い、「変更内容を保存」をクリックします。
  6. 「リソース」で、Autonomous Data Guardをクリックして関連付けの詳細を表示します。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Autonomous Container Databaseバックアップ設定の編集

Autonomous Container Database (ACD)のプロビジョニング中に自動バックアップが無効になった場合は、後でOracle Cloud Infrastructure (OCI)コンソールから有効にできます。

  1. バックアップ設定を変更するAutonomous Container Databaseの「詳細」ページに移動します。
  2. 「その他のアクション」の下で、「バックアップ設定の編集」をクリックします。

    ノート:

    Autonomous Container Databaseの「情報」タブの「バックアップ」セクションにある「編集」リンクをクリックして、バックアップ設定を編集することもできます。

    「バックアップ設定の編集」ダイアログが開きます。

  3. このACDで自動バックアップが無効になっている場合は、自動バックアップの有効化チェック・ボックスを選択して有効にし、次の設定に適切な値を選択します:
    • バックアップの保存先タイプ: バックアップの保存先タイプを選択し、選択したタイプに基づいてオプションを指定します。

      ノート:

      バックアップ保存先タイプは、ACDで自動バックアップを有効にしている場合にのみ設定でき、後で変更できません。
      次のオプションから選択可能です。
      • オブジェクト・ストレージ: Oracle Cloud InfrastructureのOracle管理オブジェクト・ストレージ・コンテナにバックアップを格納します。

        タイプとして「オブジェクト・ストレージ」を選択した場合は、オプションで、ストレージ・コンテナへの接続時に使用するインターネットHTTPプロキシを指定できます。 Oracleでは、セキュリティを強化するために、可能な場合はプロキシを使用することをお薦めします。

      • ネットワーク・ファイル・システム(NFS): バックアップをネットワーク・ファイル・システム(NFS)ストレージの場所に格納します。

        タイプとして「ネットワーク・ファイル・システム(NFS)」を選択した場合は、ネットワーク・ファイル・システム(NFS)ストレージを使用する、以前に定義したバックアップ保存先を選択します。

      • リカバリ・アプライアンス: Oracle Zero Data Loss Recovery Applianceを使用する、以前に定義したバックアップ保存先の1つにバックアップを格納します。

        タイプとして「リカバリ・アプライアンス」を選択した場合は、Oracle Zero Data Loss Recovery Appliance、Autonomous Container DatabaseのDB_UNIQUE_NAMEおよびVPCユーザー名パスワードを使用する、以前に定義したバックアップ保存先を選択します。

        リカバリ・アプライアンスに接続する接続文字列を、Oracleの簡易接続文字列形式(<host>:<port>/<service name>)で指定します。<host>は、Zero Data Loss Recovery ApplianceのSCANホスト名です。

    • バックアップ保存期間(日数): ニーズを満たすバックアップ保持期間値を指定します。 7日から95日のいずれかの値を選択できます。

      オブジェクト・ストレージおよびネットワーク・ファイル・システム(NFS)のバックアップ保存先タイプの場合、バックアップ保存ポリシーの値はデフォルトで30日になります。

      リカバリ・アプライアンスのバックアップ保存先タイプの場合、この値はリカバリ・アプライアンス保護ポリシーによって制御されます。

      バックアップの保存期間が経過すると、すべてのバックアップが自動的に削除されます。

  4. 「変更の保存」をクリックします。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

フィジカル・スタンバイACDからスナップショット・スタンバイACDへの変換

スナップショット・スタンバイ・データベースは、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換することによって作成される、完全に更新可能なスタンバイ・データベースです。

スナップショット・スタンバイ・データベースは、プライマリ・データベースから受信したREDOデータを受信してアーカイブします。 ただし、プライマリ・データベースから受信したREDOデータは適用されません。 REDOデータは、スナップショット・スタンバイ・データベースに対するすべてのローカル更新を破棄した後、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻すときに適用されます。 変換が完了すると、スタンバイACDのロールがSNAPSHOT_STANDBYに変更されます。 SNAPSHOT_STANDBY ACDのすべてのADBでDDLおよびDML操作を実行できます。

ノート:

  • スナップショット・スタンバイは、7日後にフィジカル・スタンバイに自動的に変換されます。
  • 自動バックアップはスナップショット・スタンバイでは作成されません。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、対象のフィジカル・スタンバイ・データベースの表示名をクリックします。

    Autonomous Container Database詳細ページが表示されます。

  4. 「その他のアクション」ドロップダウン・リストから「スナップショット・スタンバイに変換」を選択します。

    ノート:

    自動フェイルオーバーが有効になっている場合は、フィジカル・スタンバイをスナップショット・スタンバイに変換できません。 自動フェイルオーバーを無効にして、スタンバイ・データベースをスナップショット・スタンバイ・モードに変換します。

  5. 自動フェイルオーバーを無効にするには、次を実行します:
    1. 「リソース」の下で、Autonomous Data Guardをクリックします。
    2. ピア(プライマリ)データベースの名前をクリックします。

      プライマリACD詳細ページが表示されます。

    3. 「その他のアクション」ドロップダウン・リストから「Autonomous Data Guardの更新」を選択します。
    4. 結果の「Autonomous Data Guardの更新」ダイアログで、「自動フェイルオーバーの有効化」チェック・ボックスの選択を解除します。
    5. 「変更の保存」をクリックします。
  6. 自動フェイルオーバーを無効にした後、フィジカル・スタンバイからスナップショット・スタンバイへの変換を続行します。

    スナップショット・スタンバイに変換ウィンドウで警告メッセージを確認します。

    スナップショット・スタンバイへの変換では、次の2つのオプションがサポートされています:

    • 新規データベース・サービスの使用: スナップショット・スタンバイ・モードでのみアクティブな新しいサービスを使用して、スナップショット・スタンバイ・データベースに接続します。
    • プライマリ・データベース・サービスの使用: プライマリ・データベースの同じサービスを使用して、スナップショット・スタンバイ・データベースに接続します。

    「プライマリ・データベース・サービスの使用」オプションを選択すると、プライマリ・データベースとスナップショット・スタンバイ・データベースに接続するための適切な接続文字列をそれぞれ構成することに関する追加の警告メッセージが表示され、データベース接続が正しくないことが回避されます。

  7. 「変換」をクリックします。

    変換後、スタンバイ・データベースのロールが「スナップショット・スタンバイ」に変更され、「フィジカル・スタンバイへの変換」オプションが「その他のアクション」ドロップダウン・リストで使用可能になります。

    ノート:

    フィジカル・スタンバイACDへの変換は、ACDがSNAPSHOT_STANDBYモードの場合にのみ有効になります。

    • フィジカル・スタンバイACDに変換すると、すべてのADBからすべてのローカル更新が破棄され、プライマリACDからREDOデータが適用されます。
    • フィジカル・スタンバイに変換すると、スタンバイACDロールおよびそのすべてのADBロールがSTANDBYに戻ります。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

スナップショット・スタンバイACDからフィジカル・スタンバイACDへの変換

スナップショット・スタンバイ・データベースは、7日後にフィジカル・スタンバイ・データベースに自動的に変換されます。

スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに再変換される実際の日付のバナーが表示されます。 ACDのすべてのADBのデータベース・ロールもそれに応じて変更されます。 自動変換に関するバナー・メッセージは、ACDでのみ使用できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のスナップショット・スタンバイ・データベースの表示名をクリックします。

    Autonomous Container Database詳細ページが表示されます。

  4. 「その他のアクション」ドロップダウン・リストから「フィジカル・スタンバイへの変換」を選択します。

    ノート:

    スナップショット・スタンバイAutonomous Container Databaseをフィジカル・スタンバイに変換すると、スナップショット・スタンバイに対するすべてのローカル更新が破棄され、プライマリAutonomous Container Databaseのデータが適用されます。

  5. 「変換」をクリックします。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

CDB暗号化キーのローテーション

TDEマスター・キーをローテーションするには、次のステップに従います。 キーをローテーションすると、ACDライフ・サイクルは通常の更新状態をたどり、使用可能に戻ります。

TDEマスター・キーは、必要な回数だけローテーションできます。 新しいTDEマスター・キーは、前のキーが格納されたウォレットに格納されます。 TDEマスター・キーをローテーションすると、OKVで新しいキーが生成され、このデータベースに割り当てられます。 OKVのすべてのキーを表示できます。

ノート:

Oracle管理の暗号化キーと顧客管理の暗号化キーの両方をローテーションできます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、詳細を表示するプライマリ・データベースまたはスタンバイ・データベースの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページで、「暗号化キーのローテーション」をクリックします。
  5. 「暗号化キーのローテーション」ダイアログで「暗号化キーのローテーション」をクリックします。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

スタンバイの管理Autonomous Container Database

Autonomous Container DatabaseでAutonomous Data Guardを有効にすると、データ保護、高可用性を提供し、プライマリ・データベースの障害リカバリを容易にするスタンバイ(ピア) Autonomous Container Databaseが作成されます。

リージョンの障害、Autonomous Exadata Infrastructureの障害またはAutonomous Container Database自体の失敗によってプライマリAutonomous Container Databaseが使用できなくなった場合、自動フェイルオーバーが有効になっている場合、プライマリAutonomous Container Databaseは自動的にスタンバイAutonomous Container Databaseにフェイルオーバーします。 障害の発生したプライマリ・データベースのロールは「無効なスタンバイ」となり、しばらくすると、スタンバイ・データベースはプライマリ・データベースのロールを引き継ぎます。

次の表に、ハードウェア障害およびリージョナル停止に加えて、自動フェイルオーバーをトリガーするデータベースの健全性条件を示します:

表6-8 データベース・ヘルス条件

データベース・ヘルス条件 説明
データファイル書込みエラー データ・ファイル(一時ファイル、システム・データ・ファイル、UNDOファイルなど)で書込みエラーが発生すると、ファスト・スタート・フェイルオーバーが開始されます。
破損したディクショナリ 重要なデータベースのディクショナリが破損しました。 現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。
破損した制御ファイル ディスク障害のために制御ファイルが永続的に破損しました。

ノート:

  • 自動フェイルオーバーが終了すると、フェイルオーバーが発生したことを通知するメッセージが無効になっているスタンバイ・データベースの詳細ページに表示されます。
  • Autonomous Data Guardの構成時は、自動フェイルオーバーはオプションです。 Autonomous Data Guardを構成した後、自動フェイルオーバーを有効または無効にできます。
  • FastStartFailoverLagLimit構成属性は、適用されたREDOに関して、スタンバイ・データベースがプライマリ・データベースの後ろに置くことができる最大許容制限(秒)を設定します。 制限に達すると、ファスト・スタート・フェイルオーバーは実行されません。 この属性は、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。
    FastStartFailOverLagLimit属性:
    • デフォルト値は30秒です
    • 構成できません
    • 最大パフォーマンス保護モードの場合にのみ適用できます

サービスが前のプライマリAutonomous Container Databaseの問題を解決した後、手動スイッチオーバーを実行して両方のデータベースを初期ロールに戻すことができます。

スタンバイ・データベースをプロビジョニングすると、次のようなスタンバイ・データベースに関連する様々な管理タスクを実行できます:
  • プライマリ・データベースをスタンバイ・データベースに手動で切り替える
  • プライマリ・データベースのスタンバイ・データベースへの手動フェイルオーバー
  • フェイルオーバー後のプライマリ・データベースのスタンバイ・ロールへの回復
  • スタンバイ・データベースの終了

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

スタンバイAutonomous Container Databaseへのフェイルオーバーの実行

スタンバイ・データベースのData Guard関連付けを使用してフェイルオーバー操作を開始します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のインフラストラクチャ・リソースの表示名をクリックします。
  4. フェイルオーバーするプライマリAutonomous Container Databaseに関連付けられているスタンバイ・データベースまたはスナップショット・スタンバイの名前をクリックします。

    スタンバイACDがスナップショット・スタンバイ・モードの場合、フェイルオーバー操作を実行すると警告が表示されます:

    警告:

    スタンバイ・データベースはスナップショット・スタンバイ・ロールです。 フェイルオーバーでは、スナップショット・スタンバイに対するすべてのローカル更新を破棄し、プライマリ・データベースからデータを適用することで、スナップショット・スタンバイ・データベースをフィジカル・スタンバイに変換します。
  5. 「フェイルオーバー」をクリックします。
  6. 「スタンバイへの手動フェイルオーバーの確認」ダイアログ・ボックスで、フェイルオーバーするAutonomous Container Databaseの名前を入力し、「フェイルオーバー」をクリックします。

    あるいは、次のようにします。

    1. 「リソース」で、Autonomous Data Guardをクリックして、管理しているプライマリ・データベースのピア・データベースのリストを表示します。
    2. フェイルオーバーを実行するData Guard関連付けについて、「処理」アイコン(3ドット)をクリックし、「フェイルオーバー」をクリックします。
    3. 「スタンバイへの手動フェイルオーバーの確認」ダイアログ・ボックスで、フェイルオーバーするAutonomous Container Databaseの名前を入力し、「フェイルオーバー」をクリックします。

      ノート:

      フェイルオーバーが正常に完了すると、スタンバイACDロールはプライマリに変更され、プライマリ・ロールは無効化されたスタンバイになります。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

スタンバイまたはプライマリAutonomous Container Databaseへのスイッチオーバーの実行

プライマリ・データベースのData Guard関連付けを使用して、スイッチオーバー操作を開始します。

  • スイッチオーバーを実行できるのは、プライマリとスタンバイの両方が使用可能な状態の場合のみです。
  • プライマリまたはスタンバイでパッチ適用またはメンテナンスが進行中の場合、スイッチオーバーを実行できません。
  • スタンバイACDがスナップショット・スタンバイ・モードの場合、スイッチオーバー操作は実行できません。
  • スイッチオーバー後、新しいスタンバイおよびプライマリのメンテナンス・プリファレンスは、古いスタンバイおよびプライマリと同じままになります。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のインフラストラクチャ・リソースの表示名をクリックします。
  4. プライマリ・データベースまたはセカンダリ・データベースの名前をクリックします。
  5. 「スイッチオーバー」をクリックします。
  6. 確認ダイアログ・ボックスで、「スイッチオーバー」をクリックします。

    あるいは、次のようにします。

    1. 「リソース」の下で、「Data Guard関連付け」をクリックします。
    2. スイッチオーバーを実行するData Guard関連付けについて、「処理」アイコン(3ドット)をクリックし、「スイッチオーバー」をクリックします。
    3. 「スタンバイへのスイッチオーバーの確認」ダイアログ・ボックスで、Swichoverをクリックします。

      このデータベースはスタンバイのロールを引き受け、スタンバイはData Guard関連付けでプライマリのロールを引き継ぐ必要があります。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なスタンバイAutonomous Container Databaseの回復

プライマリ・データベースをスタンバイにフェイルオーバーすると、スタンバイはプライマリ・ロールを引き継ぎ、古いプライマリは無効化されたスタンバイとして識別されます。

運用チームが障害の原因を修正した後、Data Guard関連付けを使用して、障害が発生したデータベースを現在のプライマリの機能するスタンバイとして回復できます。Data Guard関連付けを使用して、障害が発生したデータベースを現在のプライマリの機能するスタンバイとして回復できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のインフラストラクチャ・リソースの表示名をクリックします。
  4. 「無効なスタンバイ」データベースの名前をクリックします。
  5. 「リソース」の下で、Autonomous Data Guard。をクリックします。
  6. このデータベースを回復するData Guard関連付けについて、「処理」アイコン(3ドット)をクリックし、「回復」をクリックします。
  7. 「データベースの回復」ダイアログ・ボックスで、「回復」をクリックします。

    このデータベースをData Guard関連付けのスタンバイとして回復する必要があります。 スイッチオーバー操作を実行して、それぞれのデータベースを元のロールに戻すことができるようになりました。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なプライマリAutonomous Container Databaseの終了

Oracle Exadata Cloud@Customerシステムで自律型コンテナ・データベースを終了するには、次のステップに従います。

コンテナ・データベース自体を終了する前に、コンテナ・データベース内のすべてのAutonomous Databasesを終了する必要があります。 Autonomous Container Databaseを終了すると、Autonomous Data Guardが無効になり、Autonomous Databasesの高可用性および障害リカバリに影響します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のインフラストラクチャ・リソースの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページで、その他のアクション・ドロップ・ダウン・リストから「終了」を選択します。
  5. 「終了」をクリックします。
  6. 確認ダイアログで、Autonomous Container Databaseの名前を入力し、「Autonomous Container Databaseの終了」をクリックします。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なスタンバイAutonomous Container Databaseの終了

Oracle Exadata Cloud@Customerシステムで自律型コンテナ・データベースを終了するには、次のステップに従います。

スタンバイAutonomous Databasesが含まれている場合でも、スタンバイAutonomous Container Databaseを終了できます。 ただし、スタンバイAutonomoous Container Database内のスタンバイAutonomous Databasesは終了できません。 スタンバイAutonomoous Databaseを終了するには、まずプライマリAutonomous Databaseを終了する必要があります。 Autonomous Container Databaseを終了すると、Autonomous Data Guardが無効になり、Autonomous Databasesの高可用性および障害リカバリに影響します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のインフラストラクチャ・リソースの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページで、その他のアクション・ドロップ・ダウン・リストから「終了」を選択します。
  5. 「終了」をクリックします。
  6. 確認ダイアログで、Autonomous Container Databaseの名前を入力し、「Autonomous Container Databaseの終了」をクリックします。

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

APIを使用して実行される操作

APIを使用してAutonomous Data Guard対応Autonomous Container Databaseを管理する方法について学習します。

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

次の表に、Autonomous Data Guard対応Autonomous Container Databaseを管理するためのREST APIエンドポイントを示します。

操作 REST APIエンドポイント

Autonomous Container Databasesを作成します(既存のAPIへの更新)

CreateAutonomousContainerDatabase

指定したAutonomous Container Databaseの詳細の表示

GetAutonomousContainerDatabase

Autonomous Data Guard関連付けを持つAutonomous Container Databasesのリストの表示

ListAutonomousContainerDatabaseDataguardAssociations

Autonomous Container Database Autonomous Data Guard関連付けの詳細をフェッチ

GetAutonomousContainerDatabaseDataguardAssociation

既存のプライマリAutonomous Container Databaseに障害が発生した後、またはアクセスできなくなった後に、autonomousContainerDatabaseIdパラメータで識別されるスタンバイAutonomous Container DatabaseをプライマリAutonomous Container Databaseにフェイルオーバーします。

FailoverAutonomousContainerDatabaseDataguardAssociation

Autonomous Data Guardピア関連付けのプライマリAutonomous Container Databaseをスタンバイ・ロールにスイッチオーバーします。 autonomousContainerDatabaseDataguardAssociationIdに関連付けられたスタンバイAutonomous Container Databaseは、プライマリAutonomous Container Databaseロールを引き継ぎます。

SwitchoverAutonomousContainerDatabaseDataguardAssociation

autonomousContainerDatabaseIdパラメータで識別される無効化されたスタンバイAutonomous Container Databaseをアクティブ・スタンバイAutonomous Container Databaseに回復します。

ReinstateAutonomousContainerDatabaseDataguardAssociation

指定したAutonomous Databaseに関連付けられているAutonomous Data Guard対応データベースのリストを表示します。

ListAutonomousDatabaseDataguardAssociations

Autonomous Database Autonomous Data Guard関連付けの詳細をフェッチ

GetAutonomousDatabaseDataguardAssociation

ピア・データベース・ロール、タイム・ラグ、トランスポート・ラグ、状態などの詳細をフェッチ

GetAutonomousDatabase

関連トピック

親トピック: Autonomous Container DatabaseでのAutonomous Data Guardの有効化

Autonomous DatabaseでのAutonomous Data Guardの有効化

Autonomous Databasesは、親コンテナ・データベースからData Guard設定を継承します。

親トピック: Exadata Cloud@CustomerでのAutonomous Data GuardとAutonomous Databaseの使用

Autonomous Data Guard有効化の表示

Autonomous Data Guard設定は、データベースが実行されているAutonomous Container Databasesで構成されます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Container Databasesをクリックします。

    このページには、自律型データベースがData Guard対応かどうかが表示され、有効な場合はData Guard関連付けにおけるデータベースのロールが表示されます。

親トピック: Autonomous DatabaseでのAutonomous Data Guardの有効化

Autonomous Data Guard対応Autonomous Databaseの作成

Oracle Exadata Cloud@CustomerシステムでAutonomous Databaseを作成するには、次のステップに従います。

ノート:

Autonomous Data Guard対応コンテナ・データベースでは、Autonomous Database for Developersインスタンスを作成できません。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. 「Autonomous Databaseの作成」をクリックします。
  4. Autonomous Databaseを作成ダイアログで、次のように入力します:

    基本的なデータベース情報

    • コンパートメント: Autonomous Databaseのコンパートメントを選択します。
    • 表示名: ユーザー・フレンドリな説明またはリソースを簡単に識別するのに役立つその他の情報。 表示名は一意である必要はありません。 機密情報の入力は避けてください。
    • データベース名: データベース名は、文字および数字のみで構成され、文字で始まる必要があります。 機密情報の入力は避けてください。

    ワークロード・タイプ

    目的のワークロード・タイプを選択します。 各ワークロード・タイプの詳細は、Autonomous Data WarehouseおよびAutonomous Transaction Processingを参照してください。

    Autonomous Container Database: Autonomous Data Guard対応Autonomous Container Databasesチェック・ボックスを選択し、Autonomous Container Databaseを選択します。

    コンパートメント: 使用するAutonomous Container Databaseを含むコンパートメントを指定します。

    データベースCPUコア数およびストレージ構成

    • CPU数: Autonomous Exadata Infrastructure内のすべてのデータベースで使用可能なコアの合計数は、インフラストラクチャ・シェイプおよび他のAutonomous Databasesにすでに割り当てられているものによって異なります。

      CPUタイプ(OCPUまたはECPU)は、親のAutonomous Exadata VM Clusterリソース・コンピュート・タイプによって決まります。

      選択したCPU数はプロビジョニング可能なCPUのリストに対して検証され、選択したCPU数までデータベースをスケール・アップできない場合は、最も近い2つのプロビジョニング可能なCPU値が提供されます。

      各ノードのリソース使用率に基づいて、使用可能なCPUのすべての値を使用してAutonomous Databasesをプロビジョニングまたはスケーリングできるわけではありません。 たとえば、AVMCレベルで使用可能なCPUが20個あり、ノード・レベルでのリソースの可用性に応じて、1から20個のCPUのすべての値を使用してAutonomous Databasesをプロビジョニングまたはスケーリングできるわけではないとします。 Autonomous Databaseのプロビジョニングまたはスケーリングに使用できるCPU値のリストは、「プロビジョニング可能なCPU」と呼ばれます。

      コンソールで、Autonomous Databaseのプロビジョニングまたはスケーリングを試行すると、CPU数がプロビジョニング可能なCPUのリストに対して検証され、値がプロビジョニングできない場合は、最も近いプロビジョニング可能な2つのCPU値が提供されます。 または、Autonomous Exadata VM Clusterのプロビジョニング可能なCPU値の完全なリストを表示する場合は、次のAPIを使用できます:

      GetAutonomousContainerDatabaseは、指定されたAutonomous Container Databaseで新しいAutonomous Databaseを作成するために使用できる、プロビジョニング可能なOCPU値のリストを返します。 詳細は、GetAutonomousContainerDatabaseを参照してください。

      ECPUの場合、この値のデフォルトは2 ECPUです。 2つ以上のECPUを必要とするデータベースの場合、割り当てられるECPUの数を1単位で指定する必要があります。

      ノート:

      CPUオーバー・プロビジョニングはECPUでは許可されません。

      OCPUの場合、デフォルト値は1 OCPUです。 ただし、0.1から0.9 (0.1 OCPUの増分)までの小数OCPU値を、完全なOCPUを必要としないデータベースに割り当てることができます。 これにより、CPUをオーバー・プロビジョニングし、各インフラストラクチャ・インスタンスでより多くのデータベースを実行できます。 1つ以上のOCPUを必要とするデータベースの場合、割り当てられたOCPUの数を整数で指定する必要があります。 たとえば、3.5 OCPUをデータベースに割り当てることはできません。 3を超えると、次に使用可能なOCPUの数は4です。

      CPUのオーバー・プロビジョニングがあるデータベースは、tpおよびlowサービスを使用してのみ接続できます。

      自動スケーリングを無効にするには、自動スケーリングの選択を解除します。 デフォルトでは、自動スケーリングが有効になっており、ワークロードの要求を満たすために最大3倍のCPUおよびIOリソースを自動的に使用できます。

    • ストレージ(TB): Autonomous Databaseで使用可能にするストレージをテラバイト単位で指定します。 使用可能なストレージは、インフラストラクチャのシェイプおよび他のAutonomous Databasesですでに使用されているものによって異なります。

    管理者資格証明

    次の基準を満たすパスワードを入力して、Autonomous Database管理ユーザーのパスワードを設定します。 このパスワードは、Autonomous Databaseサービス・コンソールへのアクセス時およびSQLクライアント・ツールの使用時に使用します。

    • 12から30文字を含む
    • 小文字を1文字以上含めます
    • 大文字を1文字以上含めます
    • 数字を1文字以上含めます
    • 二重引用符(")を含めることはできません
    • 大/小文字に関係なく、文字列「admin」は含まれません

    「ネットワーク・アクセスの構成」

    必要に応じて、データベース・プロビジョニング時またはその後の任意の時点でACLを作成できます。

    1. 「アクセス制御の変更」をクリックします。
    2. 「アクセス制御リストの編集」ダイアログで、「データベース・レベルのアクセス制御の有効化」チェック・ボックスを選択します。
    3. 「プライマリ・データベースのアクセス制御リスト」で、IP表記法タイプ・ドロップ・ダウン・セレクタを使用して、リストに次のタイプのアドレスを指定します:

      IPアドレスを使用すると、1つ以上の個別のパブリックIPアドレスを指定できます。 カンマを使用して、入力フィールドのアドレスを区切ります。

      CIDRブロックでは、CIDR表記を使用して1つ以上のパブリックIPアドレスの範囲を指定できます。 カンマを使用して、入力フィールドのCIDRブロック・エントリを区切ります。

    4. スタンバイ・データベースのアクセス制御で、次の手順を実行します:

      (デフォルト)プライマリ・データベースと同じ: セカンダリ・データベースに同じアクセス制御リストを使用する場合は、そのままにします。

      スタンバイ・データベースのアクセス制御の定義: プライマリと同じ詳細で初期化されました。 必要に応じて、エントリを追加または変更します。

    拡張オプション

    タグ: オプションで、タグを適用できます。 リソースの作成権限がある場合、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用するかどうか不明な場合は、このオプションをスキップする(タグを後から適用できます)か、管理者に問い合せてください。 機密情報の入力は避けてください。

    暗号化キー: ADBは、親ACDから暗号化設定を継承します。 親ACDが顧客管理OKVベースの暗号化用に構成されている場合、子ADBでも、ACDマスター・キーの格納に使用されるのと同じOKVウォレットでTDEマスター・キーが生成および管理されます。 また、Autonomous Databaseで取得されたバックアップには、OKVベースのキーが関連付けられます。

  5. 「Autonomous Databaseの作成」をクリックします。

    ノート:

    Autonomous Transaction ProcessingおよびAutonomous Data Warehouseデータベースには、次のネーミング制限が適用されます:

    • 過去60日以内に終了したデータベースに関連付けられた名前は、新規データベースの作成時には使用できません。
    • データベース名は、Autonomous Data WarehouseデータベースとAutonomous Transaction Processingデータベースの両方に同時に使用することはできません。

関連トピック

親トピック: Autonomous DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なプライマリまたはスタンバイAutonomous Databaseの詳細の表示

Oracle Exadata Database Service on Cloud@CustomerシステムのプライマリまたはスタンバイAutonomous Databaseに関する詳細情報を表示するには、次のステップに従います。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Databasesのリストで、詳細を表示するデータベースの表示名をクリックします。
  4. 「Autonomous Database詳細」ページで、Autonomous Data Guardの関連付けステータスおよびピア・データベースの状態を確認します。
  5. 「リソース」で、Autonomous Data Guardをクリックして関連付けの詳細を表示します。

親トピック: Autonomous DatabaseでのAutonomous Data Guardの有効化

ADB暗号化キーのローテーション

TDEマスター・キーをローテーションするには、次のステップに従います。 キーをローテーションすると、ADBライフ・サイクルは通常の更新状態をたどり、使用可能に戻ります。

TDEマスター・キーは、必要な回数だけローテーションできます。 新しいTDEマスター・キーは、前のキーが格納されたウォレットに格納されます。 TDEマスター・キーをローテーションすると、OKVで新しいキーが生成され、このデータベースに割り当てられます。 OKVのすべてのキーを表示できます。

ノート:

Oracle管理の暗号化キーと顧客管理の暗号化キーの両方をローテーションできます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Databasesのリストで、詳細を表示するデータベースの表示名をクリックします。
  4. 「Autonomous Database詳細」ページで、「その他のアクション」ドロップダウン・リストから「暗号化キーのローテーション」を選択します。
  5. 「暗号化キーのローテーション」ダイアログで「暗号化キーのローテーション」をクリックします。

親トピック: Autonomous DatabaseでのAutonomous Data Guardの有効化

Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用

Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールを変更するには、次のステップに従います。

親トピック: Exadata Cloud@CustomerでのAutonomous Data GuardとAutonomous Databaseの使用

Data Guardが有効なAutonomous Container Databaseの自動メンテナンス・スケジュールの構成

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のコンテナ・データベースの表示名をクリックします。
  4. Autonomous Container Databaseの詳細ページで、「メンテナンス・プリファレンスの編集」をクリックします。

    表示される「自動メンテナンスの編集」ダイアログで、メンテナンス・スケジュールとパッチ・タイプの両方を構成できます。

    ノート:

    スタンバイ・データベースには、デフォルトで「プリファレンスなし」があります。 スタンバイ・メンテナンスは、プライマリ・メンテナンス・スケジュールによって異なります。

  5. オプションで、メンテナンス・パッチ・タイプを変更できます。 この設定を編集するには、「リリース更新(RU)」または「リリース更新改訂(RUR)」を選択します。

    リリース更新(RU): Autonomous Databaseは、最新のリリース更新のみをインストールします。

    リリース更新改訂(RUR): Autonomous Databaseは、リリース更新と追加の修正をインストールします。

    ノート:

    スタンバイは常にプライマリの前にパッチが適用され、スタンバイとプライマリの間のデフォルトのギャップは7日間です。 デフォルトのギャップを1つの間の任意の時間に変更するオプションがあります - 7 days.

    コンテナ・データベースのメンテナンス・バージョンの構成
    • 次のリリース更新(RU): 次のメンテナンス・サイクルで次のリリース更新に更新します。
    • 最新リリース更新(RU): 次のメンテナンス・サイクルで最新のリリース更新に更新します。
  6. メンテナンス・スケジュールを構成するには、自動メンテナンス・スケジュールの構成セクションでスケジュールの指定を選択します。 コンテナ・データベース・メンテナンスに対して希望する月、週、平日および開始時刻を選択します。

    • メンテナンス月で、Autonomous Exadata Infrastructureのメンテナンスを実行するメンテナンス四半期ごとに1か月以上を指定します。

      ノート:

      メンテナンス四半期は、2月、5月、8月、11月に始まり、1年の最初のメンテナンス四半期は2月から始まります。

    • 毎月何週で、メンテナンスを実行する週を指定します。 週は月の1日目、8日目、15日目、22日目から始まり、期間は7日です。 週は、曜日ではなくカレンダの日付に基づいて開始および終了します。 28日を超える月の5週目のメンテナンスはスケジュールできません。
    • 曜日で、メンテナンスを実行する曜日を指定します。
    • 開始時間で、メンテナンス実行を開始する時間を指定します。
    • プライマリ・メンテナンスの実行とスタンバイ・メンテナンスの実行の間のバッファ期間を選択します。 バッファ期間は、プライマリAutonomous Container Databaseメンテナンスの前にスタンバイAutonomous Container Databaseメンテナンスがスケジュールされるまでの日数です
  7. 「変更の保存」をクリックします。

親トピック: Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用

Data Guardが有効なAutonomous Container Databaseの次回のスケジュール済メンテナンス実行の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のコンテナ・データベースの表示名をクリックします。
  4. Autonomous Container Databaseの詳細ページの「メンテナンス」の下で、「次回のメンテナンス」フィールドの「表示」リンクをクリックします。
  5. 「メンテナンス」ページの「Autonomous Databaseのメンテナンス」の下で、「メンテナンス」をクリックします。

    メンテナンス・イベントのリストで、スケジュール済メンテナンス実行の詳細を確認できます。 メンテナンス・イベントの詳細には、次のものが含まれます:

    • スケジュール済メンテナンス実行のステータス
    • メンテナンス実行のタイプ(四半期ごとのソフトウェア・メンテナンスまたはクリティカル・パッチ)
    • メンテナンス・イベントのOCID
    • メンテナンスの開始日時

親トピック: Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用

Data Guardが有効なAutonomous Container Databaseのメンテナンス履歴の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、目的のコンテナ・データベースの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページの「メンテナンス」の下で、「次回のメンテナンス」フィールドの「表示」リンクをクリックします。
  5. 「メンテナンス」ページの「Autonomous Databaseのメンテナンス」の下で、「メンテナンス履歴」をクリックします。

    過去のメンテナンス・イベントのリストで、個々のイベント・タイトルをクリックすると、発生したメンテナンスの詳細を読み取ることができます。 メンテナンス・イベントの詳細には、次のものが含まれます:

    • メンテナンスのカテゴリ(四半期ごとのソフトウェア・メンテナンスまたはクリティカル・パッチ)
    • メンテナンスがスケジュールされたかどうか
    • メンテナンス・イベントのOCID
    • メンテナンスの開始日時

親トピック: Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用

Data Guardが有効なAutonomous Container Databaseへの即時パッチ適用

ノート:

プライマリにすぐにパッチを適用すると、スタンバイにまだパッチが適用されていない場合は、最初にスタンバイにパッチが適用されます。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、パッチを適用するAutonomous Container Databaseの表示名をクリックします。
  4. 「Autonomous Container Database詳細」ページの「メンテナンス」セクションで、「次回のメンテナンス」フィールドの「表示」リンクをクリックして、パッチを適用するAutonomous Container DatabaseのMaintenanceページを表示します。
  5. Autonomous Container Databaseセクションで、「予定開始時間」フィールドの「今すぐパッチ」をクリックして「メンテナンスの実行」ダイアログを表示します。
  6. 「今すぐパッチ」をクリックして、パッチ適用操作を開始します。

親トピック: Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用

Data Guardが有効なAutonomous Container Databaseのスケジュール済メンテナンスの再スケジュールまたはスキップ

ノート:

プライマリをスキップすると、スタンバイもスキップされます。 スタンバイにパッチが適用されている場合、プライマリでのスキップは許可されません。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Autonomous Databasesをクリックします。
  3. Autonomous Container Databasesのリストで、管理するコンテナ・データベースの表示名をクリックします。
  4. Autonomous Container Databaseの詳細ページの「メンテナンス」セクションで、「次回のメンテナンス」フィールドの「表示」リンクをクリックします。
  5. 「メンテナンス」ページで、次の15日間に計画されているコンテナ・データベース・メンテナンス・イベントがメンテナンス・イベントのリストに表示されます。

    コンテナ・データベースのスケジュール済メンテナンスをスキップするには、「スキップ」をクリックします。

    ノート:

    スケジュール済メンテナンスを連続して2回以上スキップすることはできません。

    メンテナンスを再スケジュールするには、「編集」をクリックし、「メンテナンスの編集」ダイアログに更新の開始時間を入力します。 指定したコンテナ・データベース・メンテナンス・ウィンドウが、スケジュールされたExadataインフラストラクチャ・メンテナンスよりも四半期内にあることを確認します。

親トピック: Data Guardが有効なAutonomous Container Databaseのメンテナンス・スケジュールおよびパッチ適用