リリース11i（11.5.10）
部品番号: B15656-01
目次
前へ
次へ
| Oracle Applications概要 リリース11i（11.5.10） 部品番号: B15656-01 | 目次 | 前へ | 次へ |
高可用性のためのオプションと機能では、計画済および計画外の停止時間を最小にしたり、停止時間後のリカバリを容易にすることができます。 このオプションと機能は、次のとおりです。
この項では、新規インストールまたはアップグレードの計画時に正しい判断をするための指針を中心に、Oracle E-Business Suiteの可用性を向上させる主要機能について包括的なガイドを提供します。
パッチの適用は、Oracle Applicationsのデータベース管理者（DBA）が行う主要な仕事の1つです。 多数のパッチを適用する必要がある場合、停止時間に必要な時間が多大になる可能性があります。 しかし、この停止時間を最小限に抑えるいくつかの簡単な方法があります。
保守モードは、リリース11.5.10で導入された新規の操作モードで、パッチ適用操作の場合にのみOracle Applicationsシステムへのアクセスが可能になります。 このモードでは、AutoPatchセッションに対して、最適パフォーマンスを提供し、必要な停止時間を最小限に抑えます。
注意: 保守モードは、AutoPatchセッションの場合にのみ必要です。 その他のADユーティリティでは、保守モードを有効にする必要はありません。
管理者は、Oracle Applications Managerを使用して、システムの停止時間をスケジュールし、ユーザーに停止時間が近づいていることを知らせるアラート・メッセージを送信できます。 保守モードに入ると、Oracle Applicationsにログオンを試行するユーザーは、システムの停止時間を知らせるURLにリダイレクトされます。
保守モードの使用に関して実用に際し役立つポイントがいくつかあります。
この項目については、「共有APPL_TOP」で説明するため、ここでは簡単に言及します。 高可用性に関連する、最も重要な共有APPL_TOP機能は次のとおりです。
ステージAPPL_TOPとは、本番システムからコピーされて1つ以上のパッチが適用され、その後本番システムに再コピーされるAPPL_TOPです。 これは、パッチの適用に必要な本番システムの停止時間を最小化させ、可用性を向上させるのに役立ちます。
このコンセプトは、Oracle Applicationsシステム全体のステージングにも適用できます。 これには、すべてのAPPL_TOPおよびデータベースを含む、本番システムの完全なコピーを作成します。 その後、本番システムを稼働させたまま、パッチをステージ・システムに適用できます。 本番システムの停止時間は、必ず、すべてのパッチがテスト・システムに適用された後に開始する必要があります。 ステージAPPL_TOPは、本番データベースへの更新の適用のためと、本番APPL_TOPとの同期化のために使用されます。
前提条件と制限事項
ステージ・システムへのパッチの適用
ステージ・システムには、関連するパッチ・ドライバを適用するAutoPatchにより、Oracle Applicationsシステムに対する場合と同じようにパッチが適用されます。 このステップが実行されている間は、本番システムにパッチを適用しないようにします。 適用した場合、ステージ・システムの再作成が必要になります。
注意: パッチの適用の詳細は、『Oracle Applicationsメンテナンス・プロシージャ』を参照してください。
本番システムの更新
ステージ・システムに必要なパッチが適用された後は、本番システムを更新できます。 本番システム上のすべてのサービスを使用不可にした後、適用するパッチのデータベース・ドライバまたは統合ドライバ（「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を使用して、抽出された履歴データを本番データベースにインポートできます。
図 11-1 ステージAPPL_TOPを使用したパッチ適用
ステージAPPL_TOPと共有APPL_TOPの組合せ
ステージAPPL_TOPの方法と共有APPL_TOPの方法には、相互に異なる、補完的な利点があります。 必要に応じて、共有APPL_TOPシステムのステージAPPL_TOPを作成して、共有APPL_TOP（および分散AD）の利点をステージ・システムにも適用できます。
多くの配置では、大規模データベース・サーバーと、複数の小規模アプリケーション（中間）層システムを使用しています。 増加する低価格のLinuxベース・システムの配置においては、この構成が一般的になってきています。
ADでは常にジョブ・システムが稼働し、複数のワーカーがジョブを割り当てられています。 ジョブ・システムの情報はデータベースに格納されていて、ワーカーは関連する表の内容に基づいてそれぞれの割当てを受け取ります。 分散AD機能は、同じADセッションの複数のワーカーを複数のアプリケーション階層ノードで開始できるようにすることで、スケーラビリティ、パフォーマンスおよびリソース活用を向上させます。これにより、使用可能なリソースを使用して、割り当てられたジョブをより効率的に完了できます。
分散ADの要件
ADワーカーは、データベース・オブジェクトに加え、ファイル・システム・オブジェクトも作成および更新するので、共有APPL_TOPを使用して、これらのファイルが中央の単一の場所で作成されるようにする必要があります。
注意: 共有APPL_TOPの使用の概要は「共有APPL_TOP」を、詳細はOracle MetaLinkのNote 233428.1の「Sharing an APPL_TOP in Oracle Applications 11i」を参照してください。
分散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コントローラ・セッションの呼び出し元であるノードの名前を含めることをお薦めします。
OracleデータベースのNOLOGGING機能は、Oracle E-Business Suite リリース11iの特定の領域のパフォーマンスを向上させる場合に使用します。 たとえば、パッチのインストール時や、Business Intelligenceの要約データの構築時に使用します。
操作時にNOLOGGINGを使用するということは、データベースのREDOログの、行われた変更についての情報が不完全であることを意味します。NOLOGGING操作時に更新されたデータ・ブロックは無効として示されます。 その結果、（ホット・バックアップまたはコールド・バックアップの時点から）ある時点までのデータベースのリストアには、影響を受けたデータ・ブロックを最新の状態にし、リストアしたデータベースを使用可能にするための追加手順が必要となる場合があります。 この追加手順には、関連データファイルの新規バックアップ、または影響を受けたオブジェクトの削除および再構築が含まれます。 これは、スタンバイ・データベースを有効化する場合にも同様です。
注意: Oracle9i リリース2を使用している場合は、ロギングを常に実行するように強制できます。これにより、確実にすべてのデータ変更がデータベースのREDOログに書き込まれるので、リストアされたバックアップへの再作成やスタンバイ・データベースへの伝播が可能になります。 「FORCELOGGING」オプションの詳細は、『Oracle Data Guard概要および管理, リリース2（9.2）』を参照してください。
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操作が実行された場合にそれを識別し、バックアップ・データファイルを新規コピーでリフレッシュしておき、リストアが必要になったときに使用できるようにしておくことができます。
注意: NOLOGGING操作および関連タスクの詳細は、『Oracle Data Guard概要および管理』を参照してください。
Oracle E-Business Suiteのインストレーションに影響する重大な問題は、組織の活動能力にとってリスクとなります。 そのような問題として次のものが考えられます。
この項では、障害時リカバリの分野について概要を示します。これは、高可用性戦略における決定的な要素と考えられます。 障害時リカバリでは、重大な問題に際しても運転の続行を確保するために、データベースおよびその環境を保護する手段を講じることが必要です。 Oracleでは、セカンダリ（スタンバイ）・データベースの設定および保守に役立つOracle Data Guardなどの機能を提供しています。
E-Business Suite リリース11iでのスタンバイ環境の前提条件
プライマリ・サイト全体におよぶ災害から防御するためには、セカンダリ環境が、プライマリ環境と物理的に離れている必要があります。 このため、2つのデータ間で、最大のREDOログ・トラフィックに対しても十分な帯域幅（容量）のある、信頼できるネットワーク接続を維持することが必須になります。
セカンダリ（スタンバイ）環境設定におけるその他の主要要件は、次のとおりです。
その他の決定事項
使用するアーカイブ・モードを決定する必要があります。 Oracle 8.1.7では、セカンダリ・サイトに対し、「必須」または「オプション」のアーカイブ・モードを選択できます。 セカンダリ・サイトに対して「必須」アーカイブを使用した場合、アーカイブREDOログはすべて、プライマリ・サイトとセカンダリ・サイトの両方に同時に書き込まれます。
ただし、セカンダリ・サイトへのネットワーク接続が中断された場合は、セカンダリ・サイトでアーカイブできないので、プライマリ・データベースでは、REDOログのアーカイブが停止されます。 このため、ほとんどのサイトでは、セカンダリ・サイトに対しては「オプション」アーカイブが使用されます。その場合、追加の管理手順が必要になります。
Oracle 9.2では、必要な保護レベルを選択して、保護、可用性またはパフォーマンスを最大化できます。
最後に、コンカレント・マネージャのログ・ファイルおよび出力ファイルをセカンダリ・サイトにコピーする必要があるかどうかを決定する必要があります。 これは、障害発生後にセカンダリ・サイトでログ・ファイルを確認したりレポートを再実行できることが、これらのファイルを同期化するオーバーヘッドと比較して、より重要かどうかで判断します。
Oracle Data Guardの使用
Oracle Data Guardは、サイトの1つに障害が発生した場合の損失を防ぐために、1つのデータベースから他のデータベースへ変更を伝播するメカニズムを提供します。 Oracle Data Guardは、前述した要件を満たすための、セカンダリ環境の設定を支援します。
Oracle Data Guardの構成には主に、フィジカル・スタンバイとロジカル・スタンバイの2種類があります。 これらはともにプライマリ・データベースのREDOログを使用して、本番システムの変更をスタンバイに伝播します。
フィジカル・スタンバイは、権限ユーザーによる重大なデータ操作エラーなどの結果生じる、論理データの破壊による影響を防ぐためにも有益です。 プライマリのREDOログをセカンダリに適用する前にタイム・ラグを追加すると、ウィンドウが表示され、そこで問題を特定でき、問題に関連するREDOログがセカンダリに適用されるのを防ぐ処置を取ることができます。
Oracle Data GuardとNOLOGGING
Oracle Data Guardが本番データベースから生成されるREDOログに依存しているということは、Oracle E-Business Suiteでリソース集約的なタスクをより効率的に実行するためにNOLOGGING機能（前述）を使用する操作の場合には、重大な影響をもたらします。
パッチの適用時などにNOLOGGING機能が使用されると、REDOログには、スタンバイ・データベース上で対応する変更を行うために必要な十分なデータが含まれなくなります。 したがって、NOLOGGING操作後には、スタンバイを引き続き使用できるようにリフレッシュするための手段を講じる必要があります。
