リリース11i（11.5.10）
部品番号: B15656-01
目次
前へ
次へ
| Oracle Applications概要 リリース11i（11.5.10） 部品番号: B15656-01 | 目次 | 前へ | 次へ |
ここでは、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スキーマにインストールされます。
次のオブジェクトはベース製品スキーマにインストールされます。
さらに、表および順序から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リリース11.5.10で標準として導入されている（旧リリースではオプションで使用可能な）新規表領域モデルについて説明しています。
注意: Oracle Applicationsリリース11iで必要なOracleデータベース・ブロック・サイズは8KBです。
Oracle9iデータベース・サーバーでは、常に次の表領域が使用可能である必要があります。
注意: 詳細は、『Oracle Database管理者ガイド』を参照してください。
インストールの際に、Rapid Installでは、表領域を様々なディスクに分散するオプションが提供されます。これにより、ディスク・ヘッドの競合が少なくなり、システム全体のパフォーマンスが向上します。 この他に、パフォーマンスをさらに向上させるため、多くの本番システムにおいて、オペレーティング・システム・レベルで高度なディスクおよびボリューム管理テクノロジが使用されます。
注意: 詳細は、『Oracle Applicationsのアップグレード』を参照してください。
従来のOracle Applications表領域モデルでは、製品の表および索引に対して独立した表領域が使用されていました。 生成される表領域には、製品の短縮名またはOracleスキーマ名に、データの場合はD、索引の場合はXを追加して名前が付けられていました。 たとえば、APDはOracle Payablesデータの表領域であり、APXはOracle Payablesの索引の表領域です。 これらはすべて、割当てサイズが均一なローカル管理表領域でした。
注意: ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
各製品について別々の表および索引表領域を使用することで、製品の保守が容易になり、データベース・パフォーマンスが向上しました。 ただし、製品数の増加に伴って、このモデルでは、数百もの製品表領域と、一時表領域、システム表領域およびロールバック（UNDO）表領域が必要となることも多くありました。
この従来の表領域モデルでは、データベースのサイジング・ファクタにより、Oracle Applications製品の表および索引などの動的オブジェクトのエクステント・サイズが設定されます。このファクタの値は、Applicationsデータベース・オブジェクトに対する一般的な見積成長率のパーセントです。 サイジング・ファクタは、後続のエクステント・サイズにのみ影響します。後続のエクステント・サイズは、NEXTデータベース・オブジェクト作成パラメータにより決定されます。 大部分のオブジェクトは、最初のエクステントは小さい値に、追加のエクステントは大きい値に定義されます。
格納パラメータにより、オブジェクトがディクショナリ管理表領域で作成されるときのオブジェクトに対する領域割当てが決定されます。 後述のように、ローカル管理表領域の方が単純な領域割当ての方法であり、大部分の格納パラメータはローカル管理表領域のコンテキストでは意味を持ちません。
Oracle Applicationsリリース11.5.10では、表領域管理用の新規インフラストラクチャ、Oracle Applications表領域モデル（OATM）が導入されています。
注意: この項の情報は、Oracle Applications表領域モデルに移行された旧リリースのApplicationsにも適用されます。 詳細は、Oracle MetaLinkのNote 248857.1を参照してください。
Oracle Applications表領域モデルは、システム表領域、UNDO表領域および一時表領域を保持している点では、従来のモデルと類似しています。 主な相違点は、OATM内のApplications製品が、それぞれの専用の表領域を持つのではなく、はるかに少ない数の表領域を共有するという点です。
Applicationsのスキーマ・オブジェクトは、主な2つの要素に基づいて共有表領域に割り当てられます。この2つの要素は、共有表領域に含まれるデータの型と、サイズ、期間、アクセス方法およびロック粒度などのI/O特性です。 たとえば、シード・データが含まれる表は、トランザクション・データが含まれる表とは異なる表領域に割り当てられます。
トランザクション表の索引は、トランザクション表索引専用の表領域に保持されます。 他の索引はすべて、実表と同じ表領域に保持されます。
Oracle Applications表領域モデルには、従来の表領域モデルに比べて様々な利点があります。これらの利点を次のリストに要約し、後で詳細に説明します。
Oracle Applications表領域モデルではローカル管理表領域が使用されるため、エクステント・サイズをシステムにより自動的に決定すること（自動割当て）も、またはすべてのエクステントを同じユーザー指定サイズに設定すること（均一）も可能です。 このようにエクステント管理タイプに選択の自由があるということは、ローカル管理表領域は、従来の表領域モデルで使用されるディクショナリ管理表領域よりも柔軟性が高いことを意味します。 ただし、ローカル管理表領域で均一なエクステントを使用する場合、エクステント・サイズは注意して選択する必要があります。サイズが小さすぎると、領域管理およびパフォーマンスに悪影響を及ぼす可能性があります。
ローカル管理表領域、つまりOATMを使用することのもう1つの利点は、自動セグメント領域管理が導入されることです。これは、セグメント内の領域をより単純かつ効率的に管理する方法であり、PCTUSED、FREELISTSおよびFREELIST GROUPSなどのスキーマ・オブジェクト格納パラメータの指定およびチューニングなど、従来の手動セグメント領域管理タスクの必要性がなくなります。 自動セグメント領域管理は自動チューニング式であるため、ユーザー数の増加を考慮に入れることができます。 Real Application Clusters（RAC）環境のもう1つの利点は、インスタンスに対する領域の動的親和性です。これにより、従来の空きリスト・グループの使用にともなう領域のハード・パーティション化を回避できます。
Oracle9iより前のOracleデータベース・サーバーのリリースでは、UNDO領域管理はロールバック・セグメントを使用して実行されていました。 わかりやすいように、この方法は現在では手動UNDO管理と呼ばれています。 その後継となる自動UNDO管理は、少数のUNDO表領域の使用に基づいており、手動UNDO管理で一般的に使用される多数の各種サイズのロールバック・セグメントとは対照的です。
| 表領域タイプ | 表領域の内容 |
| トランザクション表 | トランザクション・データが含まれる表。 |
| トランザクション索引 | トランザクション表の索引。 |
| 参照 | 参照および設定データと索引。 |
| インタフェース | インタフェースおよび一時データと索引。 |
| 要約 | マテリアライズド・ビューなどの要約管理オブジェクト、および要約情報を記録したその他のオブジェクト。 |
| ロギングなし | 要約管理に使用されないマテリアライズド・ビューおよび一時オブジェクト。 |
| アドバンスト・キューイング | アドバンスト・キューイング表および索引。 |
| メディア | テキスト、映像、音声、グラフィックおよび空間データなどのマルチメディア・オブジェクト。 |
| アーカイブ | アーカイブ済のパージ関連データが含まれる表。 |
| UNDO | 自動UNDO管理（AUM）表領域。 AUMが有効である場合、UNDOセグメントはロールバック・セグメントに相当します。 |
| 一時 | グローバル一時表、ソートおよびハッシュ結合用の一時表領域。 |
| システム | Oracleデータベースで使用されるシステム表領域。 |
11.5.10より前のApplicationsリリースからOracle Applications表領域モデルへの変換は、スタンドアロン操作として実行されます。 OATM移行ユーティリティでは、既存のディクショナリ管理表領域からローカル管理表領域にオブジェクトが移行され、ローカル管理表領域では、前述のように自動セグメント領域管理によって領域の使用が最適化されます。 以前の表領域からOATMへデータおよび索引セグメントを移行するプロセスの間、移行ユーティリティでは未使用の領域が再要求されます。 これは、列が頻繁に挿入、更新または削除される索引の場合など、断片化が発生したときに特に有効です。
移行ユーティリティは、対話型のメニューベースPerlプログラムであり、許容停止時間および変換に使用可能なディスク領域に応じて、すべてのスキーマを同時に移行したり、1つ以上の選択したスキーマを一度に移行できます。 段階的なスキーマごとの移行よりも、全スキーマを1回で包括的に移行する方が効率的です。 本番停止時間を最小限にするために、テストを1回以上実行して、必要となりそうな停止時間数を決定する必要があります。
OATM移行ユーティリティのアクションは、次の機能領域に分類されます。
「表領域移行ユーティリティ」メイン・メニューには、データベース・オブジェクトのOATMへの移行に使用される6つの必要な連続ステップが表示されます。 これらのステップは、次の3つのフェーズに分割できます。
ステップ2aは、Oracle Applicationsにユーザーがログオンしていない状態で実行する必要があります。 Oracle Applicationsをユーザーが再度使用できるようにする前に、ステップ2bおよび3aを完了する必要があります。
移行ユーティリティには、最終的なオプションである「カスタマイズ・ステップの実行」があり、これを使用して、表領域、表領域タイプおよびオブジェクト分類を必要に応じてカスタマイズします。 Oracle Applicationsの標準スキーマ（GL、PA、POおよびAPPSなど）で作成されたカスタム・データベース・オブジェクト（表、索引、マテリアライズド・ビューおよびマテリアライズド・ビュー・ログなど）は、オブジェクト・タイプに基づいて、デフォルトのトランザクション表領域または暗黙的ルールにより指示された表領域タイプに移動されます。 Oracle Applicationsに登録されたカスタム・スキーマで作成されたカスタム・データベース・オブジェクトは影響を受けません。ただし、これらのオブジェクトがOracle Applicationsの標準表領域にある場合、移行時に例外としてレポートされます。 ここで考えられる例としては、サード・パーティまたは他のOracle製品スキーマ（Oracle PortalまたはOracle Discovererなど）に存在するデータベース・オブジェクトがあります。
注意: カスタマイズ・ステップはすべて、他の移行ステップの開始前に実行する必要があります。
Oracle表領域移行ユーティリティでは、次のカスタマイズ・タスクがサポートされます。
警告: 移行ユーティリティでは、移行プロセスの戻し処理はサポートされません。 オブジェクトが旧表領域モデルから新規表領域モデルに移動された後は、元に戻すことはできません。 このプロセスをロールバックする唯一の方法は、バックアップからデータベースをリストアする方法です。 システムに重要な変更を加える場合と同様に、OATMへの移行を開始する前に全体バックアップをとる必要があります。
Oracle Applications表領域移行ユーティリティは、Oracle Applicationsの標準製品スキーマで、表、索引およびマテリアライズド・ビューなどのオブジェクトにOracle Applications表領域モデルを使用できるようにすることを主な目的として設計されています。 移行ユーティリティでは、カスタムまたはサード・パーティのアプリケーション・スキーマは、デフォルトで処理されません。 したがって、カスタム作成のデータベース・オブジェクトは、個別に管理するか、またはOracle Enterprise Managerなどのデータベース管理ツールを使用して管理する必要があります。
注意: OATMおよび移行ユーティリティの詳細は、Oracle MetaLinkのNote 269291.1を参照してください。
