機械翻訳について
  1. Exadata Database Service on Dedicated Infrastructure
  2. Exadata Cloud Infrastructureデプロイメントの開始
  3. Exadata Cloud Infrastructureインスタンスの作成

Exadata Cloud Infrastructureインスタンスの作成

このトピックでは、Oracle Exadata Cloud Infrastructureインスタンスの作成方法について説明します。 また、Oracle Cloud Infrastructure Object Storageサービスに必要なアクセスを構成し、DNSを設定する方法についても説明します。

コンソールまたはAPIを使用してExadata Cloud Infrastructureインスタンスを作成すると、Oracleデータベースをサポートするようにシステムがプロビジョニングされます。 インフラストラクチャとともに、VMクラスタ、初期データベース・ホームおよびデータベースが作成されます。 コンソールまたはOracle Cloud Infrastructure APIを使用して、いつでも追加のデータベース・ホームおよびデータベースを作成できます。 サービスでは、提供するオプションおよびこのトピックで後述する一部のデフォルト・オプションに基づいて、初期データベースが作成されます。

親トピック: Exadata Cloud Infrastructureデプロイメントの開始

作成するリソース

Exadata Cloud InfrastructureインフラストラクチャおよびVMクラスタ・リソースを個別にプロビジョニングします。

  • 「クラウドExadataインフラストラクチャ」リソース: インフラストラクチャ・リソースは最上位(親)リソースです。 インフラストラクチャ・レベルで、データベースおよびストレージ・サーバーの数を制御します。 また、Exadataシステム・メンテナンス・スケジュールをExadataインフラストラクチャ・レベルで制御します。
  • 「クラウドVMクラスタ」リソース: VMクラスタはインフラストラクチャ・リソースの子リソースであり、Exadataクラウド・インフラストラクチャ・リソースとOracle Database間のリンクを提供します。 ネットワーキング、OCPU数、IORM (「IORMについて」を参照)およびOracle Grid Infrastructureは、VMクラスタ・レベルで構成および管理されます。 クラウドVMクラスタを作成するには、VMクラスタを格納するための既存のクラウドExadataインフラストラクチャ・リソースが必要です。

ノート:

  • 「Exadataクラウド・インフラストラクチャ」では、選択したハードウェア・シェイプ・ファミリ(X7、X8、X8MまたはX9M)に関係なく、新しいリソース・モデル(個別のExadataインフラストラクチャおよびVMクラスタ・リソースで構成される)を使用して「Exadataクラウド・インフラストラクチャ」インスタンスをプロビジョニングすることのみがサポートされます。 DBシステムのリソース・モデルおよびAPIは、Exadata Cloud Infrastructureでは非推奨です。
  • 「マルチVM対応インフラストラクチャ」は、インフラストラクチャでの最大8つのVMクラスタの作成をサポートします。>> X8M以上の世代のDBサーバーを含むExadata Infrastructuresは、すべてのDBサーバーで最大8つのVMクラスタをサポートできます。 インフラストラクチャ全体でのクラスタの最大数は、DBサーバーごとに使用可能なリソースに応じて異なり、DBサーバーごとの最大VM制限の対象となります。 詳細は、「VMクラスタ・ノード・サブセット化の概要」を参照してください。
  • マルチVM対応ではないExadata Cloud Serviceインフラストラクチャ・インスタンスでは、1つのクラウドVMクラスタのみがサポートされます

親トピック: Exadata Cloud Infrastructureインスタンスの作成

Cloud Exadata Infrastructureインスタンスの作成の前提条件

インフラストラクチャ・インスタンスを作成するには、SSHキー・ペア・キーと仮想クラウド・ネットワーク(VCN)が必要です。

  • 続行するには適切なIAMポリシーが必要です。 「Exadata Cloud Infrastructureに必要なIAMポリシー」を参照してください

  • OpenSSH形式の公開キーで、SSHを介したシステムへの接続に使用する予定のキー・ペアです。 読みやすくするために省略されたサンプルの公開キーを次に示します。 

    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAA....lo/gKMLVM2xzc1xJr/Hc26biw3TXWGEakrK1OQ== rsa-key-20160304

    詳細は、「Linuxインスタンスでのキー・ペアの管理」を参照してください。

  • システムを起動する仮想クラウド・ネットワーク(VCN)。 関連するネットワーク・リソース(ゲートウェイ、ルート表、セキュリティ・リスト、DNSなど)も、システムで必要に応じて構成する必要があります。 詳細は、Exadata Cloud Infrastructureインスタンスのネットワーク設定を参照してください。

関連トピック

親トピック: Exadata Cloud Infrastructureインスタンスの作成

初期データベースのデフォルト・オプション

デフォルト・オプションは、コンソールおよびAPIの使用時にExadata Cloud Infrastructureインスタンスの起動を簡略化します。

次のデフォルト・オプションが初期データベースに使用されます:

  • コンソール有効: False
  • コンテナ・データベースの作成: バージョン11.2.0.4データベースではFalseです。 そうでなければ、true。
  • インスタンスのみの作成(スタンバイおよび移行の場合): False
  • データベース・ホームID: データベース・ホームを作成
  • データベース言語: AMERICAN
  • データベース・サイズ設定テンプレート: odb2
  • データベース・ストレージ: 自動ストレージ管理(ASM)
  • データベース・テリトリ: AMERICA
  • 一意のデータベース名: ユーザー指定のデータベース名とシステム生成サフィクス(dbtst_phx1csなど)。
  • PDB管理名: pdbuser (バージョン11.2.0.4データベースには適用されません。)

親トピック: Exadata Cloud Infrastructureインスタンスの作成

コンソールを使用したインフラストラクチャ・リソースの作成

クラウド・リソースの作成に必要なコンソール・タスク

親トピック: Exadata Cloud Infrastructureインスタンスの作成

  1. ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、Oracle Exadata Database Service on Dedicated Infrastructureをクリック
  2. Oracle Exadata Database Service on Dedicated Infrastructureで、Exadata Infrastructureをクリックします。
  3. 「Exadata Cloud Infrastructureの作成」をクリックします。
  4. コンパートメント: Exadataインフラストラクチャのコンパートメントを選択します。
  5. 表示名: Exadataインフラストラクチャの表示名を入力します。 名前は、一意である必要はありません。 Oracle Cloud Identifier (OCID)は、クラウドExadataインフラストラクチャ・リソースを一意に識別します。 機密情報の入力は避けてください。
  6. 可用性ドメインの選択: Exadataインフラストラクチャが存在する可用性ドメイン。
  7. Exadata Cloud Infrastructureモデルを選択します: 固定シェイプ・システム(クォータ、ハーフまたはフル・ラックのX7-2またはX8-2シェイプ)、またはスケーラブル・システム(X8M-2、X9M-2またはX11M)のいずれかを選択します。

    X11M: フレキシブルなX11Mクラウド・インフラストラクチャ・モデルを選択した場合、初期Exadata Cloud Infrastructureインスタンスには、32台までのデータベース・サーバーと64台のストレージ・サーバーまで、2台以上のデータベース・サーバーと3台のストレージ・サーバーを含めることができます。 データベース・サーバーおよびストレージ・サーバー・タイプも選択する必要があります。 これは、データベース・サーバー・タイプの場合はX11M、ストレージ・サーバー・タイプの場合はX11M-HCにデフォルト設定されます。 プロビジョニング後、ストレージ・サーバー、コンピュート・サーバーまたはその両方を追加することで、必要に応じてサービス・インスタンスをスケーリングできます。

    X9M-2: 柔軟なX9M-2クラウド・インフラストラクチャ・モデルを選択した場合、最初のExadataクラウド・インフラストラクチャインスタンスには、2台以上のデータベース・サーバーおよび3台までのストレージ・サーバーと、最大32台のデータベース・サーバーと64台のストレージ・サーバーを含めることができます。 プロビジョニング後、ストレージ・サーバー、コンピュート・サーバーまたはその両方を追加することで、必要に応じてサービス・インスタンスをスケーリングできます。

    X8M-2: フレキシブルなX8M-2クラウド・インフラストラクチャ・モデルを選択した場合、最初のExadataクラウド・インフラストラクチャ・インスタンスには、32台のデータベース・サーバーおよび64台のストレージ・サーバーまで、2台以上のデータベース・サーバーと3台のストレージ・サーバー(X8クォータ・ラック・シェイプに相当)を含めることができます。 プロビジョニング後、ストレージ・サーバー、コンピュート・サーバーまたはその両方を追加することで、必要に応じてサービス・インスタンスをスケーリングできます。

    X7およびX8: X7またはX8システムを選択すると、クォータ・ラック、ハーフ・ラックまたはフル・ラックをプロビジョニングできます。 ハードウェアおよび容量の詳細は、「Exadataシェイプの構成」を参照してください。

    Exadataベース: Exadataベース・シェイプは単一の構成で、クォータ・ラック・システムをプロビジョニングする経済的な代替手段を提供します。 「Exadataシェイプの構成」を参照してください

  8. フレキシブル・シェイプ(X8M-2、X9M-2またはX11M)を選択した場合は、コンピュートおよびストレージ構成を指定します。 データベース・サーバーは、2台から32台まで指定できます。 ストレージ・サーバーは、3台から64台まで指定できます。
  9. タイム・ゾーンの選択 : 次のいずれかを選択します :
    • UTC
    • 別のタイムゾーンを選択
    • (ブラウザ検出)タイムゾーン
  10. メンテナンスを構成します。

    「メンテナンス・プリファレンスの編集」をクリックして値を変更します。

    「メンテナンスの構成」ページで、次を構成します:
    • メンテナンス・スケジュール設定: Oracle管理スケジュール
      • メンテナンス・メソッドを選択してください:
        • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
        • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
      • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
        • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

          ノート:

          カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。

          デフォルト: 15分

          最大: 120分

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

        ノート:

        次回のメンテナンス実行以降は、Oracleのスケジュールに従って実行されます。
    • メンテナンス・スケジュール設定: 顧客管理スケジュール
      • メンテナンス・スケジュール: このインフラストラクチャのメンテナンス・プリファレンスを定義します。

        ノート:

        変更は、次のメンテナンス実行から有効になります。
        • メンテナンス・プリファレンスを構成します: 各四半期のメンテナンス時間プリファレンスを定義します。 1つの四半期に複数のプリファレンスが定義されている場合、Oracle Automationはそれらのいずれかを選択して、インフラストラクチャ内のすべてのコンポーネントでメンテナンスを実行します。

          2四半期ごとに少なくとも1か月を選択します。

        • スケジュールを指定します: インフラストラクチャ・メンテナンスの希望する週、平日、開始時間およびリード・タイムを選択します。
          • オプション。 「該当月の週」で、メンテナンスを実行する月の週を指定します。 週は月の1日目、8日目、15日目、22日目から始まり、期間は7日です。 週は、曜日ではなくカレンダの日付に基づいて開始および終了します。 28日を超える月の5週目のメンテナンスはスケジュールできません。 月の週を指定しない場合は、Oracleによって、中断が最小限になる週にメンテナンス更新が実行されます。
          • オプション。 「曜日」で、メンテナンスを実行する曜日を指定します。 曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
          • オプション。 「1日の時間」で、メンテナンス実行を開始する時間を指定します。 開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
          • 「通知リード・タイム」で、通知メッセージを受信するメンテナンス・イベントの最小週数を指定します。 リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
        • メンテナンス・メソッドを選択してください:
          • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
          • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
        • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
          • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

            ノート:

            カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。

            デフォルト: 15分

            最大: 120分

        • 拡張オプションの表示:
          • 月次セキュリティ・インフラストラクチャ・メンテナンスの有効化: 月次セキュリティ・インフラストラクチャ・メンテナンスを実行するには、このチェック・ボックスを選択します。
      • メンテナンス・スケジュール: スケジュール・ポリシーからのメンテナンス・ウィンドウ・プリファレンスの使用

        インフラストラクチャのプロビジョニング中に、スケジューリング・ポリシーを選択した後、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。 推奨される計画では、期間に基づいてポリシーからメンテナンス・ウィンドウにすべてのDBサーバー、ストレージ・サーバーの順にスケジュールします。 インフラストラクチャのプロビジョニング後、「メンテナンス・スケジューリング計画」リソースを編集してスケジューリング計画を更新し、特定のコンポーネントに更新をカスタマイズして、スケジューリング・ポリシーの異なるウィンドウに合せることができます。

  11. In the メンテナンスの詳細の指定 : 最大10の一意のメンテナンス連絡先の電子メール・アドレスを指定。 「連絡先の追加」をクリックします。
    「連絡先のEメール」フィールドに、目的の連絡先の電子メールIDを指定します。

    ノート:

    少なくとも1つの担当者が必要です。

    「連絡先の追加」をクリックして別の連絡先を追加します。

  12. 「高度なオプションを表示」をクリックして、初期データベースの拡張オプションを指定します。

    「タグ」タブでは、データベースにタグを追加できます。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、リソース・タグを参照してください。 タグを適用するかどうか不明な場合は、このオプションをスキップする(タグを後から適用できます)か、管理者に問い合せてください。

  13. 「Exadata Infrastructureを作成」をクリックします。 クラウドExadataインフラストラクチャは、ステータスがプロビジョニングのExadata Infrastructureリストに表示されます。 インフラストラクチャ・アイコンが黄色から緑(エラーを示す赤)に変わります。

次の手順

クラウドExadataインフラストラクチャ・リソースが正常にプロビジョニングされ、「使用可能」ステータスになったら、クラウドVMクラスタ・リソースを作成するにはの説明に従って、インフラストラクチャにクラウドVMクラスタを作成できます。 新しいExadata Cloud Infrastructureインスタンスで「最初のデータベースの作成」を実行するには、インフラストラクチャ・リソースとVMクラスタの両方をプロビジョニングする必要があります。

関連トピック

親トピック: コンソールを使用したインフラストラクチャ・リソースの作成

「Exadataクラウド・インフラストラクチャ」インスタンスにVMクラスタを作成します。

ノート:

Exadata Cloud InfrastructureインスタンスにクラウドVMクラスタを作成するには、最初に「クラウドExadataインフラストラクチャ・リソースの作成」が必要です。

ノート:

「マルチVM対応インフラストラクチャ」では、複数のVMクラスタの作成がサポートされます。 機能「Exadataシステム(MultiVM)およびVMクラスタ・ノード・サブセットごとの複数の仮想マシンの作成および管理」がリリースされる前に作成されたインフラストラクチャは、単一のクラウドVMクラスタの作成のみをサポートしています。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、Oracle Exadata Database Service on Dedicated Infrastructureをクリック
  2. Oracle Exadata Database Service on Dedicated Infrastructureで、「Exadata VMクラスタ」をクリックします。

    ノート:

    複数のVMクラスタは、「マルチVM対応インフラストラクチャ」でのみ作成できます。
  3. 「Exadata VMクラスタの作成」をクリックします。

    「Exadata VMクラスタの作成」ページが表示されます。 VMクラスタを構成するために必要な情報を指定します。

  4. コンパートメント: VMクラスタ・リソースのコンパートメントを選択します。
  5. 表示名: VMクラスタのわかりやすい表示名を入力します。 名前は、一意である必要はありません。 Oracle Cloud Identifier (OCID)はDBシステムを一意に識別します。 機密情報の入力は避けてください。
  6. Exadataインフラストラクチャの選択: VMクラスタを含むインフラストラクチャ・リソースを選択します。 新しいVMクラスタを作成するための十分なリソースがあるインフラストラクチャ・リソースを選択する必要があります。 「コンパートメントの変更」をクリックし、作業しているコンパートメントとは別のコンパートメントを選択して、他のコンパートメントのインフラストラクチャ・リソースを表示します。

    ノート:

    複数のVMクラスタは、「マルチVM対応インフラストラクチャ」でのみ作成できます
  7. Oracle Grid Infrastructureバージョンを選択します: リストから、VMクラスタにインストールするOracle Grid Infrastructureリリース(19cおよび23ai)を選択します。

    Oracle Grid Infrastructureリリースによって、VMクラスタでサポートできるOracle Databaseリリースが決まります。 Oracle Grid Infrastructureソフトウェア・リリースより後のOracle Databaseリリースは実行できません。

    ノート:

    Grid Infrastructure 23aiでVMクラスタをプロビジョニングするための最小要件:
    • Exadataシステム・ソフトウェアを実行するExadataゲストVM 23.1.8
    • Exadata Infrastructure Exadataシステム・ソフトウェアの実行23.1.x
  8. Exadataイメージ・バージョンを選択します:
    • Oracle Linux 7およびExadataイメージ・バージョン22.1.10.0.0.230422のExadataインフラストラクチャ:
      • 「イメージを変更」ボタンは有効になっていません。
      • Oracle Grid Infrastructureバージョンのデフォルトは19.0.0.0.0です。
      • Exadataゲストのバージョンは、ホストOSのバージョンと同じです。
    • Oracle Linux 8およびExadataイメージ・バージョン23.1.3.0.0.230613のExadataインフラストラクチャ:
      • Exadataゲスト・バージョンは、デフォルトで最新(23.1.3.0)になります。
      • Oracle Grid Infrastructureバージョンのデフォルトは19.0.0.0.0です
      • 「イメージを変更」ボタンが有効になっています。
      • 「イメージの変更」をクリックします。

        結果の「イメージの変更」パネルには、使用可能なExadataイメージのメジャー・バージョン(23.1.3.0および22.1.3.0)のリストが表示されます。

        各メジャー・バージョンの最新リリースは、"(latest)で示されます。

      • スライド「使用可能なすべてのバージョンの表示」。

        最新バージョンのExadataイメージ23.1.3.0および22.1.3.0を含む6つの過去のバージョンが表示されます。

      • バージョンの選択
      • 「変更の保存」をクリックします。
  9. VMクラスタを構成します: 新しいVMクラスタに使用するDBサーバーを指定します(デフォルトでは、すべてのDBサーバーが選択されています)。 「DBサーバーの変更」をクリックして、使用可能なDBサーバーから選択します。 「VMごとのリソース割当て」ペインで:
    • X11M Exadataインフラストラクチャで作成されるVMクラスタについて、各VMクラスタの仮想マシン・コンピュート・ノードに割り当てるOCPUコアの数を指定します。これはECPUです。 最小は、VM当たり2 OCPU、またはX11M Exadataインフラストラクチャで作成されたVMクラスタに対して8 ECPUです。 読取り専用「Exadata VMクラスタのリクエストされたOCPU数」フィールドには、割り当てているOCPUコアの合計数が表示されます。
    • 各VMに割り当てる「VM当たりのメモリー」を指定します。 VM当たりの最小値は30 GBです。
    • ローカル・ストレージを各VMに割り当てるには、「VMごとのローカル・ストレージ」を指定します。 VM当たりの最小値は60 GBです。

      新しいVMクラスタを作成するたびに、使用可能な合計領域のうち残りの領域が新しいVMクラスタに使用されます。

      /u02に加えて、追加のローカル・ファイル・システムのサイズを指定できます。

      個々のVMのサイズを指定する方法の詳細は、「スケール・アップまたはスケール・ダウン操作の概要」を参照してください。

      • 「追加のローカル・ファイル・システム構成オプションを表示」をクリックします。
      • 必要に応じて、/, /u01, /tmp, /var, /var/log, /var/log/auditおよび/homeファイル・システムのサイズを指定します。

        ノート:

        • これらのファイル・システムは拡張のみ可能で、拡張後にサイズを減らすことはできません。
        • バックアップ・パーティションおよびミラー化により、/および/varファイル・システムは、割り当てられた領域の2倍を消費します。これは、読取り専用「ミラー化による / (GB)の割当て済ストレージの合計」および「ミラー化による/tmp (GB)の割当て済ストレージの合計」フィールドに示されています。
      • VMクラスタの作成後、「Exadata Infrastructure詳細」ページの「Exadataリソース」セクションをチェックして、ローカル・ストレージ(/u02)およびローカル・ストレージ(追加のファイル・システム)に割り当てられているファイル・サイズを確認します。
  10. Exadataストレージの構成: 次のように指定します:
    • 「使用可能なExadataストレージTBの指定」。 ストレージは1 TBの倍数で指定します。 最小: 2 TB
    • Exadataスパース・スナップショットのストレージの割当: VMクラスタ内でスナップショット機能を使用する場合は、この構成オプションを選択します。 このオプションを選択すると、PDBスパース・クローニングにVMクラスタ・スナップショット機能を使用できるように、SPARSEディスク・グループが作成されます。 このオプションを選択すると、SPARSEディスク・グループが作成されず、環境に作成されたどのデータベース・デプロイメントでもスナップショット機能を使用できません。

      ノート:

      スパース・スナップショットのストレージ構成オプションは、VMクラスタの作成後に変更できません。
    • ローカル・バックアップ用にストレージを割り当てます: Exadataクラウド・インフラストラクチャインスタンス内のローカルExadataストレージへのデータベース・バックアップを実行する場合は、このオプションを選択します。 このオプションを選択すると、Exadataストレージにバックアップを格納するために使用されるRECOディスク・グループにより多くの領域が割り当てられます。 このオプションを選択しない場合、DATAディスク・グループにより多くの領域が割り当てられるため、データベースにさらに多くの情報を格納できます。

      ノート:

      ローカル・バックアップのストレージ構成オプションは、VMクラスタの作成後に変更できません。
  11. SSHキーを追加します: DBシステムへのSSHアクセスに使用する各キー・ペアの公開キー部分を追加します:
    • 「SSHキー・ペアの生成」 (デフォルト・オプション) SSHキー・ペアを生成するには、このラジオ・ボタンを選択します。 次に、下のダイアログで「秘密キーを保存」をクリックしてキーをダウンロードし、オプションで「公開キーの保存」をクリックしてキーをダウンロードします。
    • SSHキー・ファイルのアップロード: .pubファイルを参照またはドラッグ・アンド・ドロップするには、このラジオ・ボタンを選択します。
    • SSHキーの貼付け: 個々の公開キーに貼り付けるには、このラジオ・ボタンを選択します。 複数のキーを貼り付けるには、「+別のSSHキー」をクリックし、エントリごとに1つのキーを指定します。

  12. ネットワーク設定の構成: 次のように指定します:

    ノート:

    IPアドレス(100.64.0.0/10)は、Exadata Cloud Infrastructure X8Mインターコネクトに使用されます。
    • 仮想クラウド・ネットワーク: VMクラスタを作成するVCN。 「コンパートメントの変更」をクリックして、別のコンパートメントのVCNを選択します。
    • クライアント・サブネット: VMクラスタがアタッチする必要のあるサブネット。 「コンパートメントの変更」をクリックして、別のコンパートメントのサブネットを選択します。

      192.168.16.16/28と重複するサブネットは使用しないでください。これはデータベース・インスタンス上のOracle Clusterwareプライベート・インターコネクトによって使用されています。 重複しているサブネットを指定すると、プライベート・インターコネクトが正しく動作しません。

    • バックアップ・サブネット: バックアップ・ネットワークに使用するサブネット。通常は、バックアップの保存先との間のバックアップ情報の転送、およびData Guardレプリケーションに使用されます。 「コンパートメントの変更」をクリックして、別のコンパートメントのサブネットを選択します(該当する場合)。

      192.168.128.0/20とオーバーラップするサブネットは使用しないでください。 この制限は、クライアント・サブネットとバックアップ・サブネットの両方に適用されます。

      データベースをObject StorageまたはAutonomous Recoveryサービスにバックアップする場合は、「Exadataデータベースのバックアップの管理」のネットワークの前提条件を参照してください。

      ノート:

      自律型リカバリ・サービスを使用する場合は、新しい専用サブネットを強くお薦めします。 Oracle Cloudデータベースをリカバリ・サービスにバックアップするために必要なネットワーク要件および構成を確認します。 「リカバリ・サービスのネットワーク・リソースの構成」を参照してください。

    • ネットワーク・セキュリティ・グループ: オプションで、クライアント・ネットワークとバックアップ・ネットワークの両方に1つ以上のネットワーク・セキュリティ・グループ(NSG)を指定できます。 NSGは仮想ファイアウォールとして機能し、イングレスおよびエグレス「セキュリティ・ルール」のセットを「Exadataクラウド・インフラストラクチャ」 VMクラスタに適用できます。 NSGは5つまで指定できます。 詳細は、「ネットワーク・セキュリティ・グループ」および「Exadataクラウド・インフラストラクチャ」インスタンスのネットワーク設定を参照してください。

      「セキュリティ・リスト」を持つサブネットを選択すると、VMクラスタのセキュリティ・ルールは、セキュリティ・リストおよびNSG内のルールの結合になります。

      ネットワーク・セキュリティ・グループを使用するには:

      • 「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」チェック・ボックスを選択します。 このボックスは、クライアント・サブネットとバックアップ・サブネットの両方のセレクタの下に表示されます。 NSGは、クライアントまたはバックアップ・ネットワーク、あるいは両方のネットワークに適用できます。 NSGをネットワークに割り当てるには、仮想クラウド・ネットワークを選択する必要があります。
      • ネットワークで使用するNSGを指定します。 複数のNSGを使用する必要がある場合があります。 不明な場合は、ネットワーク管理者に問い合わせてください。
      • ネットワークで追加のNSGを使用するには、「+;別のネットワーク・セキュリティ・グループ」をクリックします。

      ノート:

      クラウドVMクラスタ・リソースに追加のセキュリティを提供するには、Oracle Cloud Infrastructure Zero Trust Packet Routingを使用して、セキュリティ属性で識別されたリソースのみがリソースにアクセスするためのネットワーク権限を持っていることを確認できます。 Oracleには、一般的なデータベース・セキュリティ・ユース・ケースのポリシーの作成に役立つデータベース・ポリシー・テンプレートが用意されています。 今すぐ構成するには、Oracle Cloud Infrastructure Zero Trust Packet Routingを使用してセキュリティ属性をすでに作成している必要があります。 このプロシージャの最後にある「高度なオプションを表示」をクリックします。

      クラスタのセキュリティ属性を指定する場合、クラスタが適用されるとすぐに、すべてのリソースがクラスタにアクセスするためにゼロ・トラスト・パケット・ポリシーを必要とすることに注意してください。 エンドポイントにセキュリティ属性がある場合は、ネットワーク・セキュリティ・グループ(NSG)とOracle Cloud Infrastructure Zero Trust Packet Routingポリシー(OCI ZPR)の両方のルールを満たす必要があります。

    • プライベートDNSサービスを使用するには

      ノート:

      プライベートDNSは、選択する前に構成する必要があります。 「プライベートDNSの構成」を参照してください
      • 「プライベートDNSサービスの使用」チェック・ボックスを選択します。
      • プライベート・ビューを選択します。 別のコンパートメントのプライベート・ビューを選択するには、「コンパートメントの変更」をクリックします。
      • プライベート・ゾーンを選択します。 別のコンパートメントのプライベート・ゾーンを選択するには、「コンパートメントの変更」をクリックします。
    • ホスト名プレフィクス: Exadata DBシステムのホスト名の選択。 ホスト名は英字で始める必要があり、英数字とハイフン(-)のみを使用できます。 Exadata DBシステムで許可される最大文字数は12です。

      注意:

      ホスト名はサブネット内で一意である必要があります。 一意でない場合、VMクラスタはプロビジョニングに失敗します。
    • ホスト・ドメイン名: VMクラスタのドメイン名。 選択したサブネットで、DNS名解決にOracle-供給インターネットおよびVCNリゾルバを使用している場合、このフィールドにはサブネットのドメイン名が表示され、変更できません。 それ以外の場合は、ドメイン名を選択できます。 ハイフン(-)は使用できません。

      データベース・バックアップをObject StorageまたはAutonomous Recoveryサービスに格納する場合、Oracleでは、バックアップに使用されるSwiftエンドポイントが自動的に解決されるため、クライアント・サブネットのDNS名前解決にVCN Resolverを使用することをお薦めします。

    • ホストおよびドメインURL: この読取り専用フィールドには、ホスト名とドメイン名が結合され、データベースの完全修飾ドメイン名(FQDN)が表示されます。 最大の長さは、63文字です。
  13. ライセンス・タイプの選択: VMクラスタに使用するライセンスのタイプ。 選択は請求の測定に影響します。
    • 「含まれるライセンス」は、cloud serviceのコストにデータベース・サービスのライセンスが含まれていることを意味します。
    • ライセンス持込み (BYOL)は、ユーザーが無制限ライセンス契約または無制限ライセンス契約を持つOracle Databaseの顧客で、Oracle Cloud Infrastructureでライセンスを使用することを意味します。 これにより、個別のオンプレミス・ライセンスおよびクラウド・ライセンスの必要性が削除されます。
  14. 診断収集: 診断収集および通知を有効にすることで、Oracle Cloud操作により、ゲストVMの問題を迅速かつ効果的に識別、調査、追跡および解決できます。 イベントをサブスクライブして、リソース状態の変更に関する通知を取得します。

    ノート:

    前述のイベント(またはメトリック、ログ・ファイル)のリストが将来変更される可能性があることを理解することに反対しています。 この機能はいつでもオプトアウトできます。
    • 診断イベントの有効化: Oracleがクリティカル・イベント、警告イベント、エラー・イベントおよび情報イベントを収集して公開することを許可します。
    • ヘルス・モニタリングの有効化: Oracleがヘルス・メトリック/イベント(Oracle Database up/down、ディスク領域使用量など)を収集し、それらをOracle Cloud操作と共有できるようにします。 一部のイベントの通知も受信します。
    • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

    ノート:

    前述のイベント(またはメトリック、ログ・ファイル)のリストが将来変更される可能性があることを理解することに反対しています。 この機能はいつでもオプトアウトできます。
    デフォルトでは、3つのチェック・ボックスがすべて選択されています。 デフォルト設定をそのままにすることも、必要に応じてチェックボックスをクリアすることもできます。 診断収集の設定は、「VMクラスタ詳細」ページの「一般情報>>診断収集」の下に表示されます。
    • 有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(3つのオプションすべて)。
    • 無効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集しないことを選択した場合(3つすべてのオプション)。
    • 一部使用可能: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイル(1つまたは2つのオプション)を収集することを選択した場合。
  15. 「高度なオプションを表示」をクリックして、VMクラスタの詳細オプションを指定します:

    • タイムゾーン: このオプションは、管理タブにあります。 DBシステムのデフォルト・タイム・ゾーンはUTCですが、別のタイム・ゾーンを指定できます。 タイムゾーン・オプションは、両方のJava.util.TimeZoneクラスおよびOracle Linuxオペレーティング・システムでサポートされているオプションです。 詳細は、「DB Systemのタイムゾーン」」を参照してください。

      ノート:

      UTCまたはブラウザが検出したタイム・ゾーン以外のタイム・ゾーンを設定する場合、必要なタイム・ゾーンが表示されない場合は、「別のタイムゾーンの選択」オプションを選択し、「リージョンまたは国」リストで「その他」を選択して追加の「タイムゾーン」選択を検索してみてください。

    • SCANリスナー・ポート: このオプションは、ネットワークタブにあります。 SCANリスナー・ポート(TCP/IP)は、1024から8999の範囲で割り当てることができます。 デフォルトは、1521です

      ノート:

      バックエンド・ソフトウェアを使用したプロビジョニング後のVMクラスタのSCANリスナー・ポートの手動変更はサポートされていません。 この変更により、Data Guardのプロビジョニングが失敗する可能性があります。
      .
    • Zero Trust Packet Routing (ZPR): このオプションは、セキュリティ属性タブにあります。 ネームスペースを選択し、セキュリティ属性のキーと値を指定します。 構成中にこのステップを完了するには、Oracle Cloud Infrastructure Zero Trust Packet Routingを使用してセキュリティ属性をすでに設定しておく必要があります。 構成後にセキュリティ属性を追加し、後で追加することもできます。 Oracle Exadata Database Service on Dedicated Infrastructure固有のポリシーの追加の詳細は、「ポリシーTemplate Builder」を参照してください。
    • タグ: リソースを作成する権限がある場合は、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
  16. 「Exadata VMクラスタの作成」をクリックします。

次は?

VMクラスタが正常に作成され、使用可能状態になったら、クラスタのリストでVMクラスタの名前をクリックして、「VMクラスタ詳細」ページを表示できます。 「VMクラスタ詳細」ページで、「データベースの作成」をクリックしてクラスタ内の「最初のデータベースの作成」を実行できます。

関連トピック

親トピック: コンソールを使用したインフラストラクチャ・リソースの作成

リカバリ・サービスのネットワーク・リソースの構成

リカバリ・サービス操作には、データベースVCN内の既存のIP4のみのサブネットを使用します。 データベースとリカバリ・サービス間のバックアップ・トラフィックを制御するセキュリティ・ルールを定義します。 最後に、プライベート・サブネットをリカバリ・サービス・サブネットとして登録します。

親トピック: コンソールを使用したインフラストラクチャ・リソースの作成

リカバリ・サービスへのプライベート・サブネットの使用について

Recovery Serviceでは、データベースが存在する仮想クラウド・ネットワーク(VCN)内のプライベート・サブネットが使用されます。 プライベート・サブネットは、データベースとリカバリ・サービス間のバックアップのネットワーク・パスを定義します。

Oracleでは、データベースVCNに、リカバリ・サービスへのバックアップ専用の単一のプライベート・サブネットが必要です。 Oracle Cloudデータベースは、リカバリ・サービスで使用されるものと同じプライベート・サブネット、または同じVCN内の別のサブネットに配置できます。

プライベート・サブネットを作成することも、データベースVCN内の既存のサブネットを使用することもできます。 Oracleでは、 /24 (256 IPアドレス)のサブネット・サイズを使用することをお薦めします。

ノート:

データベースVCNのリカバリ・サービス用のIPv4のみのサブネットを選択します。 リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。 詳細は、「サブネットの作成」を参照してください。

データベースVCNでは、データベースとリカバリ・サービス間のバックアップ・トラフィックを許可するセキュリティ・ルールが必要です。 セキュリティ・ルールには、宛先ポート8005および2484を許可するステートフル・イングレス・ルールを含める必要があります。 次のネットワーキング・サービス機能を使用して、セキュリティ・ルールを実装できます:

  • セキュリティ・リスト

    セキュリティ・リストを使用すると、サブネット・レベルでセキュリティ・ルールを追加できます。 データベースVCNで、リカバリ・サービス・サブネットに使用されるセキュリティ・リストを選択し、イングレス・ルールを追加して宛先ポート8005および2484を許可します。

  • 「ネットワーク・セキュリティ・グループ(NSG)」ネットワーク・セキュリティ・グループ(NSG)を使用すると、VCN内の個々のVNICに適用されるセキュリティ・ルールをきめ細かく制御できます。 リカバリ・サービスでは、NSGを使用してセキュリティ・ルールを構成する次のオプションがサポートされています:
    • ネットワーク分離を実装するには、データベースVNICに1つのNSG (ポート2484および8005を許可するためのエグレス・ルールの追加)とリカバリ・サービス用の個別のNSG (ポート2484および8005を許可するイングレス・ルールの追加)を作成します。
    • データベースVNICおよびリカバリ・サービスに対して単一のNSG (エグレスおよびイングレス・ルールを含む)を作成および使用します。

ノート:

データベースVCN内にセキュリティ・リストおよびNSGを構成した場合、NSGで定義されたルールはセキュリティ・リストで定義されたルールよりも優先されます。

詳細は、「セキュリティ・リストとネットワーク・セキュリティ・グループの比較」を参照してください。

データベースVCNにプライベート・サブネットを作成した後、セキュリティ・ルールを割り当て、そのサブネットをリカバリ・サービス・サブネットとして登録します。 セキュリティ・ルールを実装するためにNSGを作成した場合は、リカバリ・サービスNSGをリカバリ・サービス・サブネットに関連付けることも確認する必要があります。

ノート:

Oracleでは、バックアップにプライベート・サブネットを使用することをお薦めします。 ただし、パブリック・サブネットを使用することは可能です。

サブネットを構成するためのネットワーキング・サービス権限の確認

データベースVCNにサブネットを作成し、リカバリ・サービスのセキュリティ・ルールを割り当てるには、次のネットワーキング・サービス権限が必要です。

表4-6 プライベート・サブネットの作成およびリカバリ・サービスのセキュリティ・ルールの構成に必要なネットワーキング・サービス権限

操作 必要なIAMポリシー

データベースVCNでのプライベート・サブネットの構成
  • VCNが存在するコンパートメントの場合はuse vcns
  • VCNが存在するコンパートメントの場合はuse subnets
  • VCNが存在するコンパートメントの場合はmanage private-ips
  • VCNが存在するコンパートメントの場合はmanage vnics
  • データベースがプロビジョニングされている、またはプロビジョニングされるコンパートメントのmanage vnics

または、ネットワーク・コンポーネントへのより広範なアクセス権を持つ指定されたグループを許可するポリシーを作成できます。

たとえば、このポリシーを使用して、NetworkAdminグループがテナンシ内の任意のコンパートメント内のすべてのネットワークを管理できるようにします。

例4-1 ネットワーク管理者のポリシー

Allow group NetworkAdmin to manage virtual-network-family in tenancy

リカバリ・サービス・サブネットのサブネット・サイズ要件およびセキュリティ・ルールの確認

セキュリティ・ルールは、データベースとリカバリ・サービス間のバックアップ・トラフィックを許可するために必要です。

ノート:

データベースVCNのリカバリ・サービス用のIPv4のみのサブネットを選択します。 リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。 詳細は、「サブネットの作成」を参照してください。

表4-7 リカバリ・サービスで使用されるプライベート・サブネットのサブネット・サイズ要件およびイングレス・ルール

項目 要件

最小サブネット・サイズ

/24 (256 IPアドレス)

一般イングレス・ルール1: AnywhereからのHTTPSトラフィックを許可

このルールでは、Oracle Cloud Infrastructure Databaseからリカバリ・サービスへのバックアップ・トラフィックを許可します。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: データベースが存在するVCNのCIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 8005

一般イングレス・ルール2: 任意の場所からのSQLNetトラフィックを許可

このルールにより、リカバリ・カタログ接続およびOracle Cloud Infrastructure Databaseからリカバリ・サービスへのリアルタイム・データ保護が可能になります。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: データベースが存在するVCNのCIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 2484

ノート:

ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、またはデータベースVCNがサブネット間のネットワーク・トラフィックを制限する場合は、データベースNSGまたはサブネットから作成したリカバリ・サービスNSGまたはサブネットに、ポート2484および8005のエグレス・ルールを必ず追加してください。

OCIコンソールを使用して、データベース仮想クラウド・ネットワーク(VCN)のリカバリ・サービスのプライベート・サブネットを構成します。

  1. ナビゲーション・メニューで、「ネットワーク」を選択し、「仮想クラウド・ネットワーク」を選択して「仮想クラウド・ネットワーク」ページを表示します。
  2. データベースが存在するVCNを選択します。
  3. 次のステップを使用して、セキュリティ・リストを含むリカバリ・サービス・サブネットを作成します。 ネットワーク・セキュリティ・グループを使用する場合は、「ステップ4」に進みます。
    1. 「リソース」の下で、「セキュリティ・リスト」を選択します。
    2. VCNに使用されるセキュリティ・リストを選択します。宛先ポート8005および2484を許可するには、2つのイングレス・ルールを追加する必要があります。
    3. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのHTTPSトラフィックを許可するステートフル・イングレス・ルールを設定します:
      • ソース・タイプ: CIDR
      • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
      • IPプロトコル: TCP
      • ソース・ポート範囲: All
      • 宛先ポート範囲: 8005
      • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。
    4. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するステートフル・イングレス・ルールを設定します:
      • ソース・タイプ: CIDR
      • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
      • IPプロトコル: TCP。
      • ソース・ポート範囲: All
      • 宛先ポート範囲: 2484
      • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールのオプションの説明を指定します。

      ノート:

      データベースVCNのリカバリ・サービス用のIPv4のみのサブネットを選択します。 リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。 more.Seeについて学習するには、サブネットの作成を参照してください: 詳細は、リカバリ・サービス・サブネットのサブネット・サイズ要件およびセキュリティ・ルールの確認を参照してください。

    5. 「Virtual Cloud Networksの詳細」ページで、「サブネットの作成」をクリックします。
    6. プライベート・サブネットを作成するか、データベースVCNにすでに存在するプライベート・サブネットを選択します。 Oracleでは、プライベート・サブネットのサブネット・サイズを /24 (256 IPアドレス)にすることをお薦めします。

    7. 「サブネットの詳細」ページの「リソース」で、「セキュリティ・リスト」を選択します。 宛先ポート8005および2484を許可するイングレス・ルールを含むセキュリティ・リストを追加します。

      ノート:

      データベースVCNがサブネット間のネットワーク・トラフィックを制限する場合は、必ず、データベース・サブネットから作成したリカバリ・サービス・サブネットにポート2484および8005のエグレス・ルールを追加してください。
  4. 次のステップを使用して、ネットワーク・セキュリティ・グループ(NSG)を含むリカバリ・サービス・サブネットを作成します。
    1. 「リソース」の下で、「ネットワーク・セキュリティ・グループ」を選択します。
    2. 「ネットワーク・セキュリティ・グループの作成」をクリックします。次のいずれかのサポートされているメソッドを使用して、NSGを使用してセキュリティ・ルールを構成します:
      • ネットワーク分離を実装するには、データベースVNICに1つのNSG (ポート2484および8005を許可するためのエグレス・ルールの追加)とリカバリ・サービス用の個別のNSG (ポート2484および8005を許可するイングレス・ルールの追加)を作成します。
      • データベースVNICおよびリカバリ・サービスに対して単一のNSG (エグレスおよびイングレス・ルールを含む)を作成および使用します。
      「ネットワーク・セキュリティ・グループ」ページには、作成するNSGがリストされます。

    ノート:

    追加の構成の詳細は、関連するOCI Database Serviceのドキュメントを参照してください。
  5. データベースVCNにリカバリ・サービス・サブネットを作成した後、サブネットをリカバリ・サービス・サブネットとして登録します。 Oracleでは、NSGを使用してセキュリティ・ルールを実装したVCN.Ifごとに1つのリカバリ・サービス・サブネットを登録してから、リカバリ・サービスNSGをリカバリ・サービス・サブネットに追加することも確認する必要があります。
リカバリ・サービス・サブネットの登録

データベースVCNでリカバリ・サービスのプライベート・サブネットを作成した後、この手順を使用して、リカバリ・サービスにサブネットを登録します。

複数の保護されたデータベースで、同じリカバリ・サービス・サブネットを使用できます。 リカバリ・サービス・プライベート・エンドポイントをサポートするために必要な数のIPアドレスが使用可能であることを確認するために、複数の保護されたデータベースで使用されるリカバリ・サービス・サブネットに複数のサブネットを割り当てることができます。

ノート:

データベースVCNのリカバリ・サービス用のIPv4のみのサブネットを選択します。 リカバリ・サービスでは、次の前提条件の構成タスクを完了したIPv6対応のsubnet.Ensureの使用がサポートされていないため、IPv6対応サブネットを選択しないでください:
  1. OCIテナンシにログインします。
  2. ナビゲーション・メニューで、Oracle Databaseをクリックし、「データベース・バックアップ」を選択して「データベース・バックアップ」ページを表示します。
  3. 「リカバリ・サービス・サブネット」をクリックします。
  4. 「コンパートメント」フィールドで、リカバリ・サービス・サブネットを作成するコンパートメントを選択します。
  5. 「リカバリ・サービス・サブネットの登録」をクリックし、詳細を指定します。
  6. 「名前」フィールドに、リカバリ・サービス・サブネットの名前を入力します。
  7. 「コンパートメント」フィールドで、リカバリ・サービス・サブネットを作成するコンパートメントを選択します。
  8. 「仮想クラウド・ネットワーク」フィールドで、データベースVCN.Click 「コンパートメントの変更」を選択して、別のコンパートメントに属するVCNを選択します。
  9. 「サブネット」フィールドで、データベースのリカバリ・サービス操作用に構成したプライベート・サブネット(VCN.Click 「コンパートメントの変更」)を選択し、別のコンパートメントからプライベート・サブネットを選択します。
  10. (オプション)「+他のサブネット」をクリックして、リカバリ・サービスsubnet.Ifに追加のサブネットを割り当てます。単一のサブネットには、リカバリ・サービス・プライベート・エンドポイントをサポートするための十分なIPアドレスが含まれていないため、複数のサブネットを割り当てることができます。
  11. 「詳細オプションの表示」をクリックして、これらの追加機能を構成します。
    • ネットワーク・セキュリティ・グループ
    • タグ

    ネットワーク・セキュリティ・グループ(NSG)を使用してデータベースVCNのリカバリ・サービスのセキュリティ・ルールを実装した場合は、リカバリ・サービスNSGをリカバリ・サービス・サブネットに追加する必要があります。 リカバリ・サービスNSGは、同じコンパートメントまたは別のコンパートメントに配置できます。 ただし、NSGは、指定したサブネットが属するVCNと同じVCNに属している必要があります。

    1. 「ネットワーク・セキュリティ・グループ」セクションで、「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」を選択します。
    2. データベースVCNに作成したリカバリ・サービスNSGを選択します。
    3. 「+他のネットワーク・セキュリティ・グループ」をクリックして、複数のNSGを関連付けます(最大5つ)。
    (オプション) 「タグ名スペース」フィールドで、タグ・ネームスペースの追加、または既存のタグ・ネームスペースによるコントロールのタグ付けを検討します。
  12. 「登録」をクリックします。

    サブネットを置き換えたり、さらにサブネットを追加して必要な数のプライベート・エンドポイントをサポートできます。

  13. 既存のリカバリ・サービス・サブネットを更新するには、次のステップを使用します:
    1. リカバリ・サービス・サブネットの詳細ページの「リソース」で、「サブネット」をクリックします。
    2. 「サブネットの追加」をクリックし、追加するサブネットを選択します。
    3. 既存のサブネットを置き換えるには、「アクション」メニューをクリックし、「サブネットの削除」を選択します。 その後、別のサブネットを追加できます。

    ノート:

    リカバリ・サービス・サブネットは、データベースVCNに属する少なくとも1つのサブネットに関連付けられている必要があります。
  14. 既存のリカバリ・サービス・サブネットのネットワーク・セキュリティ・グループ(NSG)を管理するには、次のステップを使用します:
    1. 「ネットワーク・セキュリティ・グループ」セクションで、「ネットワーク・セキュリティ・グループの追加」をクリックします。
    2. リカバリ・サービスのネットワーク・セキュリティ・グループを選択して追加します(最大5つ)。
    3. NSGを削除するには、リソースを選択して「削除」をクリックします。

自律型リカバリ・サービスのチェックリスト

親トピック: コンソールを使用したインフラストラクチャ・リソースの作成

リカバリ・サービス・サブネットがOracle Servicesと通信できることの確認

登録したリカバリ・サービス・サブネットは、リカバリ・サービスと通信する必要があります。

サービスにアクセスするには、プライベート・サブネットのルーティング表に"Oracle Services NetworkのすべてのIADサービス"を含める必要があります。

詳細は、「Oracle Servicesへのプライベート・アクセス」を参照してください。

データベースにTDEが完全に構成されていることの確認

Autonomous Recovery Serviceを使用する場合、データベースを完全にTDE暗号化する必要があります。

クラウドに生まれた新しいデータベースの場合、これはすでに完了している必要があります。 ただし、OCIでスタブ・データベースを作成し、オンプレミスまたは他の場所からOracle Databaseサービスにデータベースを移行する場合、すべての基準を満たすとはかぎりません。 これらのデータベースでは、リカバリ・サービスへのバックアップの前提条件を満たしていることを確認する必要があります。 私はここで見つけることができるブログ投稿を持っています問合せで実行するために何をチェックすべきかを概説します。

次の3つの基準を満たす必要があります:
  • データベースでWALLET_ROOTを構成する必要があります。 まだsqlnet.oraを使用している場合は、dbaascliを使用して、リカバリ・サービスを使用するすべてのデータベースにWALLET_ROOTを正しく設定する必要があります。
    既存のデータベースに対してwallet_root SPFILEパラメータを有効にするには、次を実行します:
    dbaascli tde enableWalletRoot

    詳細は、dbaascli tde enableWalletRootを参照してください。

    ノート:

    sqlnet.oraでのENCRYPTION_WALLET_LOCATIONの設定はサポートされていないため、非推奨になります。
  • CDBおよびデータベース内のすべてのPDBに暗号化キーを設定する必要があります。
  • 最初のバックアップを実行する前に、すべての表領域をTDE暗号化する必要があります。
手動操作バックアップをオフにします

場合によっては、OCIユーザーが手動の操作バックアップを実行します。 これらのバックアップは、標準ツールの外部で実行され、Point-in-Timeリカバリ (非KEEPバックアップ)をサポートします。

これらのタイプの操作バックアップを実行している場合は、この時点でオフにすることが重要です。 2つの異なるロケーションに操作バックアップを実行すると、両方のバックアップで問題が発生する可能性があります。

ノート:

オブジェクト・ストレージのバックアップにツールを使用し、リカバリ・サービスに切り替えると、ツールによってスイッチオーバーが自動化され、以前のすべてのバックアップが使用可能なままになります。