Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。

Oracleのパッチおよび更新には、物理データベース・サーバー・ホスト、Exadata Storage Server、ネットワーク・ファブリック・スイッチ、管理スイッチ、電力配分装置(PDU)、統合電源管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。これは、インフラストラクチャ・メンテナンスと呼ばれます。

更新の頻度は、次のようにリージョン・タイプによって異なります:

• 商用リージョン: Oracleは、四半期ごとの完全なインフラストラクチャ更新と、月ごとのセキュリティ・インフラストラクチャ更新を実行します。
• 政府リージョン: Oracleは、毎月の完全なインフラストラクチャ・メンテナンス更新を実行します。

ごくまれな例外的状況を除き、計画を支援するために、これらの更新に関する事前通知が送信されます。VMクラスタ仮想マシン(VM)に、対応する推奨更新がある場合、Oracleからそれらに関する通知が提供されます。

可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を保持する方法で実行されます。ただし、更新プロセス中に個々のシステム・コンポーネントが使用できない間は、パフォーマンスやスループットに顕著な影響が生じることがあります。

たとえば、通常、データベース・サーバーのパッチ適用では再起動が必要です。このような場合、データベース・サーバーは、可能なかぎりローリング方式で1つずつ再起動され、プロセス全体でサービスの可用性が保持されるようにします。ただし、各データベース・サーバーは、再起動中に短時間使用不能になるため、全体的なサービス容量はそれに応じて減少します。アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。たとえば、データベース・サーバーのパッチ適用が発生したときにアプリケーションを停止します。

デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。

非ローリング・メンテナンスを選択して、データベース・サーバーとストレージ・サーバーを更新することもできます。非ローリング・メンテナンス方法は、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。非ローリング・メンテナンスでは、メンテナンス時間が最小化されますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。

ローリング・インフラストラクチャ・メンテナンスは、Exadataデータベース・サーバー・ホストから開始されます。ローリング・メンテナンス方法では、データベース・サーバーは一度に1つずつ更新されます。データベース・サーバー・ホストの各VMが停止され、ホストが更新および再起動されてからVMが起動されますが、その間他のデータベース・サーバーは稼働したままです。このローリング・メンテナンスは、ローリング・インスタンスの停止を処理するために書き込まれていない古いアプリケーションに影響します。すべてのサーバーが更新されるまでこのプロセスが続行されます。

データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。ローリング・メンテナンス方法では、ストレージ・サーバーは一度に1つずつ更新され、VMクラスタのVMの可用性には影響しません。ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーがオフラインになり(使用可能なIO容量が減少)、オンラインに戻ったときに再同期されると、IOパフォーマンスが低下する可能性があります(データベース・サーバーのオーバーヘッドが少ない)。データベースおよびストレージ・インフラストラクチャを適切にサイジングして、メンテナンスされていないデータベースおよびストレージ・サーバーに分散された作業の増加に対応すると、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。

最大可用性アーキテクチャ(MAA)のベスト・プラクティスに従い、Data Guardを使用してクリティカルなアプリケーションの可用性を最大にすることをお薦めします。Data Guardが有効なデータベースの場合、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前に、スイッチオーバーを実行することもできます。これにより、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避できます。

事前チェックは、メンテナンス・ウィンドウの開始前にExadata Cloud Infrastructureコンポーネントで実行されます。事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。最初の事前チェックはメンテナンス開始の約5日前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックでメンテナンスの再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に通知が送信されます。

• 四半期メンテナンスWindowsの見積り時間
  インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法およびカスタム・アクションが有効になっているかどうかによって異なります。

四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコアにわたる脆弱性の修正を含みます。

セキュリティ・メンテナンスは、必要に応じて、各月の18日から21日の間に開始し、翌月の9日から12日まで実行される21日の期間中に適用されるようにスケジュールされています。顧客には、月次メンテナンス・ウィンドウの開始日の7日前までにスケジュール案が通知され、必要に応じて、ウィンドウ内の別の日付に月次メンテナンスを再スケジュールできます。毎月のセキュリティ・メンテナンス・プロセスでは、データベース・サーバーが更新され、重要なセキュリティの脆弱性と製品に関する問題が修正されます。また、月次メンテナンスでは、ストレージ・サーバーをExadata Storageソフトウェア・イメージに更新して、既知のセキュリティの脆弱性と製品の問題を解決します。

データベース・サーバーへの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新は、VMおよびデータベースを含むVM内のすべてのプロセスが稼働している間、ホスト・サーバーにオンラインで適用されるためです。サーバーとVMは再起動されません。ストレージ・サーバーに対する更新は、ローリング方式で適用されます。四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションに対して最小限に抑える必要があります。

四半期と月の両方のセキュリティ・メンテナンスが同じ月に実行されるようにスケジュールされている場合は、特別な考慮事項があります。四半期メンテナンスでは、セキュリティ・メンテナンスによってすでに適用されているセキュリティ修正が再適用され、既存のストレージ・サーバーのバージョンが更新に含まれるバージョンと同じかそれより新しい場合は、四半期メンテナンスも月次メンテナンスもストレージ・サーバー更新を適用しません。

• 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前の月から最新のExadataリリースを使用します。その時点で追加のセキュリティ修正が使用可能な場合は、それらの更新が四半期メンテナンスに含まれます。このイメージは四半期全体で使用されます。たとえば、1月のリリースは、2月、3月および4月の四半期メンテナンスに使用されます。
• 四半期メンテナンスが適用されると、データベース・サーバーに以前にインストールされたセキュリティ更新が、適用される四半期メンテナンス・リリースに含まれていない可能性があります。その場合、自動化では、四半期メンテナンスによってインストールされた新しいリリースに同じセキュリティ修正が適用されるため、セキュリティ修正が低下することはありません。ストレージ・サーバーの現在のイメージが、四半期または月次セキュリティ・メンテナンスによって適用されるイメージと同じかそれより新しい場合、そのメンテナンスはストレージ・サーバーに対してスキップされます。

四半期メンテナンスが月次スケジュールの24時間以内にスケジュールされている場合、スケジュールされた月次メンテナンスはスキップされ、かわりに四半期メンテナンスの直後に月次更新が適用されます。

• 同じ時間にスケジュールされている場合、四半期メンテナンスの完了直後に月次更新が実行されます。
• 月次メンテナンスが四半期メンテナンスより0-24時間前に開始するようにスケジュールされている場合、月次メンテナンスはスケジュールどおりに実行されません。かわりに、待機して四半期メンテナンスの直後に実行されます。四半期メンテナンスが後で再スケジュールされた場合、月次セキュリティ・メンテナンスは即座に開始されます。したがって、四半期メンテナンスと月次メンテナンスを同じ時間にスケジュールすることをお薦めします。そうすると、四半期メンテナンスを直前に再スケジュールした場合、月次メンテナンスはスケジュールの編集直後ではなく、スケジュールされた時間に実行されます。また、四半期メンテナンスの再スケジュール時に、月次セキュリティ・メンテナンスを再スケジュールすることもできます(月次メンテナンスが現在のメンテナンス・ウィンドウ内にある場合にかぎります)。月次メンテナンスはメンテナンス・ウィンドウ内の別の時間に再スケジュールできますが、スキップすることはできません。

ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。

Exadata Cloud Infrastructureソフトウェアの完全な更新は、商用リージョンの場合は四半期ベースで、政府リージョンの場合は月次でスケジュールされます。さらに、重要なセキュリティ更新は毎月スケジュールされます。これらのインフラストラクチャの更新をオプト・アウトすることはできませんが、クラウド通知ポータルを介して更新が事前にアラートされ、スケジュールを柔軟に設定して計画を立てることができます。

四半期ごとのインフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。また、Oracle Cloud Infrastructureコンソールの「Exadataインフラストラクチャの詳細」ページで、メンテナンス方法の編集、カスタム・アクションの有効化、スケジュール済メンテナンス実行とメンテナンス履歴の表示、メンテナンス連絡先の管理を行うことができます。

• Exadata Cloud Infrastructureの自動四半期メンテナンス・スケジュールを設定するには
  
• Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
  Exadata Cloud Infrastructureのスケジュールされた四半期メンテナンスのプロパティを確認および変更します。
• Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには
  このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースのメンテナンス履歴を表示する方法について説明します。
• スケジュールされたインフラストラクチャ・メンテナンス実行のノードのパッチ適用順序を設定するには
  このタスクでは、クラウドExadataインフラストラクチャまたはExadata DBシステム・リソースのスケジュール済インフラストラクチャ・メンテナンス実行に対してノードのパッチ適用順序を設定する方法について説明します。

Exadataインフラストラクチャ・リソースのライフサイクル状態により、インフラストラクチャ・リソースのメンテナンスがいつ開始および終了するかをモニターできます。

Oracle Cloud Infrastructureコンソールで、「Exadataインフラストラクチャの詳細」ページにライフサイクル状態の詳細メッセージが表示されます(「ステータス」フィールドの横にツールチップが表示されます)。これらのメッセージには、ListCloudExadataInfrastructures API、およびSDKやOCI CLIなどのAPIに基づくツールを使用してアクセスすることもできます。

通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。

Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。スケジュール・リマインダ、パッチ適用の開始、パッチ適用の終了など、スケジュール済メンテナンス実行のためのOracleの準備として、適切なメンテナンス関連イベントが生成されます。すべてのメンテナンス関連イベントの詳細は、Oracle Cloud Exadataインフラストラクチャ・イベントを参照してください。障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成して、インフラストラクチャ・メンテナンス連絡先に通知します。

Oracle Cloud Infrastructure Eventsの詳細は、イベントの概要を参照してください。インフラストラクチャ・メンテナンス連絡先に送信された通知以外の追加の通知を受信するには、インフラストラクチャ・メンテナンス・イベントにサブスクライブし、Oracle Notification Serviceを使用して通知を受信します。通知の概要を参照してください。

Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。

• Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには
  コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。

次のAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス制御およびリソースを管理します。

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

次のAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス制御を管理します。

クラウドExadataインフラストラクチャ・リソース(新しいリソース・モデル):

• ListCloudExadataInfrastructures
• GetCloudExadataInfrastructure
• UpdateCloudExadataInfrastructure
• GetMaintenanceRun
• ListMaintenanceRuns
• UpdateMaintenanceRun