10gリリース2（10.1.2）
B15814-06
 目次 |
 索引 |
| Oracle Application Server 管理者ガイド 10gリリース2（10.1.2） B15814-06 |
|
この章では、テスト環境から本番環境への変更の使用例について説明します。テスト環境でアプリケーションを開発およびテストし、最終的にテスト・アプリケーションや任意のテスト・データを本番環境へ展開することができます。また、このアプローチによってアップグレード版をテストおよび展開できます。
この章の項目は次のとおりです。
表12-1に、使用するアプリケーションおよび構成環境に該当する使用例を見つける方法について、指針を示します。
| アプリケーションのタイプ | 想定される構成 | この使用例の参照先 |
|---|---|---|
|
J2EE |
|
|
|
ケース1 |
本番環境: 中間層インスタンスがすでに存在している。 |
|
|
ケース2 |
本番環境: 本番環境が存在していない。中間層インスタンスを作成したい。 |
関連項目: 第12.2.2項「ケース2: Identity Managementのないテスト用中間層から新しい本番環境にJ2EEアプリケーションを移行」 |
|
ケース3 |
テスト環境: 中間層インスタンスとIdentity Managementがすでに存在している。 本番環境: 本番環境が存在していない。中間層インスタンスとIdentity Managementを作成したい。 |
関連項目: 第12.2.3項「ケース3: Identity Managementのあるテスト用中間層から新しい本番環境にJ2EEアプリケーションを移行」 |
|
J2EE以外 |
|
|
|
ケース1 |
テスト環境: テスト環境が存在していない。中間層インスタンスとIdentity Managementを作成したい。 本番環境: Identity Managementがすでに存在している。中間層インスタンスを作成したい。 |
関連項目: 第12.3.1項「ケース1: Identity Managementのあるテスト用中間層からIdentity Managementのある本番環境にアプリケーションを移行」 |
|
ケース2 |
テスト環境: テスト環境が存在していない。中間層インスタンス、Identity Management、および製品メタデータのMetadata Repositoryを作成したい。 本番環境: Identity Managementがすでに存在している。中間層インスタンス、および製品メタデータのMetadata Repositoryを作成したい。 |
|
|
ケース3 |
テスト環境: テスト環境が存在していない。複数の中間層インスタンスを作成し、それぞれのインスタンスを、Identity Management、および製品メタデータのMetadata Repositoryを備えたものにしたい。 本番環境: Identity Managementがすでに存在している。複数の中間層インスタンスを作成し、それぞれのインスタンスを、製品メタデータのMetadata Repositoryを備えたものにしたい。 |
関連項目: 第12.3.3項「ケース3: 専用のIdentity Management Metadata Repositoryのある複数のテスト用中間層からアプリケーションを移行」 |
J2EEおよびJ2EE以外の使用例に加え、この章では、テスト環境から本番環境に、製品固有のデータを徐々に移行する場合の指針も示します。
この章に示すケースの多くでは、アプリケーション開発を目的としてテスト用中間層インスタンスがすでに存在している構成の中に、本番用中間層インスタンスを作成する作業について説明します。これらのケースには、3つのオプションがあります。次のことが可能になります。
このオプションは、構成設定を保存する場合に使用します。
このオプションは、テスト用中間層インスタンスの目的を本番用中間層インスタンスの目的にする場合に使用します。
このオプションは、テスト用中間層インスタンスとは別のオペレーティング・システムに本番用中間層インスタンスを作成するときに使用します。
この項では、テスト環境から本番環境にJ2EEアプリケーションを移行する方法を示します。次の項目では、代表的なケースを示します。
このケースでは、テスト用中間層インスタンスにJ2EEアプリケーションがあり、このアプリケーションを既存の本番用中間層に再デプロイします。図12-1に、このケースを示します。
この使用例で想定している構成は次のとおりです。
新しい中間層に、J2EEアプリケーションのEARファイルを再デプロイします。次のメカニズムのどれか1つを使用できます。
redeployApplicationコマンドを使用します。
このケースでは、Identity Managementのないテスト用中間層インスタンスに、J2EEアプリケーションがあります。中間層インスタンスがある新しい本番環境を作成し、そこにJ2EEアプリケーションを移行します。図12-2に、このケースを示します。
この使用例で想定している構成は次のとおりです。
このケースでは、本番用中間層インスタンスを作成する必要があります。2つの構成オプションから選択できます。次のいずれかが可能です。
このケースでは、Identity Managementのあるテスト用中間層インスタンスに、J2EEアプリケーションがあります。J2EEアプリケーションのある中間層インスタンスとMetadata RepositoryのあるIdentity Managementを含む新しい本番用環境を作成します。図12-3に、このケースを示します。
このケースで想定している構成は次のとおりです。
このケースでは、本番環境を作成するには、次の作業を実行します。
この使用例では、テスト環境は既存の本番環境から作成されます。テストが済んだデータは、本番環境に戻されます。この使用例が役立つのは、パッチのテストや展開など、本番環境のシミュレーションを行うテスト環境を作成するような場合です。次の項目では、代表的なケースを示します。
このケースでは、既存の本番環境に、Metadata RepositoryのあるIdentity Managementインストールが含まれています。アプリケーションの開発およびテスト用のテスト環境を作成したいと考えています。その後、テストしたアプリケーションを本番環境に展開することも予定しています。
このケースでは、本番用Identity Managementのレプリカをインストールおよび設定することにより、テスト環境を作成します。このIdentity Managementには固有のMetadata Repositoryがあります。テスト用Identity ManagementのOracle Internet Directoryは、本番用Oracle Internet DirectoryのLDAPベースのレプリカです。本番用Oracle Internet Directoryからテスト用Oracle Internet Directoryへのレプリケーションは常時行われます。このレプリカには固有のMetadata Repositoryがあります。次に、テスト用の中間層インスタンスをインストールして、テスト用Identity Managementを使用できるようにします。
アプリケーションの開発とテストの後、テスト用中間層インスタンスをクローニングするか、中間層を本番環境にインストールすることによって、本番用中間層インスタンスを作成し、アプリケーションを再デプロイします。
図12-4に、このケースの例を示します。
このケースで想定している構成は次のとおりです。
この手順では、次の作業を行います。
テスト用のIdentity ManagementとMetadata Repositoryを構成するには、テスト環境にIdentity Managementを設定します。この構成を実行するには、次の下位作業を行います。
テスト用の中間層インスタンスを構成するには、中間層インスタンスをインストールして、アプリケーションの開発とテストを行います。この構成を実行するには、次の下位作業を行います。
本番用中間層インスタンスを作成するには、テスト用中間層インスタンスをクローニングするか、中間層のインストールを実行します。本番用中間層インスタンスを別に作成しない場合は、テスト用中間層インスタンスが本番用Identity Managementをポイントするように選択できます。
テスト用中間層インスタンスをクローニングするときには、テスト用Identity Managementから本番用Identity Managementにデータを移行し、本番用中間層インスタンスと本番用Identity Managementを関連付けることも必要です。テスト用中間層インスタンスをクローニングするには、次の手順を実行します。
テスト用中間層インスタンスが本番用Identity Managementをポイントするようにするには、作業5を除いて、クローニングと同じ作業を実行します。
本番用中間層インスタンスをインストールする手順は次のとおりです。
インストール時には、テスト用Identity Managementのデータは本番環境から移行されていません。
同じ本番環境の別の中間層インスタンスにテスト用アプリケーションをデプロイする場合、次の作業を実行して2つ目の中間層インスタンスを作成します。
このケースは第12.3.1項「ケース1: Identity Managementのあるテスト用中間層からIdentity Managementのある本番環境にアプリケーションを移行」に類似していますが、テスト用中間層インスタンスに本番用メタデータのMetadata Repositoryが追加されている点が異なります。このケースでは、アプリケーションまたは同じIdentity Managementに対する関連アプリケーションを開発およびテストします。その後、これらのアプリケーションを同時に本番環境に展開します。最初のアプリケーションのセットをデプロイしたら、2つ目のアプリケーションのセットの開発、テストおよびデプロイができます。このようにして、このケースは製造ラインのように機能します。
アプリケーションを別々のタイミングでデプロイする場合は、第12.3.3項「ケース3: 専用のIdentity Management Metadata Repositoryのある複数のテスト用中間層からアプリケーションを移行」を検討してください。
ケース1と同様に、まず本番用Identity Managementのレプリカを使用してテスト環境を作成します。次にテスト用中間層インスタンスをインストールして、テスト用Identity Managementおよび、製品メタデータ向けの別個のMetadata Repositoryを使用します。
その後で本番環境を構成します。テスト用の製品Metadata Repositoryを本番環境に移行します。その後、テスト用中間層インスタンスをクローニングするか、中間層を本番環境にインストールすることによって、本番用中間層インスタンスを作成し、アプリケーションを再デプロイします。
図12-5に、このケースの例を示します。
このケースで想定している構成は次のとおりです。
この手順では、次の作業を行います。
テスト用のIdentity ManagementとMetadata Repositoryを構成するには、テスト環境にIdentity Managementを設定します。この構成を実行するには、次の手順を実行します。
テスト用の製品Metadata Repositoryを構成するには、「テスト用の製品Metadata Repositoryのインストールと移入」手順を実行します。
テスト用の中間層インスタンスを構成するには、中間層インスタンスをインストールして、アプリケーションの開発とテストを行います。この構成を実行するには、次の手順を実行します。
本番用の製品Metadata Repositoryを構成するには、「テスト用の製品Metadata Repositoryを本番環境に移動」手順を実行します。
本番用中間層インスタンスを作成するには、テスト用中間層インスタンスをクローニングするか、中間層のインストールを実行します。本番用中間層インスタンスを別に作成しない場合は、テスト用中間層インスタンスが本番用Identity Managementをポイントするように選択できます。
テスト用中間層インスタンスをクローニングするときには、テスト用Identity Managementから本番用Identity Managementにデータを移行し、本番用中間層インスタンスと本番用Identity Managementを関連付けることも必要です。テスト用中間層インスタンスをクローニングするには、次の手順を実行します。
テスト用中間層インスタンスが本番用Identity Managementをポイントするようにするには、作業5を除いて、クローニングと同じ作業を実行します。
本番用中間層インスタンスをインストールする手順は次のとおりです。
インストール時には、テスト用Identity Managementのテスト・データは本番環境から移行されていません。
このケースでは、複数のテスト用中間層インスタンスから本番環境にアプリケーションのデータを移行する方法を示します。このケースでは、アプリケーションのセットまたは関連アプリケーションの2つのセットを別々のテスト環境で開発およびテストします。それぞれのテスト環境には、専用のIdentity Managementがあります。その後、これらのアプリケーションを別々のデプロイ時に本番環境に展開します。
アプリケーションのセットの開発、テストおよびデプロイを一度に行う場合は、第12.3.2項「ケース2: Identity Managementと製品Metadata Repositoryのあるテスト用中間層からIdentity Managementのある既存の本番環境にアプリケーションを移行」を検討してください。
このケースでは、既存の本番環境に、Metadata RepositoryのあるIdentity Managementインストールが含まれています。アプリケーションの開発およびテスト用のテスト環境を作成したいと考えています。このテスト環境に、部門1と部門2という2つの中間層インスタンスを含めようと考えています。このとき、それぞれのインスタンスには、専用のIdentity Managementおよび本番用のMetadata Repositoryがあります。テストの済んだアプリケーションは、同じく部門1および部門2の中間層を含む本番環境に展開します。それぞれの中間層には、専用の製品Metadata Repositoryがあります。
Identity Managementにデータ競合を発生させずにこの移行を行うには、データを部門ごとにシリアルに移行します。
図12-6に、このケースの例を示します。
このケースで想定している構成は次のとおりです。
この手順では、次の作業を行います。
テスト用のIdentity ManagementとMetadata Repositoryを構成するには、両方の部門のテスト環境にIdentity Managementを設定します。この構成を実行するには、次の手順を実行します。
個々のIdentity ManagementとMetadata Repositoryに、別々のデータのユーザー・セットがあることを確認してください。
テスト用の製品Metadata Repositoryを構成するには、「テスト用の製品Metadata Repositoryのインストールと移入」手順を実行します。
各部門の製品Metadata Repositoryごとに、一意のホスト名、インスタンス名、グローバル・データベース名およびOracle System Identifier（SID）を構成します。
テスト用の中間層インスタンスを構成するには、中間層インスタンスをインストールして、アプリケーションの開発とテストを行います。この構成を実行するには、次の手順を実行します。
本番用の製品Metadata Repositoryを構成するには、「テスト用の製品Metadata Repositoryを本番環境に移動」手順を、まず部門1に対して、次に部門2に対して実行します。部門2のデータと、すでに部門1に存在している情報をマージするときには、ユーザー・グループをマージして、ユーザー・データに競合が生じないようにする必要があります。
部門ごとに本番用中間層インスタンスを作成するには、テスト用中間層インスタンスをクローニングするか、中間層のインストールを実行します。本番用中間層インスタンスを別に作成しない場合は、テスト用中間層インスタンスが本番用Identity Managementをポイントするように選択できます。
テスト用中間層インスタンスをクローニングするときには、テスト用Identity Managementから本番用Identity Managementにデータを移行し、本番用中間層インスタンスと本番用Identity Managementを関連付けることも必要です。テスト用中間層インスタンスをクローニングするには、次の手順を実行します。
テスト用中間層インスタンスが本番用Identity Managementをポイントするようにするには、作業5を除いて、クローニングと同じ作業を実行します。
本番用中間層インスタンスをインストールする手順は次のとおりです。
インストール時には、テスト用Identity Managementのテスト・データは本番環境から移行されていません。
第12.3項「ケース2: J2EE以外のアプリケーションの本番環境への移行」の一般的な手順は次のとおりです。
この手順では、テスト用のIdentity Managementと、それに関連付けられたMetadata Repositoryをインストールおよび設定します。テスト用のIdentity Managementは、元のIdentity ManagementのLDAPベースのレプリカです。
テスト用Oracle Internet DirectoryのOracleホームで、次のコマンドを実行します。
remtool -pilotreplica begin -bind test_oid_host:test_oid_port/test_replication_dn_ passwd
この構文では、次のようになります。
test_oid_hostは、テスト用ディレクトリ・サーバーのホスト名を表します。
test_oid_portは、テスト用ディレクトリ・サーバーのLDAPポートを表します。
test_replication_dn_passwdは、テスト用ディレクトリ・サーバーのレプリケーションDNのパスワードを表します。デフォルトでは、これはスーパーユーザーDN（cn=orcladmin）のパスワードと同じです。
|
関連項目
|
新しいデータベースを作成し、そこにOracleAS Metadata Repositoryを移入します。
テスト用の中間層インスタンスをインストールし、それらのインスタンスがテスト内容に応じてテスト用のIdentity Managementを使用するように設定します。
テスト環境で、アプリケーションを開発およびテストします。
テスト用のOracle Internet Directoryで変更または追加したデータが本番用のOracle Internet Directoryに移行しないように、これらのデータをクリーンアップ（削除）することができます。この作業の対象には、中間層コンポーネントが考えられます。または、本番Oracle Internet DirectoryでOracle Internet Directoryの一貫性を保つ管理者に適しています。
データをクリーンアップするには、ldapdeleteコマンドライン・ユーティリティを使用して、移行しないエントリを削除します。
テストから本番へのデータ移行中は、分散ディレクトリ環境を停止する必要があります。これにより更新の競合が回避されるため、データの損失や破損を防止できます。
分散ディレクトリ環境を停止する手順は次のとおりです。
テスト用ホストで、次の行を含むreadonly.ldifというLDIFファイルを作成します。
dn: changetype:modify replace:orclservermode orclservermode:r
次のコマンドを実行します。
TEST_HOME/bin/ldapmodify -p test_oid_port -D cn=orcladmin -w test_orcladmin_passwd -v -f readonly.ldif
この構文では、次のようになります。
test_oid_portは、テスト用ディレクトリ・サーバーのLDAPポートを表します。
test_orcladmin_passwordは、スーパーユーザーDN（cn=orcladmin）のパスワードを表します。
テスト用Oracle Internet DirectoryのOracleホームで、次のコマンドを実行します。
remtool -pilotreplica end -bind test_oid_host:test_oid_port/test_replication_dn_passwd [-bkup fname]
この構文では、次のようになります。
test_oid_hostは、テスト用ディレクトリ・サーバーのホスト名を表します。
test_oid_portは、テスト用ディレクトリ・サーバーのLDAPポートを表します。
test_replication_dn_passwdは、テスト用ディレクトリ・サーバーのレプリケーションDNのパスワードを表します。デフォルトでは、これはスーパーユーザーDN（cn=orcladmin）のパスワードと同じです。
fnameは、パイロット・モード開始後に変更されたエントリの格納先バックアップ・ファイルを指定します。このエントリはLDIF形式です。「Oracle Internet Directoryデータを本番環境に移行」手順でこのファイルを使用します。
|
関連項目
|
テスト用の製品Metadata Repositoryを本番環境に移動するには、いくつかの方法があります。
この場合、それ以上の作業は必要ありません。
Oracle Universal Installerを使用してInfrastructureをインストールします。Metadata Repositoryのみのオプションを選択します。Metadata Repositoryを本番用のIdentity Managementに登録します。
各テスト用中間層インスタンスが新しいMetadata Repositoryを使用するように変更します。各中間層インスタンスについて、次の手順を実行します。
この手順では、テスト用のIdentity Managementから本番用のIdentity ManagementにOracle Internet Directoryのデータを移行する方法について説明します。
PRODUCTION_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w production_orcladmin_passwd -r -f fname
データの移行と競合の解決を行うために、引数-rを必ず指定してください。また、-f引数には「テスト用Oracle Internet Directoryのパイロット・モードの終了」手順で取得したLDIFファイルを必ず指定してください。
この構文では、次のようになります。
production_oid_hostは、本番用ディレクトリ・サーバーのホストを表します。
production_oid_portは、本番用ディレクトリ・サーバーのLDAPポートを表します。
production_orcladmin_passwordは、スーパーユーザーDN（cn=orcladmin）のパスワードを表します。
fnameでは、「テスト用Oracle Internet Directoryのパイロット・モードの終了」手順で指定したLDIFファイルを指定します。
ldapaddmtによって成功がレポートされていることを確認します。add.logファイルでエラーをチェックできます。このファイルは、ldapaddmtコマンドを実行したディレクトリに作成されます。
add.logが空であれば、コマンドは成功しています。
add.logに「Additional Info: Parent entry not found in the directory」のようなエラーが記録されている場合は、LDIFファイルのエントリの順序が誤っています（子エントリが親エントリの前にあります）。ldapaddmtをもう一度実行すると、子エントリが追加されます。必要な場合は、ステップ1を繰り返します。
OracleAS Single Sign-Onデータを移行する手順は次のとおりです。
ORASSOスキーマ・パスワードを取得します。
TEST_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w test_orcladmin_passwd -b "orclresourcename=orasso, orclreferencename=test_oid_global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
この構文では、次のようになります。
test_oid_hostは、テスト用ディレクトリ・サーバーのホストを表します。
test_oid_portは、テスト用ディレクトリ・サーバーのLDAPポートを表します。
test_orcladmin_passwordは、スーパーユーザーDN（cn=orcladmin）のパスワードを表します。
test_oid_global_dbnameは、テスト用Metadata Repositoryのグローバル・データベース名を表します。
このコマンドを実行すると、ORASSOパスワードが次のように行に出力されます。
orclpasswordattribute=LAetjdQ5
ORACLE_HOMEが設定されていることを確認してください）。
TEST_HOME/sso/bin/ssomig -export -s orasso -p test_orasso_passwd -c test_net_service_name -log_d $TEST_HOME/sso/log
この構文では、次のようになります。
test_orasso_passwdは、前の手順で取得したORASSOパスワードです。
test_net_service_nameは、テスト用Metadata Repositoryのデータベース名を表します。
ssomig.dmpおよびssoconf.logファイルをテスト用から本番用のディレクトリ・サーバーにコピーします（各ファイルの正確なフルパスを保持）。
cp TEST_HOME/sso/log/ssomig.dmp PRODUCTION_HOME/sso/log/ssomig.dmp cp TEST_HOME/sso/log/ssoconf.log PRODUCTION_HOME/sso/log/ssoconf.log
ORASSOスキーマ・パスワードを取得します。
PRODUCTION_HOME/bin/ldapsearch -h production_oid_host -D "cn=orcladmin"
-p production_oid_port -w production_orcladmin_password -b "orclresourcename=orasso, orclreferencename=production_global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
この構文では、次のようになります。
production_oid_hostは、本番用ディレクトリ・サーバーのホストを表します。
production_oid_portは、本番用ディレクトリ・サーバーのLDAPポートを表します。
production_orcladmin_passwordは、スーパーユーザーDN（cn=orcladmin）のパスワードを表します。
production_oid_global_dbnameは、本番用Metadata Repositoryのグローバル・データベース名を表します。
PRODUCTION_HOME/sso/bin/ssomig -import -overwrite -s orasso -p production_orasso_passwd -c production_net_service_name -log_d $PRODUCTION_HOME/sso/log -discoforce
この構文では、次のようになります。
production_orasso_passwdは、前の手順で取得したORASSOパスワードです。
production_net_service_nameは、本番用Metadata Repositoryのデータベース名を表します。
OracleAS Single Sign-On移行ツールによって成功がレポートされていることを確認します。次のログ・ファイルでエラーをチェックすることもできます。
TEST_HOME/sso/log/ssomig.log PRODUCTION_HOME/sso/log/ssomig.log
Directory Integration and Provisioningデータを移行する手順は次のとおりです。
TEST_HOME/bin/oidctl server=odisrv instance=1 stop
TEST_HOME/bin/dipassistant reassociate -src_ldap_host test_oid_host -src_ldap_port test_oid_port -dst_ldap_host production_oid_host -dst_ldap_port production_oid_port -src_ldap_passwd test_orcladmin_passwd -dst_ldap_passwd production_orcladmin_passwd
ログ・メッセージが次のファイルに出力されます。
TEST_HOME/ldap/odi/log/reassociate.log
この構文では、次のようになります。
test_oid_hostは、テスト用ディレクトリ・サーバーのホストを表します。
test_oid_portは、テスト用ディレクトリ・サーバーのLDAPポートを表します。
production_oid_hostは、本番用ディレクトリ・サーバーのホストを表します。
production_oid_portは、本番用ディレクトリ・サーバーのLDAPポートを表します。
test_orcladmin_passwordは、テスト用ディレクトリ・サーバーのスーパーユーザーDN（cn=orcladmin）のパスワードを表します。
production_orcladmin_passwordは、本番用ディレクトリ・サーバーのスーパーユーザーDN（cn=orcladmin）のパスワードを表します。
PRODUCTION_HOME/bin/oidctl server=odisrv instance=1 stop
PRODUCTION_HOME/bin/odisrvreg -D "cn=orcladmin" -w production_orcladmin_passwd -p production_oid_port
-h production_oid_host
この構文では、次のようになります。
production_orcladmin_passwordは、スーパーユーザーDN（cn=orcladmin）のパスワードを表します。
production_oid_portは、本番用ディレクトリ・サーバーのLDAPポートを表します。
production_oid_hostは、本番用ディレクトリ・サーバーのホストを表します。
PRODUCTION_HOME/bin/oidctl server=odisrv instance=1 flags="port=production_oid_port" start
この構文で、production_oid_portは、本番用ディレクトリ・サーバーのLDAPポートを表します。
一部の中間層コンポーネントは、本番環境への移行後の特別なクリーンアップ要件を備えていることがあります。これらのクリーンアップ作業は、中間層インスタンスを本番ノードに移行した後にテスト環境で行うことができます。
各本番用中間層インスタンスで、ID管理の変更ウィザードを起動し、インスタンスを再起動します。
この使用例では、既存のテスト環境および本番環境でアプリケーションのテストに使用された増分データのみを移行します。データの移行方法は、アプリケーションによって異なります。この項では、次のコンポーネントで移行プロセスがどのように行われるかについて説明します。
このケースでは、既存のテスト環境と本番環境にOracleAS Portal Metadata Repositoryがあります。テスト用Metadata Repositoryから本番環境にメタデータを移行します。OracleAS Portalメタデータを移行するには、エクスポート/インポート・ユーティリティを使用して内容を移行します。図12-7に、このケースを示します。
テスト環境と本番環境があり、それぞれに中間層インスタンス、Metadata Repositoryを持つIdentity Managementインストール、およびOracleAS Portalメタデータ用の追加Metadata Repositoryがあります。テスト環境には、OracleAS Portalメタデータがすでに存在しています。
エクスポートとインポートを使用してOracleAS Portalメタデータを移行する手順は次のとおりです。
このケースでは、テスト環境と本番環境がすでに存在しています。OracleBI Discovererのテスト・データは、中間層、Metadata Repositoryおよびデータベースにすでに存在しています。本番システムのパフォーマンスに影響を与えずにビジネス領域の開発を行うため、最初にテスト環境を使用してEnd User Layer（EUL）を作成します。
移行プロセスには、次の3つの主要な作業が含まれます。まず、中間層から構成ファイルを移行し、次にテスト用Metadata Repositoryから本番環境にOracleBI Discovererメタデータを移行します。最後に、テスト用データベースから本番用データベースに、OracleBI Discoverer情報（EULを含む）を移行します。
図12-8に、このケースを示します。
テスト環境と本番環境があり、それぞれに中間層インスタンス、Metadata Repositoryを持つIdentity Managementインストール、OracleBI Discovererメタデータ用の追加Metadata Repository、およびデータベースがあります。テスト環境には、OracleAS Portalメタデータがすでに存在しています。
OracleBI Discovererの構成、メタデータおよびデータベース・データを移行する手順は次のとおりです。
pref.txtファイルを本番環境にコピーします。
configuration.xmlファイルを本番環境にコピーします。
opmn.xmlファイルを本番環境にコピーします。
tnsnames.oraファイルを本番環境にコピーします。
「テスト用の製品Metadata Repositoryを本番環境に移動」を実行します。この際、OracleBI Discovererメタデータを格納するDISCOVERER5スキーマも移動します。
|
 Copyright © 2002, 2006 Oracle. All Rights Reserved. |
|