リリース11i（11.5.10）
部品番号: B15656-01
目次
前へ
次へ
| Oracle Applications概要 リリース11i（11.5.10） 部品番号: B15656-01 | 目次 | 前へ | 次へ |
Oracle E-Business Suiteリリース11iの多くの機能は、基礎となるOracleデータベース・テクノロジの拡張機能に基づいて構築されています。 リリース11iでは、様々なOracleデータベース機能により、パフォーマンス、スケーラビリティおよびビジネス・インテリジェンス能力を最適化しています。
データベース・パフォーマンス機能には、最適化、リソース使用率、領域管理およびアクセス権限が含まれます。
Oracleオプティマイザは、SQL文を実行するための最も効率のよい方法を計算するため、多くのファクタを評価します。 Oracleオプティマイザは、SQL文の実行に、ルールベースまたはコストベースのどちらかのアプローチを使用できます。 ルールベースの最適化がApplicationsの旧リリースで使用されていましたが、リリース11iで使用されるSQLは、コストベースの最適化に幅広くチューニングされているため、リリース11iでは、オプティマイザによってコストベースの最適化（CBO）を使用しています。
オプティマイザは、CBOを使用して、SQL文がアクセスする表や索引に関する統計情報を考慮し、使用可能なアクセス・パスについて判断します。 CBOでは、SQL文のコメントに含まれる最適化提案であるヒントについても検討します。
最初に、オプティマイザは使用可能なアクセス・パスおよびヒントに基づき、SQL文について考えられる実行プラン一式を作成します。 次にオプティマイザは、データ・ディクショナリの統計に基づいて、データ配分や、表、索引およびパーティションの記憶特性を判断することで、各実行プランのコストを評価します。 オプティマイザは実行プランのコストを比較し、最もコストの低い、つまり最適な実行特性を持つ実行プランを選択します。
バッチ処理などの一部の処理では、リリース11iはCBOを使用して、SQL文でアクセスするすべての行の処理に最も効率的な方法を実現します。 フォームへのアクセスまたはデスクトップ・クライアントとの通信など、その他の処理では、リリース11iはCBOを使用して、SQL文でアクセスする最初の行の処理に必要な応答時間を最短にします。
パーティション表などのリリース11iで使用されるその他の複数のOracleデータベース・パフォーマンス強化にも、コストベース・オプティマイザの使用が必要です。
注意: 詳細は、『Oracle9i Concepts』の「The Optimizer Overview」、『Oracle9i Database Performance Tuning Guide and Reference』の「Introduction to the Optimizer」、『Oracle Applicationsシステム管理者ガイド』の「Oracle Applicationsとコスト・ベース最適化」を参照してください。
データベース・リソース・マネージャにより、システム管理者はデータベース・ノード上のリソースの処理を、幅広く管理できます。 システム管理者はビジネス・ルールに基づいてサーバーのCPUを分散させることができ、優先度の最も高い活動では、十分なCPUリソースを常に確保できます。 システム管理者は、たとえばシステム上の他のグループのユーザーの負荷やユーザー数に関係なく、営業時間中にオーダーを入力するユーザーに対してCPUリソースの40％を保証できます。
また、システム管理者は、データベース・リソース・マネージャを使用して、非効率的な非定型問合せの影響を制限できます。 たとえば、データベースへの非定型問合せに対して、CPUリソースの5%という制限を設けることができます。
パーティション化は、非常に大きな表や索引を、パーティションと呼ばれる小さな扱いやすい構成要素に分割することによってサポートします。 目的のパーティションが定義されると、SQL文は元の表または索引ではなくパーティションへのアクセスが可能になります。
注意: リリース11iの標準Applications表のカスタム・パーティション化は、完全にサポートされています。
パーティション化によってアクセス時間が短縮され、特にパーティションは、大量の履歴データを頻繁に格納および分析するデータ・ウェアハウス・アプリケーションでは有効です。 たとえば、データのコピーまたは削除に関連した操作は、パーティション表の使用により改善されています。 パーティション表のすべての行を作成および削除すれば、選択した行を既存の表に挿入したり、表から削除するよりもはるかに素早く操作できます。 数時間費やしていた可能性のある一部の操作を、現在では数秒で完了できます。
実装が異なると、データ配分およびアクセス・パスが異なるため、大部分のApplications表には、すべてのインストレーションに適用される自然パーティション化キーはありません。 したがって、特定の要件にあわせて、表を論理的にパーティション化する必要があります。 たとえば、period_nameおよびset_of_books_idは、GL_BALANCES表のパーティション化に適した候補です。
注意: カスタム・パーティション化は注意して計画してください。 カスタム・パーティション化の実装後、必要なパフォーマンス上の利点が実現されているかどうかをテストする必要があります。パーティション化が正しく計画されていない場合、パフォーマンスが低下する可能性があります。
旧リリースでは、複数報告通貨（MRC）または複数会計帳簿アーキテクチャ（MSOBA）を使用している場合、Oracle Applicationsパッケージの複数のコピーがデータベース内に存在する必要がありました。 これによって、より多くの領域が消費されるだけでなく、保守に余分な時間と作業が必要でした。
Applicationsリリース11iでは、Oracleデータベース・サーバーの実行者権限機能を使用すると、多くの場合、パッケージをAPPSスキーマでのみインストールすることが必要になります。 PL/SQLルーチンは、実行者権限により、APPSスキーマ内のパッケージにアクセスします。
注意: Oracle Applicationsの最近のリリースでは、MRCアーキテクチャに大幅な変更が加えられており、リリース11.5.10にはMRCスキーマはすでに存在しません。詳細は「複数報告通貨」を参照してください。
最新のビジネス活動の詳細に対する需要を満たすため、Oracle Applicationsでは、こうした環境で一般的に必要となる問合せタイプの最適化に役立つ、Oracleデータベース機能が使用されています。
マテリアライズド・ビューは、データの要約、事前計算、レプリケートおよび配分に使用できるスキーマ・オブジェクトです。 マテリアライズド・ビューを使用して、合計や平均などの集計データを事前計算して格納すると、大規模データベースに対する問合せの速度が著しく高まります。 したがって、マテリアライズド・ビューにより、要約データについて多くの問合せを実行するDaily Business IntelligenceなどのOracle Applications製品のパフォーマンスが向上します。
コストベースの最適化では、マテリアライズド・ビューにより、要求に対応するためにいつ問合せを使用できるかを自動的に認識し、問合せのパフォーマンスを向上させることができます。オプティマイザは、マテリアライズド・ビューを使用するために要求を透過的に再書込みします。 問合せは、基礎となるディテール表またはビューではなく、マテリアライズド・ビューに送られます。
分散環境ではマテリアライズド・ビューを使用して、リモート・サイトでデータをレプリケートできます。これにより、本来ならメイン・サイトからアクセスする必要があり、ネットワーク遅延が発生するデータに対してローカル・アクセスが可能になります。
複数ノード・システムにより、コンピューティング能力が強化されるだけでなく、需要の増加にあわせてマシンを容易に追加できます。 また、複数ノード・システムでは、個々のコンポーネントに障害が発生した場合にリジリエンスが提供されます。
Real Application Clusters（RAC）では、相互接続された複数のコンピュータの処理能力を活用します。 クラスタとして知られるRACのソフトウェアおよびコンピュータの集合は、各コンポーネントの処理能力を活用して、堅牢かつ強力なコンピューティング環境を作成します。 大きなタスクをサブタスクに分割し、複数ノードに分配することで、1つのノードでタスク全体が処理される場合に比べ、より高速かつ効率的に処理できます。 またクラスタ処理では、追加ハードウェア資源の配置が容易になることで、より負荷の大きい作業や急速なユーザー数の増加にも対応できます。
RAC環境では、実行中のすべてのインスタンスが、共有データベースに対して同時にトランザクションを実行できます。 RACは、各インスタンスによる共有データへのアクセスを調整し、データの一貫性とデータの整合性を提供します。 開発者の視点からは、RACによりアプリケーションをスケール化して、アプリケーション・コードを変更せずに増え続けるデータ処理の需要を満たすことができます。
E-Business Suiteモジュールはすべて、RAC対応のOracleデータベースに対して正常に配置できます。 パラレル・コンカレント処理（「Applicationsアーキテクチャ」を参照）を使用することで、個々のアプリケーション層マシンのコンカレント・マネージャは、RACクラスタ内の別々のデータベース・サーバーに要求を送るよう構成できます。
注意: AutoConfig構成管理ツール（「AutoConfig」を参照）では、リリース11.5.10以降、RAC環境がサポートされています。
