この章では、Oracle Fusion Middlewareをテスト環境などのソース環境から本番環境などのターゲット環境に移行する方法について説明します。ソース環境内でアプリケーションの開発とテストを行い、最終的にはテスト・アプリケーション、また、必要に応じてテスト・データをターゲット環境にロール・アウトできます。このアプローチは、アップグレードのテストおよびロール・アウトにも使用できます。
この章の内容は次のとおりです。
注意:
|
Oracle Fusion Middlewareコンポーネントをソース環境からターゲット環境に移行できます。
Oracle Fusion Middlewareコンポーネントを移行しない場合、移行元の環境で行ったカスタマイズや構成変更は、移行先の環境にすべて再適用する必要がありますが、コンポーネントを移行することにより、このような作業が最小化されます。ソース環境では、Oracle Fusion Middlewareのインストール、構成、カスタマイズおよび検証を行うことができます。システムが安定し、必要に応じて機能するようになったら、ターゲット環境を作成しますが、このとき、ソース環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをソース環境から移行することでターゲット環境を作成できます。
この項では、環境を移行する前に知っておく必要がある重要な情報について説明します。内容は次のとおりです。
Oracle Fusion Middlewareには、環境の移行に使用できる一連のスクリプトが用意されています。
copyBinary: ソースOracleホームのバイナリ・ファイルをコピーします。
pasteBinary: コピーしたOracleホームをターゲットに適用します。
copyConfig: 次のいずれにも使用できます。
WebLogic Serverドメインの構成をコピーします(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)
スタンドアロン・ドメインの構成をコピーします(ドメイン内のすべてのシステム・コンポーネントを含む)
ノード・マネージャの構成をコピーします。
extractMovePlan: copyConfig操作で作成されたアーカイブ・ファイルから、移動計画を.xmlファイル(名前はmoveplan.xml)として抽出し、さらにその他のファイルも抽出します。
pasteConfig: 次のいずれにも使用できます。
コピーされたWebLogic Serverドメインの構成を適用します(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)
コピーされたスタンドアロン・ドメインの構成を適用します(ドメイン内のすべてのシステム・コンポーネントを含む)
コピーされたノード・マネージャの構成を適用します。
こうしたスクリプトにより、ユーザーはOracleホーム・ドメイン、Oracle WebLogic Serverドメイン、さらにOracle HTTP ServerやOracle SOA Suiteなどの特定のOracle Fusion Middlewareコンポーネントの構成をコピーできます。
表20-1は、移行スクリプトをサポートしているOracle Fusion Middlewareコンポーネントを示しています。
表20-1 移行スクリプトのサポート
コンポーネント | サポートの有無 |
---|---|
Oracle SOA Core Extensions |
はい |
Oracle Application Development Framework |
はい |
Oracle B2B |
はい |
Oracle B2B for Healthcare |
はい |
Oracle Business Activity Monitoring |
はい |
Oracle Business Process Management |
はい |
Oracle Coherence |
はい |
Oracle Data Integrator |
はい |
Oracle Enterprise Data Quality |
はい |
Oracle Enterprise Scheduler |
はい |
Oracle HTTP Server |
はい |
Oracle HTTP Server WebGate |
はい |
Oracle Managed File Transfer |
はい |
Oracle Platform Security Services |
はい |
Oracle Service Bus |
はい |
Oracle SOA Suite |
はい |
Oracle User Messaging Service |
はい |
Oracle Web Services Manager |
はい |
Oracle WebLogic Server |
はい |
コンポーネントの移動計画のプロパティについては、表A-11を参照してください。
この章の手順では、次の一部またはすべてが含まれる、Oracle Fusion Middlewareのインストールおよび構成がソース環境で行われていることを想定しています。
Oracle SOA SuiteなどのOracle Fusion Middlewareコンポーネントで使用される1つ以上のデータベースをインストールしました。
RCUを使用してソース環境で必要なスキーマを作成しました。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
Oracle Fusion Middleware製品をインストールし、構成しました。たとえば、Oracle WebLogic ServerとOracle Web Services Managerをインストールし、Oracleホームを作成し、Oracle WebLogic Serverドメインを構成しました。
ドメインを構成するときには、2つの方法のいずれかを選択できます。
開発モード: このモードでは、セキュリティの構成が比較的緩くなります。アプリケーションのデプロイには、ユーザー名とパスワードが必要です。
本番モード: このモードでは、セキュリティの構成が比較的厳格で、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要です。
または、スタンドアロン・ドメインにシステム・コンポーネント(Oracle HTTP Serverなど)をインストールおよび構成しました。
セキュリティ・ポリシーを構成しました。
Oracle Platform Security Servicesの場合、セキュリティ・ポリシーおよび格納済の資格証明を資格証明ストア・フレームワーク(CSF)に作成しました。
1つ以上のアプリケーションまたはSOAコンポジット・アプリケーションをデプロイしました。これらのアプリケーションには、内部参照および外部参照が含まれる場合があります。
WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、管理サーバーと管理対象サーバーが実行されていることを確認してください。
Windowsの場合、WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、ノード・マネージャを停止する必要があります。
Oracle Web Services Managerの場合は、copyConfigスクリプトを実行する前に、Oracle Web Services Managerポリシー・マネージャ・アプリケーションのデプロイ先のサーバーが実行されている必要があります。
また、ソース環境については次の点に注意してください。
WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、管理サーバーと管理対象サーバーが実行されていることを確認してください。
Windowsの場合、WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、ノード・マネージャを停止する必要があります。
Oracle Web Services Managerの場合は、copyConfigスクリプトを実行する前に、Oracle Web Services Managerポリシー・マネージャ・アプリケーションのデプロイ先のサーバーが実行されている必要があります。
Oracle Fusion Middlewareでは、次の2つのタイプのキーストアがサポートされています。
JKS: Javaキーストア
KSS: Oracle Platform Security Servicesキーストア・サービス。キーストア・サービスは、Oracle JRFを含むドメインを作成した場合にのみ使用できます。
キーストア関連のプロパティは、次の状況である移動計画のすべてのサーバーに対して移入されます。
構成されているキーストアに関係なく、ソース・ドメインでSSLが有効化されている場合(管理サーバー・ポートまたは管理サーバーのSSLポートのいずれか)。
ソース・ドメインで非SSLポートのみが有効化されており、管理サーバーのキーストアが次のタイプのいずれかである場合。
CustomIdentityandCustomTrust
CustomIdentityandJavaStandardTrust
CustomIdentityandCommandLineTrust
ソース・ドメインで非SSLポートのみが有効化されており、DemoIdentityAndDemoTrustキーストアが構成されている場合、キーストア関連のプロパティは移動計画に移入されません。
ソース環境が構成されている方法に関係なく、pasteConfigスクリプトを使用して構成をターゲットに移動する場合は、移動計画のプロパティを構成する方法について次の点に注意する必要があります。
Oracle JRFで構成されているドメインの場合:
すべてのサーバーは、同じキーストアを持っている必要があります。
キーストア・タイプ(JKSまたはKSS)は、すべてのサーバーで同じにする必要があります。
移動計画を変更して、キーストア・タイプをJKSからKSS、またはKSSからJKSに変更できます。
Oracle JRFで構成されていないドメインの場合:
すべてのサーバーは、同じキーストアを持っている必要があります。
JKSキーストアのみを使用できます。
Oracle JRFで構成されているドメインおよびOracle JRFなしで構成されているドメインの両方に対して、キーストアをソースからターゲットに変更できます。ソースが非SSLのみでDemoIdentityAndDemoTrustである場合を除けば、たとえキーストアの値がソースにあるとしても、次のいずれかの値に変更できます。
DemoIdentityAndDemoTrust
CustomIdentityAndCustomTrust
CustomIdentityAndJavaStandardTrust
CustomIdentityAndCommandLineTrust
この章の手順を使用するには、ターゲット環境が次の前提条件を満たしている必要があります。
コピーするOracleホームおよびコンポーネントのバージョンと互換性のあるcloningclient.jarファイルおよび移行スクリプト(pasteBinaryなど)を使用する必要があります。この章の手順では、現行バージョンのcloningclient.jarファイルおよび移行スクリプトを使用することを前提としています。
ターゲット環境は、ソース環境と同じオペレーティング・システム上にある必要があります。また、オペレーティング・システム・アーキテクチャは、両方の環境で同じでなければなりません。たとえば、両方の環境で32ビットのオペレーティング・システムまたは64ビットのオペレーティング・システムを実行している必要があります。
スクリプトを実行するときに、対応するJavaホームを指定する必要があります。つまり、Oracleホームが64ビットの場合、64ビットのJavaホームを指定する必要があります。Oracleホームが32ビットの場合、32ビットのJavaホームを指定する必要があります。
ホストには、JDK 1.7.0_x以降がインストールされている必要があります。
ターゲット環境では、ソース環境のユーザーと同じスーパーユーザーまたは管理ユーザーが必要です。インストールの移行が完了したら、ターゲット環境でユーザーを変更できます。
ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースがOracle Databaseである場合、ターゲット環境のデータベースもOracle Databaseである必要があります。ターゲット環境のデータベースは、ソース環境のデータベースと同じバージョンである必要があります。
データベースが適切に調整されていない場合、copyConfig操作およびpasteConfig操作でパフォーマンスの問題が発生することがあります。このようなパフォーマンスの問題を回避するには、次の標準データベース・パフォーマンス調整ガイドラインに加えて、MDS表のインポート用に、データベースに十分なRAMが割り当てられていることを確認します。また、次のプロシージャを実行して、ターゲット・データベースに対する統計を実行します。
BEGIN
dbms_stats.gather_schema_stats(ownname => 'prefix_MDS',
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
CASCADE => TRUE, ESTIMATE_PERCENT => NULL);
END;
このプロシージャでは、prefix
_MDS
は、インストールのMDSスキーマ名です。
Oracle Fusion MiddlewareがインストールされていないホストにOracleホームのアーカイブを適用する場合、次の点に注意してください。
ソース・ホストの次の場所からpasteBinaryスクリプトをターゲット・ホストにコピーします。
(UNIX) ORACLE_HOME/oracle_common/bin/pasteBinary.sh (Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd
Windowsの場合、pasteBinary.shはコピーしません。
ソース・ホストの次のファイルをターゲット・ホストにコピーします。
(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar (Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar
ORACLE_HOME/oracle_common/bin
以外の場所からpasteBinaryスクリプトを実行する場合は、pasteBinaryスクリプトとcloningclient.jarファイルが同一ディレクトリにある必要があります。
前のOracle Fusion MiddlewareインストールがないホストでpasteBinaryを実行する場合、pasteBinaryを実行する前にORACLE_HOME/oracle_common/bin
は存在していないため、pasteBinaryスクリプトとcloningclient.jarは同じディレクトリに存在する必要があります。
ファイルに実行権限があることを確認してください。
ソース環境でcopyConfigコマンドを実行するときには、任意のシステム・コンポーネントを起動または停止できます。いずれの場合も、copyConfig操作は完了します。これは、WebLogic Serverドメインにもスタンドアロン・ドメインにも当てはまります。
Windowsでは、ファイルMSVCR90.DLLがターゲット・ホストに存在する必要があります。そうでない場合、pasteConfigは失敗します。
このファイル(または、このファイルの様々なバージョン)は、次の下のディレクトリ・ツリーに置かれています。
(Windows 32 bit) C:\Windows\System32 (Windows 64 bit) C:\Windows\winsxs
次の制限事項に注意してください。
ソース環境とターゲット環境は、同じエンコーディングを使用している必要があります。たとえば、ソース環境がja_JP.utf8ロケール・エンコーディングを使用しており、ターゲット環境がja_JPロケール・エンコーディングを使用している場合、ターゲットで一部のファイル名が正しく処理されない可能性があります。
コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)
カスタム・アプリケーションで内部データ・ソースを使用する場合(たとえば、JDeveloperを使用してアプリケーションが作成され、内部データ・ソースとともにデプロイされている場合など)、pasteConfig操作では内部データ・ソースは移行されません。
この問題を解決するには、ドメインに外部データ・ソースを作成し、アプリケーションでそのデータ・ソースを使用するように変更して、アプリケーションを再度デプロイします。
ソースOracleホームで、Oracleホームの外部にあるJDKを使用する場合、pasteBinary操作でも外部のJDKを使用する必要があります。
ソースとターゲットで使用されているJDKが同じである必要があります。
ソースとターゲットで使用されているJDKが同じである必要があります。たとえば、ソースでJava SEを使用する場合は、ターゲットでもJava SEを使用する必要があります。
ソースおよびターゲットで使用されるベンダーは同じである必要があります。たとえば、ソースでOracle JDKを使用する場合は、ターゲットでもOracleのJDKを使用する必要があります。
ソースおよびターゲットで使用されるJDKのメジャー・バージョンは、同じである必要があります。たとえば、ソースでバージョン1.7を使用する場合は、ターゲットでも1.7を使用する必要があります。
エンティティを移行する際に一時ディレクトリに十分な領域がない場合は、その旨を示すエラーが返されます。この問題が発生しないようにするには、第A.1.2項で説明しているように、T2P_JAVA_OPTIONS環境変数を使用して、一時ディレクトリとして別の場所を指定します。
環境を移行して、カスタムのインベントリの場所を使用(invPtrLocパラメータを使用)してpasteBinaryスクリプトを実行した場合、次のいずれかの引数を使用してrunInstallerを起動する必要があります。
-invPtrLoc custom_inventory_pointer_location
Oracle Platform Security Servicesを移行していて、LDAP間でデータを移動している場合、ソースおよびターゲットのLDAPドメイン・コンポーネントの階層は同じである必要があります。同一でないと、Oracle Platform Security Servicesのデータ移行は失敗します。たとえば、ソースの階層がdc=us,dc=com
として構成されている場合、ターゲットのLDAPは同じドメイン・コンポーネントの階層を持っている必要があります。
ドメインでOracle Service Busが構成されている場合、pasteConfig操作時に最初に管理サーバーを起動した際に、次のエラーが表示されることがあります。
Failed to initialize the application "Service Bus Framework Starter Application" due to error java.lang.RuntimeException: OSB system user authentication failed java.lang.RuntimeException: OSB system user authentication failed
このエラーは無視できます。
この項では、インストールをソース環境からターゲット環境に移行する一般的な手順について説明します。表20-1に、この手順を示すフローチャートを表示します。
一般的な手順は次のとおりです。
ソース環境をチェックします。第20.2.2項を参照してください。
ターゲット環境を準備します。第20.2.4項を参照してください。
環境でデータベースを使用している場合は、新しいデータベースを作成します。第20.3.1項を参照してください。
Oracleホームにあるバイナリ・ファイルのコピーを、ソース環境からターゲット環境に移行します。
copyBinaryおよびpasteBinaryスクリプトを使用します(第20.3.2項を参照)。
ストレージ・レベルのクローニング・ツールを使用(環境でサポートされている場合)して、既存のディスク・ボリュームのコピーを作成し、それを別の場所に移動します。次に、pasteBinaryスクリプトを使用して、必要なインベントリ情報、ファイル権限および正しいORACLE_HOMEパスのための文字列置換を作成または更新することにより、ターゲットOracleホームを正しいOracleホームに変換します。第20.3.3項を参照してください。
この方法は、環境が1つのディスク・ボリュームにある場合に使用できます。
ドメインおよびコンポーネントの構成のコピーを移行します。ほとんどの場合、copyConfig、extractMovePlanおよびpasteConfigスクリプトを使用します。従う手順は、ご使用のトポロジによって異なります。
第20.3.6項で説明するような特定の状況では、ノード・マネージャがソース環境で構成されている場合に、その構成のコピーを別途移行する必要があります。
一部のコンポーネントで必要になる追加の手順を実行します。各コンポーネントに固有の情報については、第20.4項を参照してください。
サーバーとコンポーネントを起動します。第20.3.8項を参照してください。
Oracle Fusion Middlewareコンポーネントの多くで、ソース環境からターゲット環境に移行する際に、共通の手順を使用します。ただし、すべてのコンポーネントがこれらの手順のすべてまたはそれらの一部を使用するわけではありません。また、一部コンポーネントでは追加の手順が必要な場合があります。特定のコンポーネントを移行する際に追加の手順が必要かどうか、表20-2でチェックする必要があります。
この項では、共通の手順について、次のとおり説明します。
この項の手順では、標準的なインストール・トポロジが使用されていると仮定しています。このトポロジは、1つの管理サーバーを含む1つのWebLogic Serverドメインと、1つのホスト上の2つの管理対象サーバーまたはシステム・コンポーネントを含むスタンドアロン・ドメインが含まれているクラスタで構成されます。
複数のマシンにわたる分散トポロジの場合は、第20.6項を参照してください。
注意: これらの手順および移動計画で使用するスクリプトでは、通常、パスワードを含むファイルを指定する必要があります。不明瞭化したパスワードを含むファイルを生成するには、第A.1.2.10項で説明されているobfuscatePasswordスクリプトを使用します。 |
Oracle Application Development Framework、Oracle SOA Suiteなどの一部のコンポーネントでは、メタデータを格納するためにデータベースを使用することがあります。
ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースがOracle Databaseである場合、ターゲット環境のデータベースもOracle Databaseである必要があります。ターゲット環境のデータベースは、ソース環境のデータベースと同じバージョンである必要があります。
新しいデータベースをインストールする手順は次のとおりです。
データベース・ソフトウェアをインストールして構成します。
RCUを使用してターゲット・データベースで必要なスキーマを作成します。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
アプリケーションで使用するカスタム・スキーマを作成します。たとえば、アプリケーションがソース環境でカスタム・スキーマを使用する場合、ターゲット環境でそのスキーマを作成します。
copyBinaryおよびpasteBinaryスクリプトを使用して、Oracleホームのコピーをターゲット環境に移行できます。
copyBinaryスクリプトによって、ソースの準備が実行され、アーカイブが作成されます。また、Oracleホームのファイル権限も記録されます。
このアーカイブには、Oracle WebLogic ServerホームやOracle HTTP Serverホームなどの製品ホームを含む、Oracleホームが含まれています。
pasteBinaryスクリプトによって、クローニング先で前提条件が満たされているかどうかが確認されます。アーカイブ・ファイルから複数のファイルが抽出され、OracleホームがOracleインベントリに登録されます。
次に、スクリプトによってファイル権限がリストアされ、必要に応じてリンクが再設定されます。
次の点に注意してください。
copyBinaryおよびpasteBinaryスクリプトを実行しても、ソースOracleホームおよび製品ホーム(WebLogic Serverホームなど)の、ロード可能なモジュールやアプリケーション固有のライブラリなどのすべての依存関係が、ターゲット・ホームに継承されるわけではありません。スクリプトによって、Oracleホームおよびソースの製品ホーム全体がコピー先のOracleホームにコピーされるためです。ソースのWebLogic ServerまたはOracleホームの外部にあるファイルは、自動的にはコピーされません。そのため、ソースのWebLogic ServerまたはOracleホームの外部にあるファイルを参照するアプリケーションは、ターゲット・ホームで正しく機能しない場合があります。
Oracleホームをコピーする場合は、Oracleホームの読取り専用部分のみがコピーされます。user_projectsディレクトリなどのユーザー構成ファイルは、アーカイブから除外されます。WebLogic Serverドメインはコピーされません。(copyConfigおよびpasteConfigスクリプトを使用して、ドメインをコピーします。)
パスがシンボリック・リンクの場合、Oracleホームを移行することはできません。
Oracleホームを移行する手順は次のとおりです。
ソースでcopyBinaryスクリプトを実行します。これにより、OracleホームおよびWebLogic Serverホームなど、Oracleホームに含まれている製品ホームがコピーされます。
copyBinaryスクリプトの構文については、第A.1.2.1項を参照してください。
たとえば、/scratch/oracle/Oracle_home1にあるOracleホームをコピーするには、次のコマンドを使用します。
copyBinary.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/oh_copy.jar -sourceOracleHomeLoc /scratch/oracle/Oracle_home1
Oracleホームを別のホストにコピーする場合は、アーカイブ・ファイルをそのシステムにコピーするか、または、ストレージ・レベルのクローニングを使用している場合は、ボリュームのスナップショット・コピーをターゲット・システムにコピーし、そのボリュームをマウントします。
pasteBinaryスクリプトとcloningclient.jarファイルをターゲット・システムにコピーし、実行権限があることを確認します。
cloningclient.jarファイルは次の場所にあります。
(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar (Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar
pasteConfigなど他のスクリプトをコピーしないでください。これらのスクリプトは、ステップ5で説明しているように、ファイルの抽出時に生成されます。
LinuxとUNIXでは、インストールされているOracle製品がターゲット・システムにない場合、oraInst.locファイルを作成し、Oracleインベントリ(oraInventory)に対する書込みアクセス権が付与されているメンバーの所属グループとOracleインベントリの格納先を指定する必要があります。たとえば、oraInst.locファイルには次を含めることができます。
inst_group=dba inventory_loc=/scratch/oracle1/oraInventory
そして、その場所がデフォルトの場所ではない場合、-invPtrLocオプションをpasteBinaryスクリプトに使用して、oraInst.locファイルの場所を指定します。(LinuxおよびAIXの場合、デフォルトの場所は/etc/oraInst.locで、その他のUNIXプラットフォームの場合は、/var/opt/oracle/oraInst.locです。)
クローニング先で、pasteBinaryスクリプトを使用して、アーカイブからファイルを抽出します。pasteBinaryスクリプトの構文については、第A.1.2.2項を参照してください。
注意: Oracleホームの親ディレクトリが存在しない場合は、pasteBinaryスクリプトにより作成されます。 Oracleホーム(たとえば、Oracle_Home_prod)の実際のディレクトリは、存在してはいけないか、または既存の空のディレクトリにする必要があります。 |
たとえば、/scratch/oracle/ORACLE_HOME_prodディレクトリにアーカイブを適用するには、次のコマンドを使用します。
pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 -archiveLoc /tmp/oh_copy.jar -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod -targetOracleHomeName ORACLE_HOME_prod -invPtrLoc /scratch/oracle/oraInventory
Oracleホームは/scratch/oracle/ORACLE_HOME_prodに抽出され、製品ホームはソースの製品ホームの名前と同じ名前でその下に抽出されます。
copyBinaryおよびpasteBinaryスクリプトでは、user_projectsディレクトリはコピーされません。これらのスクリプトでは、Oracleホームにある他のドメイン・ディレクトリがコピーされて貼り付けられます。ただし、これらのドメイン・ディレクトリは機能しません。(ドメイン・ディレクトリは、Oracleホームの下には作成しないことをお薦めします。)
pasteConfigスクリプトにより、ドメイン・ディレクトリがターゲット環境で再作成されるため、pasteConfigコマンドを実行する前に、ドメイン・ディレクトリをターゲットから削除してください(第20.3.4項を参照)。
ターゲットでは、ノード・マネージャがホストごとにOracleホームの下にある場合は、ノード・マネージャのディレクトリおよびその中のファイルを削除します。
この状態で、ノード・マネージャを第20.3.6に従って移行します。
copyBinaryスクリプトのかわりに、Oracle Solaris ZFSやNetApp Flex Cloningなどのストレージ・レベルのクローニング・ツールを使用して、既存のディスク・ボリュームのコピーを作成し、それを別の場所に移行できます。
この方法は、環境が1つのディスク・ボリュームにある場合に使用できます。
ストレージ・レベルのクローニング・ツールを使用してOracleホームおよびバイナリ・ファイルを移行する手順は、次のとおりです。
クローニング・ツールを使用して、ディスク・ボリュームをターゲット環境にレプリケートします。
詳細は、ご使用のディスク・ボリュームのドキュメントを参照してください。
ターゲットで、pasteBinaryスクリプトを-ohAlreadyClonedオプションを指定して使用します。このオプションを指定すると、必要なインベントリ情報、ファイル権限および正しいORACLE_HOMEパスのための文字列置換が、pasteBinaryスクリプトにより作成または更新されます。
pasteBinaryスクリプトの構文については、第A.1.2.2項を参照してください。
たとえば、/scratch/oracle/ORACLE_HOME_prodディレクトリにアーカイブを適用するには、次のコマンドを使用します。
pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 -ohAlreadyCloned true -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod -targetOracleHomeName ORACLE_HOME_prod
ターゲットでは、ノード・マネージャが「ホストごとに」Oracleホームの下にある場合は、ノード・マネージャのディレクトリおよびその中のファイルを削除します。
この状態で、ノード・マネージャを第20.3.6に従って移行します。
ストレージ・レベルのクローニング・ツールはユーザー・ディレクトリ全体をコピーするため、ドメイン・ディレクトリがソース環境で構成されていた場合は、バイナリ・ファイルだけではなく、ドメイン・ディレクトリもコピーされます。ただし、これらのドメイン・ディレクトリは正しく構成されていないので、機能しません。
pasteConfigコマンドにより、正しく構成されたドメイン・ディレクトリがターゲット環境で再作成されるので、このコマンドを実行する前に、ドメインディレクトリをターゲットから削除してください(第20.3.4項を参照)。
copyConfig、extractMovePlanまたはpasteConfigスクリプトを使用して、WebLogic Serverドメインの構成のコピーを移行できます。 domain configuration using the この手順により、ドメイン、管理サーバーと管理対象サーバーおよびドメイン内のすべてのコンポーネントの構成のコピーが移行されます。
コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)
ドメイン・ディレクトリは各マシンに対してローカルです。pasteConfigスクリプトは管理サーバー・ドメイン・ディレクトリでのみ実行されます。その後、管理対象サーバーのディレクトリが管理サーバーと異なる場合は、Oracle WebLogic Serverのpackおよびunpackコマンドを使用して、管理対象サーバーのドメイン・ディレクトリを再作成する必要があります。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。
通常、ユーザーに固有のデータはターゲット環境とソース環境で同じではないため、この処理では、ユーザー固有のデータは移行されません。
注意: デフォルトでは、copyConfigおよびpasteConfigの操作時に、最大ヒープ・サイズと最大永続生成サイズを指定する次のコマンドが設定されます。 -Xmx512m -XX:MaxPermSize=256m これらの値は、copyConfigおよびpasteConfigスクリプトのT2P_JAVA_OPTIONSパラメータを使用して変更できます。 |
ドメイン構成のコピーを移行する手順は、次のとおりです。
ソースで、管理サーバーおよびすべての管理対象サーバーが起動されていることを確認します。
Windowsの場合、copyConfigスクリプトを実行する前に、ノード・マネージャを停止する必要があります。
ソースで、自動的にロックを取得するようにドメイン構成が設定されていないことを確認します。開発モードでドメインを構成した場合は、ロックの自動取得が有効になっています。本番モードでドメインを構成した場合は、デフォルトで無効になっています。次の手順を実行します。
管理コンソールで「プリファレンス」をクリックします。
「プリファレンス」タブで、「ロックを自動取得して変更をアクティブ化」の選択を解除します。
「保存」をクリックします。
「チェンジ・センター」で、該当する場合は「構成の解放」をクリックします。
ソースで次のスクリプトを実行して、domainAdminPasswordFileパラメータに必要な不明瞭化したパスワード・ファイルを生成します。
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。
ソースでcopyConfigスクリプトを実行して、ドメイン構成をコピーします。
copyConfigスクリプトは、次の場所にあります。
(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh (Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd
copyConfigスクリプトの構文については、第A.1.2.3項を参照してください。
たとえば、Oracleホーム/scratch/oracle/Oracle_home1のWLS_domain1という構成をコピーするには、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/oracle/jdk1.7.0_17 -archiveLoc /tmp/wls.jar -sourceDomainLoc /scratch/oracle/domains/WLS_domain1 -sourceOracleHomeLoc /scratch/oracle/Oracle_home1 -domainHostName example.com -domainPortNum 8001 -domainAdminUserName domain_admin_username -domainAdminPasswordFile /scratch/admin/passwd.txt -logDirLoc /tmp/logs
Oracle Service Busでは、copyConfigスクリプトの使用時に、キーosb.configuration.passphrase.file
およびパスフレーズを含むファイルの絶対パスを指定するキー値とともに-additionalParams
オプションを渡す必要があります。次に例を示します。
-additionalParams osb.configuration.passphrase.file=/scratch/passwd/osb_passwd
このオプションを指定しないと、エクスポートされた構成はパスワードで保護されません。
ドメイン構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
ソースでextractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。
次に例を示します。
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/wls.jar -planDirLoc /tmp/Oracle/t2p_plans/wls
注意: ソース環境に変更を加えていなくても、copyConfigスクリプトを使用するたびに、新しい移動計画を抽出する必要があります。pasteConfigスクリプトによって、移動計画とアーカイブが一致することが確認されます。一致しない場合は、スクリプトによりエラーが返されます。 |
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。移行するコンポーネントのタイプごとのプロパティのリストについては、表A-11を参照してください。
編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。
ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、第A.1.2.7項を参照してください。
たとえば、アーカイブをOracleホーム/scratch/oracle/Oracle_home1に適用するには、次のコマンドを使用します。
pasteConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/wls.jar -movePlanLoc /tmp/Oracle/t2p_plans/wls/moveplan.xml -targetDomainLoc /scratch/oracle/config/domains/WLS_domain1 -targetOracleHomeLoc /scratch/oracle/Oracle_home1/ -domainAdminPasswordFile /scratch/pwd_dir/passwd.txt
管理対象サーバーが管理サーバーと同じホスト上に置かれていない場合は、Oracle WebLogic Serverのpackおよびunpackコマンドを使用して、管理対象サーバーのドメイン・ディレクトリを再作成する必要があります。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。
この作業が完了した際に、第20.4項の説明に従って、一部のコンポーネントで追加手順の実行が必要な場合があります。
複数のシステム・コンポーネントを含むスタンドアロン・ドメインの構成を移行できます。たとえば、Oracle HTTP Serverをスタンドアロン・ドメインにインストールしたとします。
システム・コンポーネントを含むスタンドアロン・ドメインの構成を移行するには、
ソースで、copyConfigスクリプトを実行して構成をコピーします。
copyConfigスクリプトの構文については、第A.1.2.4項を参照してください。
たとえば、Oracleホームの/scratch/oracle/Oracle_home1のOHS_domain1というドメインの構成をコピーするには、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/oracle/jdk1.7.0_17 -archiveLoc /tmp/stdalone_dom.jar -sourceDomainLoc /scratch/oracle/domains/OHS_domain1 -sourceOracleHomeLoc /scratch/oracle/Oracle_home1/
このスクリプトを実行する前に、ノード・マネージャを停止する必要はありません。
構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
ソースでextractMovePlanスクリプトを使用して、copyConfigスクリプトにより作成したアーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。
次に例を示します。
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/stdalone_dom.jar -planDirLoc /tmp/Oracle/t2p_plans/
注意: ソース環境に変更を加えていなくても、copyConfigスクリプトを使用するたびに、新しい移動計画を抽出する必要があります。pasteConfigスクリプトによって、移動計画とアーカイブが一致することが確認されます。一致しない場合は、スクリプトによりエラーが返されます。 |
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。移行するコンポーネントのタイプごとのプロパティのリストについては、表A-11を参照してください。
編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。
ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、第A.1.2.7項を参照してください。
たとえば、アーカイブをOracleホーム/scratch/oracle/Oracle_home1に適用するには、次のコマンドを使用します。
pasteConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/stdalone_dom.jar -targetDomainLoc /scratch/oracle/config/domains/dom_cl -targetOracleHomeLoc /scratch/oracle/Oracle_home1 -movePlanLoc /tmp/Oracle/t2p_plans/move_plan.xml -logDirLoc /tmp/log
ノード・マネージャがソース環境で構成される場合は、次の条件でノード・マネージャを別途移行する必要があります。
ノード・マネージャは「ホストごと」です。
複数ホストの環境で、ノード・マネージャは「ドメインごと」で構成はドメイン・ディレクトリ内にあるが、各ホストにはそのホストにだけ適用可能な、カスタマイズされたノード・マネージャ・プロパティがある。
ノード・マネージャがドメインごとの場合、ドメインを移行するためのスクリプトにより、ノード・マネージャも移行されます。
ノード・マネージャの構成を移行する手順は、次のとおりです。
ソースにおいて、ノード・マネージャが実行されていることを確認します。
ソースでcopyConfigスクリプトを実行して、ノード・マネージャ構成をコピーします。
スクリプトの構文については、第A.1.2.5項を参照してください。たとえば、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/nm.jar -sourceNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager -logDirLoc /tmp/logs
ノード・マネージャを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
ソースでextractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。
次に例を示します。
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/nm.jar -planDirLoc /tmp/Oracle/t2p_plans/nm
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ノード・マネージャのプロパティのリストについては、表A-12と表A-13を参照してください。
編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。
ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、第A.1.2.9項を参照してください。
たとえば、次のコマンドを使用します。
pasteConfig -javaHome /scratch/oracle/jdk1.7.7.0_17 -archiveLoc /tmp/nm.jar -targetNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager -targetOracleHomeLoc /scratch/oracle/Oracle_home1 -movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml
新しいターゲット環境でセキュリティを構成する必要があります。手順は、環境およびアプリケーションの構成によって異なります。
ターゲット環境のLDAPアイデンティティ・ストアでは、ソース環境と同じユーザーおよびグループを使用しない可能性や、すでにユーザーおよびグループが移入されている可能性があります。LDAPストアがOracle Internet Directory LDAPストアであり、ソース環境のユーザー、グループおよびパスワードをターゲット環境に移行する必要がある場合のみ、次の手順を実行します。
ldapsearchコマンドを使用して、ソース環境のLDAPアイデンティティ・ストアからユーザーおよびグループをエクスポートします。これにより、後でターゲット環境のLDAPアイデンティティ・ストアにインポートするldifファイルが作成されます。ldapsearchコマンドは、アイデンティティ管理コンポーネントのORACLE_HOME/binディレクトリにあります。次に例を示します。
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
次の例で示すように、ldapaddmtコマンドを使用して、ソース環境からエクスポートしたldifファイルをターゲット環境にインポートします。(ORACLE_HOMEはアイデンティティ管理のOracleホームです。)
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
表20-2に、特定のコンポーネントの移行を完了するために追加の手順が必要かどうか、または追加の情報を指定する必要があるかどうかを示します。
表20-2 異なる環境への移行に追加の手順を必要とするコンポーネント
コンポーネント | 追加の手順 |
---|---|
Oracle Application Development Framework |
なし |
Oracle B2B |
|
Oracle Business Activity Monitoring |
なし |
Oracle Business Process Management |
第20.4.3項を参照 |
Oracle Coherence |
なし |
Oracle Data Integrator |
|
Oracle Enterprise Data Quality |
なし |
Oracle Enterprise Scheduler |
なし |
Oracle HTTP Server |
なし |
Oracle Managed File Transfer |
なし |
Oracle Service Bus |
|
Oracle SOA Core Extensions |
なし |
Oracle SOA Suite |
なし |
Oracle User Messaging Service |
なし |
Oracle Web Services Manager |
なし |
Oracle WebLogic Server |
なし |
Oracle Data Integratorを移行する場合は、次の追加手順が必要です。
RCUを使用して、ターゲット・データベースで必要なマスター・リポジトリおよび作業リポジトリのスキーマを作成します。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
ターゲット環境の作業リポジトリとマスター・リポジトリの両方が、それぞれ組織全体で一意のIDで作成されていることを確認します(これには、開発リポジトリとソース・リポジトリも含まれます)。さらに、ターゲットの作業リポジトリが、ソース・リポジトリと同じタイプで作成されていることを確認します(たとえば、ソースの作業リポジトリが開発リポジトリとして作成されている場合、ターゲットの作業リポジトリも開発リポジトリとして作成される必要があります)。
Oracle Data IntegratorでRCUのカスタム変数の一部として作成されたODI作業リポジトリ名は、次の例に示すように、moveplan.xmlファイルの<configProperty id="WORKREP1">として反映されます。
... <configProperty id="WORKREP1"> <configProperty> <name>Url</name> <value>jdbc:oracle:thin:@localhost:1521:ora1120</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> <configProperty> <name>User</name> <value>odi_work_11g</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> <configProperty> @ <name>Password File</name> <value>/tmp/all_pswd.txt</value> <itemMetadata> <dataType>STRING</dataType> @ <password>true</password> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> </configProperty> ...
ここで重要なのは、moveplan.xmlでWORKREP1
として反映されているデフォルトのODI作業リポジトリ名WORKREP
は変更され、対応する名前の変更が本番環境で正確に反映されて、それに従うということです。
スキーマの作成の詳細は、『リポジトリ作成ユーティリティを使用したスキーマの作成』を参照してください。その他の情報は、RCUのオンライン・ヘルプに記載されています。
移行スクリプトを実行する前に、ODI Client (Studio)を使用してプロジェクトとモデルを作成します。
copyConfigスクリプトを実行する場合は、次に注意してください。
Agentの構成時には、構成ファイルをcopyConfigスクリプトに渡す必要があります。これを渡すには、引数odiCustomArgで-additionalParamsオプションを使用します。次に例を示します。
./copyConfig.sh -javaHome /private/Middleware/jrockit_160_26_D1.2.0-5 -archiveLocation /tmp/ar.jar -sourceOracleHomeLoc /private/Middleware -sourceDomainLoc /scratch/oracle/domains/base_domain -domainHostName host1.example.com -domainPortNum 7001 -domainAdminUserName weblogic -domainAdminPasswordFile /tmp/wls_pswd.txt -additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml
ファイルodiCustomArg.xmlは構成ファイルです。サンプル・ファイルが次の場所にあります。
ORACLE_HOME/ODI_Oracle_Home/odi/plugin/t2p/odiCustomArg.xml
スクリプトに渡す構成ファイルには、すべてのOracle Data Integratorマスター・リポジトリの接続情報が含まれています。構成ファイルのサンプルを次に示します。
<?xml version="1.0" encoding="UTF-8" ?>
<config>
<masterRepositories>
<masterRepository>
<driver>oracle.jdbc.OracleDriver</driver>
<url>jdbc:oracle:thin:@localhost:1521:sid_or_service_name/example.com</url>
<schema>odi_master_12c</schema>
<schema_password_file>/tmp/all_pswd.txt</schema_password_file>
<supervisor>SUPERVISOR</supervisor>
<supervisor_password_file>/tmp/sup_pswd.txt</supervisor_password_file>
</masterRepository>
<masterRepository>
.....content for 2nd master repository
</masterRepository>
</masterRepositories>
</config>
次に構成ファイルのエントリを説明します。
masterRepositories: ODIマスター・リポジトリのリストが含まれます。
masterRepository: ODIマスター・リポジトリのセクション。
driver: ODIマスター・リポジトリに接続するためのJDBCドライバ。
url: ODIマスター・リポジトリに接続するためのJDBC URL。
schema: ODIマスター・リポジトリのスキーマ名。
schema_password_file: スキーマのパスワードを含むファイルのパス。
supervisor: ODIマスター・リポジトリのスーパーバイザ・ユーザー
supervisor_password_file: スーパーバイザ・ユーザーのパスワードを含むファイルのパス。
移行スクリプトによって、移動計画で指定した情報に基づき、ターゲット環境の物理アーキテクチャが更新されます。ターゲット環境の物理アーキテクチャの次の項目を確認してから、次に進みます。
物理エージェント: ホスト、ポートおよびWebアプリケーション・コンテキスト(Java EEエージェント用)を、ターゲット環境の構成と一致するように変更します。
データ・サーバー: データ・サーバーの接続に関する情報(JDBC、JNDI、データ・ソース名)を、ターゲット環境の構成と一致するように変更します。
物理スキーマ: データ・サーバー用に定義されたスキーマ(ファイル・フォルダの場所を含みます)は、ターゲット環境の構成と一致している必要があります。
移行の完了後に、ターゲット環境のJava EEエージェントを再起動します。これらのエージェントは、スケジュール済シナリオの処理を開始します。
移行スクリプトを実行すると、Oracle B2Bがターゲット環境に移行されます。ただし、次の追加の手順を実行する必要があります。
『Oracle Platform Security Servicesによるアプリケーションの保護』のドメイン内のキーストア・サービス・アーティファクトの移行に関する項の説明に従って、キーストア・サービス証明書を移行し、B2Bインタフェースを使用してキーストア・パスワードを更新します。
移行スクリプトの実行中にB2Bアグリーメントはデプロイされません。『Oracle B2Bユーザーズ・ガイド』のアグリーメントのデプロイに関する項の説明に従って、B2Bアグリーメントをデプロイします。
リスニング・チャネルを有効化します。
B2Bコンソールにログインし、「管理」タブ→「リスニング・チャネル」を選択します。
リスニング・チャネルを選択します。
チャネル属性タブを選択します。次に、チャネルの有効化を選択します。
「保存」をクリックします。
Oracle Business Process Managementの組織単位およびダッシュボードを新しいターゲット環境に移行するには、次の手順を実行します。
組織単位を作成するには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』のプロセス・ワークスペースでの組織単位の管理に関する項を参照してください。
ダッシュボードを移行するには、ant-t2p-workspace.xml移行ツールを使用します。移行ツールは、コマンド行で実行できるantターゲットとして使用できます。これは、この作業で説明されているとおり、データの移行用の入力パラメータを指定して作成される構成ファイルをコールします。
このスクリプトでは、BPMUserApplicationData表内の、データ型がBAM_WIDGETであるダッシュボード・データがターゲット環境に移行されます。
ソース環境内とターゲット環境内のユーザーは同じではないため、移行ツールでは、ユーザー固有の構成は移行されないことに注意してください。
次のスクリプトを使用します。
ORACLE_HOME/soa/bin/ant-t2p-workspace.xml
コマンドの形式は次のとおりです。
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE
次の手順を実行します。
PATH環境変数に、必要なJAVA_HOMEおよびANT_HOME環境変数が含まれており、それらがOracle SOA Suiteインストール内の場所を指していることを確認してください。
暗号化キーoracle.bpm.services.client.key
を環境変数として設定します。次に例を示します。
oracle.bpm.services.client.key=1XXXX6XXXXX98XXX
暗号化キーは、antコマンドに引数として渡すことでも設定できます。指定しない場合、antタスクにより入力するようプロンプトが出されます。
ソース環境からダッシュボードをエクスポートします。
構成ファイルを作成してダッシュボードをエクスポートします。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</sourceEndPoint>
<targetEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</targetEndPoint>
<operation>EXPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username
/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、次の要素でソース環境用の値を指定する必要があります。
serverURL: SOAサーバーのURL
adminUserLogin: 管理者のユーザー名
adminUserPassword: 管理ユーザーのパスワード
migrationFile: エクスポート操作によって生成されたファイル
objectDetails: ログインおよびパスワード要素
userApplicationData: 所有者ID要素
次のコマンドを使用して、ダッシュボードをエクスポートします。
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
ダッシュボードをインポートします。
構成ファイルを作成してダッシュボードをインポートします。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</sourceEndPoint>
<targetEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</targetEndPoint>
<operation>IMPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username
/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、次の要素をターゲット環境用の値で更新する必要があります。
serverURL: SOAサーバーのURL
adminUserLogin: 管理者のユーザー名
adminUserPassword: 管理ユーザーのパスワード
パスワードは、ant-t2p-workspace.xmlツールを初めて実行する際に暗号化されます。
migrationFile: エクスポート操作によって生成されたファイル
objectDetails: ログインおよびパスワード要素
パスワードは、ant-t2p-workspace.xmlツールを初めて実行する際に暗号化されます。
userApplicationData: 所有者ID要素
次のコマンドを使用して、ダッシュボードをインポートします。
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
移行のスクリプトは、新しいターゲット環境への移行を対象としています。既存の環境へのアーティファクトの移行はサポートしていません。
すでに新しいターゲットに環境を移行した場合、後になって、ソース環境で変更したアーティファクトをターゲット環境に移行したいことがあります。変更したアーティファクトの移行の詳細は、Oracle HTTP Serverなど、個々のコンポーネントのドキュメントを参照してください。
次の各項では、分散トポロジの場合の考慮事項について説明します。
ドメインが複数のホストに分散されている場合、移行を実行するためには追加の手順が必要です。
コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)
これらの手順は、管理サーバー・ホストで第20.3項の手順を実行済であることを前提としています。
共有ディスクを使用していない場合は、pasteBinaryコマンドを使用して、リモート・ホスト(たとえばHost B)にOracleホームを作成します。第20.3.2項の手順1で作成した、同じアーカイブを使用します。
次に例を示します。
pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 -archiveLoc /tmp/oh_copy.jar -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod -targetOracleHomeName ORACLE_HOME_prod
Oracle WebLogic Serverのpackとunpackコマンドを使用して、リモートの管理対象サーバーに対するドメイン・ディレクトリを再作成します。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。
Oracle Real Application Cluster (Oracle RAC)環境に、またはOracle Real Application Cluster (Oracle RAC)環境から環境を移行している場合は、次の点に注意してください。
Oracle RAC環境ではないソース環境から、Oracle RACを使用するターゲット環境に移行している場合、移動計画には、汎用データ・ソースの1つのエントリ(mds-adfなど)があります。Oracle RACインスタンスの1つを指すように移動計画を更新し、ソース環境からターゲット環境への移行を完了します。
そして、『高可用性ガイド』(特にデータベースの考慮事項に関する説明)に従って、Oracle RAC用にターゲット環境を構成します。
移動計画にリストされていない場合でも、複数のデータ・ソースがターゲット環境に移行されます。
Oracle RAC環境を使用するソース環境から、Oracle RACを使用しないターゲット環境に移行している場合、移動計画には、汎用データ・ソースの複数のエントリがあります。たとえば、4つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac4までの名前を持つ4つの汎用データ・ソースがあります。すべての汎用データ・ソースがターゲット環境のRAC以外の単一インスタンスを指すように、移動計画を更新します。
Oracle RACを使用するソース環境から、Oracle RACを使用するターゲット環境に移行しているが、ターゲット環境にそれ以外のOracle RACインスタンスがある場合、移動計画には、汎用データ・ソースで複数のエントリがあります。たとえば、ソース環境に3つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac3までの名前を持つ3つの汎用データ・ソースがあります。ターゲット環境に、4つのOracle RACインスタンスがあります。汎用データ・ソースがターゲット環境の最初の3つのデータ・ソースを指すように、移動計画を更新します。
Oracle RACを使用するソース環境から、Oracle RACを使用するターゲット環境に移行しているが、ターゲット環境にそれ以外のOracle RACインスタンスが少ない場合、移動計画には、汎用データ・ソースで複数のエントリがあります。たとえば、ソース環境に4つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac4までの名前を持つ4つの汎用データ・ソースがあります。ターゲット環境に、3つのOracle RACインスタンスがあります。最初の3つの汎用データ・ソースがターゲット環境の3つのデータ・ソースを指すように、移動計画を更新します。最後の汎用データ・ソースは、3つ目の汎用データ・ソースを指すようにします。(3つ目のOracle RACインスタンスにはmds-adf-rac3とmds-adf-rac4の両方が含まれます)。
第10.2.2.1項の説明に従って、データ・ソースを追加できます。
pasteBinaryまたはpasteConfigスクリプトを実行して移動計画に不正な情報を入力すると、スクリプトはエラーを返します。場合によっては、貼付け操作が部分的に実行されていることもあります。リカバリするには、エラーを返したスクリプトに応じて、次の処理を実行します。
Windowsで、Sun JDKを使用すると、copyBinary、pasteBinary、copyConfigまたはpasteConfigの操作が次のエラーで失敗する場合があります。
java.nio.channels.OverlappingFileLockException
この場合、T2P_JAVA_OPTIONSを使用して、システム・プロパティのsun.nio.ch.disableSystemWideOverlappingFileLockCheckを設定します。次に例を示します。
set T2P_JAVA_OPTIONS= -Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true
操作を再試行してください。
pasteConfigスクリプトを再実行して、現在の環境にOracle Platform Security Servicesを含める場合は、スクリプトを再実行する前に、ターゲット・データベースでOPSSスキーマを再作成する必要があります。
ターゲットで、Oracleホーム・ディレクトリの移行中にpasteBinaryスクリプトでエラーが返された場合の手順は、次のとおりです。
ターゲットOracleホームを削除します。
OracleインベントリにOracleホーム・エントリが存在する場合、それを削除します。
Windowsでは、Oracleホームのショートカットを削除します。
copyConfigスクリプトでは、ディレクトリが変更されないように、すべてのサーバーが実行中であり、アイドルである必要があります。サーバーがアイドルではない場合、copyConfigスクリプトはクローニング操作が正常に完了したことを報告し、copyConfigエラー・ログ・ファイルが0バイトのままとなります。ただし、copyConfig標準ログ・ファイルには、packed_domain.jarへの書込みに関するエラーが含まれます。このエラーによって、pasteConfigプロセスが失敗します。
この問題を回避するには、少しの間待機して、copyConfig操作を再試行します。
Javaコンポーネントの移行中に、pasteConfigスクリプトでエラーが返された場合は、次の手順を実行します。
ドメインに関連するすべてのプロセスを停止します。
次のディレクトリを削除します。
ORACLE_HOME/user_projects/domains/domain_name ORACLE_HOME/user_projects/applications/domain_name
スキーマを削除して、RCUを使用してそれらを再作成します。
また、Oracle Platform Securityの再割当てが失敗した場合、次の処理を実行します。
ファイルベースのストアからLDAPストアに移行している場合は、移動計画の値で別の値を指定します。
LDAPストアの場合は、ドメイン・ノードを削除します。
データベースベース・ストアでは、スキーマを削除しRCUを使用してそれを再作成します。
pasteConfigスクリプトを使用しているときにメモリー不足エラーが発生した場合は、次のいずれかの方法でこのエラーを回避できます。
JVMヒープ・サイズを拡張します。最大ヒープ・サイズにオプション-Xmxを、初期ヒープ・サイズに-Xmsを使用します。次に例を示します。
CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"
多くの場合、Oracle WebLogic Serverドメインのディレクトリ構造には、不要な大容量ファイル(大容量の古いログ・ファイルなど)が含まれています。これらのファイルを削除してから、copyConfigおよびpasteConfigスクリプトを再度実行します。
Oracle SOA SuiteインストールでcopyConfigスクリプトを使用した際に次のエラーが表示された場合は、T2P_JAVA_OPTIONS環境変数を使用して、メッセージのサイズを大きくします。
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'.
第A.1項の説明に従って、T2P_JAVA_OPTIONS環境変数を使用し、-Dweblogic.MaxMessageSize=20000000プロパティをcopyConfigとpasteConfigの両方のスクリプトに渡します。
pasteConfig操作を使用する際に、Oracle B2Bインバウンド/アウトバウンド・ディスパッチャが構成されていると、次のエラーが表示される場合があります。
oracle.mds.exception.MDSRuntimeException: java.sql.SQLException: Data Source mds-soa does not exist. Data Source mds-soa does not exist.
この状況では、失敗後に管理対象サーバーのプロセスを強制終了し、手動で管理対象サーバーを再起動します。
Oracle SOA Suite管理対象サーバーを起動しようとしてエラーが発生した場合は、pasteConfigスクリプトの実行後に管理コンソールを使用して、システム・パラメータを変更する必要があります。(これらのシステム・パラメータには、pasteConfigスクリプトによって一時的な値が設定されます。)
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
サーバーを選択します。
「サーバーの起動」タブを選択します。
「引数」フィールドで、次のパラメータを入力します。
-Dtangosol.coherence.wkan=hostname -Dtangosol.coherence.localhost=hostname -Dtangosol.coherence.localport=localport_number -Dtangosol.coherence.wka1.port=port_number_for_Coherence
「保存」をクリックして、「変更のアクティブ化」をクリックします。
サーバーを起動します。