| Oracle® Fusion Middleware Oracle Fusion Middlewareの管理 12c (12.1.2) E47968-02 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareをテスト環境などのソース環境から本番環境などのターゲット環境に移行する方法について説明します。ソース環境内でアプリケーションの開発とテストを行い、最終的にはテスト・アプリケーション、また、必要に応じてテスト・データをターゲット環境にロール・アウトできます。このアプローチは、アップグレードのテストおよびロール・アウトにも使用できます。
この章の内容は次のとおりです。
|
注意:
|
Oracle Fusion Middlewareコンポーネントをソース環境からターゲット環境に移行できます。
Oracle Fusion Middlewareコンポーネントを移行しない場合、移行元の環境で行ったカスタマイズや構成変更は、移行先の環境にすべて再適用する必要がありますが、コンポーネントを移行することにより、このような作業が最小化されます。ソース環境では、Oracle Fusion Middlewareのインストール、構成、カスタマイズおよび検証を行うことができます。システムが安定し、必要に応じて機能するようになったら、ターゲット環境を作成しますが、このとき、ソース環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをソース環境から移行することでターゲット環境を作成できます。
この章では、環境を移行する前に知っておく必要がある重要な情報について説明します。内容は次のとおりです。
Oracle Fusion Middlewareには、環境の移行に使用できる一連のスクリプトが用意されています。
copyBinary: ソースOracleホームのバイナリ・ファイルをコピーします。
pasteBinary: コピーしたOracleホームをターゲットに適用します。
copyConfig: 次のいずれにも使用できます。
WebLogic Serverドメインの構成をコピーします(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)
スタンドアロン・ドメインの構成をコピーします(ドメイン内のすべてのシステム・コンポーネントを含む)
ノード・マネージャの構成をコピーします。
extractMovePlan: ドメインまたはコンポーネントから移動計画を抽出します。
pasteConfig: 次のいずれにも使用できます。
コピーされたWebLogic Serverドメインの構成を適用します(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)
コピーされたスタンドアロン・ドメインの構成を適用します(ドメイン内のすべてのシステム・コンポーネントを含む)
コピーされたノード・マネージャの構成を適用します。
こうしたスクリプトにより、ユーザーはOracleホーム・ドメインおよびOracle WebLogic Serverドメイン、ならびにOracle HTTP Serverなどの特定のOracle Fusion Middlewareコンポーネントの構成をコピーできます。
表20-1は、移行スクリプトをサポートしているOracle Fusion Middlewareコンポーネントを示しています。
表20-1 移行スクリプトのサポート
| コンポーネント | サポートの有無 |
|---|---|
|
Oracle Application Development Framework |
はい |
|
Oracle Coherence |
はい |
|
Oracle Data Integrator |
はい |
|
Oracle HTTP Server |
はい |
|
Oracle HTTP Server WebGate |
はい |
|
Oracle Platform Security Services |
はい |
|
Oracle User Messaging Service |
はい |
|
Oracle Web Services Manager |
はい |
|
Oracle WebLogic Server |
はい |
この章の手順では、次の一部またはすべてが含まれる、Oracle Fusion Middlewareのインストールおよび構成がソース環境で行われていることを想定しています。
Oracle Fusion Middlewareコンポーネントに使用される1つ以上のデータベースをインストールしました。
RCUを使用してソース環境で必要なスキーマを作成しました。『Repository Creation Utilityによるスキーマの作成』を参照してください。
Oracle Fusion Middleware製品をインストールし、構成しました。たとえば、Oracle WebLogic ServerとOracle Web Services Managerをインストールし、Oracleホームを作成し、Oracle WebLogic Serverドメインを構成しました。
ドメインを構成するときには、2つの方法のいずれかを選択できます。
開発モード: このモードでは、セキュリティの構成が比較的緩くなります。アプリケーションのデプロイには、ユーザー名とパスワードが必要です。
本番モード: このモードでは、セキュリティの構成が比較的厳格で、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要です。
または、スタンドアロン・ドメインにシステム・コンポーネント(Oracle HTTP Serverなど)をインストールおよび構成しました。
セキュリティ・ポリシーを構成しました。
Oracle Platform Securityの場合、セキュリティ・ポリシーおよび格納済の資格証明を資格証明ストア・フレームワーク(CSF)に作成しました。
1つ以上のアプリケーションをデプロイしました。これらのアプリケーションには、内部参照および外部参照が含まれる場合があります。
WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、管理サーバーと管理対象サーバーが実行されていることを確認してください。
Oracle Web Services Managerの場合は、copyConfigスクリプトを実行する前に、Oracle Web Services Managerポリシー・マネージャ・アプリケーションのデプロイ先のサーバーが実行されている必要があります。
この章の手順を使用するには、ターゲット環境が次の前提条件を満たしている必要があります。
コピーするOracleホームおよびコンポーネントのバージョンと互換性のあるcloningclient.jarファイルおよび移行スクリプトを使用する必要があります。この章の手順では、現行バージョンのcloningclient.jarファイルおよび移行スクリプトを使用することを前提としています。
ターゲット環境は、ソース環境と同じオペレーティング・システム上にある必要があります。また、オペレーティング・システム・アーキテクチャは、両方の環境で同じでなければなりません。たとえば、両方の環境で32ビットのオペレーティング・システムまたは64ビットのオペレーティング・システムを実行している必要があります。
スクリプトを実行するときに、対応するJavaホームを指定する必要があります。つまり、Oracleホームが64ビットの場合、64ビットのJavaホームを指定する必要があります。Oracleホームが32ビットの場合、32ビットのJavaホームを指定する必要があります。
ターゲット環境では、ソース環境のユーザーと同じスーパーユーザーまたは管理ユーザーが必要です。インストールの移行が完了したら、ターゲット環境でユーザーを変更できます。
ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースが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スキーマ名です。
ホストには、JDK 1.7.0_15以降がインストールされている必要があります。また、PATH、CLASSPATH、およびJAVA_HOME環境変数がJDKを指していることを確認してください。
たとえば、CLASSPATH変数には次のコマンドが含まれている必要があります。
$ORACLE_HOME/lib:/scratch/jdkn/lib
Oracle Fusion MiddlewareがインストールされていないホストにOracleホームのアーカイブを適用する場合、次の点に注意してください。
ソース・ホストの次の場所からpasteBinaryスクリプトをターゲット・ホストにコピーします。
(UNIX) ORACLE_COMMON_HOME/bin/pasteBinary.sh (Windows) ORACLE_COMMON_HOME\bin\pasteBinary.cmd
ソース・ホストの次の場所から次のファイルをターゲット・ホストにコピーします。
(UNIX) ORACLE_COMMON_HOME/jlib/cloningclient.jar (Windows) ORACLE_COMMON_HOME\jlib\cloningclient.jar
pasteBinaryスクリプトをORACLE_COMMON_HOME/bin以外の場所から実行する場合、pasteBinaryスクリプトとcloningclient.jarファイルは同じディレクトリに存在する必要があります。
前のOracle Fusion MiddlewareインストールがないホストでpasteBinaryを実行する場合、pasteBinaryを実行する前にORACLE_COMMON_HOME/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が同じである必要があります。たとえば、ソースでJava SEを使用する場合は、ターゲットでもJava SEを使用する必要があります。さらに、ベンダーは同じである必要があります。たとえば、ソースでOracle JDKを使用する場合は、ターゲットでもOracleのJDKを使用する必要があります。
ソースとターゲットで使用されているJDKが同じである必要があります。たとえば、ソースでJava SEを使用する場合は、ターゲットでもJava SEを使用する必要があります。
ソースおよびターゲットで使用されるベンダーは同じである必要があります。たとえば、ソースでOracle JDKを使用する場合は、ターゲットでもOracleのJDKを使用する必要があります。
ソースおよびターゲットで使用されるJDKのメジャー・バージョンは、同じである必要があります。たとえば、ソースでバージョン1.7を使用する場合は、ターゲットでも1.7を使用する必要があります。
エンティティを移行する際に一時ディレクトリに十分な領域がない場合は、その旨を示すエラーが返されます。この問題が発生しないようにするには、第A.1.1項で説明しているように、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は同じドメイン・コンポーネントの階層を持っている必要があります。
環境にIPV4とIPV6の両方のプロトコルが含まれている場合は、移動計画を更新するときに、いずれかのIPアドレスでIPV4プロトコルを使用する必要があります。
この項では、インストールをソース環境からターゲット環境に移行する一般的な手順について説明します。表20-1に、この手順を示すフローチャートを表示します。
一般的な手順は次のとおりです。
ソース環境をチェックします。第20.2.2項を参照してください。
ターゲット環境を準備します。第20.2.3項を参照してください。
環境でデータベースを使用している場合は、新しいデータベースを作成します。第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.3.8項を参照してください。
Oracle Fusion Middlewareコンポーネントの多くで、ソース環境からターゲット環境に移行する際に、共通の手順を使用します。ただし、すべてのコンポーネントがこれらの手順のすべてまたはそれらの一部を使用するわけではありません。また、一部コンポーネントでは追加の手順が必要な場合があります。特定のコンポーネントを移行する際に追加の手順が必要かどうか、表20-2でチェックする必要があります。
この項では、共通の手順について、次のとおり説明します。
この項の手順では、標準的なインストール・トポロジが使用されていると仮定しています。このトポロジは、1つの管理サーバーを含む1つのWebLogic Serverドメインと、1つのホスト上の2つの管理対象サーバーまたはシステム・コンポーネントを含むスタンドアロン・ドメインが含まれているクラスタで構成されます。
複数のマシンにわたる分散トポロジの場合は、第20.6項を参照してください。
|
注意: これらの手順および移動計画で使用するスクリプトでは、通常、パスワードを含むファイルを指定する必要があります。不明瞭化したパスワードを含むファイルを生成するには、第A.1.1.10項で説明されているobfuscatePasswordスクリプトを使用します。 |
Oracle Application Development Frameworkなどの一部のコンポーネントでは、メタデータを格納するためにデータベースを使用する場合があります。
ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースがOracle Databaseである場合、ターゲット環境のデータベースもOracle Databaseである必要があります。ターゲット環境のデータベースは、ソース環境のデータベースと同じバージョンである必要があります。
新しいデータベースをインストールする手順は次のとおりです。
データベース・ソフトウェアをインストールして構成します。
RCUを使用してターゲット・データベースで必要なスキーマを作成します。『Repository Creation Utilityによるスキーマの作成』を参照してください。
アプリケーションで使用するカスタム・スキーマを作成します。たとえば、アプリケーションがソース環境でカスタム・スキーマを使用する場合、ターゲット環境でそのスキーマを作成します。
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.1.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
-invPtrLoc /scratch/oracle/oraInst.loc
Oracleホームを別のホストにコピーする場合は、アーカイブ・ファイルをそのシステムにコピーするか、または、ストレージ・レベルのクローニングを使用している場合は、ボリュームのスナップショット・コピーをターゲット・システムにコピーし、そのボリュームをマウントします。
pasteBinaryスクリプトとcloningclient.jarファイルをターゲット・システムにコピーし、実行権限があることを確認します。
cloningclient.jarファイルは次の場所にあります。
(UNIX) ORACLE_COMMON_HOME/jlib/cloningclient.jar (Windows) ORACLE_COMMON_HOME\jlib\cloningclient.jar
pasteConfigなど他のスクリプトをコピーしないでください。これらのスクリプトは、ステップ5で説明しているように、ファイルの抽出時に生成されます。
LinuxとUNIXでは、インストールされているOracle製品がターゲット・システムにない場合、oraInst.locファイルを作成し、Oracleインベントリ(oraInventory)に対する書込みアクセス権が付与されているメンバーの所属グループとOracleインベントリの格納先を指定する必要があります。たとえば、oraInst.locファイルには次を含めることができます。
inst_group=dba inventory_loc=/scratch/oracle1/oraInventory
そして、その場所がデフォルトの場所(/etc/oraInst.loc.)ではない場合、-invPtrLocオプションをpasteBinaryスクリプトに使用して、oraInst.locファイルの場所を指定します。
クローニング先で、pasteBinaryスクリプトを使用して、アーカイブからファイルを抽出します。pasteBinaryスクリプトの構文については、A.1.1.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
Oracleホームは/scratch/oracle/ORACLE_HOME_prodに抽出され、製品ホームはソースの製品ホームの名前と同じ名前でその下に抽出されます。
copyBinaryおよびpasteBinaryスクリプトにより、Oracleホーム内の任意のドメイン・ディレクトリがコピーおよび貼り付けられますが、user_projectsディレクトリ下のドメイン・ディレクトリはコピー、貼り付けられません。これらのドメイン・ディレクトリは正しく構成されていないので、機能しません。
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.1.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パラメータを使用して変更できます。 |
ドメイン構成のコピーを移行する手順は、次のとおりです。
ソースで、管理サーバーおよびすべての管理対象サーバーが起動されていることを確認します。
ソースで、自動的にロックを取得するようにドメイン構成が設定されていないことを確認します。開発モードでドメインを構成した場合は、ロックの自動取得が有効になっています。本番モードでドメインを構成した場合は、デフォルトで無効になっています。次の手順を実行します。
管理コンソールで「プリファレンス」をクリックします。
「プリファレンス」タブで、「ロックを自動取得して変更をアクティブ化」の選択を解除します。
「保存」をクリックします。
「チェンジ・センター」で、該当する場合は「構成の解放」をクリックします。
ソースでcopyConfigスクリプトを実行して、ドメイン構成をコピーします。
copyConfigスクリプトは、次の場所にあります。
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
copyConfigスクリプトの構文については、A.1.1.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
ドメイン構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
ソースでextractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、A.1.1.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を参照してください。
編集した移動計画をターゲットにコピーします。(pasteConfig操作の間、-movePlanLocオプションを使用して場所を指定します。)
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれる場所の入力を求めるプロンプトが表示されます。
ターゲットで、copyConfig操作中に-opssDataExportパラメータがtrueに設定された場合(デフォルトでtrueに設定されます)、初期ヒープ・サイズおよび最大ヒープ・サイズを設定する、次の環境変数を設定する必要があります。
CONFIG_JVM_ARGS "-Xmx2048M -Xms2048M"
ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、A.1.1.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.1.4項を参照してください。
たとえば、Oracleホーム/scratch/oracle/Oracle_home1のWLS_domain1という構成をコピーするには、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/oracle/jdk1.7.0_17
-archiveLoc /tmp/a.jar
-sourceDomainLoc /scratch/oracle/domains/WLS_domain1
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1/
構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
ソースでextractMovePlanスクリプトを使用して、copyConfigスクリプトにより作成したアーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、A.1.1.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を参照してください。
編集した移動計画をターゲットにコピーします。(pasteConfig操作の間、-movePlanLocオプションを使用して場所を指定します。)
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれる場所の入力を求めるプロンプトが表示されます。
ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、A.1.1.7を参照してください。
たとえば、アーカイブをOracleホーム/scratch/oracle/Oracle_home1に適用するには、次のコマンドを使用します。
pasteConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
-archiveLoc /tmp/java_ee_cl.jar
-targetDomainLoc /scratch/oracle/config/domains/dom_cl
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /scratch/oracle/java_ee/move_plan.xml
-logDirLoc /tmp/log
ノード・マネージャがソース環境で構成される場合は、次の条件でノード・マネージャを別途移行する必要があります。
ノード・マネージャは「マシンごと」。
ノード・マネージャは「ドメインごと」だが、構成はドメイン・ディレクトリの外部にある。
複数ホストの環境で、ノード・マネージャは「ドメインごと」で構成はドメイン・ディレクトリ内にあるが、各ホストにはそのホストにだけ適用可能な、カスタマイズされたノード・マネージャ・プロパティがある。
ノード・マネージャがドメインごとの場合、ドメインを移行するためのスクリプトにより、ノード・マネージャも移行されます。
ノード・マネージャの構成を移行する手順は、次のとおりです。
ソースでcopyConfigスクリプトを実行して、ノード・マネージャ構成をコピーします。
スクリプトの構文については、A.1.1.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.1.6項を参照してください。
次に例を示します。
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
-archiveLoc /tmp/nm.jar
-planDirLoc /tmp/Oracle/t2p_plans/nm
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ノード・マネージャのプロパティのリストについては、表A-14を参照してください。
編集した移動計画をターゲットにコピーします。(pasteConfig操作の間、-movePlanLocオプションを使用して場所を指定します。)
ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれる場所の入力を求めるプロンプトが表示されます。
ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、A.1.1.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 Coherence |
なし |
|
Oracle Data Integrator |
第20.4.1項を参照 |
|
Oracle HTTP Server |
なし |
|
Oracle User Messaging Service |
なし |
|
Oracle Web Services Manager |
なし |
|
Oracle WebLogic Server |
なし |
Oracle Data Integratorを移行する場合は、次の追加手順が必要です。
RCUを使用して、ターゲット・データベースで必要なマスター・リポジトリおよび作業リポジトリのスキーマを作成します。『Repository Creation Utilityによるスキーマの作成』を参照してください。
ターゲットの作業リポジトリが、ソース・リポジトリと同じタイプで作成されていることを確認します(たとえば、ソースの作業リポジトリが開発リポジトリとして作成されている場合、ターゲットの作業リポジトリも開発リポジトリとして作成される必要があります)。
copyConfigスクリプトを実行する場合は、次に注意してください。
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 -domainPortNo 7001 -domainAdminUserName weblogic -domainAdminPasswordFile /tmp/wls_pswd.txt -additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml
ファイルodiCustomArg.xmlは構成ファイルです。サンプル・ファイルが次の場所にあります。
ORACLE_HOME/ODI_Oracle_Home/odi/pluggin/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_11g</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 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
操作を再試行してください。
ターゲットで、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スクリプトを再度実行します。
