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

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

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

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

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

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

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

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

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

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

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

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

   • メンテナンス方法:メンテナンス方法では、VMクラスタ内の仮想マシンをバッチ処理する方法、およびソフトウェア更新の適用時に一緒にアップグレードされるノードを決定します。
     • 一度に1ノード(ローリング): (デフォルト)データベース・インスタンスは、クラスタ内の1つのVMで一度に更新され、その間、他のインスタンスは操作を続けます。
     • スマート・バッチ(ローリング):データベース・インスタンスは、一度に1つ以上のVMで更新されます。構成されたデータベース・サービスに基づいて、VMがバッチ処理されます。これにより、必要なバッチの合計数を最小限に抑えながら、すべてのサービスが複数のノードで構成されているかぎり、引き続き使用可能になります。
     • 非ローリング:クラスタ内のすべてのVMのすべてのデータベース・インスタンスがパラレルで更新され、フル・ダウンタイムが発生します。
     • 50/50 (ローリング): VMsの半分のデータベース・インスタンスは、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. 「メンテナンス・サイクルの作成」をクリックします。

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

   「Exadata Fleet Update」で、「コレクション」がデフォルトで選択されています。

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

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

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

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

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

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

       • データベース・ホーム:ソフトウェア更新の一環として、データベースはターゲット・イメージ・バージョンの新しいホームに移動されます。メンテナンス・サイクル中に新しいホームを作成することも、既存のホームがVMクラスタにすでに存在する場合は再利用することもできます。
         • 新規ホームの作成:新規ホームを作成する場合、コレクション内のデータベースは同様の構造を維持します。ソフトウェア更新の前に共有ホーム(他のデータベースと共有)にあるデータベースは、更新の一環として共有ホームに移動されます。ソフトウェア更新の前に共有ホームにないデータベースは、更新の一環として個別のホームに移動されます。
         • 使用可能な場合は既存のホームを使用します:既存のホームを使用すると、同じVMクラスタ内のすべてのデータベース・ターゲットが共有データベース・ホームに移動されます。選択したイメージの既存のホームがターゲット・データベースのVMクラスタ内に見つからない場合、新しいホームが作成されます。選択したイメージの既存のホームが複数見つかった場合、データベース数が最も少ないホームが使用されます。複数のホームにデータベースの数が最も少ない場合は、ホームがランダムに選択されます。
         • データベース・ホームの表示名接頭辞:メンテナンス・サイクルの一部として作成された新しいデータベース・ホームの表示名。データベース・ホームの名前に順序番号が付加され、一意になります。
     • Grid Infrastructure:
       • ターゲット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 OSおよびゲストVM OS + Grid Infrastructureの更新では、非ローリング更新はサポートされていません。

     • 50/50 (ローリング): VMsの半分のデータベース・インスタンスは、あるバッチで更新され、もう一方の半分は別のバッチで更新されます。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. 「メンテナンス・サイクルの作成」をクリックします。

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

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

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

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

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

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

5. 「メンテナンス・サイクルの作成」ページで、リクエストされた情報を指定します。

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

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

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

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

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

   スケジュールされたステージング・ソフトウェアおよび事前チェックの適用アクションが成功すると、最初のバッチによって更新プロセスが開始されます。

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

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

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

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

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

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

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

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

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

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

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

2. 「メンテナンス・サイクル」をクリックします。
3. 「リスト範囲」で、リストからコンパートメントを選択します。

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

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

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

2. 「メンテナンス・サイクル」をクリックします。
3. 「フィルタ」で、リストから状態を選択します。