クラウド・インフラストラクチャのメンテナンス更新
Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。
インフラストラクチャ・メンテナンスに関して通知される連絡先を管理したり、メンテナンス・ウィンドウを設定して四半期ごとのインフラストラクチャ・メンテナンスを開始する時間を決定したり、Oracle Cloud InfrastructureコンソールでExadata Cloud Infrastructureのスケジュール済メンテナンス実行およびメンテナンス履歴を表示したりできます。インフラストラクチャ・メンテナンス・プロセスおよびメンテナンス制御の構成の詳細は、次を参照してください:
- Oracle管理のExadata Cloud Infrastructureメンテナンスについて
Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。 - 四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。 - 月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコア間の脆弱性の修正を含みます。 - 同月の月次メンテナンスと四半期メンテナンスについて
- コンソールを使用したOracle管理インフラストラクチャ更新の構成
ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。 - ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。 - インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。 - インフラストラクチャ・メンテナンス連絡先の管理
Exadataインフラストラクチャ・メンテナンス連絡先を管理する方法について学習します。 - APIを使用したExadata Cloud Infrastructureメンテナンス制御の管理
次のAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス制御およびリソースを管理します。
親トピック: ハウツー・ガイド
Oracle管理のExadata Cloud Infrastructureメンテナンスについて
Oracleは、Exadata Cloud Infrastructure上のOracle管理システム・コンポーネントすべてに対してパッチおよび更新を実行します。
Oracleのパッチおよび更新には、物理データベース・サーバー・ホスト、Exadata Storage Server、ネットワーク・ファブリック・スイッチ、管理スイッチ、電力配分装置(PDU)、統合電源管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。これは、インフラストラクチャ・メンテナンスと呼ばれます。
更新の頻度は、次のようにリージョン・タイプによって異なります:
- 商用リージョン: Oracleは、四半期ごとの完全なインフラストラクチャ更新と、月ごとのセキュリティ・インフラストラクチャ更新を実行します。
- 政府リージョン: Oracleは、毎月の完全なインフラストラクチャ・メンテナンス更新を実行します。
ごくまれな例外的状況を除き、計画を支援するために、これらの更新に関する事前通知が送信されます。VMクラスタ仮想マシン(VM)に、対応する推奨更新がある場合、Oracleからそれらに関する通知が提供されます。
可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を保持する方法で実行されます。ただし、更新プロセス中に個々のシステム・コンポーネントが使用できない間は、パフォーマンスやスループットに顕著な影響が生じることがあります。
たとえば、通常、データベース・サーバーのパッチ適用では再起動が必要です。このような場合、データベース・サーバーは、可能なかぎりローリング方式で1つずつ再起動され、プロセス全体でサービスの可用性が保持されるようにします。ただし、各データベース・サーバーは、再起動中に短時間使用不能になるため、全体的なサービス容量はそれに応じて減少します。アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。たとえば、データベース・サーバーのパッチ適用が発生したときにアプリケーションを停止します。
Oracle Cloud Infrastructure (OCI) US Government (OC2)および米国国防総省(OC3)リージョンでExadata Database on Dedicated Infrastructureを使用するお客様は、OCIコンソールを使用して、月次および四半期ごとのパッチ適用イベントを再スケジュールできます。
現時点では、Exadata Cloud Infrastructureのパッチ管理スケジュールの設定と呼ばれるメンテナンス・スケジュールの指定は、Exadataパッチ管理のOCI US Government (OC2)およびUS DOD (OC3)レルムではまだ使用できません。パッチ管理再スケジュール時のExadata Database on Dedicated Infrastructureの詳細は、こちらを参照してください。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。
非ローリング・メンテナンスを選択して、データベース・サーバーとストレージ・サーバーを更新することもできます。非ローリング・メンテナンス方法は、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。非ローリング・メンテナンスでは、メンテナンス時間が最小化されますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。
ローリング・インフラストラクチャ・メンテナンスは、Exadataデータベース・サーバー・ホストから開始されます。ローリング・メンテナンス方法では、データベース・サーバーは一度に1つずつ更新されます。データベース・サーバー・ホストの各VMが停止され、ホストが更新および再起動されてからVMが起動されますが、その間他のデータベース・サーバーは稼働したままです。このローリング・メンテナンスは、ローリング・インスタンスの停止を処理するために書き込まれていない古いアプリケーションに影響します。すべてのサーバーが更新されるまでこのプロセスが続行されます。
データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。ローリング・メンテナンス方法では、ストレージ・サーバーは一度に1つずつ更新され、VMクラスタのVMの可用性には影響しません。ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーがオフラインになり(使用可能なIO容量が減少)、オンラインに戻されると再同期される(データベース・サーバーでのオーバーヘッドが少ない)ため、IOパフォーマンスが低下する可能性があります。データベースおよびストレージ・インフラストラクチャのサイズを適切に設定して、データベースおよびストレージ・サーバーに分散される作業の増加に対応することで、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。
ローリング・メンテナンス・プロセス中はデータベースが使用可能であることが想定されますが、自動化メンテナンスでは、Oracle Clusterwareが実行中であることは検証しますが、サーバーがオンラインに戻された後にすべてのデータベース・サービスおよびプラガブル・データベース(PDB)が使用可能であることは検証しません。メンテナンス後のデータベース・サービスおよびPDBの可用性は、アプリケーション・サービス定義に依存する可能性があります。たとえば、特定の優先ノードおよび使用可能ノードで構成されたデータベース・サービスは、メンテナンス中に再配置されると、メンテナンスの完了後に元のノードに自動的に再配置されません。Exadata Cloudシステム上のアプリケーションの継続的可用性の実現に関するドキュメントを確認して、アプリケーションへの影響の可能性を減らすことをお薦めします。ドキュメントのガイドラインに従うことで、データベース・サーバーは順番に更新されるため、インフラストラクチャ・メンテナンスの影響は、わずかなサービス低下のみになります
最大可用性アーキテクチャ(MAA)のベスト・プラクティスに従い、Data Guardを使用してクリティカルなアプリケーションの可用性を最大にすることをお薦めします。Data Guardが有効なデータベースの場合、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前に、スイッチオーバーを実行することもできます。これにより、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避できます。
事前チェックは、メンテナンス・ウィンドウの開始前にExadata Cloud Infrastructureコンポーネントで実行されます。事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。最初の事前チェックはメンテナンス開始の約5日前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックでメンテナンスの再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に通知が送信されます。
パッチ適用ウィンドウ中はデータベースまたはアプリケーションで主要なメンテナンス操作を実行しないでください。これらの操作はインフラストラクチャ・メンテナンス操作によって影響を受ける可能性があるためです
- Windowsの四半期メンテナンスの見積り時間
インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法、およびカスタム・アクションが有効になっているかどうかによって異なります。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
四半期メンテナンスWindowsの見積時間
インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法、およびカスタム・アクションが有効化されているかどうかによって異なります。
提示される概算時間は見積りです。カスタム・アクション(構成されている場合)の時間は見積りに含まれません。データベース・サーバーのメンテナンス時間は、更新前に各VMを停止してから、各ノードの更新後に次のノードに進む前に各VMおよび関連リソースを起動するために必要な時間によって異なる場合があります。ストレージ・サーバーのメンテナンス時間は、ASMリバランスに必要な時間によって異なります(この時間は次の見積りには含まれません)。メンテナンス中に問題が発生した場合、リストされている概算時間を超えて完了が遅延することもあります。このような状況では、Oracleクラウド操作によって、予想されるウィンドウを超えて解決が延長されると判断された場合、通知が送信され、メンテナンスが再スケジュールされることがあります。
Oracle Cloud Operationsで追加のメンテナンス作業が必要と判断された場合、次に示す時間枠が変更される可能性があります。追加の時間が必要な場合は、次の四半期メンテナンス・ウィンドウに追加の時間が必要であることを顧客に通知するために、Oracleから事前に顧客に通知が送信されます。
表5-1 Exadataインフラストラクチャ・メンテナンスのおおよその時間
Exadataシェイプ構成 | ローリング・パッチ適用方式(概算時間) | 非ローリング・パッチ適用方式(概算時間) |
---|---|---|
クォータ・ラック | 5-6時間 | 4-7時間 |
ハーフ・ラック | 10時間 | 4-7時間 |
フル・ラック | 20時間 | 4-7時間 |
フレキシブル・シェイプ(X8M以上) | コンピュート・ノード当たり1.5時間 + ストレージ・ノード当たり1時間 | 4-7時間 |
月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコアの脆弱性の修正を含みます。
CVEリリース・マトリックスの詳細は、Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(ドキュメントID 888828.1)を参照してください。
Exadataインフラストラクチャ・バージョンに固有のCVEリリース・マトリックスを表示するには、Exadataバージョン(Exadata 23など)をクリックします。バージョン固有のCVEリリース・マトリックスは、表の「ノート」列にリストされます。
セキュリティ・メンテナンスは、必要に応じて、各月の18日から21日の間に開始し、翌月の9日から12日まで実行される21日のウィンドウ中に適用されるようにスケジュールされます。顧客には、月次メンテナンス・ウィンドウの開始日の7日前までにスケジュール案が通知され、必要に応じて、ウィンドウ内の別の日付に月次メンテナンスを再スケジュールできます。月次セキュリティ・メンテナンス・プロセスでは、データベース・サーバーを更新して、重要なセキュリティ脆弱性および重要な製品の問題を修正します。また、月次メンテナンスでは、既知のセキュリティの脆弱性および製品の問題を解決するExadata Storageソフトウェア・イメージにストレージ・サーバーを更新します。
データベース・サーバーの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新はホスト・サーバーにオンラインで適用され、VMおよびデータベースを含むVM内のすべてのプロセスは稼働したままです。サーバーおよびVMは再起動されません。ストレージ・サーバーに対する更新は、ローリング形式で適用されます。四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションにとって最小限である必要があります。
毎月のインフラストラクチャ・メンテナンス中は、VMの起動および停止操作のみがサポートされます。
同月の月次メンテナンスと四半期メンテナンスについて
四半期セキュリティ・メンテナンスと月次セキュリティ・メンテナンスの両方が同じ月に実行されるようにスケジュールされている場合、特別な考慮事項があります。四半期メンテナンスでは、セキュリティ・メンテナンスによってすでに適用されているセキュリティ修正が再適用され、既存のストレージ・サーバーのバージョンが更新に含まれるバージョンと同じかそれより新しい場合は、四半期メンテナンスも月次メンテナンスもストレージ・サーバーの更新を適用しません。
- 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前月から最新のExadataリリースが使用されます。その時点で追加のセキュリティ修正が使用可能な場合は、それらの更新が四半期メンテナンスに含まれます。そのイメージは四半期を通して使用されます。たとえば、1月リリースは、2月、3月および4月の四半期メンテナンスに使用されます。
- 四半期メンテナンスを適用すると、以前にデータベース・サーバーにインストールされたセキュリティ更新が、適用される四半期メンテナンス・リリースに含まれていない可能性があります。その場合、自動化では四半期メンテナンスによってインストールされた新しいリリースに同じセキュリティ修正が適用されるため、セキュリティ修正の回帰はありません。ストレージ・サーバー上の現在のイメージが、四半期または月次のセキュリティ・メンテナンスによって適用されるイメージと同じかそれより新しい場合、そのメンテナンスはストレージ・サーバーに対してスキップされます。
四半期メンテナンスが月次スケジュールの24時間以内にスケジュールされている場合、スケジュールされた月次メンテナンスはスキップされ、かわりに四半期メンテナンスの直後に月次更新が適用されます。
- 同じ時間にスケジュールされている場合、四半期メンテナンスの完了直後に月次更新が実行されます。
- 月次メンテナンスが四半期メンテナンスより0-24時間前に開始するようにスケジュールされている場合、月次メンテナンスはスケジュールどおりに実行されません。かわりに、待機して四半期メンテナンスの直後に実行されます。四半期メンテナンスが後で再スケジュールされた場合、月次セキュリティ・メンテナンスは即座に開始されます。したがって、四半期メンテナンスと月次メンテナンスを同じ時間にスケジュールすることをお薦めします。そうすると、四半期メンテナンスを直前に再スケジュールした場合、月次メンテナンスはスケジュールの編集直後ではなく、スケジュールされた時間に実行されます。また、四半期メンテナンスの再スケジュール時に、月次セキュリティ・メンテナンスを再スケジュールすることもできます(月次メンテナンスが現在のメンテナンス・ウィンドウ内にある場合にかぎります)。月次メンテナンスはメンテナンス・ウィンドウ内の別の時間に再スケジュールできますが、スキップすることはできません。
四半期メンテナンス前の月次セキュリティ・メンテナンス
- 四半期メンテナンスの前にセキュリティ・メンテナンスを適用するには、四半期メンテナンスの24時間以上前に月次セキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、アプリケーションに影響を与えずにデータベース・サーバーにセキュリティ・パッチをオンラインに適用し、アプリケーションへの影響を最小限に抑えてストレージ・サーバーに更新を適用します(パフォーマンスがわずかに低下する可能性があります)。四半期メンテナンスはスケジュールどおりに実行され、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期メンテナンスの一環として、システムにすでにインストールされているデータベース・サーバーに同じセキュリティ更新が適用されます(セキュリティ回帰はありません)。
- 最新のセキュリティ更新が適用される場合、新しい月次メンテナンス・ウィンドウが開いた後に(通常は月の21日に)月次セキュリティ・メンテナンスを実行するようにスケジュールします。
- ストレージ・サーバーの毎月のセキュリティ・メンテナンスの再起動による影響は最小限に抑える必要があるため、今月のアプリケーションへの影響は、四半期メンテナンス中のデータベース・サーバーの再起動によるものです。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。
月次セキュリティ・メンテナンス前の四半期メンテナンス
- 月次セキュリティ・メンテナンスの前に四半期メンテナンスを実行するには、四半期メンテナンスの開始がスケジュールされる24時間以内に実行されるようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。四半期メンテナンスでは、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期ごとのメンテナンスでは、ストレージ・サーバーのパッチ適用がスキップされる場合とスキップされない場合があります。これは、現在インストールされているリリースより新しいものか古いものかによって異なります。ほとんどの場合、インストールされるバージョンは、四半期メンテナンスに関連付けられているバージョンより新しいバージョンである必要があります。このルールの例外は、メンテナンス四半期の最初の月である場合、または1つ以上の前の月のセキュリティ・メンテナンスをスキップした場合に発生する可能性があります。セキュリティ・メンテナンスは、四半期メンテナンスの完了直後に、またはスケジュールされたいずれか遅い方で実行されます。データベース・サーバーへのオンライン更新(アプリケーションへの影響なし)が適用され、ローリング方式でストレージ・サーバーが更新される可能性があります。場合によっては、四半期メンテナンスにセキュリティ・メンテナンスと同じストレージ・サーバー・リリースが含まれている可能性があり、セキュリティ・メンテナンス・ストレージ・サーバーの更新はスキップされます。
- セキュリティ・メンテナンスの前に四半期メンテナンスを実行するエンド・ユーザーへの影響は、セキュリティ・メンテナンスを最初に実行する場合とほぼ同じである必要があります。四半期ごとのメンテナンスは中断を伴うイベントですが、ストレージ・サーバーを再起動するセキュリティ・メンテナンスによって中断が最小限に抑えられ、セキュリティ・メンテナンスがオンラインのデータベース・サーバーに適用されます。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。これらの2つのメンテナンス・ウィンドウを、エンド・ユーザーに単一のメンテナンス・ウィンドウとして表示されるように連続して実行するようにスケジュールできます。これを行うには、四半期メンテナンスと同時に(または24時間前まで)開始するようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。毎月のセキュリティ・メンテナンスを定期的に適用している場合、ストレージ・サーバーは四半期メンテナンスによってスキップされ、四半期メンテナンスの完了直後にセキュリティ・メンテナンスによって更新されます。
メンテナンスWindowsの最小化
- メンテナンス・ウィンドウの数を最小限に抑えるには(エンド・ユーザーとのネゴシエーションが必要)、四半期メンテナンスと月次メンテナンスを同時にスケジュールします。セキュリティ・メンテナンスはブロックされます。四半期メンテナンスでは、ローリング方式でデータベース・サーバーが更新され、おそらくストレージ・サーバーはスキップされます。セキュリティ・メンテナンスはただちにフォローアップされ、データベース・サーバーをオンラインおよびストレージ・サーバーにローリング方式で更新します。その結果、単一のメンテナンス・ウィンドウでデータベースとストレージ・サーバーが再起動されます。
- 二つの例外がある(1)四半期メンテナンスと月次メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスによってストレージ・サーバー更新が適用され、セキュリティ・メンテナンスはスキップされます。1つのメンテナンス・ウィンドウでも、これは1回のローリング再起動です。2.ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれるリリースより古く、セキュリティ・メンテナンスのリリースより古くなっています。これにより、四半期メンテナンスでストレージが更新され、その後セキュリティ・メンテナンスでストレージも更新されます。これは、前の月のセキュリティ・メンテナンスをスキップした場合にのみ発生する可能性があります。これは、現在のイメージが2か月以上古くなっている必要があるためです。このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。これにより、1つのストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウ(セキュリティ・メンテナンスでは1つ目、その後は四半期メンテナンス)になります。
- エンド・ユーザーへの影響を最小限に抑えるには、常に月次セキュリティ更新を適用し、両方がスケジュールされている月単位で同時にスケジュールします。
Oracleがセキュリティ・メンテナンスをスケジュールする前にExadataインフラストラクチャがプロビジョニングされた場合、セキュリティ・メンテナンスの対象となります。
スケジュールされた月次Exadataインフラストラクチャ・メンテナンスの前にいつでも再スケジュールできます。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
コンソールを使用したOracle管理インフラストラクチャ更新の構成
ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。
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 Cloud Infrastructureの自動四半期メンテナンス・スケジュールを設定するには
メンテナンス・スケジュールの指定は、政府リージョンでは使用できません。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
-
アクセスするクラウドExadataインフラストラクチャに移動します:
「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
リソースの詳細ページの「メンテナンス」または「インフラストラクチャ・メンテナンス」で、「四半期メンテナンス・スケジュール」フィールドの「編集」リンクをクリックします。 - 「自動メンテナンス・スケジュール」ダイアログで「スケジュールの指定」を選択します。
- 「メンテナンス月」で、Exadataインフラストラクチャのメンテナンスを実行する月を四半期ごとに少なくとも1つ指定します。四半期ごとに複数の月を選択できます。事前通知に長いリード・タイム(たとえば、4週間)を指定する場合は、メンテナンス実行を行うことができる月を四半期ごとに2つまたは3つ指定することをお薦めします。これにより、必要なリード・タイムを考慮したうえで、メンテナンス更新が適時に適用されるようになります。リード・タイムについては、後のステップで説明します。
ノート
メンテナンス四半期は、2月、5月、8月、11月に始まり、年の最初のメンテナンス四半期は2月に始まります。 - 「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。
- オプション。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleは影響が最小限になるよう週末の日にメンテナンス更新を実行します。
- オプション。「開始時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合、Oracleは、メンテナンス更新を実行するのに最も影響が少ない時間を選択します。
- 「リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な期間を考慮して、新しくリリースされたメンテナンス更新がスケジュールされます。
- メンテナンス・スケジュールを更新します。
Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
Exadata Cloud Infrastructureのスケジュールされた四半期メンテナンスのプロパティを確認および変更します。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
- アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
クラウドExadataインフラストラクチャ(新しいリソース・モデル): 「Oracle CloudのExadata」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
DBシステム: 「ベア・メタル、VMおよびExadata」で、「DBシステム」をクリックします。DBシステムのリストで、アクセスするExadata DBシステムを検索し、名前をクリックしてその詳細を表示します。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- リソースの詳細ページの「メンテナンス」で、「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。
「Exadata Infrastructureメンテナンス」ページが表示されます。
- 「Exadata Infrastructureメンテナンス」ページに、スケジュール済メンテナンスの詳細がリストされます。
ターゲットDBサーバーのバージョンおよびターゲット・ストレージ・サーバーのバージョン: これらのフィールドには、スケジュールされたメンテナンスによって適用されるExadataソフトウェアのバージョンが表示されます。適用されるバージョンは、クラウド内のExadataインフラストラクチャに対する最新の認定済更新です。メンテナンスがスケジュールされているときに次回の四半期更新がまだ認定されていない場合、新しい四半期更新が使用可能になるまで、バージョンは「最新」と表示されることがあります。更新が使用可能になると、新しいバージョンが表示されます。
データベース・サーバーのExadataソフトウェア・バージョンまたはストレージ・サーバーのExadataソフトウェア・バージョンに関する情報を検索するには、My Oracle SupportノートのExadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)を参照してください。
スケジュール済Exadataインフラストラクチャ・リソース・メンテナンス・イベントごとに、次の詳細が「メンテナンス」ページにリストされます:
- イベントのステータス
- イベントのOCID
- イベントのスケジュール済開始日時
- メンテナンス・イベントをただちに開始するには、「今すぐパッチ」をクリックします。プロンプトが表示されたら、「メンテナンスの実行」をクリックして、イベントを今すぐ開始することを確認します。
リソースのメンテナンス・イベントが開始されるときに、Exadataインフラストラクチャ・リソースによってホストされる1つ以上のVMクラスタでメンテナンス・イベントがすでに進行中の場合、Exadataインフラストラクチャ・リソースのメンテナンス・イベントはキューに入れられ、すべてのVMクラスタ・メンテナンス・イベントが完了した後、ただちに開始されます。
- 次回のスケジュール済メンテナンス設定を変更するには、「メンテナンス実行の編集」をクリックします。
- 「メンテナンスの編集」ページで、次を実行します:
- メンテナンス方法として、「ローリング」または「非ローリング」を選択します。
ノート
「非ローリング」オプションを選択すると、コンポーネントが同時に更新され、完全なシステム・ダウンタイムが発生します。 - DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できる最大タイムアウト。
デフォルト: 30分
最小: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できる最大タイムアウト。
- 次回のメンテナンス実行を再スケジュールするには、「スケジュール開始時間」フィールドに日時を入力します。
次の制限事項が適用されます。
- インフラストラクチャ・メンテナンスは、前のインフラストラクチャ・メンテナンスから180日以内の日付に再スケジュールできます。再スケジュールされたメンテナンス実行より前に新しいメンテナンス・リリースが公開された場合、その新しいリリースが指定した日付に適用されます。メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。現在時刻がスケジュール済メンテナンス開始時刻の2時間以内である場合、メンテナンスは再スケジュールできません。
- Oracleでは、四半期ごとに特定の日付を内部メンテナンス操作のために予約しており、これらの日付にメンテナンスをスケジュールすることはできません。
- 「変更の保存」をクリックします。
- メンテナンス方法として、「ローリング」または「非ローリング」を選択します。
- 様々なコンポーネントの推定メンテナンス時間の詳細を表示するには、「推定メンテナンス時間合計」フィールドの「表示」リンクをクリックします。
「表示」リンクは、メンテナンス方法が「ローリング」の場合にのみ、「推定メンテナンス時間合計」フィールドに表示されます。
「推定メンテナンス時間詳細」ページに、次の詳細が表示されます:- 推定メンテナンス時間合計
- データベース・サーバー推定メンテナンス時間
- ストレージ・サーバー推定メンテナンス時間
- コンポーネントが更新される順序。ローリング・メンテナンスでは、コンポーネントは表示されている順序で更新されます
- データベース・サーバーのメンテナンスの一環として再起動されるVMの数を表示するには、「詳細の表示」リンクをクリックします。
「VMの場所」ダイアログが表示されます。
- 「VMクラスタ名」フィールドで、特定のVMが属するVMクラスタを確認できます。
- 「閉じる」をクリックします。
- 「閉じる」をクリックして、「推定メンテナンス時間詳細」ページを閉じます。
Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには
このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースに対するメンテナンス履歴を表示する方法について説明します。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
-
アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
- リソースの詳細ページの「ベア・メタル、VMおよびExadata」で、「メンテナンス履歴」をクリックします。
- メンテナンス・ジョブ、パッチ適用の状態およびタイプが表示されます。
スケジュールされたインフラストラクチャ・メンテナンス実行のノードのパッチ適用順序を設定するには
このタスクでは、クラウドExadataインフラストラクチャまたはExadata DBシステム・リソースのスケジュール済インフラストラクチャ・メンテナンス実行に対してノードのパッチ適用順序を設定する方法について説明します。
デフォルトでは、スケジュールされたすべてのメンテナンス実行は、最初はローリング・パッチ適用を使用するように設定されています。ローリング以外のパッチ適用を使用するには、スケジュール後にメンテナンス実行ごとにこの設定を変更する必要があります。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Public Cloud上のExadata」.をクリックします
- アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
-
クラウドExadataインフラストラクチャ(新しいリソース・モデル): 「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
-
DBシステム: 「ベア・メタル、VMおよびExadata」で、「DBシステム」をクリックします。DBシステムのリストで、アクセスするExadata DBシステムを検索し、その名前をクリックしてその詳細を表示します。
-
- リソースの詳細ページの「メンテナンス」で、「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。
- 「メンテナンス」ページで、スケジュール済クラウドExadataインフラストラクチャ・メンテナンス実行の「メンテナンス方法」フィールドの「編集」リンクをクリックします。
- 「Exadataインフラストラクチャ・ノードのパッチ適用順序の更新」で、メンテナンス方法を必要に応じて「ローリング」または「非ローリング」に変更します。
ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態により、インフラストラクチャ・リソースのメンテナンスがいつ開始および終了するかをモニターできます。
Oracle Cloud Infrastructureコンソールで、「Exadataインフラストラクチャの詳細」ページにライフサイクル状態の詳細メッセージが表示されます(「ステータス」フィールドの横にツールチップが表示されます)。これらのメッセージには、ListCloudExadataInfrastructures
API、およびSDKやOCI CLIなどのAPIに基づくツールを使用してアクセスすることもできます。
-
メンテナンス・ウィンドウを指定した場合、指定した開始時間にパッチ適用が開始されます。インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変わります。ノート
メンテナンスの開始前に事前チェックが実行されます。 - Exadataデータベース・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャは更新中です」です。
- ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基礎となるインフラストラクチャは更新中であり、これはデータベースの可用性には影響しません」です。
- ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチがローリング方式で1つずつ更新されます。
- メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールにライフサイクル状態メッセージは表示されません。
インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。
Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。スケジュール・リマインダ、パッチ適用の開始、パッチ適用の終了など、スケジュール済メンテナンス実行のためのOracleの準備として、適切なメンテナンス関連イベントが生成されます。すべてのメンテナンス関連イベントの詳細は、Oracle Cloud Exadataインフラストラクチャ・イベントを参照してください。障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成して、インフラストラクチャ・メンテナンス連絡先に通知します。
Oracle Cloud Infrastructure Eventsの詳細は、イベントの概要を参照してください。インフラストラクチャ・メンテナンス連絡先に送信された通知以外の追加の通知を受信するには、インフラストラクチャ・メンテナンス・イベントにサブスクライブし、Oracle Notification Serviceを使用して通知を受信します。通知の概要を参照してください。
インフラストラクチャ・メンテナンス連絡先の管理
Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。
- Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
Exadataインフラストラクチャ管理者がシステム更新通知に忙殺されないように、メンテナンス通知が送信されるユーザーの電子メール・アドレスを最大10個まで指定できます。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
- 「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックして、デフォルト・コンパートメント内のExadataインフラストラクチャのリストを表示します。「リスト範囲」セクションにある「コンパートメント」ドロップダウンから別のコンパートメントを選択できます。
- Exadataインフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
- 「メンテナンス」セクションで、「顧客の連絡先」フィールドの「管理」をクリックして「連絡先の管理」ダイアログを表示します。
- 「連絡先の追加」ボタンをクリックすると、有効な電子メール・アドレスを入力するフィールドが表示されます。Exadataインフラストラクチャごとに最大10個のメンテナンス連絡先を設定できます。
- 電子メール・アドレスを編集するには、「連絡先の管理」ダイアログで、編集する電子メール・アドレスの前にあるボックスを選択し、「編集」ボタンをクリックします。
- リストから電子メール・アドレスを削除するには、「連絡先の管理」ダイアログで、削除する電子メール・アドレスの前にあるボックスを選択し、「削除」ボタンをクリックします。
親トピック: インフラストラクチャ・メンテナンス連絡先の管理
APIを使用したExadata Cloud Infrastructureのメンテナンス制御の管理
次のAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス制御およびリソースを管理します。
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
次のAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス制御を管理します。
クラウドExadataインフラストラクチャ・リソース(新しいリソース・モデル):
親トピック: クラウド・インフラストラクチャのメンテナンス更新