次の各トピックでは、リポジトリ作成ユーティリティ(RCU)を使用する前に、理解しておく必要がある概念および機能について説明します。
動作保証要件およびシステム要件についてのドキュメントを使用して、RCUのサポート対象プラットフォームおよび動作保証済データベースに関する重要な情報と、データベース構成情報について調べてください。
RCUを入手して実行する前に、この情報をよく読んでください。
システム要件についてのドキュメントを使用して、RCUの実行が可能なサポート対象プラットフォームを確認してください。
RCUを実行できるプラットフォームを確認するには、Oracle Fusion Middlewareのシステム要件と仕様ドキュメントのRCUのサポート対象プラットフォームに関する項を参照してください。
スキーマをインストールできるデータベースをまだ用意していない場合は、動作保証済のデータベースをインストールして構成する必要があります。
RCUで使用可能な動作保証されているデータベースのリストについては、Oracle Fusion Middlewareでサポートされているシステム構成のページにある、使用しているリリースのOracle Fusion Middleware 12cのシステム要件とサポート対象プラットフォームに関する動作保証ドキュメントを参照してください。
RCUを実行する前に満たしておく必要のある、一般的なデータベース要件とコンポーネント固有のデータベース要件について確認してください。
RCUを使用する前に、Oracle Fusion Middlewareのシステム要件と仕様についてのドキュメントのリポジトリ作成ユーティリティの要件に関する説明を確認してください。
すべてのスキーマがすべてのデータベースでサポートされているわけではないことに注意してください。この項に記載されている情報に慎重に目を通し、ご使用のFusion Middlewareコンポーネントに必要なスキーマをサポートする、動作保証されたデータベースを構成してください。
IBM DB2データベースでコンポーネント・スキーマを作成する際に考慮する追加要件があります。
領域および構成に関する通常のデータベース要件に加え、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
詳細は、使用しているシステムのドキュメントを参照してください。
スキーマを作成する前に、スキーマの作成と編成に関する概念について理解しておきます。
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権限を必要とするscript_postDataLoad.sql
スクリプトを生成するコンポーネントにのみ必要です。製品ロード・フェーズの完了後、SYSまたはSYSDBA権限を持つユーザーがscript_postDataLoad.sql
スクリプトを実行する必要があります。
この手順を、次のコンポーネントで実行する必要があります。
監査サービス(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データベースのカスタム接頭辞に関する重要な情報は、「IBM DB2データベースに関する追加要件」を参照してください。
追加された接頭辞は、次に示すように、アンダースコア(_)によりスキーマ名と区別されます。
prefix_schemaname
接頭辞:
英数字のみ使用でき、スペースやその他の特殊文字は使用できません。
最初の文字は英字にする必要があります。
12文字以内に制限されています。
注意:
接頭辞の付いたスキーマ名の合計長(カスタム接頭辞とコンポーネント・スキーマ名の合計)は、30文字以内に制限されています。
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
で管理されます。
サービス表スキーマは、接頭辞ごとに1回、自動的に作成される特別なスキーマです。サービス表には、基本的なスキーマ構成情報が格納され(スキーマ接頭辞、パスワードなど)、これにOracle Fusion Middlewareコンポーネントがドメイン作成中にアクセスし、使用することができます。
たとえば、構成ウィザードには、RCUの実行時にサービス表に格納されたデータを使用するように構成できる画面があります。サービス表のスキーマ資格証明を提供した後は、サービス表からのデータが使用されて画面のフィールドに値が入れられるため、データを手動で入力する必要はありません。
サービス表を作成すると、サービス表はOracle Fusion Middlewareコンポーネントをワイヤリングするために使用されます。詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の連携するコンポーネントのワイヤリングに関する項を参照してください。
RCUを実行する前に、目的の環境に応じて複数のスキーマをグループ化および分散する方法について理解しておいてください。
詳細は、次の各例を参照してください。
この例では、単一のWebLogicドメインで使用されている単一のデータベースに含まれるスキーマ・セットを示します。
これは、DEV
接頭辞を使用するすべてのスキーマがグループ化され、この単一のWebLogicドメインによって使用される、簡単なシナリオです。
この例では、単一のWebLogicドメインで使用されている複数のデータベースに分散した1つのスキーマ・セットを示します。
同じスキーマ接頭辞(この場合はDEV
)を使用すると、これらの関連するスキーマをグループ化することができます(複数のデータベースにまたがる場合も)。
この例では、単一のデータベース上の複数のスキーマを複数のドメイン用にグループ化する方法を示します。
この例では、1つ目のスキーマ・セット(WebLogicドメイン1用)にDEV1
を使用し、2つ目のスキーマ・セット(WebLogicドメイン2用)にDEV2
を使用して、接頭辞をグループ化しています。
複数のドメイン間で1つのスキーマ・セットを共有することはできず、各ドメインが専用のスキーマ・セットを持つ必要があります。
RCUは、XML DTDによる拡張性を備えています。このようなDTDを使用することによって、コンポーネント所有者は、定義されているDTDに応じた構成ファイルを提供することで、そのコンポーネントと前提条件をRCUに統合できます。
詳細は、「カスタム・アプリケーション・リポジトリを構成するためのリポジトリ作成ユーティリティの拡張」を参照してください。
Java Access Bridgeを使用すると、JAWSスクリーン・リーダーなどのアシスティブ・テクノロジを使用して、Windowsプラットフォームで実行されているJavaアプリケーションを読み取ることができます。
アシスティブ・テクノロジでは、Oracle Universal InstallerやOracle Enterprise ManagerなどのJavaベースのインタフェースを読み取ることができます。
詳細は、以下のトピックを参照してください。
ORACLE_OEM_CLASSPATH
を設定します。