| Oracle® Fusion Middleware Repository Creation Utilityによるスキーマの作成 12c (12.1.2) E47987-01 |
|
 前 |
 次 |
この章では、Repository Creation Utility (RCU)を使用する前に、理解しておく必要がある概念および機能について説明します。
Oracle Fusion Middlewareコンポーネントの多くは、データベース内にスキーマがないとインストールできません。このようなスキーマを作成してデータベースにロードするには、Repository Creation Utility (RCU)を使用します。
この章は、次の項で構成されています。
この項には、RCUのためのサポートされているプラットフォーム、動作確認されているデータベースおよびデータベース構成情報に関する重要な情報へのリンクが記載されています。RCUを入手して実行する前に、この情報をよく読んでください。
RCUを実行できるプラットフォームを確認するには、Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントのRCUのサポート対象プラットフォームに関する説明を参照してください。
RCUで使用可能な認定されたデータベースのリストについては、「Oracle Fusion Middleware Supported System Configurations」ページにある、ご使用のリリースの動作保証に関するドキュメントを参照してください。
RCUを使用する前に、Oracle Fusion Middlewareのシステム要件と仕様についてのドキュメントのRepository Creation Utility (RCU)の要件に関する説明を確認してください。
この項には、全般的およびコンポーネント固有のデータベース要件に関する重要な情報が記載されています。これらの要件は、RCUを実行する前に満たしておく必要があります。
すべてのスキーマがすべてのデータベースでサポートされているわけではないことに注意してください。この項に記載されている情報に慎重に目を通し、ご使用のFusion Middlewareコンポーネントに必要なスキーマをサポートする、動作保証されたデータベースを構成してください。
領域および構成に関する通常のデータベース要件に加え、IBM DB2データベースには、次の特殊な要件があります。
Linuxオペレーティング・システム上で動作するIBM DB2データベースには、スキーマ名の長さに制限があります。
IBM DB2データベースに作成されるスキーマごとに、データベース・オペレーティング・システム・ユーザーを1人作成する必要があります。
詳細は、Oracle Fusion Middlewareのシステム要件と仕様についてのドキュメントの、IBM DB2データベースのRCU前提条件に関する説明を参照してください。
この項では、スキーマの作成および編成に関する重要な情報および概念を示します。
次のトピックを取り扱います:
RCUでのスキーマ作成は複数のフェーズで実行されますが、その各フェーズでデータベースに対して異なるレベルのアクセス権限が必要になります。
システム・ロード・フェーズ
システム・ロード・フェーズの間、RCUは必要な表領域とスキーマ、およびschema_version_registry(まだ存在しない場合)を作成します。schema_version_registryでは各コンポーネントに1つのエントリが作成され、このエントリはschema_version_registry表で適切なアクセス権が与えられ、ステータスはLOADEDに設定されます。
これらのアクションは、SYSまたはSYSDBA権限を持つユーザーが実行する必要があり、RCUの実行時に「データベース接続の詳細」画面で認証資格証明を提供する必要があります。
必要な権限がない場合は、「リポジトリの作成」画面で「システム・ロードに対するスクリプトの準備」を選択できます。これによって、RCUが選択されたコンポーネントに対してアクションを実行した場合にコールされるSQL文およびブロックと同じものを、すべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
システム・ロード・フェーズが完了した後は、どのユーザーでもRCUを再度実行して、製品ロード・フェーズを実行することでスキーマ作成を完了できます。
|
注意: システム・ロード用のスクリプトを生成する必要がある場合は、OracleおよびOracle EBRデータベースでのみスキーマを作成できます(このシステム・ロード・スクリプトはその他のデータベースではサポートされません)。 完全なSYSまたはSYSDBA権限でシステム・ロードを実行する場合は、動作保証されたデータベースであれば、どれにでもスキーマを作成できます。 |
製品ロード・フェーズ
製品ロード・フェーズ中に、RCUはスキーマ内のプロシージャ、ファンクション、表、索引などのオブジェクトを作成し、DBAアクセスが不要なアクションを実行します。DBA以外の任意のユーザーまたはREGISTRYOWNERユーザーを、この手順に使用できます。
オプションの製品ロード後のフェーズ
このオプションの手順は、DBA権限が必要な製品ロード・スクリプトを実行する必要があるコンポーネントに対して必要です。
ユーザーにシステム・ロード・フェーズを実行可能な制限された権限を付与する場合は、システム・ロードを実行する前にそのユーザーに次を付与する必要があります。
|
注意: このユーザーは問合せのためにシステムに接続する場合に使用し、システム・ロード・フェーズから生成されたスクリプトはDBA権限を持つユーザーが実行する必要があります。 |
grant select_catalog_role to user; grant select any dictionary to user; grant create session to user; grant select on schema_version_registry to user;
|
注意: 最後のコマンドを実行すると「表またはビューが存在しません。」というエラー・メッセージが表示される場合がありますが、これは無視してもかまいません。 |
システム・ロードの実行後に、同じユーザーに次を付与して、データ・ロードを実行できるようにします。
grant REGISTRYACCESS to user;
データベース内のスキーマは、カスタム接頭辞を使用してグループ化できます。
|
注意: IBM DB2データベースのカスタム接頭辞に関する重要情報については、Oracle Fusion Middlewareのシステム要件と仕様についてのドキュメントの、スキーマ接頭辞のサイズ制限に関する説明を参照してください。 |
追加された接頭辞は、次に示すように、アンダースコア(_)によりスキーマ名と区別されます。
prefix_schemaname
RCUで使用されるデフォルトの接頭辞はDEVです。DEVがすでに使用されている場合のデフォルトはDEV1、DEV1が使用されている場合はDEV2になります。以降についても同様です。接頭辞は、スキーマの論理グループを作成および編成するために使用されます。たとえば、TEST_MDSというテスト・バージョンのメタデータ・サービス(スキーマ名MDS)を作成しておき、本番バージョンの準備が整ったときに、PROD_MDSという2番目のバージョンのスキーマを作成することができます。TEST_MDSとPROD_MDSは両方とも、同じデータベースに配置することも、別々のデータベースに配置することも可能です。
1つのデータベース内で使用できる接頭辞は、スキーマごとに1つのみです。たとえば、DEV_MDSというバージョンのメタデータ・サービス・スキーマが存在する場合は、別のバージョンのメタデータ・サービス・スキーマを作成するためにDEV接頭辞を再度使用すること(DEV_MDS2など)はできません。
同一の接頭辞を使用して別のバージョンのスキーマを作成する場合は、まず既存のスキーマを削除してから、再度スキーマを作成する必要があります。
接頭辞とスキーマとのマッピングは、schema_version_registryで管理されます。
サービス表スキーマは、RCUが実行されるたびに自動的にインストールされる特別なスキーマです。サービス表には、基本的なスキーマ構成情報が格納され(スキーマ接頭辞、パスワードなど)、これにOracle Fusion Middlewareコンポーネントがドメイン作成中にアクセスし、使用することができます。
たとえば、構成ウィザードには、RCUの実行時にサービス表に格納されたデータを使用するように構成できる画面があります。サービス表のスキーマ資格証明を提供した後は、サービス表からのデータが使用されて画面のフィールドに値が入れられるため、データを手動で入力する必要はありません。
サービス表を作成すると、サービス表はOracle Fusion Middlewareコンポーネントをワイヤリングするために使用されます。詳細は、『Oracle Fusion Middlewareの管理』のコンポーネント間のワイヤリングに関する説明を参照してください。
この項では、特定の環境に合わせてスキーマをグループ化し、分散できる方法を理解するうえで役立つ例を示します。次のような例が用意されています。
図1-1に、単一のWebLogicドメインで使用される単一データベース内のスキーマ・セットを示します。これは、DEV接頭辞を使用するすべてのスキーマがグループ化され、この単一のWebLogicドメインによって使用される、簡単なシナリオです。
図1-2に、単一のWebLogicドメインで使用される、複数データベースに分散する単一のスキーマ・セットを示します。
同じスキーマ接頭辞(この場合はDEV)を使用すると、これらの関連するスキーマをグループ化することができます(複数のデータベースにまたがる場合も)。
図1-3に、単一データベース上のスキーマを、複数のドメイン用にグループ化する方法を示します。
この例では、1つ目のスキーマ・セット(WebLogicドメイン1用)にDEV1を使用し、2つ目のスキーマ・セット(WebLogicドメイン2用)にDEV2を使用して、接頭辞をグループ化しています。
複数のドメイン間で1つのスキーマ・セットを共有することはできず、各ドメインが専用のスキーマ・セットを持つ必要があります。
図1-4に、複数のデータベース上のスキーマを、複数のWebLogicドメインで使用するように編成する1つの方法を示します。
このシナリオでは、同じホスト上の別々のドメインで、名前および接頭辞(DEV)が同じ複数のスキーマを使用できますが、これは、これらのスキーマが異なるデータベース上に存在するためです。
RCUは、XML DTDによる拡張性を備えています。このようなDTDを使用することによって、コンポーネント所有者は、定義されているDTDに応じた構成ファイルを提供することで、そのコンポーネントと前提条件をRCUに統合できます。
詳細は、付録C「カスタム・アプリケーション・リポジトリを構成するためのRepository Creation Utilityの拡張」を参照してください。
JavaAccess Bridgeを使用すると、JAWSスクリーン・リーダーなどのアシスティブ・テクノロジを使用して、Windowsプラットフォームで実行されているJavaアプリケーションを読み取ることができます。アシスティブ・テクノロジでは、Oracle Universal InstallerやOracle Enterprise ManagerなどのJavaベースのインタフェースを読み取ることができます。
Java Access Bridgeをインストールするには:
次のURLからJava Access Bridgeをダウンロードします。
http://java.sun.com/javase/technologies/accessibility/accessbridge/
Java Access Bridgeをインストールします。
インストールの場所からaccess-bridge.jarとjaccess-1_4.jarをjre\lib\extディレクトリにコピーします。
インストール場所からjre\binディレクトリへ、WindowsAccessBridge.dllファイル、JavaAccessBridge.dllファイルおよびJAWTAccessBridge.dllファイルをコピーします。
jre\libディレクトリへaccessibility.propertiesファイルをコピーします。
インストールの完了後、Java Access Bridgeを使用するようにRCUを構成するには、インストールしたJava Access Bridgeファイルを指すようにシステム変数ORACLE_OEM_CLASSPATHを設定します。
コントロール パネルから「システムのプロパティ」を表示します。
「詳細設定」タブを選択します。
システム環境変数リストで「新規」ボタンをクリックします。「新しいシステム変数」ダイアログが表示されます。
「変数名」フィールドに、ORACLE_OEM_CLASSPATHと入力します。
「変数値」フィールドに、access-bridge.jarおよびjaccess-1_4.jarへのフルパスを入力します。
セミコロンを使用して2つのパスを区切ります。引用符や空白は使用しないでください。
「OK」をクリックします。
