Oracle管理インフラストラクチャ・メンテナンスの構成
Oracleは、すべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を「Exadataクラウド・インフラストラクチャ」で実行します。
Oracleは、「Exadataクラウド・インフラストラクチャ」インフラストラクチャに対して定期的なメンテナンスを実行して、データベースの可用性、整合性およびセキュリティに影響を与える可能性のある潜在的な問題がないことを確認します。 インフラストラクチャで実行されているソフトウェアを最新の製品およびセキュリティ修正で更新すると、データおよびOracle Cloudの全体的なコンプライアンスが保護されます。 これらの更新は自動化された方法で実行され、すべてのベスト・プラクティスが含まれるため、インフラストラクチャの維持にあらゆる労力を費やす必要がなくなります。 Oracleの更新には、物理データベース・サーバー・ホスト、ストレージ・サーバー、ネットワーク・ファブリック・スイッチ、管理スイッチ、配電盤(PDU)、統合ライト・アウト管理(ILOM)インタフェース、およびコントロール・プレーン・サーバーが含まれます。
Oracleでは、次の2つのタイプのインフラストラクチャ・メンテナンスが実行されます:
- 四半期メンテナンスは3か月ごとに適用され、製品の修正、拡張機能およびセキュリティ修正を含めることができます。
- 月次メンテナンスでは、オンラインで適用できる重要なセキュリティ修正のみが適用され、コンポーネントが最高のセキュリティ標準で維持され、セキュリティ脆弱性はできるだけ早く修正されます。
四半期メンテナンス
Oracleは、ローリング・メンテナンス操作を使用してアプリケーションに四半期メンテナンスの影響を最小限に抑え、更新プロセス全体でデータベースの可用性を維持します。 ローリング・メンテナンスでは、各データベース・サーバーが一度に1つずつ再起動され、一度に最大1つのサーバーがオフラインになります。 高可用性のために設計されたアプリケーションは、中断することなく、使用可能なデータベース・インスタンス間でデータベース接続を自動的かつ透過的に移行するため、ダウンタイムをスケジュールする必要がなくなります。 ストレージ・サーバーの更新もローリング方式で適用されます。 ストレージ・サーバーの再起動はデータベース・サービスに影響しないため、アプリケーションには影響しません。
Oracleでは、四半期メンテナンス・スケジュールを完全に制御できるため、ビジネス・ユーザーへの影響を最小限に抑える期間にメンテナンスをスケジュールできます。 四半期メンテナンスがいつ適用されるかを完全に管理および表示できます。 また、予期しないビジネス上の問題が発生した場合にメンテナンスを再スケジュールすることもできます。
月次セキュリティ・メンテナンス
毎月のセキュリティ・メンテナンスは、データベース・サーバー上でオンラインで実行され、再起動は行われず、アプリケーションへの影響もありません。 月次更新は、ローリング方式でストレージ・サーバーに適用され、アプリケーションにも影響を与えません。
月次セキュリティ・メンテナンスは、1つのメンテナンス・ウィンドウにあっても、月の特定の時間にスケジュールすることもできます。 Oracleは、メンテナンス期間の開始の少なくとも1週間前に月次メンテナンスのスケジュールを公開し、必要に応じて再スケジュールできます。
- 「Oracle管理のExadata Cloud Infrastructureメンテナンスについて」
Oracleは、「Exadataクラウド・インフラストラクチャ」上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。 - 「四半期インフラストラクチャ・メンテナンス・プロセスの概要」
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、続いてストレージ・サーバーが更新されます。 - 「月次セキュリティ・メンテナンスの概要」
四半期メンテナンスとともに実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月単位で実行され、すべてのCVSSスコアにわたる脆弱性の修正が含まれます。 - 「同月の月次および四半期メンテナンスについて」
- 「メンテナンス・スケジューリング・ポリシー」
OCIコンソールを使用して、メンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。 - 「コンソールを使用したOracle管理のインフラストラクチャ更新の構成」
ソフトウェア更新は四半期ごとおよび月ごとにスケジュールされます。 コンソールを使用して、スケジュールおよび計画を行うことができます。 - 「スケジュール計画から作成された四半期メンテナンス実行の管理」
- 「ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスの監視」
Exadata Infrastructureリソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。 - 「インフラストラクチャ・メンテナンス更新に関する通知の受信」
通知を受信するには、2つの方法があります。 一方はインフラストラクチャ・メンテナンス連絡先への電子メールによるもので、もう一方はメンテナンス・イベントをサブスクライブして通知を受け取ることです。 - 「インフラストラクチャ・メンテナンス連絡先の管理」
Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。 - 「APIを使用したExadata Cloud Infrastructureのメンテナンス制御の管理」
これらのAPI操作を使用して、「Exadataクラウド・インフラストラクチャ」メンテナンス・コントロールおよびリソースを管理します。
親トピック: How-toガイド
Oracle管理の「Exadataクラウド・インフラストラクチャ」メンテナンスについて
Oracleは、「Exadataクラウド・インフラストラクチャ」上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。
更新の頻度は、次のようにリージョン・タイプによって異なります:
- 商業リージョン: Oracleは、四半期ごとのインフラストラクチャ更新および月次のセキュリティ・インフラストラクチャ更新を実行します。
- 政府リージョン: Oracleは、毎月のフル・インフラストラクチャ・メンテナンス更新を実行します。
まれではないすべての状況で、これらの更新に関する事前通信を受信して計画に役立てます。 VMクラスタ仮想マシン(VM)に対応する推奨の更新がある場合、Oracleはその通知を提供します。
可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を維持する方法で実行されます。 ただし、更新プロセス中は個々のシステム・コンポーネントを使用できませんが、パフォーマンスとスループットに多少の影響を与える可能性があります。
たとえば、データベース・サーバーのパッチ適用には通常、再起動が必要です。 このような場合、可能であれば、データベース・サーバーはローリング方式で一度に1つずつ再起動されるため、プロセス全体でサービスが使用可能になります。 ただし、再起動の間、各データベース・サーバーは短時間使用できなくなり、それに応じてサービス容量全体が減少します。 アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。 たとえば、データベース・サーバーのパッチ適用の実行中にアプリケーションを停止します。
ノート:
Oracle Cloud Infrastructure (OCI)米国政府(OC2)リージョンおよび米国国防総省(OC3)リージョンでExadata Database on Dedicated Infrastructureを使用するお客様は、OCIコンソールを使用して、月次および四半期ごとのパッチ適用イベントを再スケジュールできます。
現時点では、Exadata Cloud Infrastructureのパッチ管理スケジュールの設定と呼ばれるメンテナンス・スケジュールの指定は、Exadataパッチ管理用のOCI US Government (OC2)およびUS DOD (OC3)レルムではまだ使用できません。 パッチ管理の再スケジュールに関するExadata Database on Dedicated Infrastructureの詳細は、「こちら」を参照してください。
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
四半期インフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。
ローリング・インフラストラクチャのメンテナンスは、Exadataデータベース・サーバー・ホストから始まります。 ローリング・メンテナンス・メソッドでは、データベース・サーバーは一度に1つずつ更新されます。 各データベース・サーバー・ホストVMが停止され、ホストが更新されて再起動され、VMが起動され、他のデータベース・サーバーは引き続き稼働状態になります。 このローリング・メンテナンスは、高可用性のために設計されたアプリケーションには影響しません。 ローリング・インスタンスの再起動を処理するために書き込まれていない古いアプリケーションが影響を受ける可能性があります。 このプロセスは、すべてのサーバーが更新されるまで続行されます。
データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。 ローリング・メンテナンス・メソッドの場合、ストレージ・サーバーは一度に1つずつ更新されるため、データベースまたはアプリケーションの可用性には影響しません。 ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーを一度に1つずつオフラインにし(使用可能なIO容量を削減)、オンラインに戻すと再同期(データベース・サーバーでのオーバーヘッドが少ない)されるため、IOパフォーマンスが低下する可能性があります。 データベースおよびストレージ・インフラストラクチャのサイズを適切に設定して、メンテナンスされていないデータベースおよびストレージ・サーバーに分散される作業の増加に対応することで、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。
非ローリング・メンテナンスを選択して、データベースおよびストレージ・サーバーを更新することもできます。 非ローリング・メンテナンス・メソッドは、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。 非ローリング・メンテナンスではメンテナンス時間が最小限になりますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。
ローリング・メンテナンス・プロセス中にデータベースが使用可能であることが予想される間、自動メンテナンスはOracle Clusterwareが実行中であることを検証しますが、サーバーがオンラインに戻った後にすべてのデータベース・サービスおよびプラガブル・データベース(PDB)が使用可能であることは検証しません。 メンテナンス後のデータベース・サービスおよびPDBの可用性は、アプリケーション・サービス定義によって異なる場合があります。 たとえば、特定の優先ノードおよび使用可能なノードで構成されたデータベース・サービスは、メンテナンス中に再配置され、メンテナンスの完了後に元のノードに自動的に再配置されません。 Oracleでは、「Exadata Cloudシステムでのアプリケーションの継続的な可用性の実現」のドキュメントを確認して、アプリケーションへの影響の可能性を減らすことをお薦めします。 ドキュメントのガイドラインに従うことで、データベース・サーバーが順次更新されるため、インフラストラクチャ・メンテナンスの影響は軽度のサービスの低下にすぎません。
Oracleでは、Maximum Availability Architecture (MAA)のベスト・プラクティスに従い、Data Guardを使用して重要なアプリケーションに最高の可用性を確保することをお薦めします。 Data Guardが有効なデータベースの場合、Oracleでは、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。 また、プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前にスイッチオーバーを実行することもできます。 これにより、インフラストラクチャ・メンテナンス時のプライマリ・データベースへの影響を回避できます。
事前チェックは、メンテナンス・ウィンドウの開始前に「Exadataクラウド・インフラストラクチャ」コンポーネントに対して実行されます。 事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。 Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。 初期事前チェックはメンテナンス開始の約5日前に実行され、メンテナンス開始の約24時間前に別の事前チェックが実行されます。 事前チェックで、メンテナンス通知の再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に送信されます。
インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス・メソッド、およびカスタム・アクションが有効になっているかどうかによって異なります。 推定時間は概算です。 カスタム・アクションの時間(構成されている場合)は、次の見積に含まれません。 データベース・サーバーのメンテナンス時間は、更新前に各VMをシャットダウンし、次のノードに進む前に各ノードの更新後に各VMおよび関連リソースを起動するために必要な時間によって異なる場合があります。 ストレージ・サーバーのメンテナンス時間は、ASMのリバランスに必要な時間によって異なります。この時間は、次の見積りには含まれません。 メンテナンス中に問題が発生した場合、表示されるおおよその時間を超えて完了が遅延する可能性があります。 このような状況では、Oracleクラウド操作で解決が予想されるウィンドウを超えて延長されると、通知が送信され、メンテナンスが再スケジュールされる場合があります。
ノート:
これらの操作はインフラストラクチャのメンテナンス操作によって影響を受ける可能性があるため、パッチ適用期間中はデータベースまたはアプリケーションに対して主要なメンテナンス操作を実行しないでください月次セキュリティ・メンテナンスの概要
四半期メンテナンスとともに実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月単位で実行され、すべてのCVSSスコアにわたる脆弱性の修正が含まれます。
ノート:
CVEリリース・マトリックスの詳細は、Exadata Database MachineおよびExadata Storage Serverのサポートされるバージョン(ドキュメントID 888828.1)を参照してください。Exadata Infrastructureバージョンに固有のCVEリリース・マトリックスを表示するには、Exadataバージョン(Exadata 23など)をクリックします。 バージョン固有のCVEリリース・マトリックスは、表のノート列にリストされています。
セキュリティ・メンテナンスは、必要に応じて、各月の18th-21stの間に開始され、翌月の9th-12thまで実行される21日のウィンドウ中に適用されるようにスケジュールされます。 顧客は、月次メンテナンス・ウィンドウの開始の少なくとも7日前に提案されたスケジュールの通知を受信し、必要に応じて、月次メンテナンスをウィンドウの別の日付に再スケジュールできます。 月次セキュリティ・メンテナンス・プロセスは、物理データベース・サーバーを更新して、重要なセキュリティの脆弱性および重要な製品の問題を修正します。 また、月次メンテナンスでは、ストレージ・サーバーをExadata Storageソフトウェア・イメージに更新し、セキュリティの既知の脆弱性と製品の問題を解決します。 顧客管理ゲストVMに更新は適用されません。 また、月次メンテナンスでは、ストレージ・サーバーをExadata Storageソフトウェア・イメージに更新し、セキュリティの既知の脆弱性と製品の問題を解決します。
データベース・サーバーへの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新は、VMおよびデータベースを含むVM内のすべてのプロセスが稼働している間、ホスト・サーバーにオンラインで適用されるためです。 サーバーおよびVMは再起動されません。 ストレージ・サーバーへの更新は、ローリング方式で適用されます。 四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションに対して最小限に抑える必要があります。
ノート:
月次インフラストラクチャのメンテナンスでサポートされる操作は、CPUのスケーリングとVMの起動/停止のみです。同月の月次および四半期メンテナンスについて
四半期と月の両方のセキュリティ・メンテナンスが同じ月に実行されるようにスケジュールされている場合は、特別な考慮事項があります。 四半期メンテナンスでは、セキュリティ・メンテナンスによってすでに適用されているセキュリティ修正が再適用され、既存のストレージ・サーバーのバージョンが更新に含まれるバージョンと同じか新しい場合は、四半期メンテナンスも月次メンテナンスもストレージ・サーバー更新を適用しません。
- 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前の月から最新のExadataリリースを使用します。 その時点で追加のセキュリティ修正が使用可能な場合は、それらの更新が四半期メンテナンスに含まれます。 このイメージは、四半期全体にわたって使用されます。 たとえば、1月のリリースは、2月、3月および4月の四半期メンテナンスに使用されます。
- 四半期メンテナンスが適用されると、データベース・サーバーに以前にインストールされたセキュリティ更新が、適用される四半期メンテナンス・リリースに含まれていない可能性があります。 その場合、自動化では、四半期メンテナンスによってインストールされた新しいリリースに同じセキュリティ修正が適用されるため、セキュリティ修正が低下することはありません。 ストレージ・サーバーの現在のイメージが、四半期または月次セキュリティ・メンテナンスによって適用されるイメージと同じかそれより新しい場合、そのメンテナンスはストレージ・サーバーに対してスキップされます。
月次メンテナンスがスケジュールされてから24時間以内に四半期メンテナンスがスケジュールされている場合、スケジュールされた月次メンテナンスはスキップされ、かわりに四半期メンテナンスの直後に月次更新が適用されます。
- 同時にスケジュールすると、四半期メンテナンスの完了直後に月次更新が実行されます。
- 月次メンテナンスが四半期メンテナンスの0-24時間前に開始するようにスケジュールされている場合、月次メンテナンスはスケジュールどおりには実行されず、かわりに四半期メンテナンスの直後に実行されます。 四半期メンテナンスがその後再スケジュールされると、月次セキュリティ・メンテナンスがただちに開始されます。 したがって、Oracleでは、四半期メンテナンスと月次メンテナンスを同時にスケジュールすることをお薦めします。 その結果、四半期ごとに最終時点で再スケジュールすると、スケジュールの編集直後になく、月次メンテナンスがスケジュールされた時間に実行されます。 月次メンテナンスを現在のメンテナンス・ウィンドウ内に保持しているかぎり、四半期メンテナンスを再スケジュールするときに月次セキュリティ・メンテナンスを再スケジュールすることもできます。 月次メンテナンスはメンテナンス・ウィンドウで別の時間に再スケジュールできますが、スキップできません。
四半期メンテナンス前の月次セキュリティ・メンテナンス
- 四半期メンテナンスの前にセキュリティ・メンテナンスを適用するには、月次セキュリティ・メンテナンスを四半期メンテナンスの24時間以上前に実行するように再スケジュールします。 セキュリティ・メンテナンスは、アプリケーションに影響を与えずにデータベース・サーバーにセキュリティ・パッチをオンラインで適用し、アプリケーションへの影響を最小限に抑えてストレージ・サーバーに更新を適用します(パフォーマンスが若干低下する可能性があります)。 四半期メンテナンスはスケジュールどおりに実行され、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれていないアプリケーションに影響します。 四半期メンテナンスの一環として、システムにすでにインストールされているデータベース・サーバーに同じセキュリティ更新が適用されます(セキュリティの低下はありません)。
- 最新のセキュリティ更新の適用に関心がある場合は、新しい月次メンテナンス・ウィンドウが開いた後(通常は月の21日)、月次セキュリティ・メンテナンスの実行をスケジュールします。
- ストレージ・サーバーをリブートする月次セキュリティ・メンテナンスの影響は最小限に抑える必要があるため、この月のアプリケーションへの影響は、四半期メンテナンス中のデータベース・サーバーの再起動のみによるものです。 ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。
月次セキュリティ・メンテナンス前の四半期メンテナンス
- 月次セキュリティ・メンテナンスの前に四半期メンテナンスを実行するには、四半期メンテナンスの開始がスケジュールされる24時間前までにセキュリティ・メンテナンスを再スケジュールします。 セキュリティ・メンテナンスは、四半期ごとのメンテナンスが完了するまで延期されます。 四半期メンテナンスでは、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれていないアプリケーションに影響します。 四半期メンテナンスでは、ストレージ・サーバーのパッチ適用がスキップされる場合とスキップされない場合があります。 これは、現在インストールされているリリースより新しいか古いかによって異なります。 ほとんどの場合、インストールされるバージョンは、四半期メンテナンスに関連付けられているバージョンより新しいものである必要があります。 このルールの例外は、メンテナンス四半期の最初の月である場合、または1か月以上前にセキュリティ・メンテナンスをスキップした場合に発生します。 セキュリティ・メンテナンスは、四半期メンテナンスの完了直後、またはスケジュールされたいずれか後のいずれか後に実行されます。 これは、オンライン更新をデータベース・サーバーに適用し(アプリケーションの影響なし)、ストレージ・サーバーをローリング方式で更新します。 場合によっては、四半期ごとのメンテナンスにセキュリティ・メンテナンスと同じストレージ・サーバー・リリースが含まれている場合があり、セキュリティ・メンテナンス・ストレージ・サーバーの更新はスキップされます。
- セキュリティ・メンテナンスの前に四半期メンテナンスを実行するエンド・ユーザーへの影響は、最初にセキュリティ・メンテナンスを実行する場合とほぼ同じである必要があります。 四半期メンテナンスは中断を伴うイベントになりますが、ストレージ・サーバーを再起動するセキュリティ・メンテナンスによって中断が最小限に抑えられ、セキュリティ・メンテナンスがオンラインのデータベース・サーバーに適用されます。 ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。 これらの2つのメンテナンス・ウィンドウを、エンド・ユーザーに対して単一のメンテナンス・ウィンドウとして表示されるようにスケジュールできます。 これを行うには、四半期メンテナンスと同時に(または最大24時間前に)セキュリティ・メンテナンスを開始するように再スケジュールします。 セキュリティ・メンテナンスは、四半期ごとのメンテナンスが完了するまで延期されます。 毎月のセキュリティ・メンテナンスを定期的に適用している場合、ストレージ・サーバーは四半期ごとのメンテナンスによってスキップされ、四半期ごとのメンテナンスが完了するとすぐにセキュリティ・メンテナンスによって更新されます。
メンテナンスWindowsの最小化
- メンテナンス・ウィンドウの数を最小化(エンド・ユーザーとのネゴシエーションが必要)するには、四半期メンテナンスと月次メンテナンスを同時にスケジュールします。 セキュリティ・メンテナンスはブロックされます。 四半期メンテナンスでは、データベース・サーバーがローリング方式で更新され、おそらくストレージ・サーバーがスキップされます。 セキュリティ・メンテナンスはただちにフォローアップされ、データベース・サーバーとストレージ・サーバーをローリング方式で更新します。 その結果、単一のメンテナンス・ウィンドウで単一のデータベースとストレージ・サーバーが再起動されます。
- 2つの例外があります。1. 四半期メンテナンスと月次メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスはストレージ・サーバー更新を適用し、セキュリティ・メンテナンスはスキップされます。 お客様のパースペクティブから見ると、これは単一のメンテナンス・ウィンドウでの単一のローリング再起動です。2. ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれるリリースより古いため、セキュリティ・メンテナンスのリリースより古いものです。 これにより、四半期ごとのメンテナンスによってストレージが更新され、セキュリティ・メンテナンスによってストレージも更新されます。 これは、現在のイメージが2か月以上古い必要があるため、前月のセキュリティ・メンテナンスをスキップした場合にのみ発生します。 このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。 これにより、1つのストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウが発生 - 1つ目はセキュリティ・メンテナンス用で、その後は四半期メンテナンス用です。
- エンド・ユーザーへの影響を最小限に抑えるには、常に月次セキュリティ更新を適用し、両方がスケジュールされている月数で同時にスケジュールします。
ノート:
Oracleがセキュリティ・メンテナンスをスケジュールする前にExadata Infrastructureをプロビジョニングした場合、セキュリティ・メンテナンスの対象となります。スケジュールされた月次Exadata Infrastructureメンテナンスの前であれば、いつでも再スケジュールできます。
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
メンテナンス・スケジューリング・ポリシー
OCIコンソールを使用して、メンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。
メンテナンス・スケジューリング・ポリシーは、フリート全体のスケジュールを標準化し、一貫性と効率性を確保します。 単一のポリシーを定義し、それを複数のリソースに適用することで、スケジューリング・プロセスが合理化され、メンテナンス・アクティビティがビジネスのベスト・プラクティスに整合します。
ポリシーは、中央リポジトリとして機能し、ステークホルダーとのメンテナンス・コミットメントを文書化し、調整することで、コンプライアンスと運用効率を向上させます。 集中管理により、コンプライアンス要件への準拠が保証され、単一の制御ポイントからの変更を効率的に調整できます。 さらに、このポリシーにより、フリート内の環境全体で計画メンテナンスに関するコミュニケーションが強化され、より適切な調整と認識が促進されます。
メンテナンス・スケジューリング・ポリシーを使用する場合、インフラストラクチャ・メンテナンスのすべてのスケジューリング・プリファレンスはポリシーから導出されます。 インフラストラクチャ内で定義されているプリファレンスは、ポリシーの使用中は有効ではありません。
- 「メンテナンス・スケジュール・ポリシーのリストの表示」
- 「メンテナンス・スケジューリング・ポリシーの作成」
- 「メンテナンス・スケジュール・ポリシーの詳細の表示」
- 「メンテナンス・スケジュール・ポリシーの編集」
- 「注意が必要な状態のメンテナンス・スケジュール・ポリシーの編集」
- 「メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの表示」
- 「メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの編集」
- 「メンテナンス・スケジュール・ポリシーへの追加のメンテナンスWindowsの追加」
- 「ポリシーに関連付けられたリソースの表示」
- 「メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの削除」
- 「別のコンパートメントへのメンテナンス・スケジューリング・ポリシーの移動」
- 「メンテナンス・スケジュール・ポリシーへのタグの追加」
- 「メンテナンス・スケジューリング・ポリシーの削除」
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
メンテナンス・スケジュール・ポリシーのリストの表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタを使用して、特定のコンパートメントで作成されたポリシーのリストを表示します。
- 「状態」を使用して、ポリシーの状態でフィルタします。
ポリシーの状態は次のとおりです:
- 作成
- 注意が必要
- 使用可能
- 更新
- 失敗
- 削除中
- 削除済
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジューリング・ポリシーの作成
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「メンテナンス・スケジューリング・ポリシーの作成」をクリックします。
- 表示される「メンテナンス・スケジューリング・ポリシーの作成」ウィンドウで、次のように入力します:
- 名: ポリシーのわかりやすい名前を入力します。
- コンパートメント: このリソースを作成するコンパートメントを選択します。
- ケイデンス: 頻度を選択します。
使用可能なオプション:
- 6か月ごと
- 四半期ごと
ノート:
スケジューリング・ポリシーを使用して四半期ごとのインフラストラクチャ・メンテナンスを計画および自動化するには、「四半期」ケイデンスとスケジュールされた開始月の値を「2月」に設定したポリシーを作成する必要があります - 毎月
- スケジュール開始月: 開始月を選択します。
Oracle自動化では、インフラストラクチャ・メンテナンスにこのポリシーを使用する場合、四半期メンテナンス・スケジュールを2月に開始する必要があります。
- メンテナンス・ウィンドウ: Oracle Automationは、スケジュールで定義されたメンテナンス・ウィンドウに従って、スケジュール済アクションを実行するためのメンテナンスを実行します。
- 月: 月を選択します。 月の選択オプションは、選択したポリシー・ケイデンスによって異なります。 6か月の間隔では、第1、第2、第3、第4、第5、または第6の月のいずれかを選択できます。 四半期単位の場合は、各四半期の第1、第2または第3の月を選択できます。
- 週: 月の「第1」、「第2」、「第3」または「第4」のいずれかの週を選択できます。
- 日: 曜日から選択できます: 日曜日、月曜日、火曜日、水曜日、木曜日、金曜日、または土曜日。
- 開始時間: メンテナンスを開始する開始時間を指定します。
- 期間: Database Cloudサービス・アクションを完了するための平均時間の見積りに基づいて、メンテナンス・ウィンドウを計画します。 時間の見積りについては、「四半期インフラストラクチャ・メンテナンス・プロセスの概要」を参照してください。
- ウィンドウの期間を強制: このオプションを有効にすると、構成されたウィンドウ期間を超えるスケジュール済アクションが一時停止され、将来のメンテナンス・ウィンドウで再開するように再スケジュールされます。
ノート:
更新またはアクションがすでに進行中で、中断を発生させずに一時停止および再開できない場合は、続行してアクションを完了します。 Oracle Automationは、構成済のウィンドウ期間後に開始する予定のアクションを将来のメンテナンス・ウィンドウに再スケジュールします。
- Show Advanced Options:
- タグ: (オプション)タグの適用を選択できます。 リソースの作成権限がある場合、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、リソース・タグを参照してください。 タグを適用する必要があるかどうかわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
ノート:
作成後に、スケジュール・ポリシーにメンテナンス・ウィンドウを追加できます。親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーの詳細の表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 詳細を表示するポリシーの名前をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーの編集
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 編集するポリシーの名前をクリックします。
- 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「スケジュール・ポリシーの編集」をクリックします。
- 表示された「スケジューリング・ポリシーの編集」ウィンドウで、ポリシーの名前のみを編集できます。
- 名前を編集し、「スケジュール・ポリシーの編集」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
注意が必要な状態のメンテナンス・スケジュール・ポリシーの編集
ノート:
メンテナンス・ウィンドウなしのスケジュール・ポリシーを使用して、サービス全体のメンテナンス・アクティビティを計画および自動化することはできません。そのため、「注意が必要」ライフ・サイクル状態になります。 ポリシーにウィンドウが定義されていませんが、ケイデンスやスケジュール開始月など、すべてのプロパティを変更できます。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
-
「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「注意が必要」状態のポリシーの名前をクリックします。
- 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「スケジュール・ポリシーの編集」をクリックします。
- 表示された「スケジューリング・ポリシーの編集」ウィンドウで、ポリシー設定を更新します。
- 「スケジュール・ポリシーの編集」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- メンテナンス・ウィンドウの詳細を表示するポリシーの名前をクリックします。
結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの編集
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- メンテナンス・ウィンドウの詳細を編集するポリシーの名前をクリックします。
結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。
- 編集するメンテナンス・ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの編集」を選択します。
- 表示された「メンテナンス・ウィンドウの編集」ページで、変更を行い、「保存」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーへの追加のメンテナンスWindowsの追加
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- メンテナンス・ウィンドウを追加するポリシーの名前をクリックします。
結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。
- 「メンテナンス・ウィンドウの追加」をクリックします。
ノート:
セキュリティ・メンテナンスの場合、スケジュールされた開始時間を21日のウィンドウ内に追加できます。 - 表示された「メンテナンス・ウィンドウの追加」ページで、詳細を追加し、「追加」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
ポリシーに関連付けられたリソースの表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 関連付けられたリソースを表示するポリシーの名前をクリックします。
結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「関連リソース」セクションには、ポリシーに関連付けられているリソースがリストされます。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの削除
ノート:
メンテナンス・アクティビティを計画および自動化するためにリソースによって使用されないメンテナンス・ウィンドウのみをポリシーから削除できます。 サービスでメンテナンスを自動化するためにすでに使用されているウィンドウは削除できません。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- メンテナンス・ウィンドウを削除するポリシーの名前をクリックします。
結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。
- 削除するメンテナンス・ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
- 表示されるメンテナンス・ウィンドウの削除ダイアログで、メンテナンス・ウィンドウの名前を入力し、「メンテナンス・ウィンドウの削除」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
別のコンパートメントへのメンテナンス・スケジューリング・ポリシーの移動
ノート:
ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 別のコンパートメントに移動するポリシーの名前をクリックします。
- 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「リソースの移動」をクリックします。
- 表示される「別のコンパートメントへのリソースの移動」ダイアログで、コンパートメントを選択し、「リソースの移動」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジュール・ポリシーへのタグの追加
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- タグを追加するポリシーの名前をクリックします。
- 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「タグの追加」をクリックします。
- 表示される「タグの追加」ダイアログで、タグを追加し、「タグの追加」をクリックします。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジューリング・ポリシーの削除
ノート:
ポリシーは、いずれかのリソースがメンテナンス・アクティビティの計画および自動化に使用している場合、削除できません。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 削除するポリシーの名前をクリックします。
- 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「削除」をクリックします。
- 表示された「メンテナンス・ポリシーの削除」ダイアログで、ポリシーの名前を入力し、「メンテナンス・ポリシーの削除」をクリックします。
ノート:
ポリシーは、メンテナンス・スケジューリング・プランで使用されている場合、削除できません。
親トピック: メンテナンス・スケジューリング・ポリシー
コンソールを使用したOracle管理インフラストラクチャの更新の構成
ソフトウェア更新は四半期ごとおよび月ごとにスケジュールされます。 コンソールを使用して、スケジュールおよび計画を行うことができます。
「Exadataクラウド・インフラストラクチャ」ソフトウェアの完全な更新は、商用リージョンの場合は四半期ベースで、政府リージョンの場合は月次でスケジュールされます。 さらに、重要なセキュリティ更新は毎月スケジュールされます。 これらのインフラストラクチャの更新をオプトアウトすることはできませんが、OracleはCloud Notification Portalを使用して事前にアラートを送信し、スケジュールの柔軟性を利用して計画に役立てることができます。
四半期インフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。 Oracle Cloud InfrastructureコンソールのExadata Infrastructureの詳細ページで、メンテナンス・メソッドの編集、カスタム・アクションの有効化、スケジュール済メンテナンス実行とメンテナンス履歴の表示、メンテナンス連絡先の管理を行うこともできます。
ノート:
スケジューリング・ポリシーは、四半期ごとのインフラストラクチャ・メンテナンス更新に使用できます。 ただし、月次セキュリティ更新では、メンテナンスのスケジュール・ポリシーはサポートされません。 Oracle Automationにより、インフラストラクチャの月次セキュリティ更新が自動的にスケジュールされます。
- 「四半期メンテナンス・プリファレンスを表示または編集するには」
- 「スケジュール・ポリシーを使用した四半期メンテナンス・プランの管理」
- 「Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには」
スケジュールされた四半期メンテナンス「Exadataクラウド・インフラストラクチャ」のプロパティを確認および変更します。 - 「メンテナンス進行中のメンテナンスの表示および編集」
メンテナンスの進行中に、カスタム・アクションを有効または無効にして、カスタム・アクションのタイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。 - 「メンテナンスがカスタム・アクションを待機中のメンテナンスの表示および編集」
メンテナンスの進行中に、カスタム・アクションを有効または無効にして、カスタム・アクションのタイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。 - 「スケジュールされたセキュリティ・メンテナンスを表示または編集するには」
次回のスケジュール済セキュリティ・メンテナンスを表示および編集する方法について学習します。 - 「Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには」
このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースのメンテナンス履歴の表示方法について説明します。 - 「スケジュールされたインフラストラクチャ・メンテナンス実行のノード・パッチ適用順序を設定するには」
このタスクでは、クラウドExadataインフラストラクチャまたはExadata DBシステム・リソースに対してスケジュールされたインフラストラクチャ・メンテナンス実行のノード・パッチ適用順序を設定する方法について説明します。
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
四半期メンテナンス・プリファレンスを表示または編集するには
このタスクでは、四半期メンテナンス・プリファレンスの設定方法について説明します。 変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされている変更は適用されません。
ノート:
メンテナンス・スケジュールの指定は、政府リージョンでは使用できません。- ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- アクセスするクラウドExadataインフラストラクチャに移動します:
Oracle Exadata Database Service on Dedicated Infrastructureセクションで、Exadata Infrastructureをクリックします。 インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、そのハイライト表示されている名前をクリックして詳細ページを表示します。
インフラストラクチャの詳細ページが表示されます。
- 「メンテナンス作業環境の編集」をクリックします。
「メンテナンス作業環境の編集」ページが表示されます。
ノート:
メンテナンス作業環境の変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。 - 「メンテナンス作業環境の編集」ページで、次を構成します:
- メンテナンス・スケジューリング・プリファレンス: Oracle管理スケジュール
- メンテナンス・メソッドを選択してください:
- ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
ノート:
カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。デフォルト: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
- 「変更の保存」をクリックします。
ノート:
次回のメンテナンス実行以降は、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分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
- 拡張オプションの表示:
- 月次セキュリティ・インフラストラクチャ・メンテナンスの有効化: 月次セキュリティ・インフラストラクチャ・メンテナンスを実行するには、このチェック・ボックスを選択します。
- メンテナンス・プリファレンスを構成します: 各四半期のメンテナンス時間プリファレンスを定義します。 1つの四半期に複数のプリファレンスが定義されている場合、Oracle Automationはそれらのいずれかを選択して、インフラストラクチャ内のすべてのコンポーネントでメンテナンスを実行します。
- メンテナンス・スケジュール: スケジュール・ポリシーからのメンテナンス・ウィンドウ・プリファレンスの使用
インフラストラクチャのプロビジョニング中に、スケジューリング・ポリシーを選択した後、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。 推奨される計画では、期間に基づいてポリシーからメンテナンス・ウィンドウにすべてのDBサーバー、ストレージ・サーバーの順にスケジュールします。 インフラストラクチャのプロビジョニング後、「メンテナンス・スケジューリング計画」リソースを編集してスケジューリング計画を更新し、特定のコンポーネントに更新をカスタマイズして、スケジューリング・ポリシーの異なるウィンドウに合せることができます。
- 「ポリシーの選択」をクリックします。
- 表示される「メンテナンス・スケジューリング・ポリシーの選択」ウィンドウで、コンパートメントとポリシーを選択します。
メンテナンス・スケジューリング・ポリシーを作成して使用することもできます。 詳細は、「メンテナンス・スケジューリング・ポリシーの作成」を参照してください。 ポリシーの作成後に、追加のメンテナンス・ウィンドウをポリシーに追加できます。 詳細は、「メンテナンス・スケジュール・ポリシーへの追加のメンテナンスWindowsの追加」を参照してください。
- 「変更の保存」をクリックします。
ノート:
変更は、次のメンテナンス実行から有効になります。アタッチされたポリシーで作成された関連付けられたメンテナンス・プランを削除する変更を行う前に、確認ダイアログで現在使用されているポリシー名を入力して選択を確認する必要があります。- インフラストラクチャに対して推奨されるメンテナンス・プランが作成および保存された後に、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更
- スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびインフラストラクチャに沿ったメンテナンス・プリファレンスの定義への変更
- スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびOracle管理のスケジュールに従って更新を適用することに変更します。
前述の変更はすべて、現在のポリシーで作成されたインフラストラクチャのスケジューリング計画を削除し、後で同じポリシーをアタッチした場合、Oracle推奨計画に対するカスタマイズはすべて失われます。
- メンテナンス・スケジュール: このインフラストラクチャのメンテナンス・プリファレンスを定義します。
- メンテナンス・スケジューリング・プリファレンス: Oracle管理スケジュール
- 「変更の保存」をクリックします。
ローリングから非ローリング・メンテナンス・メソッドに切り替えると、「非ローリング・メンテナンス・メソッドの確認」ダイアログが表示されます。
- 表示されたフィールドにインフラストラクチャの名前を入力して変更を確認します。
- 「変更の保存」をクリックします。
スケジュール・ポリシーを使用した四半期メンテナンス・プランの管理
スケジューリング・ポリシーが選択されると、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。 推奨される計画では、期間に基づいてポリシーからメンテナンス・ウィンドウにすべてのDBサーバー、ストレージ・サーバーの順にスケジュールします。 メンテナンス計画を更新し、更新を特定のコンポーネントにカスタマイズして、スケジューリング・ポリシーの様々なウィンドウに合せることができます。
- 「四半期メンテナンス・スケジュール・ポリシーの表示」
インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを表示するには、この手順を使用します。 - 「四半期メンテナンス・スケジュール・ポリシーの変更」
インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを変更するには、この手順を使用します。 - 「メンテナンス計画計画の表示」
インフラストラクチャのメンテナンス・スケジュール計画を表示するには、この手順を使用します。 - 「メンテナンス・プランのスケジュール済アクションの編集」
Exadata Cloud@Customerインフラストラクチャ・メンテナンス・スケジューリング・プランのスケジュール済アクションを編集するには、この手順を使用します。
四半期メンテナンス・スケジュール・ポリシーの表示
インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを表示するには、この手順を使用します。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- 四半期メンテナンス・スケジュール・ポリシーを表示するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。 「保守」セクションで、「四半期メンテナンス・スケジュール」ポリシーを見つけます。
- リンクをクリックして、ポリシーの詳細を表示します。
四半期メンテナンス・スケジュール・ポリシーの変更
インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを変更するには、この手順を使用します。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- 四半期メンテナンス・スケジュール・ポリシーを表示するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。 「保守」セクションで、「四半期メンテナンス・スケジュール」ポリシーを見つけます。
- 「メンテナンス作業環境の編集」をクリックします。
スケジュール・ポリシーの「顧客管理スケジュールおよび使用」メンテナンス・ウィンドウのプリファレンスが、ポリシー選択の一部として選択されます。
- 「ポリシーの選択」をクリックします。
- 既存のポリシーを選択するか、ポリシーを作成して選択します。
- 「変更の保存」をクリックします。
ノート:
変更は、次のメンテナンス実行から有効になります。- インフラストラクチャに対して推奨されるメンテナンス・プランが作成および保存された後に、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更するには、確認ダイアログで現在使用されているポリシー名を前に入力して選択を確認する必要があります。
- ポリシー変更により、インフラストラクチャの現在のポリシーで作成されたスケジューリング計画が削除され、後で同じポリシーをアタッチした場合、Oracle推奨プランに対するカスタマイズはすべて失われます。
メンテナンス計画計画の表示
インフラストラクチャのメンテナンス・スケジュール計画を表示するには、この手順を使用します。
このインフラストラクチャのメンテナンス・スケジューリング・プランは、関連付けられたスケジューリング・ポリシーに従って作成され、メンテナンス・ウィンドウ全体で、インフラストラクチャ・コンポーネントが更新されます。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- メンテナンス・スケジュール・プランを表示するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- 「リソース」の下で、「メンテナンス計画計画」をクリックします。
「メンテナンス・スケジュール計画」セクションには、インフラストラクチャに関連付けられたメンテナンス・スケジュール計画が表示されます。 詳細には、プランに関連付けられたメンテナンス・ウィンドウ、ライフサイクル状態、時間単位の期間、スケジュール済アクションおよび見積り時間が含まれます。
ノート:
- すべてのインフラストラクチャ・コンポーネントがメンテナンス・スケジュール・プランの更新にスケジュールされていない場合、コンソールに、プランから欠落しているコンポーネントを示すバナーが表示され、プランには「注意が必要」ライフサイクル状態が反映されます。
- Oracle Automationで次の四半期メンテナンス実行がスケジュールされる前に、欠落しているコンポーネントが計画に含まれていない場合、その四半期のメンテナンス実行の「未計画」メンテナンス・ウィンドウに自動的に追加されます。
メンテナンス・プランのスケジュール済アクションの編集
Exadata Cloud@Customerインフラストラクチャ・メンテナンス・スケジューリング・プランのスケジュール済アクションを編集するには、この手順を使用します。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- メンテナンス・スケジュール・プランを表示するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- 「リソース」の下で、「メンテナンス計画計画」をクリックします。
- 「メンテナンス・スケジューリング・プラン」セクションで、アクションを編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「スケジュール済アクションの編集」を選択します。
- 表示される「スケジュール済アクションの編集」ウィンドウで、次の手順を実行します:
- スケジュール済アクションを追加します:
- 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
- アクション・タイプの選択:
- DBサーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー外で追加のアクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
ノート:
カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。デフォルト: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
- DBサーバーの追加:
- DBサーバーの選択: 選択したDBサーバーに対する更新は、現在スケジュールされているウィンドウからメンテナンス・アクションを追加するウィンドウに移動されます。
- メンテナンス方法の構成:
- ストレージ・サーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
ノート:
非ローリング・ストレージ更新を適用するには、インフラストラクチャ内のすべてのストレージ・サーバーが単一のメンテナンス・アクションで更新されるようにスケジュールする必要があります。 これらの更新は適用されますが、データベース・ワークロードでは完全なダウンタイムが発生します。
- ストレージ・サーバーの選択元: ストレージ・サーバーを追加するウィンドウを選択します。
- 追加するメンテナンス処理の選択: ストレージ・サーバーの追加元となるアクションを選択します。
- 追加するストレージ・サーバーの数を選択します: このアクションに追加するストレージ・サーバーの数を選択します。
- メンテナンス方法の構成:
- DBサーバーのExadata完全ソフトウェア更新
- アクション・タイプの選択:
- 別のウィンドウからの移動処理: アクションを移動するときに、特定のウィンドウで更新するようにスケジュールされたすべてのコンポーネントを新しいウィンドウに移動することを選択できます。
- アクションを移動するウィンドウを選択してください: メンテナンス実行からウィンドウを選択します。
- 移動するアクションを選択します: 移動するメンテナンス・ウィンドウから特定のアクションを選択します。
- 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
- スケジュール済アクションの削除:
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
ノート:
- そのアクションで更新がスケジュールされているコンポーネントがないかぎり、任意のアクションを削除できます。
- 更新がスケジュールされているアクションがそのウィンドウ内にないかぎり、すべてのウィンドウを削除できます。
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
- スケジュール済アクションの編集:
- メンテナンス・アクション・タイプ「DBサーバーの完全なソフトウェア更新」および「ストレージ・サーバーの完全なソフトウェア更新。」の「アクション」メニュー(3つのドット)をクリックし、「スケジュール済アクションの編集」を選択します。
- スケジュール済アクションを追加します:
「Exadataクラウド・インフラストラクチャ」の次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
スケジュールされた四半期メンテナンス「Exadataクラウド・インフラストラクチャ」のプロパティを確認および変更します。
- ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- アクセスするクラウドExadataインフラストラクチャまたはDBシステムにナビゲートします:
クラウドExadataインフラストラクチャ(新しいリソース・モデル): Exadata at Oracle Cloudで、Exadata Infrastructureをクリックします。 インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、そのハイライト表示されている名前をクリックして詳細ページを表示します。
DBシステム: ベア・メタル、VMおよびExadataで、DBシステムをクリックします。 DBシステムのリストで、アクセスするExadata DBシステムを探し、名前をクリックすると詳細が表示されます。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
ノート:
情報ブロックは、ローリング・メンテナンス・メソッドまたは非ローリング・メンテナンス・メソッドを選択したかに関係なく、メンテナンス実行の開始の6時間前に表示されます。 メンテナンスが開始されると、自動的に削除されます。 - リソースの詳細ページの「メンテナンス」で、「次四半期メンテナンス」フィールドの「表示」リンクをクリックします。
Exadata Infrastructureのメンテナンス・ページが表示されます。
ノート:
スケジューリング・ポリシーの使用を選択した場合は、ポリシーへのリンクが表示されます。 リンクをクリックして、メンテナンス・スケジュール・ポリシーの詳細を表示します。 メンテナンス・ウィンドウを編集するには、「スケジュール計画から作成された四半期メンテナンス実行の管理」にリストされているトピックを参照してください。 - 「Exadata Infrastructureメンテナンス」ページに、スケジュール済メンテナンスの詳細がリストされます。
ターゲットDBサーバー・バージョンとターゲット・ストレージ・サーバーのバージョン: これらのフィールドには、スケジュールされたメンテナンスによって適用されるExadataソフトウェアのバージョンが表示されます。 適用されるバージョンは、クラウド内のExadataインフラストラクチャの最新の認定済更新です。 メンテナンスがスケジュールされているときに次の四半期更新がまだ認証されていない場合、新しい四半期更新が使用可能になるまで、バージョンは"LATEST"と表示されることがあります。 更新が使用可能になると、新しいバージョンが表示されます。
Database Server Exadataソフトウェア・バージョンまたはStorage Server Exadataソフトウェア・バージョンの詳細は、My Oracle Supportノート「Exadata Database MachineおよびExadata Storage Serverでサポートされているバージョン(ドキュメントID 888828.1)」を参照してください。
スケジュールされたExadata Infrastructureリソース・メンテナンス・イベントごとに、メンテナンス・ページに次の詳細がリストされます:
- イベントのステータス
- イベントのOCID
- イベントのスケジュールされた開始日時
- メンテナンス・イベントをすぐに開始するには、「今すぐパッチ」をクリックします。 プロンプトが表示されたら、「メンテナンスの実行」をクリックして、イベントをすぐに開始することを確認します。
Exadata Infrastructureリソースがホストする1つ以上のVMクラスタでメンテナンス・イベントがすでに進行中で、そのリソースのメンテナンス・イベントが開始されると、Exadata Infrastructureリソース・メンテナンス・イベントがキューに入れられ、すべてのVMクラスタ・メンテナンス・イベントが完了した直後に開始されます。
- 次のスケジュール済メンテナンス設定を変更するには、「メンテナンス実行の編集」をクリックします。
- 「メンテナンスの編集」ページで、次のようにします:
- メンテナンス・メソッド「ローリング」または「非ローリング」を選択します。
ノート:
「非ローリング」オプションを選択すると、コンポーネントが同時に更新され、システム全体のダウンタイムが発生します。 - DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できる最大タイムアウト。
デフォルト: 30分
最小: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できる最大タイムアウト。
- 次のメンテナンス実行を再スケジュールするには、「予定開始時間」フィールドに日時を入力します。
次の制限が適用されます。
- Oracleは、インフラストラクチャ・メンテナンスを少なくとも四半期に1回実行できると予想しています。 予期しない問題により次のメンテナンス四半期の前での対応が妨げられないかぎり、メンテナンス四半期の終わりを超えてメンテナンスを延期しないでください。
- 予期しない問題により、スケジュールされたインフラストラクチャ・メンテナンス実行に対応できない場合、インフラストラクチャ・メンテナンスを前のインフラストラクチャ・メンテナンスから180日以内に別の日付に再スケジュールできます。 通常のメンテナンスは四半期ごとに実行する必要があるため、インフラストラクチャ・メンテナンスを再スケジュールするためにさらに約90日かかります。 Oracleでは、180日の制限付近にメンテナンスをスケジュールしないことを強くお薦めします。これは、追加の予期しない問題が発生した場合にそれ以上再スケジュールできる柔軟性がないためです。
- 再スケジュールしたメンテナンスの実行前に新しいメンテナンス・リリースが発表された場合、指定した日付に新しいリリースが適用されます。
- メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。 現在の時間がスケジュールされたメンテナンス開始時間から2時間以内である場合は、メンテナンスを再スケジュールできません。
- Oracleでは、各四半期の特定の日付が内部メンテナンス操作用に予約されており、これらの日付にメンテナンスをスケジュールすることはできません。
- 「変更の保存」をクリックします。
- メンテナンス・メソッド「ローリング」または「非ローリング」を選択します。
- 様々なコンポーネントの推定メンテナンス時間の詳細を表示するには、「合計推定メンテナンス時間」フィールドに「ビュー」リンクが表示されます。
「表示」リンクは、Maintenanceメソッドが「ローリング」の場合にのみ「合計見積メンテナンス時間」フィールドに表示されます。
「見積メンテナンス時間の詳細」ページに、次の詳細が表示されます:- 推定メンテナンス時間合計
- データベース・サーバー推定メンテナンス時間
- ストレージ・サーバー推定メンテナンス時間
- コンポーネントが更新される順序。 ローリング・メンテナンスでは、表示される順序でコンポーネントが更新されます
- データベース・サーバーのメンテナンスの一部として再起動される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 Infrastructureをクリックします。 インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、そのハイライト表示されている名前をクリックして詳細ページを表示します。
- リソース詳細ページの「ベア・メタル、VMおよびExadata」で、「メンテナンス履歴」をクリックします。
- メンテナンス・ジョブ、パッチ適用の状態およびタイプが表示されます。
スケジュールされたインフラストラクチャ・メンテナンス実行のノード・パッチ適用順序を設定するには
このタスクでは、クラウドExadataインフラストラクチャまたはExadata DBシステム・リソースに対してスケジュールされたインフラストラクチャ・メンテナンス実行のノード・パッチ適用順序を設定する方法について説明します。
ノート:
デフォルトでは、すべてのスケジュール済メンテナンス実行は、ローリング・パッチ適用を使用するように最初に設定されます。 非ローリング・パッチ適用を使用するには、スケジュールされたメンテナンス実行ごとにこの設定を変更する必要があります。
- ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、「Oracle Public Cloud上のExadata。」をクリック
- アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
-
クラウドExadataインフラストラクチャ(新しいリソース・モデル): Oracle Exadata専用インフラストラクチャ上のデータベース・サービスで、Exadata Infrastructureをクリックします。 インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、そのハイライト表示されている名前をクリックして詳細ページを表示します。
-
DBシステム: ベア・メタル、VMおよびExadataで、DBシステムをクリックします。 DBシステムのリストで、アクセスするExadata DBシステムを探し、名前をクリックすると詳細が表示されます。
-
- リソースの詳細ページの「メンテナンス」で、「次四半期メンテナンス」フィールドのviewリンクをクリックします。
- 「メンテナンス」ページで、スケジュールされたクラウドExadataインフラストラクチャ・メンテナンス実行の「メンテナンス・メソッド」フィールドの「編集」リンクをクリックします。
- 「Exadata Infrastructureノードのパッチ適用順序の更新」で、必要に応じてメンテナンス・メソッドを「ローリング」または「非ローリング」に変更します。
スケジュール計画から作成された四半期メンテナンス実行の管理
- 「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの表示」
- 「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの編集」
- 「メンテナンス実行に関連付けられたメンテナンス処理の表示」
- 「メンテナンス実行に関連付けられたメンテナンス・ウィンドウのメンテナンス処理の編集」
- メンテナンス進行中のメンテナンスの表示および編集
- メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集
- 「進行中のメンテナンス実行の取消」
- 「コンパートメントのメンテナンス・アクティビティの表示」
- 「メンテナンス活動の詳細の表示」
- 「未計画メンテナンス活動のレビューおよび応答」
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
メンテナンス実行に関連付けられたメンテナンス・ウィンドウの表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 開始時間(UTC): ウィンドウ開始時間(UTC)。たとえば、Sun、Jun 23、2024、18:30:58 UTCです。
次の制限が適用されます。
- Oracleは、インフラストラクチャ・メンテナンスを少なくとも四半期に1回実行できると予想しています。 予期しない問題により次のメンテナンス四半期の前での対応が妨げられないかぎり、メンテナンス四半期の終わりを超えてメンテナンスを延期しないでください。
- 予期しない問題により、スケジュールされたインフラストラクチャ・メンテナンス実行に対応できない場合、インフラストラクチャ・メンテナンスを前のインフラストラクチャ・メンテナンスから180日以内に別の日付に再スケジュールできます。 通常のメンテナンスは四半期ごとに実行する必要があるため、インフラストラクチャ・メンテナンスを再スケジュールするためにさらに約90日かかります。 Oracleでは、180日の制限付近にメンテナンスをスケジュールしないことを強くお薦めします。これは、追加の予期しない問題が発生した場合にそれ以上再スケジュールできる柔軟性がないためです。
- 再スケジュールしたメンテナンスの実行前に新しいメンテナンス・リリースが発表された場合、指定した日付に新しいリリースが適用されます。
- メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。 現在の時間がスケジュールされたメンテナンス開始時間から2時間以内である場合は、メンテナンスを再スケジュールできません。
- Oracleでは、各四半期の特定の日付が内部メンテナンス操作用に予約されており、これらの日付にメンテナンスをスケジュールすることはできません。
- タイプ: 計画vs未計画。 インフラストラクチャ・メンテナンス・スケジュール・プランから作成またはこのメンテナンス実行に追加されたすべてのウィンドウは、「計画済」ウィンドウです。 障害、期間強制または予期しないイベントに対処するためにOracle Automationによって作成される他のすべてのウィンドウは、「計画外」ウィンドウとして定義されます。 「未計画」ウィンドウで実行するようにスケジュールされているアクティビティを常にレビューします。
- メンテナンス・アクション: 特定のウィンドウで更新するようにスケジュールされたアクションのサマリー。
サーバー名は、DBサーバーにスケジュールされている更新を識別します。 たとえば、DBサーバーdbServer-1およびdbServer-2に完全更新を適用します。 ストレージ・サーバーの更新は、すべてのストレージ・サーバーのストレージ・レイアウトが同じであるため、カウントとして識別されます。 たとえば、2つのストレージ・サーバーに完全更新を適用します。
- 推定時間: メンテナンス実行のすべてのウィンドウにすべてのインフラストラクチャ・コンポーネントに更新を適用するようにスケジュールされているメンテナンス・アクションをOracle Automationが完了する推定時間。
- 開始時間(UTC): ウィンドウ開始時間(UTC)。たとえば、Sun、Jun 23、2024、18:30:58 UTCです。
メンテナンス実行に関連付けられたメンテナンス・ウィンドウの編集
ノート:
ウィンドウは「スケジュール済」ライフ・サイクル状態のまま、ウィンドウ・スケジュールの開始時間、期間および期間の強制など、ウィンドウ構成を更新できます。 ウィンドウが進行中の場合、構成を変更することはできません。 ウィンドウの実行中のメンテナンスを取り消すことを選択できます。 詳細は、「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの取消」の項を参照してください。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの編集」を選択します。
- 表示されたメンテナンス・ウィンドウの編集ダイアログで、「メンテナンス・ウィンドウの開始時間」、「期間(時間)」および「ウィンドウ期間の強制」フィールドを更新
- 「メンテナンス・ウィンドウの編集」をクリックします。
メンテナンス実行に関連付けられたメンテナンス処理の表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・アクションを表示するアクティビティの名前をクリックします。
- 「リソース」の下で、「メンテナンス・アクション」をクリックします。
- アクションを追加するには:
- 「アクションの追加」をクリックします。
- 表示される「メンテナンス・アクションの追加」ウィンドウの「アクション・タイプの選択」で、「メンテナンス・アクションの追加」をクリックします。
- 処理を削除する手順は、次のとおりです。
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
メンテナンス実行に関連付けられたメンテナンス・ウィンドウのメンテナンス処理の編集
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
-
「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
-
「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
-
関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションを編集します。」を選択します。結果として表示される「メンテナンスの編集」アクション・ページにアクションのリストが表示されます。 アクションを追加することも、既存のアクションを削除することもできます。
- アクションを追加するには:
- 「アクションの追加」をクリックします。
- 表示される「メンテナンス・アクションの追加」ウィンドウで、次の手順を実行します:
- 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
- アクション・タイプの選択:
- DBサーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー外で追加のアクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
ノート:
カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。デフォルト: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。
- DBサーバーの追加:
- DBサーバーの選択: 選択したDBサーバーに対する更新は、現在スケジュールされているウィンドウからメンテナンス・アクションを追加するウィンドウに移動されます。
- メンテナンス方法の構成:
- ストレージ・サーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
-
非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
ノート:
非ローリング・ストレージ更新を適用するには、インフラストラクチャ内のすべてのストレージ・サーバーが単一のメンテナンス・アクションで更新されるようにスケジュールする必要があります。 これらの更新は適用されますが、データベース・ワークロードでは完全なダウンタイムが発生します。
- ストレージ・サーバーの選択元: ストレージ・サーバーを追加するウィンドウを選択します。
- 追加するメンテナンス処理の選択: ストレージ・サーバーの追加元となるアクションを選択します。
- 追加するストレージ・サーバーの数を選択します: このアクションに追加するストレージ・サーバーの数を選択します。
- メンテナンス方法の構成:
- DBサーバーのExadata完全ソフトウェア更新
- アクション・タイプの選択:
- 別のウィンドウからアクションを移動: アクションを移動するときに、特定のウィンドウで更新するようにスケジュールされたすべてのコンポーネントを新しいウィンドウに移動することを選択できます。
- アクションを移動するウィンドウを選択してください: メンテナンス実行からウィンドウを選択します。
- 移動するアクションを選択します: 移動するメンテナンス・ウィンドウから特定のアクションを選択します。
- 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
- 処理を削除する手順は、次のとおりです。
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
ノート:
- そのアクションで更新がスケジュールされているコンポーネントがないかぎり、任意のアクションを削除できます。
- 更新がスケジュールされているアクションがそのウィンドウ内にないかぎり、すべてのウィンドウを削除できます。
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
メンテナンス進行中のメンテナンスの表示および編集
メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
ノート:
「次四半期メンテナンス」フィールドに「メンテナンス中」ステータスが表示されます。 - 「次の四半期メンテナンス」フィールドの「ビュー」リンクをクリックします。
進行中のメンテナンス実行の詳細ページが表示されます。
- メンテナンス実行の詳細ページで「メンテナンス・ウィンドウ」をクリックします。
- 進行中のメンテナンス・ウィンドウを識別
- 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションの編集」を選択します。
- 「アクション」メニュー(3つのドット)をクリックし、「カスタム・アクション構成の編集」を選択します。
- 表示される「カスタム・アクション構成の編集」ページで、「カスタム・アクション(分)」と入力します。
ノート:
メンテナンスの進行中は、DBサーバー・アクション・タイプのカスタム・アクション時間のみ変更できます。 このオプションをサポートするためのカスタム処理時間は、他の処理タイプに対して変更できません。 - 「変更の保存」をクリックします。
メンテナンスがカスタム・アクションを待機している間にメンテナンスを表示および編集
メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- Exadata Infrastructureをクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
ノート:
「次四半期メンテナンス」フィールドに「メンテナンス中」ステータスが表示されます。 - 「次の四半期メンテナンス」フィールドの「ビュー」リンクをクリックします。
進行中のメンテナンス実行の詳細ページが表示されます。
- 表示された「メンテナンス実行」の詳細ページで、「リソース」の下の「メンテナンス・アクション」をクリックします。
メンテナンスがカスタム・アクションを待機している間に、情報ブロックが表示されます。 情報ブロックは、メンテナンスが再開されると削除されます。
- 情報ブロックで、次を実行します:
- 「今すぐメンテナンスを再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。
「メンテナンスの再開」ダイアログが表示されます。 「今すぐメンテナンスを再開」をクリックします。
- 「カスタム・アクション・タイムアウトの拡張」をクリックします。
最大許容時間2時間内にタイムアウトを複数回延長できます。 最大制限を超えて拡張しようとすると、「カスタム・アクション・タイムアウトを拡張できません」ダイアログが表示され、カスタム・アクション・タイムアウトがすでに最大許容時間2時間まで延長されており、それ以上延長できないことが示されます。
- 「今すぐメンテナンスを再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。
進行中のメンテナンス実行の取消
メンテナンス実行に関連付けられたメンテナンス・ウィンドウを取り消すには、次のステップに従います:
ノート:
ウィンドウに対してスケジュールされた更新の進行中に、実行中のメンテナンスを取り消すことができます。 更新の進行中にメンテナンスを取り消すと、まだ開始していないすべてのアクションを、選択した将来のメンテナンス・ウィンドウに再スケジュールできます。 新しい開始時間と期間を選択して、取り消すことにしたメンテナンス・ウィンドウから再スケジュールされたすべてのアクションを終了できます。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 取り消す「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。
進行中のメンテナンス実行を取り消すには、次のステップに従います:
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 取り消す「進行中」アクティビティの名前をクリックします。
- メンテナンス実行の詳細ページで「メンテナンス・ウィンドウ」をクリックします。
- 進行中のメンテナンス・ウィンドウを識別します。
- 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。
- 結果の「メンテナンス実行の取消」ウィンドウで、「メンテナンス・ウィンドウの開始時間」を再構成します。
- 「ウィンドウ期間の強制」チェック・ボックスを選択して、構成済のウィンドウ期間を超えるスケジュール済アクションを一時停止および再スケジュールし、将来のメンテナンス・ウィンドウで再開します。
- 「メンテナンス実行の再スケジュール」をクリックします。
ノート:
メンテナンス実行により、現在の操作が完了します。 このウィンドウにスケジュールされている残りのすべてのアクションは、新しいメンテナンス・ウィンドウに再スケジュールされます。コンパートメントのメンテナンス・アクティビティの表示
ノート:
メンテナンス・アクティビティには、選択したExadataクラウド・サービスの特定のコンパートメント内のすべてのインフラストラクチャ・リソースに対して実行するようにスケジュールされているすべてのメンテナンス更新がリストされます。- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
メンテナンス活動の詳細の表示
- ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。
結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」の下で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。
- 詳細を表示するメンテナンス・アクティビティの「アクション」メニュー(3つのドット)をクリックします。
結果の「メンテナンス実行」ページには、選択したメンテナンス・アクティビティの詳細が表示されます。
未計画メンテナンス活動のレビューおよび応答
メンテナンス計画後にインフラストラクチャをスケーリングする場合の未計画メンテナンス・アクティビティ
- DBサーバーまたはストレージ・サーバーを追加してインフラストラクチャをスケーリングした後、これらの新しいコンポーネントを含めるようにメンテナンス・スケジュール計画を更新する必要がある場合があります。 メンテナンス・プランにインフラストラクチャ・コンポーネントがない場合、インフラストラクチャ・メンテナンス・プランの詳細セクションに警告が表示されます。
- Oracle Automationによって四半期のメンテナンス実行が作成されると、メンテナンス計画に含まれていないコンポーネントはすべて、自動的に「計画外」メンテナンス・ウィンドウに追加されます。 これにより、すべてのコンポーネントに、四半期ごとに正しいシステム・ソフトウェアが適用され、OCIソフトウェアのコンプライアンスが維持されます。
- 必要に応じて、「未計画」ウィンドウの予定開始時間を編集するか、欠落しているコンポーネントの更新を既存の計画ウィンドウに移動できます。
スケジュールされた更新の適用に失敗した場合の未計画メンテナンス・アクティビティ
- スケジュールされた更新が失敗した場合、Oracleオペレーション・チームは、失敗を評価し、失敗した更新を将来のメンテナンス・ウィンドウに対する未完了の更新とともに再スケジュールします。 Oracle Automationにより、この再スケジュールされたウィンドウが「未計画」としてマークされ、再スケジュールされたメンテナンス・アクティビティのレビューが通知されます。
- 必要に応じて、「未計画」ウィンドウの予定開始時間を編集したり、失敗および未完了の更新を既存の計画ウィンドウに移動できます。
スケジュール・アクティビティが強制ウィンドウ期間を超えた場合の未計画メンテナンス
- 期間強制で構成されたメンテナンス・ウィンドウの場合、Oracle Automationは、実行の見積時間を確認し、スケジュール済更新を適用する時間が残りのウィンドウ期間内に十分かどうかをチェックします。 そうでない場合は、Oracle自動化により、未完了のすべての更新が将来の「未計画」ウィンドウに自動的に再スケジュールされ、現在のウィンドウに「期間超過」のマークが付けられ、再スケジュールされたメンテナンス・アクティビティを確認するよう通知されます。
- すでに進行中の更新は、基礎となるリソースの一貫した状態を確保するために、強制されたウィンドウ期間を超えて継続されます。
ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスの監視
Exadata Infrastructureリソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。
Oracle Cloud Infrastructureコンソールでは、「ステータス」フィールドの横にツールチップが表示されると、ライフサイクル状態の詳細メッセージが「Exadata Infrastructure詳細」ページに表示されます。 また、ListCloudExadataInfrastructures APIを使用してこれらのメッセージにアクセスし、APIに基づくツール(SDKsおよびOCI CLIなど)を使用することもできます。
-
メンテナンス・ウィンドウを指定すると、指定した開始時間にパッチ適用が開始されます。 インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変更されます。
ノート:
これで、事前チェックはメンテナンスの開始前に実行されます。 - Exadataデータベース・サーバーのメンテナンスが開始すると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」で、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャを更新しています」です。
- ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」で、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基盤となるインフラストラクチャが更新され、データベースの可用性に影響が及びません」です。
- ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチはローリング方式で一度に1つずつ更新されます。
- メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールはライフサイクル状態メッセージを提供しません。
インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。 一方はインフラストラクチャ・メンテナンス連絡先への電子メールによるもので、もう一方はメンテナンス・イベントをサブスクライブして通知を受け取ることです。
Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。 コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。 スケジュール済メンテナンス実行の準備として、スケジュール・リマインダ、パッチ適用開始、パッチ適用終了などの適切なメンテナンス関連イベントがOracleによって生成されます。 すべてのメンテナンス関連イベントの詳細は、「Oracle Cloud Exadata Infrastructureイベント」を参照してください。 障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成し、インフラストラクチャ・メンテナンス連絡先に通知します。
Oracle Cloud Infrastructureイベントの詳細は、「イベントの概要」を参照してください。 インフラストラクチャ・メンテナンス連絡先に送信された通知以外の通知を受信するには、インフラストラクチャ・メンテナンス・イベントをサブスクライブして、Oracle Notificationサービスを使用して通知を受けることができます(「通知の概要」を参照)。
インフラストラクチャ・メンテナンス連絡先の管理
Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。
- 「Exadata Cloud Infrastructureでメンテナンス連絡先を管理するには」
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
Exadata Cloud Infrastructureでメンテナンス連絡先を管理するには
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
Exadataインフラストラクチャ管理者がシステム更新通知に圧倒されるのを防ぐには、メンテナンス通知が送信されるユーザーの電子メール・アドレスを最大10まで指定できます。
- ナビゲーション・メニューを開きます。 Oracle Databaseをクリックし、Oracle Exadata Database Service on Dedicated Infrastructureをクリックします。
- Oracle Exadata Database Service on Dedicated Infrastructureセクションで、Exadata Infrastructureをクリックして、デフォルトのコンパートメントにExadataインフラストラクチャのリストを表示します。 「リスト・スコープ」セクションにある「コンパートメント」ドロップダウンから、別のコンパートメントを選択できます。
- Exadataインフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、そのハイライト表示されている名前をクリックして詳細ページを表示します。
- 「メンテナンス」セクションで、「顧客担当者」フィールドの「管理」をクリックして、「担当者の管理」ダイアログを表示します。
- 有効な電子メール・アドレスを入力するフィールドを表示するには、「連絡先の追加」ボタンをクリックします。 Exadataインフラストラクチャごとに最大10個のメンテナンス連絡先を設定できます。
- 電子メール・アドレスを編集するには、「担当者の管理」ダイアログで、編集する電子メール・アドレスの前にあるボックスを選択し、「編集」ボタンをクリックします。
- リストから電子メール・アドレスを削除するには、「担当者の管理」ダイアログで、削除する電子メール・アドレスの前にあるボックスを選択し、「削除」ボタンをクリックします。
親トピック: インフラストラクチャ・メンテナンス連絡先の管理
APIを使用したExadata Cloud Infrastructureメンテナンス制御の管理
これらのAPI操作を使用して、「Exadataクラウド・インフラストラクチャ」メンテナンス・コントロールおよびリソースを管理します。
APIの使用およびリクエストの署名の詳細は、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。
これらのAPI操作を使用して、Exadata Cloud Infrastructureメンテナンス・コントロールを管理します。
クラウドExadataインフラストラクチャ・リソース(新しいリソース・モデル):
- ListCloudExadataInfrastructures
- GetCloudExadataInfrastructure
- UpdateCloudExadataInfrastructure
- GetMaintenanceRun
- ListMaintenanceRuns
- UpdateMaintenanceRun
- ListSchedulingPolicies
- CreateSchedulingPolicy
- GetSchedulingPolicy
- UpdateSchedulingPolicy
- DeleteSchedulingPolicy
- ChangeSchedulingPolicyCompartment
- ListRecommendedScheduledActions
- ListSchedulingWindows
- CreateSchedulingWindow
- GetSchedulingWindow
- UpdateSchedulingWindow
- DeleteSchedulingWindow
- ListSchedulingPlans
- CreateSchedulingPlan
- GetSchedulingPlan
- DeleteSchedulingPlan
- ChangeSchedulingPlanCompartment
- ReorderScheduledActions
- ListScheduledActions
- CreateScheduledAction
- GetScheduledAction
- UpdateScheduledAction
- DeleteScheduledAction
- ListParamsForActionType
- ListExecutionWindows
- CreateExecutionWindow
- GetExecutionWindow
- UpdateExecutionWindow
- DeleteExecutionWindow
- ReorderExecutionActions
- ListExecutionActions
- CreateExecutionAction
- GetExecutionAction
- UpdateExecutionAction
- DeleteExecutionAction
- MoveExecutionActionMember
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成