| Oracle® Fusion Middlewareリポジトリ作成ユーティリティによるスキーマの作成 12c (12.2.1) E69931-01 |
|
 前 |
 次 |
Oracle Fusion Middlewareコンポーネントの多くは、データベース内にスキーマがないとインストールできません。このようなスキーマを作成してデータベースにロードするには、リポジトリ作成ユーティリティ(RCU)を使用します。
この章は、次の項で構成されています。
この項には、RCUのためのサポートされているプラットフォーム、動作確認されているデータベースおよびデータベース構成情報に関する重要な情報へのリンクが記載されています。RCUを入手して実行する前に、この情報をよく読んでください。
RCUを実行できるプラットフォームを確認するには、Oracle Fusion Middlewareのシステム要件と仕様ドキュメントのRCUのサポート対象プラットフォームに関する項を参照してください。
RCUで使用可能な認定されたデータベースのリストについては、Oracle Fusion Middlewareのサポートされるシステム構成ページにある、ご使用のリリースの動作保証に関するドキュメントを参照してください。
RCUを使用する前に、Oracle Fusion Middlewareのシステム要件と仕様ドキュメントのリポジトリ作成ユーティリティ(RCU)の要件に関する項を確認してください。
この項には、全般的およびコンポーネント固有のデータベース要件に関する重要な情報が記載されています。これらの要件は、RCUを実行する前に満たしておく必要があります。
すべてのスキーマがすべてのデータベースでサポートされているわけではないことに注意してください。この項に記載されている情報に慎重に目を通し、ご使用のFusion Middlewareコンポーネントに必要なスキーマをサポートする、動作保証されたデータベースを構成してください。
領域および構成に関する通常のデータベース要件に加え、IBM DB2データベースには、次の特殊な要件があります。
Linuxオペレーティング・システム上で動作するIBM DB2データベースには、スキーマ名の長さに制限があります。
IBM DB2データベースに作成されるスキーマごとに、データベース・オペレーティング・システム・ユーザーを1人作成する必要があります。
たとえば、RCUを使用してDEV_STBという名前のスキーマを作成した場合は、オペレーティング・システム・ユーザー名はdev_stb(すべて小文字)にする必要があります。
オペレーティング・システム・ユーザーは、次のコマンドをrootとして実行して作成できます(この例では、dev_stbというオペレーティング・システム・ユーザーを作成し、ユーザーに割り当てられたパスワードを割り当てます)。
/usr/sbin/useradd dev_stb -p password -d /scratch/dev_stb
次のコマンドをrootとして実行して、ユーザーのパスワード(たとえば、dev_stb)を設定できます。
passwd -u dev_stb passwd dev_stb
詳細は、使用しているシステムのドキュメントを参照してください。
IBM DB2データベースのRCU前提条件の詳細は、Oracle Fusion Middlewareのシステム要件と仕様ドキュメントを参照してください。
この項では、スキーマの作成および編成に関する重要な情報および概念を示します。
内容は次のとおりです。
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ユーザーを、この手順に使用できます。
製品ロード・フェーズを実行する前に、ユーザーに次の権限を付与する必要があります。
grant REGISTRYACCESS to user; grant STBROLE to user;
製品ロード・フェーズの完了後、各コンポーネントのステータスは、schema_version_registry内で、「ロード済」から「有効」に変更されます。
オプションの製品ロード後のフェーズ
このオプションの手順は、DBA権限が必要な製品ロード・スクリプトを実行する必要があるコンポーネントに対して必要です。
この手順を、次のコンポーネントで実行する必要があります。
監査サービス(IAU)
Oracle Enterprise Scheduler (ESS)
制限された権限を持つユーザーにシステム・ロード・オブジェクトを問い合せる権限を付与する場合は、システム・ロードを問い合せる前にそのユーザーに次を権限を付与する必要があります。
注意:
このユーザーは問合せのためにシステムに接続する場合に使用し、システム・ロード・フェーズから生成されたスクリプトは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; grant STBROLE to user;
データベース内のスキーマは、カスタム接頭辞を使用してグループ化できます。
注意:
IBM DB2データベースのカスタム接頭辞に関する重要情報については、Oracle Fusion Middlewareのシステム要件と仕様のドキュメントの、スキーマ接頭辞のサイズ制限に関する項を参照してください。
追加された接頭辞は、次に示すように、アンダースコア(_)によりスキーマ名と区別されます。
prefix_schemaname
接頭辞:
英数字のみ使用でき、スペースやその他の特殊文字は使用できません。
最初の文字は英字にする必要があります。
12文字以内に制限されています。
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に統合できます。
詳細は、「カスタム・アプリケーション・リポジトリを構成するためのリポジトリ作成ユーティリティの拡張」を参照してください。
