Oracle Cloud Infrastructureドキュメント

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

Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。

Oracleは、Exadata Cloud Infrastructureインフラストラクチャで定期的なメンテナンスを実行して、データベースの可用性、整合性およびセキュリティに影響を与える可能性のある潜在的な問題がないことを確認します。インフラストラクチャで実行されているソフトウェアを最新の製品およびセキュリティ修正で更新すると、データおよびOracle Cloudの全体的なコンプライアンスが保護されます。これらの更新は自動化された方法で実行され、すべてのベストプラクティスが含まれているため、インフラストラクチャの維持に投資する必要がなくなります。Oracleの更新には、物理データベース・サーバー・ホスト、ストレージ・サーバー、ネットワーク・ファブリックおよび管理スイッチ(InfiniBandシステムのみ)、配電ユニット(PDU)、統合ライトアウト管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。

Oracleでは、次の2つのタイプのインフラストラクチャ・メンテナンスが実行されます。

  • 四半期メンテナンスは3か月ごとに適用され、製品の修正、拡張機能およびセキュリティ修正を含めることができます。
  • 月次メンテナンスでは、オンラインで適用できる重要なセキュリティ修正のみが適用され、コンポーネントが最高のセキュリティ標準で維持され、セキュリティ脆弱性はできるだけ早く修正されます。

四半期メンテナンス

Oracleは、ローリング・メンテナンス操作を使用してアプリケーションに四半期メンテナンスの影響を最小限に抑え、更新プロセス全体でデータベースの可用性を維持します。ローリング・メンテナンスでは、各データベース・サーバーが一度に1つずつ再起動され、一度に最大1つのサーバーがオフラインになります。高可用性を実現するために設計されたアプリケーションは、中断することなく、使用可能なデータベース・インスタンス間でデータベース接続を自動的かつ透過的に移行するため、ダウンタイムをスケジュールする必要はありません。ストレージ・サーバーの更新もローリング方式で適用されます。ストレージ・サーバーの再起動はデータベース・サービスに影響しないため、アプリケーションには影響しません。

Oracleでは、四半期メンテナンス・スケジュールを完全に制御できるため、ビジネス・ユーザーへの影響が最も少ない期間にメンテナンスをスケジュールできます。四半期メンテナンスがいつ適用されるかを完全に管理および表示できます。また、予期しないビジネス上の問題が発生した場合にメンテナンスを再スケジュールすることもできます。

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

月次セキュリティ・メンテナンスは、データベース・サーバー上でオンラインで実行され、再起動は行われず、アプリケーションへの影響もありません。月次更新はローリング方式でストレージ・サーバーに適用され、アプリケーションにも影響を与えません。

月次セキュリティ・メンテナンスは、1つのメンテナンス・ウィンドウにあっても、月の特定の時間にスケジュールすることもできます。Oracleは、メンテナンス期間の開始の少なくとも1週間前に月次メンテナンスのスケジュールを公開し、必要に応じて再スケジュールできます。

親トピック: ハウツー・ガイド

Oracle管理のExadata Cloud Infrastructureメンテナンスについて

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

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

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

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

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

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

ノート

Oracle Cloud Infrastructure (OCI) US Government (OC2)および米国国防総省(OC3)リージョンでExadata Database on Dedicated Infrastructureを使用するお客様は、OCIコンソールを使用して、月次および四半期ごとのパッチ適用イベントを再スケジュールできます。

現時点では、Exadata Cloud Infrastructureのパッチ管理スケジュールの設定と呼ばれるメンテナンス・スケジュールの指定は、Exadataパッチ管理のOCI US Government (OC2)およびUS DOD (OC3)レルムではまだ使用できません。パッチ管理再スケジュール時のExadata Database on Dedicated Infrastructureの詳細は、こちらを参照してください。

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

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

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

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

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

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

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

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

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

ノート

パッチ適用ウィンドウ中はデータベースまたはアプリケーションで主要なメンテナンス操作を実行しないでください。これらの操作はインフラストラクチャ・メンテナンス操作によって影響を受ける可能性があるためです

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

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

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

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

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

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

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

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

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

四半期メンテナンス前の月次セキュリティ・メンテナンス

  • 四半期メンテナンスの前にセキュリティ・メンテナンスを適用するには、四半期メンテナンスの24時間以上前に月次セキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、アプリケーションに影響を与えずにデータベース・サーバーにセキュリティ・パッチをオンラインに適用し、アプリケーションへの影響を最小限に抑えてストレージ・サーバーに更新を適用します(パフォーマンスがわずかに低下する可能性があります)。四半期メンテナンスはスケジュールどおりに実行され、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期メンテナンスの一環として、システムにすでにインストールされているデータベース・サーバーに同じセキュリティ更新が適用されます(セキュリティ回帰はありません)。
  • 最新のセキュリティ更新が適用される場合、新しい月次メンテナンス・ウィンドウが開いた後に(通常は月の21日に)月次セキュリティ・メンテナンスを実行するようにスケジュールします。
  • ストレージ・サーバーの毎月のセキュリティ・メンテナンスの再起動による影響は最小限に抑える必要があるため、今月のアプリケーションへの影響は、四半期メンテナンス中のデータベース・サーバーの再起動によるものです。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。

月次セキュリティ・メンテナンス前の四半期メンテナンス

  • 月次セキュリティ・メンテナンスの前に四半期メンテナンスを実行するには、四半期メンテナンスの開始がスケジュールされる24時間以内に実行されるようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。四半期メンテナンスでは、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期ごとのメンテナンスでは、ストレージ・サーバーのパッチ適用がスキップされる場合とスキップされない場合があります。これは、現在インストールされているリリースより新しいものか古いものかによって異なります。ほとんどの場合、インストールされるバージョンは、四半期メンテナンスに関連付けられているバージョンより新しいバージョンである必要があります。このルールの例外は、メンテナンス四半期の最初の月である場合、または1つ以上の前の月のセキュリティ・メンテナンスをスキップした場合に発生する可能性があります。セキュリティ・メンテナンスは、四半期メンテナンスの完了直後に、またはスケジュールされたいずれか遅い方で実行されます。データベース・サーバーへのオンライン更新(アプリケーションへの影響なし)が適用され、ローリング方式でストレージ・サーバーが更新される可能性があります。場合によっては、四半期メンテナンスにセキュリティ・メンテナンスと同じストレージ・サーバー・リリースが含まれている可能性があり、セキュリティ・メンテナンス・ストレージ・サーバーの更新はスキップされます。
  • セキュリティ・メンテナンスの前に四半期メンテナンスを実行するエンド・ユーザーへの影響は、セキュリティ・メンテナンスを最初に実行する場合とほぼ同じである必要があります。四半期ごとのメンテナンスは中断を伴うイベントですが、ストレージ・サーバーを再起動するセキュリティ・メンテナンスによって中断が最小限に抑えられ、セキュリティ・メンテナンスがオンラインのデータベース・サーバーに適用されます。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。これらの2つのメンテナンス・ウィンドウを、エンド・ユーザーに単一のメンテナンス・ウィンドウとして表示されるように連続して実行するようにスケジュールできます。これを行うには、四半期メンテナンスと同時に(または24時間前まで)開始するようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。毎月のセキュリティ・メンテナンスを定期的に適用している場合、ストレージ・サーバーは四半期メンテナンスによってスキップされ、四半期メンテナンスの完了直後にセキュリティ・メンテナンスによって更新されます。

メンテナンスWindowsの最小化

  • メンテナンス・ウィンドウの数を最小限に抑えるには(エンド・ユーザーとのネゴシエーションが必要)、四半期メンテナンスと月次メンテナンスを同時にスケジュールします。セキュリティ・メンテナンスはブロックされます。四半期メンテナンスでは、ローリング方式でデータベース・サーバーが更新され、おそらくストレージ・サーバーはスキップされます。セキュリティ・メンテナンスはただちにフォローアップされ、データベース・サーバーをオンラインおよびストレージ・サーバーにローリング方式で更新します。その結果、単一のメンテナンス・ウィンドウでデータベースとストレージ・サーバーが再起動されます。
  • 二つの例外がある(1)四半期メンテナンスと月次メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスによってストレージ・サーバー更新が適用され、セキュリティ・メンテナンスはスキップされます。1つのメンテナンス・ウィンドウでも、これは1回のローリング再起動です。2.ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれるリリースより古く、セキュリティ・メンテナンスのリリースより古くなっています。これにより、四半期メンテナンスでストレージが更新され、その後セキュリティ・メンテナンスでストレージも更新されます。これは、前の月のセキュリティ・メンテナンスをスキップした場合にのみ発生する可能性があります。これは、現在のイメージが2か月以上古くなっている必要があるためです。このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。これにより、1つのストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウ(セキュリティ・メンテナンスでは1つ目、その後は四半期メンテナンス)になります。
  • エンド・ユーザーへの影響を最小限に抑えるには、常に月次セキュリティ更新を適用し、両方がスケジュールされている月単位で同時にスケジュールします。
ノート

Oracleがセキュリティ・メンテナンスをスケジュールする前にExadataインフラストラクチャがプロビジョニングされた場合、セキュリティ・メンテナンスの対象となります。

スケジュールされた月次Exadataインフラストラクチャ・メンテナンスの前にいつでも再スケジュールできます。

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

OCIコンソールを使用して、メンテナンス・スケジューリング・ポリシーを構成および管理する方法について学習します。

メンテナンス・スケジューリング・ポリシーでは、フリート全体のスケジュールを標準化し、一貫性と効率性を確保します。単一のポリシーを定義し、それを複数のリソースに適用することで、スケジューリング・プロセスが合理化され、メンテナンス・アクティビティがビジネスのベスト・プラクティスに合せられます。

ポリシーは、中央リポジトリとして機能し、ステークホルダーとのメンテナンスコミットメントを文書化し、調整することで、コンプライアンスと運用効率を向上させます。集中管理により、コンプライアンス要件への準拠が保証され、単一の制御ポイントからの変更を効率的に調整できます。さらに、このポリシーにより、フリート内の環境間の計画メンテナンスに関するコミュニケーションが強化され、より適切な調整と認識が促進されます。

メンテナンス・スケジューリング・ポリシーを使用する場合、インフラストラクチャ・メンテナンスのすべてのスケジューリング・プリファレンスはポリシーから導出されます。インフラストラクチャ内で定義されたプリファレンスは、ポリシーの使用中は有効ではありません。

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

保守スケジュール・ポリシーのリストの表示

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

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

  3. 「コンパートメント」フィルタを使用して、特定のコンパートメントで作成されたポリシーのリストを表示します。
  4. 「状態」は、状態によってポリシーをフィルタします。

    ポリシーの状態は次のとおりです。

    • 作成中
    • 注意が必要
    • 選択可能
    • 更新しています
    • 失敗しました
    • 削除中
    • 削除されました

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

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

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

  3. 「メンテナンス・スケジューリング・ポリシーの作成」をクリックします。
  4. 表示される「メンテナンス・スケジューリング・ポリシーの作成」ウィンドウで、次のように入力します。
    1. 名前:ポリシーの記述名を入力します。
    2. コンパートメント:このリソースを作成するコンパートメントを選択します。
    3. 頻度:頻度を選択します。
      使用可能なオプション:
      1. 6か月ごと
      2. 四半期ごと
        ノート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート

メンテナンス・ウィンドウがないスケジュール・ポリシーを使用して、サービス全体のメンテナンス・アクティビティを計画および自動化することはできないため、「注意が必要」ライフ・サイクル状態になります。ポリシーにはウィンドウが定義されていませんが、ケイデンスやスケジュール開始月など、すべてのプロパティを変更できます。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。

  2. 「メンテナンス」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    セキュリティ・メンテナンスの場合、21日のウィンドウ内にスケジュールされた開始時間を追加できます。
  5. 表示された「メンテナンスの追加」ウィンドウ・ページで、詳細を追加し、「追加」をクリックします。

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

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

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

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

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

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

ノート

メンテナンス・アクティビティを計画および自動化するためにリソースによって使用されないメンテナンス・ウィンドウのみをポリシーから削除できます。サービスでメンテナンスを自動化するためにすでに使用されているウィンドウは削除できません。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「メンテナンス」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

ノート

ポリシーを使用してメンテナンス・アクティビティを計画および自動化するリソースがある場合は、コンパートメント間でポリシーを移動できません。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「メンテナンス」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

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

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

ノート

いずれかのリソースがポリシーを使用してメンテナンス・アクティビティを計画および自動化する場合、ポリシーを削除できません。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「メンテナンス」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

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

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

ノート

スケジューリング・ポリシーは、四半期ごとのインフラストラクチャ・メンテナンス更新に使用できます。ただし、月次セキュリティ更新では、メンテナンスのスケジュール・ポリシーはサポートされません。Oracle Automationにより、インフラストラクチャの月次セキュリティ更新が自動的にスケジュールされます。

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

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

このタスクでは、四半期メンテナンス・プリファレンスの設定方法について説明します。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。

ノート

メンテナンス・スケジュールの指定は、政府リージョンでは使用できません。
  1. ナビゲーション・メニューを開きます。「Oracle Database」、「Oracle Exadata Database Service on Dedicated Infrastructure」の順にクリックします。
  2. アクセスするクラウドExadataインフラストラクチャに移動します:

    「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。

    インフラストラクチャの詳細ページが表示されます。

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

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

    ノート

    メンテナンス・プリファレンスに加えられた変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。
  4. 「メンテナンスのプリファレンスの編集」ページで、次を構成します:
    • メンテナンス・スケジュール・プリファレンス: Oracle管理スケジュール
      • メンテナンス方法の選択:
        • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
        • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
      • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
        • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
          ノート

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

          デフォルト: 15分

          最大: 120分

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

        次回のメンテナンス実行以降は、Oracleのスケジュールに従って実行されます。
    • メンテナンス・スケジューリング・プリファレンス: 顧客管理スケジュール
      • メンテナンス・スケジュール:このインフラストラクチャのメンテナンス・プリファレンスを定義します。

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

        • 保守作業環境の構成:各四半期の保守時間作業環境を定義します。1つの四半期に複数のプリファレンスを定義すると、Oracle Automationにより、その中の1つが選択され、インフラストラクチャのすべてのコンポーネントでメンテナンスが実行されます。

          2四半期ごとに少なくとも1か月を選択します。

        • スケジュールの指定: インフラストラクチャ・メンテナンスに対して希望する週、平日、開始時刻およびリード・タイムを選択します。
          • オプションです。「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。月の週を指定しない場合は、Oracleによって、中断が最小限になる週にメンテナンス更新が実行されます。
          • オプションです。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
          • オプションです。「1日の時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
          • 「通知リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
        • メンテナンス方法の選択:
          • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
          • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
        • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
          • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
            ノート

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

            デフォルト: 15分

            最大: 120分

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

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

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

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

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

          変更は、次のメンテナンス実行から有効になります。
          アタッチされたポリシーで作成された関連付けられたメンテナンス・プランを削除する変更を行う前に、確認ダイアログで現在使用されているポリシー名を入力して選択を確認する必要があります。
          • インフラストラクチャに対して推奨されるメンテナンス計画を作成して保存した後、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更
          • スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびインフラストラクチャに沿ったメンテナンス・プリファレンスの定義への変更
          • スケジューリング・ポリシーの使用からポリシーを使用しないこと、およびOracle管理のスケジュールに従って更新を適用することに変更します。

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

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

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

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

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

スケジューリング・ポリシーが選択されると、Oracleでは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング計画が生成されます。推奨計画では、期間に基づいてポリシーからメンテナンス・ウィンドウにすべてのDBサーバー、ストレージ・サーバーの順にスケジュールします。保守スケジューリング計画を更新し、更新を特定のコンポーネントにカスタマイズして、スケジューリング・ポリシーの異なるウィンドウに合せることができます。

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

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

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

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

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

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

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

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

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

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

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

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

    変更は、次のメンテナンス実行から有効になります。
    • インフラストラクチャに対して推奨されるメンテナンス・プランが作成および保存された後に、あるスケジューリング・ポリシーから別のスケジューリング・ポリシーに変更するには、確認ダイアログで現在使用されているポリシー名を前に入力して選択を確認する必要があります。
    • ポリシー変更により、インフラストラクチャの現在のポリシーで作成されたスケジューリング計画が削除され、後で同じポリシーをアタッチした場合、Oracle推奨プランに対するカスタマイズはすべて失われます。
メンテナンス・スケジューリング・プランの表示

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

このインフラストラクチャのメンテナンス・スケジューリング・プランは、関連付けられたスケジューリング・ポリシーに従って作成され、メンテナンス・ウィンドウ全体で、インフラストラクチャ・コンポーネントが更新されます。

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

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

  5. 「メンテナンス・スケジューリング・プラン」をクリックします。

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

    ノート

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

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

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

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

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

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

                  デフォルト: 15分

                  最大: 120分

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

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

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

Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには

Exadata Cloud Infrastructureのスケジュールされた四半期メンテナンスのプロパティを確認および変更します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:

    クラウドExadataインフラストラクチャ(新しいリソース・モデル): 「Oracle CloudのExadata」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。

    DBシステム: 「ベア・メタル、VMおよびExadata」で、「DBシステム」をクリックします。DBシステムのリストで、アクセスするExadata DBシステムを検索し、名前をクリックしてその詳細を表示します。

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

    ノート

    情報ブロックは、ローリング・メンテナンス方法と非ローリング・メンテナンス方法のどちらを選択した場合でも、メンテナンス実行の開始の6時間前に表示されます。メンテナンスが開始されると、これは自動的に削除されます。
  3. リソースの詳細ページの「メンテナンス」で、「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。

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

    ノート

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

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

    データベース・サーバーのExadataソフトウェア・バージョンまたはストレージ・サーバーのExadataソフトウェア・バージョンに関する情報を検索するには、My Oracle SupportノートのExadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)を参照してください。

    スケジュール済Exadataインフラストラクチャ・リソース・メンテナンス・イベントごとに、次の詳細が「メンテナンス」ページにリストされます:

    • イベントのステータス
    • イベントのOCID
    • イベントのスケジュール済開始日時
    • メンテナンス・イベントをただちに開始するには、「今すぐパッチ」をクリックします。プロンプトが表示されたら、「メンテナンスの実行」をクリックして、イベントを今すぐ開始することを確認します。

    リソースのメンテナンス・イベントが開始されるときに、Exadataインフラストラクチャ・リソースによってホストされる1つ以上のVMクラスタでメンテナンス・イベントがすでに進行中の場合、Exadataインフラストラクチャ・リソースのメンテナンス・イベントはキューに入れられ、すべてのVMクラスタ・メンテナンス・イベントが完了した後、ただちに開始されます。

  5. 次回のスケジュール済メンテナンス設定を変更するには、「メンテナンス実行の編集」をクリックします。
  6. 「メンテナンスの編集」ページで、次を実行します:
    • メンテナンス方法として、「ローリング」または「非ローリング」を選択します。
      ノート

      「非ローリング」オプションを選択すると、コンポーネントが同時に更新され、完全なシステム・ダウンタイムが発生します。
    • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できる最大タイムアウト。

        デフォルト: 30分

        最小: 15分

        最大: 120分

    • 次回のメンテナンス実行を再スケジュールするには、「スケジュール開始時間」フィールドに日時を入力します。

      次の制限事項が適用されます。

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

    「表示」リンクは、メンテナンス方法が「ローリング」の場合にのみ、「推定メンテナンス時間合計」フィールドに表示されます。

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

      「VMの場所」ダイアログが表示されます。

    2. 「VMクラスタ名」フィールドで、特定のVMが属するVMクラスタを確認できます。
    3. 「閉じる」をクリックします。
  8. 「閉じる」をクリックして、「推定メンテナンス時間詳細」ページを閉じます。

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

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

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

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

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

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

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

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

    ノート

    カスタム・アクション構成のみを編集でき、メンテナンス方法やスケジュールされた開始時間は編集できません。メンテナンス進行中のカスタム・アクションの有効化または無効化、またはカスタム・アクション・タイムアウトの変更は、まだ更新されていないすべてのデータベース・サーバーに適用されます。
  7. 「メンテナンスの編集」ページで、次を実行します:
    • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。

        デフォルト: 30分

        最大: 120分

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

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

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

メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集

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

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

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

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

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

    ノート

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

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

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

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

スケジュールされたセキュリティ・メンテナンスを表示または編集するには

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

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

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

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

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

    「Exadata Infrastructureメンテナンス」ページが表示されます。「Exadataインフラストラクチャのメンテナンス」ページには、タイプ: 月次セキュリティのメンテナンス、スケジュール済開始時間などの詳細が含まれます。

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

    特定のブラックアウト日はセキュリティ・メンテナンスに使用できず、再スケジュール・カレンダでグレー表示されます。
  7. 日付を選択し、「変更の保存」をクリックします。
  8. メンテナンス履歴を表示するには、「メンテナンス履歴」をクリックします。

    「メンテナンス履歴」ページには、メンテナンスのタイプ、「月次」または「四半期」などの詳細が表示されます。

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

Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには

このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースに対するメンテナンス履歴を表示する方法について説明します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」、「Oracle Exadata Database Service on Dedicated Infrastructure」の順にクリックします。

  2. アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:

    「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。

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

    メンテナンス・ジョブ、パッチ適用の状態およびタイプが表示されます。

スケジュールされたインフラストラクチャ・メンテナンス実行のノードのパッチ適用順序を設定するには

このタスクでは、クラウドExadataインフラストラクチャまたはExadata DBシステム・リソースのスケジュール済インフラストラクチャ・メンテナンス実行に対してノードのパッチ適用順序を設定する方法について説明します。

ノート

デフォルトでは、スケジュールされたすべてのメンテナンス実行は、最初はローリング・パッチ適用を使用するように設定されています。ローリング以外のパッチ適用を使用するには、スケジュール後にメンテナンス実行ごとにこの設定を変更する必要があります。

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Public Cloud上のExadata」をクリックします
  2. アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:

    • クラウドExadataインフラストラクチャ(新しいリソース・モデル): 「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。

    • DBシステム: 「ベア・メタル、VMおよびExadata」で、「DBシステム」をクリックします。DBシステムのリストで、アクセスするExadata DBシステムを検索し、その名前をクリックしてその詳細を表示します。

  3. リソースの詳細ページで、「メンテナンス」をクリックします。
  4. 「メンテナンス」ページで、「メンテナンス実行の編集」をクリックします。
  5. 必要に応じて、メンテナンス方法を「ローリング」または「非ローリング」に変更してください。
  6. 「保存」をクリックします。

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

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

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

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

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

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

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

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

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

    • 開始時間(UTC):ウィンドウ開始時間(UTC)。たとえば、Sun、2024年6月23日、18:30:58 UTCです。
      次の制限事項が適用されます。
      • Oracleでは、少なくとも四半期に1回はインフラストラクチャ・メンテナンスを実行できると予想しています。メンテナンス四半期の終了以降にメンテナンスを延期しないでください。予期しない問題により次のメンテナンス四半期までにメンテナンスに対応できなくなる場合を除きます。
      • 予期しない問題により、スケジュールされたインフラストラクチャ・メンテナンス実行に対応できない場合、インフラストラクチャ・メンテナンスは、前のインフラストラクチャ・メンテナンスから180日以内の別の日付に再スケジュールできます。通常メンテナンスは四半期ごとに実行する必要があるため、インフラストラクチャ・メンテナンスを再スケジュールするために約90日間追加されます。Oracleでは、180日の制限時間またはそれに近い時間にメンテナンスをスケジュールしないことを強くお薦めします。予期しない追加の問題が発生した場合に柔軟に再スケジュールできないためです。
      • 再スケジュールされたメンテナンス実行より前に新しいメンテナンス・リリースが公開された場合、その新しいリリースが指定した日付に適用されます。
      • メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。現在時刻がスケジュール済メンテナンス開始時刻の2時間以内である場合、メンテナンスは再スケジュールできません。
      • Oracleでは、四半期ごとに特定の日付を内部メンテナンス操作のために予約しており、これらの日付にメンテナンスをスケジュールすることはできません。
    • タイプ:計画済対未計画。インフラストラクチャ・メンテナンス・スケジュール・プランから作成またはこのメンテナンス実行に追加されたすべてのウィンドウは、「計画済」ウィンドウです。Oracle Automationにより、障害、期間強制または予期しないイベントに対処するために作成される他のすべてのウィンドウは、「計画外」ウィンドウとして定義されます。「未計画」ウィンドウで実行するようにスケジュールされているアクティビティを常にレビューします。
    • メンテナンス・アクション:特定のウィンドウで更新がスケジュールされているアクションのサマリー。

      サーバー名は、DBサーバーにスケジュールされている更新を識別します。たとえば、DBサーバーdbServer-1およびdbServer-2に完全更新を適用します。ストレージ・サーバーの更新は、すべてのストレージ・サーバーのストレージ・レイアウトが同じであるため、カウントとして識別されます。たとえば、2つのストレージ・サーバーに完全更新を適用します。

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

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

ノート

ウィンドウは「スケジュール済」ライフ・サイクル状態のまま、ウィンドウ・スケジュールの開始時間、期間および期間の強制など、ウィンドウ構成を更新できます。ウィンドウが進行中の場合、構成を変更することはできません。ウィンドウの実行中のメンテナンスを取り消すことを選択できます。「メンテナンス実行に関連付けられたメンテナンス・ウィンドウの取消」セクションで説明する詳細。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「リソース」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

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

保守実行に関連付けられた保守処理の表示

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

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

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

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

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

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

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

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

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

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

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

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

  6. Click the Actions menu (three dots) of the Maintenance window you want to edit, and then select Edit maintenance actions.The resulting Edit maintenance action page displays the list of actions.アクションを追加するか、既存のアクションを削除できます。
  7. アクションを追加するには:
    1. 「アクションの追加」をクリックします。
    2. 結果の「メンテナンス・アクションの追加」ウィンドウで、次の手順を実行します。
      • 新規アクションの作成: 新しいメンテナンス・アクションを作成するときに、別のメンテナンス・ウィンドウで更新するようにすでにスケジュールされているコンポーネントを新しいウィンドウに追加することを選択できます。
        • アクション・タイプの選択:
          • DBサーバーのExadata完全ソフトウェア更新
            • メンテナンス方法の構成:
              • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
              • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
              • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効にする: Oracleのプレビューの外部で追加のアクションを実行する場合にのみ、カスタム・アクションを有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
                • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
                  ノート

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

                  デフォルト: 15分

                  最大: 120分

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

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

                ノート

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

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

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

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

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

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

    ノート

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

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

  6. 結果の「メンテナンス実行」詳細ページで、「メンテナンス・アクション」をクリックします。

    メンテナンスのカスタム・アクションの待機中は、情報ブロックが表示されます。情報ブロックは、メンテナンスが再開されると削除されます。

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

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

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

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

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

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

ノート

ウィンドウに対するスケジュール済更新の進行中は、実行中のメンテナンスを取り消すことができます。更新の進行中にメンテナンスを取り消すと、まだ開始していないすべてのアクションを、選択した将来のメンテナンス・ウィンドウに再スケジュールできます。新しい開始時間と期間を選択して、取り消すことにしたメンテナンス・ウィンドウから再スケジュールされたすべてのアクションを終了できます。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「リソース」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート

メンテナンス・アクティビティには、選択したExadataクラウド・サービスの特定のコンパートメント内のすべてのインフラストラクチャ・リソースに対して実行するようにスケジュールされているすべてのメンテナンス更新がリストされます。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「リソース」で、「スケジューリング・ポリシー」をクリックします。

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

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

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

メンテナンス・アクティビティの詳細の表示

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

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

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

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

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

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

未計画保守活動のレビューおよび応答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには

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

Exadataインフラストラクチャ管理者がシステム更新通知に忙殺されないように、メンテナンス通知が送信されるユーザーの電子メール・アドレスを最大10個まで指定できます。

  1. ナビゲーション・メニューを開きます。「Oracle Database」、「Oracle Exadata Database Service on Dedicated Infrastructure」の順にクリックします。
  2. 「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックして、デフォルト・コンパートメント内のExadataインフラストラクチャのリストを表示します。「リスト範囲」セクションにある「コンパートメント」ドロップダウンから別のコンパートメントを選択できます。
  3. Exadataインフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
  4. 「メンテナンス」セクションで、「顧客の連絡先」フィールドの「管理」をクリックして「連絡先の管理」ダイアログを表示します。
  5. 「連絡先の追加」ボタンをクリックすると、有効な電子メール・アドレスを入力するフィールドが表示されます。Exadataインフラストラクチャごとに最大10個のメンテナンス連絡先を設定できます。
  6. 電子メール・アドレスを編集するには、「連絡先の管理」ダイアログで、編集する電子メール・アドレスの前にあるボックスを選択し、「編集」ボタンをクリックします。
  7. リストから電子メール・アドレスを削除するには、「連絡先の管理」ダイアログで、削除する電子メール・アドレスの前にあるボックスを選択し、「削除」ボタンをクリックします。

APIを使用したExadata Cloud Infrastructureのメンテナンス制御の管理

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

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

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

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