ヘッダーをスキップ

Oracle Applications概要
リリース12
E05390-02		目次へ
目次		前のページへ
前へ		次のページへ
次へ

高可用性

概要

高可用性のためのオプションと機能では、計画済および計画外の停止時間を最小にしたり、停止時間後のリカバリを容易にすることができます。このオプションと機能は、次のとおりです。

この項では、新規インストールまたはアップグレードの計画時に正しい判断をするための指針を中心に、Oracle E-Business Suiteの可用性を向上させる主要機能について包括的なガイドを提供します。

パッチ適用に関するヒント

パッチの適用は、Oracle Applicationsのデータベース管理者（DBA）が行う主要な仕事の1つです。多数のパッチを適用する必要がある場合、停止時間に必要な時間が多大になる可能性があります。しかし、この停止時間を最小限に抑えるいくつかの簡単な方法があります。

これらの方法については、この項で必要に応じて詳しく説明します。

保守モード

保守モードは、Oracle Applicationsシステムがパッチ・アクティビティを行う場合にのみアクセスできる操作モードです。このモードでは、AutoPatchセッションに対して、最適パフォーマンスを提供し、必要な停止時間を最小限に抑えます。

注意: 保守モードは、AutoPatchセッションの場合にのみ必要です。その他のADユーティリティでは、保守モードを有効にする必要はありません。

管理者は、Oracle Applications Managerを使用して、システムの停止時間をスケジュールし、ユーザーに停止時間が近づいていることを知らせるアラート・メッセージを送信できます。保守モードに入ると、Oracle Applicationsにログオンを試行するユーザーは、システムの停止時間を知らせるURLにリダイレクトされます。

保守モードの使用に関して実用に際し役立つポイントがいくつかあります。

共有APPL_TOPおよびアプリケーション層ファイル・システム

従来のOracle Applicationsの複数ノード・インストールでは、各アプリケーション層ノードで独自のファイル・システムを保守する必要がありました。その後、単一のAPPL_TOPを複数ノード・システムのすべてのアプリケーション層ノードで共有できるようにするために、インストールおよび移行のオプションが導入されました。これが共有APPL_TOPファイル・システムと呼ばれ、通常、共有APPL_TOPと略称されています。

さらに導入された機能が、それぞれ独自のアプリケーション層サービス・セットを持った複数ノードのAPPL_TOPをマージして、全体で共有できる単一のAPPL_TOPを生成するためのものです。あまり一般的ではない使用例として、ノード数を減らす、つまり複数ノード・インストールから単一ノード・インストールに移行するための計画の一部としてAPPL_TOPをマージする場合があります。

これらの概念は、その後、アプリケーション層テクノロジ・スタック・ファイル・システムも共有できるように拡張され、その結果が、共有アプリケーション層ファイル・システムと呼ばれています。

この項では、Oracle Applicationsリリース12環境でデフォルトとして使用されている共有アプリケーション層ファイル・システムの利点を説明します。現在の制限事項についても、必要に応じて説明します。

共有アプリケーション層ファイル・システム

共有アプリケーション層ファイル・システムでは、各アプリケーション層ノードでマウントされた単一の共有ディスク・リソースにすべてのアプリケーション層ファイルがインストールされます。アプリケーション層ノードはいずれも、フォームやWebページの提供などのすべての標準アプリケーション層サービスを実行するように構成でき、共有ファイル・システムに対するすべての変更が、すべてのアプリケーション層ノードでただちに参照できます。

共有アプリケーション層ファイル・システムの配置は、従来の共有APPL_TOPアーキテクチャの拡張とみなすことができます。共有アプリケーション層ファイル・システムの利点と制限は、共有APPL_TOPの場合に類似しています。

共有アプリケーション層ファイル・システムの使用には、次のような利点があります。

共有アプリケーション層ファイル・システムの使用には、現在次のような制限があります。

共有ディスク・リソース

共有アプリケーション層ファイル・システムは、リモートのNFSマウント・ディスクやRAIDアレイの一部など、任意の標準タイプの共有ディスク・リソースに常駐できます。ただし、選択したディスク・リソースのパフォーマンスがピーク需要を満たす十分なものであることを確認する必要があります。たとえば、NFSマウント・ディスクでは大量のネットワーク・トラフィックがある際に読取りや書込みのパフォーマンスが不十分な場合があり、RAIDアレイでは高可用性とパフォーマンスおよびコストの間で適切なバランスをとるよう慎重に実装する必要があります。

共有アプリケーション層ファイル・システムの作成

デフォルトで、リリース12のRapid Installでは複数ノードのアプリケーション層環境で共有アプリケーション層ファイル・システムを使用するよう構成されます。

注意: 共有アプリケーション層ファイル・システムの使用方法の詳細は、OracleMetaLinkのNote 384248.1の「Sharing the Application Tier File System in Oracle E-Business Suite Release 12」を参照してください。

共有APPL_TOPおよび共有アプリケーション層ファイル・システムの高可用性

共有APPL_TOPおよび共有アプリケーション層ファイル・システムの利用により、次のように高可用性が向上します。

ステージAPPL_TOP

ステージAPPL_TOPとは、本番システムからコピーされて1つ以上のパッチが適用され、その後本番システムに再コピーされるAPPL_TOPです。これは、パッチの適用に必要な本番システムの停止時間を最小化させ、可用性を向上させるのに役立ちます。

このコンセプトは、Oracle Applicationsシステム全体のステージングにも適用できます。これには、すべてのAPPL_TOPおよびデータベースを含む、本番システムの完全なコピーを作成します。その後、本番システムを稼働させたまま、パッチをステージ・システムに適用できます。本番システムの停止時間は、必ず、すべてのパッチがテスト・システムに適用された後に開始する必要があります。ステージAPPL_TOPは、本番データベースへの更新の適用のためと、本番APPL_TOPとの同期化のために使用されます。

前提条件と制限事項

ステージ・システムへのパッチの適用

ステージ・システムには、関連するパッチ・ドライバを適用するAutoPatchにより、Oracle Applicationsシステムに対する場合と同じようにパッチが適用されます。このステップが実行されている間は、本番システムにパッチを適用しないようにします。適用した場合、ステージ・システムの再作成が必要になります。

注意: パッチの適用の詳細は、『Oracle Applicationsメンテナンス・プロシージャ』を参照してください。

本番システムの更新

ステージ・システムに必要なパッチが適用された後は、本番システムを更新できます。本番システム上のすべてのサービスを使用不可にした後、適用するパッチのドライバを適用可能に指定して、AutoPatchを実行します。ステージ・システムに複数のパッチを適用した場合、ステージに適用した各パッチのドライバを同じ順番で実行する必要があります。停止時間を短縮するには、ステージングの前にパッチのマージを検討してください。

ここで、本番APPL_TOPをステージAPPL_TOPと同期化する必要があります。このタスクは、本番データベースの更新中に完了できます。このタスクの実行には、様々なソフトウェア・ユーティリティを使用できます。ハードウェアによるソリューションを提供しているベンダーもあります。

システムのトポロジに複数のAPPL_TOPが含まれている場合は、各APPL_TOPを本番システムにコピーする必要があります。単一のAPPL_TOPを共有している場合は、1つのシステムのみを同期化します。COMMON_TOPディレクトリは、システムによってはAPPL_TOPの外にありますが、これも、Oracle ApplicationsシステムではAPPL_TOPごとに更新する必要があります。

警告: 特定の構成ファイル、ログ・ディレクトリおよび環境スクリプトは、APPL_TOPごとに固有です。これらのファイルおよびディレクトリは、コピーから除外する必要があります。

パッチ適用の最終手順

Oracle Applicationsのステージ・システムを使用して適用されたパッチに関するパッチ履歴のコピーおよび生成部分は、この段階ではステージ・データベースに格納されており、これらのパッチのパッチ履歴のデータベース部分は、ステージ・データベースと本番データベースの両方に格納されています。

本番システムのパッチ履歴を完全なものにするには、本番データベースに接続されているOracle Applicationsのステージ・システムを使用して適用されたすべてのパッチのコピーおよび生成部分をロードする必要があります。adphmigr.plユーティリティを使用すれば、Oracle Applicationsのステージ・システムを使用して適用されたパッチのコピーおよび生成部分のパッチ履歴をステージ・データベースからエクスポートできます。その後、AutoPatchを使用して、抽出された履歴データを本番データベースにインポートできます。

図9-1 ステージAPPL_TOPを使用したパッチ適用

本文の説明内容に関するイメージ

ステージAPPL_TOPと共有APPL_TOPの組合せ

ステージAPPL_TOPの方法と共有APPL_TOPの方法には、相互に異なる、補完的な利点があります。必要に応じて、共有APPL_TOPシステムのステージAPPL_TOPを作成して、共有APPL_TOP（および分散AD）の利点をステージ・システムにも適用できます。

分散AD

多くの配置では、大規模データベース・サーバーと、複数の小規模アプリケーション（中間）層システムを使用しています。増加する低価格のLinuxベース・システムの配置においては、この構成が一般的になってきています。

ADでは常にジョブ・システムが稼働し、複数のワーカーがジョブを割り当てられています。ジョブ・システムの情報はデータベースに格納されていて、ワーカーは関連する表の内容に基づいてそれぞれの割当てを受け取ります。分散AD機能は、同じADセッションの複数のワーカーを複数のアプリケーション階層ノードで開始できるようにすることにより、スケーラビリティ、パフォーマンスおよびリソース活用を向上させます。これにより、使用可能なリソースを使用して、割り当てられたジョブをより効率的に完了できます。

分散ADの要件

ADワーカーは、データベース・オブジェクトに加え、ファイル・システム・オブジェクトも作成および更新するので、共有APPL_TOP（前述）を使用して、これらのファイルが単一の集中保管場所で作成されるようにする必要があります。

分散ADの使用

共有APPL_TOPノードの1つで、ローカル・ワーカーの数およびワーカーの合計数を指定して、AutoPatchまたはAD管理のセッションを開始します。

AutoPatchまたはAD管理の使用時も、ローカルおよびローカルでないワーカーの両方を使用して、共有APPL_TOP環境にある任意のノードから通常のADコントローラ・セッションを開始して標準のADコントローラ操作を実行できます。これは、ジョブ・システムがAutoPatchおよびAD管理の実行時にも複数回起動できることから可能になります。ジョブ・システムの個々の呼び出しが完了するたびに、分散ADコントローラ・セッションは、ジョブ・システムが再び呼び出される（このときローカル・ワーカーが再度開始されます）まで、またはADセッションが終了する（このときADコントローラが終了します）まで待機します。

注意: 分散ADおよびADコントローラの詳細は、『Oracle Applicationsメンテナンス・ユーティリティ』を参照してください。

ADコントローラのログ・ファイル

ADコントローラにより作成されるログ・ファイルは、ADコントローラ・セッションがどこで開始されても作成されます。これは、特定のプラットフォーム上でのファイル・ロックの問題を防ぐためです。したがって、ADコントローラのログ・ファイルには、ADコントローラ・セッションの呼び出し元であるノードの名前を含めることをお薦めします。

NOLOGGING操作

OracleデータベースのNOLOGGING機能は、Oracle E-Business Suiteの特定の領域のパフォーマンスを向上させる場合に使用します。たとえば、パッチのインストール時や、Business Intelligenceの要約データの構築時に使用します。

操作時にNOLOGGINGを使用するということは、データベースのREDOログの、行われた変更についての情報が不完全であることを意味します。NOLOGGING操作時に更新されたデータ・ブロックは無効として示されます。その結果、（ホット・バックアップまたはコールド・バックアップの時点から）ある時点までのデータベースのリストアには、影響を受けたデータ・ブロックを最新の状態にし、リストアしたデータベースを使用可能にするための追加手順が必要となる場合があります。この追加手順には、関連データファイルの新規バックアップ、または影響を受けたオブジェクトの削除および再構築が含まれます。これは、スタンバイ・データベースを有効化する場合にも同様です。

注意: Oracleデータベース・サーバー10g リリース2でも、ロギングを常に実行するように強制できます。これにより、確実にすべてのデータ変更がデータベースのREDOログに書き込まれるので、リストアされたバックアップへの再作成やスタンバイ・データベースへの伝播が可能になります。DATABASEコマンドおよびTABLESPACEコマンドのFORCE LOGGING句の詳細は、『Oracle Data Guard概要および管理』を参照してください。

NOLOGGINGの原理

Oracle E-Business Suiteでは、特定の場合に、リソース集約的なタスクをより効率的に実行するために、データベースのNOLOGGING機能が使用されます。操作にNOLOGGINGが使用される場合、データ・ブロックは、システム・グローバル領域（SGA）のバッファ・キャッシュを介さずに、データファイルに直接書き込まれます。

インスタンス・リカバリでは、クラッシュ後のSGAの再構築にはオンラインREDOログが使用され、コミットされた変更がロール・フォワードされてデータ・ブロックの有効性が確保されます。NOLOGGINGを使用しても、インスタンス・リカバリには影響はありません。

データベース・リカバリでは、REDOログを使用して必要な変更をロール・フォワードして再作成し、データベースを目的の時点までリストアする必要があります。NOLOGGING操作では、REDOログはバイパスされ、直接データファイルに書き込まれるので、REDOログにはメディア・リカバリでロール・フォワードするための十分なデータが含まれません。かわりに、新規ブロックが無効であることを示す情報のみが含まれます。したがって、NOLOGGING操作でのロール・フォワードは、結果として、リストアされたデータベースに無効なブロックが残ります。同じ問題が、スタンバイ・データベースを有効化する際にも発生する可能性があります。

NOLOGGING操作が実行された後にバックアップ・データベースまたは有効化されたスタンバイ・データベースを使用できるようにするには、データベース・リカバリ以外のメカニズムを使用して、影響を受けたブロックの最新コピーを取得または作成する必要があります。

これには2つのオプションがあり、状況によっていずれかが適切なオプションとなります。

NOLOGGINGの使用方法

NOLOGGINGは、Oracle E-Business Suiteでは、次の状況で使用します。

必要な処理

各自の環境下におけるNOLOGGING処理をモニターするには、定期的に本番データベースに問い合せて、NOLOGGING操作が行われたデータファイルを識別する必要があります。また、Oracle Applicationsのパッチを適用する前後で問合せを実行して、NOLOGGING処理が行われたかどうかを調べる必要があります。

Oracle Enterprise Managerなどのモニタリング・ソフトウェアを介して適切な問合せを実行できます。または、データ・ディクショナリ・ビューv$datafileのunrecoverable_change#とunrecoverable_timeの列に基づいて問合せを作成できます。これらは、データファイル内でリカバリ不能な操作またはNOLOGGING操作によりブロックが無効とマークされるたびに更新されます。

問合せの結果は、スナップショットとして保存し、最新のスナップショットと比較できます。これにより、データベースでNOLOGGING操作が実行された場合にそれを識別し、バックアップ・データファイルを新規コピーでリフレッシュしておき、リストアが必要になったときに使用できるようにしておくことができます。

障害時リカバリ

Oracle E-Business Suiteのインストールに影響する重大な問題は、組織の活動能力にとってリスクとなります。そのような問題として次のものが考えられます。

この項では、障害時リカバリの分野について概要を示します。これは、高可用性戦略における決定的な要素と考えられます。障害時リカバリでは、重大な問題に際しても運転の続行を確保するために、データベースおよびその環境を保護する手段を講じることが必要です。Oracleでは、Oracle Data Guardおよびフラッシュバック・データベースなどの機能を提供しています。

フェイルオーバー後にスタンバイ環境を本番環境として実行するために必要なその他のハードウェアおよびソフトウェアをインストールして、プライマリ・データベースでの変更がすべてスタンバイ上で一致していることを確認する必要もあります。例として、テープ・バックアップ機器とソフトウェア、システム管理とモニタリング・ソフトウェアおよびその他のアプリケーションがあります。

Data Guardおよびリリース12

Oracle Data Guardは、サイトの1つに障害が発生した場合の損失を防ぐために、1つのデータベースから他のデータベースへ変更を伝播するメカニズムを提供します。Oracle Data Guardの構成には主に、REDO Apply（多くの場合、フィジカル・スタンバイと呼ばれます）とSQL Apply（多くの場合、ロジカル・スタンバイと呼ばれます）の2種類があります。 これらはともにプライマリ・データベースのREDO情報を使用して、本番システムの変更をスタンバイ・データベースに伝播します。

プライマリ・サイト全体におよぶ災害から防御するためには、セカンダリ環境が、プライマリ環境と物理的に離れている必要があります。このため、2つのデータ間で、最大のREDOトラフィックに対しても十分な帯域幅（容量）のある、信頼できるネットワーク接続を維持することが必須になります。もう1つの要件は、セカンダリ・サイトのサーバーがプライマリ・サイトと同じタイプであり、必要なレベルのサービスを提供できる十分な数があることです。これは、所属組織のニーズに応じて、（より少ないユーザー数をサポートする）最小限のレベルのサービスか、通常提供されているのとまったく同じレベルのサービスのいずれかとなります。

Oracle Data Guardが本番データベースから生成されるREDOに依存しているということは、Oracle E-Business Suiteでリソース集約的なタスクをより高速のスループットで実行するためにNOLOGGING機能（前述）を使用する操作の場合には、重大な影響をもたらします。Oracleでは、バックアップとリカバリおよびスタンバイ・データベースの保守手順を簡略化するために、データベース・レベルで強制ロギング機能をオンにすることをお薦めしています。リリース12でNOLOGGING機能が使用されている場合、強制ロギングを使用しないように選択すると、対応する変更をスタンバイ・データベースに加えるには不十分なREDO情報が生成されることになります。したがって、その後、手動ステップを実行してスタンバイをリフレッシュ（または関連オブジェクトを再作成）し、スタンバイが引き続き使用可能なことを確認する必要がある場合があります。

最後に、所属組織のビジネス要件に応じて、次の保護モードのいずれかを選択します。

フラッシュバック・データベース

Oracleでは、次の目的のためにフラッシュバック・データベース機能を有効にすることをお薦めします。

フラッシュバック・データベースでは、データ・ファイルのバックアップ・コピーをリストアせずにデータベースを以前の時点まで巻き戻すことができます。これは、通常操作時に、フラッシュ・リカバリ領域に常駐するフラッシュバック・ログに、フラッシュバック・データベースがバックデータ・ブロックのビフォア・イメージをバッファおよび書き込むことで実現できます。

フラッシュバック・データベースでは、プライマリまたはスタンバイ・データベースをData Guardロールの推移の前の時点にフラッシュバックすることもできます。さらに、フラッシュバック・データベース操作はリセット・ログ操作の前の時点まで実行できます。これにより、管理者がより柔軟にヒューマン・エラーを検出して修正することができます。

目次   |   前へ   |   ページの先頭へ   |   次へ

Oracleロゴ
Copyright © 2000, 2007, Oracle. All rights reserved.