6 BAMを追加するためのドメインの拡張

この章は、Oracle Business Activity Monitoring（BAM）をエンタープライズ環境で使用するユーザーを対象としています。この項の内容は次のとおりです。

• 第6.1項「ドメインへのBAMの追加の概要」

• 第6.2項「BAMの追加によるドメインの拡張」

• 第6.3項「soa-createUDD.pyスクリプトの実行」

• 第6.4項「BAM UMS用のJMS永続ストアの構成」

• 第6.5項「トランザクション・リカバリ用デフォルト永続ストアの構成」

• 第6.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」

• 第6.7項「pack/unpackユーティリティを使用した、BAMHOST1およびBAMHOST2へのドメイン構成の伝播」

• 第6.8項「WLS_BAMn管理対象サーバーに対するホスト名検証の無効化」

• 第6.9項「BAMHOST1およびBAMHOST2でのノード・マネージャの起動」

• 第6.10項「BAMシステムの起動」

• 第6.11項「BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成」

• 第6.12項「適切なBAMサーバー・アドレスを使用するためのADCサーバーの構成」

• 第6.13項「WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成」

• 第6.14項「Oracle HTTP Serverを介したアクセスの検証」

• 第6.15項「WLS_BAMサーバーのサーバー移行の構成」

• 第6.16項「インストールのバックアップ」

6.1 ドメインへのBAMの追加の概要

BAMシステムは、第4章「ドメインの作成」で作成したWL_HOMEおよびORACLE_HOMEを使用して共有記憶域にインストールします。BAMHOST1およびBAMHOST2は、ORACLE_BASE/product/fmwをマウントして、既存のWLSおよびSOAのインストールを再利用します。packユーティリティおよびunpackユーティリティを使用して、この2つの新しいノードでWLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。BAMシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle FMWをインストールするときに必要としたシステム構成と同一の構成をBAMHOST1およびBAMHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。

バックアップの実行

構成ウィザードを使用する前に、Oracle Fusion Middlewareの管理者ガイドの説明に従って、ドメインをバックアップする必要があります。

この項では、第4章「ドメインの作成」で作成したドメインにBAMを追加する方法を説明します。

注意: 第5章「SOAコンポーネントを使用するためのドメインの拡張」の説明に従って、すでにドメインにSOAコンポーネントが追加済となっていることもあります。

• 手順1: BAMを追加するためのドメインの拡張

• 手順2: soa-createUDD.pyスクリプトの実行

• 手順3: BAM UMS用のJMS永続ストアの構成

• 手順4: トランザクション・リカバリ用デフォルト永続ストアの構成

• 手順5: WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除

• 手順6: pack/unpackユーティリティを使用した、BAMHOST1およびBAMHOST2へのドメイン構成の伝播

• 手順7: BAMHOST1およびBAMHOST2でのノード・マネージャの起動

• 手順8: BAMシステムの起動

• 手順9: BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成

• 手順10: 適切なBAMサーバー・アドレスを使用するためのADCサーバーの構成

• 手順11: WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成

• 手順12: WLS_BAMサーバーのサーバー移行の構成

6.2 BAMを追加するためのドメインの拡張

この手順では、第4章「ドメインの作成」で作成したドメインを、BAMを扱うことができるように拡張します。この項の手順は、SOAのデプロイメントと同じデータベース・サービス（soaedg.mycompany.com）をBAMのデプロイメントでも使用することを前提としています。ただし、BAM専用の別のデータベース・サービスをデプロイメントに使用することもできます。

注意: 次の手順を実行する前に、Oracle Fusion Middlewareの管理者ガイドの説明に従ってドメインをバックアップしておきます。

注意: BAMでは、BAMサーバーを実行する管理対象サーバーに仮想IP（VIP）を使用します。BAMHOST1マシン（BAMHOST1上のBAMHOST1VHN1）でVIPを有効にする必要があります。VIPを有効にするには、第4.3項「SOAHOST1でのSOAHOST1VHN1の有効化」で説明している手順に従ってください。

1. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。

   SOAHOST1> cd ORACLE_BASE/product/fmw/soa/common/bin
   

2. 構成ウィザードを起動します。

   SOAHOST1> ./config.sh
   

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリ（ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>）を選択し、「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、次の手順を実行します。

   • 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

   • 次の製品を選択します。

     • Oracle Business Activity Monitoring 11.1.1.1

   「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマの構成」画面（図6-1）で、次の手順を実行します。

   1. 「BAM Schema」を選択します。

   2. 「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。

   3. 「次へ」をクリックします。

   図6-1 「JDBCコンポーネント・スキーマの構成」画面

   
   「図6-1 「JDBCコンポーネント・スキーマの構成」画面」の説明
   
   

7. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面（図6-2）で、次の手順を実行します。

   1. 「BAM Schema」を選択します。その他のデータ・ソースはそのままにします。

   2. 次の各フィールドに値を入力して、RCUでシードされたRACデータベースの接続情報を指定します。

      • ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

      • サービス名: データベースのサービス名を入力します（soaedg.mycompany.comなど）。

      • ユーザー名: スキーマの完全なユーザー名（接頭辞を含む）を入力します。図6-2に示すユーザー名では、RCUから作成されたスキーマの接頭辞にsoedgが使用されたことが前提となっています。

      • パスワード: スキーマへのアクセスに使用するパスワードを入力します。

   3. 「追加」をクリックし、最初のRACインスタンスの詳細を入力します。

   4. この手順をRACインスタンスごとに実行します。

      
      

      注意: SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマの情報はそのままにしておきます。

      
      

   5. 「次へ」をクリックします。

   図6-2「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

   
   「図6-2 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明
   
   

8. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。

   すべての接続に成功したら「次へ」をクリックします。

9. 「オプションの構成」画面で、次の項目を選択します。

   • 管理対象サーバー、クラスタ、およびマシン

   • デプロイメントとサービス

10. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。

    bam_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_BAM1に変更し、WLS_BAM2という新しいサーバーを追加します。表6-1に示す属性をこれらのサーバーに割り当てます。この画面に表示されている他のサーバーは、このまま変更しません。

    表6-1 管理対象サーバー

    名前	リスニング・アドレス	リスニング・ポート	SSLリスニング・ポート	SSL有効
    WLS_BAM1	VIP4	9001	n/a	いいえ
    WLS_BAM2	BAMHOST2	9001	n/a	いいえ

    
    

    「次へ」をクリックします。

11. 「クラスタの構成」画面で、表6-2に示す次のクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。

    表6-2 クラスタ

    名前	クラスタ・メッセージング・モード	マルチキャスト・アドレス	マルチキャスト・ポート	クラスタ・アドレス
    BAM_Cluster	ユニキャスト	n/a	n/a	空白

    
    

    「次へ」をクリックします。

12. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

    • BAM_Cluster

      • WLS_BAM1

      • WLS_BAM2

    「次へ」をクリックします。

13. 「マシンの構成」画面で、次の手順を実行します。

    • デフォルトで表示される「LocalMachine」を削除します。

    • 「Unixマシン」タブをクリックします。マシンBAMHOST1およびBAMHOST2を追加して、次のように入力します。

      表6-3 マシン

      名前	ノード・マネージャのリスニング・アドレス
      SOAHOST1	SOAHOST1
      SOAHOST2	SOAHOST2
      BAMHOST1	BAMHOST1
      BAMHOST2	BAMHOST2

      
      

    その他すべてのフィールドはデフォルト値のままにします。

    「次へ」をクリックします。

14. 「サーバーのマシンへの割当」画面で、次の項目を追加します。

    • WLS_BAM1をBAMHOST1に割り当てます。

    • WLS_BAM2をBAMHOST2に割り当てます。

    「次へ」をクリックします。

15. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • usermessagingserverおよびusermessagingdriver-emailは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定する必要があります（usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです）。

    • WSM-PMはWSM-PM_Clusterにのみターゲット設定する必要があります。

    • 「DMSアプリケーション」は、BAM_Cluster、SOA_Cluster、WSM-PM_Clusterおよび「管理サーバー」にターゲット設定する必要があります。

    • oracle.rules.*、oracle.sdp.*の各デプロイメントは、SOA_ClusterおよびBAM_Clusterにターゲット設定する必要があります。oracle.soa.*デプロイメントは、SOA_Clusterにのみターゲット設定する必要があります。

    • oracle.wsm.seedpoliciesライブラリは、WSM-PM_Clusterにのみターゲット設定する必要があります。

    • oracle.bamは、BAM_Clusterにのみターゲット設定する必要があります。

    「次へ」をクリックします。

16. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • OWSM起動クラスは、WSM_Clusterにのみターゲット設定する必要があります。

    • mds-owsm、mds-owsm-rac0およびmds-owsm-rac1は、WSM-PM_ClusterおよびAdminServerの両方にターゲット設定する必要があります。

    • mds-soa、mds-soa-rac0およびmds-soa-rac1は、SOA_ClusterおよびAdminServerの両方にターゲット設定する必要があります

    • OraSDPMDatasource、OraSDPMDatasource-rac0およびOraSDPMDatasource-rac1は、SOA_ClusterおよびBAM_Clusterの両方にターゲット設定する必要があります。

17. 「次へ」をクリックします。

18. 「構成のサマリ」画面で、「拡張」をクリックします。

    
    

    注意: ドメインを拡張するので、「構成のサマリ」画面に表示されている値は変更しないでください。

    
    

19. ドメインのポートの競合に関する警告ダイアログで「OK」をクリックします。

20. 「ドメインの作成中」画面で、「完了」をクリックします。

21. 管理サーバーを再起動して、ここまでの変更を有効にします。

6.2.1 管理サーバーの再起動

管理サーバーを再起動して、変更内容をドメインにコミットします。

1. 次の手順で管理サーバーを停止します。

   SOAHOST1> cd ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/bin
   SOAHOST1> ./stopWebLogic.sh
   

2. 次の手順で管理サーバーを起動します。

   SOAHOST1> ./startWebLogic.sh
   

   SOAHOST1> cd /u01/app/oracle/product/11.1.1/wls/user_projects/domains/wcdomain/bin
   SOAHOST1> cd ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/bin
   SOAHOST1> ./startWebLogic.sh
   

6.2.2 BAM JDBCデータ・ソースのキャッシュ・サイズの構成

BAM JDBCデータ・ソースの場合、文キャッシュ・サイズ・パラメータを0に設定する必要があります。これはデータベースの単一インスタンスに対して構成ウィザードを実行する場合のデフォルト設定ですが、RACデータベースに対して構成ウィザードを実行する場合、BAM JDBCデータ・ソースについては文キャッシュ・サイズが設定されません。この場合は、Oracle WebLogic Server管理コンソールを使用して文キャッシュ・サイズを構成する必要があります。

注意: BAMデータ・ソースをOracle WebLogic Server管理コンソールで使用できるようにするには、管理サーバーを再起動し、構成ウィザードで発生した変更内容をコミットする必要があります。

文キャッシュ・サイズを構成する手順は次のとおりです。

1. 「ロックして編集」をクリックします。

2. 「ドメイン構造」ウィンドウの「サービス」ノードを開きます。

3. 「JDBC」ノードを開き、「データ・ソース」を選択します。「JDBCデータ・ソースの概要」ページが表示されます。

4. 表の「名前」列の「BAMDataSource-rac0」をクリックします。「設定」ページが表示されます。

5. 「接続プール」タブをクリックします。

6. 「文キャッシュ・サイズ」フィールドに0を入力します。

7. 「保存してアクティブ化」をクリックします。

8. この手順をBAMDataSource-rac1でも実行します。

6.3 soa-createUDD.pyスクリプトの実行

SOAHOST1でWLS_BAM1管理対象サーバーを起動するには、その前にオフラインでWLSTを使用してsoa-createUDD.pyスクリプトを実行する必要があります。このスクリプトは<ORACLE_HOME>/bin/soa-createUDD.pyにあります。

1. setDomainEnv.shスクリプトを実行して環境を設定します。

   SOAHOST1> ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/bin/setDomainEnv.sh
   

2. soa-createUDD.pyスクリプトを実行します。このスクリプトは、ORACLE_BASE/product/fmw/soa/binディレクトリにあります。

   SOAHOST1> ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20/bin/java weblogic.WLST ORACLE_BASE/product/fmw/soa/bin/soa-createUDD.py
   --domain_home ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>
   --bamcluster BAM_Cluster
   --extend=true
   

   
   

   注意: この場合、SOAコンポーネントに対してsoa-CreateUDD.pyスクリプトをすでに実行済で（第5章「SOAコンポーネントを使用するためのドメインの拡張」を参照）、ここではBAMを扱うためのドメインの拡張にこのスクリプトを使用することを前提としています。このスクリプトは、その他のモデルにも使用できます。その例として、JMSシステムを1つのパスで構成してSOAとBAMの両方を同時に扱うモデルや、BAM専用にJMSシステムを構成するモデルがあります。このスクリプトの様々なオプションの詳細は、soa-createUDD.pyスクリプト・ファイルを参照してください。

   
   

3. 管理サーバーを再起動します。第6.2.1項「管理サーバーの再起動」の手順を参照してください。

4. Oracle WebLogic Server管理コンソールにログインします。

5. 「ドメイン構造」ウィンドウで、「サービス」→「メッセージング」を開きます。

6. 「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。

7. 表の「名前」列で「UMSJMSSystemResource」（これはハイパーリンクとして表示されています）をクリックします。

8. 「サブデプロイメント」タブをクリックします。

9. UMSJMSSubDMSOAを除くすべてのサブデプロイメントを削除します。

10. Oracle WebLogic Server管理コンソールにアクセスします。

11. 「ドメイン構造」ウィンドウで、「サービス」→「メッセージング」を開きます。

12. 「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。

13. 表の「名前」列で「UMSJMSSystemResource」（これはハイパーリンクとして表示されています）をクリックします。

14. 「ターゲット」をクリックします。

15. ターゲットとしての「BAMクラスタ」の選択を解除します。

16. 「保存してアクティブ化」をクリックします。

17. 次のモジュールがOracle WebLogic Server管理コンソールに表示されることを確認します。

    • SOAJMSModuleUDDs

      Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージング」ノードを開きます。「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で「SOAJMSMOduleUDDS」（これはハイパーリンクとして表示されています）をクリックします。「サブデプロイメント」タブをクリックします。「SOAJMSSubDM」をクリックします。

      このモジュールが、「SOAJMSServer_auto_1」と「SOAJMSServer_auto_2」にターゲット設定されていることを確認します。

    • UMSJMSSystemResource

      Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージング」ノードを開きます。「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で「UMSJMSSystemResource」（これはハイパーリンクとして表示されています）をクリックします。「サブデプロイメント」タブをクリックします。「UMSJMSSubDMSOA」をクリックします。

      このモジュールが、「UMSJMSServer_auto_1」と「UMSJMSServer_auto_2」にターゲット設定されていることを確認します。

    • BAMJMSModuleUDDs

      Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージング」ノードを開きます。「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で「BAMJMSModuleUDDs」（これはハイパーリンクとして表示されています）をクリックします。「サブデプロイメント」タブをクリックします。「BAMJMSSubDM」をクリックします。

      このモジュールが、「BAMJMSServer_auto_1」と「BAMJMSServer_auto_2」にターゲット設定されていることを確認します。

    • UMSJMSModuleUDDsBAM

      Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージング」ノードを開きます。「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で「UMSJMSModuleUDDsBAM」（これはハイパーリンクとして表示されています）をクリックします。「サブデプロイメント」タブをクリックします。「UMSJMSSubDMBAM」をクリックします。

      このモジュールが、「UMSJMSServer_auto_3」と「UMSJMSServer_auto_4」にターゲット設定されていることを確認します。

6.4 BAM UMS用のJMS永続ストアの構成

すべての永続ストアの場所を、両ノードから認識できるディレクトリとして構成します。詳細は、第4.1項「Oracle Fusion Middlewareホームのインストール」を参照してください。次のように、この共有ベース・ディレクトリを使用するようにすべての永続ストアを変更する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「サービス」ノードを開き、「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。

3. 表の「名前」列で、永続ストア「UMSJMSFileStore_auto_3」（これはハイパーリンクとして表示されています）を選択します。その永続ストアの「設定」ページが表示されます。

4. 「構成」タブの「ディレクトリ」フィールドに、クラスタにある他のサーバーで使用できる永続記憶域ソリューション（NASやSANなど）上の場所を入力します。この場所を指定すると、JMSの保留メッセージを送信できます。この場所は、次のディレクトリ構造であることが必要です。

   ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms/UMSJMSFileStore_auto_3
   

5. 「保存してアクティブ化」をクリックします。

6. この手順をUMSJMSFileStore_auto_4についても実行します。

6.5 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク（SAN）をこの場所とすることをお薦めします。

デフォルトの永続ストアに場所を設定するには、WLS_BAM1とWLS_BAM2について次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

3. 表の「名前」列にあるサーバーの名前（ハイパーリンクとして表示されています）をクリックします。選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

4. 「サービス」タブをクリックします。

5. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

   ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
   

6. 「保存」をクリックします。

注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_BAM1とWLS_BAM2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

6.6 WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除

BAMのBAMサーバー・コンポーネントはシングルトンなので、そのコンポーネントをサーバー移行用に構成する前に、いずれかのWLS_BAMサーバーのターゲット設定を解除する必要があります。

次の手順では、BAMサーバーのランタイムをWLS_BAM2から削除します。この手順を実行して、WLS_BAM2からBAMサーバー・アーティファクトのターゲット設定を解除します。

1. http://SOAHOST1VHN1:7001/consoleのOracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 表の「名前」列で「WLS_BAM2」を選択します。WLS_BAM2の「設定」ページが表示されます。

4. 「デプロイメント」タブをクリックします。

5. 表の「名前」列でoracle-bamアプリケーションを選択します。oracle-bamアプリケーションの「設定」ページが表示されます。

6. 「ターゲット」タブをクリックします。

7. 「ロックして編集」をクリックします。

8. 表6-4に従って各モジュールのターゲットを変更します。

   
   

   注意: 表6-4に従ってすべてのコンポーネントをターゲット設定する必要があります。ターゲット設定に誤りがあると、BAMシステムが起動しないことがあります。

   
   

   表6-4 oracle-bamコンポーネントのターゲット・タイプ

   コンポーネント	タイプ	ターゲット
   oracle-bam（11.1.1）	エンタープライズ・アプリケーション	BAM_Cluster
   /oracle/bam	WEBAPP	WLS_BAM1
   oracle-bam-adc-ejb.jar	EJB	WLS_BAM1
   oracle-bam-ems-ejb.jar	EJB	WLS_BAM1
   oracle-bam-eventengine-ejb.jar	EJB	WLS_BAM1
   oracle-bam-reportcache-ejb.jar	EJB	WLS_BAM1
   oracle-bam-statuslistener-ejb.jar	EJB	WLS_BAM1
   OracleBAM	WEBAPP	BAM_Cluster
   OracleBAMWS	WEBAPP	BAM_Cluster
   sdpmessagingclient-ejb.jar	EJB	WLS_BAM1

   
   

6.7 pack/unpackユーティリティを使用した、BAMHOST1およびBAMHOST2へのドメイン構成の伝播

WLS_BAM1およびWLS_BAM2を持つEDGトポロジは、WLS_SOA1およびWLS_SOA2の場合と同じノードに適切な容量があれば、そのノードで実行できます。この場合は、WLS_BAMサーバー用の新しい独立したドメイン・ディレクトリに対してpack/unpackを実行し、ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>にあるSOA構成を保存しておくことをお薦めします。推奨される方法として、BAMの独立したドメイン・ディレクトリをSOAHOST1のORACLE_BASE/admin/<domain_name>/mserverbam/<domain_name>に用意します。

1. SOAHOST2と同様のディレクトリと共有記憶域構成がBAMHOST1に存在することを確認します（第2章「データベースと環境の事前構成」を参照）。BAMHOST1およびBAMHOST2では、第4章「ドメインの作成」の説明に従ってORACLE_BASE/product/fmwディレクトリをマウントしている必要があります。

2. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

   1. 次のコマンドを実行します。

      SOAHOST1> cd ORACLE_BASE/product/fmw/soa/common/bin
      

      
      

      注意: このディレクトリは、第4章「ドメインの作成」で作成したMW_HOMEへのマウント・ポイントとして使用できます。

      
      
      
      

      注意: ant-soa-util.xmlスクリプトを実行してSOA構成の整合性を確認している場合、リストア・オプションを指定してもう一度このスクリプトを実行し、管理サーバー・ディレクトリでSOA構成のアーティファクトをリカバリする必要があります。これは圧縮を実行する前に行う必要があります。詳細は、第5.8項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」を参照してください。

      
      

   2. 次のようにpackコマンドを実行します。

      SOAHOST1> ./pack.sh -managed=true
         -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>
         -template=soadomaintemplateBAM.jar
         -template_name=soa_domain_templateBAM
      

3. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをBAMHOST1にコピーします。

   SOAHOST1> scp soadomaintemplateBAM.jar
      oracle@BAMHOST1:/ORACLE_BASE/product/fmw/soa/common/bin
   

4. 次のように、BAMHOST1でunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

   BAMHOST1> cd ORACLE_BASE/fmw/soa/common/bin
   BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> -template=soadomaintemplateBAM.jar "-app_dir=ORACLE_BASE/admin/<domain_name>/mserver/apps
   

5. BAMHOST2に対してcopyコマンドとunpackコマンドを実行します。

6.8 WLS_BAMn管理対象サーバーに対するホスト名検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です（第7章「ノード・マネージャの設定」を参照）。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第7章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。

ホスト名検証を無効にする手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。

3. 「ホスト名の検証」を「なし」に設定します。

4. 管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。

5. 変更を保存してアクティブ化します。

6.9 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

次の手順を実行して、BAMHOST1およびBAMHOST2でノード・マネージャを起動します。

1. ノード・マネージャを起動する前に、ORACLE_BASE/product/fmw/soa/common/binディレクトリにあるsetNMProps.shスクリプトを各ノードで実行し、StartScriptEnabledプロパティをtrueに設定します。

   BAMHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
   BAMHOSTn> ./setNMProps.sh
   

   
   

   注意: クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。第10.6.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

   
   

2. 次のコマンドを実行し、BAMHOST1でノード・マネージャを起動します。

   BAMHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
   BAMHOST1> ./startNodeManager.sh BAMHOST1
   

   次のコマンドを実行し、BAMHOST2でノード・マネージャを起動します。

   BAMHOST2> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
   BAMHOST2> ./startNodeManager.sh BAMHOST2
   

6.10 BAMシステムの起動

次の手順を実行して、BAMHOST1でWLS_BAM1管理対象サーバーを起動します。

1. WLS_BAM1管理対象サーバーを起動します。

   1. http://soahost1vhn1:7001/consoleのOracle WebLogic Server管理コンソールにログインします。

   2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

   3. 「制御」タブをクリックします。

   4. 表の「サーバー」列の「WLS_BAM1」を選択します。

   5. 「起動」をクリックします。

2. http://BAMHOST1VHN1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。

管理対象サーバーの起動に失敗すると次のメッセージが表示されます。

Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>

この場合は、データベースのPROCESSES初期化パラメータが十分に高い値に設定されていることを確認してください。詳細は、第2.1.1.3項「初期化パラメータ」を参照してください。このエラーが発生する可能性があるのは、1台のサーバーを起動した後で別のサーバーを起動した場合です。

1. WLS_BAM2管理対象サーバーを起動します。

   1. http://soahost1vhn1:7001/consoleのOracle WebLogic管理コンソールにログインします。

   2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

   3. 「制御」タブをクリックします。

   4. 表の「サーバー」列の「WLS_BAM2」を選択します。

   5. 「起動」をクリックします。

2. http://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2のステータスを確認します。

注意: ここで示す手順は、SOAHOST2でWS-MまたはSOAの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。

6.11 BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成

次の手順を実行して、BAMHOST1でBAMサーバーを使用するようにOracleBamWeb（WLS_BAM1）アプリケーションおよびOracleBamWeb（WLS_BAM2）アプリケーションを構成します。

1. http://soahost1vhn1:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. ナビゲーション・ツリーの「BAM」を開きます。

3. 「OracleBamWeb（WLS_BAM1）」を右クリックします。

4. コンテキスト・メニューから「BAM Webプロパティ」を選択します。「BAM Webプロパティ」ページが表示されます。

5. 次のプロパティを定義します。

   • アプリケーションURLにhttps://soa.mycompany.comと入力します。

   • サーバー名にBAMHOST1VHN1と入力します。第2.2.3項「IPと仮想IP」の表2-2も参照してください。

6. ナビゲーション・ツリーから「OracleBamWeb（WLS_BAM2）を選択して、この手順を繰り返します。

6.12 適切なBAMサーバー・アドレスを使用するためのADCサーバーの構成

次の手順を実行して、正しいBAMServerアドレスを使用するようにADCServerを構成します。

1. http://soahost1vhn1:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. ナビゲーション・ツリーの「BAM」を開きます。

3. 「OracleBamServer（WLS_BAM1）」を右クリックします。

4. コンテキスト・メニューから「システムMBeanブラウザ」を選択します。

5. システムMBeanブラウザの「アプリケーション定義のMBeans」でoracle.bam.serverを開きます。

6. 「BamServerConfig」MBeanをクリックします（図6-3を参照）。

7. ADCServerName属性の値としてBAMHOST1VHN1を入力し、この属性を更新します。

8. ADCServerPort属性をBAMサーバーのリスニング・ポートに更新します。

9. 「適用」をクリックします。

図6-3 システムMBeanブラウザ

「図6-3 システムMBeanブラウザ」の説明

6.13 WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_BAMn管理対象サーバーが属するBAM_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

1. 次の行をOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。

   # BAM Web Application
   <Location /OracleBAM >
       SetHandler weblogic-handler
       WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
   </Location>
   

2. WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。

   WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1
   WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2
   

6.14 Oracle HTTP Serverを介したアクセスの検証

URLを検証して、HTTP ServerからBAM_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。

1. WLS_BAM2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_BAM1を停止します。

2. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します（BAMサーバーが停止しているので、レポートやデータは取得できません）。

3. Oracle WebLogic Server管理コンソールでWLS_BAM1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_BAM2を停止します。

5. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します

6.15 WLS_BAMサーバーのサーバー移行の構成

BAMの高可用性アーキテクチャでは、サーバーの移行を使用してBAMサーバーのシングルトン・サービスを障害から保護します。障害が発生した場合にBAMHOST2で再起動できるようにWLS_BAM1管理対象サーバーを構成します。この構成では、WebLogic Serverの移行によってフェイルオーバーの対象となる特定の浮動IPをWLS_BAM1でリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

• 手順1: サーバー移行リース・テーブルのユーザーおよび表領域の設定

• 手順2: WebLogic Server管理コンソールでのマルチ・データ・ソースの作成

• 手順3: BAMHOSTnノードのノード・マネージャと管理サーバー間でのホスト名検証証明書の有効化

• 手順4: ノード・マネージャのプロパティ・ファイルの編集

• 手順5: wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

• 手順6: サーバー移行ターゲットの構成

• 手順7: サーバー移行のテスト

注意: SOAに対してサーバーの移行を構成済であれば、それと同じデータ・ソースとデータベース・スキーマをBAMステムで使用できます。この場合、手順1から5を実行する必要はありません。

6.15.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

次の手順を実行してユーザーと表領域を作成します。

1. leasingという表領域を作成します。たとえば、SYSDBAユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。

   SQL> create tablespace leasing
           logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
           size 32m autoextend on next 32m maxsize 2048m extent management local;
   

2. 次のように、leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

   SQL> create user leasing identified by welcome1;
   SQL> grant create table to leasing;
   SQL> grant create session to leasing;
   SQL> alter user leasing default tablespace leasing;
   SQL> alter user leasing quota unlimited on LEASING;
   

3. 次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。

   1. ORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracle/920ディレクトリにあるleasing.ddlファイルを、使用するデータベース・ノードにコピーします。

   2. leasingユーザーとしてデータベースに接続します。

   3. 次のように、leasing.ddlスクリプトをSQL*Plusで実行します。

      SQL> @copy_location/leasing.ddl;
      

6.15.2 WebLogic Server管理コンソールでのマルチ・データ・ソースの作成

Oracle Weblogic Server管理コンソールを使用して、リース・テーブル用のマルチ・データ・ソースを作成します。マルチデータソースの設定プロセス中に、各RACデータベース・インスタンスのデータソースを、これらのデータソースとグローバル・リース・マルチデータソースの両方に対して作成します。このデータ・ソースを作成する手順は次のとおりです。

• 該当のデータソースが非XAデータ・ソースであることを確認します。

• マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。

• Oracleのドライバ（Thin）バージョン9.0.1、9.2.0、10または11を使用します。

• 「グローバル・トランザクションのサポート」、「1フェーズ・コミット」を使用し、データベースのサービス名を指定します。

• これらのデータ・ソースのターゲットをSOAクラスタに設定します。

Oracle WebLogic Server管理コンソールによるマルチ・データ・ソース作成の詳細は、第8.2項「Oracle WebLogic Server管理コンソールでのマルチ・データ・ソースの作成」を参照してください。

6.15.3 BAMHOSTnノードのノード・マネージャと管理サーバー間でのホスト名検証証明書の有効化

第7.2項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

6.15.4 ノード・マネージャのプロパティ・ファイルの編集

nodemanager.propertiesファイルは、ORACLE_BASE/product/fmw/wlserver_10.3/common/nodemanagerディレクトリにあります。

次のプロパティを追加してサーバー移行が正常に動作するようにします。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

• Interface

  このプロパティは浮動IP（eth0など）のインタフェース名を指定します。

• NetMask

  このプロパティは浮動IP用インタフェースのネット・マスクを指定します。

• UseMACBroadcast

  このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

サーバーを実行する2つのノードでこの構成を行います。ノード・マネージャの出力（ノード・マネージャを起動するシェル）で、これらのプロパティが使用されていることを確認します。使用されていないプロパティがあると、移行中に問題が発生することがあります。出力は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意: サーバーのプロパティ（起動プロパティ）が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動できるようにするためにShiphometに必要なものです。

2. ORACLE_BASE/ product/fmw/wlserver_10.3/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

   
   

   注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース（eth3）を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。

   
   

6.15.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

次の手順を実行してwlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定します。

1. 表6-5に示すファイルをPATH環境変数で指定していることを確認します。

   表6-5 PATH環境変数に必要なファイル

   ファイル	ディレクトリの場所
   wlsifconfig.sh	ORACLE_BASE/admin/<domain_name>/mserver/ <domain_name>/bin/server_migration
   wlscontrol.sh	ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
   nodemanager.domains	ORACLE_BASE/product/fmw/wlserver_10.3/common

   
   

2. sudoの構成をwlsifconfig.shスクリプトに付与します。

   • パスワードの要求がなくても動作するようにsudoを構成します。

   • セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定する手順は次のとおりです。

     1. パスワードによる制限を設けずにsudo権限をWebLogicユーザー（oracle）に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

     2. WebLogicユーザー（oracle）がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

        oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
        

   
   

   注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

   
   

6.15.6 サーバー移行ターゲットの構成

クラスタの移行を構成すると、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。次の手順を実行して、クラスタでクラスタの移行を構成します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ（BAM_Cluster）をクリックします。

4. 「移行」タブをクリックします。

5. 「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。

6. 自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。

7. 「保存」をクリックします。

8. サーバー移行の候補となるマシンを次のように設定します。

   
   

   注意: WLS_BAM2はサーバーの移行には使用しないため、この作業はWLS_BAM1のみに行ってください。

   
   

   1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

   2. 移行を構成するサーバーを選択します。

   3. 「移行」タブをクリックします。

   4. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。WLS_BAM1についてBAMHOST2を選択します。

   5. 「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。

   6. 「保存」をクリックします。

   7. 管理サーバーとWLS_BAM1サーバーを再起動します。

6.15.7 サーバー移行のテスト

次の手順を実行して、サーバー移行が適切に機能することを確認します。

ノード1で次の操作を実行します。

1. WLS_BAM1管理対象サーバーを停止します。

   停止するには、次のコマンドを実行します。

   BAMHOST1> kill -9 <pid>
   

   <PID>には管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。

   BAMHOST1> ps -ef | grep WLS_BAM1
   

2. ノード・マネージャのコンソールを確認します。WLS_BAM1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_BAM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

ノード2で次の操作を実行します。

1. ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_BAM1の再起動が前回試行されてから30秒間経過した後に、WLS_BAM1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. BAMHOST1VHN1とsoa.mycompany.com/OracleBAMを使用してOracle BAMコンソールにアクセスします。

管理コンソールでの確認

移行は次のように管理コンソールで確認することもできます。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」タブをクリックします。

   「移行の状態」の表に、移行の状態に関する情報が表示されます。

6.16 インストールのバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、『Oracle Database Backup and Recovery Guide』も参照してください。

次の手順を実行して、この時点でのインストールをバックアップします。

1. Web層をバックアップする手順は次のとおりです。

   1. opmnctlを使用してインスタンスを停止します。

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
      

   2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
      

   3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
      

   4. opmnctlを使用してインスタンスを起動します。

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
      

2. データベースをバックアップします。これは、Oracle Recovery Manager（推奨）またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルはすべてORACLE_BASE/admin/<domain_name>ディレクトリ以下にあります。

   SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>