Oracle管理インフラストラクチャ・メンテナンスの構成
Oracleは、Oracle Exadata Database Service on Cloud@Customer上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。
Oracleは、Exadata Cloud@Customerインフラストラクチャで定期的なメンテナンスを実行して、データベースの可用性、整合性およびセキュリティに影響を与える可能性のある潜在的な問題がないことを確認します。インフラストラクチャで実行されているソフトウェアを最新の製品およびセキュリティ修正で更新すると、データおよびOracle Cloudの全体的なコンプライアンスが保護されます。これらの更新は自動化された方法で実行され、すべてのベストプラクティスが含まれているため、インフラストラクチャの維持に投資する必要がなくなります。Oracleの更新には、物理データベース・サーバー・ホスト、ストレージ・サーバー、ネットワーク・ファブリック・スイッチ、管理スイッチ、配電ユニット(PDU)、統合ライトアウト管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。
Oracleでは、次の2つのタイプのインフラストラクチャ・メンテナンスが実行されます。
- 四半期メンテナンスは3か月ごとに適用され、製品の修正、拡張機能およびセキュリティ修正を含めることができます。
- 月次メンテナンスでは、オンラインで適用できる重要なセキュリティ修正のみが適用され、コンポーネントが最高のセキュリティ標準で維持され、セキュリティ脆弱性はできるだけ早く修正されます。
四半期メンテナンス
Oracleは、ローリング・メンテナンス操作を使用してアプリケーションに四半期メンテナンスの影響を最小限に抑え、更新プロセス全体でデータベースの可用性を維持します。ローリング・メンテナンスでは、各データベース・サーバーが一度に1つずつ再起動され、一度に最大1つのサーバーがオフラインになります。高可用性を実現するために設計されたアプリケーションは、中断することなく、使用可能なデータベース・インスタンス間でデータベース接続を自動的かつ透過的に移行するため、ダウンタイムをスケジュールする必要はありません。ストレージ・サーバーの更新もローリング方式で適用されます。ストレージ・サーバーの再起動はデータベース・サービスに影響しないため、アプリケーションには影響しません。
Oracleでは、四半期メンテナンス・スケジュールを完全に制御できるため、ビジネス・ユーザーへの影響が最も少ない期間にメンテナンスをスケジュールできます。四半期メンテナンスが適用されるタイミングを完全に制御および可視化でき、複数のメンテナンス・ウィンドウにわたってメンテナンスをスケジュールすることもできます。スケジューリングは、一貫性と効率性を確保するためにフリート全体のスケジューリングを標準化することを目的としたメンテナンス・スケジューリング・ポリシーを使用して簡素化されます。ポリシーを1回定義して複数のリソースに適用することで、スケジューリング・プロセスが合理化されます。また、予期しないビジネス上の問題が発生した場合にメンテナンスを再スケジュールすることもできます。
月次セキュリティ・メンテナンス
月次セキュリティ・メンテナンスは、データベース・サーバー上でオンラインで実行され、再起動は行われず、アプリケーションへの影響もありません。月次更新はローリング方式でストレージ・サーバーに適用され、アプリケーションにも影響を与えません。
月次セキュリティ・メンテナンスは、1つのメンテナンス・ウィンドウにあっても、月の特定の時間にスケジュールすることもできます。Oracleは、メンテナンス期間の開始の少なくとも1週間前に月次メンテナンスのスケジュールを公開し、必要に応じて再スケジュールできます。
インフラストラクチャ・メンテナンスに関して通知される連絡先を管理したり、メンテナンス・ウィンドウを設定して四半期ごとのインフラストラクチャ・メンテナンスを開始する時間を決定したり、Oracle Cloud InfrastructureコンソールでExadata Cloud@Customerのスケジュール済メンテナンス実行およびメンテナンス履歴を表示したりできます。インフラストラクチャ・メンテナンス・プロセスおよびメンテナンス制御の構成の詳細は、次を参照してください:
- Oracle管理Oracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について
Oracleは、Oracle Exadata Database Service on Cloud@Customer上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。 - インフラストラクチャ・メンテナンス連絡先
メンテナンス連絡先は、ハードウェアの交換やその他のメンテナンス・イベントのためのサービス・リクエスト・ベースの連絡用に必要です。 - メンテナンス・スケジューリング・ポリシー
OCIコンソールを使用してメンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。メンテナンス・スケジューリング・ポリシーを使用する場合、インフラストラクチャ・メンテナンスのすべてのスケジューリング・プリファレンスは、ポリシーから導出されます。 - コンソールを使用したOracle管理インフラストラクチャ更新の構成
完全なExadataインフラストラクチャ・ソフトウェア更新は、四半期ごとにスケジュールされます。さらに、重要なセキュリティ更新は毎月スケジュールされます。これらのインフラストラクチャの更新をオプト・アウトすることはできませんが、クラウド通知ポータルを介して更新が事前にアラートされ、スケジュールを柔軟に設定して計画を立てることができます。 - スケジューリング・プランから作成された四半期メンテナンス実行の管理
- ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。 - インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。 - APIを使用したOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス制御の管理
Oracle Exadata Database Service on Cloud@Customerは、Oracle Cloud Infrastructureと同じAPIを使用してインフラストラクチャ・メンテナンス制御を管理します。
親トピック: ハウツー・ガイド
Oracle管理のOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について
Oracleは、Oracle Exadata Database Service on Cloud@Customer上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。
ごくまれな例外的状況を除き、計画を支援するために、これらの更新に関する事前通知が送信されます。VMクラスタ仮想マシン(VM)に、対応する推奨更新がある場合、Oracleからそれらに関する通知が提供されます。
可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を保持する方法で実行されます。ただし、更新プロセス中に個々のシステム・コンポーネントが使用できない間は、パフォーマンスやスループットに顕著な影響が生じることがあります。
たとえば、通常、データベース・サーバーのパッチ適用では再起動が必要です。このような場合、データベース・サーバーは、可能なかぎりローリング方式で1つずつ再起動され、プロセス全体でサービスの可用性が保持されるようにします。ただし、各データベース・サーバーは、再起動中に短時間使用不能になるため、全体的なサービス容量はそれに応じて減少します。アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。たとえば、データベース・サーバーのパッチ適用が発生したときにアプリケーションを停止します。
- 四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。 - 月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコア間の脆弱性の修正を含みます。 - 同月の月次メンテナンスと四半期メンテナンスについて
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。
ローリング・インフラストラクチャ・メンテナンスは、Exadataデータベース・サーバー・ホストから開始されます。ローリング・メンテナンス方法では、データベース・サーバーは一度に1つずつ更新されます。データベース・サーバー・ホストの各VMが停止され、ホストが更新および再起動されてからVMが起動されますが、その間他のデータベース・サーバーは稼働したままです。このローリング・メンテナンスは、高可用性のために設計されたアプリケーションには影響しません。ローリング・インスタンスの再起動を処理するために書き込まれていない古いアプリケーションが影響を受ける可能性があります。すべてのサーバーが更新されるまでこのプロセスが続行されます。
データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。ローリング・メンテナンス方法では、ストレージ・サーバーは一度に1つずつ更新され、データベースまたはアプリケーションの可用性には影響しません。ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーを一度に1つずつオフラインにし(使用可能なIO容量を削減)、オンラインに戻すと再同期(データベース・サーバーのオーバーヘッドが少ない)されるため、IOパフォーマンスが低下する可能性があります。データベースおよびストレージ・インフラストラクチャのサイズを適切に設定して、メンテナンスされていないデータベースおよびストレージ・サーバーに分散される作業の増加に対応することで、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。
非ローリング・メンテナンスを選択して、データベース・サーバーとストレージ・サーバーを更新することもできます。非ローリング・メンテナンス方法は、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。非ローリング・メンテナンスでは、メンテナンス時間が最小化されますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。
ローリング・メンテナンス・プロセス中はデータベースが使用可能であることが想定されますが、自動化メンテナンスでは、Oracle Clusterwareが実行中であることは検証しますが、サーバーがオンラインに戻された後にすべてのデータベース・サービスおよびプラガブル・データベース(PDB)が使用可能であることは検証しません。メンテナンス後のデータベース・サービスおよびPDBの可用性は、アプリケーション・サービス定義に依存する可能性があります。たとえば、特定の優先ノードおよび使用可能ノードで構成されたデータベース・サービスは、メンテナンス中に再配置されると、メンテナンスの完了後に元のノードに自動的に再配置されません。Exadata Cloudシステム上のアプリケーションの継続的可用性の実現に関するドキュメントを確認して、アプリケーションへの影響の可能性を減らすことをお薦めします。ドキュメントのガイドラインに従うことで、データベース・サーバーは順番に更新されるため、インフラストラクチャ・メンテナンスの影響は、わずかなサービス低下のみになります。
最大可用性アーキテクチャ(MAA)のベスト・プラクティスに従い、Data Guardを使用してクリティカルなアプリケーションの可用性を最大にすることをお薦めします。Data Guardが有効なデータベースの場合、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前に、スイッチオーバーを実行することもできます。これにより、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避できます。
事前チェックは、メンテナンス・ウィンドウの開始前にExadata Cloud@Customerインフラストラクチャ・コンポーネントで実行されます。事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。最初の事前チェックはメンテナンス開始の約2週間前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックでメンテナンスの再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に通知が送信されます。
Exadataインフラストラクチャのメンテナンス・タイムフレームについては、MOSノートKB181723を参照してください。
月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべての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ソフトウェア・イメージにストレージ・サーバーを更新します。顧客管理ゲストVMに更新は適用されません。また、月次メンテナンスでは、既知のセキュリティの脆弱性および製品の問題を解決するExadata Storageソフトウェア・イメージにストレージ・サーバーを更新します。
データベース・サーバーの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新はホスト・サーバーにオンラインで適用され、VMおよびデータベースを含むVM内のすべてのプロセスは稼働したままです。サーバーおよびVMは再起動されません。ストレージ・サーバーに対する更新は、ローリング形式で適用されます。四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションにとって最小限である必要があります。
毎月のインフラストラクチャ・メンテナンス中にサポートされる操作は、CPUスケーリングおよび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インフラストラクチャ・メンテナンスの前にいつでも再スケジュールできます。
インフラストラクチャ・メンテナンス連絡先
メンテナンス連絡先は、ハードウェアの交換やその他のメンテナンス・イベントのためのサービス・リクエスト・ベースの連絡用に必要です。
主メンテナンス連絡先を追加し、オプションで最大9個の副連絡先を追加します。主連絡先と副連絡先の両方とも、ハードウェアの交換、ネットワークの問題およびソフトウェア・メンテナンスの実行に関する通知をすべて受信します。
どの副連絡先も必要なときにいつでも主連絡先として昇格できます。副連絡先を主連絡先に昇格すると、現在の主連絡先は自動的に副連絡先に降格されます。
詳細は、コンソールを使用したインフラストラクチャの作成およびインフラストラクチャ・メンテナンス連絡先の管理を参照してください。
メンテナンス・スケジューリング・ポリシー
OCIコンソールを使用して、メンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。メンテナンス・スケジューリング・ポリシーを使用する場合、インフラストラクチャ・メンテナンスのすべてのスケジューリング・プリファレンスは、ポリシーから導出されます。
メンテナンス・スケジューリング・ポリシーは、フリート全体のスケジューリングを標準化し、一貫性と効率性を確保することを目的としています。ポリシーを1回定義して複数のリソースに適用することで、スケジューリング・プロセスが合理化されます。このポリシーは、ビジネス・ベスト・プラクティスに準拠し、これらの標準に従ってメンテナンス・アクティビティをスケジュールします。また、さまざまなステークホルダーとのメンテナンスコミットメントを文書化および調整するための中央リポジトリとして機能し、コンプライアンスと効率性を高めます。ポリシーにサブスクライブするリソースを集中管理することで、コンプライアンス要件への準拠が保証され、変更は1つの場所から効率的に調整できます。さらに、このポリシーにより、フリート内の様々な環境における計画メンテナンスに関するコミュニケーションが改善され、より適切な調整と認識が促進されます。
スケジューリング・ポリシーを使用する場合、インフラストラクチャでローカルに定義されたスケジューリング・プリファレンスは、四半期ごとの更新を適用するためにOracle Automationでは使用されません。
- メンテナンス・スケジューリング・ポリシーのリストの表示
- メンテナンス・スケジューリング・ポリシーの作成
- メンテナンス・スケジューリング・ポリシーの詳細の表示
- メンテナンス・スケジューリング・ポリシーの編集
- 注意が必要な状態のメンテナンス・スケジューリング・ポリシーの編集
- メンテナンス・スケジューリング・ポリシーのメンテナンスWindowsの表示
- メンテナンス・スケジューリング・ポリシーのメンテナンス・ウィンドウの編集
- メンテナンス・スケジューリング・ポリシーへの追加のメンテナンスWindowsの追加
- ポリシーに関連付けられているリソースの表示
- メンテナンス・スケジューリング・ポリシーのメンテナンス・ウィンドウの削除
- 別のコンパートメントへのメンテナンス・スケジューリング・ポリシーの移動
- メンテナンス・スケジューリング・ポリシーへのタグの追加
- メンテナンス・スケジューリング・ポリシーの削除
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
メンテナンス・スケジューリング・ポリシーの作成
作成後に、スケジュール・ポリシーにメンテナンス・ウィンドウを追加できます。
スケジュール・ポリシーを使用した四半期インフラストラクチャ・メンテナンスの実行に関する詳細なガイダンスは、コンソールを使用したOracle管理インフラストラクチャ更新の構成を参照してください。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジューリング・ポリシーのメンテナンス・ウィンドウの削除
リソースがメンテナンス・アクティビティを計画および自動化するために使用していないメンテナンス・ウィンドウのみをポリシーから削除できます。サービスでメンテナンスを自動化するためにすでに使用されているウィンドウは削除できません。
親トピック: メンテナンス・スケジューリング・ポリシー
別のコンパートメントへのメンテナンス・スケジューリング・ポリシーの移動
ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジューリング・ポリシーへのタグの追加
ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。
親トピック: メンテナンス・スケジューリング・ポリシー
メンテナンス・スケジューリング・ポリシーの削除
ポリシーは、いずれかのリソースがメンテナンス・アクティビティの計画および自動化に使用している場合、削除できません。
ポリシーは、保守スケジューリング・プランで使用されている場合は削除できません。
親トピック: メンテナンス・スケジューリング・ポリシー
コンソールを使用したOracle管理インフラストラクチャ更新の構成
完全なExadataインフラストラクチャ・ソフトウェア更新は、四半期ごとにスケジュールされます。さらに、重要なセキュリティ更新は毎月スケジュールされます。これらのインフラストラクチャの更新をオプト・アウトすることはできませんが、クラウド通知ポータルを介して更新が事前にアラートされ、スケジュールを柔軟に設定して計画を立てることができます。
四半期ごとのインフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。Oracle Cloud Infrastructureコンソールで、メンテナンス方法の編集、カスタム・アクションの有効化、Exadata Cloud@Customerのスケジュール済メンテナンス実行およびメンテナンス履歴の表示を行うこともできます。セキュリティ・メンテナンスの場合、21日のウィンドウ内でスケジュールされた開始時間を編集できます。
- 四半期メンテナンス・プリファレンスの表示または編集
Oracle Exadata Database Service on Cloud@Customerインフラストラクチャの四半期メンテナンス・プリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。 - スケジューリング・ポリシーを使用した四半期メンテナンス・プランの管理
スケジューリング・ポリシーを選択すると、Oracleによって、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランが生成されます。 - スケジュール済四半期メンテナンスの表示または編集
次のスケジュール済メンテナンスの時間を表示および編集する方法について学習します。 - スケジュール済セキュリティ・メンテナンスの表示または編集
次にスケジュール済セキュリティ・メンテナンスを表示および編集する方法について学習します。 - メンテナンス履歴の表示
Oracle Exadata Database Service on Cloud@Customerインフラストラクチャのメンテナンス履歴を表示する方法について学習します。
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
四半期メンテナンスのプリファレンスの表示または編集
Oracle Exadata Database Service on Cloud@Customerインフラストラクチャの四半期メンテナンス・プリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- 「Exadata Infrastructure」をクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- 「アクション」メニューをクリックし、「メンテナンス・プリファレンスの編集」を選択します。
「メンテナンスのプリファレンスの編集」ページが表示されます。
ノート
メンテナンス・プリファレンスに加えられた変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。
- 「メンテナンスのプリファレンスの編集」ページで、次を構成します:
- メンテナンス・スケジュール・プリファレンス: Oracle管理スケジュール
- メンテナンス方法の選択:
- ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
-
カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
ノート
カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。この時間内に、計画したアクションを実行できます。カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。カスタム・アクションが進行中の場合、顧客は2つのオプション(カスタム・アクション・タイムアウトの延長またはメンテナンス・ウィンドウの再開)を取得します。デフォルト: 15分
最大: 120分
-
- 「変更の保存」をクリックします。
ノート
次回のメンテナンス実行以降は、Oracleのスケジュールに従って実行されます。
- メンテナンス方法の選択:
- メンテナンス・スケジューリング・プリファレンス: 顧客管理スケジュール
- メンテナンス・スケジュール:このインフラストラクチャのメンテナンス・プリファレンスを定義します。
ノート
変更は、次のメンテナンス実行から有効になります。- 保守作業環境の構成:各四半期の保守時間作業環境を定義します。1四半期に複数のプリファレンスが定義されている場合、Oracle Automationはそれらのいずれかを選択して、インフラストラクチャ内のすべてのコンポーネントでメンテナンスを実行します。
2四半期ごとに少なくとも1か月を選択します。
- スケジュールの指定: インフラストラクチャ・メンテナンスに対して希望する週、平日、開始時刻およびリード・タイムを選択します。
- オプション。「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。曜日を指定しない場合は、Oracleは影響が最小限になるよう週末の日にメンテナンス更新を実行します。
- オプション。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
- オプション。「時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
- 「通知リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
- メンテナンス方法の選択:
- ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各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インフラストラクチャ・メンテナンス・スケジューリング・プランのスケジュール済アクションを編集するには、この手順を使用します。
スケジュール済四半期メンテナンスの表示または編集
次回のスケジュール済メンテナンスの時間を表示および編集する方法について学習します。
- メンテナンスの進行中のメンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開したり、タイムアウトを延長できます。 - メンテナンスがカスタム・アクションを待っている間、メンテナンスを表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開するか、タイムアウトを延長できます。
メンテナンス進行中のメンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開したり、タイムアウトを延長できます。
親トピック: スケジュール済四半期メンテナンスの表示または編集
メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開するか、タイムアウトを延長できます。
親トピック: スケジュール済四半期メンテナンスの表示または編集
スケジュール計画から作成された四半期メンテナンス実行の管理
- メンテナンス実行に関連付けられたメンテナンスWindowsの表示
- メンテナンス実行に関連付けられたメンテナンス・ウィンドウの編集
- メンテナンス実行に関連付けられたメンテナンス・アクションの表示
- メンテナンス実行に関連付けられたメンテナンス・ウィンドウのメンテナンス・アクションの編集
- メンテナンス進行中のメンテナンスの表示および編集
- メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集
- 進行中のメンテナンス実行の取消
- コンパートメントのメンテナンス・アクティビティの表示
- メンテナンス・アクティビティの詳細の表示
- コンパートメントのメンテナンス履歴の表示
- コンパートメントのメンテナンス履歴詳細の表示
- 未計画保守アクティビティのレビューおよび応答
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成
メンテナンス実行に関連付けられたメンテナンスWindowsの表示
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 開始時間(UTC):ウィンドウ開始時間(UTC): Sun、Jun 23、2024、18:30:58 UTCなど。
次の制限事項が適用されます。
- Oracleでは、少なくとも四半期に1回はインフラストラクチャ・メンテナンスを実行できると予想しています。メンテナンス四半期の終了以降にメンテナンスを延期しないでください。予期しない問題により次のメンテナンス四半期までにメンテナンスに対応できなくなる場合を除きます。
- 予期しない問題により、スケジュールされたインフラストラクチャ・メンテナンス実行に対応できない場合、インフラストラクチャ・メンテナンスは、前のインフラストラクチャ・メンテナンスから180日以内の別の日付に再スケジュールできます。通常メンテナンスは四半期ごとに実行する必要があるため、インフラストラクチャ・メンテナンスを再スケジュールするために約90日間追加されます。Oracleでは、180日の制限時間またはそれに近い時間にメンテナンスをスケジュールしないことを強くお薦めします。予期しない追加の問題が発生した場合に柔軟に再スケジュールできないためです。
- 再スケジュールされたメンテナンス実行より前に新しいメンテナンス・リリースが公開された場合、その新しいリリースが指定した日付に適用されます。
- メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。
- Oracleでは、四半期ごとに特定の日付を内部メンテナンス操作のために予約しており、これらの日付にメンテナンスをスケジュールすることはできません。
- タイプ:「計画」と「計画外」。インフラストラクチャ・メンテナンス・スケジュール・プランから作成またはこのメンテナンス実行に追加されたすべてのウィンドウは、「計画済」ウィンドウです。Oracle Automationにより、障害、期間強制または予期しないイベントに対処するために作成される他のすべてのウィンドウは、「計画外」ウィンドウとして定義されます。「未計画」ウィンドウで実行するようにスケジュールされているアクティビティを常にレビューします。
- メンテナンス・アクション:特定のウィンドウで更新がスケジュールされているアクションのサマリー。
サーバー名は、DBサーバーにスケジュールされている更新を識別します。たとえば、DBサーバーdbServer-1およびdbServer-2に完全更新を適用します。ストレージ・サーバーの更新は、すべてのストレージ・サーバーのストレージ・レイアウトが同じであるため、カウントとして識別されます。たとえば、2つのストレージ・サーバーに完全更新を適用します。ネットワーク・スイッチはペアとして更新され、様々なアクションまたはメンテナンス・ウィンドウで更新するようにスケジュールすることはできません。たとえば、2つのネットワーク・スイッチに完全更新を適用します。
- 見積時間: Oracle Automationがメンテナンス実行のすべてのウィンドウにわたってすべてのインフラストラクチャ・コンポーネントに更新を適用するようにスケジュールされたメンテナンス・アクションを完了するための推定時間。
- 開始時間(UTC):ウィンドウ開始時間(UTC): Sun、Jun 23、2024、18:30:58 UTCなど。
メンテナンス実行に関連付けられたメンテナンス・ウィンドウの編集
ウィンドウは「スケジュール済」ライフ・サイクル状態のまま、ウィンドウ・スケジュールの開始時間、期間および期間の強制などのウィンドウ構成を更新できます。ウィンドウが進行中の場合、構成を変更することはできません。ウィンドウの実行中のメンテナンスを取り消すことを選択できます。詳細は、「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの取消」の項を参照してください。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの編集」を選択します。
- 表示される「メンテナンス・ウィンドウの編集」ダイアログで、「メンテナンス・ウィンドウの開始時間」、「期間(時間)」および「ウィンドウ期間の強制」フィールドを更新します
- 「メンテナンス・ウィンドウの編集」をクリックします。
メンテナンス実行に関連付けられたメンテナンス・アクションの表示
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・アクションを表示するアクティビティの名前をクリックします。
- 「メンテナンス・アクション」をクリックします。
- 処理を追加する手順は、次のとおりです。
- 「アクションの追加」をクリックします。
- 表示される「メンテナンス・アクションの追加」ウィンドウで、「アクション・タイプの選択」、「メンテナンス・アクションの追加」の順にクリックします。
- アクションを削除するには:
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
メンテナンス実行に関連付けられたメンテナンス・ウィンドウのメンテナンス・アクションの編集
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションの編集」を選択します。結果の「メンテナンス・アクションの編集」ページに、アクションのリストが表示されます。アクションを追加するか、既存のアクションを削除できます。
- 処理を追加する手順は、次のとおりです。
- 「アクションの追加」をクリックします。
- 結果の「メンテナンス・アクションの追加」ウィンドウで、次の手順を実行します。
- 新規アクションの作成:新規メンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新規ウィンドウに追加することを選択できます。
- アクション・タイプの選択:
- DBサーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効にする: Oracleのプレビューの外部で追加のアクションを実行する場合にのみ、カスタム・アクションを有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
-
カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
ノート
カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。この時間内に、計画したアクションを実行できます。カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。カスタム・アクションが進行中の場合、顧客は2つのオプション(カスタム・アクション・タイムアウトの延長またはメンテナンス・ウィンドウの再開)を取得します。デフォルト: 15分
最大: 120分
-
- DBサーバーの追加:
- DBサーバーの選択:選択したDBサーバーに対する更新は、現在スケジュールされているウィンドウからメンテナンス・アクションを追加するウィンドウに移動されます。
- メンテナンス方法の構成:
- ストレージ・サーバーのExadata完全ソフトウェア更新
- メンテナンス方法の構成:
- ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
-
非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
ノート
非ローリング・ストレージ更新を適用するには、インフラストラクチャ内のすべてのストレージ・サーバーが単一のメンテナンス・アクションで更新されるようにスケジュールする必要があります。これらの更新は適用されますが、データベース・ワークロードでは完全なダウンタイムが発生します。
- ストレージ・サーバーの選択元: ストレージ・サーバーを追加するウィンドウを選択します。
- 追加するメンテナンス・アクションの選択:ストレージ・サーバーの追加元となるアクションを選択します。
- 追加するストレージ・サーバーの数の選択:このアクションに追加するストレージ・サーバーの数を選択します。
- メンテナンス方法の構成:
- ネットワーク・スイッチのソフトウェア更新:選択したメンテナンス・ウィンドウでネットワーク・スイッチのソフトウェア更新がすでにスケジュールされている場合、「ネットワーク・スイッチの更新はすでに選択したメンテナンス・ウィンドウにスケジュールされています」というメッセージが表示されたバナー。
- DBサーバーのExadata完全ソフトウェア更新
- アクション・タイプの選択:
- 別のウィンドウからの移動処理:処理を移動するときに、特定のウィンドウで更新するようにスケジュールされているすべてのコンポーネントを新しいウィンドウに移動することを選択できます。
- アクションを移動するウィンドウの選択:メンテナンス実行からウィンドウを選択します。
- 移動するアクションの選択:移動するメンテナンス・ウィンドウから特定のアクションを選択します。
- 新規アクションの作成:新規メンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新規ウィンドウに追加することを選択できます。
- アクションを削除するには:
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
ノート
- そのアクションで更新がスケジュールされているコンポーネントがないかぎり、任意のアクションを削除できます。
- 更新がスケジュールされているアクションがそのウィンドウ内にないかぎり、すべてのウィンドウを削除できます。
- メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。
メンテナンス進行中のメンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開したり、タイムアウトを延長できます。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- 「Exadata Infrastructure」をクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
ノート
「メンテナンス進行中」ステータスが「次の四半期メンテナンス」フィールドに表示されます。 - 「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。
メンテナンス実行履歴ページが表示されます。
- 「アクション」メニュー(3つのドット)をクリックし、「詳細の表示」を選択します。
- メンテナンス実行履歴ページで「メンテナンス・ウィンドウ」をクリックします。
- 進行中のメンテナンス・ウィンドウを識別します
- 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションの編集」を選択します。
- 「アクション」メニュー(3つのドット)をクリックし、「カスタム・アクション構成の編集」を選択します。
- 結果の「カスタム・アクション構成の編集」ページで、「カスタム・アクション(分)」と入力します。
ノート
メンテナンスの進行中は、DBサーバー・アクション・タイプのカスタム・アクション時間のみ変更できます。他の処理タイプに対してこのオプションをサポートするためのカスタム処理時間は変更できません。 - 「変更の保存」をクリックします。
メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開したり、タイムアウトを延長できます。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- 「Exadata Infrastructure」をクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
ノート
「メンテナンス進行中」ステータスが「次の四半期メンテナンス」フィールドに表示されます。
- 「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。
進行中のメンテナンス実行の詳細ページが表示されます。
- 結果の「メンテナンス実行」詳細ページで、「メンテナンス・アクション」をクリックします。
メンテナンスのカスタム・アクションの待機中は、情報ブロックが表示されます。また、顧客のアクションを待機している間はメンテナンスを編集できません。情報ブロックは、メンテナンスが再開されると削除されます。
- 情報ブロックで、次を実行します:
- 「メンテナンスを今すぐ再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。
「メンテナンスの再開」ダイアログが表示されます。「メンテナンスを今すぐ再開」をクリックします。
- 「カスタム・アクション・タイムアウトの延長」をクリックします。
2時間の最大許容時間内でタイムアウトを複数回延長できます。最大制限を超えて延長しようとすると、「カスタム・アクション・タイムアウトは延長できません」ダイアログが表示され、カスタム・アクション・タイムアウトがすでに最大許容時間である2時間まで延長されており、それ以上延長できないことが示されます。
- 「メンテナンスを今すぐ再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。
進行中のメンテナンス実行の取消
メンテナンス実行に関連付けられたメンテナンス・ウィンドウを取り消すには、次のステップに従います:
ウィンドウに対してスケジュールされた更新の進行中に、実行中のメンテナンスを取り消すことができます。更新の進行中にメンテナンスを取り消すと、まだ開始していないすべてのアクションを、選択した将来のメンテナンス・ウィンドウに再スケジュールできます。新しい開始時間と期間を選択して、取り消すことにしたメンテナンス・ウィンドウから再スケジュールされたすべてのアクションを終了できます。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。
結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。
- 取り消す「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。
進行中のメンテナンス実行を取り消すには、次のステップに従います:
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
- 取り消す「進行中」アクティビティの名前をクリックします。
- メンテナンス実行の詳細ページで「メンテナンス・ウィンドウ」をクリックします。
- 進行中のメンテナンス・ウィンドウを識別します。
- 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。
- 結果の「メンテナンス実行の取消」ウィンドウで、「メンテナンス・ウィンドウの開始時間」を再構成します。
- 「ウィンドウ期間の強制」チェック・ボックスを選択して、構成済のウィンドウ期間を超えるスケジュール済アクションを一時停止および再スケジュールし、将来のメンテナンス・ウィンドウに再開します。
- 「メンテナンス実行の再スケジュール」をクリックします。
メンテナンス実行により、現在の操作は完了します。このウィンドウにスケジュールされている残りのすべてのアクションは、新しいメンテナンス・ウィンドウに再スケジュールされます。
コンパートメント内のメンテナンス・アクティビティの表示
メンテナンス・アクティビティには、選択したExadataクラウド・サービスの特定のコンパートメント内のすべてのインフラストラクチャ・リソースに対して実行するようにスケジュールされているすべてのメンテナンス更新がリストされます。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。
メンテナンス・アクティビティの詳細の表示
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「アクティビティ」をクリックします。
結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。
- 詳細を表示するメンテナンス・アクティビティの「アクション」メニュー(3つのドット)をクリックします。
結果の「メンテナンス実行」ページには、選択したメンテナンス・アクティビティの詳細が表示されます。
コンパートメントのメンテナンス履歴の表示
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「履歴」をクリックします。
表示されるページには、選択したコンパートメントのメンテナンス実行の履歴が表示されます。
コンパートメントのメンテナンス履歴詳細の表示
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
- 「リソース」で、「スケジューリング・ポリシー」をクリックします。
結果の「スケジューリング・ポリシー」ページには、ポリシーのリストが表示されます。
- 「コンパートメント」フィルタからコンパートメントを選択します。
- 「メンテナンス」で、「履歴」をクリックします。
結果の「履歴」ページには、メンテナンス実行ステータス(成功または失敗)と、選択したコンパートメント内のメンテナンス・アクティビティの他の詳細がリストされます。
失敗した場合、自動化によって実行が「失敗」としてマークされ、ターゲット・バージョンに更新する必要がある残りのコンポーネントを含む新しいウィンドウが自動的に再スケジュールされます。同じ更新順序が継承されます。
- 詳細を表示するメンテナンス・アクティビティの「アクション」メニュー(3つのドット)をクリックします。
結果の「メンテナンス履歴」ページには、選択したメンテナンス・アクティビティの詳細が表示されます。
未計画保守活動のレビューおよび応答
メンテナンス計画後にインフラストラクチャをスケーリングする場合の未計画メンテナンス・アクティビティ
- DBサーバーまたはストレージ・サーバーを追加してインフラストラクチャをスケーリングした後、メンテナンス・スケジューリング計画を更新して、これらの新しいコンポーネントを含める必要がある場合があります。メンテナンス・プランにインフラストラクチャ・コンポーネントがない場合、インフラストラクチャ・メンテナンス・プランの詳細セクションに警告が表示されます。
- Oracle Automationによって四半期のメンテナンス実行が作成されると、メンテナンス計画に含まれていないコンポーネントはすべて、自動的に「計画外」メンテナンス・ウィンドウに追加されます。これにより、すべてのコンポーネントに、四半期ごとに正しいシステム・ソフトウェアが適用され、OCIソフトウェアのコンプライアンスが維持されます。
- 必要に応じて、「未計画」ウィンドウの予定開始時間を編集するか、欠落しているコンポーネントの更新を既存の計画ウィンドウに移動できます。
スケジュールされた更新の適用に失敗した場合の未計画メンテナンス・アクティビティ
- スケジュールされた更新が失敗した場合、Oracle運用チームは、失敗を評価し、失敗した更新を将来のメンテナンス・ウィンドウに対する未完了の更新とともに再スケジュールします。Oracle Automationにより、この再スケジュールされたウィンドウが「未計画」としてマークされ、再スケジュールされた保守アクティビティをレビューするよう通知されます。
- 必要に応じて、「未計画」ウィンドウの予定開始時間を編集するか、失敗および未完了の更新を既存の計画ウィンドウに移動できます。
スケジュール・アクティビティが強制ウィンドウ期間を超えた場合の未計画保守
- 期間強制で構成されたメンテナンス・ウィンドウの場合、Oracle Automationは、実行の見積時間を確認し、スケジュール済更新を適用する時間が残りのウィンドウ期間内に十分かどうかをチェックします。そうでない場合、Oracle Automationは未完了のすべての更新を将来の「未計画」ウィンドウに自動的に再スケジュールし、現在のウィンドウを「期間超過」としてマークし、再スケジュールされた保守アクティビティをレビューするよう通知します。
- すでに進行中の更新は、基礎となるリソースの一貫した状態を確保するために、強制されたウィンドウ期間を超えて続行されます。
ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態により、インフラストラクチャ・リソースのメンテナンスがいつ開始および終了するかをモニターできます。
Oracle Cloud Infrastructureコンソールで、「Exadataインフラストラクチャの詳細」ページにライフサイクル状態の詳細メッセージが表示されます(「ステータス」フィールドの横にツールチップが表示されます)。これらのメッセージには、ListExadataInfrastructures API、およびSDKやOCI CLIなどのAPIに基づくツールを使用してアクセスすることもできます。
-
メンテナンス・ウィンドウを指定した場合、指定した開始時間にパッチ適用が開始されます。インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変わります。ノート
メンテナンスの開始前に事前チェックが実行されます。 - Exadataデータベース・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャは更新中です」です。
- ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基礎となるインフラストラクチャは更新中であり、これはデータベースの可用性には影響しません」です。
- ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチがローリング方式で1つずつ更新されます。
- メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールにライフサイクル状態メッセージは表示されません。
インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。
Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。事前チェック、パッチ適用の開始、パッチ適用の終了など、スケジュール済メンテナンス実行のためのOracleの準備として、適切なメンテナンス関連イベントが生成されます。すべてのメンテナンス関連イベントの詳細は、Oracle Exadata Cloud@Customerイベントを参照してください。障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成して、インフラストラクチャ・メンテナンス連絡先に通知します。
Oracle Cloud Infrastructure Eventsの詳細は、イベントの概要を参照してください。インフラストラクチャ・メンテナンス連絡先に送信された通知以外の追加の通知を受信するには、インフラストラクチャ・メンテナンス・イベントにサブスクライブし、Oracle Notification Serviceを使用して通知を受信します。通知の概要を参照してください。
APIを使用したOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス制御の管理
Oracle Exadata Database Service on Cloud@Customerは、Oracle Cloud Infrastructureと同じAPIを使用してインフラストラクチャ・メンテナンス制御を管理します。
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
次のAPI操作を使用して、インフラストラクチャ・メンテナンス制御を管理します:
- CreateExadataInfrastructure
- GetExadataInfrastructure
- ListExadataInfrastructures
- UpdateExadataInfrastructure
- UpdateMaintenanceRun
- GetMaintenanceRun
- ListMaintenanceRuns
- ListSchedulingPolicies
- CreateSchedulingPolicy
- GetSchedulingPolicy
- UpdateSchedulingPolicy
- DeleteSchedulingPolicy
- ChangeSchedulingPolicyCompartment
- ListRecommendedScheduledActions
- ListSchedulingWindows
- CreateSchedulingWindow
- GetSchedulingWindow
- UpdateSchedulingWindow
- DeleteSchedulingWindow
- ListSchedulingPlans
- CreateSchedulingPlan
- GetSchedulingPlan
- DeleteSchedulingPlan
- ChangeSchedulingPlanCompartment
- ReorderScheduledActions
- CascadingDeleteSchedulingPlan
- ListScheduledActions
- CreateScheduledAction
- GetScheduledAction
- UpdateScheduledAction
- DeleteScheduledAction
- ListParamsForActionType
- ReorderScheduledActions
- ListExecutionWindows
- CreateExecutionWindow
- GetExecutionWindow
- UpdateExecutionWindow
- DeleteExecutionWindow
- ReorderExecutionActions
- CancelExecutionWindow
- ListExecutionActions
- CreateExecutionAction
- GetExecutionAction
- UpdateExecutionAction
- DeleteExecutionAction
- MoveExecutionActionMember
親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成