6 アプリケーションの継続的なサービスの有効化
基盤となるネットワーク、システムおよびデータベースが常に使用可能であれば、アプリケーションの継続的なサービスは簡単に実現します。
計画外停止や計画メンテナンス・アクティビティの際にも継続的なサービスを実現することは困難な場合があります。MAAデータベース・アーキテクチャおよびその構成と運用のベスト・プラクティスは、冗長性と、障害を許容および防止し、場合によっては自動修復する機能に基づいて構築されます。
ただし、障害の影響がデータベース・インスタンス、データベース・ノード、またはクラスタやデータ・センター全体に及ぶ場合は常に、アプリケーションの停止時間が発生する可能性があります。同様に、計画メンテナンス・アクティビティの中には、データベース・インスタンス、データベース・ノードまたはデータベース・サーバー全体の再起動が必要になるものがあります。
いずれの場合も、単純なチェックリストに従って、アプリケーションが接続されているデータベース・サービスを別のOracle RACインスタンスまたは別のデータベースに移行できれば必ず、アプリケーションの停止時間をなくすか、ほとんど発生させないようにすることが可能です。
アプリケーションの継続的なサービスを実現するための様々なレベルとオプションについては、「アプリケーションの継続的な可用性の構成」を参照してください。
計画メンテナンス・イベントのドレイン・タイムアウト
計画メンテナンス・イベントの場合、アプリケーションによっては実行中のトランザクションが完了するまでに時間がかかる場合があります。
ワークロードが実行中のトランザクションを正常に完了し、セッションを移動するまでの時間(DRAIN_TIMEOUT
)は、ワークロードの特性によって異なります。短いOLTPトランザクションでは、1分のDRAIN_TIMEOUT
で十分ですが、バッチ・ジョブには30分かかる場合があります。場合によっては、これらの長いトランザクションを、計画メンテナンス・ウィンドウ外の時間まで一時停止することをお薦めします。
DRAIN_TIMEOUT
をより長くする構成には、計画メンテナンス・ウィンドウが拡張されるというトレードオフがあります。
次の表では、Oracle RACインスタンスのローリング再起動が発生する計画メンテナンス・イベントと、アプリケーションに影響を与える可能性がある、関連するサービスの排出タイムアウト変数について概説します。
表6-1 計画メンテナンス・イベントの排出タイムアウト変数
計画メンテナンス・イベント | アプリケーション・ドレイン・タイムアウト変数 |
---|---|
Exadataデータベース・ホスト(Dom0)のソフトウェアの変更 |
Exadataホストは、10分の最大タイムアウトでオペレーティング・システム(OS)のシャットダウンを処理します。 OSのシャットダウンによって、次の排出タイムアウト設定を持つ
それぞれのクラスタウェア管理サービスも、前述の値より小さくすることができる 関連項目: Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1) |
Exadataデータベース・ゲスト(DomU)のソフトウェアの変更 |
Exadataの
それぞれのクラスタウェア管理サービスも、前述の値より小さくすることができる 関連項目: Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Doc ID 2385790.1) |
Oracle Grid Infrastructure (GI)ソフトウェアの変更またはアップグレード |
推奨されるステップは、Graceful Application Switchover in RAC with No Application Interruption (Doc ID 1593712.1)に記載されています。 例:
それぞれのクラスタウェア管理サービスも、前述の値より小さくすることができる |
Oracle Databaseソフトウェアの変更 |
推奨されるステップは、Graceful Application Switchover in RAC with No Application Interruption (Doc ID 1593712.1)に記載されています。 例:
それぞれのクラスタウェア管理サービスも、前述の値より小さくすることができる |
関連項目: