28 Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture
Oracle Exadata Cloud Infrastructure (ExaDB-D)とOracle Exadata Cloud@Customer (ExaDB-C@C)のOracle Maximum Availability Architectureでは、クラウドの自動化とライフサイクル操作の両方と統合された固有の高可用性、データ保護および障害時リカバリ保護が提供され、Oracle Exadata Cloudシステムをエンタープライズ・データベースおよびアプリケーションに最適なクラウド・ソリューションにすることができます。
Oracle CloudのMAAアーキテクチャおよび機能の詳細なウォークスルーは、Oracle Cloud: Maximum Availability Architectureを参照してください。
Oracle Maximum Availability Architectureの利点
-
デプロイメント: Oracle Exadata Cloudシステム(ExaDB-DおよびExaDB-C@C)は、ストレージ、ネットワーク、オペレーティング・システム、Oracle Grid InfrastructureおよびOracle Databaseの構成のベスト・プラクティスを含む、Oracle Maximum Availability Architectureのベスト・プラクティスを使用してデプロイされます。ExaDB-Dは、きわめて高いスケーラビリティ、可用性および拡張度でエンタープライズOracleデータベースを実行するように最適化されています。
-
Oracle Maximum Availability Architectureデータベース・テンプレート: Oracle Cloudの自動化で作成されたすべてのOracle Cloudデータベースでは、ExaDB-D用に最適化されたOracle Maximum Availability Architectureのデフォルト設定を使用します。
カスタム・スクリプトを使用してクラウド・データベースを作成することはお薦めしません。メモリーおよびシステム・リソースの設定を調整する以外に、以前のデータベース・パラメータ設定(特に文書化されていないパラメータ)を移行しないようにしてください。潜在的なオーバーヘッドが原因で、1つの有益なデータベース・データ保護パラメータ
DB_BLOCK_CHECKINGはデフォルトで有効になっていません。MAAでは、アプリケーションのパフォーマンスへの影響を評価し、パフォーマンスへの影響が妥当である場合はこの設定を有効にすることを推奨しています。 -
バックアップとリストアの自動化: Oracle Cloud Infrastructure Object Storageへの自動バックアップを構成すると、リージョンに複数の可用性ドメインが存在する場合にバックアップ・コピーによって追加の保護が提供され、RMANによってクラウド・データベースのバックアップに物理的な破損がないかどうかが検証されます。
データベースのバックアップは毎日行われ、完全バックアップが週に1回、増分バックアップが他のすべての日に行われます。アーカイブ・ログのバックアップは、障害発生時のデータ損失の可能性を低減するために頻繁に行われます。アーカイブ・ログ頻度は通常30分です。
-
Oracle Exadata Database Machine固有の利点: Oracle Exadata Database Machineは、Oracleが提供する最適なOracle Maximum Availability Architectureプラットフォームです。Exadataは、最もミッション・クリティカルなエンタープライズ・アプリケーションをサポートするハードウェア、ソフトウェア、データベースおよび可用性のイノベーションを使用して設計されています。
具体的に言うと、Exadataには、Oracleを他のプラットフォーム・ベンダーやクラウド・ベンダーと差別化する独自の高可用性、データ保護およびサービス品質機能が用意されています。最高の可用性、安定性およびパフォーマンスを確保するには、アプリケーションおよびデータベース・システムのリソース・ニーズ(十分なCPU、メモリーおよびI/Oリソースなど)を満たすようにExadataクラウド・システムのサイズを設定することが非常に重要です。多数のデータベースを同じクラスタに統合する場合は、適切なサイズ設定が特に重要です。
Oracle Exadata Database MachineシステムにおけるOracle Maximum Availability Architectureの利点の包括的なリストは、Exadata Database Machine: Maximum Availability Architectureのベスト・プラクティスを参照してください。
これらの利点の例は次のとおりです。
-
高い可用性と短時間のブラウンアウト: 完全な冗長性を備えたフォルト・トレラントなハードウェアがストレージ、ネットワークおよびデータベース・サーバーに存在します。Oracle Real Application Clusters (Oracle RAC)、Oracle Clusterware、Oracle Database、Oracle Automatic Storage Management、Oracle Linux、Oracle Exadata Storage Serverなど、可用性に優れたリジリエントなソフトウェアを使用すると、アプリケーションは、計画外停止や計画メンテナンス・イベントを通してアプリケーション・サービス・レベルを維持できます。
たとえば、Exadataには、データベース・ノード、ストレージ・サーバーおよびネットワークの障害を2秒未満で検出して修復し、アプリケーションおよびデータベース・サービスの稼働時間とパフォーマンスを回復できる即時障害検出が用意されています。他のプラットフォームでは、同じタイプの障害について、30秒あるいは数分に及ぶブラックアウトと長期のアプリケーション・ブラウンアウトが発生することがあります。アプリケーションとデータベースのエンドツーエンドのブラウンアウトおよびブラックアウトを評価するための広範囲にわたる計画外停止および計画メンテナンス・テストを提供しているのは、Exadataプラットフォームのみです。
-
データ保護: Exadataは、物理的および論理的なブロック破損の防止と検出に加えて、場合によっては自動修正をOracle Databaseに提供します。
Exadata Hardware Assisted Resilient Data (HARD)チェックには、サーバー・パラメータ・ファイル、制御ファイル、ログ・ファイル、Oracleデータ・ファイルおよびOracle Data Guard Brokerファイルのサポートが含まれます(これらのファイルがExadataストレージに格納されている場合)。このインテリジェントなExadataストレージ検証では、HARDチェックが失敗すると、破損したデータがディスクに書き込まれなくなるため、データベース業界で以前は防止できなかった大規模なクラスの障害が排除されます。
Exadata HARDチェックの例は次のとおりです。
- REDOおよびブロック・チェックサム
- 正しいログ順序
- ブロック・タイプの検証
- ブロック番号の検証
- ブロック・マジック番号、ブロック・サイズ、順序番号、ブロック・ヘッダーおよびテール・データ構造などのOracleデータ構造
Exadata HARDチェックは、Exadataストレージ・ソフトウェア(セル・サービス)から開始され、データベースの
DB_BLOCK_CHECKSUMパラメータを有効にした後(クラウドではデフォルトで有効になっている)、透過的に機能します。Exadataは、HARDイニシアチブを現在サポートしている唯一のプラットフォームです。さらに、Oracle Exadata Storage Serverには、非侵入型の自動ハード・ディスク・スクラブおよび修復が用意されています。この機能では、アイドル時間中に定期的にハード・ディスクが検査され、修復されます。ハード・ディスクで不良セクターが検出された場合、Oracle Exadata Storage Serverは、別のミラー・コピーからデータを読み取ることによって不良セクターを修復するようOracle Automatic Storage Management (ASM)に自動的にリクエストを送信します。
最後に、ExadataおよびOracle ASMでは、データ・ブロックがバッファ・キャッシュに読み込まれるときに破損を検出し、後続のデータベース書込みでデータ・ブロックの良好なコピーを使用してデータ破損を自動的に修復できます。この固有のインテリジェントなデータ保護により、Exadata Database MachineとExaDB-Dは、Oracleデータベースに最適なデータ保護ストレージ・プラットフォームになります。
包括的なデータ保護のための最大可用性アーキテクチャのベスト・プラクティスは、別個のExadataインスタンス上のスタンバイ・データベースを使用して、Exadataのみで対処できない破損の検出、防止および自動修復を行うことです。また、スタンバイ・データベースによって、サイト、クラスタおよびデータベースの障害に起因する障害時の停止時間とデータ損失も最小限に抑えられます。
-
レスポンス時間に関するサービス品質: レスポンス時間を確実に短く最適に維持するようにエンドツーエンドのサービス品質機能を備えているのはExadataのみです。データベース・サーバーのI/Oレイテンシ制限とExadataストレージのI/Oレイテンシ制限により、レスポンス時間が特定のしきい値を超えた場合に、読取りまたは書込みI/Oをパートナ・セルにリダイレクトできます。
パフォーマンスが低下したり、予測できないためにストレージの信頼性がなくなった(ただし障害は発生していない)場合、ディスクまたはフラッシュ・キャッシュをオフラインに限定し、後でI/Oパフォーマンスが許容可能なレベルに戻ったことをヒューリスティックが示した場合にオンラインに戻すことができます。リソース管理は、最適化されたレベルでアプリケーションおよびデータベースが動作するように、重要なデータベース・ネットワークまたはI/O機能を優先するために役立ちます。
たとえば、データベース・ログの書込みは、Exadataネットワークおよびストレージでのバックアップ・リクエストよりも優先されます。さらに、パートナ・フラッシュ・キャッシュがウォームされてフラッシュ・ミスが最小限に抑えられるようにすることで、ストレージ・ソフトウェアの更新中に迅速なレスポンス時間が維持されます。
-
エンドツーエンドのテストと全体的なヘルス・チェック: OracleはOracle Exadata Cloud Infrastructure全体を所有しているため、エンドツーエンドのテストおよび最適化によって、オンプレミスとクラウドのどちらでホストされているかに関係なく、世界中のすべてのExadata顧客に利点がもたらされます。ミッション・クリティカルなシステムを実行するために必要な検証済の最適化および修正が、厳密なテストの後に一律に適用されます。ヘルス・チェックは、スタック全体を評価するように設計されています。
Exadataのヘルス・チェック・ユーティリティEXACHKは、Exadataクラウド対応であり、顧客の変更によって発生した可能性がある構成およびソフトウェアのアラートを強調表示します。現在、他のクラウド・プラットフォームでは、このようなエンドツーエンドのヘルス・チェックは提供されていません。Oracle Autonomous Databaseについては、EXACHKが自動的に実行されて、最大可用性アーキテクチャへの準拠が評価されます。Autonomous Database以外については、少なくとも月に1回と、ソフトウェア更新の前後にEXACHKを実行して、新しいベスト・プラクティスおよびアラートを評価することをお薦めします。
-
稼働時間の向上: 1か月当たりの稼働時間に関するサービス・レベル合意は99.95% (1か月当たり最大22分の停止時間)ですが、継続的なサービスのためのMAAベスト・プラクティスを使用すると、ほとんどの月で停止時間がゼロになります。
Exadataの機能および利点の完全なリスト: Oracle Exadata Database Machineの新機能
Oracle Maximum Availability Architectureのベスト・プラクティス・ペーパー: Oracle Maximum Availability Architecture (MAA)エンジニアリングはOracle Cloudチームと協力して、Oracle Cloud Infrastructureおよびセキュリティについて最適化されたOracle MAAプラクティスを統合します。継続的な可用性、Oracle Data Guard、Hybrid Data Guard、Oracle GoldenGate、および最大可用性アーキテクチャに関連する他のトピックについての追加情報は、Oracle CloudのMAAベスト・プラクティスを参照してください。
計画外停止に伴う予想される影響
次の表に、様々な計画外停止とそれに関連する潜在的なデータベースの停止時間、アプリケーション・レベルのリカバリ時間目標(RTO)およびデータ損失の可能性またはリカバリ・ポイント目標(RPO)を示します。Oracle Data Guardアーキテクチャの場合、データベースの停止時間またはサービス・レベルの停止時間には、検出時間や顧客がクラウド・コンソールのData Guardフェイルオーバー操作を開始するまでに要した時間は含まれません。
表28-1 Exadata Cloudのソフトウェア更新による可用性およびパフォーマンスへの影響
| 障害およびメンテナンス・イベント | データベースの停止時間 | サービス・レベルの停止時間(RTO) | 潜在的なサービス・レベルのデータ損失(RPO) |
|---|---|---|---|
|
次のものを含む、局所的なイベント: Exadataクラスタ・ネットワーク・トポロジの障害 ストレージ(ディスクおよびフラッシュ)の障害 データベース・インスタンスの障害 データベース・サーバーの障害 |
ゼロ | ほぼゼロ | ゼロ |
|
スタンバイ・データベースが存在しないため、バックアップからのリストアを必要とするイベント: データ破損 データベース全体の障害 全面的なストレージ障害 可用性ドメイン |
数分から数時間 (Data Guardなし) |
数分から数時間 (Data Guardなし) |
30分 (Data Guardなし) |
|
Data Guardを使用してフェイルオーバーするイベント: データ破損 データベース全体の障害 全面的なストレージ障害 可用性ドメインまたはリージョンの障害 |
数秒から数分1 自動ブロック修復機能により、物理的な破損については停止時間ゼロ |
数秒から数分1 自動ブロック修復を完了する間、物理的な破損を検出するフォアグラウンド・プロセスは一時停止します |
最大可用性(SYNC)についてはゼロ 最大パフォーマンス(ASYNC)についてはほぼゼロ |
1 リージョン障害から保護するには、プライマリ・データベースとは異なるリージョンにスタンバイ・データベースが必要です。
計画メンテナンスに伴う予想される影響
次の表に、様々なソフトウェア更新とそれに関連するデータベースおよびアプリケーションへの影響を示します。これは、Oracle Exadata Cloud@Customer (ExaDB-C@C)、Oracle Exadata Cloud Infrastructure (ExaDB-D) Gen2およびOracle Autonomous Database (ADB)を含む、Oracle Exadata Cloudインフラストラクチャすべてに適用可能です。
表28-2 Oracle Exadata Cloudのソフトウェア更新による可用性およびパフォーマンスへの影響
| ソフトウェア更新 | データベースへの影響 | アプリケーションへの影響 | スケジュール作成者 | 実行者 |
|---|---|---|---|---|
|
Exadataネットワーク・ファブリック・スイッチ |
データベースの再起動なしで停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト |
Oracleが顧客の好みに基づいてスケジュール。顧客は再スケジュールできます |
ADBと非ADBの両方に対応したOracle Cloud |
|
Exadataストレージ・サーバー |
データベースの再起動なしで停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト Exadataストレージ・サーバーは、冗長性を維持しながらローリング方式で更新されます Oracle Exadata System Softwareは、フラッシュ・キャッシュに最も頻繁にアクセスされるOLTPデータのセカンダリ・ミラーをプリフェッチして、ストレージ・サーバーの再起動中にアプリケーション・パフォーマンスを維持します データベース・バッファ用のExadataスマート・フラッシュは、ストレージ・サーバーの再起動後も維持されます Exadata 21.2ソフトウェアでは、永続ストレージ索引および永続列キャッシュ機能により、ストレージ・サーバーのソフトウェア更新後に一貫した問合せパフォーマンスを実現できます |
Oracleが顧客の好みに基づいてスケジュール。顧客は再スケジュールできます |
ADBと非ADBの両方に対応したOracle Cloud |
|
Exadata Databaseホスト - 月次インフラストラクチャ・セキュリティ・メンテナンス |
ホストまたはデータベースの再起動なしで停止時間ゼロ |
停止時間ゼロ |
Oracleがスケジュール。顧客は再スケジュールが可能 |
ADBと非ADBの両方に対応したOracle Cloud |
|
Exadata Databaseホスト - 四半期インフラストラクチャ・メンテナンス |
Oracle RACローリング更新により停止時間ゼロ |
停止時間ゼロ 計画メンテナンスが完了するまで、Exadata Databaseのコンピュート・リソースが削減されます |
Oracleが顧客の好みに基づいてスケジュール。顧客は再スケジュールできます |
ADBと非ADBの両方に対応したOracle Cloud |
|
Exadataデータベース・ゲスト |
Oracle RACローリング更新により停止時間ゼロ |
停止時間ゼロ 計画メンテナンスが完了するまで、Exadata Databaseのコンピュート・リソースが削減されます |
ADBの顧客 |
ADBに対応したOracle Cloud ADB以外については顧客がOracle Cloudコンソール/APIを使用 |
|
Oracle Databaseの四半期更新またはカスタム・イメージ更新 |
Oracle RACローリング更新により停止時間ゼロ |
停止時間ゼロ 計画メンテナンスが完了するまで、Exadata Databaseのコンピュート・リソースが削減されます データベースOJVMを使用するアプリケーションのデータベースを四半期ごとにローリング更新する際には、特別な考慮事項が必要になります。詳細は、MOSノート2217053.1を参照してください。 |
ADBの顧客 |
ADBに対応したOracle CloudADB-Dの場合は、Standby-First Patchのプラクティスが自動的に適用されます。 ADB以外については顧客がOracle Cloudコンソール/APIまたはdbaascliユーティリティを使用データベース・ホーム・パッチによるインプレースと、データベース移動によるアウトオブプレースでは、ソフトウェア更新が存在します。Data Guardおよびスタンバイ・データベースで動作します(MOS 2701789.1を参照)。 |
|
Oracle Grid Infrastructureの四半期更新またはアップグレード |
Oracle RACローリング更新により停止時間ゼロ |
停止時間ゼロ 計画メンテナンスが完了するまで、Exadata Databaseのコンピュート・リソースが削減されます |
ADBの顧客 |
ADBに対応したOracle Cloud ADB以外については顧客がOracle Cloudコンソール/APIまたはdbaascliユーティリティを使用 |
|
停止時間を伴うOracle Databaseのアップグレード |
数分から数時間の停止時間 |
数分から数時間の停止時間 |
ADBの顧客 |
ADBに対応したOracle Cloud ADB以外については顧客がOracle Cloudコンソール/APIまたはdbaascliユーティリティを使用 Data Guardおよびスタンバイ・データベースで動作します(MOS 2628228.1を参照)。 |
|
停止時間がゼロに近いOracle Databaseのアップグレード |
DBMS_ROLLING、Oracle GoldenGateレプリケーション、またはプラガブル・データベースの再配置により最小限の停止時間 |
DBMS_ROLLING、Oracle GoldenGateレプリケーション、またはプラガブル・データベースの再配置により最小限の停止時間 |
非ADBの顧客 |
共有Exadataインフラストラクチャ上のADB (ADB-S)に対応したOracle Cloudは、アップグレードのユースケースでプラガブル・データベースの再配置を実行できます DBMS_ROLLINGを利用するAutonomous以外については、顧客がdbaascliを使用。Exadata Cloud Database 19c Rolling Upgrade With DBMS_ROLLING (Doc ID 2832235.1)を参照してください ADB以外については顧客が最大可用性アーキテクチャの一般的なベスト・プラクティスを使用 |
Exadataクラウド・システムには、データベースおよびアプリケーションのパフォーマンス・ニーズを調整するために使用できるエラスティック機能が多数用意されています。必要に応じてリソースを再配置することで、ターゲット・データベースおよびアプリケーションのシステム・リソースを最大化できるとともに、コストを最小化できます。次の表に、Oracle Exadata Cloud InfrastructureおよびVMクラスタのエラスティック更新と、それらの更新に関連するデータベースおよびアプリケーションへの影響を示します。特に指定されていないかぎり、これらの操作はすべて、Oracle CloudコンソールまたはAPIを使用して実行できます。
表28-3 Exadataのエラスティック操作による可用性およびパフォーマンスへの影響
| VMクラスタの変更 | データベースへの影響 | アプリケーションへの影響 |
|---|---|---|
|
VMクラスタ・メモリーのスケール・アップまたはスケール・ダウン |
Oracle RACローリング更新により停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト |
|
VMクラスタCPUのスケール・アップまたはスケール・ダウン |
データベースの再起動なしで停止時間ゼロ |
停止時間ゼロ アプリケーションのパフォーマンスとスループットは、使用可能なCPUリソースの影響を受けることがあります |
|
データベース使用状況に応じたASMストレージのスケール・アップまたはスケール・ダウン(サイズ変更) |
データベースの再起動なしで停止時間ゼロ |
停止時間ゼロ アプリケーションのパフォーマンスへの影響は最小限に抑えられる可能性があります。 |
|
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X8M以降のシステム) |
データベースの再起動なしで停止時間ゼロ |
停止時間ゼロ |
|
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X8以前のシステム) |
Oracle RACローリング更新により停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト |
|
VMのローカル/u02ファイル・システム・サイズのスケール・ダウン |
スケール・ダウンについてはOracle RACローリング更新により停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト |
|
Exadataストレージ・セルの追加 |
データベースの再起動なしで停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト アプリケーションのパフォーマンスへの影響は最小限に抑えられる可能性があります |
|
Exadataデータベース・サーバーの追加 |
データベースの再起動なしで停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト Oracle RACインスタンスとCPUリソースを追加すると、アプリケーションのパフォーマンスとスループットが向上する可能性があります |
|
仮想マシン(VM)クラスタでのデータベース・ノードの追加/削除 |
データベースの再起動なしで停止時間ゼロ |
ゼロから数秒(1桁台)のブラウンアウト Oracle RACインスタンスとCPUリソースを追加または削除すると、アプリケーションのパフォーマンスとスループットが向上または低下する可能性があります |
これらのエラスティック変更の中にはかなりの時間を要するものがあり、アプリケーションの使用可能なリソースに影響を及ぼす可能性があるため、計画が必要です。
スケール・ダウンおよび削除による変更では、使用可能なリソースが減少します。リソースが減少してデータベースおよびアプリケーションの安定性に必要な量を下回ることがないように、また、アプリケーション・パフォーマンス目標を満たすように注意を払う必要があります。推定時間および計画の推奨事項は、次の表を参照してください。
表28-4 Exadataのエラスティック操作に関する顧客計画の推奨事項
| VMクラスタの変更 | 推定タイミング | 顧客計画の推奨事項 |
|---|---|---|
|
VMクラスタ・メモリーのスケール・アップまたはスケール・ダウン |
サービスを排出する時間およびOracle RACローリング再起動 通常はノード当たり15-30分ですが、アプリケーションの排出によって異なる場合があります |
アプリケーションの排出についての理解。 アプリケーションの継続的な可用性の実現を参照してください メモリーをスケール・ダウンする前に、データベースのSGAを引き続きhugepagesに格納できることと、アプリケーション・パフォーマンスが引き続き許容可能であることを確認します。 予測可能なアプリケーション・パフォーマンスおよび安定性を確保するには:
|
|
VMクラスタCPUのスケール・アップまたはスケール・ダウン |
オンライン操作は、通常、VMクラスタ当たり5分未満です。非常に小さい値から非常に大きい値へのスケール・アップ(10以上のoCPUの増加)には、10分かかる場合があります。 |
予測可能なアプリケーション・パフォーマンスおよび安定性を確保するには:
|
|
データベース使用状況に応じたASMストレージのスケール・アップまたはスケール・ダウン(サイズ変更) |
時間は、使用されているデータベース・ストレージ容量およびデータベース・アクティビティによって異なります。使用されているデータベース・ストレージの割合が高くなるほど、サイズ変更操作(ASMリバランスを含む)にかかる時間が長くなります。 通常は数分から数時間。 |
Oracle ASMリバランスは自動的に開始されます。ストレージの冗長性は保持されます。非侵入型のASM指数制限を使用する固有のベスト・プラクティスにより、アプリケーション・ワークロードへの影響は最小限です。 サイズ変更およびリバランス操作を最適化できるように、非ピーク・ウィンドウを選択します。 時間は大きく異なる可能性があるため、操作が数時間かけて完了するものと想定して計画します。VMクラスタ当たりの既存のサイズ変更またはリバランス操作の時間を推定するには、
リバランスが進行するにつれて、推定された統計はより正確になる傾向がありますが、同時ワークロードによって異なる場合があることに注意してください。 |
|
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X8M以降) |
オンライン操作は、通常、VMクラスタ当たり5分未満です |
VMローカル・ファイル・システムの領域はローカル・データベース・ホスト・ディスクに割り当てられ、そのデータベース・ホストにプロビジョニングされたすべてのVMクラスタの、すべてのVMゲストによって共有されます。ローカル/u02ファイル・システムのスケール・ダウンはRACローリング方式で実行する必要があり、アプリケーションの中断を引き起こす可能性があるため、同じExadataインフラストラクチャ上の他のVMクラスタでスケール・アップするための領域が残らないように、1つのVMクラスタ上でローカル/u02ファイル・システムの領域を不必要にスケール・アップしないでください。 |
|
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X8以前) |
サービスを排出する時間およびOracle RACローリング再起動通常はノード当たり15-30分ですが、アプリケーションの排出設定によって異なる場合があります。 |
アプリケーションの排出についての理解。 アプリケーションの継続的な可用性の実現を参照してください |
|
VMのローカル/u02ファイル・システム・サイズのスケール・ダウン |
サービスを排出する時間およびOracle RACローリング再起動通常はノード当たり15-30分ですが、アプリケーションの排出設定によって異なる場合があります。 |
アプリケーションの排出についての理解 アプリケーションの継続的な可用性の実現を参照してください |
|
Exadataストレージ・セルの追加 |
管理者が分散方法を選択するために、より多くの使用可能領域を作成するオンライン操作。 VMクラスタの数、データベース・ストレージの使用状況およびストレージ・アクティビティに応じて、通常は操作当たり3-72時間。非常にアクティブなデータベースと負荷が大きいストレージ・アクティビティでは、最大72時間かかることがあります。 ストレージ・セルの追加操作の一部として、この操作には2つの部分があります。1) ストレージの追加の一部としてシステムにストレージが追加されます。2) 管理者は別個の操作として、ASMディスク・グループを拡張するVMクラスタを決定する必要があります。 |
操作が数日かけて完了することがあるため、ストレージ容量の使用率が1か月以内に80%に達したときにストレージを追加することを計画します。 Oracle ASMリバランスは自動的に開始されます。ストレージの冗長性は保持されます。非侵入型のASM指数制限を使用する固有のベスト・プラクティスにより、アプリケーション・ワークロードへの影響は最小限です。 時間は大きく異なる可能性があるため、ストレージが使用可能になる前に操作が数日かけて完了するものと想定して計画します。VMクラスタ当たりの既存のサイズ変更またはリバランス操作の時間を推定するには、
リバランスが進行するにつれて、推定された統計はより正確になる傾向がありますが、同時ワークロードによって異なる場合があることに注意してください。 |
|
Exadataデータベース・サーバーの追加 |
VMクラスタを拡張するオンライン操作。データベース・コンピュートをExaDB-Dに追加して、VMクラスタを拡張する1ステップ・プロセス。 Exadata Database Server当たり、およそ1から6時間 |
データベース・リソースの使用率が1か月以内に80%に達したときに、データベース・コンピュートを追加することを計画します。この操作には数時間から1日かかることに注意して計画してください。 データベース・コンピュートの追加操作をより短時間で完了できるように、非ピーク・ウィンドウを選択します Oracle Clusterwareによって登録され、Oracle Cloudコンソールに表示される各Oracle RACデータベースが拡張されます。Oracle Cloudコンソール外で、またはdbaascliを使用せずにデータベースが構成された場合、そのデータベースは拡張されません。 |
|
仮想マシン(VM)クラスタでのデータベース・ノードの追加/削除 |
VMクラスタでデータベース・ノードを追加する際、VMクラスタ内のデータベースの数に応じて通常は3-6時間かかり、データベースの停止時間はゼロです VMクラスタでデータベース・ノードを削除する際、VMクラスタ内のデータベースの数に応じて通常は1-2時間かかり、データベースの停止時間はゼロです |
追加/削除操作は即時ではなく、操作が完了するまでに数時間かかる場合があることを理解してください 削除操作によって、データベース・コンピュート、OCPUおよびメモリー・リソースが削減されるため、アプリケーション・パフォーマンスに影響が生じる可能性があります |
アプリケーションの継続的な可用性の実現
Oracle Exadata Database Service (ExaDB-DおよびExaDB-C@C)の一部として、すべてのソフトウェア更新(非ローリング・データベース・アップグレードまたは非ローリング・パッチを除く)をオンラインで、あるいはOracle RACローリング更新を使用して行うことで、継続的なデータベース稼働時間を実現できます。さらに、ストレージ、ExadataネットワークまたはExadataデータベース・サーバーのローカルな障害が自動的に管理され、データベース稼働時間が維持されます。
Oracle RACのスイッチオーバーまたはフェイルオーバー・イベント中に継続的なアプリケーション稼働時間を実現するには、次に示すアプリケーション構成のベスト・プラクティスに従ってください。
- Oracle Clusterware管理データベース・サービスを使用してアプリケーションを接続します。Oracle Data Guard環境では、ロール・ベースのサービスを使用します。
- タイムアウト、再試行および遅延が組み込まれた推奨の接続文字列を使用して、停止中に着信接続でエラーが表示されないようにします。
- 高速アプリケーション通知を使用して接続を構成します。
- サービスを排出および再配置します。次の表を参照し、作業のバッチを流用または開始する際の接続のテストや、使用間におけるプールへの接続の返却など、排出をサポートする推奨ベスト・プラクティスを使用してください。
- アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを利用して、障害後に、実行中のコミットされていないトランザクションを透過的にリプレイします。
前述のチェックリストの詳細は、「アプリケーションの継続的な可用性の構成」を参照してください。アプリケーション・フェイルオーバーの準備状況の検証(ドキュメントID 2758734.1)に従って、アプリケーションの準備状況をテストすることをお薦めします。
Oracle Exadata Database Serviceの計画メンテナンス・イベントに応じて、Oracleでは、Oracle RACインスタンスを停止する前にデータベース・サービスを自動的に排出および再配置しようと試みます。OLTPアプリケーションについては、サービスの排出および再配置が通常は非常に適切に機能し、アプリケーションの停止時間がなくなります。
実行時間が長いバッチ・ジョブやレポートなど、一部のアプリケーションでは、排出および再配置を最大排出時間内に正常に行うことができない場合があります。そうしたアプリケーションについては、これらのタイプのアクティビティを避けてソフトウェアの計画メンテナンス・ウィンドウをスケジュールするか、計画メンテナンス・ウィンドウの前にこれらのアクティビティを停止することをお薦めします。たとえば、バッチ・ウィンドウ外で実行するように計画メンテナンス・ウィンドウを再スケジュールしたり、計画メンテナンス・ウィンドウの前にバッチ・ジョブを停止できます。
データベースOJVMを使用するアプリケーションのデータベースを四半期ごとにローリング更新する際には、特別な考慮事項が必要になります。詳細は、MOSノート2217053.1を参照してください。
次の表に、Oracle RACインスタンスのローリング再起動を実行する計画メンテナンス・イベントと、アプリケーションに影響を与える可能性がある、関連するサービスの排出タイムアウト変数を示します。
表28-5 Exadata Cloudのソフトウェア更新とエラスティック操作のためのアプリケーション・ドレイン属性
| Oracle Exadata Database Serviceのソフトウェア更新またはエラスティック操作 | 排出タイムアウト変数 |
|---|---|
|
Oracle DBHOMEパッチ適用およびデータベース移動 |
Oracle Cloudソフトウェアの自動化により、データベース・サービス構成(srvctlなど)によって定義されたdrain_timeout設定を保持したまま、データベース・サービスが停止/再配置されます。1 サービスで定義されたdrain_timeoutは、オプション サポートされているOracle Cloud内部の最大排出時間は2時間です。 |
|
Oracle Grid Infrastructure (GI)パッチ適用およびアップグレード |
Oracle Cloudソフトウェアの自動化により、データベース・サービス構成(srvctlなど)によって定義されたdrain_timeout設定を保持したまま、データベース・サービスが停止/再配置されます。1 コマンドライン操作 サポートされているOracleクラウド内部の最大排出時間は2時間です。 |
|
仮想マシン・オペレーティング・システムのソフトウェア更新(Exadataデータベース・ゲスト) |
Exadataのpatchmgr/dbnodeupdateソフトウェア・プログラムによって、排出オーケストレーション(rhphelper)がコールされます。 排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1)を参照してください)。
データベース・サービス構成によって定義されたDRAIN_TIMEOUT設定は、サービスの停止/再配置中に適用されます。 |
|
Exadata X8以前のシステム
|
Exadata X8以前のシステムのローカル・ファイル・システムのサイズ変更操作によって、排出オーケストレーション(rhphelper)がコールされます。 排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1)を参照してください)。
データベース・サービス構成によって定義されたDRAIN_TIMEOUT設定は、サービスの停止/再配置中に適用されます。 この操作でサポートされているOracle Cloud内部の最大排出時間は300秒です。 |
|
Exadata X8M以降のシステム
|
Exadata X8M以降のシステムによって、排出オーケストレーション(rhphelper)がコールされます。 排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1)を参照してください)。
データベース・サービス構成によって定義されたDRAIN_TIMEOUT設定は、サービスの停止/再配置中に適用されます。 この操作でサポートされているOracle Cloud内部の最大排出時間は300秒です。 |
|
Exadata X8M以降のシステム
|
Exadata X8M以降のシステムによって、排出オーケストレーション(rhphelper)がコールされます。 排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1)を参照してください)。
データベース・サービス構成によって定義されたDRAIN_TIMEOUT設定は、サービスの停止/再配置中に適用されます。 この操作でサポートされているOracle Cloud内部の最大排出時間は300秒です。 |
|
Oracle Exadata Cloud Infrastructure (ExaDB-D)のソフトウェア更新 |
ExaDB-Dデータベース・ホストによって、ドレイン・オーケストレーション(rhphelper)がコールされます。 排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1)を参照してください)。
データベース・サービス構成によって定義されたDRAIN_TIMEOUT設定は、サービスの停止/再配置中に適用されます。 この操作でサポートされているOracle Cloud内部の最大排出時間は、次のとおりです
拡張インフラストラクチャ・メンテナンス制御機能: Oracle Cloudの内部最大値より長い排出時間を実現するには、拡張インフラストラクチャ・メンテナンス制御機能のカスタム・アクション機能を利用します。これにより、次のデータベース・サーバー更新の開始前にインフラストラクチャ・メンテナンスを一時停止し、データベース・サーバーで実行中のデータベース・サービスを直接停止/再配置してから、次のデータベース・サーバーに進むためにインフラストラクチャ・メンテナンスを再開できます。この機能は現在、Oracle Exadata Cloud@Customer (ExaDB-C@C)でも使用できます。詳細は、Oracle Cloud InfrastructureドキュメントのOracle管理のインフラストラクチャ・メンテナンスの構成に関する項を参照してください。 |
1 このサービス排出機能を入手するための最小ソフトウェア要件は、1) Oracle Database 12.2以降、2) 最新のOracle Cloud DBaaSツール・ソフトウェアです
Oracle Exadata CloudにおけるOracle Maximum Availability Architectureリファレンス・アーキテクチャ
Oracle Exadata Cloud (ExaDB-DおよびExaDB-C@C)は、固有の高可用性、データ保護および障害時リカバリのサービス・レベル合意に関係なく、すべてのOracle Maximum Availability Architectureリファレンス・アーキテクチャをサポートし、すべてのOracle Databaseについてサポートを提供します。Oracle Exadata CloudにおけるOracle Maximum Availability Architectureの詳細は、Oracle CloudのMAAベスト・プラクティスを参照してください。