機械翻訳について

Exadataフリート更新メンテナンス・サイクル

Exadataフリート更新メンテナンス・サイクルの作成および管理について学習します。

• メンテナンス・サイクルの作成
  特定のコレクションについて、完全アップグレードまたは特定のターゲット・バージョンへの完全更新イベントを表すメンテナンス・サイクルを作成します。
• メンテナンス・サイクルのリストの表示
  すべての回収のすべてのメンテナンス・サイクルのリストを表示できます。
• メンテナンス・サイクルの編集
  メンテナンス・サイクルを編集するには、メンテナンス・サイクルの編集に必要なフィールドに値を指定する準備をします。
• メンテナンス・サイクルの削除
  削除したメンテナンス・サイクルはリカバリできません。

メンテナンス・サイクルの作成

特定のコレクションについて、完全アップグレードまたは特定のターゲット・バージョンへの完全更新イベントを表すメンテナンス・サイクルを作成します。

ノート:

最近公開したバージョンから以前に公開したバージョンへのアップグレード

重要: 適切なターゲット・バージョンを選択して、既知のセキュリティ脆弱性に身をさらさないようにしてください。

Oracleは、四半期ごとにクリティカル・パッチ・アップデート(CPU)をリリースします。 これらの更新には、Oracle DatabaseおよびGrid Infrastructureコンポーネントのセキュリティ修正が含まれており、リリース更新(RU)として提供されます。 RUは、OracleコードとOracle製品にバンドルされているサードパーティ・コンポーネントの両方の脆弱性に対処します。

RUは、複数のOracle DatabaseおよびGrid Infrastructureバージョンに対して四半期ごとにリリースされるため、アップグレード元のソース・バージョンが、リリース日に関してターゲット・バージョンより新しいものではないことを強くお薦めします。 より新しいバージョンから古いバージョンにアップグレードすると、重要なセキュリティ修正が失われる可能性があります。

例

• Oracle Database 19.27は2025年4月にリリースされました
• Oracle Database 23.7は2025年1月にリリースされました

19.27から23.7にアップグレードすると、以前の23.7リリースに存在しない可能性がある19.27に含まれるセキュリティ更新がバイパスされ、システムが既知の脆弱性にさらされます。

• アップグレード・メンテナンス・サイクルの作成
  特定のコレクションについて、特定のターゲット・バージョンへの完全なアップグレード・イベントを表すメンテナンス・サイクルを作成します。 各収集には、1つ以上のメンテナンス・サイクルを含めることができますが、一度にアクティブにできるメンテナンス・サイクルは1つのみです。
• 更新メンテナンス・サイクルの作成
  特定のコレクションについて、特定のターゲット・バージョンへの完全更新イベントを表すメンテナンス・サイクルを作成します。 各収集には、ゼロ個以上のメンテナンス・サイクルを含めることができますが、一度にアクティブにできるメンテナンス・サイクルは1つのみです。
• 一度に1つのバッチを有効化
  50/50(ローリング)メンテナンス・メソッドを選択すると、追加のチェック・ボックスが表示されます。一度に1つのバッチを有効にして、一度に1つのバッチに更新を適用できます。

アップグレード・メンテナンス・サイクルの作成

特定のコレクションについて、特定のターゲット・バージョンへの完全なアップグレード・イベントを表すメンテナンス・サイクルを作成します。 各収集には、1つ以上のメンテナンス・サイクルを含めることができますが、一度にアクティブにできるメンテナンス・サイクルは1つのみです。

26aiへのアップグレードの前提条件: Oracle AI Database 26aiには、Oracle Grid Infrastructure (GI) 26aiが必要です。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 編集するコレクションの名前をクリックします。

   「コレクションの詳細」ページが表示されます。

3. 「リソース」の下で、「メンテナンス・サイクル」をクリックします。
4. 「メンテナンス・サイクルの作成」をクリックします。

   「メンテナンス・サイクルの作成」ページが表示されます。

5. 「メンテナンス・サイクルの作成」ページで、リクエストされた情報を入力します:
   • メンテナンス・サイクル名: わかりやすい名前を入力します。
   • 使用可能な選択肢は、コレクション・タイプ(データベースまたはGrid Infrastructure)によって異なります。
     • データベース:
       • ターゲット・データベースのイメージ: デフォルトは、最新のOracle提供のイメージです。 「データベース・イメージの変更」をクリックして、26aiターゲット・データベース・イメージを選択します。
         • Oracle提供のデータベース・ソフトウェア・イメージ: これらのイメージには、一般に使用可能なバージョンのOracle Databaseソフトウェアが含まれています。
         • カスタム・データベース・ソフトウェア・イメージ: これらのイメージは組織によって作成され、ソフトウェア更新およびパッチのカスタマイズされた構成が含まれます。
           • 「コンパートメント」を選択します。
           • 「リージョン」を選択します。

             リージョン・フィルタは、デフォルトで現在接続されているリージョンに設定され、そのリージョンで作成されたすべてのソフトウェア・イメージがリストされます。 別のリージョンを選択すると、選択したリージョンで作成されたソフトウェア・イメージが表示されるように、ソフトウェア・イメージ・リストがリフレッシュされます。

       • データベース・ホーム:ソフトウェアのアップグレードの一環として、データベースは26aiターゲット・イメージ・バージョンの新しいホームに移動されます。 新しい26aiバージョンのデータベース・ホームは、メンテナンス・サイクル中に作成するか、既存のホームがVMクラスタにすでに存在する場合は再利用できます。
         • 新規ホームの作成: 新しいホームを作成する場合、コレクション内のデータベースは同様の構造を維持します。 ソフトウェア更新前の共有ホーム(他のデータベースと共有)内のデータベースは、更新の一部として共有ホームに移動されます。 ソフトウェア更新の前に共有ホームにないデータベースは、更新の一部として別のホームに移動されます。
         • 使用可能な場合は既存のホームを使用します: 既存のホームを使用すると、同じVMクラスタ内のすべてのデータベース・ターゲットが共有データベース・ホームに移動されます。 選択したイメージの既存のホームがターゲット・データベースのVMクラスタに見つからない場合は、新しいホームが作成されます。 選択したイメージの複数の既存のホームが見つかった場合は、データベース数が最も少ないホームが使用されます。 複数のホームにデータベース数が最も少ない場合、ホームはランダムに選択されます。
         • データベース・ホームの表示名プレフィクス: メンテナンス・サイクルの一部として作成された新しいデータベース・ホームの表示名。 一意にするために、データベース・ホームの名前に序数が追加されます。
     • グリッド・インフラストラクチャ:
       • ターゲットGrid Infrastructureイメージ: デフォルトは、最新のOracle提供のイメージです。 「Grid Infrastructureの変更」イメージをクリックして、別のターゲットGrid Infrastructureイメージを選択します。
         • Oracle提供のGrid Infrastructureソフトウェア・イメージ: これらのイメージには、一般に使用可能なバージョンのOracle Grid Infrastructureソフトウェアが含まれています。
         • カスタムGrid Infrastructureソフトウェア・イメージ: これらのイメージは組織によって作成され、ソフトウェア更新およびパッチのカスタマイズされた構成が含まれます。 詳細は、「カスタムのOracle Grid Infrastructureソフトウェア・イメージの作成」を参照してください。
           • 「コンパートメント」を選択します。
           • 「リージョン」を選択します。

             リージョン・フィルタは、デフォルトで現在接続されているリージョンに設定され、そのリージョンで作成されたすべてのソフトウェア・イメージがリストされます。 別のリージョンを選択すると、選択したリージョンで作成されたソフトウェア・イメージが表示されるように、ソフトウェア・イメージ・リストがリフレッシュされます。

   • メンテナンス・メソッド: メンテナンス・メソッドでは、VMクラスタ内のVMのバッチ処理メソッド、およびソフトウェア更新の適用時に一緒にアップグレードされるノードを決定します。
     • 一度に1つのノード(ローリング): (デフォルト)データベース・インスタンスは、クラスタ内の1つのVMで同時に更新され、他のインスタンスは動作したままになります。
     • スマート・バッチ(ローリング): データベース・インスタンスは、一度に1つ以上のVMで更新されます。 VMは、構成されたデータベース・サービスに基づいてバッチされます。 これにより、必要なバッチの合計数を最小限に抑えながら、複数のノードにすべてのサービスを構成しているかぎり、すべてのサービスが使用可能になります。
     • 非ローリング: クラスタ内のすべてのVMのすべてのデータベース・インスタンスがパラレルに更新され、完全な停止時間が発生します。
     • 50/50 (rolling): VMの半分にあるデータベース・インスタンスは、1つのバッチで更新され、残りの半分は別のバッチで更新されます。 2つのバッチは、データベース・サービスの構成によって決まります。 これにより、すべてのサービスが使用可能になります。
       • 一度に1つのバッチを有効にします: このチェック・ボックスを選択すると、一度に1つのバッチに更新が適用されます。

         適用アクションでは、1つ目のバッチの更新を適用すると、2つ目のバッチを開始する前に、続行が待機されます。

   • ソフトウェアのステージング開始時間: オプションで、ソフトウェアのステージングの開始時間を設定します。
   • 更新開始時間を適用: オプションで、更新を適用するための開始時間を設定します。 適用更新開始時間は、ステージ・ソフトウェア開始時間の24時間以上後にする必要があります。

     ソフトウェアのステージング・アクションが完了するまで、更新の適用アクションは実行されません。

   • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

     ノート:

     この構成に対する変更は、メンテナンス・サイクルのすべてのアクションがスケジュールされた状態の場合にのみサポートされます。 メンテナンス・サイクルのアクションが開始されると、この設定を変更できません。
     推奨: この設定を有効にしておくと、Oracleで診断データを迅速に分析できるため、問題の解決が迅速になります。

     このサイクルおよび将来のイベントのすべてのターゲットに対して有効化: このサイクルおよび将来のイベントのすべてのターゲットの診断ログ収集を有効にします。 Oracleでは、トラブルシューティングが簡単で、より優れたサポートを実現するために、これを推奨しています。

     このサイクルのすべてのターゲットに対してのみ有効にします: 現在のメンテナンス・サイクルでのみ、すべてのターゲットの診断ログ収集を有効にします。 サイクルが終了すると、ログ収集設定はメンテナンス・サイクルの開始前に設定に戻ります。

     既存の診断ログ収集設定を使用します: ログ収集がすでに有効になっているターゲットのログのみを収集します。

     詳細は、次を参照してください。

     • 「Exadata Database Service on Cloud@Customer管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Exadata Database Service on Dedicated Infrastructure管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Database Service APIのドキュメント」の「DataCollectionOptionsリファレンス」。
   • 拡張オプション:
     • Grid Infrastructure (GI)収集アップグレードでは、アップグレード・オプションはサポートされていません。
     • データベース収集のアップグレードでは、次のオプションがサポートされています:
       • 無効なオブジェクトの再コンパイル: データベースのアップグレード中に無効なオブジェクトの再コンパイルを有効または無効にします。
       • タイムゾーンのアップグレード: タイムゾーンのアップグレードを有効または無効にします。

         ノート:

         タイムゾーン・アップグレードでは、アップグレード中に停止時間が長くなる可能性があります。
     • タグ: (オプション)タグの適用を選択できます。 リソースの作成権限がある場合、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用する必要があるかどうかわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
6. 「メンテナンス・サイクルの作成」をクリックします。

メンテナンス・サイクル・ライフサイクルの状態:

• メンテナンス・サイクルは、作成時に「アクティブ」状態になります。 属性の更新時に、必要に応じて「更新中」状態になる場合があります。
• アクションが実行されると、メンテナンス・サイクルは「メンテナンス中」状態になります。
• 失敗したジョブに失敗したアクションがあり、失敗したジョブを正常に完了するための後続のアクションがまだ実行されていない場合、メンテナンス・サイクルは「確認が必要」状態になります。
• 適用アクションが成功すると、メンテナンス・サイクルは「成功」状態に移行し、クリーンアップ・アクションが使用可能になります。

  クリーン・アップ処理は、メンテナンス・サイクルでのオプションの処理です。 メンテナンス・サイクルが正常に完了した後、クリーンアップ・アクションを実行して、メンテナンス・サイクルのソース・データベースおよびGrid Infrastructureホーム(コレクション内のデータベースおよびグリッド・インフラストラクチャ)を削除します。 すぐにクリーンアップまたはクリーンアップをスケジュールできます。

ノート:

メンテナンス・サイクルがすでに存在する場合に別のメンテナンス・サイクルを作成しようとすると、コレクションに存在できるアクティブなメンテナンス・サイクルが1つのみであることを意図したダイアログが表示されます。

更新メンテナンス・サイクルの作成

特定のコレクションについて、特定のターゲット・バージョンへの完全更新イベントを表すメンテナンス・サイクルを作成します。 各収集には、ゼロ個以上のメンテナンス・サイクルを含めることができますが、一度にアクティブにできるメンテナンス・サイクルは1つのみです。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 編集するコレクションの名前をクリックします。

   「コレクションの詳細」ページが表示されます。

3. 「リソース」の下で、「メンテナンス・サイクル」をクリックします。
4. 「メンテナンス・サイクルの作成」をクリックします。

   「メンテナンス・サイクルの作成」ページが表示されます。

5. 「メンテナンス・サイクルの作成」ページで、リクエストされた情報を入力します:
   • メンテナンス・サイクル名: わかりやすい名前を入力します。
   • 使用可能な選択肢は、コレクション・タイプ(データベース、Grid Infrastructure、ゲストVM OSソフトウェア、またはGrid InfrastructureとゲストVM OSソフトウェアの組合せ)によって異なります。
     • データベース:
       • ターゲット・データベースのイメージ: デフォルトは、最新のOracle提供のイメージです。 別のターゲット・データベース・イメージを選択するには、「データベース・イメージの変更」をクリックします。
         • Oracle提供のデータベース・ソフトウェア・イメージ: これらのイメージには、一般に使用可能なバージョンのOracle Databaseソフトウェアが含まれています。
         • カスタム・データベース・ソフトウェア・イメージ: これらのイメージは組織によって作成され、ソフトウェア更新およびパッチのカスタマイズされた構成が含まれます。
           • 「コンパートメント」を選択します。
           • 「リージョン」を選択します。

             リージョン・フィルタは、デフォルトで現在接続されているリージョンに設定され、そのリージョンで作成されたすべてのソフトウェア・イメージがリストされます。 別のリージョンを選択すると、選択したリージョンで作成されたソフトウェア・イメージが表示されるように、ソフトウェア・イメージ・リストがリフレッシュされます。

       • データベース・ホーム: ソフトウェア更新の一部として、データベースはターゲット・イメージ・バージョンの新しいホームに移動されます。 新しいホームは、メンテナンス・サイクル中に作成することも、既存のホームがVMクラスタにすでに存在する場合は再利用することもできます。
         • 新規ホームの作成: 新しいホームを作成する場合、コレクション内のデータベースは同様の構造を維持します。 ソフトウェア更新前の共有ホーム(他のデータベースと共有)内のデータベースは、更新の一部として共有ホームに移動されます。 ソフトウェア更新の前に共有ホームにないデータベースは、更新の一部として別のホームに移動されます。
         • 使用可能な場合は既存のホームを使用します: 既存のホームを使用すると、同じVMクラスタ内のすべてのデータベース・ターゲットが共有データベース・ホームに移動されます。 選択したイメージの既存のホームがターゲット・データベースのVMクラスタに見つからない場合は、新しいホームが作成されます。 選択したイメージの複数の既存のホームが見つかった場合は、データベース数が最も少ないホームが使用されます。 複数のホームにデータベース数が最も少ない場合、ホームはランダムに選択されます。
         • データベース・ホームの表示名プレフィクス: メンテナンス・サイクルの一部として作成された新しいデータベース・ホームの表示名。 一意にするために、データベース・ホームの名前に序数が追加されます。
     • グリッド・インフラストラクチャ:
       • ターゲットGrid Infrastructureイメージ: デフォルトは、最新のOracle提供のイメージです。 「Grid Infrastructureの変更」イメージをクリックして、別のターゲットGrid Infrastructureイメージを選択します。
         • Oracle提供のGrid Infrastructureソフトウェア・イメージ: これらのイメージには、一般に使用可能なバージョンのOracle Grid Infrastructureソフトウェアが含まれています。
         • カスタムGrid Infrastructureソフトウェア・イメージ: これらのイメージは組織によって作成され、ソフトウェア更新およびパッチのカスタマイズされた構成が含まれます。 詳細は、「カスタムのOracle Grid Infrastructureソフトウェア・イメージの作成」を参照してください。
           • 「コンパートメント」を選択します。
           • 「リージョン」を選択します。

             リージョン・フィルタは、デフォルトで現在接続されているリージョンに設定され、そのリージョンで作成されたすべてのソフトウェア・イメージがリストされます。 別のリージョンを選択すると、選択したリージョンで作成されたソフトウェア・イメージが表示されるように、ソフトウェア・イメージ・リストがリフレッシュされます。

     • ゲストVM OSソフトウェア:
       • ターゲットExadataイメージ: 「Exadataイメージの変更」をクリックして、選択した別のターゲット・ゲストVM OSイメージを選択します。
     • Grid InfrastructureおよびゲストVM OSソフトウェア:
       • ターゲットExadataイメージ: 「Exadataイメージの変更」をクリックして、選択した別のターゲット・ゲストVM OSイメージを選択します。
       • ターゲットGrid Infrastructureイメージ: デフォルトは、最新のOracle提供のイメージです。 「Grid Infrastructureイメージの変更」をクリックして、別のターゲットGrid Infrastructureイメージを選択します。
   • メンテナンス・メソッド: メンテナンス・メソッドでは、VMクラスタ内のVMのバッチ処理メソッドと、ソフトウェア更新の適用時にどのノードをまとめて更新するかを決定します。
     • 一度に1つのノード(ローリング): (デフォルト)データベース・インスタンスは、クラスタ内の1つのVMで同時に更新され、他のインスタンスは動作したままになります。
     • スマート・バッチ(ローリング): データベース・インスタンスは、一度に1つ以上のVMで更新されます。 VMは、構成されたデータベース・サービスに基づいてバッチされます。 これにより、必要なバッチの合計数を最小限に抑えながら、複数のノードにすべてのサービスを構成しているかぎり、すべてのサービスが使用可能になります。
     • 非ローリング: クラスタ内のすべてのVMのすべてのデータベース・インスタンスがパラレルに更新され、完全な停止時間が発生します。

       ノート:

       現在のリリースのゲストVM OSおよびゲストVM OS + Grid Infrastructureの更新では、非ローリング更新はサポートされていません。

     • 50/50 (rolling): VMの半分にあるデータベース・インスタンスは、1つのバッチで更新され、残りの半分は別のバッチで更新されます。 2つのバッチは、データベース・サービスの構成によって決まります。 これにより、すべてのサービスが使用可能になります。
       • 一度に1つのバッチを有効にします: このチェック・ボックスを選択すると、一度に1つのバッチに更新が適用されます。

         適用アクションでは、1つ目のバッチの更新を適用すると、2つ目のバッチを開始する前に、続行が待機されます。

   • ソフトウェアのステージング開始時間: オプションで、ソフトウェアのステージングの開始時間を設定します。
   • 更新開始時間を適用: オプションで、更新を適用するための開始時間を設定します。 適用更新開始時間は、ステージ・ソフトウェア開始時間の24時間以上後にする必要があります。

     ソフトウェアのステージング・アクションが完了するまで、更新の適用アクションは実行されません。

   • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

     ノート:

     この構成に対する変更は、メンテナンス・サイクルのすべてのアクションがスケジュールされた状態の場合にのみサポートされます。 メンテナンス・サイクルのアクションが開始されると、この設定を変更できません。
     推奨: この設定を有効にしておくと、Oracleで診断データを迅速に分析できるため、問題の解決が迅速になります。

     このサイクルおよび将来のイベントのすべてのターゲットに対して有効化: このサイクルおよび将来のイベントのすべてのターゲットの診断ログ収集を有効にします。 Oracleでは、トラブルシューティングが簡単で、より優れたサポートを実現するために、これを推奨しています。

     このサイクルのすべてのターゲットに対してのみ有効にします: 現在のメンテナンス・サイクルでのみ、すべてのターゲットの診断ログ収集を有効にします。 サイクルが終了すると、ログ収集設定はメンテナンス・サイクルの開始前に設定に戻ります。

     既存の診断ログ収集設定を使用します: ログ収集がすでに有効になっているターゲットのログのみを収集します。

     詳細は、次を参照してください。

     • 「Exadata Database Service on Cloud@Customer管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Exadata Database Service on Dedicated Infrastructure管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Database Service APIのドキュメント」の「DataCollectionOptionsリファレンス」。
   • 拡張オプション:
     • データベースの起動/停止オプション:
       • 最大ドレイン・タイムアウト(秒): ノード間のドレイン・タイムアウトを秒単位で指定します。 これは、ローリング更新中に使用され、データベース接続の再配置の時間を提供します。 使用されるドレイン・タイムアウトは、この値の最大値、または特定のインスタンスで実行されているサービスの最大構成ドレイン・タイムアウトになります。 デフォルトは600です。
       • サービスの配置を維持: 有効にすると、データベース・サービスは、更新を適用アクションの前に配置にリストアされます。
     • ソフトウェア更新オプション:
       • 欠落しているバグ修正を無視: ソース・ホームに存在するバグ修正のパッチがターゲット・ホームにない場合でも、ソフトウェア更新の一部として移動を実行するには、このチェック・ボックスを選択します。
         • 無視するバグ番号: オプションで、無視するバグ番号を入力します。 バグ番号を指定しない場合、ソースで修正されているがターゲットにないバグは無視されます。
       • ローリング・パッチの強制: 非ローリング・パッチでもパッチ操作を強制的にローリング方式で実行するには、このチェック・ボックスを選択します。
     • タグ: (オプション)タグの適用を選択できます。 リソースの作成権限がある場合、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用する必要があるかどうかわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
6. 「メンテナンス・サイクルの作成」をクリックします。

メンテナンス・サイクル・ライフサイクルの状態:

• メンテナンス・サイクルは、作成時に「アクティブ」状態になります。 属性の更新時に、必要に応じて「更新中」状態になる場合があります。
• アクションが実行されると、メンテナンス・サイクルは「メンテナンス中」状態になります。
• 失敗したジョブに失敗したアクションがあり、失敗したジョブを正常に完了するための後続のアクションがまだ実行されていない場合、メンテナンス・サイクルは「確認が必要」状態になります。
• 適用アクションが成功すると、メンテナンス・サイクルは「成功」状態に移行し、クリーンアップ・アクションが使用可能になります。

  クリーン・アップ処理は、メンテナンス・サイクルでのオプションの処理です。 メンテナンス・サイクルが正常に完了した後、クリーンアップ・アクションを実行して、メンテナンス・サイクルのソース・データベースおよびGrid Infrastructureホーム(コレクション内のデータベースおよびグリッド・インフラストラクチャ)を削除します。 すぐにクリーンアップまたはクリーンアップをスケジュールできます。

ノート:

メンテナンス・サイクルがすでに存在する場合に別のメンテナンス・サイクルを作成しようとすると、コレクションに存在できるアクティブなメンテナンス・サイクルが1つのみであることを意図したダイアログが表示されます。

一度に1つのバッチを有効化

50/50(ローリング)メンテナンス・メソッドを選択すると、追加のチェック・ボックスが表示されます。一度に1つのバッチを有効にして、一度に1つのバッチに更新を適用できます。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 編集するコレクションの名前をクリックします。

   「コレクションの詳細」ページが表示されます。

3. 「リソース」の下で、「メンテナンス・サイクル」をクリックします。
4. 「メンテナンス・サイクルの作成」をクリックします。

   「メンテナンス・サイクルの作成」ページが表示されます。

5. 「メンテナンス・サイクルの作成」ページで、必要な情報を指定します。

   50/50(ローリング)メンテナンス・メソッドを選択すると、追加のチェック・ボックス「一度に1つのバッチを有効化」が表示されます。 このチェック・ボックスを選択すると、一度に1つのバッチに更新が適用されます。

   適用アクションでは、1つ目のバッチの更新を適用すると、2つ目のバッチを開始する前に、続行が待機されます。

6. 「作成」をクリックします。

   スケジュール済の場合、「ソフトウェアのステージング」および「更新を適用」アクションはスケジュールされた時間に実行されます。

   「メンテナンスの詳細」ページの「アクション」セクションに、これらの詳細が表示されます。

   スケジュールされた「ソフトウェアのステージング」および「事前チェックの適用」アクションが成功した場合、最初のバッチは更新プロセスを開始します。

   最初のバッチに更新を適用すると、「メンテナンス・サイクル」のステータスが「確認が必要」に変わります。 2番目のバッチの「更新を適用」のステータスは、「待機中」のままです。

7. 「更新を適用」をクリックします。

   「更新アクションの適用」の詳細ページが表示されます。

8. 「適用の続行」をクリックします。

   2番目のバッチの「更新を適用」のステータスが「進行中」に変わります。

   「メンテナンス・サイクル」のステータスが「進行中」に変わります。

   2番目のバッチに更新を適用すると、「メンテナンス・サイクル」のステータスが「成功」に変わります。

   2番目のバッチの「更新を適用」のステータスが「成功」に変わります。

メンテナンス・サイクルのリストの表示

すべての回収のすべてのメンテナンス・サイクルのリストを表示できます。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。

コンパートメント別のメンテナンス・サイクルのフィルタ

個々のコンパートメントに固有のメンテナンス・サイクルを検索するには、リスト範囲を使用して、コンパートメント別にメンテナンス・サイクルをフィルタします。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。
3. 「適用済フィルタ」リストからコンパートメントを選択します。

状態によるメンテナンス・サイクルのフィルタ

状態のリストから状態を選択して、メンテナンス・サイクルをフィルタします。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。
3. 「検索とフィルタ」フィールドで、「状態」を選択し、リストから1つ以上の状態を選択します。

現在または前のメンテナンス・サイクルのフィルタ

現在または前、あるいは両方のメンテナンス・サイクルをフィルタします。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。
3. 「検索とフィルタ」フィールドから、「メンテナンス・サイクル」、「現在」、「前」またはその両方を選択します。

メンテナンス・サイクルの編集

メンテナンス・サイクルを編集するには、メンテナンス・サイクルの編集に必要なフィールドに値を指定する準備をします。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。
3. メンテナンス・サイクルのリストで、メンテナンス・サイクルの名前をクリックして詳細を表示するか、ターゲットのアクション・アイコン(3つのドット)をクリックして「詳細を見る」をクリックします。

   「メンテナンス・サイクル」の詳細ページが表示されます。

4. 「アクション」メニューから、「メンテナンス・サイクルの編集」を選択します。
5. 必須フィールドに適切な値を入力します。

   使用可能な選択肢は、コレクション・タイプ(データベース、Grid Infrastructure、ゲストVM OSソフトウェア、またはGrid InfrastructureとゲストVM OSソフトウェアの組合せ)によって異なります。

   ノート:

   ターゲット・イメージは、適用の実行前にのみ変更できます。 適用が実行されると、これらのフィールドは編集できません。

   • データベース:選択したデータベース・イメージ・バージョンを選択します。
   • Grid Infrastructureイメージ:選択したGrid Infrastructureイメージ・バージョンを選択します。
   • ゲストVM OSソフトウェア:選択したExadataイメージ・バージョンを選択します。
   • Grid InfrastructureおよびゲストVM OSソフトウェア: Exadataイメージ・バージョンとGrid Infrastructureイメージ・バージョンの両方を選択します。
   • メンテナンス方法:

     メンテナンス方法では、VMクラスタ内のVMのバッチ処理方法と、ソフトウェア更新の適用時に一緒に更新されるノードを決定します。

     • 一度に1つのノード(ローリング): (デフォルト)データベース・インスタンスは、クラスタ内の1つのVMで同時に更新され、他のインスタンスは動作したままになります。
     • スマート・バッチ(ローリング): データベース・インスタンスは、一度に1つ以上のVMで更新されます。 VMは、構成されたデータベース・サービスに基づいてバッチされます。 これにより、必要なバッチの合計数を最小限に抑えながら、複数のノードにすべてのサービスを構成しているかぎり、すべてのサービスが使用可能になります。
     • 非ローリング: クラスタ内のすべてのVMのすべてのデータベース・インスタンスがパラレルに更新され、完全な停止時間が発生します。

       ノート:

       現在のリリースのゲストVM OSおよびゲストVM OS + Grid Infrastructureの更新では、非ローリング更新はサポートされていません。

     • 50/50 (rolling): VMの半分にあるデータベース・インスタンスは、1つのバッチで更新され、残りの半分は別のバッチで更新されます。 2つのバッチは、データベース・サービスの構成によって決まります。 これにより、すべてのサービスが使用可能になります。
       • 一度に1つのバッチを有効にします: このチェック・ボックスを選択すると、一度に1つのバッチに更新が適用されます。

         適用アクションでは、1つ目のバッチの更新を適用すると、2つ目のバッチを開始する前に、続行が待機されます。

   • 更新開始時間を適用: オプションで、更新を適用するための開始時間を設定します。 適用更新開始時間は、ステージ・ソフトウェア開始時間の24時間以上後にする必要があります。

     ソフトウェアのステージング・アクションが完了するまで、更新の適用アクションは実行されません。

   • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

     ノート:

     この構成に対する変更は、メンテナンス・サイクルのすべてのアクションがスケジュールされた状態の場合にのみサポートされます。 メンテナンス・サイクルのアクションが開始されると、この設定を変更できません。

     このサイクルおよび将来のイベントのすべてのターゲットに対して有効化: このサイクルおよび将来のイベントのすべてのターゲットの診断ログ収集を有効にします。 Oracleでは、トラブルシューティングが簡単で、より優れたサポートを実現するために、これを推奨しています。

     このサイクルのすべてのターゲットに対してのみ有効にします: 現在のメンテナンス・サイクルでのみ、すべてのターゲットの診断ログ収集を有効にします。 サイクルが終了すると、ログ収集設定はメンテナンス・サイクルの開始前に設定に戻ります。

     既存の診断ログ収集設定を使用します: ログ収集がすでに有効になっているターゲットのログのみを収集します。

     詳細は、次を参照してください。

     • 「Exadata Database Service on Cloud@Customer管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Exadata Database Service on Dedicated Infrastructure管理者ガイド」の「インシデント・ログおよびトレース・ファイル」および「データベース・サービス・イベント」。
     • 「Database Service APIのドキュメント」の「DataCollectionOptionsリファレンス」。
6. 「保存」をクリックします。

メンテナンス・サイクルの削除

削除したメンテナンス・サイクルはリカバリできません。

1. ナビゲーション・メニューを開きます。 「Oracle AI Database」で、「Exadata Fleet Update」をクリックします。

   「Exadataフリートの更新」では、デフォルトで「コレクション」が選択されています。

2. 「メンテナンス・サイクル」をクリックします。
3. 削除するメンテナンス・サイクルの名前をクリックします。

   「メンテナンス・サイクル詳細」ページが表示されます。

4. 「アクション」メニューから「削除」を選択します。

   「削除」ダイアログが表示されます。

5. メンテナンス・サイクルの名前を入力し、「削除」をクリックします。