Exadata Cloud Infrastructureデプロイメントの開始
Exadata Cloud Infrastructureの準備の準備タスクを完了したら、次の手順に従ってExadata Cloud Infrastructureシステムのデプロイを開始します。
- Oracle Exadata Database Service on Dedicated Infrastructureリソースのタグ付け
タグ付けはOracle Cloud Infrastructure (OCI)向けの強力な基盤サービスであり、タグに基づいて一連のリソースに対する検索、アクセス制御および一括アクションを実行できます。 - X8MおよびX9MスケーラブルExadataインフラストラクチャの概要
Oracle Cloud InfrastructureのスケーラブルなX8MおよびX9M Exadataクラウド・インフラストラクチャ・モデルを使用すると、プロビジョニング後にデータベースおよびストレージ・サーバーを追加し、容量のニーズに合ったシステムを作成できます。 - Exadata Cloud Infrastructureインスタンスの作成
このトピックでは、Oracle Exadata Cloud Infrastructureインスタンスの作成方法について説明します。また、Oracle Cloud Infrastructure Object Storageサービスへの必要なアクセスの構成方法とDNSの設定方法についても説明します。 - クラウド・インフラストラクチャのメンテナンス更新
Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。 - Exadata Cloud Infrastructureインスタンスへの接続
このトピックでは、SSHまたはSQL Developerを使用してExadata Cloud Infrastructureに接続する方法について説明します。 - Exadata Cloud Infrastructureインスタンスのベスト・プラクティス
Exadata Cloud Infrastructureインスタンスの管理性を確保するために、次のベスト・プラクティス・ガイドラインを使用することをお薦めします: - ゼロ・ダウンタイム移行を使用したOracle Cloudへの移行
Oracle Exadata Database Service on Dedicated Infrastructureリソースのタグ付け
タグ付けはOracle Cloud Infrastructure (OCI)向けの強力な基盤サービスであり、タグに基づいて一連のリソースに対する検索、アクセス制御および一括アクションを実行できます。
タグ付けの重要性
Oracle Cloud Infrastructure (OCI)タグ付けシステムを使用すると、組織のスキームに従ってリソースにタグ付けできるため、リソースのグループ化、コストの管理および使用状況に関するインサイトの取得が可能になります。また、タグは、セキュリティおよび最大可用性アーキテクチャ(MAA)に関するガバナンス・モデルを構築するのに役立ちます。組織がクラウド環境を拡大するにつれて、デプロイメント・アーキテクチャ、セキュリティのベスト・プラクティス、MAA、アプリケーション層などをトラッキングすることが困難になる場合があります。メタデータ・タグを使用してワークロード属性を識別すると、コスト超過なしでテナンシのセキュリティと可用性を最新状態に維持できます。
お客様がOCIリソースを安全かつコスト効率よく管理できるように、リソースのタグ付けのベスト・プラクティスに沿った一連の事前定義済タグが用意されています。これらのタグは、oracleStandard
ネームスペースとOracleApplicationName
ネームスペースの2つのネームスペースにグループ化されます。タグ・ネームスペースは、タグ・キーのコンテナと見なすことができます。
組織に、テナンシ内の複数のコンパートメントにわたるExadataインフラストラクチャ、VMクラスタ、DBホーム、Oracle DatabaseおよびVMクラスタNetworksなどの複数のクラウド・リソースがあるシナリオを考えてみます。これらのクラウド・リソースを特定の目的で追跡したり、レポートしたり、一括アクションを実行するとします。その場合、環境、クリティカル度、ターゲット・ユーザー、アプリケーションなどの様々な基準に基づいてこれらのリソースをグループ化できるシステムが必要です。これを実現するには、これらのリソースに適切なタグを適用します。
たとえば、開発スタック内のすべてのリソースにOracle-Standard.Environment=Dev
でタグ付けしたり、ビジネスクリティカルなアプリケーション・スタックにOracle-Standard.Criticality=High
またはExtreme
を設定できます。様々な理由でサービスが中断した場合、アプリケーションまたはビジネス機能に関連付けられているすべてのOCIリソースを迅速に識別したり、クリティカルなワークロードとクリティカルでないワークロードを分離することができます。
タグ付けは、タグで識別されたワークロード属性に基づいて最適化された構成をデプロイする場合にも役立ちます。たとえば、PeopleSoftアプリケーションのデータベース・デプロイメントには特定の構成が必要です。Oracle Databaseのデプロイ時にApplicationName
およびAppMajorVersion
タグを設定すると、データベースを構成して、PeopleSoftなどの特定のアプリケーションで即時利用できるように準備できます。
さらに、クラウド・アドバイザOCIサービスと統合することで、クラウド・サービスが企業のガイドラインにどの程度準拠しているかを直接かつ深く知ることができ、経営陣がビジョンを持ってガバナンスを行うことができるようになります。詳細は、クラウド・アドバイザの概要を参照してください。
タグの追加
リソースには、Oracle Cloud Infrastructure (OCI)コンソール、コマンドライン・インタフェースまたはSDKを使用してタグ付けできます。
Oracle Exadata Database Service on Dedicated Infrastructureデプロイメントでタグ付けできるクラウド・リソースは多数あります。Exadataインフラストラクチャ、VMクラスタ、DBホーム、Oracle Database、Autonomous Exadata VMクラスタ、Autonomous Container Database、Autonomous DatabaseおよびVMクラスタ・ネットワークはその一部です。タグは、リソースの作成時に適用するか、後で変更できます。たとえば、ACDのプロビジョニング中にAutonomous Container Database (ACD)にタグを適用したり、「詳細」ページから後で追加できます。
タグの使用の詳細は、タグ付けの仕組みを参照してください。タグ付けはOracle Cloud Infrastructure認可システムと統合されています。IAMポリシー・コントロールを使用して、タグ操作の委任または制限を有効にできます。定義済タグおよびフリーフォーム・タグの操作に必要な権限について学習するには、認証と認可を参照してください。(必須)概念の定義と目的を含む紹介テキストをここに入力します。
ヒント:
Oracle Autonomous Databaseでのタグの実装を示すチュートリアルを試してみる場合は、Oracle LiveLabsのフリート管理者専用Oracle Autonomous Databaseワークショップのラボ14: Oracle標準タグを参照してください。テナンシには、ほとんどのリソースに適用される標準タグのライブラリが付属しています。これらのタグは現在、ガバナンス管理者がデプロイできるタグ・ネームスペースのセットとして使用可能です。OCIのベスト・プラクティスでは、標準タグを適用できるすべてのリソースにこれらのタグを適用することをお薦めします。OCIサービス自動化では、レポートとガバナンスの他に、標準のタグ値に基づいてワークロード固有の最適化を提供できます。
たとえば、PeopleSoftアプリケーションのデータベース・デプロイメントには特定の構成が必要です。Autonomous Databaseのデプロイ時にOracle-ApplicationName
タグ・ネームスペースで適切なアプリケーション・タグ・キーを設定すると、データベースを構成して、PeopleSoftなどの特定のアプリケーションで即時利用できるように準備できます。
図4-1 タグ付けの例
Oracle標準タグ
テナンシ・ガバナンス管理者は、テナンシ・レベルで標準タグをデプロイでき、特定のタグを必須とマークすることで、そのコンパートメントのリソースにタグを強制的に付けることができます。次に、OracleStandard
というネームスペースに定義されている標準タグを示します。標準タグのインポートの詳細は、タグ・ネームスペースの管理の項の標準タグをインポートするにはを参照してください。
表4-1 Oracle標準タグ
タグ・キー | タグ値のオプション | 説明 |
---|---|---|
|
|
企業のアプリケーション分類基準に沿ったリソースの階層化を可能にします。カスタマ・ガバナンスでは、このタグをレポートに使用し、リソースが属する層のガイドラインに従ってリソースが構成されるようにできます。 たとえば、 |
|
|
リソース・ライフサイクルを示します。データベースの場合、統合密度の決定、コンテナ間のデータベース分散、メンテナンス・プランの設定、クローンの管理に役立ちます。 |
|
|
アプリケーションまたはデータベース分類タグ。 |
|
値については、コンプライアンス規則のリストを参照してください。 |
リソースが準拠する必要がある1つ以上のコンプライアンス規則を示します。 タグ管理者は、OCIの「ガバナンスと管理」コンソールからリストに値を追加できます。詳細は、事前定義済の値の使用を参照してください。 |
|
|
リソースのエンド・ユーザーを示します。ターゲット・ユーザーを決定し、ガバナンス・チームがユーザー・タイプまたはアプリケーション・タイプに基づいて企業標準を設定できるようにする、別の形式のリソース分類。 |
|
|
エンド・ユーザーの概数。このタグは、可用性またはセキュリティ・イベント中に影響を受けるユーザー数または影響を受けるユーザーの範囲を特定するのに役立ちます。また、これは、多数のクラウド・リソースに影響する重大な停止が発生した場合にリカバリ作業に優先順位を付けるのにも役立ちます。 |
|
フリーフォーム・タグ。例: john.smith@acme.comまたはapp_support_grp@acme.com |
リソース所有者の電子メール・アドレスを示します。 |
|
|
リソースを所有または使用する顧客の事業部門または部門を識別します。これは、コスト集計レポートと、ビジネス単位間の使用状況の決定に役立ちます。タグ管理者は、OCIの「ガバナンスと管理」コンソールからリストに関連する値を追加できます。詳細は、事前定義済の値の使用を参照してください。 |
|
|
コスト・センターの自由形式フィールド。 |
|
0-10080 |
時間(分)。リソースが障害からのリカバリに必要な最大時間を示します。 |
|
0-1440 |
時間(分)。データベースやストレージ・デバイスなどのデータ・ストア・リソースの最大データ損失許容範囲。 |
コンプライアンス規則のリスト
表4-2 コンプライアンス規則のリスト
規則 | 説明 |
---|---|
PCI DSS |
クレジット・カード業界データ・セキュリティ基準 |
HIPAA |
医療保険の相互運用性と説明責任に関する法律 |
ISO |
国際標準化機構 |
SOC1 |
システムおよび組織管理1 |
SOC 2 |
システムおよび組織管理2 |
FedRamp |
米国連邦リスク承認管理プログラム |
GLBA |
グラム・リーチ・ブライリー法 |
CCPA |
カリフォルニア州消費者プライバシ法 |
SOX |
サーベンス・オクスリー法 |
NIST |
米国国立標準技術研究所 - サイバー・セキュリティ |
FISMA |
連邦情報セキュリティ管理 |
HITECH |
経済的および臨床的健全性のための医療情報技術に関する法律 |
FERPA |
家族教育権利およびプライバシ法(学生プライバシ法) |
FACTA |
公正かつ正確な信用取引のための法律 |
Texas HB300 |
テキサス医療記録プライバシ法 |
CIS |
国際インターネット・セキュリティ組織 |
CJIS |
刑事司法情報サービス・セキュリティ・ポリシー |
C-TPAT |
テロリズムに対する関税-貿易パートナシップ |
COPPA |
児童オンライン・プライバシ保護法 |
PIPED ActまたはPIPEDA |
個人情報保護および電子文書法 |
GDPR |
一般データ保護規則 |
PIPL |
個人情報保護法 |
Oracleアプリケーション名タグ
表4-3 Oracleアプリケーション名タグ
タグ・キー | タグ値のオプション | 説明 |
---|---|---|
Hyperion |
|
Hyperionアプリケーションのバージョンを示します。 |
JD Edwards |
|
JD Edwardsアプリケーションのバージョンを示します。 |
Oracle_E-Business_Suite |
|
Oracle E-Business Suiteアプリケーションのバージョンを示します。 |
PeopleSoft |
|
PeopleSoftアプリケーションのバージョンを示します。 |
Siebel |
|
Siebelアプリケーションのバージョンを示します。 |
Other_Oracle_Application |
文字列形式の自由形式タグ。 |
前述以外のアプリケーションを示すために使用できます。アプリケーション名を文字列値として入力できます。 |
クラウド・インフラストラクチャのメンテナンス更新
Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。
インフラストラクチャ・メンテナンスに関して通知される連絡先を管理したり、メンテナンス・ウィンドウを設定して四半期ごとのインフラストラクチャ・メンテナンスを開始する時間を決定したり、Oracle Cloud InfrastructureコンソールでExadata Cloud Infrastructureのスケジュール済メンテナンス実行およびメンテナンス履歴を表示したりできます。インフラストラクチャ・メンテナンス・プロセスおよびメンテナンス制御の構成の詳細は、次を参照してください:
- Oracle管理のExadata Cloud Infrastructureメンテナンスについて
Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。 - 四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。 - 月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコア間の脆弱性の修正を含みます。 - 同月の月次メンテナンスと四半期メンテナンスについて
- コンソールを使用したOracle管理インフラストラクチャ更新の構成
ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。 - ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態を使用すると、インフラストラクチャ・リソースのメンテナンスが開始および終了するタイミングをモニターできます。 - インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。 - インフラストラクチャ・メンテナンス連絡先の管理
Exadataインフラストラクチャ・メンテナンス連絡先を管理する方法について学習します。
Oracle管理のExadata Cloud Infrastructureメンテナンスについて
Oracleは、Exadata Cloud Infrastructure上のOracle管理システム・コンポーネントすべてに対してパッチおよび更新を実行します。
Oracleのパッチおよび更新には、物理データベース・サーバー・ホスト、Exadata Storage Server、ネットワーク・ファブリック・スイッチ、管理スイッチ、電力配分装置(PDU)、統合電源管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。これは、インフラストラクチャ・メンテナンスと呼ばれます。
更新の頻度は、次のようにリージョン・タイプによって異なります:
- 商用リージョン: Oracleは、四半期ごとの完全なインフラストラクチャ更新と、月ごとのセキュリティ・インフラストラクチャ更新を実行します。
- 政府リージョン: Oracleは、毎月の完全なインフラストラクチャ・メンテナンス更新を実行します。
ごくまれな例外的状況を除き、計画を支援するために、これらの更新に関する事前通知が送信されます。VMクラスタ仮想マシン(VM)に、対応する推奨更新がある場合、Oracleからそれらに関する通知が提供されます。
可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を保持する方法で実行されます。ただし、更新プロセス中に個々のシステム・コンポーネントが使用できない間は、パフォーマンスやスループットに顕著な影響が生じることがあります。
たとえば、通常、データベース・サーバーのパッチ適用では再起動が必要です。このような場合、データベース・サーバーは、可能なかぎりローリング方式で1つずつ再起動され、プロセス全体でサービスの可用性が保持されるようにします。ただし、各データベース・サーバーは、再起動中に短時間使用不能になるため、全体的なサービス容量はそれに応じて減少します。アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。たとえば、データベース・サーバーのパッチ適用が発生したときにアプリケーションを停止します。
Oracle Cloud Infrastructure (OCI) US Government (OC2)および米国国防総省(OC3)リージョンでExadata Database on Dedicated Infrastructureを使用するお客様は、OCIコンソールを使用して、月次および四半期ごとのパッチ適用イベントを再スケジュールできます。
現時点では、Exadata Cloud Infrastructureのパッチ管理スケジュールの設定と呼ばれるメンテナンス・スケジュールの指定は、Exadataパッチ管理のOCI US Government (OC2)およびUS DOD (OC3)レルムではまだ使用できません。パッチ管理再スケジュール時のExadata Database on Dedicated Infrastructureの詳細は、こちらを参照してください。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要
デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。
非ローリング・メンテナンスを選択して、データベース・サーバーとストレージ・サーバーを更新することもできます。非ローリング・メンテナンス方法は、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。非ローリング・メンテナンスでは、メンテナンス時間が最小化されますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。
ローリング・インフラストラクチャ・メンテナンスは、Exadataデータベース・サーバー・ホストから開始されます。ローリング・メンテナンス方法では、データベース・サーバーは一度に1つずつ更新されます。データベース・サーバー・ホストの各VMが停止され、ホストが更新および再起動されてからVMが起動されますが、その間他のデータベース・サーバーは稼働したままです。このローリング・メンテナンスは、ローリング・インスタンスの停止を処理するために書き込まれていない古いアプリケーションに影響します。すべてのサーバーが更新されるまでこのプロセスが続行されます。
データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。ローリング・メンテナンス方法では、ストレージ・サーバーは一度に1つずつ更新され、VMクラスタのVMの可用性には影響しません。ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーがオフラインになり(使用可能なIO容量が減少)、オンラインに戻されると再同期される(データベース・サーバーでのオーバーヘッドが少ない)ため、IOパフォーマンスが低下する可能性があります。データベースおよびストレージ・インフラストラクチャのサイズを適切に設定して、データベースおよびストレージ・サーバーに分散される作業の増加に対応することで、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。
ローリング・メンテナンス・プロセス中はデータベースが使用可能であることが想定されますが、自動化メンテナンスでは、Oracle Clusterwareが実行中であることは検証しますが、サーバーがオンラインに戻された後にすべてのデータベース・サービスおよびプラガブル・データベース(PDB)が使用可能であることは検証しません。メンテナンス後のデータベース・サービスおよびPDBの可用性は、アプリケーション・サービス定義に依存する可能性があります。たとえば、特定の優先ノードおよび使用可能ノードで構成されたデータベース・サービスは、メンテナンス中に再配置されると、メンテナンスの完了後に元のノードに自動的に再配置されません。Exadata Cloudシステム上のアプリケーションの継続的可用性の実現に関するドキュメントを確認して、アプリケーションへの影響の可能性を減らすことをお薦めします。ドキュメントのガイドラインに従うことで、データベース・サーバーは順番に更新されるため、インフラストラクチャ・メンテナンスの影響は、わずかなサービス低下のみになります。
最大可用性アーキテクチャ(MAA)のベスト・プラクティスに従い、Data Guardを使用してクリティカルなアプリケーションの可用性を最大にすることをお薦めします。Data Guardが有効なデータベースの場合、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前に、スイッチオーバーを実行することもできます。これにより、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避できます。
事前チェックは、メンテナンス・ウィンドウの開始前にExadata Cloud Infrastructureコンポーネントで実行されます。事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。最初の事前チェックはメンテナンス開始の約5日前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックでメンテナンスの再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に通知が送信されます。
パッチ適用ウィンドウ中はデータベースまたはアプリケーションで主要なメンテナンス操作を実行しないでください。これらの操作はインフラストラクチャ・メンテナンス操作によって影響を受ける可能性があるためです
- Windowsの四半期メンテナンスの見積り時間
インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法、およびカスタム・アクションが有効になっているかどうかによって異なります。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
四半期メンテナンスWindowsの見積時間
インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法、およびカスタム・アクションが有効化されているかどうかによって異なります。
提示される概算時間は見積りです。カスタム・アクション(構成されている場合)の時間は見積りに含まれません。データベース・サーバーのメンテナンス時間は、更新前に各VMを停止してから、各ノードの更新後に次のノードに進む前に各VMおよび関連リソースを起動するために必要な時間によって異なる場合があります。ストレージ・サーバーのメンテナンス時間は、ASMリバランスに必要な時間によって異なります(この時間は次の見積りには含まれません)。メンテナンス中に問題が発生した場合、リストされている概算時間を超えて完了が遅延することもあります。このような状況では、Oracleクラウド操作によって、予想されるウィンドウを超えて解決が延長されると判断された場合、通知が送信され、メンテナンスが再スケジュールされることがあります。
Oracle Cloud Operationsで追加のメンテナンス作業が必要と判断された場合、次に示す時間枠が変更される可能性があります。追加の時間が必要な場合は、次の四半期メンテナンス・ウィンドウに追加の時間が必要であることを顧客に通知するために、Oracleから事前に顧客に通知が送信されます。
表4-4 Exadataインフラストラクチャ・メンテナンスのおおよその時間
Exadataシェイプ構成 | ローリング・パッチ適用方式(概算時間) | 非ローリング・パッチ適用方式(概算時間) |
---|---|---|
クォータ・ラック | 5-6時間 | 4-7時間 |
ハーフ・ラック | 10時間 | 4-7時間 |
フル・ラック | 20時間 | 4-7時間 |
フレキシブル・シェイプ(X8M以上) | コンピュート・ノード当たり1.5時間 + ストレージ・ノード当たり1時間 | 4-7時間 |
月次セキュリティ・メンテナンスの概要
四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコアの脆弱性の修正を含みます。
CVEリリース・マトリックスの詳細は、Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(ドキュメントID 888828.1)を参照してください。
Exadataインフラストラクチャ・バージョンに固有のCVEリリース・マトリックスを表示するには、Exadataバージョン(Exadata 23など)をクリックします。バージョン固有のCVEリリース・マトリックスは、表の「ノート」列にリストされます。
セキュリティ・メンテナンスは、必要に応じて、各月の18日から21日の間に開始し、翌月の9日から12日まで実行される21日のウィンドウ中に適用されるようにスケジュールされます。顧客には、月次メンテナンス・ウィンドウの開始日の7日前までにスケジュール案が通知され、必要に応じて、ウィンドウ内の別の日付に月次メンテナンスを再スケジュールできます。月次セキュリティ・メンテナンス・プロセスでは、データベース・サーバーを更新して、重要なセキュリティ脆弱性および重要な製品の問題を修正します。また、月次メンテナンスでは、既知のセキュリティの脆弱性および製品の問題を解決するExadata Storageソフトウェア・イメージにストレージ・サーバーを更新します。
データベース・サーバーの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新はホスト・サーバーにオンラインで適用され、VMおよびデータベースを含むVM内のすべてのプロセスは稼働したままです。サーバーおよびVMは再起動されません。ストレージ・サーバーに対する更新は、ローリング形式で適用されます。四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションにとって最小限である必要があります。
毎月のインフラストラクチャ・メンテナンス中は、VMの起動および停止操作のみがサポートされます。
同月の月次メンテナンスと四半期メンテナンスについて
四半期セキュリティ・メンテナンスと月次セキュリティ・メンテナンスの両方が同じ月に実行されるようにスケジュールされている場合、特別な考慮事項があります。四半期メンテナンスでは、セキュリティ・メンテナンスによってすでに適用されているセキュリティ修正が再適用され、既存のストレージ・サーバーのバージョンが更新に含まれるバージョンと同じかそれより新しい場合は、四半期メンテナンスも月次メンテナンスもストレージ・サーバーの更新を適用しません。
- 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前月から最新のExadataリリースが使用されます。その時点で追加のセキュリティ修正が使用可能な場合は、それらの更新が四半期メンテナンスに含まれます。そのイメージは四半期を通して使用されます。たとえば、1月リリースは、2月、3月および4月の四半期メンテナンスに使用されます。
- 四半期メンテナンスを適用すると、以前にデータベース・サーバーにインストールされたセキュリティ更新が、適用される四半期メンテナンス・リリースに含まれていない可能性があります。その場合、自動化では四半期メンテナンスによってインストールされた新しいリリースに同じセキュリティ修正が適用されるため、セキュリティ修正の回帰はありません。ストレージ・サーバー上の現在のイメージが、四半期または月次のセキュリティ・メンテナンスによって適用されるイメージと同じかそれより新しい場合、そのメンテナンスはストレージ・サーバーに対してスキップされます。
四半期メンテナンスが月次スケジュールの24時間以内にスケジュールされている場合、スケジュールされた月次メンテナンスはスキップされ、かわりに四半期メンテナンスの直後に月次更新が適用されます。
- 同じ時間にスケジュールされている場合、四半期メンテナンスの完了直後に月次更新が実行されます。
- 月次メンテナンスが四半期メンテナンスより0-24時間前に開始するようにスケジュールされている場合、月次メンテナンスはスケジュールどおりに実行されません。かわりに、待機して四半期メンテナンスの直後に実行されます。四半期メンテナンスが後で再スケジュールされた場合、月次セキュリティ・メンテナンスは即座に開始されます。したがって、四半期メンテナンスと月次メンテナンスを同じ時間にスケジュールすることをお薦めします。そうすると、四半期メンテナンスを直前に再スケジュールした場合、月次メンテナンスはスケジュールの編集直後ではなく、スケジュールされた時間に実行されます。また、四半期メンテナンスの再スケジュール時に、月次セキュリティ・メンテナンスを再スケジュールすることもできます(月次メンテナンスが現在のメンテナンス・ウィンドウ内にある場合にかぎります)。月次メンテナンスはメンテナンス・ウィンドウ内の別の時間に再スケジュールできますが、スキップすることはできません。
四半期メンテナンス前の月次セキュリティ・メンテナンス
- 四半期メンテナンスの前にセキュリティ・メンテナンスを適用するには、四半期メンテナンスの24時間以上前に月次セキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、アプリケーションに影響を与えずにデータベース・サーバーにセキュリティ・パッチをオンラインに適用し、アプリケーションへの影響を最小限に抑えてストレージ・サーバーに更新を適用します(パフォーマンスがわずかに低下する可能性があります)。四半期メンテナンスはスケジュールどおりに実行され、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期メンテナンスの一環として、システムにすでにインストールされているデータベース・サーバーに同じセキュリティ更新が適用されます(セキュリティ回帰はありません)。
- 最新のセキュリティ更新が適用される場合、新しい月次メンテナンス・ウィンドウが開いた後に(通常は月の21日に)月次セキュリティ・メンテナンスを実行するようにスケジュールします。
- ストレージ・サーバーの毎月のセキュリティ・メンテナンスの再起動による影響は最小限に抑える必要があるため、今月のアプリケーションへの影響は、四半期メンテナンス中のデータベース・サーバーの再起動によるものです。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。
月次セキュリティ・メンテナンス前の四半期メンテナンス
- 月次セキュリティ・メンテナンスの前に四半期メンテナンスを実行するには、四半期メンテナンスの開始がスケジュールされる24時間以内に実行されるようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。四半期メンテナンスでは、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれないアプリケーションに影響します。四半期ごとのメンテナンスでは、ストレージ・サーバーのパッチ適用がスキップされる場合とスキップされない場合があります。これは、現在インストールされているリリースより新しいものか古いものかによって異なります。ほとんどの場合、インストールされるバージョンは、四半期メンテナンスに関連付けられているバージョンより新しいバージョンである必要があります。このルールの例外は、メンテナンス四半期の最初の月である場合、または1つ以上の前の月のセキュリティ・メンテナンスをスキップした場合に発生する可能性があります。セキュリティ・メンテナンスは、四半期メンテナンスの完了直後に、またはスケジュールされたいずれか遅い方で実行されます。データベース・サーバーへのオンライン更新(アプリケーションへの影響なし)が適用され、ローリング方式でストレージ・サーバーが更新される可能性があります。場合によっては、四半期メンテナンスにセキュリティ・メンテナンスと同じストレージ・サーバー・リリースが含まれている可能性があり、セキュリティ・メンテナンス・ストレージ・サーバーの更新はスキップされます。
- セキュリティ・メンテナンスの前に四半期メンテナンスを実行するエンド・ユーザーへの影響は、セキュリティ・メンテナンスを最初に実行する場合とほぼ同じである必要があります。四半期ごとのメンテナンスは中断を伴うイベントですが、ストレージ・サーバーを再起動するセキュリティ・メンテナンスによって中断が最小限に抑えられ、セキュリティ・メンテナンスがオンラインのデータベース・サーバーに適用されます。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。これらの2つのメンテナンス・ウィンドウを、エンド・ユーザーに単一のメンテナンス・ウィンドウとして表示されるように連続して実行するようにスケジュールできます。これを行うには、四半期メンテナンスと同時に(または24時間前まで)開始するようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。毎月のセキュリティ・メンテナンスを定期的に適用している場合、ストレージ・サーバーは四半期メンテナンスによってスキップされ、四半期メンテナンスの完了直後にセキュリティ・メンテナンスによって更新されます。
メンテナンスWindowsの最小化
- メンテナンス・ウィンドウの数を最小限に抑えるには(エンド・ユーザーとのネゴシエーションが必要)、四半期メンテナンスと月次メンテナンスを同時にスケジュールします。セキュリティ・メンテナンスはブロックされます。四半期メンテナンスでは、ローリング方式でデータベース・サーバーが更新され、おそらくストレージ・サーバーはスキップされます。セキュリティ・メンテナンスはただちにフォローアップされ、データベース・サーバーをオンラインおよびストレージ・サーバーにローリング方式で更新します。その結果、単一のメンテナンス・ウィンドウでデータベースとストレージ・サーバーが再起動されます。
- 二つの例外がある(1)四半期メンテナンスと月次メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスによってストレージ・サーバー更新が適用され、セキュリティ・メンテナンスはスキップされます。1つのメンテナンス・ウィンドウでも、これは1回のローリング再起動です。2.ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれるリリースより古く、セキュリティ・メンテナンスのリリースより古くなっています。これにより、四半期メンテナンスでストレージが更新され、その後セキュリティ・メンテナンスでストレージも更新されます。これは、前の月のセキュリティ・メンテナンスをスキップした場合にのみ発生する可能性があります。これは、現在のイメージが2か月以上古くなっている必要があるためです。このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。これにより、1つのストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウ(セキュリティ・メンテナンスでは1つ目、その後は四半期メンテナンス)になります。
- エンド・ユーザーへの影響を最小限に抑えるには、常に月次セキュリティ更新を適用し、両方がスケジュールされている月単位で同時にスケジュールします。
Oracleがセキュリティ・メンテナンスをスケジュールする前にExadataインフラストラクチャがプロビジョニングされた場合、セキュリティ・メンテナンスの対象となります。
スケジュールされた月次Exadataインフラストラクチャ・メンテナンスの前にいつでも再スケジュールできます。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
コンソールを使用したOracle管理インフラストラクチャ更新の構成
ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。
Exadata Cloud Infrastructureソフトウェアの完全な更新は、商用リージョンの場合は四半期ベースで、政府リージョンの場合は月次でスケジュールされます。さらに、重要なセキュリティ更新は毎月スケジュールされます。これらのインフラストラクチャの更新をオプト・アウトすることはできませんが、クラウド通知ポータルを介して更新が事前にアラートされ、スケジュールを柔軟に設定して計画を立てることができます。
四半期ごとのインフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。また、Oracle Cloud Infrastructureコンソールの「Exadataインフラストラクチャの詳細」ページで、メンテナンス方法の編集、カスタム・アクションの有効化、スケジュール済メンテナンス実行とメンテナンス履歴の表示、メンテナンス連絡先の管理を行うことができます。
- Exadata Cloud Infrastructureの四半期ごとのインフラストラクチャ・メンテナンスのプリファレンスの表示または編集
Oracle Exadata Database Service on Dedicated Infrastructureのインフラストラクチャ・メンテナンスのプリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。 - Exadata Cloud Infrastructureの自動月次メンテナンス・スケジュールを設定するには
- Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
Exadata Cloud Infrastructureのスケジュールされた四半期メンテナンスのプロパティを確認および変更します。 - Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには
このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースのメンテナンス履歴を表示する方法について説明します。 - メンテナンスの進行中またはカスタム・アクションの待機中の四半期メンテナンスの表示および編集
メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開するか、タイムアウトを延長できます。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
Exadata Cloud Infrastructureの四半期ごとのインフラストラクチャ・メンテナンスのプリファレンスの表示または編集
Oracle Exadata Database Service on Dedicated Infrastructureのインフラストラクチャ・メンテナンスのプリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。
- ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
ノート
メンテナンス・プリファレンスの指定は、政府リージョンでは使用できません。 - 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
- 「Exadataインフラストラクチャ」をクリックします。
- 編集するExadataインフラストラクチャの名前をクリックします。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- 「メンテナンスのプリファレンスの編集」をクリックします。
「メンテナンスのプリファレンスの編集」ページが表示されます。
ノート
メンテナンス・プリファレンスに加えられた変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。スケジュール済メンテナンスを変更するには、Exadata Cloud Infrastructureのスケジュール済メンテナンスの表示または編集を参照してください。 - 「メンテナンスのプリファレンスの編集」ページで、次を構成します:
- メンテナンス方法の選択:
- ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
- 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
- DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
-
カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
デフォルト: 30分
最大: 120分
-
- メンテナンス・スケジュール:
- プリファレンスなし: システムによってインフラストラクチャ・メンテナンスの日付と開始時刻が割り当てられます。
- スケジュールの指定: インフラストラクチャ・メンテナンスに対して希望する月、週、平日、開始時刻およびリード・タイムを選択します。
ノート
メンテナンス・スケジュールの指定は、政府リージョンでは使用できません。- 「メンテナンス月」で、Exadataインフラストラクチャのメンテナンスを実行する月を四半期ごとに少なくとも1つ指定します。四半期ごとに複数の月を選択できます。事前通知に長いリード・タイム(たとえば、4週間)を指定する場合は、メンテナンス実行を行うことができる月を四半期ごとに2つまたは3つ指定することをお薦めします。これにより、必要なリード・タイムを考慮したうえで、メンテナンス更新が適時に適用されるようになります。リード・タイムについては、後のステップで説明します。
- オプション。「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。月の週を指定しない場合は、Oracleによって、中断が最小限になる週にメンテナンス更新が実行されます。
- オプション。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
- オプション。「開始時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
- 「リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
- メンテナンス方法の選択:
- 「変更の保存」をクリックします。
ローリングから非ローリング・メンテナンス方法に切り替えると、「非ローリング・メンテナンス方法の確認」ダイアログが表示されます。
- 表示されたフィールドにインフラストラクチャの名前を入力して、変更を確認します。
- 「変更の保存」をクリックします。
Exadata Cloud Infrastructureの自動月次メンテナンス・スケジュールを設定するには
このタスクでは、クラウドExadataインフラストラクチャ・リソースのメンテナンス・スケジュールを設定する方法について説明します。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
-
アクセスするクラウドExadataインフラストラクチャに移動します:
「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
リソース詳細ページの「メンテナンス」で、「次のセキュリティ・メンテナンス」フィールドの「表示」リンクをクリックします。次のセキュリティ・メンテナンスには、月次メンテナンスがスケジュールされている場合にのみスケジュール時間が表示されます。顧客は月次メンテナンスの7日前までに事前通知され、3週間のウィンドウ内でスケジュールを変更することができます。 - 「クラウドExadataインフラストラクチャ」ペインに、「スケジュールされた開始時間」が表示されます
- 「スケジュールされた開始時間」フィールドで、「編集」をクリックします。
- 「メンテナンス開始時間の編集」ダイアログで、「スケジュールされた開始時間」フィールドに新しい日時を入力します。メンテナンスの実行は、次の範囲内で開始するように再スケジュールできます: 3週間、15日から翌月の6日、ブロックされた日付/週末、その他の検証によりUI/APIがブロックされます。
- 変更を保存します。
Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
Exadata Cloud Infrastructureのスケジュールされた四半期メンテナンスのプロパティを確認および変更します。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
- アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
クラウドExadataインフラストラクチャ(新しいリソース・モデル): 「Oracle CloudのExadata」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
DBシステム: 「ベア・メタル、VMおよびExadata」で、「DBシステム」をクリックします。DBシステムのリストで、アクセスするExadata DBシステムを検索し、名前をクリックしてその詳細を表示します。
「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。
- リソースの詳細ページの「メンテナンス」で、「次の四半期メンテナンス」フィールドの「表示」リンクをクリックします。
「Exadata Infrastructureメンテナンス」ページが表示されます。
- 「Exadata Infrastructureメンテナンス」ページに、スケジュール済メンテナンスの詳細がリストされます。
ターゲットDBサーバーのバージョンおよびターゲット・ストレージ・サーバーのバージョン: これらのフィールドには、スケジュールされたメンテナンスによって適用されるExadataソフトウェアのバージョンが表示されます。適用されるバージョンは、クラウド内のExadataインフラストラクチャに対する最新の認定済更新です。メンテナンスがスケジュールされているときに次回の四半期更新がまだ認定されていない場合、新しい四半期更新が使用可能になるまで、バージョンは「最新」と表示されることがあります。更新が使用可能になると、新しいバージョンが表示されます。
データベース・サーバーのExadataソフトウェア・バージョンまたはストレージ・サーバーのExadataソフトウェア・バージョンに関する情報を検索するには、My Oracle SupportノートのExadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)を参照してください。
スケジュール済Exadataインフラストラクチャ・リソース・メンテナンス・イベントごとに、次の詳細が「メンテナンス」ページにリストされます:
- イベントのステータス
- イベントのOCID
- イベントのスケジュール済開始日時
- メンテナンス・イベントをただちに開始するには、「今すぐパッチ」をクリックします。プロンプトが表示されたら、「メンテナンスの実行」をクリックして、イベントを今すぐ開始することを確認します。
リソースのメンテナンス・イベントが開始されるときに、Exadataインフラストラクチャ・リソースによってホストされる1つ以上のVMクラスタでメンテナンス・イベントがすでに進行中の場合、Exadataインフラストラクチャ・リソースのメンテナンス・イベントはキューに入れられ、すべてのVMクラスタ・メンテナンス・イベントが完了した後、ただちに開始されます。
- 次回のスケジュール済メンテナンス設定を変更するには、「メンテナンス実行の編集」をクリックします。
- 「メンテナンスの編集」ページで、次を実行します:
- メンテナンス方法として、「ローリング」または「非ローリング」を選択します。
ノート
「非ローリング」オプションを選択すると、コンポーネントが同時に更新され、完全なシステム・ダウンタイムが発生します。 - DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できる最大タイムアウト。
デフォルト: 30分
最小: 15分
最大: 120分
- カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できる最大タイムアウト。
- 次回のメンテナンス実行を再スケジュールするには、「スケジュール開始時間」フィールドに日時を入力します。
次の制限事項が適用されます。
- インフラストラクチャ・メンテナンスは、前のインフラストラクチャ・メンテナンスから180日以内の日付に再スケジュールできます。再スケジュールされたメンテナンス実行より前に新しいメンテナンス・リリースが公開された場合、その新しいリリースが指定した日付に適用されます。メンテナンスは、現在スケジュールされているよりも早く実行するように再スケジュールできます。現在時刻がスケジュール済メンテナンス開始時刻の2時間以内である場合、メンテナンスは再スケジュールできません。
- Oracleでは、四半期ごとに特定の日付を内部メンテナンス操作のために予約しており、これらの日付にメンテナンスをスケジュールすることはできません。
- 「変更の保存」をクリックします。
- メンテナンス方法として、「ローリング」または「非ローリング」を選択します。
- 様々なコンポーネントの推定メンテナンス時間の詳細を表示するには、「推定メンテナンス時間合計」フィールドの「表示」リンクをクリックします。
「表示」リンクは、メンテナンス方法が「ローリング」の場合にのみ、「推定メンテナンス時間合計」フィールドに表示されます。
「推定メンテナンス時間詳細」ページに、次の詳細が表示されます:- 推定メンテナンス時間合計
- データベース・サーバー推定メンテナンス時間
- ストレージ・サーバー推定メンテナンス時間
- コンポーネントが更新される順序。ローリング・メンテナンスでは、コンポーネントは表示されている順序で更新されます
- データベース・サーバーのメンテナンスの一環として再起動されるVMの数を表示するには、「詳細の表示」リンクをクリックします。
「VMの場所」ダイアログが表示されます。
- 「VMクラスタ名」フィールドで、特定のVMが属するVMクラスタを確認できます。
- 「閉じる」をクリックします。
- 「閉じる」をクリックして、「推定メンテナンス時間詳細」ページを閉じます。
Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには
このタスクでは、クラウドExadataインフラストラクチャまたはDBシステム・リソースに対するメンテナンス履歴を表示する方法について説明します。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
-
アクセスするクラウドExadataインフラストラクチャまたはDBシステムに移動します:
「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。インフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
- リソースの詳細ページの「ベア・メタル、VMおよびExadata」で、「メンテナンス履歴」をクリックします。
- メンテナンス・ジョブ、パッチ適用の状態およびタイプが表示されます。
ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター
Exadataインフラストラクチャ・リソースのライフサイクル状態により、インフラストラクチャ・リソースのメンテナンスがいつ開始および終了するかをモニターできます。
Oracle Cloud Infrastructureコンソールで、「Exadataインフラストラクチャの詳細」ページにライフサイクル状態の詳細メッセージが表示されます(「ステータス」フィールドの横にツールチップが表示されます)。これらのメッセージには、ListCloudExadataInfrastructures
API、およびSDKやOCI CLIなどのAPIに基づくツールを使用してアクセスすることもできます。
-
メンテナンス・ウィンドウを指定した場合、指定した開始時間にパッチ適用が開始されます。インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変わります。ノート
メンテナンスの開始前に事前チェックが実行されます。 - Exadataデータベース・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャは更新中です」です。
- ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基礎となるインフラストラクチャは更新中であり、これはデータベースの可用性には影響しません」です。
- ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチがローリング方式で1つずつ更新されます。
- メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールにライフサイクル状態メッセージは表示されません。
インフラストラクチャ・メンテナンス更新に関する通知の受信
通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。
Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。スケジュール・リマインダ、パッチ適用の開始、パッチ適用の終了など、スケジュール済メンテナンス実行のためのOracleの準備として、適切なメンテナンス関連イベントが生成されます。すべてのメンテナンス関連イベントの詳細は、Oracle Cloud Exadataインフラストラクチャ・イベントを参照してください。障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成して、インフラストラクチャ・メンテナンス連絡先に通知します。
Oracle Cloud Infrastructure Eventsの詳細は、イベントの概要を参照してください。インフラストラクチャ・メンテナンス連絡先に送信された通知以外の追加の通知を受信するには、インフラストラクチャ・メンテナンス・イベントにサブスクライブし、Oracle Notification Serviceを使用して通知を受信します。通知の概要を参照してください。
インフラストラクチャ・メンテナンス連絡先の管理
Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。
- Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
親トピック: クラウド・インフラストラクチャのメンテナンス更新
Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには
コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。
Exadataインフラストラクチャ管理者がシステム更新通知に忙殺されないように、メンテナンス通知が送信されるユーザーの電子メール・アドレスを最大10個まで指定できます。
- ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
- 「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックして、デフォルト・コンパートメント内のExadataインフラストラクチャのリストを表示します。「リスト範囲」セクションにある「コンパートメント」ドロップダウンから別のコンパートメントを選択できます。
- Exadataインフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
- 「メンテナンス」セクションで、「顧客の連絡先」フィールドの「管理」をクリックして「連絡先の管理」ダイアログを表示します。
- 「連絡先の追加」ボタンをクリックすると、有効な電子メール・アドレスを入力するフィールドが表示されます。Exadataインフラストラクチャごとに最大10個のメンテナンス連絡先を設定できます。
- 電子メール・アドレスを編集するには、「連絡先の管理」ダイアログで、編集する電子メール・アドレスの前にあるボックスを選択し、「編集」ボタンをクリックします。
- リストから電子メール・アドレスを削除するには、「連絡先の管理」ダイアログで、削除する電子メール・アドレスの前にあるボックスを選択し、「削除」ボタンをクリックします。
親トピック: インフラストラクチャ・メンテナンス連絡先の管理