リリース12
E05390-02
目次
前へ
次へ
| Oracle Applications概要 リリース12 E05390-02 | 目次 | 前へ | 次へ |
ここでは、Oracle Applicationsデータ・モデルについて説明します。基本的なApplicationsデータ・モデルと、これに対応するOracleデータベース・サーバーの要件について説明しています。
特定のOracleデータベースに、Oracle E-Business Suiteの単一のインストールに関連付けられたオブジェクトを格納できます。一般に、製品データ・オブジェクトは関連付けられた製品スキーマに格納されるのに対し、製品コード・オブジェクトはすべてAPPSスキーマに格納されます。
Oracle E-Business Suiteの各製品には、スキーマ名およびパスワードの両方に製品略称を使用した、デフォルトOracleユーザーIDがあります。たとえば、Oracle General LedgerのデフォルトのOracleユーザーIDおよびパスワードは、GL/GLです。
重要: セキュリティ対策として、インストール後ただちにパスワードを変更してください。ただし、デフォルト・ユーザーIDは変更しないことをお薦めします。
製品のスキーマにより、順序、表および索引などの製品のデータ・オブジェクトの所有権が決定されます。同じスキーマの下に2つの製品がインストールされている場合、このスキーマでは両方の製品のデータ・オブジェクトが所有されます。
製品のデータ・オブジェクトはそれぞれの製品独自のスキーマ（GLスキーマなど）に作成されますが、ユーザーがAPPSスキーマを介してすべてのデータ・オブジェクトにアクセスするため、APPSスキーマとベース製品スキーマ間には、適切な権限付与およびシノニムが必要です。
APPSスキーマには、Oracle E-Business Suiteデータ・モデル全体へのアクセス権限があります。これは、データベース全体へのアクセス権限を持つSYSTEMスキーマに類似しています。Oracle Applications職責がAPPSスキーマに接続され、環境変数FNDNAMがAPPSスキーマの名称に設定されます。
製品のすべてのデータ・オブジェクトは、ベース製品スキーマと呼ばれるその製品のスキーマが所有します。APPSと呼ばれる1つのスキーマがOracle E-Business Suiteのすべてのコード・オブジェクトを所有し、すべてのデータ・オブジェクトにアクセス可能です。製品インストール・グループごとにAPPSスキーマが1つ存在します。
次のコード・オブジェクトはAPPSスキーマにインストールされます。
パッケージ
プロシージャ
ファンクション
トリガー
ビュー
マテリアライズド・ビュー
Javaクラス
キュー
次のオブジェクトはベース製品スキーマにインストールされます。
表
順序
索引
制約
キュー
さらに、表および順序からAPPSスキーマへの権限付与があり、APPSスキーマからこれらのオブジェクトに対するシノニムがあります。
図3-1 APPSスキーマおよびベース製品スキーマ
APPSスキーマにより、製品間の権限付与およびシノニムの必要性がなくなり、インストール、アップグレードおよびパッチの信頼性が高まり、所要時間が短縮されます。すべてのオブジェクトにアクセス可能な1つのスキーマを利用すると、製品間の依存がなくなり、クモの巣状ではなくハブ・アンド・スポーク・アクセス・モデルが作成されます。
場合によっては、Oracle Applicationsデータに対して制限付きまたは読取り専用アクセス権限を持つスキーマを作成できます。
警告: APPSスキーマは、すべてのOracle Applicationsオブジェクトに対してすべての権限を持つため、ユーザーにこのスキーマへの直接アクセス権限を付与しないでください。
ベース製品スキーマのオブジェクトに対するアクセス権限をユーザー・スキーマに付与する必要があります。
注意: 基礎となるオブジェクトが削除および再作成された場合、アクセス権限を再付与する必要があります。
ビューの中にはパッケージまたはファンクションにアクセスするものがありますが、パッケージまたはファンクションから戻される値は、正しく設定された環境に応じて異なります。サインオン画面でOracle Applicationsにアクセスしたり、Oracle ReportsまたはSQLスクリプトでコンカレント処理を使用する際に、環境が自動的に初期化されます。
したがって、スキーマに直接接続した場合、ビューにより戻される行は、Oracle Applications環境で実行している場合に戻される行とは異なる場合があります。たとえば、ビューがプロファイル・オプションを参照する場合があり、SQL*Plusからアクセスすると、特定のApplicationsユーザーの設定ではなく、プロファイル・オプションのサイト値が使用されます。
この項では、Oracle Applicationsの領域管理のニーズにあわせたOracleデータベースの設定方法について説明します。表領域に関する説明では、必要な基本表領域の概要を説明し、次にApplications製品のサポートに使用される従来の表領域構造を説明し、最後にOracle Applicationsリリース12で標準として使用されている表領域モデルについて説明しています。
重要: Oracle Applicationsリリース12で必要なOracleデータベース・ブロック・サイズは8KBです。他のブロック・サイズが使用されることはありません。
Oracle 10g リリース2データベース・サーバーでは、常に次の表領域が使用可能である必要があります。
システム表領域: この表領域には、SYSアカウントが所有するデータ・ディクショナリ表が保持されます。この表領域は、データベースのインストール時に作成されます。
UNDO表領域: この表領域には、データベース変更の追跡に使用されるUNDO（ロールバック）情報が、これらの変更がコミットされるか元に戻される（ロールバックされる）まで保持されます。
一時表領域: 一時表領域は、処理中のデータのソートに使用されます。一般にTEMPと呼ばれる1つの一時表領域を、すべてのOracle Applications製品用に使用できます。あるいは、必要に応じて個々の製品用に独立した一時表領域を作成できます。ユーザーはAPPSスキーマを介してApplicationsオブジェクトにアクセスするので、APPSスキーマの一時表領域（最初はOracle Application Object Libraryの一時表領域と同じ）は、すべての製品で使用されます。
従来のOracle Applications表領域モデルでは、製品の表および索引に対して独立した表領域が使用されていました。生成される表領域には、製品の短縮名またはOracleスキーマ名に、データの場合はD、索引の場合はXを追加して名前が付けられていました。たとえば、APDはOracle Payablesデータの表領域であり、APXはOracle Payablesの索引の表領域です。
注意: 表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
各製品について別々の表および索引表領域を使用することで、製品の保守が容易になり、データベース・パフォーマンスが向上しました。ただし、製品数の増加に伴い、このモデルでは、すぐに数百もの製品表領域と、システム表領域、UNDO（ロールバック）表領域および一時表領域が必要となることもありました。
さらに、従来の表領域モデルでは、データベースのサイジング・ファクタを使用してOracle Applications製品の表および索引のエクステント・サイズが設定されました。このファクタの値は、Applicationsデータベース・オブジェクトに対する一般的な見積成長率のパーセントです。サイジング・ファクタは、後続のエクステント・サイズにのみ影響します。後続のエクステント・サイズは、NEXTデータベース・オブジェクト作成パラメータにより決定されます。大部分のオブジェクトは、最初のエクステントは小さい値に、追加のエクステントは大きい値に定義されます。
インストールの際に、Rapid Installでは、表領域を様々なディスクに分散するオプションが提供されます。これにより、ディスク・ヘッドの競合が少なくなり、システム全体のパフォーマンスが向上します。この他に、パフォーマンスをさらに向上させるため、多くの本番システムにおいて、オペレーティング・システム・レベルで高度なディスクおよびボリューム管理テクノロジが使用されます。
Oracle Applicationsリリース12では、表領域管理用の最新インフラストラクチャであるOracle Applications表領域モデル（OATM）が標準として使用されています。Oracle Applications表領域モデルは、システム表領域、UNDO表領域および一時表領域を保持している点では、従来のモデルと類似しています。主な相違点は、OATM環境内のApplications製品が、それぞれ専用の表領域を持つのではなく、はるかに少ない数の表領域を共有するという点です。
Applicationsのスキーマ・オブジェクトは、主な2つの要素に基づいて共有表領域に割り当てられます。この2つの要素は、共有表領域に含まれるデータの型と、サイズ、期間、アクセス方法およびロック粒度などのI/O特性です。たとえば、シード・データが含まれる表は、トランザクション・データが含まれる表とは別の表領域に割り当てられます。さらに、ほとんどの索引が実表と同じ表領域に保持されるのに対して、トランザクション表の索引は専用の単一表領域に保持されます。
Oracle Applications表領域モデルには様々な利点があります。これらの利点を次のリストに要約し、後で詳細に説明します。
従来のモデルにくらべてはるかに少ない表領域が使用され、保守およびリカバリが簡略化されます。
Oracle Real Applications Cluster（Oracle RAC）など、各表領域に独自のRAWデバイスが必要な環境で使用できる、限られた数のRAWデバイスを最大限に活用します。
ローカル管理表領域を利用するため、未使用の領域に対してより厳密な管理が可能となり、断片化が少なくなります。
自動セグメント領域管理が使用されるため、手動領域管理タスクの必要性がなくなります。
従来のモデルにくらべてブロックパッキングが増加し、全体的なバッファ取得数が減るため、ランタイム・パフォーマンスが向上します。
ワイド・ディスク・ストライプ構成の有用性が最大になります。
Oracle Applications表領域モデルではローカル管理表領域が使用されるため、エクステント・サイズを自動的に決定すること（自動割当て）も、すべてのエクステントを同じユーザー指定サイズに設定すること（均一）も可能です。このようにエクステント管理タイプに選択の自由があるということは、ローカル管理表領域は、従来の表領域モデルで使用されるディクショナリ管理表領域よりも柔軟性が高いことを意味します。ただし、ローカル管理表領域で均一なエクステントを使用する場合、エクステント・サイズは注意して選択する必要があります。サイズが小さすぎると、領域管理およびパフォーマンスに悪影響を及ぼす可能性があります。
ローカル管理表領域つまりOATM使用のもう1つの利点は、セグメント内の領域をより簡単に効率よく管理する方法である自動セグメント領域管理が導入されることです。この方法ではより多くの領域が必要になる可能性がありますが、PCTUSEDなどのスキーマ・オブジェクト格納パラメータの指定やチューニングなど、従来の手動セグメント領域管理タスクの必要性がなくなります。このパラメータおよび関連する格納パラメータは、ディクショナリ管理表領域内のオブジェクト用の領域割当ての決定にのみ使用され、ローカル管理表領域のコンテキストでは意味がありません。
自動セグメント領域管理は自動チューニング式であるため、ユーザー数の増加を考慮に入れることができます。Oracle Real Applications Cluster（Oracle RAC）環境のもう1つの利点は、インスタンスに対する領域の動的親和性です。これにより、従来の空きリスト・グループの使用に伴う領域のハード・パーティション化を回避できます。
Oracle9iより前のOracleデータベース・サーバーのリリースでは、UNDO領域管理はロールバック・セグメントを使用して実行されていました。わかりやすいように、この方法は現在では手動UNDO管理と呼ばれています。その後継となる自動UNDO管理は、少数のUNDO表領域の使用に基づいており、手動UNDO管理で一般的に使用される様々なサイズの数多くのロールバック・セグメントとは対照的です。
