リリース12
E05390-02
目次
前へ
次へ
| Oracle Applications概要 リリース12 E05390-02 | 目次 | 前へ | 次へ |
Oracle E-Business Suiteリリース12i の多くの機能は、基礎となるOracleデータベース・テクノロジの拡張機能に基づいて構築されています。リリース12i では、様々なOracleデータベース機能を利用してパフォーマンスおよびスケーラビリティを最適化しています。
リリース12のOracle Applicationsで使用されているバージョン（Oracle Database 10g リリース2）には、データベースのパフォーマンスの追跡と、必要に応じた適切な訂正処理を可能にする高度な機能が数多く含まれています。
注意: 説明されたツールの機能および使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
自動ワークロード・リポジトリは、すべてのOracle 10g リリース2データベースに組み込まれた、データベース・パフォーマンス統計のリポジトリです。AWRは、一定の間隔で（通常、1時間に1回）パフォーマンス・データのスナップショットを自動生成し、問題検出とチューニングに使用するための統計を収集します。収集されたデータは、レポートおよびビューの両方に表示できます。
Oracle Enterprise Manager Database Controlを介してAWRにアクセスし、標準的なパフォーマンス期間を取得するベースラインを作成するためにスナップショットを管理したり設定を変更できます。このベースラインは、パフォーマンスの問題が報告された類似のワークロード期間との比較に使用できます。
自動データベース診断モニターは、Oracle Databaseによるパフォーマンスの診断と、特定された問題の解決方法の決定を可能にするツールです。ADDMでは定期的にAWRデータが解析され、パフォーマンスの問題の根本原因を検出して訂正するための推奨策が提供されます。AWRは履歴的なパフォーマンス・データのリポジトリであるため、ADDMを使用してイベント後のパフォーマンスの問題を解析し、問題を再現する時間とリソースを節約することができます（再現さえできない問題もあります）。
自動データベース診断モニターはデフォルトで有効になっており、その主インタフェースはOracle Enterprise Manager Database Controlです。
アクティブ・セッション履歴は、データベース・アクティビティの詳細履歴を取得して格納する方法です。アクティブなセッションのみが取得されるため、記録されるデータ量は実行される作業に直接比例します。V$ACTIVE_SESSION_HISTORYビューに現在のサンプル済アクティビティが記録されます。
AWRにより収集されるインスタンスレベルの統計とは異なり、ASHではセッション・レベルのデータが収集されます。特定の時間にのみ発生する可能性があるデータベースの一時的なパフォーマンスの問題を解析するには、ASHレポートを実行できます。たとえば、多くの場合、ADDMの解析期間のごくわずかでしか現れない短期間（2、3秒のみの継続時間）の問題を特定するためにASHを使用できます。
データベース・パフォーマンス機能には、最適化、リソース使用率、領域管理およびアクセス権限が含まれます。
リリース12で使用されるSQLは、コストベースの最適化のために幅広くチューニングされています。最もコストの低い（最も効率的な）SQL文の実行方法を計算する際、Oracle問合せオプティマイザでは、多くのファクタを評価して最も効率的なSQL文の実行方法を計算します。たとえば、オプティマイザはSQL文がアクセスする表や索引に関する統計情報を考慮し、使用可能なアクセス・パスについて判断します。 オプティマイザでは、SQL文のコメントに含まれる最適化提案であるヒントについても考慮します。
操作の一部として、オプティマイザでは、使用可能なアクセス・パスおよびすべてのヒントを基に、SQL文について考えられる実行プラン一式を作成します。次に、データ・ディクショナリの統計を基に、データ分散や、表、索引およびパーティションの記憶域特性を判断することで、各実行プランのコストを評価します。最後に、オプティマイザは実行プランのコストを比較し、最もコストの低い、つまり最適な実行特性を持つ実行プランを選択します。
バッチ処理など一部の処理では、リリース12はコストベースの最適化を使用して、SQL文でアクセスするすべての行の処理に最も効率的な方法を実現します。その他、フォームへのアクセスまたはデスクトップ・クライアントとの通信などの処理では、リリース12はコストベースの最適化を使用して、SQL文でアクセスする最初の行の処理に必要な応答時間を最短にします。
パーティション表など、リリース12で使用されるその他のいくつかのOracleデータベース・パフォーマンス機能にも、コストベースの問合せオプティマイザの使用が必要です。
注意: 最適化の詳細は、『Oracle Database概要』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
データベース・リソース・マネージャにより、システム管理者はデータベース・ノード上のリソースの処理を、幅広く管理できます。システム管理者はビジネス・ルールに基づいてサーバーのCPUを分散させることができ、優先度の最も高い活動では、十分なCPUリソースを常に確保できます。システム管理者は、たとえばシステム上の他のグループのユーザーの負荷やユーザー数に関係なく、営業時間中にオーダーを入力するユーザーに対してCPUリソースの40％を保証できます。
また、システム管理者は、データベース・リソース・マネージャを使用して、非効率的な非定型問合せの影響を制限できます。たとえば、データベースへの非定型問合せに対して、CPUリソースの5%という制限を設けることができます。
注意: 詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
パーティション化は、非常に大きな表や索引を、パーティションと呼ばれる小さな扱いやすい構成要素に分割することによってサポートします。目的のパーティションが定義された後、SQL文は元の表や索引のかわりにパーティションにアクセスできます。
注意: リリース12の標準Applications表のカスタム・パーティション化は、完全にサポートされています。
パーティション化によってアクセス時間が短縮され、特にパーティションは、大量の履歴データを頻繁に格納および分析するデータ・ウェアハウス・アプリケーションでは有効です。たとえば、データのコピーまたは削除に関連した操作は、パーティション表の使用により改善されています。パーティション表のすべての行を作成および削除すれば、選択した行を既存の表に挿入したり、表から削除するよりもはるかに素早く操作できます。数時間費やしていた可能性のある一部の操作を、現在では数秒で完了できます。
実装が異なると、データ配分およびアクセス・パスが異なるため、大部分のApplications表には、すべてのインストールに適用される自然パーティション化キーはありません。したがって、特定の要件にあわせて、表を論理的にパーティション化する必要があります。たとえば、period_nameおよびledger_idは、GL_BALANCES表のパーティション化に適した候補です。
重要: カスタム・パーティション化は注意して計画してください。カスタム・パーティション化の実装後、必要なパフォーマンス上の利点が実現されているかどうかをテストする必要があります。パーティション化が正しく計画されていない場合、パフォーマンスが低下する可能性があります。
複数ノード・システムにより、コンピューティング能力が強化されるだけでなく、需要の増加にあわせてマシンを容易に追加できます。また、複数ノード・システムでは、個々のコンポーネントに障害が発生した場合にリジリエンスが提供されます。
Oracle Real Application Clusters（Oracle RAC）では、相互接続された複数のコンピュータの処理能力を活用します。Oracleクラスタウェアと呼ばれるOracle RACソフトウェアおよびコンピュータの集合（クラスタとも呼ばれます）は、各コンポーネントの処理能力を活用して、堅牢かつ強力なコンピューティング環境を作成します。大きなタスクをサブタスクに分割し、複数ノードに分配することで、1つのノードでタスク全体が処理される場合に比べ、より高速かつ効率的に処理できます。またクラスタ処理では、追加ハードウェア資源の配置が容易になることで、より負荷の大きい作業や急速なユーザー数の増加にも対応できます。
Oracle RAC環境では、実行中のすべてのインスタンスが、共有データベースに対して同時にトランザクションを実行できます。Oracle RACは、各インスタンスによる共有データへのアクセスを調整し、データの一貫性とデータの整合性を提供します。開発者の視点からは、Oracle RACによりアプリケーションをスケール化し、増え続けるデータ処理の需要をアプリケーション・コードを変更せずに満たすことができます。
E-Business Suiteモジュールはすべて、Oracle RAC対応のOracleデータベースに対して正常に配置できます。パラレル・コンカレント処理（第1章「Oracle Applicationsアーキテクチャ」を参照）を使用することで、個々のアプリケーション層マシンのコンカレント・マネージャは、Oracle RACクラスタ内の別々のデータベース・サーバーに要求を送るよう構成できます。
自動ストレージ管理(ASM)では、Oracleデータベース・ファイルのストレージ専用のファイル・システムとボリューム・マネージャが提供されます。ストライプ化とミラー化の概念の強化により、パフォーマンスを最適化し、手動のI/Oチューニングの必要性をなくしています。
注意: スケーラビリティ・オプションの詳細は、OracleMetaLinkのNote 388577.1の「Oracle E-Business Suite Release 12 with 10g Release 2 Real Application Clusters and Automatic Storage Management」を参照してください。
最新のビジネス活動の詳細に対する需要を満たすため、Oracle Applicationsでは、こうした環境で一般的に必要となる問合せタイプの最適化に役立つ、Oracleデータベース機能が使用されています。
マテリアライズド・ビューは、データの要約、事前計算、レプリケートおよび配分に使用できるスキーマ・オブジェクトです。マテリアライズド・ビューを使用して、合計や平均などの集計データを事前計算して格納すると、大規模データベースに対する問合せの速度が著しく高まります。したがって、マテリアライズド・ビューにより、要約データについて多くの問合せを実行するDaily Business IntelligenceなどのOracle Applications製品のパフォーマンスが向上します。
問合せベースの最適化では、マテリアライズド・ビューを使用して、要求を満たすために問合せを使用できる時期を自動認識することで問合せのパフォーマンスを向上させることができます。オプティマイザは、マテリアライズド・ビューを使用するために要求を透過的に再書込みします。問合せは、基礎となるディテール表またはビューではなく、マテリアライズド・ビューに送られます。
分散環境ではマテリアライズド・ビューを使用して、リモート・サイトでデータをレプリケートできます。これにより、本来ならメイン・サイトからアクセスする必要があり、ネットワーク遅延が発生するデータに対してローカル・アクセスが可能になります。
