ヘッダーをスキップ
Oracle® Fusion Middleware管理者ガイド
11g リリース1(11.1.1)
B60984-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

18 環境のリカバリ

この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止からリカバリするための推奨されるリカバリ計画および手順について説明します。

この章の項目は次のとおりです。

18.1 環境のリカバリの概要

この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ計画の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。


注意:

この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。

ファイルのリストア時、圧縮ファイルの解凍には、それに適したツールを使用します。

使用しているツールが、ファイルの権限とタイムスタンプを保存することを確認してください。

必要なファイルを間違って上書きしないよう、バックアップからファイルをリストアする前に既存のファイルおよびディレクトリの名前を変更してください。

18.2 データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

この項では、ディスクをリストアできないような、実データの損失や破損、またはメディア障害などが関係する停止に対するリカバリ計画について説明します。適切に機能しなくなったアプリケーションに対するリカバリ計画についても説明します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。次の項目が含まれます。

18.2.1 Middlewareホームのリカバリ

破損したりファイルが削除されたMiddlewareホームをリカバリできます。

Middlewareホームをリカバリする手順は次のとおりです。

  1. 関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  2. バックアップからMiddlewareホーム・ディレクトリをリカバリします。たとえば、次のように指定します。

    cd MW_HOME
(UNIX) tar -xf mw_home_backup_092010.tar
(Windows) jar xtf mw_home_backup_092010.jar

  3. 関連するすべてのプロセスを起動します。つまり、Middlewareホームで実行するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

18.2.2 Oracle WebLogic Serverドメインのリカバリ

ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリすることができます。


注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリする手順は次のとおりです。

  1. 関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  2. バックアップからドメイン・ディレクトリをリカバリします。

    cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_092010.tar 
(Windows) jar xtf domain_backup_092010.jar

  3. 関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

  4. 管理サーバーを起動できない場合は、第18.2.5項の説明に従って、管理サーバーをリカバリします。

  5. 管理対象サーバーを起動できない場合は、第18.2.6項の説明に従って、管理対象サーバーをリカバリします。

18.2.3 Oracleホームのリカバリ

特定のコンポーネントのOracleホームをリカバリする手順は次のとおりです。

  1. バックアップ・ファイルからOracleホームを元のディレクトリにリカバリします。たとえば、次のように指定します。

    cd ORACLE_HOME
tar -xf Oracle_home_backup_092010.tar

  2. WLSTのstartコマンドを使用して、アプリケーションのデプロイ先の管理対象サーバーを再起動します。たとえば、次のように指定します。

    wls:/mydomain/serverConfig> start('myserver','Server')

18.2.4 Oracleインスタンス・ホームのリカバリ

Oracleインスタンス・ホームには、Oracle HTTP ServerやOracle Internet Directoryなどのシステム・コンポーネントに関する構成情報が含まれています(システム・コンポーネントの一覧は、第3.5.2項を参照)。次の各項目で、Oracleインスタンス・ホームをリカバリする方法について説明します。

18.2.4.1 ファイル・システムからOracleインスタンス・ホームが削除された後のリカバリ

ファイル・システムから削除されたり破損したOracleインスタンス・ホームをリカバリする手順は次のとおりです。

  1. 関連するすべてのプロセスを停止します。つまり、Oracleインスタンスに関連するすべてのプロセスを強制終了します。

  2. バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。たとえば、次のように指定します。

    cd ORACLE_INSTANCE
(UNIX) tar -xf Instance_home_backup_092010.tar 
(Windows) jar xtf Instance_home_backup_092010.jar

  3. 関連するすべてのプロセスを起動します。つまり、Oracleインスタンスに関連するすべてのプロセスを起動します。

    opmnctl startall

18.2.4.2 Oracleインスタンス・ホームが登録解除された後のリカバリ

ドメインから登録解除されたOracleインスタンス・ホームをリカバリする手順は次のとおりです。

  1. バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。たとえばLinuxでは、次のように指定します。

    cd ORACLE_INSTANCE
tar -xf Instance_home_backup_092010.tar

  2. opmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir
     -instanceName Instance_name -wlserverHome Middleware_Home

18.2.5 管理サーバー構成のリカバリ

ファイルの削除またはファイル・システムの破損が原因で、管理サーバーの構成が失われた場合でも、問題の発生時に管理サーバーのコンソールがすでに起動しているときには、このコンソールは引き続き機能します。管理サーバー・ディレクトリは、セキュリティ情報を除き、自動的に再生成されます。その結果、管理サーバーを起動するたびに、ユーザー名とパスワードの入力を求めるプロンプトが表示されます。これを避けるには、構成をリカバリします。


注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

管理サーバーの構成をリカバリする手順は次のとおりです。

  1. 管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  2. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

    DOMAIN_HOME/config

  3. 管理サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
   -Dweblogic.management.password=password
   -Dweblogic.system.StoreBootIdentity=true

  4. 管理サーバーが正常に起動しており、アクセス可能であることを確認します。

構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。

18.2.6 管理対象サーバーのリカバリ

管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。

次の各項目で、管理対象サーバーのファイルをリカバリする方法について説明します。

18.2.6.1 管理対象サーバーのリカバリ(起動できない場合)

このシナリオでは、管理対象サーバーの構成が削除されたり破損したために、あるいは構成が誤って変更され変更内容を確認できないために、管理対象サーバーが適切に動作しなかったり起動できない場合を考えます。

管理対象サーバーを起動できない場合のリカバリの手順は次のとおりです。

  1. 管理サーバーにアクセスできない場合は、第18.2.5項の説明に従って、管理サーバーをリカバリします。

  2. 管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。

    1. 必要に応じて、Middlewareホームをバックアップからリカバリします。たとえば、次のように指定します。

      tar -xf mw_home_backup_092010.tar

    2. packユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。

      pack.sh -domain=MW_HOME/user_projects/domains/domain_name
   -template=/scratch/temp.jar -template_name=test_install 
   -template_author=myname -log=/scratch/logs/my.log -managed=true

      -managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

    3. unpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

      unpack.sh -template=/scratch/aime1/ms.jar
   -domain=MW_HOME/user_projects/domains/domain_name
   -log=/scratch/logs/new.log -log_priority=info

    4. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。


      注意:

      • ステージング・モードのアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

      • ステージングなしまたは外部ステージング・モード・アプリケーションでは、管理対象サーバーのステージング・ディレクトリでアプリケーション・ファイルが使用可能であることを確認してください。

      ステージング、ステージングなし、または外部ステージング・モード・アプリケーションの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

    5. 管理対象サーバーを起動します。たとえば、次のように指定します。

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name
          admin_url

      管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

18.2.6.2 管理対象サーバーのリカバリ(適切に機能しない場合)

このシナリオでは、管理対象サーバーが実行されていて、管理対象サーバーのファイル・システムが損失または破損している場合を考えます。

管理対象サーバーをリカバリする手順は次のとおりです。

  1. 管理対象サーバーを停止します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url
        username password

  2. 必要に応じて、Middlewareホームをバックアップからリカバリします。

    tar -xf mw_home_backup_092010.tar

  3. packユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。

    pack.sh -domain=MW_HOME/user_projects/domains/WLS_SOAWC
  -template=/scratch/temp.jar -template_name=test_install 
  -template_author=myname -log=/scratch/logs/my.log -managed=true

    -managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

  4. unpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

    unpack.sh -template=/scratch/aime1/ms.jar 
   -domain=MW_HOME/user_projects/domains/WLS_SOAWC
   -log=/scratch/logs/new.log -log_priority=info

  5. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。


    注意:

    • ステージング・モードのアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

    • ステージングなしまたは外部ステージング・モード・アプリケーションでは、管理対象サーバーのステージング・ディレクトリでアプリケーション・ファイルが使用可能であることを確認してください。

    アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

  6. 管理対象サーバーを再起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

18.2.6.3 ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ

Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、管理対象サーバー・ディレクトリをリストアする必要があります。たとえば、ドメインに2つの管理対象サーバーがあり(その1つにOracle SOA Suiteが含まれています)、いずれの管理対象サーバーのディレクトリも管理サーバーと同じディレクトリ構造内には存在しないとします。

この場合、管理対象サーバーをバックアップからリストアする必要があります。

  1. バックアップから管理対象サーバーをリストアします。

    cd ManagedServer_Home
tar -xf managed_server_backup_092010.tar

  2. 管理対象サーバーを再起動します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
          admin_url

18.2.7 コンポーネントのリカバリ

次の各項目で、ほとんどのコンポーネントについてリカバリする方法を説明します。

一部のコンポーネントについては、別の手順に従う必要があります。表18-1に、そのようなコンポーネントと、そのリカバリ手順を説明している項を示します。

表18-1 特定のコンポーネントのリカバリ手順

コンポーネント 手順

Oracle Access Manager

18.2.7.5項

Oracle Adaptive Access Manager

18.2.7.6項

Oracle BI Enterprise Edition

18.2.7.10項

Oracle Business Intelligence Publisher

18.2.7.11項

Oracle Business Process Management

18.2.7.7項

Oracle Real-Time Decisions

18.2.7.12項

Oracle Data Integrator

18.2.7.13項

Oracle Identity Manager

18.2.7.3項

Oracle Identity Navigator

18.2.7.4項

Oracle Imaging and Process Management

18.2.7.15項

Oracle Information Rights Management

18.2.7.14項

Oracle Universal Content Management

18.2.7.16項

Oracle Universal Records Management

18.2.7.17項

Oracle WebCenterアクティビティ・グラフ

18.2.7.8項

Oracle WebCenter Analytics

18.2.7.9項

18.2.7.1 適切に機能してないコンポーネントのリカバリ

コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

  • Oracle SOA SuiteなどのJavaコンポーネントの場合は、第18.2.6項の説明に従って、管理対象サーバーをリカバリします。

  • システム・コンポーネントの場合(Oracle HTTP ServerやWeb Cacheなど):

    1. コンポーネントを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。

      opmnctl stopproc ias-component=component_name

      コンポーネントの停止方法の詳細は、第4.3項を参照してください。

    2. バックアップからコンポーネント固有のファイルをリカバリします。第16.5項に、各コンポーネントに必要なディレクトリとファイルを示します。たとえば、Oracle HTTP Serverのファイルをリカバリするには、次のディレクトリをリカバリします。

      ORACLE_INSTANCE/config/OHS/component_name
ORACLE_INSTANCE/diagnostics/logs/OHS/component_name

    3. コンポーネントを起動します。たとえば、Oracle HTTP Serverを起動するには、次のコマンドを使用します。

      opmnctl startproc ias-component=component_name

      コンポーネントの起動方法の詳細は、第4.3項を参照してください。

18.2.7.2 クラスタ構成変更後のコンポーネントのリカバリ

クラスタ・レベルで構成が変更されコミットされたために、クラスタ内のコンポーネントが適切に機能しないまたは起動できない場合、それらのコンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。


注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

コンポーネントをリカバリする手順は次のとおりです。

  1. クラスタを停止します。

    stop('cluster_name', 'Cluster')

  2. 管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  3. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

    DOMAIN_HOME/config

  4. 管理サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

  5. クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTのstartコマンドを次のように使用します。

    start('clusterName', 'Cluster')

最新の構成が管理サーバーからクラスタのすべてのメンバーに取得されます。

18.2.7.3 Oracle Identity Managerのリカバリ

Oracle Identity Managerをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. OIM、MDS、SOAINFRAおよびOIDスキーマが含まれるデータベースを同じ時点にリストアします。第18.2.10項を参照してください。

    Oracle Identity Managerでは、ユーザーおよびロールをLDAPストアに格納します。データベースをLDAPストアと異なる時点にリストアする場合、リコンシリエーション・エンジンでは変更ログをチェックして、LDAPストアとデータベースのリストアの間に発生したすべての変更を再度適用します。たとえば、データベースをLDAPストアの10時間後の時点にリストアする場合、リコンシリエーション・エンジンは変更ログをチェックしてLDAPストアで直前の10時間以内に発生したすべての変更をデータベースに再度適用します。

    リコンシリエーションを明示的にトリガーする必要はありません。LDAP同期は定期的なスケジュール済タスクとして設定され、定期的にリコンシリエーション・イベントを発行します。また、リコンシリエーション・プロセスを手動で起動して、Oracle Identity Managerコンソールからリコンシリエーション・イベントを監視することもできます。『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のリコンシリエーションの構成に関する項を参照してください。


    注意:

    (前述のリカバリのシナリオのような)大量のリコンシリエーションが発生したときにOracle Identity Managerアプリケーションはエンド・ユーザーから使用できないようにすることをお薦めします。大量のリコンシリエーションが完了したときに、再度Oracle Identity Managerアプリケーションをエンド・ユーザーが使用できるようにしてください。リコンシリエーションは、Oracle Identity Managerコンソールで監視できます。

18.2.7.4 Oracle Identity Navigatorのリカバリ

Oracle Identity Navigatorをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. WLST importMetadataコマンドを使用して、ファイルベースのMDSリポジトリをリストアします。たとえば、次のように指定します。

    importMetadata(application='oinav', server='server_name', fromLocation='export_directory')

18.2.7.5 Oracle Access Managerのリカバリ

Oracle Access Managerをリカバリする手順は次のとおりです。

  1. 第18.2.1項の説明に従って、Middlewareホーム、およびOracle Access Manager管理対象サーバーのドメイン・ホームをリストアします。

  2. 第18.2.2項の説明に従って、ドメインをリストアします。

  3. 必要に応じて、第18.2.3項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleホームをリストアします。

  4. 必要に応じて、第18.2.4項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleインスタンスをリストアします。

  5. 必要に応じて、Oracle Access Managerポリシー・ストア用にOESで使用されるスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

18.2.7.6 Oracle Adaptive Access Managerのリカバリ

Oracle Adaptive Access Managerをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. 必要に応じて、OAAMスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

18.2.7.7 Oracle Business Process Managementのリカバリ

Oracle Business Process Managementをリカバリする手順は次のとおりです。

  1. 第18.2.6項の説明に従って、管理対象サーバーをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

18.2.7.8 Oracle WebCenterアクティビティ・グラフのリカバリ

Oracle WebCenterアクティビティ・グラフをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. 必要に応じて、ACTIVITIESスキーマが含まれるデータベースをリストアします。

18.2.7.9 Oracle WebCenter Analyticsのリカバリ

Oracle WebCenter Analyticsをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. 必要に応じて、ACTIVITIESスキーマおよびMDSスキーマが含まれるデータベースをリストアします。

18.2.7.10 Oracle BI Enterprise Editionのリカバリ

次の各項目で、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)をリカバリする方法について説明します。


注意:

Oracle BI EEをリカバリする場合、WebカタログとOracle BI EEリポジトリ(RPD)は、同じバックアップ・セットを使用して、同じ時点にリストアされるようにする必要があります。

18.2.7.10.1 非クラスタ環境でのOracle BI Enterprise Editionのリカバリ

このシナリオでは、Oracle BI Enterprise Editionが非クラスタ環境で実行されていると想定します。

  1. 障害の程度に応じて、次のものをリストアします。

    • Middlewareホーム全体が失われている場合は、第18.2.1項の説明に従って、Middlewareホームをリストアします。

    • Oracleインスタンス・ホームが失われている場合は、第18.2.4項の説明に従って、Oracleインスタンス・ホームをリストアします。

    • 管理サーバー・ノードでドメイン・ホームが失われている場合は、第18.2.5項の説明に従って、ドメイン・ホームをリストアします。

    • 管理対象サーバー・ノードでドメイン・ホームが失われている場合は、第18.2.6項の説明に従って、ドメイン・ホームをリストアします。

  2. 必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

  3. 第18.2.7.10.3項の説明に従って、LDAPデータベースとWebカタログおよびOracle BI EEリポジトリ(RPD)を調整します。

18.2.7.10.2 クラスタ環境でのOracle BI Enterprise Editionのリカバリ

このシナリオでは、Oracle BI Enterprise Editionが非クラスタ環境で実行されていると想定します。障害の程度に応じて、次のものをリカバリします。

  1. 障害の程度に応じて、次のものをリストアします。

    • Middlewareホーム全体が失われている場合は、第18.2.1項の説明に従って、Middlewareホームをリストアします。

    • Oracleインスタンス・ホームが失われている場合は、第18.2.4項の説明に従って、Oracleインスタンス・ホームをリストアします。

    • 管理サーバー・ノードでドメイン・ホームが失われている場合は、第18.2.5項の説明に従って、ドメイン・ホームをリストアします。

    • 管理対象サーバー・ノードでドメイン・ホームが失われている場合は、第18.2.6項の説明に従って、ドメイン・ホームをリストアします。

  2. 第18.2.5項の説明に従って、管理サーバーをリカバリします。

  3. 第18.2.6項の説明に従って、管理対象サーバーをリカバリします。

  4. 必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

  5. 第18.2.7.10.3項の説明に従って、LDAPデータベースとWebカタログおよびOracle BI EEリポジトリ(RPD)を調整します。

18.2.7.10.3 WebカタログおよびRPDとLDAPデータベースの調整

LDAPデータベースは、WebカタログおよびOracle BI EEリポジトリ(RPD)と調整する必要があります。

Oracle BI Enterprise Editionを使用して、同期を実行できます。常に自動同期を有効にすることも一時的に同期を実行することもできます。

同期を有効にするには、次のファイルを編集します。

INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI

フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをyesに設定してから、サーバーを再起動します。LDAPデータベースとWebカタログおよびRPDの情報は同期されます。

Windows上のOracle BI管理ツールには、リポジトリの妥当性をチェックして不整合を修正できるConsistency Check Managerが用意されています。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ・ビルダーズ・ガイドのリポジトリ・オブジェクトの一貫性のチェックに関する項を参照してください。

18.2.7.11 Oracle Business Intelligence Publisherのリカバリ

Oracle Business Intelligence Publisherをリカバリする手順は次のとおりです。

  1. 第18.2.6項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。

  2. 必要に応じて、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。

18.2.7.12 Oracle Real-Time Decisionsのリカバリ

Oracle Real-Time Decisionsをリカバリする手順は次のとおりです。

  1. 第18.2.6項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。

バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。

18.2.7.13 Oracle Data Integratorのリカバリ

Oracle Data Integratorをリカバリする手順は次のとおりです。

  1. データベースをリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。

  2. 第18.2.3項の説明に従って、バックアップからOracle Data IntegratorのOracleホームをリカバリします。

    cd ORACLE_HOME
tar -xf oracle_home_backup_092010.tar

  3. バックアップからドメイン・ディレクトリをリカバリします。

    cd DOMAIN_HOME
tar -xf domain_backup_092010.tar

18.2.7.14 Oracle Information Rights Managementのリカバリ

Oracle Information Rights Managementをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 共有ファイル・システムをリストアします。

  3. 必要に応じてデータベースをリストアします。第18.2.10項を参照してください。

    データベースとキーストアの同期を維持する必要があります。一方をリストアしたら、もう一方も同じ時点にリストアします。

  4. キーストアをリストアします。

18.2.7.15 Oracle Imaging and Process Managementのリカバリ

Oracle Imaging and Process Management(Oracle I/PM)では、データが次の場所に格納されています。

  • Oracle I/PM構成データ用データベース

  • ドキュメント・リポジトリとして機能するデータベース

  • JMS永続キュー

Oracle I/PMをリカバリする場合、すべてのデータが同じ時点からリストアされるようにする必要があります。

Oracle I/PMをリカバリする手順は次のとおりです。

  1. 第18.2.2項の説明に従って、ドメインをリストアします。

  2. 必要に応じて、IPMおよびOCSスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

18.2.7.16 Oracle Universal Content Managementのリカバリ

Oracle Universal Content Managementをリカバリする手順は次のとおりです。

  1. データベースをリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。

  2. 第18.2.2項の説明に従って、ドメインをリストアします。

  3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。

    cd /net/home/vault
tar -xf vault_backup_092010.tar

データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。

18.2.7.17 Oracle Universal Records Managementのリカバリ

Oracle Universal Records Managementは、Oracle Universal Content Managementに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle Universal Content Managementのリカバリ手順(第18.2.7.16項)を参照してください。

18.2.8 クラスタのリカバリ

次の各項目で、クラスタをリカバリする方法について説明します。

18.2.8.1 削除またはクラスタレベルの構成変更後のクラスタのリカバリ

このシナリオでは、クラスタが間違って削除されたり、JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされた場合を考えます。サーバーが起動できないか適切に動作しない、あるいはサーバー内部で実行されるサービスが開始されていません。変更内容は確認できません。


注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。

  1. クラスタを停止します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。

    stop('clusterName', 'Cluster')

  2. 管理サーバーを停止します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  3. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

    DOMAIN_HOME/config

  4. 管理サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

  5. クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。

    start('clusterName', 'Cluster')

18.2.8.2 メンバーシップを誤って変更した後のクラスタのリカバリ

クラスタのメンバーシップを誤って変更した場合に、クラスタをリカバリできます。たとえば、クラスタからメンバーを誤って削除した場合、メンバーをクラスタにリストアできます。


注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

クラスタのメンバーシップをリカバリする手順は次のとおりです。

  1. 管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  2. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

    DOMAIN_HOME/config

  3. 管理サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
   -Dweblogic.management.password=password
   -Dweblogic.system.StoreBootIdentity=true

    削除されたメンバーがクラスタに戻ります。

  4. 管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
          admin_url

  5. クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。

    start('clusterName', 'Cluster')

    これで、削除されたメンバーがクラスタの一部となります。

  6. クラスタのすべてのメンバーを起動します(起動していない場合)。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

18.2.9 アプリケーションのリカバリ

次の各項目で、アプリケーションをリカバリする方法について説明します。

アプリケーションのリカバリについては、次の点に注意してください。

  • アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。

  • デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。


関連項目:

アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

18.2.9.1 アプリケーション・アーティファクトのリカバリ

.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。

アプリケーションをリカバリする手順は次のとおりです。

  1. アプリケーションのデプロイ先の管理対象サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

    このコマンドを実行すると、構成が管理サーバーと同期されます。

    管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。

18.2.9.2 機能しなくなった再デプロイされたアプリケーションのリカバリ

Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合、そのアプリケーションをリカバリできます。

アプリケーションをリカバリする手順は次のとおりです。

  1. 必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。

  2. バックアップから古いバージョンのアプリケーションを再デプロイします。

    元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。

18.2.9.3 アンデプロイされたアプリケーションのリカバリ

デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合、そのアプリケーションをリカバリできます。

アプリケーションをリカバリする手順は次のとおりです。

  1. 必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。

  2. バックアップから古いバージョンのアプリケーションを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。

    元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。

18.2.9.4 コンポジット・アプリケーションのリカバリ

コンポジット・アプリケーション(SOAアプリケーションなど)の新しいバージョンが、管理対象サーバーまたはクラスタに再デプロイされ、 アプリケーションが機能しなくなったとします。

アプリケーションをリカバリする手順は次のとおりです。

  1. 必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。

  2. アプリケーションの古いバージョンを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。

18.2.10 データベースのリカバリ

MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。

最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。たとえば、次のように指定します。

rman> restore database;
rman> recover database;

各コンポーネントで使用するスキーマについては、付録Dを参照してください。

詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次のリンクから入手可能です。

http://www.oracle.com/technology/documentation/database.html

18.3 ホスト破損後のリカバリ

この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。


注意:

ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。

18.3.1 Oracle WebLogic Serverドメインのリカバリ

Oracle WebLogic Serverドメインをリカバリする手順は次のとおりです。

  1. 関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。

    DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

  2. バックアップからドメイン・ディレクトリをリカバリします。

    cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_092010.tar 
(Windows) jar xtf domain_backup_092010.jar

  3. 関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

  4. 管理サーバーを起動できない場合は、第18.3.2項の説明に従って、管理サーバーをリカバリします。

  5. 管理対象サーバーを起動できない場合は、第18.3.3項の説明に従って、管理対象サーバーをリカバリします。

18.3.2 管理サーバー・ホストの破損後のリカバリ

管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

18.3.2.1 同じホストへの管理サーバーのリカバリ

このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストAに障害が発生し、管理サーバーをリカバリする必要があるとします。

同じホストに管理サーバーをリカバリする手順は次のとおりです。

  1. 管理サーバーを起動してみます。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

    管理サーバーが起動する場合は、これ以上の手順は必要ありません。

  2. 管理サーバーが起動しない場合は、ホストAで次の手順を実行します。

    1. 関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。

      DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

    2. 必要に応じて、Middlewareホームをリカバリします。

      tar -xf mw_home_backup_092010.tar

    3. ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。

      cd DOMAIN_HOME
tar -xf domain_backup_092010.tar

    4. 管理サーバーを起動します。たとえば、次のように指定します。

      DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
    -Dweblogic.management.password=password
    -Dweblogic.system.StoreBootIdentity=true

    5. ホストの管理用URLを指定して、管理対象サーバーを起動します。

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

    6. ノード・マネージャを起動します。

      java weblogic.WLST
wls:/offline> startNodeManager()

18.3.2.2 別のホストへの管理サーバーのリカバリ

このシナリオでは、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストAに障害が発生し、管理サーバーをホストCに移行する必要がある場合を考えます。

別のホストに管理サーバーをリカバリする手順は次のとおりです。

  1. MiddlewareホームをホストC(新しいホスト)にリカバリします。

    cd MW_HOME
tar -xf mw_home_backup_092010.tar

  2. ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。

    cd DOMAIN_HOME
tar -xf domain_backup_092010.tar

  3. 管理サーバーにリスニング・アドレスが指定されている場合は、第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。

  4. 元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。

    java weblogic.WLST
wls:/offline> startNodeManager()

  5. 管理サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

  6. 管理対象サーバーを起動します。『Oracle Fusion Middleware Oracle WebLogic Serverでの管理サーバーの起動と停止』の障害が発生した管理サーバーの再起動に関する項には、構成方法に応じて様々な再起動の方法が説明されています。

    オプションの1つとして、次のスクリプトの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  7. 追加のアプリケーション・アーティファクトが使用可能であることを確認します。たとえば、デプロイメント・モードがステージングなしまたは外部ステージングの場合、アプリケーションはドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。

    アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。

  8. 第18.3.5.7項の説明に従って、Oracle Inventoryを更新します。

  9. 環境にOracle HTTP Serverが含まれる場合、第18.3.5.4項の説明に従って、mod_wl_ohs.confファイルを修正します。

  10. 第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。

  11. Fusion Middleware Controlの一部であるOracle Management Serviceは、元のホストに配置されており、管理サーバーのリストア時に新しいホストにリカバリされます。Oracle Management Agentは、Oracle Management Serviceに接続して、特定のコンポーネントを監視します。使用している環境に、Oracle Internet DirectoryやOracle Virtual Directoryなど、Oracle Management Agentを使用するコンポーネントが含まれるが、それらが別のホストに配置されている場合、これらのコンポーネントが含まれる各ホストで次の手順を実行する必要があります。たとえば、ホストAにあった管理サーバーを、Oracle Management ServiceとともにホストBにリストアするとします。Oracle Internet DirectoryがホストCにあり、Oracle Virtual DirectoryがホストDにある場合、ホストCとホストDの両方で次の手順を実行する必要があります。

    1. 次のファイルを編集します。

      (UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties
(Windows)ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties

      ホスト名を管理サーバーの新しいホストに置き換えて、次のエントリを更新します。

      emdWalletSrcUrl=http://newhost.domain.com:port/em/wallets/emd 
REPOSITORY_URL=http://newhost.domain.com:port/em/upload/

    2. EMエージェント・プロセスを停止して、再起動します。

      cd ORACLE_INSTANCE/EMAGENT/emagent_dir
./emctl stop agent
./emctl start agent
./emctl status agent

      ステータス・コマンドに、新しいホストを指すREPOSITORY_URLが示されます。

これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。

Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、第18.3.5項を参照してください。

18.3.3 管理対象サーバー・ホストの破損後のリカバリ

管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

18.3.3.1 同じホストへの管理対象サーバーのリカバリ

このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストBに障害が発生し、管理対象サーバーをホストBにリカバリする必要があるとします。

同じホストに管理対象サーバーをリカバリする手順は次のとおりです。

  1. ホストBでノード・マネージャを起動します。

    java weblogic.WLST
wls:/offline> startNodeManager()

  2. 管理対象サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

    管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上の手順は必要ありません。

  3. 管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。

    1. ノード・マネージャを停止します。

      java weblogic.WLST
wls:/offline> stopNodeManager()

    2. 必要に応じて、MiddlewareホームをバックアップからホストBにリカバリします。

      tar -xf mw_home_backup_092010.tar

    3. 管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。たとえば、次のように指定します。

      cd Domain_Home
tar -xf domain_home_backup_092010.tar

      ステップeに進みます。

    4. ステップcに示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。

      • packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。

        pack.sh -domain=MW_HOME/user_projects/domains/domain_name
  -template=/scratch/temp.jar -template_name=test_install 
  -template_author=myname -log=/scratch/logs/my.log -managed=true

        -managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

      • ホストBでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

        unpack.sh -template=/scratch/aime1/ms.jar
  -domain=MW_HOME/user_projects/domains/domain_name 
  -log=/scratch/logs/new.log -log_priority=info

    5. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。


      注意:

      • ステージングなしまたは外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。

      • ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

      アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

    6. ノード・マネージャが起動していない場合は、起動します。

      java weblogic.WLST
wls:/offline> startNodeManager()

    7. 管理対象サーバーを起動します。たとえば、次のように指定します。

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

      管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

18.3.3.2 別のホストへの管理対象サーバーのリカバリ

このシナリオでは、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストBに障害が発生し、管理対象サーバーをホストCにリカバリする必要がある場合を考えます。


重要:

元と同じ場所にMiddlewareホームをリカバリします。

別のホストに管理対象サーバーをリカバリする手順は次のとおりです。

  1. 管理対象サーバーのMiddlewareホームをホストCにリカバリします。

    tar -xf mw_home_backup_092010.tar

  2. 管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。たとえば、次のように指定します。

    cd Domain_Home
tar -xf domain_home_backup_092010.tar

    ステップ4に進みます。

  3. ステップ2に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。

    1. packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。

      pack.sh -domain=MW_HOME/user_projects/domains/domain_name
  -template=/scratch/temp.jar -template_name=test_install 
  -template_author=myname -log=/scratch/logs/my.log -managed=true

      -managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

    2. ホストCでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

      unpack.sh -template=/scratch/aime1/ms.jar
   -domain=MW_HOME/user_projects/domains/domain_name
   -log=/scratch/logs/new.log -log_priority=info

      別のドメイン・ホームにリカバリする場合は、unpackコマンドで-app_dirスイッチを使用します。

  4. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。


    注意:

    • ステージングなしまたは外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。

    • ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

    アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

  5. ホストCでノード・マネージャが起動していない場合は、起動します。

    java weblogic.WLST
wls:/offline> startNodeManager()

  6. WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。

    connect('username','password','http://host:port')
nmEnroll('MW_HOME/user_projects/domains/domain_name',
  'MW_HOME/wlserver_n/common/nodemanager')

  7. 管理対象サーバーの構成を、新しいホストを指すように変更します。

    1. WebLogic Server管理コンソールで、1つ以上のWebLogic Serverをホストするコンピュータの論理的な表現であるマシンを作成し、新しいホストを指すように指定します (ホーム・ページから、「マシン」を選択して、 「新規」をクリックします)。管理コンソール・ヘルプの指示に従います。

      リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のホスト名検証の使用方法に関する項を参照してください。

    2. 管理対象サーバーの構成を、新しいマシンを指すように変更します (コンソールの左ペインから、「環境」→「サーバー」を開いて、 サーバーの名前を選択します。「構成」タブを選択して、「一般」タブを選択します。「マシン」フィールドで、サーバーの割当て先のマシンを選択します)。

      「リスニング・アドレス」を新しいホストに変更します。リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。

  8. 管理対象サーバーを起動します。たとえば、次のように指定します。

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

    管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

  9. 第18.3.5.7項の説明に従って、Oracle Inventoryを更新します。

  10. 環境にOracle HTTP Serverが含まれる場合、第18.3.5.4項の説明に従って、mod_wl_ohs.confファイルを修正します。

  11. 第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。

これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。

18.3.3.3 ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ

Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、管理対象サーバー・ディレクトリをリストアする必要があります。たとえば、ドメインに2つの管理対象サーバーがあり(その1つにOracle SOA Suiteが含まれています)、いずれの管理対象サーバーのディレクトリも管理サーバーと同じディレクトリ構造内には存在しないとします。

同じホストまたは別のホストにリカバリするには、第18.2.6.3項で説明している手順を使用します。

18.3.4 コンポーネント・ホスト破損後のリカバリ

コンポーネント(およびその管理対象サーバー(該当する場合))を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。

コンポーネントによっては追加操作が必要なものがあります。それらは、表18-2で示した項で説明しています。

表18-2 特定コンポーネントのホスト破損の際のリカバリ手順

コンポーネント 手順

Oracle Access Manager

18.3.4.5.7項

Oracle Adaptive Access Manager

18.3.4.5.8項

Oracle BI Discoverer

18.3.4.8.4項

Oracle BI Enterprise Edition

18.3.4.9項

Oracle BI Publisher

18.3.4.10項

Oracle Business Process Management

ホストの破損については、追加手順は必要ありません。Oracle Business Process Managementのリカバリの詳細は、第18.2.7.7項を参照してください。

Oracle Data Integrator

18.3.4.12項

Oracle Directory Integration Platform

18.3.4.5.3項

Oracle Forms Services

18.3.4.8.2項

Oracle HTTP Server

18.3.4.7.1項

Oracle Identity Federation

18.3.4.5.4項

Oracle Identity Manager

18.3.4.5.5項

Oracle Identity Navigator

18.3.4.5.6項

Oracle Imaging and Process Management

ホストの破損については、追加手順は必要ありません。Oracle Imaging and Process Managementのリカバリの詳細は、第18.2.7.15項を参照してください。

Oracle Information Rights Management

ホストの破損については、追加手順は必要ありません。Oracle Information Rights Managementのリカバリの詳細は、第18.2.7.14項を参照してください。

Oracle Internet Directory

18.3.4.5.1項

Oracle Portal

18.3.4.8.1項

Oracle Real-Time Decisions

18.3.4.11項

Oracle Reports

18.3.4.8.3項

Oracle SOA Suite

同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする手順の詳細は、第18.3.4.6項を参照してください。

Oracle Universal Content Management

18.3.4.13.1項

Oracle Universal Records Management

18.3.4.13.2項

Oracle Virtual Directory

18.3.4.5.2項

Oracle Web Cache

18.3.4.7.2項

Oracle WebCenterアクティビティ・グラフ

ホストの破損については、追加手順は必要ありません。Oracle WebCenterアクティビティ・グラフのリカバリの詳細は、第18.2.7.8項を参照してください。

Oracle WebCenter Analytics

ホストの破損については、追加手順は必要ありません。Oracle WebCenter Analyticsのリカバリの詳細は、第18.2.7.9項を参照してください。

18.3.4.1 同じホストへのJavaコンポーネントのリカバリ

Oracle SOA SuiteなどのJavaコンポーネントを同じホストにリカバリする手順は次のとおりです。

  1. 第18.2.6.1項の説明に従って、管理対象サーバーをリカバリします。

  2. 表18-2に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。

18.3.4.2 別のホストへのJavaコンポーネントのリカバリ

Oracle SOA SuiteなどのJavaコンポーネントを別のホストにリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。

ただし、表18-2に示すように、一部のコンポーネントでは追加手順が必要です。

18.3.4.3 同じホストへのシステム・コンポーネントのリカバリ

Oracle HTTP Serverなどのシステム・コンポーネントを同じホストにリカバリするには、次の一般的な手順に従います。ただし、表18-2に示すように、一部のコンポーネントでは追加手順が必要です。

  1. 関連するすべてのプロセスを停止します。つまり、このコンポーネントに関連するすべてのプロセスを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。

    opmnctl stopproc ias-component=component_name

    コンポーネントの停止方法の詳細は、第4.3項を参照してください。

  2. バックアップからコンポーネント固有のファイルをリカバリします。第16.5項に、各コンポーネントに必要なディレクトリとファイルを示します。たとえば、Oracle HTTP Serverのファイルをリカバリするには、次のディレクトリをリカバリします。

    ORACLE_INSTANCE/config/OHS/component_name
ORACLE_INSTANCE/diagnostics/logs/OHS/component_name

  3. Oracleインスタンス・ホームが管理サーバーから登録解除されている場合は、Oracleインスタンスを登録します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

    ファイル・システムのみをリカバリする場合は、Oracleインスタンスを登録する必要はありません。

  4. 第4.3項の説明に従って、関連するすべてのプロセスを起動します。

18.3.4.4 別のホストへのシステム・コンポーネントのリカバリ

Oracle HTTP Serverなどのシステム・コンポーネントを別のホストにリカバリするには、次の一般的な手順に従います。ただし、表18-2に示すように、ほとんどのコンポーネントでは追加手順が必要です。

  1. 第18.2.1項の説明に従って、Middlewareホームをリカバリします。

  2. 関連するすべてのプロセスを起動します。第4.3項に、コンポーネントの起動方法の説明があります。

  3. 新しいホストでopmnctl updateinstanceregistrationコマンドを使用して、管理サーバーへのOracleインスタンスの登録を更新します。たとえば、次のように指定します。

    opmnctl updateinstanceregistration -adminHost admin_server_host

    このコマンドは、OPMNのinstance.propertiesファイルを更新します。

  4. 新しいホストでopmnctl updatecomponentregistrationコマンドを使用して、管理サーバーへのコンポーネントの登録を更新します。たとえば、Oracle Virtual Directoryの登録を更新するには、次のコマンドを使用します。

    opmnctl updatecomponentregistration -Host new_host -Port nonSSLPort
    -componentName ovd1 -componentType OVD

  5. 第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。

18.3.4.5 別のホストへのアイデンティティ管理コンポーネントのリカバリ

ほとんどのアイデンティティ管理コンポーネントでは、第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

一部のコンポーネントでは、次の各項で説明しているように、別のホストへのリカバリに追加手順が必要です。

18.3.4.5.1 別のホストへのOracle Internet Directoryのリカバリ

別のホストにOracle Internet Directoryをリカバリする手順は次のとおりです。

  1. 第18.3.4.4項の説明に従って、コンポーネントをリカバリします。

  2. UNIXシステムおよびLinuxシステムでは、Oracle Internet Directoryの起動を試行する前に、次のファイルを、root権限を持つように設定します。

    ORACLE_HOME/bin/oidldapd

    例:

    chown root oidldapd
chmod 4710 oidldapd

  3. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  4. Oracle Directory Services Managerがデプロイされている管理対象サーバーを別のサーバーに移動し、SSLを有効にする場合は、新しいホスト上の次のファイルを削除する必要があります。

    DOMAIN_HOME/servers/wls_ods1/tmp/_WL_user/odsm_11.1.1.1.0/randomid/war/conf/odsm.cer

    Oracle Directory Services Managerでは、このファイルがキーストアおよびトラスト・ストアとして使用され、パスワードがJKSに格納されます。ただし、Oracle Directory Services Managerが別のホストにコピーされ、起動された場合は、別のパスワードが生成されます。このファイルを削除すると、Oracle Directory Services Managerの起動時に、新しいパスワードとともに新しいファイルが作成されます。

18.3.4.5.2 別のホストへのOracle Virtual Directoryのリカバリ

別のホストにOracle Virtual Directoryをリカバリする手順は次のとおりです。

  1. 第18.3.4.4項の説明に従って、コンポーネントをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

18.3.4.5.3 別のホストへのOracle Directory Integration Platformのリカバリ

別のホストにOracle Directory Integration Platformをリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 管理対象サーバーを起動する前に、次のディレクトリにあるファイルをリストアします。

    DOMAIN_HOME/servers/wls_ods1/stage/DIP/11.1.1.1.0/

  3. 管理対象サーバーおよびOracleインスタンスを起動します。

  4. Oracle Internet Directoryも別のホストに移動する場合は、管理対象サーバーとOracleインスタンスの起動直後に次のコマンドを実行します。

    set ORACLE_HOME Oracle_home_path
set WLS_HOME WLS_Home_path
cd ORACLE_HOME/bin
./manageDIPServerConfig set -h dip_server_host -p dip_server_port 
    -D weblogic_user -attribute oidhostport -value oid_host:oid_ssl_port

    manageDIPServerConfigコマンドから、パスワードの入力を求められます。

    例:

    ./manageDIPServerConfig set -h hostname -p 19523 -D weblogic
            -attribute oidhostport -value hostname.domain.com:24163

  5. 新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location
18.3.4.5.4 別のホストへのOracle Identity Federationのリカバリ

Oracle Identity FederationではSSO機能が提供されるため、ホスト破損からのリカバリの一環としてOracle Identity Federationを実行しているホストの名前を変更すると、リモート・パートナが影響を受けます。この場合、リモート・パートナで操作を続行するには、リモート・パートナでホスト名に関する変更を加える必要があります。リモート・パートナでデータを更新するには数日かかる場合があり、これは許容できない生産性の低下を招くことにもなりかねません。スタンドアロンのOracle Identity Federationサーバーのホスト名は変更しないことを強くお薦めします。

ロード・バランサが環境の一部であり、Oracle Identity FederationをリカバリしているホストがVIPのリストに含まれている場合は、ホスト名の変更は必要ありません。

Oracle Identity Federationのスタンドアロン・インストールの場合は、影響を最小限に抑えるために、同じ名前の新しいホストを使用することをお薦めします。ただし、どのような理由であれ、リカバリしているOracle Identity Federationに別のホスト名を使用する必要がある場合は、Oracle Identity Federationおよびリモート・パートナに対してホスト名を手動で更新する必要があります。

別のホストにOracle Identity Federationをリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. 新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

  4. 更新されたデータをリモート・パートナに提供します。

  5. Fusion Middleware Controlを使用して、ホスト名を変更します。

    1. ナビゲーション・ペインで、ファームを開いてから、「Identity and Access」を開きます。

    2. Oracle Identity Federationインスタンスを選択します。

    3. 「Oracle Identity Federation」メニューで、「管理」→「サーバー・プロパティ」を選択します。

      「サーバー・プロパティ」ページが表示されます。

    4. 「ホスト」で、以前のホスト名を新しいホスト名に置き換えます。

    5. ポート番号が変更されている場合は、「ポート」のポート番号を置き換えます。

    6. SOAPポート番号が変更されている場合は、「SOAPポート」のポート番号を置き換えます。

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

    8. Oracle Identity Federationのデプロイ先の管理対象サーバーを再起動します。

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
          admin_url

  6. Oracle Identity FederationがSSLサーバーとして機能している場合は、Oracle Identity Federationからクライアントに示されているSSL証明書を、新しいホスト名を持つ新しい証明書に置き換える必要があります。そうしないと、クライアントによるホスト名の検証が失敗する場合があります。

18.3.4.5.5 別のホストへのOracle Identity Managerのリカバリ

別のホストにOracle Identity Managerをリカバリする手順は次のとおりです。

  1. 第18.3.2項の説明に従って、ドメインをリストアします。

  2. 第18.2.3項の説明に従って、Oracleホームをリストアします。

  3. 必要に応じて、OIM、OID、MDSおよびSOAINFRAスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

  4. Oracle Identity ManagerデータベースとLDAPプロバイダを同期します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』を参照してください。

  5. weblogicExportMetadata.shスクリプトを使用して、oim-config.xmlファイルをエクスポートします。SOA URLのホスト名またはIPアドレスを変更することによって、エクスポートしたファイルを編集します。weblogicImportMetadata.shスクリプトを使用して、このファイルをMDSにインポートします。

  6. 第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。

  7. 第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。

18.3.4.5.6 別のホストへのOracle Identity Navigatorのリカバリ

別のホストにOracle Identity Navigatorをリカバリする手順は次のとおりです。

  1. 第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。

  2. 第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。

18.3.4.5.7 別のホストへのOracle Access Managerのリカバリ

別のホストにOracle Access Managerをリカバリする手順は次のとおりです。

  1. 第18.2.7.5項の手順に従います。

  2. WLSエージェントをリストアするには、第18.3.3.2項の説明に従って、管理対象サーバーをリストアします。

  3. Oracle Access Managerコンソールにログインします。

  4. Oracle Access Managerプロキシ・サーバーを選択します。

  5. 新しいホスト名を指定して、「ホスト」を変更します。

  6. 保護されたページを使用している場合は、『Oracle Fusion Middleware Oracle Access Manager管理者ガイド』のリモート登録ツールに関する項で説明されているoamregツールを使用して、Oracle Single Sign-OnまたはWebゲートをパートナとしてOracle Access Managerに登録する必要があります。同じマニュアルのOSSOリモート登録リクエストに関する項も参照してください。

  7. 第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。

  8. Webゲート構成ファイルのobAccessClient.xmlを編集して、Oracle Access Managerサーバーのホスト名を更新します。このファイルは、次のディレクトリにあります。

    DOMAIN_HOME/output/agentName/

  9. 第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。

18.3.4.5.8 別のホストへのOracle Adaptive Access Managerのリカバリ

別のホストにOracle Adaptive Access Managerをリカバリする手順は次のとおりです。

  1. 第18.2.7.6項の手順に従います。

  2. 第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。

  3. 第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。

18.3.4.6 ホスト破損後のOracle SOA Suiteのリカバリ

Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、第18.3.3.3項で説明している手順に従ってください。それ以外の場合は、この項の手順に従ってください。

同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、第18.3.3.1項の説明に従って、管理対象サーバーをリカバリします。

ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリする手順は次のとおりです。

  1. リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。

  2. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  3. Oracle SOA Suite管理対象サーバーのリカバリ後に、次の操作を実行します。

    • antコマンドを使用してコンポジットをデプロイする場合は、deploy-sar.xmlファイルを編集します。このファイルは次の場所にあります。

      (UNIX) ORACLE_HOME/bin
(Windows) ORACLE_HOME\bin

      次の行で、以前のホスト名を新しいホスト名に置き換えます。

      <property name="wlsHost" value="newhostname"/>

      ロード・バランサを使用する場合は、このプロパティは変更しないでください。かわりに、新しいホストをロード・バランサに登録します。

    • SOAインフラMBeanでホスト名を変更します。

      1. Fusion Middleware Controlで、管理対象サーバーにナビゲートします。

      2. 「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。

      3. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「oaInfraConfig」を開きます。「soa-infra」を選択します。

      4. 「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。

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

    • WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。


注意:

環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。

環境にロード・バランサが構成されている場合は、次の追加手順を実行します。

  1. Oracle WebLogic Server管理サーバーにログインします。

  2. ドメイン構造で、「サーバー」にナビゲートします。管理対象サーバーごとに「プロトコル」タブ→「HTTP」タブを選択します。

  3. 「フロントエンド・ホスト」に、新しいホスト名を入力します。

  4. 「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。

  5. 管理対象サーバーをそれぞれ再起動します。

18.3.4.7 別のホストへのWeb層コンポーネントのリカバリ

Web層は、Oracle HTTP ServerとOracle Web Cacheで構成されています。次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。

18.3.4.7.1 別のホストへのOracle HTTP Serverのリカバリ

別のホストにOracle HTTP Serverをリカバリする手順は次のとおりです。

  1. 第18.3.4.4項の説明に従って、コンポーネントをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. 次のファイルにある ServerNameエントリを、新しいホスト名を持つように変更します。

    (UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf
(Windows) ORACLE_INSTANCE\config\OHS\ohs_name\httpd.conf
18.3.4.7.2 別のホストへのOracle Web Cacheのリカバリ

別のホストにOracle Web Cacheをリカバリする手順は次のとおりです。

  1. 第18.3.4.4項の説明に従って、コンポーネントをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. webcache.xmlファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。このファイルは、次のディレクトリにあります。

    (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\config\WebCache\webcache_name

18.3.4.8 別のホストへのOracle Portal、Oracle Reports、Oracle Forms ServicesおよびOracle Business Intelligence Discovererのリカバリ

次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。

18.3.4.8.1 別のホストへのOracle Portalのリカバリ

別のホストにOracle Portalをリカバリする手順は次のとおりです。

  1. Middlewareホーム、ドメイン・ディレクトリおよびOracleインスタンス・ディレクトリを新しいホストにリストアします。詳細は、第18.3.3.2項を参照してください。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. Oracleインスタンスが登録解除されている場合は、新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

  4. 新しいホストでopmnctl updateinstanceregistrationコマンドを使用して、管理サーバーへのOracleインスタンスの登録を更新します。たとえば、次のように指定します。

    opmnctl updateinstanceregistration -adminHost admin_server_host

    このコマンドは、OPMNのinstance.propertiesファイルを更新します。

  5. 次のファイルを変更して、以前のホスト名を新しいホスト名に置き換えます。

    ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf
ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/portal.conf

  6. ssoregスクリプトを実行します。これは次の場所にあります。

    Identity_Management_ORACLE_HOME/sso/bin

    次のコマンドを使用します。

    ssoreg.sh -site_name newhost:http_listen_port 
    -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
    -oracle_home_path $ORACLE_HOME -config_file any_new_file_path
    -admin_info cn=orcladmin -virtualhost -remote_midtier

    例:

    ssoreg.sh -site_name example.com:8090 
   -mod_osso_url http://example.com:8090 -config_mod_osso TRUE 
   -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf  
   -admin_info cn=orcladmin -virtualhost -remote_midtier

  7. 前の手順のファイルを新しいホストにコピーします。

  8. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ6のファイルのパスが含まれるようにします。

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

    例:

    <IfModule mod_osso.c>
    OssoIpCheck off
    OssoSecureCookies off
    OssoIdleTimeout off
    OssoConfigFile /tmp/path_of_file_created

  9. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

    • webcache.xml。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\config\WebCache\webcache_name

      以前のホスト名をすべて新しいホスト名に置き換えます。

    • instance.properties。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OPMN/opmn
(Windows) ORACLE_INSTANCE\config\OPMN\opmn

      管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。

      adminHost=host_name

  10. Oracle Portalへのアクセスに使用する公開ホストを変更する場合は、次の手順に従います。この変更は、Oracle Web CacheとWLS_PORTALの両方が含まれる単一ノード・インストールを使用している場合に行う可能性があり、これらのプロセスを別のホストに移動する必要があります。別のシナリオとして、Oracle Web CacheをノードでWLS_PORTALからリモートに実行している場合があります。この場合、Oracle Web Cacheを別のホストに移動する必要があります。どちらの場合でも、次の手順に従って、Oracle Portal内の公開ホスト情報を更新します (注意: ロード・バランサまたはリバース・プロキシ構成を使用している場合は、これらの手順は必要ありません)。

    1. 次のディレクトリからすべてのコンテンツを再帰的に削除します。ただし、ディレクトリ自体を削除しないでください。

      ORACLE_INSTANCE/portal/cache

    2. Fusion Middleware Controlにログインします。ファームを開き、「Portal」を右クリックします。「設定」→「ワイヤ構成」を選択します。

    3. 「ポータル中間層」セクションで、「公開ホスト」を新しいホスト名で更新します。

    4. 「Oracle Web Cache」セクションで、「ホスト」を新しいホスト名で更新します。

  11. WLS_PORTALインスタンスを再起動します。

18.3.4.8.2 別のホストへのOracle Forms Servicesのリカバリ

別のホストにOracle Forms Servicesをリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. 新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

  4. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

    • webcache.xml。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\config\WebCache\webcache_name

      以前のホスト名をすべて新しいホスト名に置き換えます。

    • instance.properties。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OPMN/opmn
(Windows) ORACLE_INSTANCE\config\OPMN\opmn

      管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。

      adminHost=host_name

    • forms.conf。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf
(Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf

      WebLogicHostパラメータ内のホスト名を新しいホスト名に置き換えます。

  5. 管理サーバーのホストで、次のファイルを編集します。

    DOMAIN_HOME/opmn/topology.xml

    Oracle Forms Servicesの<ias-component id>要素のプロパティを追加します。次の例は、変更後の要素を示しています。

    </ias-component>
  <ias-component id="forms" type="FormsComponent" >
  <em-properties>
      <property name="OracleHome" value="/path_to_oracle_home" />
      <property name="instName" value="instance_name" />
      <property name="EMTargetType" value="oracle_forms" />
      <property name="version" value="11.1.1" />
  </em-properties>
 </ias-component>

  6. Oracleインスタンスをリカバリした新しいホストで、opmnctl updatecomponentregistrationコマンドを使用して、管理サーバーへのコンポーネントの登録を更新します。

    例:

    opmnctl updatecomponentregistration -Host new_host -Port nonSSLPort
    -componentName forms -componentType FormsComponent

  7. ssoregスクリプトを実行します。これは次の場所にあります。

    Identity_Management_ORACLE_HOME/sso/bin

    次のコマンドを使用します。

    ssoreg.sh -site_name newhost:http_listen_port 
    -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
    -oracle_home_path $ORACLE_HOME -config_file any_new_file_path
    -admin_info cn=orcladmin -virtualhost -remote_midtier

    例:

    ssoreg.sh -site_name example.com:8090 
   -mod_osso_url http://example.com:8090 -config_mod_osso TRUE 
   -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf  
   -admin_info cn=orcladmin -virtualhost -remote_midtier

  8. 前の手順のファイルを新しいホストにコピーします。

  9. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ7のファイルのパスが含まれるようにします。

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

    例:

    <IfModule mod_osso.c>
    OssoIpCheck off
    OssoSecureCookies off
    OssoIdleTimeout off
    OssoConfigFile /tmp/path_of_file_created
18.3.4.8.3 別のホストへのOracle Reportsのリカバリ

別のホストにOracle Reportsをリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. 新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

  4. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

    • reports_install.properties。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/reports
(Windows) ORACLE_INSTANCE\reports

      SERVER_NAME、OHS_HOSTおよびREPORTS_MANAGED_WLS_HOSTの各パラメータを編集します。

    • webcache.xml。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\config\WebCache\webcache_name

      以前のホスト名をすべて新しいホスト名に置き換えます。

    • instance.properties。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OPMN/opmn
(Windows) ORACLE_INSTANCE\config\OPMN\opmn

      管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。

      adminHost=host_name

    • reports_ohs.conf。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf
(Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf

    • rwservlet.properties。このファイルは次の場所にあります。

      (UNIX) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration
(Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\configuration

      ファイル内で、<server>要素を変更して、新しいホスト名を使用します。

  5. 次のディレクトリで、新しいホスト名を含むようにサブディレクトリの名前を変更します。

    (UNIX) ORACLE_INSTANCE/diagnostics/logs/ReportsServer
(Windows) ORACLE_INSTANCE\diagnostics\logs\ReportsServer

  6. 次のディレクトリで、old_host_name.datファイルの名前を新しいホスト名に変更します。

    (UNIX) ORACLE_INSTANCE/reports/server
(Windows) ORACLE_INSTANCE\reports\server

  7. 次のディレクトリで、新しいホスト名を含むようにサブディレクトリの名前を変更します。

    (UNIX) ORACLE_INSTANCE/config/ReportsServer
(Windows) ORACLE_INSTANCE\config\ReportsServer

  8. ssoregスクリプトを実行します。これは次の場所にあります。

    Identity_Management_ORACLE_HOME/sso/bin

    次のコマンドを使用します。

    ssoreg.sh -site_name newhost:http_listen_port 
    -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
    -oracle_home_path $ORACLE_HOME -config_file any_new_file_path
    -admin_info cn=orcladmin -virtualhost -remote_midtier

    例:

    ssoreg.sh -site_name example.com:8090 
   -mod_osso_url http://example.com:8090 -config_mod_osso TRUE 
   -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf  
   -admin_info cn=orcladmin -virtualhost -remote_midtier

  9. 前の手順のファイルを新しいホストにコピーします。

  10. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ8のファイルのパスが含まれるようにします。

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

    例:

    <IfModule mod_osso.c>
    OssoIpCheck off
    OssoSecureCookies off
    OssoIdleTimeout off
    OssoConfigFile /tmp/path_of_file_created

  11. 次のファイルで、ホスト名を新しいホスト名に置き換えます。

    (UNIX) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF/mbeans.xml
(Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF\mbeans.xml

  12. 次のファイルで、ホスト名を新しいホスト名に置き換えます。

    ORACLE_INSTANCE/EMAGENT/emagent_<instanceName>/sysman/emd/targets.xml

    次のような文字列で始まる要素内のホスト名を変更します。

    <Target TYPE="oracle_repapp" ..>
<Target TYPE="oracle_repserv" ..>
18.3.4.8.4 別のホストへのOracle Business Intelligence Discovererのリカバリ

別のホストにOracle Business Intelligence Discovererをリカバリする手順は次のとおりです。

  1. 第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。

  2. 第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。

  3. 新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。

    opmnctl registerinstance -adminHost admin_server_host 
     -adminPort admin_server_port -adminUsername username 
     -adminPassword password
     -wlserverHome wlserver_home_location

  4. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

    • module_disco.conf。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/OHS/ohs_name//moduleconf
(Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf

    • webcache.xml。このファイルは次の場所にあります。

      (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\config\WebCache\webcache_name

      以前のホスト名をすべて新しいホスト名に置き換えます。

  5. ssoregスクリプトを実行します。これは次の場所にあります。

    Identity_Management_ORACLE_HOME/sso/bin

    次のコマンドを使用します。

    ssoreg.sh -site_name newhost:http_listen_port 
    -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
    -oracle_home_path $ORACLE_HOME -config_file any_new_file_path
    -admin_info cn=orcladmin -virtualhost -remote_midtier

    例:

    ssoreg.sh -site_name example.com:8090 
   -mod_osso_url http://example.com:8090 -config_mod_osso TRUE 
   -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf  
   -admin_info cn=orcladmin -virtualhost -remote_midtier

  6. 前の手順のファイルを新しいホストにコピーします。

  7. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ5のファイルのパスが含まれるようにします。

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

    例:

    <IfModule mod_osso.c>
    OssoIpCheck off
    OssoSecureCookies off
    OssoIdleTimeout off
    OssoConfigFile /tmp/path_of_file_created

18.3.4.9 別のホストへのOracle BI Enterprise Editionのリカバリ

Oracle BI Enterprise Editionを別のホストにリカバリできますが、新しいホストの名前は元のホストと同じである必要があります。


注意:

Oracle BI EE、またはOracle BI EEと同じ場所にあるその他のコンポーネントを、新しいホスト名の新しいホストにリカバリすることはできません。Oracle BI EEとその他のコンポーネントは、元のホストと同じ名前の新しいホストにのみリカバリできます。たとえば、Oracle BI EEがOracle Real-Time DecisionsおよびOracle Business Intelligence Publisherと同じ場所にある場合、いずれのコンポーネントも別の名前の新しいホストにリカバリすることはできません。

次の各項目で、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。

18.3.4.9.1 非クラスタ環境での別のホストへのOracle BI Enterprise Editionのリカバリ

別のホストにOracle BI EEをリカバリする手順は、オペレーティング・システムによって異なります。

  • UNIXでは、次の手順に従います。

    1. 第18.2.1項の説明に従って、Middlewareホームをリストアします。

    2. 必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.3.6項を参照してください。

  • Windowsでは、次の手順に従います。

    1. 第18.2.1項の説明に従って、Middlewareホームをバックアップからリストアし、作成したMiddlewareホームを新しいインストールで上書きします。

    2. 必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.3.6項を参照してください。

    3. 次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。

      Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe

    4. 第18.3.4.9.4項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。

18.3.4.9.2 クラスタ環境での別のホストへのOracle BI Enterprise Editionのリカバリ

このシナリオでは、ホストAとホストBの2つのホストにOracle BI EEクラスタがある場合を考えます。ホストAは、なんらかの理由で(元のオペレーティング・システムの破損など)置き換えられ、ホストCにリカバリする必要があります。

次の手順に従います。

  1. 第18.2.1項の説明に従って、MiddlewareホームをバックアップからホストCにリストアします。

  2. 必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.3.6項を参照してください。

  3. Windowsでは、次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。

    Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe

  4. Windowsでは、第18.3.4.9.4項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。

  5. 障害が発生したノードに管理サーバーが含まれている場合、第18.3.2.2項のステップ1 - 5の説明に従ってリカバリします。

  6. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのAPPHOST2上のBIシステムのスケールアウトに関する項の説明に従って、Oracle BI EEシステムをスケールアウトします。

    ドメイン・ホームおよびアプリケーション・ホームのディレクトリの指定を入力する場合、存在していないディレクトリまたは空のディレクトリの指定を入力します。

  7. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシステム・コンポーネントのスケールアウトに関する項の説明に従って、システム・コンポーネントをスケールアウトします。

    ホストAのインスタンス1は使用できないので、そのBIサーバー、プレゼンテーション・サーバー、およびJavaHostの数を0に変更する必要があります。

    すると、ホストB上のインスタンス2は、自動的にプライマリ・インスタンスになります。ホストC上の新しいインスタンスのインスタンス3は、セカンダリ・インスタンスになります。

  8. Oracle BIクラスタ・コントローラおよびOracle BIスケジューラは、アクティブ/パッシブ・モードで動作するシングルトン・コンポーネントです。Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項の説明に従って、これらのコンポーネントのセカンダリ・インスタンスを、高可用性のために分散されるように構成します。

  9. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server2管理対象サーバーのリスニング・アドレスの設定に関する項の説明に従って、bi_servern管理対象サーバーのリスニング・アドレスを設定します。

  10. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server2管理対象サーバーのホスト名検証の無効化に関する項の説明に従って、bi_servern管理対象サーバーのホスト名検証を無効にします。

  11. 環境に応じて、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのOracle Business Intelligenceの可用性のための追加構成の実行に関する項の説明に従って、追加構成を実行します。

  12. Oracle HTTP Serverがインストールされている場合、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのフロントエンドHTTPホストおよびポートの設定に関する項の説明に従って、Oracle BI Search URLが正しく設定されるようにOracle WebLogic ServerクラスタのフロントエンドHTTPホストおよびポートを設定します。

  13. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの管理対象サーバーのノード・マネージャの構成に関する項の説明に従って、管理対象サーバーのノード・マネージャを構成します。

  14. Oracle BI EE管理対象サーバーおよびすべてのOPMNの管理対象コンポーネントを起動します。

18.3.4.9.3 Oracle BI EEのリカバリの追加手順

環境に応じて、第18.3.4.9.2項の手順を実行した後に、追加手順を実行する必要がある場合があります。

  • ホストにマスターBIサーバー、プライマリ・クラスタ・コントローラ、およびプライマリOracle BIスケジューラが含まれている環境で障害が発生したときに、新しいインスタンスをマスターBIサーバーにする必要がある場合、必要に応じて次の手順を実行します。インスタンス2を引き続きマスターBIサーバーにする場合は、この追加手順を実行する必要はありません。

    • マスターBIサーバーが失われた場合、次の手順を実行します。

      1. すべてのノードでOracle WebLogic ServerおよびOPMNプロセスを停止します。

      2. 新しいマスターBIサーバーを指定するように次の構成ファイルを更新します。

        INSTANCE_HOME/config/OracleBIApplication/coreapplication/ClusterConfig.xml

        たとえば、NodeId要素でインスタンス数を変更し、HostNameOrIP要素でホスト名またはIPアドレスを変更します。

        <Node> 
   <NodeType>Server</NodeType> 
    <!--This Configuration setting is managed by Oracle Business 
 Intelligence Enterprise Manager-->
      <MasterServer>true</MasterServer> 
     <!--This Configuration setting is managed by Oracle Business 
 Intelligence Enterprise Manager-->
     <NodeId>instance2:coreapplication_obis1</NodeId> 
      <!--This Configuration setting is managed by Oracle Business 
Intelligence Enterprise Manager-->
<HostNameOrIP>host1.example.com</HostNameOrIP> 
    <!--This Configuration setting is managed by Oracle Business 
 Intelligence Enterprise Manager-->
   <ServicePort>9703</ServicePort> 
             <!--This Configuration setting is managed by Oracle Business 
 Intelligence Enterprise Manager--><MonitorPort>9701</MonitorPort> 
         </Node>

    • プライマリ・クラスタ・コントローラまたはスケジューラが失われた場合、スタンバイ・クラスタ・コントローラまたはスケジューラにフェイルオーバーされます。これはプライマリ・クラスタ・コントローラになるように再構成するか、プライマリ・コンポーネントに障害が発生しているために有効にされているセカンダリのままにするかを決定する必要があります。Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。

  • 障害が発生したホストにBIサーバー、セカンダリ・クラスタ・コントローラ、およびセカンダリOracle BIスケジューラが含まれる場合、セカンダリ・クラスタ・コントローラまたはスケジューラとして新しいホストを指定します。

  • 障害が発生したホストにBIサーバーおよびBIプレゼンテーション・サービスやBI Javaホストなどのシステム・コンポーネントが含まれる場合、追加手順は不要です。

  • 障害が発生したホストに次の関連するコンポーネントが含まれる場合、それらをリカバリします。

18.3.4.9.4 Oracle BI Enterpriseレジストリ・エントリのインポート

Windowsでは、Oracle BI Enterprise Editionレジストリ・エントリを新しいホストにインポートする必要があります。 第17.3.3項には元のホストからそれらをエクスポートする方法が説明されています。

  1. 元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。

  2. 元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。

18.3.4.10 別のホストへのOracle Business Intelligence Publisherのリカバリ

別のホストにOracle Business Intelligence Publisherをリカバリする手順は次のとおりです。

  1. 第18.3.3項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。

  2. 必要に応じて、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。

バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。

18.3.4.11 別のホストへのOracle Real-Time Decisionsのリカバリ

別のホストにOracle Real-Time Decisionsをリカバリする手順は次のとおりです。

  1. 第18.3.3項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。

バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。

18.3.4.12 別のホストへのOracle Data Integratorのリカバリ

別のホストにOracle Data Integratorをリカバリする手順は次のとおりです。

  1. データベースを別のホストにリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。

  2. 第18.2.3項の説明に従って、バックアップからOracle Data IntegratorのOracleホームをリカバリします。

  3. 第18.3.2項の説明に従って、ドメインをリストアします。

  4. 各スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを停止します。

  5. データベースが別のホストにある場合は、トポロジ内のリポジトリ接続情報を変更します。

    1. ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。『Oracle Fusion Middleware Oracle Data Integratorのための開発者ガイド』のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのマスター・リポジトリの新しい接続を作成します。

    2. 作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。

    3. 各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。

    4. スタンドアロン・エージェントのスクリプトが生成されていて、それらに-PORTプロパティが含まれる場合は、-PORTの値を新しいポートの値に変更します。スクリプトの名前は、agentName_agent.shまたはagentName_agent.batです。

  6. スタンドアロン・エージェントごとに次のファイルを編集し、データベースが別のホストにある場合は、新しいデータベース・ホストの場所に一致するようにODI_MASTER_URLパラメータを変更します。

    oracledi/agent/bin/odiparams.*

  7. 次のファイルを編集して、データベース接続情報とポート番号を変更します。

    oracledi/agent/bin/odi_opmn_standaloneagent_template.xml

  8. Oracle WebLogic Server構成で、新しいデータベース・ホストの場所に一致するようにデータソースを編集します。

  9. スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。

18.3.4.13 別のホストへのOracle Enterprise Content Management Suiteのリカバリ

次の各項で、Oracle Universal Content ManagementおよびOracle Universal Records Managementを別のホストにリカバリする方法について説明します。

18.3.4.13.1 別のホストへのOracle Universal Content Managementのリカバリ

別のホストにOracle Universal Content Managementをリカバリする手順は次のとおりです。

  1. データベースを別のホストにリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。

  2. 第18.3.2項の説明に従って、ドメインをリストアします。

  3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。

    cd /net/home/vault
tar -xf vault_backup_092010.tar

  4. 次のファイルを編集します。

    DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg

    このファイルで、新しいホストを指定するようにHttpServerAddressの設定を変更します。たとえば、次のように指定します。

    HttpServerAddress=hostname:port_number

データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。

18.3.4.13.2 ホスト破損後のOracle Universal Records Managementのリカバリ

Oracle Universal Records Managementは、Oracle Universal Content Managementに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle Universal Content Managementのリカバリ手順(第18.3.4.13.1項)を参照してください。

18.3.5 ホストの破損後にエンティティをリカバリするための追加の操作

リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行する必要がある場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。

次の各項目で、実行することが必要な可能性のある操作について説明します。

18.3.5.1 別のホストへのFusion Middleware Controlのリカバリ

別のホストにFusion Middleware Controlをリカバリするには、次の手順に従います。

  1. 次のファイル内のホスト名を更新します。

    DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/em/hsz5x1/META-INF/emoms.properties

    このファイルで、次のプロパティのホスト名を変更します。

    mas.conn.url
oracle.sysman.emSDK.svlt.ConsoleServerHost

  2. 次のファイルを編集します。

    (UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties
(Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties

    このファイルで、Oracle Management Agentによって監視されている各コンポーネントの次のエントリを編集し、ホスト名を置き換えます。

    REPOSITORY_URL=http://newhost.domain.com:port/em/upload/

18.3.5.2 Fusion Middleware Controlのtargets.xmlファイル内のホスト名の変更

別のホストにコンポーネントをリカバリする場合、Fusion Middleware Controlのtargets.xmlファイルを更新する必要があります。このファイルは次の場所にあります。

DOMAIN_HOME/sysman/state/targets.xml

このファイルで、別のホストにリカバリするコンポーネントのホスト名を新しいホスト名に変更します。

18.3.5.3 コンポーネントを別のホストにリカバリした場合のOracle Management Agentのリカバリ

多くのコンポーネントでは、別のホストにリカバリするときに、ホストの破損の場合と同様に、Fusion Middleware Controlがコンポーネントを管理できるように、Oracle Management Agentをリカバリする操作を実行する必要があります。これは、次のインストール・タイプやコンポーネントに関連しています。

  • アイデンティティ管理コンポーネント

  • Oracle Identity Federation

  • Oracle Portal

  • Oracle Business Intelligence Discoverer

  • Oracle Forms Services

  • Oracle Reports

Oracle Management Agentをリカバリするには、次の手順を実行します。

  1. 次のファイルを編集します。

    (UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/emd/targets.xml 
(Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\emd\targets.xml

    ファイル内で、次の要素を編集し、ホスト名を置き換えます。

    <Target TYPE="host" NAME="newhost.domain.com"
     DISPLAY_NAME="newhost.domain.com"/>

  2. 次のファイルを編集します。

    (UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties
(Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties

    次のエントリを更新して、ホスト名を置き換えます。

    EMD_URL=http://newhost.domain.com:port/emd/main

  3. 次のコマンドを使用して、Oracle Management Agentを起動します。

    opmnctl startproc ias-component=EMAGENT

  4. 管理サーバーを起動します。

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
 -Dweblogic.management.password=password
 -Dweblogic.system.StoreBootIdentity=true

    管理サーバーを起動すると、Fusion Middleware Controlも起動されます。

18.3.5.4 mod_wl_ohs.confファイルの変更

管理サーバーまたは管理対象サーバーを別のホストにリカバリする場合、環境にOracle HTTP Serverが含まれていると、新しいホスト上で次のファイルを変更する必要があります。

(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/mod_wl_ohs.conf
(Windows) ORACLE_INSTANCE\config\OHS\ohs_name\mod_wl_ohs.conf

そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(WebLogicHost、WebLogicPort、WebLogicClusterなどの要素)を変更します。たとえば、次のように指定します。

<Location /console>
    SetHandler weblogic-handler
    WebLogicHost Admin_Host
    WeblogicPort Admin_Port
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
 .
 .
 .
<Location /soa-infra>
   SetHandler weblogic-handler
   WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001*
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

18.3.5.5 特定のコンポーネントの新しいマシンの作成

次のアイデンティティ管理コンポーネント(およびリスニング・アドレスを使用している場合は管理サーバー)の場合、管理サーバーを起動する前に、新しいホスト名で新しいマシンを作成する必要があります。

  • Oracle Access Manager

  • Oracle Adaptive Access Manager

  • Oracle Identity Manager

  • Oracle Identity Navigator

次の手順に従います。

  1. 新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。

    wls:/offline> readDomain('DomainHome')
wls:/offline/sampledomain> machine = create('newhostname', 'Machine')
wls:/offline/sampledomain> cd('/Machine/newhostname')
wls:/offline/sampledomain> nm = create('newhostname', 'NodeManager')
    wls:/offline/sampledomain> cd('/Machine/newhostname/NodeManager/newhostname')
    wls:/offline/sampledomain> set('ListenAddress', 'newhostname')
    wls:/offline/sampledomain> updateDomain()
    wls:/offline/sampledomain> exit()

  2. 管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。

    wls:/offline> readDomain('DomainHome')
wls:/offline/sampledomain> cd ('/Machine/newhostname')
wls:/offline/sampledomain> machine = cmo
wls:/offline/sampledomain> cd ('/Server/AdminServer')
wls:/offline/sampledomain> set('Machine', machine)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()

18.3.5.6 特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け

次のアイデンティティ管理コンポーネントのバックアップをリストアすると、Weblogicユーザーは、前に関連付けられていたグループとは関連付けられなくなります。

  • Oracle Access Manager

  • Oracle Adaptive Access Manager

  • Oracle Identity Manager

  • Oracle Identity Navigator

Weblogicユーザーをグループに再関連付けする必要があります。

ユーザーのグループへの関連付けの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのユーザーのグループへの追加に関する項を参照してください。

18.3.5.7 Oracleインベントリの更新

多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。

ORACLE_HOME/oui/bin/attachHome.sh

また、beahomelistを更新して、Middlewareホームの場所を編集する必要があります。次のファイルを編集して、Middlewareホームの情報を更新します。

(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist

18.3.5.8 Windowsレジストリのリカバリ

Windows上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、次のWindowsレジストリ・キーをリカバリする必要があります。

HKEY_LOCAL_MACHINE\Software\Oracle

また、Oracle Web Cacheなどのシステム・コンポーネントをリカバリするときは、次のWindowsレジストリキーをリカバリする必要があります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

前にエクスポートしたキーをインポートするには、次のコマンドを使用します。

regedit  /I  FileName

例:

regedit /I C:\oracleregistry.reg

キーのインポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。

18.3.6 データベース・ホストの破損後のリカバリ

データベースを含むホストが破損した場合、RMANを使用してリカバリできます。

例:

rman> restore database;
rman> recover database;

最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。また、データベースに同じ名前を使用します。次の事項に注意してください。

  • 各コンポーネントで使用するスキーマについては、付録Dを参照してください。

  • Oracle BPEL Process Managerのポイント・イン・タイム・リカバリを使用すると、最新のプロセス定義および進行中のインスタンスがリストアされます。ただし、これによってプロセスの手順が再実行される場合があります。できるかぎり、Oracle BPEL Process Managerの冪等プロセスを使用することをお薦めします。冪等以外のプロセスがシステムに含まれている場合は、それらをデハイドレーション・ストアからクリーンアップしてからOracle Fusion Middlewareを起動する必要があります。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

データベースのリカバリおよびRMANの使用の詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次のリンクから入手可能です。

http://www.oracle.com/technology/documentation/database.html
  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引