機械翻訳について

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のメンテナンス実行およびメンテナンス履歴を表示したりできます。 インフラストラクチャのメンテナンス・プロセスおよび構成の詳細は、次を参照してください:

親トピック: How-toガイド

Oracle管理のOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について

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

まれではないすべての状況で、これらの更新に関する事前通信を受信して計画に役立てます。 VMクラスタ仮想マシン(VM)に対応する推奨の更新がある場合、Oracleはその通知を提供します。

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

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

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

四半期インフラストラクチャ・メンテナンス・プロセスの概要

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

ローリング・インフラストラクチャのメンテナンスは、Exadataデータベース・サーバー・ホストから始まります。 ローリング・メンテナンス・メソッドでは、データベース・サーバーは一度に1つずつ更新されます。 各データベース・サーバー・ホストVMが停止され、ホストが更新されて再起動され、VMが起動され、他のデータベース・サーバーは引き続き稼働状態になります。 このローリング・メンテナンスは、高可用性のために設計されたアプリケーションには影響しません。 ローリング・インスタンスの再起動を処理するために書き込まれていない古いアプリケーションが影響を受ける可能性があります。 このプロセスは、すべてのサーバーが更新されるまで続行されます。

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

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

ローリング・メンテナンス・プロセス中にデータベースが使用可能であることが予想される間、自動メンテナンスはOracle Clusterwareが実行中であることを検証しますが、サーバーがオンラインに戻った後にすべてのデータベース・サービスおよびプラガブル・データベース(PDB)が使用可能であることは検証しません。 メンテナンス後のデータベース・サービスおよびPDBの可用性は、アプリケーション・サービス定義によって異なる場合があります。 たとえば、特定の優先ノードおよび使用可能なノードで構成されたデータベース・サービスは、メンテナンス中に再配置され、メンテナンスの完了後に元のノードに自動的に再配置されません。 Oracleでは、Exadata Cloudシステム上の「アプリケーションの継続的な可用性の実現」のドキュメントを確認して、アプリケーションへの影響の可能性を減らすことをお薦めします。 ドキュメントのガイドラインに従うことで、データベース・サーバーが順次更新されるため、インフラストラクチャ・メンテナンスの影響は軽度のサービスの低下にすぎません。

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

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

インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス・メソッド、およびカスタム・アクションが有効になっているかどうかによって異なります。 推定時間は概算です。 カスタム・アクションの時間(構成されている場合)は、次の見積に含まれません。 データベース・サーバーのメンテナンス時間は、更新前に各VMをシャットダウンし、次のノードに進む前に各ノードの更新後に各VMおよび関連リソースを起動するために必要な時間によって異なる場合があります。 ストレージ・サーバーのメンテナンス時間は、ASMのリバランスに必要な時間によって異なります。この時間は、次の見積りには含まれません。 メンテナンス中に問題が発生した場合、表示されるおおよその時間を超えて完了が遅延する可能性があります。 このような状況では、Oracleクラウド操作で解決が予想されるウィンドウを超えて延長されると、通知が送信され、メンテナンスが再スケジュールされる場合があります。

関連トピック

親トピック: Oracle管理のOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について

月次セキュリティ・メンテナンスの概要

四半期メンテナンスとともに実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月単位で実行され、すべての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は再起動されません。 ストレージ・サーバーへの更新は、ローリング方式で適用されます。 四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションに対して最小限に抑える必要があります。

サービス・インフラストラクチャの更新中、メモリーやストレージのスケーリング、オペレーティング・システムとGrid Infrastructureのパッチ適用(事前チェックを含む)、コンピュート・サーバーとストレージ・サーバーの柔軟な拡張などの一部の操作がブロックされる場合があります。

ノート:

月次インフラストラクチャのメンテナンスでサポートされる操作は、CPUのスケーリングとVMの起動/停止のみです。
更新が完了するまで、これらの操作を延期するように計画してください。 影響を受ける操作を試行すると、進行中のセキュリティ更新がコンソールに通知されます。 ゲストVMではソフトウェアは更新されません。

関連トピック

親トピック: Oracle管理のOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について

同月の月次および四半期メンテナンスについて

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

  • 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前の月から最新の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管理のOracle Exadata Database Service on Cloud@Customerインフラストラクチャ・メンテナンス更新について

インフラストラクチャ・メンテナンス連絡先

メンテナンス連絡先は、ハードウェア交換およびその他のメンテナンス・イベントのサービス・リクエストベースの通信に必要です。

プライマリ・メンテナンス連絡先を追加し、オプションで最大9つのセカンダリ連絡先を追加します。 プライマリ連絡先とセカンダリ連絡先の両方が、ハードウェアの交換、ネットワークの問題およびソフトウェア・メンテナンスの実行に関するすべての通知を受け取ります。

任意のセカンダリ連絡先をプライマリとしていつでも昇格させることができます。 セカンダリ連絡先をプライマリに昇格すると、現在のプライマリ連絡先は自動的にセカンダリに降格されます。

詳細は、次を参照してください: コンソールを使用したインフラストラクチャの作成およびインフラストラクチャ・メンテナンス連絡先の管理。

関連トピック

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

メンテナンス・スケジューリング・ポリシー

OCIコンソールを使用して、メンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。 メンテナンス・スケジューリング・ポリシーを使用する場合、インフラストラクチャ・メンテナンスのすべてのスケジューリング・プリファレンスはポリシーから導出されます。

メンテナンス・スケジューリング・ポリシーは、フリート全体のスケジューリングを標準化し、一貫性と効率性を確保することを目的としています。 ポリシーを1回定義して複数のリソースに適用することで、スケジューリング・プロセスが合理化されます。 このポリシーは、ビジネス・ベスト・プラクティスに準拠し、これらの標準に従ってメンテナンス・アクティビティをスケジュールします。 また、さまざまなステークホルダーとのメンテナンス・コミットメントを文書化および調整するための中央リポジトリとして機能し、コンプライアンスと効率性を高めます。 ポリシーにサブスクライブするリソースを集中管理することで、コンプライアンス要件への準拠が保証され、変更は1つのロケーションから効率的に調整できます。 さらに、このポリシーにより、フリート内の様々な環境での計画メンテナンスに関するコミュニケーションが改善され、より適切な調整と認識が促進されます。

ノート:

スケジューリング・ポリシーを使用する場合、インフラストラクチャでローカルに定義されたスケジューリング・プリファレンスは、四半期ごとの更新を適用するためにOracle Automationでは使用されません。

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

メンテナンス・スケジュール・ポリシーのリストの表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタを使用して、特定のコンパートメントで作成されたポリシーのリストを表示します。
  4. 「状態」を使用して、ポリシーを状態別にフィルタします。
    ポリシーの状態は次のとおりです:
    • 作成
    • 注意が必要
    • 使用可能
    • 更新
    • 失敗
    • 削除中
    • 削除済

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジューリング・ポリシーの作成

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「メンテナンス・スケジューリング・ポリシーの作成」をクリックします。
  4. 表示される「メンテナンス・スケジューリング・ポリシーの作成」ウィンドウで、次のように入力します:
    1. 名: ポリシーのわかりやすい名前を入力します。
    2. コンパートメント: このリソースを作成するコンパートメントを選択します。

    3. ケイデンス: 頻度を選択します。

      使用可能なオプション:
      1. 6か月ごと
      2. 四半期ごと

        ノート:

        スケジューリング・ポリシーを使用して四半期ごとのインフラストラクチャ・メンテナンスを計画および自動化するには、「四半期」ケイデンスとスケジュールされた開始月の値を「2月」に設定したポリシーを作成する必要があります
      3. 毎月

        ノート:

        インフラストラクチャ・メンテナンス更新の適用では、6回の月次ケイデンスおよび月次ケイデンスはサポートされていません。
    4. スケジュール開始月: 開始月を選択します。

      Oracle自動化では、インフラストラクチャ・メンテナンスにこのポリシーを使用する場合、四半期メンテナンス・スケジュールを2月に開始する必要があります。

    5. メンテナンス・ウィンドウ: Oracle Automationは、スケジュールで定義されたメンテナンス・ウィンドウに従って、スケジュール済アクションを実行するためのメンテナンスを実行します。
      1. 月: 月を選択します。 月の選択オプションは、選択したポリシー・ケイデンスによって異なります。 四半期単位の場合は、各四半期の第1、第2または第3の月を選択できます。
      2. 週: メンテナンス目的の週は、月の1日目、8日目、15日目および22日に開始します。
      3. 日: 曜日から選択できます: 日曜日、月曜日、火曜日、水曜日、木曜日、金曜日、または土曜日。
      4. 開始時間: メンテナンスを開始する開始時間を指定します。
      5. 期間: Database Cloudサービス・アクションを完了するための平均時間の見積りに基づいて、メンテナンス・ウィンドウを計画します。 時間の見積りについては、「四半期インフラストラクチャ・メンテナンス・プロセスの概要」を参照してください。
      6. ウィンドウの期間を強制: このオプションを有効にすると、構成されたウィンドウ期間を超えるスケジュール済アクションが一時停止され、将来のメンテナンス・ウィンドウで再開するように再スケジュールされます。

        ノート:

        更新またはアクションがすでに進行中で、中断を発生させずに一時停止および再開できない場合は、続行してアクションを完了します。 Oracle Automationは、構成済のウィンドウ期間後に開始する予定のアクションを将来のメンテナンス・ウィンドウに再スケジュールします。
    6. Show Advanced Options:
      1. タグ: (オプション)タグの適用を選択できます。 リソースの作成権限がある場合、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、リソース・タグを参照してください。 タグを適用する必要があるかどうかわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。

ノート:

作成後に、スケジュール・ポリシーにメンテナンス・ウィンドウを追加できます。

スケジュール・ポリシーを使用した四半期インフラストラクチャ・メンテナンスの実行に関する詳細なガイダンスは、「コンソールを使用したOracle管理インフラストラクチャ更新の構成」を参照してください。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーの詳細の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 詳細を表示するポリシーの名前をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーの編集

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 編集するポリシーの名前をクリックします。
  4. 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「スケジュール・ポリシーの編集」をクリックします。
  5. 表示された「スケジュール・ポリシーの編集」ウィンドウで、ポリシーの名前のみを編集できます。
  6. 名前を編集し、「スケジュール・ポリシーの編集」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

注意が必要な状態のメンテナンス・スケジュール・ポリシーの編集

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「注意が必要」状態のポリシーの名前をクリックします。
  4. 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「スケジュール・ポリシーの編集」をクリックします。
  5. 表示された「スケジューリング・ポリシーの編集」ウィンドウで、ポリシー設定を更新します。
  6. 「スケジュール・ポリシーの編集」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. メンテナンス・ウィンドウの詳細を表示するポリシーの名前をクリックします。

    結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの編集

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. メンテナンス・ウィンドウの詳細を編集するポリシーの名前をクリックします。

    結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。

  4. 編集するメンテナンス・ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの編集」を選択します。
  5. 表示された「メンテナンス・ウィンドウの編集」ページで、変更を行い、「保存」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーへの追加のメンテナンスWindowsの追加

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. メンテナンス・ウィンドウを追加するポリシーの名前をクリックします。

    結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。

  4. 「メンテナンス・ウィンドウの追加」をクリックします。

    ノート:

    セキュリティ・メンテナンスの場合、スケジュールされた開始時間を21日のウィンドウ内に追加できます。

  5. 表示された「メンテナンス・ウィンドウの追加」ページで、詳細を追加し、「追加」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

ポリシーに関連付けられたリソースの表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 関連付けられたリソースを表示するポリシーの名前をクリックします。

    結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「関連リソース」セクションには、ポリシーに関連付けられているリソースがリストされます。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーのメンテナンス・ウィンドウの削除

ノート:

メンテナンス・アクティビティを計画および自動化するためにリソースによって使用されないメンテナンス・ウィンドウのみをポリシーから削除できます。 サービスでメンテナンスを自動化するためにすでに使用されているウィンドウは削除できません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. メンテナンス・ウィンドウを削除するポリシーの名前をクリックします。

    結果の「メンテナンス・スケジューリング・ポリシーの詳細」ページの「メンテナンス・ウィンドウ」セクションには、ポリシーに関連付けられているメンテナンス・ウィンドウがリストされます。

  4. 削除する「メンテナンス」ウィンドウの「アクション」メニューをクリックし、「削除」を選択します。
  5. 表示される「メンテナンス・ウィンドウの削除」ダイアログで、「メンテナンス」ウィンドウの名前を入力し、「削除」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

別のコンパートメントへのメンテナンス・スケジューリング・ポリシーの移動

ノート:

ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 別のコンパートメントに移動するポリシーの名前をクリックします。
  4. 結果のメンテナンス・スケジューリング・ポリシーの詳細ページで、「アクション」メニューをクリックし、「リソースの移動」を選択します。
  5. 表示される「別のコンパートメントへのリソースの移動」ダイアログで、コンパートメントを選択し、「移動」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジュール・ポリシーへのタグの追加

ノート:

ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. タグを追加するポリシーの名前をクリックします。
  4. 表示された「メンテナンス・スケジュール・ポリシーの詳細」ページで、「タグの追加」をクリックします。
  5. 表示される「タグの追加」ダイアログで、タグを追加し、「タグの追加」をクリックします。

親トピック: メンテナンス・スケジューリング・ポリシー

メンテナンス・スケジューリング・ポリシーの削除

ノート:

ポリシーは、いずれかのリソースがメンテナンス・アクティビティの計画および自動化に使用している場合、削除できません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「メンテナンス」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 削除するポリシーの名前をクリックします。
  4. 結果のメンテナンス・スケジューリング・ポリシーの詳細ページで、「アクション」メニューをクリックし、「削除」を選択します。
  5. 表示された「メンテナンス・ポリシーの削除」ダイアログで、ポリシーの名前を入力し、「削除」をクリックします。

ノート:

ポリシーは、メンテナンス・スケジューリング・プランで使用されている場合、削除できません。

親トピック: メンテナンス・スケジューリング・ポリシー

コンソールを使用したOracle管理インフラストラクチャの更新の構成

Exadataインフラストラクチャ・ソフトウェアの完全な更新は、四半期ごとにスケジュールされます。 さらに、重要なセキュリティ更新は毎月スケジュールされます。 これらのインフラストラクチャの更新をオプトアウトすることはできませんが、OracleはCloud Notification Portalを使用して事前にアラートを送信し、スケジュールの柔軟性を利用して計画に役立てることができます。

四半期インフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。 Oracle Cloud Infrastructureコンソールで、メンテナンス・メソッドの編集、カスタム・アクションの有効化、Exadata Cloud@Customerのスケジュール済メンテナンス実行およびメンテナンス履歴の表示を行うこともできます。 セキュリティ・メンテナンスの場合、21日のウィンドウ内でスケジュールされた開始時間を編集できます。

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

四半期メンテナンス・プリファレンスの表示または編集

Oracle Exadata Database Service on Cloud@Customerインフラストラクチャの四半期メンテナンス・プリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。 変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされている変更は適用されません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「アクション」メニューをクリックし、「メンテナンス・プリファレンスの編集」を選択します。

    「メンテナンス作業環境の編集」ページが表示されます。

    ノート:

    メンテナンス作業環境の変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。

  6. 「メンテナンス作業環境の編集」ページで、次を構成します:
    • メンテナンス・スケジューリング・プリファレンス: Oracle管理スケジュール
      • メンテナンス・メソッドを選択してください:
        • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
        • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
      • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各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によって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
          • オプション。 「1日の時間」で、メンテナンス実行を開始する時間を指定します。 開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
          • 「通知リード・タイム」で、通知メッセージを受信するメンテナンス・イベントの最小週数を指定します。 リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
        • メンテナンス・メソッドを選択してください:
          • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
          • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
        • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
          • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

            ノート:

            カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。

            デフォルト: 15分

            最大: 120分

        • 拡張オプションの表示:
          • 月次セキュリティ・インフラストラクチャ・メンテナンスの有効化: 月次セキュリティ・インフラストラクチャ・メンテナンスを実行するには、このチェック・ボックスを選択します。
      • メンテナンス・スケジュール: スケジュール・ポリシーからのメンテナンス・ウィンドウ・プリファレンスの使用

        インフラストラクチャのプロビジョニング中に、スケジューリング・ポリシーを選択した後、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。 推奨される計画では、期間に基づいて、すべてのDBサーバー、ストレージ・サーバーおよびネットワーク・スイッチをポリシーのメンテナンス・ウィンドウにスケジュールします。 インフラストラクチャのプロビジョニング後、「メンテナンス・スケジューリング計画」リソースを編集してスケジューリング計画を更新し、特定のコンポーネントに更新をカスタマイズして、スケジューリング・ポリシーの異なるウィンドウに合せることができます。

        • 「ポリシーの選択」をクリックします。
        • 表示される「メンテナンス・スケジューリング・ポリシーの選択」ウィンドウで、コンパートメントとポリシーを選択します。

          メンテナンス・スケジューリング・ポリシーを作成して使用することもできます。 詳細は、「メンテナンス・スケジューリング・ポリシーの作成」を参照してください。 ポリシーの作成後に、追加のメンテナンス・ウィンドウをポリシーに追加できます。 詳細は、「メンテナンス・スケジュール・ポリシーへの追加のメンテナンスWindowsの追加」を参照してください。

        • 「変更の保存」をクリックします。

          ノート:

          変更は、次のメンテナンス実行から有効になります。

          アタッチされたポリシーで作成された関連付けられたメンテナンス・プランを削除する変更を行う前に、確認ダイアログで現在使用されているポリシー名を入力して選択を確認する必要があります。

          • インフラストラクチャに対して推奨されるメンテナンス・プランが作成および保存された後に、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更
          • スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびインフラストラクチャに沿ったメンテナンス・プリファレンスの定義への変更
          • スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびOracle管理のスケジュールに従って更新を適用することに変更します。

          前述の変更はすべて、現在のポリシーで作成されたインフラストラクチャのスケジューリング計画を削除し、後で同じポリシーをアタッチした場合、Oracle推奨計画に対するカスタマイズはすべて失われます。

  7. 「変更の保存」をクリックします。

    ローリングから非ローリング・メンテナンス・メソッドに切り替えると、「非ローリング・メンテナンス・メソッドの確認」ダイアログが表示されます。

    1. 表示されたフィールドにインフラストラクチャの名前を入力して変更を確認します。
    2. 「変更の保存」をクリックします。

親トピック: コンソールを使用したOracle管理インフラストラクチャの更新の構成

スケジュール・ポリシーを使用した四半期メンテナンス・プランの管理

スケジューリング・ポリシーが選択されると、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。

推奨される計画では、期間に基づいて、すべてのDBサーバー、ストレージ・サーバーおよびネットワーク・スイッチをポリシーのメンテナンス・ウィンドウにスケジュールします。 メンテナンス計画を更新し、更新を特定のコンポーネントにカスタマイズして、スケジューリング・ポリシーの様々なウィンドウに合せることができます。

親トピック: コンソールを使用したOracle管理インフラストラクチャの更新の構成

四半期メンテナンス・スケジュール・ポリシーの表示

インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを表示するには、この手順を使用します。

  1. ナビゲーション・メニューを開きます。 「データベース」の下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 四半期メンテナンス・スケジュール・ポリシーを表示するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。 「保守」セクションで、「四半期メンテナンス・スケジュール」ポリシーを見つけます。

  5. リンクをクリックして、ポリシーの詳細を表示します。
四半期メンテナンス・スケジュール・ポリシーの変更

インフラストラクチャの四半期メンテナンス・スケジュール・ポリシーを変更するには、この手順を使用します。

  1. ナビゲーション・メニューを開きます。 「データベース」の下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 四半期メンテナンス・スケジュール・ポリシーを表示するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。 「保守」セクションで、「四半期メンテナンス・スケジュール」ポリシーを見つけます。

  5. 「アクション」メニューをクリックし、「メンテナンス・プリファレンスの編集」を選択します。

    スケジュール・ポリシーの「顧客管理スケジュールおよび使用」メンテナンス・ウィンドウのプリファレンスが、ポリシー選択の一部として選択されます。

  6. 「ポリシーの選択」をクリックします。
  7. 既存のポリシーを選択するか、ポリシーを作成して選択します。
  8. 「変更の保存」をクリックします。

    ノート:

    変更は、次のメンテナンス実行から有効になります。

    • インフラストラクチャに対して推奨されるメンテナンス・プランが作成および保存された後に、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更するには、確認ダイアログで現在使用されているポリシー名を前に入力して選択を確認する必要があります。

    • ポリシー変更により、インフラストラクチャの現在のポリシーで作成されたスケジューリング計画が削除され、後で同じポリシーをアタッチした場合、Oracle推奨プランに対するカスタマイズはすべて失われます。
メンテナンス計画計画の表示

インフラストラクチャのメンテナンス・スケジュール計画を表示するには、この手順を使用します。

  1. ナビゲーション・メニューを開きます。 「データベース」の下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. メンテナンス・スケジュール・プランを表示するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「保守計画計画」をクリックします。

    「メンテナンス・スケジュール計画」セクションには、インフラストラクチャに関連付けられたメンテナンス・スケジュール計画が表示されます。 詳細には、プランに関連付けられたメンテナンス・ウィンドウ、ライフサイクル状態、時間単位の期間、スケジュール済アクションおよび見積り時間が含まれます。

    ノート:

    • すべてのインフラストラクチャ・コンポーネントがメンテナンス・スケジュール・プランの更新にスケジュールされていない場合、コンソールに、プランから欠落しているコンポーネントを示すバナーが表示され、プランには「注意が必要」ライフサイクル状態が反映されます。
    • Oracle Automationで次の四半期メンテナンス実行がスケジュールされる前に、欠落しているコンポーネントが計画に含まれていない場合、その四半期のメンテナンス実行の「未計画」メンテナンス・ウィンドウに自動的に追加されます。
メンテナンス・プランのスケジュール済アクションの編集

Exadata Cloud@Customerインフラストラクチャ・メンテナンス・スケジューリング・プランのスケジュール済アクションを編集するには、この手順を使用します。

  1. ナビゲーション・メニューを開きます。 「データベース」の下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. メンテナンス・スケジュール・プランを表示するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「保守計画計画」をクリックします。
  6. 「メンテナンス・スケジューリング・プラン」セクションで、アクションを編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「スケジュール済アクションの編集」を選択します。
  7. 表示される「スケジュール済アクションの編集」ウィンドウで、次の手順を実行します:
    • スケジュール済アクションを追加します:
      • 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
        • アクション・タイプの選択:
          • DBサーバーのExadata完全ソフトウェア更新
            • メンテナンス方法の構成:
              • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
              • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
              • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
                • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

                  ノート:

                  カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。

                  デフォルト: 15分

                  最大: 120分

            • DBサーバーの追加:
              • DBサーバーの選択: 選択したDBサーバーに対する更新は、現在スケジュールされているウィンドウからメンテナンス・アクションを追加するウィンドウに移動されます。
          • ストレージ・サーバーのExadata完全ソフトウェア更新
            • メンテナンス方法の構成:
              • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
              • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。

                ノート:

                非ローリング・ストレージ更新を適用するには、インフラストラクチャ内のすべてのストレージ・サーバーが単一のメンテナンス・アクションで更新されるようにスケジュールする必要があります。 これらの更新は適用されますが、データベース・ワークロードでは完全なダウンタイムが発生します。
            • ストレージ・サーバーの選択元: ストレージ・サーバーを追加するウィンドウを選択します。
            • 追加するメンテナンス処理の選択: ストレージ・サーバーの追加元となるアクションを選択します。
            • 追加するストレージ・サーバーの数を選択します: このアクションに追加するストレージ・サーバーの数を選択します。
          • ネットワーク・スイッチ・ソフトウェアの更新: 選択したメンテナンス・ウィンドウでネットワーク・スイッチのソフトウェア更新がすでにスケジュールされている場合、「ネットワーク・スイッチの更新は、選択したメンテナンス・ウィンドウに対してすでにスケジュールされています。」というメッセージが表示されたバナー。
      • 別のウィンドウからアクションを移動: アクションを移動するときに、特定のウィンドウで更新するようにスケジュールされたすべてのコンポーネントを新しいウィンドウに移動することを選択できます。
        • アクションを移動するウィンドウを選択してください: メンテナンス実行からウィンドウを選択します。
        • 移動するアクションを選択します: 移動するメンテナンス・ウィンドウから特定のアクションを選択します。
    • スケジュール済アクションの削除: メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、削除を選択します。

      ノート:

      • そのアクションで更新がスケジュールされているコンポーネントがないかぎり、任意のアクションを削除できます。
      • 更新がスケジュールされているアクションがそのウィンドウ内にないかぎり、すべてのウィンドウを削除できます。
    • スケジュール済アクションの編集:
      • メンテナンス・アクション・タイプ「DBサーバーの完全なソフトウェア更新」、「ストレージ・サーバーの完全なソフトウェア更新」および「ネットワーク・スイッチ・ソフトウェアの更新」の「アクション」メニュー(3つのドット)をクリックし、「スケジュール済アクションの編集」を選択します。

スケジュール済四半期メンテナンスの表示または編集

次回のスケジュール済メンテナンスの時間を表示および編集する方法を学習します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. コンパートメントを選択します。
  3. Exadata Infrastructureをクリックします。
  4. Exadata Infrastructuresのリストで、次にスケジュールされたメンテナンス・ウィンドウを設定するインフラストラクチャを探し、強調表示された名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

    ノート:

    情報ブロックは、ローリング・メンテナンス・メソッドまたは非ローリング・メンテナンス・メソッドを選択したかに関係なく、メンテナンス実行の開始の6時間前に表示されます。 メンテナンスが開始されると、自動的に削除されます。

  5. 「インフラストラクチャの詳細」ページで、「メンテナンス」をクリックします。

    Exadata Infrastructureのメンテナンス・ページが表示されます。

    ノート:

    スケジューリング・ポリシーの使用を選択した場合は、ポリシーへのリンクが表示されます。 リンクをクリックして、メンテナンス・スケジュール・ポリシーの詳細を表示します。 メンテナンス・ウィンドウを編集するには、「スケジュール計画から作成された四半期メンテナンス実行の管理」にリストされているトピックを参照してください。

  6. 「Exadata Infrastructureのメンテナンス」ページに、スケジュール済メンテナンスの詳細がリストされます。

    ターゲットDBサーバーのバージョンおよびターゲット・ストレージ・サーバーのバージョン:これらのフィールドには、スケジュールされたメンテナンスによって適用されるExadataソフトウェア・バージョンが表示されます。 適用されるバージョンは、クラウド内のExadataインフラストラクチャの最新の認定済更新です。 メンテナンスがスケジュールされているときに次の四半期更新がまだ認証されていない場合、新しい四半期更新が使用可能になるまで、バージョンは"LATEST"と表示されることがあります。 更新が使用可能になると、新しいバージョンが表示されます。

    Database Server Exadataソフトウェア・バージョンまたはStorage Server Exadataソフトウェア・バージョンの詳細は、My Oracle Supportノート「Exadata Database MachineおよびExadata Storage Serverでサポートされているバージョン(ドキュメントID 888828.1)」を参照してください。

  7. 次回のスケジュール済メンテナンス設定を変更するには、「メンテナンス実行の編集」をクリックします。
    「メンテナンスの編集」ページで、次のようにします:
    • メンテナンス・メソッド「ローリング」または「非ローリング」を選択します。

      ノート:

      「非ローリング」オプションを選択すると、コンポーネントが同時に更新されることを示す情報ブロックが表示され、システムの完全な停止時間が発生します。

    • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できる最大タイムアウト。

        デフォルト: 30分

        最大: 120分

    • 次の四半期メンテナンス実行を再スケジュールするには、「予定開始時間」フィールドに日時を入力します。
      次の制限が適用されます。
      • Oracleは、インフラストラクチャ・メンテナンスを少なくとも四半期に1回実行できると予想しています。 予期しない問題により次のメンテナンス四半期の前での対応が妨げられないかぎり、メンテナンス四半期の終わりを超えてメンテナンスを延期しないでください。
      • 予期しない問題により、スケジュールされたインフラストラクチャ・メンテナンス実行に対応できない場合、インフラストラクチャ・メンテナンスを前のインフラストラクチャ・メンテナンスから180日以内に別の日付に再スケジュールできます。 通常のメンテナンスは四半期ごとに実行する必要があるため、インフラストラクチャ・メンテナンスを再スケジュールするためにさらに約90日かかります。 Oracleでは、180日の制限付近にメンテナンスをスケジュールしないことを強くお薦めします。これは、追加の予期しない問題が発生した場合にそれ以上再スケジュールできる柔軟性がないためです。
      • 再スケジュールしたメンテナンスの実行前に新しいメンテナンス・リリースが発表された場合、指定した日付に新しいリリースが適用されます。
      • メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。 現在の時間がスケジュールされたメンテナンス開始時間から2時間以内である場合は、メンテナンスを再スケジュールできません。
      • Oracleでは、各四半期の特定の日付が内部メンテナンス操作用に予約されており、これらの日付にメンテナンスをスケジュールすることはできません。
    • 「変更の保存」をクリックします。
  8. 様々なコンポーネントの推定メンテナンス時間の詳細を表示するには、「合計見積メンテナンス時間」フィールドに「表示」リンクが表示されます。

    「表示」リンクは、Maintenanceメソッドが「ローリング」の場合にのみ「合計見積メンテナンス時間」フィールドに表示されます。

    「見積メンテナンス時間の詳細」ページに、次の詳細が表示されます:
    • 推定メンテナンス時間合計
    • データベース・サーバー推定メンテナンス時間
    • ストレージ・サーバー推定メンテナンス時間
    • ネットワーク・スイッチ推定メンテナンス時間
    • コンポーネントが更新される順序。 ローリング・メンテナンスでは、表示される順序でコンポーネントが更新されます
    1. データベース・サーバーのメンテナンスの一部として再起動されるVMの数を表示するには、「詳細の表示」リンクをクリックします。

      「VMのロケーション」ダイアログが表示されます。

    2. 「VMクラスタ名」フィールドでは、特定のVMが属するVMクラスタを確認できます。
    3. 閉じるをクリックします。
  9. 「閉じる」をクリックして、「見積メンテナンス時間の詳細」ページを閉じます。
  • メンテナンス進行中のメンテナンスの表示および編集
    メンテナンスの進行中に、カスタム・アクションを有効または無効にして、カスタム・アクションのタイムアウトを変更できます。     メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。
  • メンテナンスがカスタム・アクションを待機中のメンテナンスの表示および編集
    メンテナンスの進行中に、カスタム・アクションを有効または無効にして、カスタム・アクションのタイムアウトを変更できます。     メンテナンスがカスタム・アクションを待機している間、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。

関連トピック

親トピック: コンソールを使用したOracle管理インフラストラクチャの更新の構成

メンテナンス進行中のメンテナンスの表示および編集

メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「メンテナンス」をクリックします。
  6. 「メンテナンス実行の編集」をクリックします。

    「メンテナンスの編集」ページが表示されます。

    ノート:

    カスタム・アクション構成のみを編集でき、メンテナンス・メソッドやスケジュールされた開始時間は編集できません。 メンテナンスの進行中にカスタム・アクションの有効化または無効化、またはカスタム・アクション・タイムアウトの変更は、まだ更新されていないすべてのデータベース・サーバーに適用されます。

  7. メンテナンスの編集ページで、次のようにします:
    • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー以外の追加アクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

        デフォルト: 30分

        最大: 120分

  8. 「変更の保存」をクリックします。

    ローリング・メンテナンス・メソッドを構成した場合は、「合計見積メンテナンス時間」フィールドに「表示」リンクが表示されます。

    1. 「表示」をクリックします。
      「見積メンテナンス時間の詳細」ページに、次の詳細が表示されます:
      • 推定メンテナンス時間合計
      • データベース・サーバー推定メンテナンス時間
      • ストレージ・サーバー推定メンテナンス時間
      • ネットワーク・スイッチ推定メンテナンス時間
      • コンポーネントが更新される順序。 ローリング・メンテナンスでは、表示される順序でコンポーネントが更新されます。
    2. 閉じるをクリックします。
メンテナンスがカスタム・アクションを待機している間にメンテナンスを表示および編集

メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseで、Exadata Cloud at Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「メンテナンス」をクリックします。

    ノート:

    • カスタム・アクションを待機している間は、メンテナンス実行の編集は使用できません。
    • メンテナンスがカスタム・アクションを待機している間に、情報ブロックが表示されます。 情報ブロックは、メンテナンスが再開されると削除されます。
  6. 情報ブロックで、次のいずれかを実行します:
    1. 「今すぐメンテナンスを再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。

      「メンテナンスの再開」ダイアログが表示されます。 「今すぐメンテナンスを再開」をクリックします。

    2. 「カスタム・アクション・タイムアウトの拡張」をクリックします。

      最大許容時間2時間内にタイムアウトを複数回延長できます。 最大制限を超えて拡張しようとすると、「カスタム・アクション・タイムアウトを拡張できません」ダイアログが表示され、カスタム・アクション・タイムアウトがすでに最大許容時間2時間まで延長されており、それ以上延長できないことが示されます。

スケジュール済セキュリティ・メンテナンスの表示または編集

次にスケジュールされたセキュリティ・メンテナンスを表示および編集する方法について学習します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャがあるリージョンおよびコンパートメントを指定します。
  3. コンパートメントを選択します。
  4. メンテナンスの詳細を表示するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

    四半期および月次のメンテナンスの詳細は、「メンテナンス」セクションに表示されます。 月次セキュリティ・メンテナンスのラベルは「次のセキュリティ・メンテナンス」です。

  5. 「インフラストラクチャの詳細」ページで、「メンテナンス」をクリックします。

    Exadata Infrastructureのメンテナンス・ページが表示されます。 Exadata Infrastructureメンテナンス・ページには、「タイプ: 月次セキュリティ・メンテナンス」、「予定開始時間」などの詳細が含まれています。

  6. 月次セキュリティ・メンテナンスを再スケジュールするには、「メンテナンス実行の編集」をクリックし、21日サイクル内の新しい日付を選択します。

    ノート:

    一部のブラックアウト日付はセキュリティ・メンテナンスに使用できず、再スケジュール・カレンダでグレー表示されます。

  7. 日付を選択し、「変更内容を保存」をクリックします。
  8. メンテナンス履歴を表示するには、「メンテナンス履歴」をクリックします。

    「メンテナンス履歴」ページには、メンテナンスのタイプ(「毎月」または「四半期」)を含む詳細が表示されます。

    月次セキュリティ・メンテナンスが進行中の場合、インフラストラクチャ・リソースの状態は「使用可能」になります。

親トピック: コンソールを使用したOracle管理インフラストラクチャの更新の構成

メンテナンス履歴の表示

Oracle Exadata Database Service on Cloud@Customerインフラストラクチャのメンテナンス履歴を表示する方法について学習します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. コンパートメントを選択します。
  3. Exadata Infrastructureをクリックします。
  4. Exadata Infrastructuresのリストで、メンテナンス履歴を表示するインフラストラクチャを探し、強調表示された名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「インフラストラクチャの詳細」ページで、「保守履歴」をクリックして、完了状態の詳細、ターゲット・データベースおよびストレージ・サーバーのバージョンなど、過去のメンテナンス・イベントのリストを表示します。

    Database Server Exadataソフトウェア・バージョンまたはStorage Server Exadataソフトウェア・バージョンの詳細は、My Oracle Supportノート「Exadata Database MachineおよびExadata Storage Serverでサポートされているバージョン(ドキュメントID 888828.1)」を参照してください。

関連トピック

親トピック: コンソールを使用したOracle管理インフラストラクチャの更新の構成

スケジュール計画から作成された四半期メンテナンス実行の管理

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

メンテナンス実行に関連付けられたメンテナンス・ウィンドウの表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。

  5. 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。

    結果の「メンテナンス実行」ページの「メンテナンス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つのストレージ・サーバーに完全更新を適用します。 ネットワーク・スイッチはペアとして更新され、様々なアクションまたはメンテナンス・ウィンドウで更新するようにスケジュールすることはできません。 たとえば、2つのネットワーク・スイッチに完全更新を適用します。

    • 推定時間: メンテナンス実行のすべてのウィンドウにすべてのインフラストラクチャ・コンポーネントに更新を適用するようにスケジュールされているメンテナンス・アクションをOracle Automationが完了する推定時間。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンス実行に関連付けられたメンテナンス・ウィンドウの編集

ノート:

ウィンドウは「スケジュール済」ライフ・サイクル状態のまま、ウィンドウ・スケジュールの開始時間、期間および期間の強制など、ウィンドウ構成を更新できます。 ウィンドウが進行中の場合、構成を変更することはできません。 ウィンドウの実行中のメンテナンスを取り消すことを選択できます。 詳細は、「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの取消」の項を参照してください

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

  5. 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。

    結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。

  6. 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの編集」を選択します。
  7. 表示されたメンテナンス・ウィンドウの編集ダイアログで、「メンテナンス・ウィンドウの開始時間」、「期間(時間)」および「ウィンドウ期間の強制」フィールドを更新
  8. 「メンテナンス・ウィンドウの編集」をクリックします。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンス実行に関連付けられたメンテナンス処理の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

  5. 関連するメンテナンス・アクションを表示するアクティビティの名前をクリックします。
  6. 「メンテナンス・アクション」をクリックします。
  7. アクションを追加するには:
    1. 「アクションの追加」をクリックします。
    2. 表示される「メンテナンス・アクションの追加」ウィンドウの「アクション・タイプの選択」で、「メンテナンス・アクションの追加」をクリックします。
  8. 処理を削除する手順は、次のとおりです。
    1. メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンス実行に関連付けられたメンテナンス・ウィンドウのメンテナンス処理の編集

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

  5. 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。

    結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。

  6. 編集する「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションの編集」を選択します。 表示される「メンテナンス・アクションの編集」ページには、アクションのリストが表示されます。 アクションを追加することも、既存のアクションを削除することもできます。
  7. アクションを追加するには:
    1. 「アクションの追加」をクリックします。
    2. 表示される「メンテナンス・アクションの追加」ウィンドウで、次の手順を実行します:
      • 新規処理の作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
        • アクション・タイプの選択:
          • DBサーバーのExadata完全ソフトウェア更新
            • メンテナンス方法の構成:
              • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。
              • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
              • DBサーバーでメンテナンスを実行する前に、カスタム・アクションを有効にします: Oracleのプレビュー外で追加のアクションを実行する場合にのみ、カスタム・アクションを有効にします。 ローリング・ソフトウェア更新で構成されたメンテナンスの場合、このオプションを有効にすると、各DBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションがメンテナンス実行によって強制的に待機されます。 非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行はすべてのDBサーバー間でメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機します。 メンテナンス実行は、カスタム・アクションを待機している間も、タイムアウトの前に再開されることがあります。

                • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前にカスタム・アクションを実行できるタイムアウト。

                  ノート:

                  カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。 お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。 この時間内に、計画したアクションを実行できます。 カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。 カスタム・アクションが進行中の場合、顧客は2つのオプションを取得 - カスタム・アクション・タイムアウトを拡張するか、メンテナンス・ウィンドウを再開します。

                  デフォルト: 15分

                  最大: 120分

            • DBサーバーの追加:
              • DBサーバーの選択: 選択したDBサーバーに対する更新は、現在スケジュールされているウィンドウからメンテナンス・アクションを追加するウィンドウに移動されます。
          • ストレージ・サーバーのExadata完全ソフトウェア更新
            • メンテナンス方法の構成:
              • ローリング: デフォルトでは、Exadata Infrastructureはローリング方式で更新され、一度に1つのサーバーは停止時間なしで更新されます。

              • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。 非ローリング・メンテナンス・メソッドではメンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。

                ノート:

                非ローリング・ストレージ更新を適用するには、インフラストラクチャ内のすべてのストレージ・サーバーが単一のメンテナンス・アクションで更新されるようにスケジュールする必要があります。 これらの更新は適用されますが、データベース・ワークロードでは完全なダウンタイムが発生します。
            • ストレージ・サーバーの選択元: ストレージ・サーバーを追加するウィンドウを選択します。
            • 追加するメンテナンス処理の選択: ストレージ・サーバーの追加元となるアクションを選択します。
            • 追加するストレージ・サーバーの数を選択します: このアクションに追加するストレージ・サーバーの数を選択します。
          • ネットワーク・スイッチ・ソフトウェアの更新: 選択したメンテナンス・ウィンドウでネットワーク・スイッチのソフトウェア更新がすでにスケジュールされている場合、「ネットワーク・スイッチの更新は、選択したメンテナンス・ウィンドウに対してすでにスケジュールされています。」というメッセージが表示されたバナー。
      • 別のウィンドウからアクションを移動: アクションを移動するときに、特定のウィンドウで更新するようにスケジュールされたすべてのコンポーネントを新しいウィンドウに移動することを選択できます。
        • アクションを移動するウィンドウを選択してください: メンテナンス実行からウィンドウを選択します。
        • 移動するアクションを選択します: 移動するメンテナンス・ウィンドウから特定のアクションを選択します。
  8. 処理を削除する手順は、次のとおりです。
    1. メンテナンス・アクションの「アクション」メニュー(3つのドット)をクリックし、「削除」を選択します。

      ノート:

      • そのアクションで更新がスケジュールされているコンポーネントがないかぎり、任意のアクションを削除できます。
      • 更新がスケジュールされているアクションがそのウィンドウ内にないかぎり、すべてのウィンドウを削除できます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンス進行中のメンテナンスの表示および編集

メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

    ノート:

    「次四半期メンテナンス」フィールドに「メンテナンス中」ステータスが表示されます。
  5. 「次の四半期メンテナンス」フィールドの「ビュー」リンクをクリックします。

    メンテナンス実行履歴ページが表示されます。

  6. 「アクション」メニュー(3つのドット)をクリックし、「詳細の表示」を選択します。
  7. メンテナンス実行履歴ページで「メンテナンス・ウィンドウ」をクリックします。
  8. 進行中のメンテナンス・ウィンドウを識別
  9. 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・アクションの編集」を選択します。
  10. 「アクション」メニュー(3つのドット)をクリックし、「カスタム・アクション構成の編集」を選択します。
  11. 表示される「カスタム・アクション構成の編集」ページで、「カスタム・アクション(分)」と入力します。

    ノート:

    メンテナンスの進行中は、DBサーバー・アクション・タイプのカスタム・アクション時間のみ変更できます。 このオプションをサポートするためのカスタム処理時間は、他の処理タイプに対して変更できません。
  12. 「変更の保存」をクリックします。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンスがカスタム・アクションを待機している間にメンテナンスを表示および編集

メンテナンスが進行中、カスタム・アクションを有効または無効にし、カスタム・アクション・タイムアウトを変更できます。 メンテナンスがカスタム・アクションを待機している間に、タイムアウトの前にメンテナンスを再開するか、タイムアウトを延長できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」および「コンパートメント」を選択し、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
  3. Exadata Infrastructureをクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページには、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

    ノート:

    「次四半期メンテナンス」フィールドに「メンテナンス中」ステータスが表示されます。

  5. 「次の四半期メンテナンス」フィールドの「ビュー」リンクをクリックします。

    進行中のメンテナンス実行の詳細ページが表示されます。

  6. 表示される「メンテナンス実行」詳細ページで、「メンテナンス・アクション」をクリックします。

    メンテナンスがカスタム・アクションを待機している間に、情報ブロックが表示されます。 また、顧客のアクションを待機している間はメンテナンスを編集できません。 情報ブロックは、メンテナンスが再開されると削除されます。

  7. 情報ブロックで、次を実行します:
    1. 「今すぐメンテナンスを再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。

      「メンテナンスの再開」ダイアログが表示されます。 「今すぐメンテナンスを再開」をクリックします。

    2. 「カスタム・アクション・タイムアウトの拡張」をクリックします。

      最大許容時間2時間内にタイムアウトを複数回延長できます。 最大制限を超えて拡張しようとすると、「カスタム・アクション・タイムアウトを拡張できません」ダイアログが表示され、カスタム・アクション・タイムアウトがすでに最大許容時間2時間まで延長されており、それ以上延長できないことが示されます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

進行中のメンテナンス実行の取消

メンテナンス実行に関連付けられたメンテナンス・ウィンドウを取り消すには、次のステップに従います:

ノート:

ウィンドウに対してスケジュールされた更新の進行中に、実行中のメンテナンスを取り消すことができます。 更新の進行中にメンテナンスを取り消すと、まだ開始していないすべてのアクションを、選択した将来のメンテナンス・ウィンドウに再スケジュールできます。 新しい開始時間と期間を選択して、取り消すことにしたメンテナンス・ウィンドウから再スケジュールされたすべてのアクションを終了できます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

  5. 関連するメンテナンス・ウィンドウを表示するアクティビティの名前をクリックします。

    結果の「メンテナンス実行」ページの「メンテナンスWindows」セクションには、選択したアクティビティに関連付けられたメンテナンス・ウィンドウがリストされます。

  6. 取り消す「メンテナンス」ウィンドウの「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

進行中のメンテナンス実行を取り消すには、次のステップに従います:

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

  5. 取り消す「進行中」アクティビティの名前をクリックします。
  6. メンテナンス実行の詳細ページで「メンテナンス・ウィンドウ」をクリックします。
  7. 進行中のメンテナンス・ウィンドウを識別します。
  8. 「アクション」メニュー(3つのドット)をクリックし、「メンテナンス・ウィンドウの取消」を選択します。
  9. 結果の「メンテナンス実行の取消」ウィンドウで、「メンテナンス・ウィンドウの開始時間」を再構成します。
  10. 「ウィンドウ期間の強制」チェック・ボックスを選択すると、将来のメンテナンス・ウィンドウで再開するために、構成済のウィンドウ期間を超えるスケジュール済アクションが一時停止および再スケジュールされます。
  11. 「メンテナンス実行の再スケジュール」をクリックします。

ノート:

メンテナンス実行により、現在の操作が完了します。 このウィンドウにスケジュールされている残りのすべてのアクションは、新しいメンテナンス・ウィンドウに再スケジュールされます。

コンパートメントのメンテナンス・アクティビティの表示

ノート:

メンテナンス・アクティビティには、選択したExadataクラウド・サービスの特定のコンパートメント内のすべてのインフラストラクチャ・リソースに対して実行するようにスケジュールされているすべてのメンテナンス更新がリストされます。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントのメンテナンス・アクティビティがリストされます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

メンテナンス活動の詳細の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「アクティビティ」をクリックします。

    結果の「アクティビティ」ページには、選択したコンパートメントで実行するようにスケジュールされているメンテナンス更新がリストされます。

  5. 詳細を表示するメンテナンス・アクティビティの「アクション」メニュー(3つのドット)をクリックします。

    結果の「メンテナンス実行」ページには、選択したメンテナンス・アクティビティの詳細が表示されます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

コンパートメントのメンテナンス履歴の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「履歴」をクリックします。

    表示されるページには、選択したコンパートメントのメンテナンス実行の履歴が表示されます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

コンパートメントのメンテナンス履歴詳細の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リソース」の下で、「スケジュール・ポリシー」をクリックします。

    結果の「スケジュール・ポリシー」ページに、ポリシーのリストが表示されます。

  3. 「コンパートメント」フィルタからコンパートメントを選択します。
  4. 「メンテナンス」の下で、「履歴」をクリックします。

    結果の「履歴」ページには、メンテナンス実行ステータス(成功または失敗)と、選択したコンパートメントのメンテナンス・アクティビティの他の詳細がリストされます。

    失敗した場合、自動化によって実行が「失敗」とマークされ、ターゲット・バージョンに更新する必要がある残りのコンポーネントを含む新しいウィンドウが自動的に再スケジュールされます。 同じ更新順序が継承されます。

  5. 詳細を表示するメンテナンス・アクティビティの「アクション」メニュー(3つのドット)をクリックします。

    結果の「メンテナンス履歴」ページには、選択したメンテナンス・アクティビティの詳細が表示されます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

未計画メンテナンス活動のレビューおよび応答

メンテナンス計画後にインフラストラクチャをスケーリングする場合の未計画メンテナンス・アクティビティ

  • DBサーバーまたはストレージ・サーバーを追加してインフラストラクチャをスケーリングした後、これらの新しいコンポーネントを含めるようにメンテナンス・スケジュール計画を更新する必要がある場合があります。 メンテナンス・プランにインフラストラクチャ・コンポーネントがない場合、インフラストラクチャ・メンテナンス・プランの詳細セクションに警告が表示されます。
  • Oracle Automationによって四半期のメンテナンス実行が作成されると、メンテナンス計画に含まれていないコンポーネントはすべて、自動的に「計画外」メンテナンス・ウィンドウに追加されます。 これにより、すべてのコンポーネントに、四半期ごとに正しいシステム・ソフトウェアが適用され、OCIソフトウェアのコンプライアンスが維持されます。
  • 必要に応じて、「未計画」ウィンドウの予定開始時間を編集するか、欠落しているコンポーネントの更新を既存の計画ウィンドウに移動できます。

スケジュールされた更新の適用に失敗した場合の未計画メンテナンス・アクティビティ

  • スケジュールされた更新が失敗した場合、Oracleオペレーション・チームは、失敗を評価し、失敗した更新を将来のメンテナンス・ウィンドウに対する未完了の更新とともに再スケジュールします。 Oracle Automationにより、この再スケジュールされたウィンドウが「未計画」としてマークされ、再スケジュールされたメンテナンス・アクティビティのレビューが通知されます。
  • 必要に応じて、「未計画」ウィンドウの予定開始時間を編集したり、失敗および未完了の更新を既存の計画ウィンドウに移動できます。

スケジュール・アクティビティが強制ウィンドウ期間を超えた場合の未計画メンテナンス

  • 期間強制で構成されたメンテナンス・ウィンドウの場合、Oracle Automationは、実行の見積時間を確認し、スケジュール済更新を適用する時間が残りのウィンドウ期間内に十分かどうかをチェックします。 そうでない場合は、Oracle自動化により、未完了のすべての更新が将来の「未計画」ウィンドウに自動的に再スケジュールされ、現在のウィンドウに「期間超過」のマークが付けられ、再スケジュールされたメンテナンス・アクティビティを確認するよう通知されます。
  • すでに進行中の更新は、基礎となるリソースの一貫した状態を確保するために、強制されたウィンドウ期間を超えて継続されます。

親トピック: スケジュール計画から作成された四半期メンテナンス実行の管理

ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスの監視

Exadata Infrastructureリソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。

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

インフラストラクチャのメンテナンス操作時には、次のことが想定されます:
  • メンテナンス・ウィンドウを指定すると、指定した開始時間にパッチ適用が開始されます。 インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変更されます。

    ノート:

    これで、事前チェックはメンテナンスの開始前に実行されます。
  • Exadataデータベース・サーバーのメンテナンスが開始すると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」で、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャを更新しています」です。
  • ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」で、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基盤となるインフラストラクチャが更新され、データベースの可用性に影響が及びません」です。
  • ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチはローリング方式で一度に1つずつ更新されます。
  • メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールはライフサイクル状態メッセージを提供しません。

関連トピック

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

インフラストラクチャ・メンテナンス更新に関する通知の受信

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

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

Oracle Cloud Infrastructureイベントの詳細は、「イベントの概要」を参照してください。 インフラストラクチャ・メンテナンス連絡先に送信された通知以外の通知を受信するには、インフラストラクチャ・メンテナンス・イベントをサブスクライブして、Oracle Notificationサービスを使用して通知を受けることができます(「通知の概要」を参照)。

関連トピック

親トピック: Oracle管理インフラストラクチャ・メンテナンスの構成

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管理インフラストラクチャ・メンテナンスの構成