1. Oracle Fusion Middlewareの管理
  2. 高度な管理: バックアップとリカバリ
  3. 環境のリカバリ

18 環境のリカバリ

Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害やホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順が用意されています。
  • リカバリ戦略の概要
    リカバリ戦略により、実データの損失などの重大な障害からのリカバリが可能になります。
  • データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ
    実データの損失や破損、またはディスクのリストアが不可能なメディア障害を伴う停止の場合に、環境の一部または全体をリカバリする必要があります。また、状況によっては、正しく機能しなくなったアプリケーションをリカバリする必要もあります。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
  • ホストの破損後のリカバリ
    Oracle Fusion Middlewareの元の動作環境が損なわれた場合、その環境をリカバリする必要があります。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。

親トピック: 高度な管理: バックアップとリカバリ

リカバリ戦略の概要

リカバリ戦略により、実データの損失を伴う重大な障害から回復できます。損失のタイプに応じて、次のファイル・タイプの組合せをリカバリできます。

  • Oracleソフトウェア・ファイル

  • 構成ファイル

  • Oracleシステム・ファイル

  • Windowsレジストリ・キー

  • アプリケーション・アーティファクト

Oracle Fusion Middleware環境のリカバリは、Oracle Fusion Middlewareがオフラインのときに実行できます。

次の各項目では、リカバリ戦略について説明します。

親トピック: 環境のリカバリ

リカバリのタイプ

Oracle Fusion Middleware環境は、その一部または全体をリカバリできます。次のリカバリが可能です。

  • Oracleホーム

  • WebLogic Serverドメイン

  • スタンドアロン・ドメイン

  • 管理サーバー

  • 管理対象サーバー

  • Oracle SOA SuiteやOracle HTTP Serverなどのコンポーネント

  • WebLogic Serverクラスタ

  • デプロイ済アプリケーション

  • データベース

親トピック: リカバリ戦略の概要

推奨されるリカバリ戦略

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

ノート:

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

リカバリに関しては次の重要な点に注意してください。

  • リカバリの実行中は、Oracle Fusion Middleware環境をオフラインにする必要があります。

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

  • 1、2個のファイルのみが消失または破損しているように見える場合もありますが、1、2個のファイルのみをリストアするのではなく、ドメインなど要素全体のディレクトリ構造をリストアする必要があります。そうすることで、リカバリが成功する可能性が高くなります。

  • ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これは通常、データベースに障害が発生する直前の状態です。

  • ファイルのリストア時に圧縮ファイルを解凍するには、「バックアップおよびリカバリで使用するツール」の説明に従って、それに適したツールを使用します。

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

環境をリカバリする場合は、正しい順序でエンティティをリカバリすることが重要です。

  1. データベース(リカバリが必要な場合)。「データベースのリカバリ」および「データベース・ホストの破損後のリカバリ」を参照してください。

  2. Oracleホーム(リカバリが必要な場合)。「Oracleホームのリカバリ」を参照してください。

  3. ドメイン全体(リカバリが必要な場合)。WebLogic Server管理対象ドメインのリカバリについては、「Oracle WebLogic Serverドメインのリカバリ」および「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」を参照してください。スタンドアロン・ドメインのリカバリについては、「スタンドアロン・ドメインのリカバリ」を参照してください。

  4. 管理サーバー(ドメインのリカバリが不要な場合)。「管理サーバー構成のリカバリ」および「管理サーバー・ホストの破損後のリカバリ」を参照してください。

  5. 管理対象サーバー(管理対象サーバーが管理サーバードメイン・ディレクトリになく、リカバリが必要な場合)。「管理対象サーバーのリカバリ」および「管理対象サーバー・ホストの破損後のリカバリ」を参照してください。

    Javaコンポーネントは、管理対象サーバーをリカバリする際にリカバリされます。システム・コンポーネントは、ドメインをリカバリする際にリカバリされます。状況によっては、「コンポーネントのリカバリ」および「コンポーネント・ホストの破損後のリカバリ」の説明に従って特定のステップを実行する必要があります。

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

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

    コンポーネント データの損失、破損、メディア障害の場合 ホスト破損の場合

    Oracle B2B

    Oracle B2Bのリカバリ

    Oracle B2Bのリカバリ

    Oracle Data Integrator

    該当なし

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

    Oracle Forms Services

    該当なし

    同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle Forms Servicesのリカバリ」を参照してください。

    Oracle HTTP Server

    該当なし

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

    Oracle Platform Security Services

    Oracle Platform Security Servicesのリカバリ

    Oracle Platform Security Servicesのリカバリ

    Oracle Reports

    該当なし

    別のホストへのOracle Reportsのリカバリ

    Oracle SOA Suite

    該当なし

    同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「ホスト破損後のOracle SOA Suiteのリカバリ」を参照してください。

    Oracle WebCenter Content

    Oracle WebCenter Contentのリカバリ

    別のホストへのOracle WebCenter Contentのリカバリ

    Oracle WebCenter Content: Records。

    Oracle WebCenter Contentをリカバリします。「Oracle WebCenter Contentのリカバリ」を参照してください。

    Oracle WebCenter Contentをリカバリします。「別のホストへのOracle WebCenter Contentのリカバリ」を参照してください。

    Oracle WebCenter Portalの分析

    Oracle WebCenter Portal分析のリカバリ

    Oracle WebCenter Portal分析のリカバリ

    Oracle WebLogic Server

    Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。

    Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。

  7. アプリケーション(リカバリが必要な場合)。「アプリケーションのリカバリ」を参照してください。

親トピック: リカバリ戦略の概要

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

実データの損失や破損、またはディスクのリストアが不可能なメディア障害を伴う停止の場合に、環境の一部または全体をリカバリする必要があります。また、状況によっては、正しく機能しなくなったアプリケーションをリカバリする必要もあります。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。

ノート:

エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。

親トピック: 環境のリカバリ

Oracleホームのリカバリ

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

Oracleホームをリカバリするには:

  1. 関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
    DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
  2. Oracleホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
  3. バックアップからOracleホーム・ディレクトリをリカバリします。たとえば:
    (UNIX) tar -xf oracle_home_backup_06052017.tar
(Windows) jar xf oracle_home_backup_06052017.jar
  4. 関連するすべてのプロセスを起動します。つまり、管理サーバーや管理対象サーバーなど、Oracleホームで実行されているすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
    DOMAIN_HOME/bin/startWebLogic.sh

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

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

破損したりファイル・システムから削除された場合、またはドメインが格納されているホストが破損した場合、Oracle WebLogic Serverドメインをリカバリすることができます。

注意:

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

破損したりファイル・システムから削除されたOracle WebLogic Serverドメインをリカバリするには:

  1. 関連するプロセスが実行中である場合、そのプロセスをすべて停止します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
    DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

    Oracle HTTP Serverなどのシステム・コンポーネントの停止の詳細は、「コマンド行を使用したコンポーネントの起動と停止」を参照してください。

  2. ドメイン・ホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
  3. バックアップからドメイン・ディレクトリをリカバリします。
    (UNIX) tar -xf domain_backup_06052017.tar 
(Windows) jar xf domain_backup_06052017.jar
  4. 関連するすべてのプロセスを起動します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
    DOMAIN_HOME/bin/startWebLogic.sh

    Oracle HTTP Serverなどのシステム・コンポーネントの起動の詳細は、「コマンド行を使用したコンポーネントの起動と停止」を参照してください。

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

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

サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ

データベース・リース(たとえば、サーバー全体の移行)を使用して、Oracle WebLogic Serverをリカバリする場合は、リース表内の情報を破棄する必要があります。単にリース表を破棄して再作成する場合は、リース表作成スクリプトを実行します。(サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照。)

スタンドアロン・ドメインのリカバリ

破損したりファイル・システムから削除された場合、またはホストが破損して同じホストにリカバリする必要がある場合、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。

スタンドアロン・ドメインをリカバリするには、次の手順に従います。

  1. Oracle HTTP Serverなどのシステム・コンポーネントやノード・マネージャが実行中の場合は、停止します。
  2. 破損している場合は、Oracleホームをリカバリします。
    (UNIX) tar xf oracle_home_backup_05_21_2013.tar
(Windows) jar xf oracle_home_backup_05_21_2013.jar
  3. ドメイン・ホームをリカバリします。
    (UNIX) tar xf domain_backup_05_21_2013.tar
(Windows) jar xf domain_backup_05_21_2013.jar
  4. ノード・マネージャを起動します。
    (UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
  5. ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。
    (UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1

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

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

ファイルの削除やファイル・システムの破損によって管理サーバー構成が失われた場合、問題発生時にリモート・コンソールがすでに起動されていれば、リモート・コンソールは機能し続けます。管理サーバーがユーザー名やパスワードのプロンプトを表示しないようにするには、「資格証明を入力しないサーバーの起動の有効化」を参照してください。

注意:

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

管理サーバーの構成をリカバリするには:

  1. 管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
    DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
  2. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
    DOMAIN_HOME/config
  3. 管理サーバーを起動します。たとえば:
    DOMAIN_HOME/bin/startWebLogic.sh
  4. 管理サーバーが正常に起動しており、アクセス可能であることを確認します。

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

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

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

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

このシナリオでは、管理対象サーバーが管理サーバーと同じホストに存在しておらず、適切に動作しない場合や起動できない場合を想定しています。この原因としては、構成の削除、構成の破損、構成を誤って変更したがその変更内容が不明であることなどが考えられます。

管理対象サーバーをリカバリするには、次の手順に従います。

  1. 管理サーバーにアクセスできない場合は、「管理サーバー構成のリカバリ」の説明に従って、管理サーバーをリカバリします。
  2. 管理対象サーバーが稼働中である場合は、停止します。たとえば:
    DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url
        username password
  3. 必要に応じて、Oracleホームをバックアップからリカバリします。たとえば:
    tar -xf oracle_home_backup_06052017.tar
  4. 「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
  5. 管理サーバーのホストでpackユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば:
    pack.sh -domain=/scratch/oracle/config/domains/WLS_domain
  -template=/scratch/temp.jar -template_name=test_install 
  -template_author=myname -log=/scratch/logs/my.log -managed=true

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

  6. 管理対象サーバーのホストでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。次の例では、temp.jarはpackコマンドにより作成されたアーカイブです。
    unpack.sh -template=/scratch/temp.jar
   -domain=/scratch/oracle/config/domains/WLS_domain
   -log=/scratch/logs/new.log -log_priority=info

    ノート:

    • 次のディレクトリが存在している必要があります。存在しない場合、unpackコマンドが失敗します。

      ORACLE_HOME/config/domains/

    • unpackコマンドの-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。環境で必要な場合は、-overwrite_domainオプションを使用してください。

    • -app_dir引数を使用して別の場所に渡さないかぎり、アプリケーションはデフォルトで次のディレクトリに格納されます。

      ORACLE_HOME/user_projects/applications/Domain_Name
  7. 管理対象サーバーを起動します。たとえば:
    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

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

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

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

次の項では、特定のコンポーネントに対して実行する必要がある追加のステップについて説明します。

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

Oracle Platform Security Servicesのリカバリ

Oracle Platform Security Servicesの場合は、次のファイルをリストアします。 

DOMAIN_HOME/config/fmwconfig/jps-config.xml
DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml
DOMAIN_HOME/config/fmwconfig/cwallet.sso
DOMAIN_HOME/config/fmwconfig/bootstrap/cwallet.sso
DOMAIN_HOME/config/fmwconfig/keystores.xml
DOMAIN_HOME/config/config.xml
DOMAIN_HOME/config/fmwconfig/ids_config.xml
DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml (if present)
DOMAIN_HOME/config/fmwconfig/jps_mbeans.xml
Oracle WebCenter Portal分析のリカバリ

Oracle WebCenter Portal分析をリカバリするには:

  1. 「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリストアします。
  2. 「Oracleホームのリカバリ」の説明に従って、Oracleホームをリストアします。
  3. 必要に応じて、ACTIVITIESスキーマおよびMDSスキーマが含まれるデータベースをリストアします。
Oracle WebCenter Contentのリカバリ

Oracle WebCenter Contentをリカバリするには:

  1. 必要に応じて、「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
  2. 「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリストアします。
  3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
    cd /net/home/vault
tar -xf vault_backup_042012.tar

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

クラスタのリカバリ

次の状況では、クラスタをリカバリする必要があります。

  • クラスタが誤って削除されているか、クラスタ・メンバーが誤って削除されている。

  • JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされている。コンポーネントまたはサーバーは起動できないか、または適切に動作せず、サーバー内で実行中のサービスは起動されていません。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

注意:

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

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

  1. クラスタを停止します。Fusion Middleware Control、Oracle WebLogicリモート・コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
    shutdown('cluster_name', 'Cluster')
  2. 管理サーバーや管理対象サーバーなど、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
    DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
  3. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
    DOMAIN_HOME/config
  4. 管理サーバーを起動します。たとえば:
    DOMAIN_HOME/bin/startWebLogic.sh

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

  5. 管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。
    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
  6. クラスタを起動します。Fusion Middleware Control、Oracle WebLogicリモート・コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
    start('cluster_name', 'Cluster')

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

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

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

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

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

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

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

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

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

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

アプリケーションをリカバリするには:

  1. アプリケーションのデプロイ先の管理対象サーバーを起動します。たとえば:
    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

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

Jakarta EEアプリケーションのリカバリ

次の場合、Jakarta EEアプリケーションをリカバリできます。

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

  • デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合。

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

アプリケーションをリカバリするには:

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

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

データベースのリカバリ

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

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

rman> restore database;
rman> recover database;

各コンポーネントで使用されるスキーマについては、『Repository Creation Utilityによるスキーマの作成』を参照してください。

データベースのリカバリの詳細なステップは、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

ホスト破損後のリカバリ

Oracle Fusion Middlewareの元の動作環境が損なわれた場合、その環境をリカバリする必要があります。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。

親トピック: 環境のリカバリ

Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ

ホストの破損後に、Oracle WebLogic Serverドメインをリカバリするには、「Oracle WebLogic Serverドメインのリカバリ」のステップに従います。

親トピック: ホスト破損後のリカバリ

スタンドアロン・ドメイン・ホストの破損後のリカバリ

スタンドアロンドメインを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

親トピック: ホスト破損後のリカバリ

同じホストへのスタンドアロン・ドメインのリカバリ

オペレーティング・システムの再インストール後に、スタンドアロン・ドメインを同じホストにリカバリするには、「スタンドアロン・ドメインのリカバリ」の手順に従います。

別のホストへのスタンドアロン・ドメインのリカバリ

このシナリオでは、スタンドアロン・ドメインを別のホストにリカバリします。

スタンドアロン・ドメインを別のホストにリカバリするには、次の手順に従います。

  1. Oracleホームをリカバリします。
    (UNIX) tar xf oracle_home_backup_05_21_2017.tar
(Windows) jar xf oracle_home_backup_05_21_2017.jar
  2. ドメイン・ホームをリカバリします。
    (UNIX) tar xf domain_backup_05_21_2017.tar
(Windows) jar xf domain_backup_05_21_2017.jar
  3. スタンドアロン・ドメインでは、デフォルトで、ノード・マネージャはローカル・ホストでリスニングします。ただし、そうではない場合、次のWLSTコマンドを使用してListenAddressを更新できます。
    readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
  4. ノード・マネージャを起動します。
    (UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
  5. システム・コンポーネントの構成ファイルをすべて、手動で更新します。

    特定コンポーネントの詳細は、「コンポーネント・ホストの破損後のリカバリ」を参照してください。

  6. ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。たとえば:
    (UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1
  7. 「Oracleインベントリの更新」の説明に従って、Oracleインベントリを更新します。
  8. Windowsの場合は、「Windowsレジストリのリカバリ」の説明に従って、Windowsレジストリを更新します。

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

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

親トピック: ホスト破損後のリカバリ

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

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

同じホストに管理サーバーをリカバリするには:

  1. ファイル・システムをリカバリします。たとえば、「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、この管理サーバーが含まれるドメインをリカバリします。

  2. 管理サーバーを起動します。たとえば:

    DOMAIN_HOME/bin/startWebLogic.sh

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

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

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

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

      tar -xf oracle_home_backup_06052017.tar

    3. ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。

      tar -xf domain_backup_06052017.tar

    4. 管理サーバーを起動します。たとえば:

      DOMAIN_HOME/bin/startWebLogic.sh

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

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

      DOMAIN_HOME/bin/startNodeManager.sh
別のホストへの管理サーバーのリカバリ

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

別のホストに管理サーバーをリカバリするには:

  1. OracleホームをホストC (新規ホスト)にリカバリします。
    tar -xf oracle_home_backup_06052017.tar
  2. ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。
    tar -xf domain_backup_06052017.tar
  3. 管理サーバーにリスニング・アドレスが指定されている場合は、「特定のコンポーネントの新しいマシンの作成」の説明に従って、新しいホスト名で新しいマシンを作成します。
  4. 管理サーバーを起動します。たとえば:
    DOMAIN_HOME/bin/startWebLogic.sh
  5. WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。
    connect('username','password','t3://host:port')
nmEnroll('/scratch/oracle/config/domains/domain_name',
  'DOMAIN_HOME/nodemanager')

    Windowsの場合は、UNIXの場合と同様に、nmEnrollコマンドではバックスラッシュ(\)ではなくスラッシュ(/)を使用します。

  6. ノード・マネージャのプロパティ・ファイルを編集して、リスニング・アドレス・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。
    DOMAIN_HOME/nodemanager/nodemanager.properties

    または、次のWLSTコマンドを使用してプロパティを変更できます。

    readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
updateDomain()
  7. 元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。
    cd DOMAIN_HOME/bin
./startNodeManager.sh
  8. 管理対象サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』の障害が発生した管理サーバーの再起動に関する項では、構成に応じた様々な再起動方法について説明されています。

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

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

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

  10. 「Oracleインベントリの更新」の説明に従って、Oracleインベントリを更新します。
  11. Windowsでは、「Windowsレジストリのリカバリ」の説明に従って、Windowsレジストリをリカバリします。
  12. 環境にOracle HTTP Serverが含まれる場合、「mod_wl_ohs.confファイルの変更」の説明に従って、mod_wl_ohs.confファイルを修正します。

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

Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、「ホストの破損後にエンティティをリカバリするための追加の操作」を参照してください。

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

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

親トピック: ホスト破損後のリカバリ

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

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

同じホストに管理対象サーバーをリカバリするには:

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

    cd DOMAIN_HOME/bin
./startNodeManager.sh

  2. 管理対象サーバーを起動します。たとえば:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

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

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

      tar -xf oracle_home_backup_06052017.tar

    2. 「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。

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

      cd Domain_Home
tar -xf domain_home_backup_06052017.tar

      ステップ3.eに進みます。

    4. 管理対象サーバーにOracle Forms ServicesまたはOracle Reportsが含まれない場合、次のステップを実行します。

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

        pack.sh -domain=/scratch/oracle/config/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/temp.jar
  -domain=/scratch/oracle/config/domains/domain_name 
  -log=/scratch/logs/new.log -log_priority=info

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

      ノート:

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

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

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

    6. 次のWLSTコマンドを使用して、ノード・マネージャのプロパティListenAddressを更新します。

      readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()

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

      cd DOMAIN_HOME/bin
./startNodeManager.sh

    8. 管理対象サーバーを起動します。たとえば:

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

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

このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストCにリカバリする必要があります。1台以上のWebLogic Serversをホストするコンピュータの論理表現である2台のマシン、ホストAのmachine_1およびホストBのmachine_2があります。

ノート:

Oracleホームは元と同じ場所にリカバリしてください。

別のホストに管理対象サーバーをリカバリするには:

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

    tar -xf oracle_home_backup_06052014.tar

  2. 新しいホストを指すように、トポロジを再構成します。

    1. バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、「WebLogic Server構成のロック」で説明しているようにWebLogic Serverの構成をロックします。

    2. Fusion Middleware Controlで、新しいホストを指し示すようmachine_2の構成を変更します。

      「WebLogicドメイン」メニューから「環境」を展開し、「マシン」を選択します。「マシン」ページで、machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。

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

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

      リモート・コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。

      マシンをmachine_2に変更します。

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

      「保存」をクリックしてから、「変更のアクティブ化」をクリックします。

    4. 「セッションの編集」メニューで「構成の解放」をクリックして、Oracle WebLogic Server構成のロックを解除します。

  3. 表18-1の説明に従って、必要なステップがあればそれを実行します。

  4. 「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。

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

    cd Domain_Home
tar -xf domain_home_backup_042012.tar

    ステップ7に進みます。

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

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

      pack.sh -domain=/scratch/oracle/config/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/temp.jar
   -domain=/scratch/oracle/config/domains/domain_name
   -log=/scratch/logs/new.log -log_priority=info

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

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

    ノート:

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

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

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

  8. 次のWLSTコマンドを使用して、ListenAddressを更新します。

    readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()

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

    cd DOMAIN_HOME/bin
./startNodeManager.sh

  10. 管理対象サーバーを起動します。たとえば:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

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

  11. 「Oracleインベントリの更新」の説明に従って、Oracleインベントリを更新します。

  12. Windowsでは、「Windowsレジストリのリカバリ」の説明に従って、Windowsレジストリをリカバリします。

  13. 環境にOracle HTTP Serverが含まれる場合、「mod_wl_ohs.confファイルの変更」の説明に従って、mod_wl_ohs.confファイルを修正します。

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

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

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

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

親トピック: ホスト破損後のリカバリ

同じホストまたは別のホストへのJavaコンポーネントのリカバリ

Javaコンポーネントを同じホストにリカバリするには、次の手順に従います。

  1. 「同じホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
  2. 表18-1に示すように、コンポーネントに追加ステップが必要な場合は、それらのステップを実行します。
別のホストへのJavaコンポーネントのリカバリ

別のホストにJavaコンポーネントをリカバリするには:

  1. 「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
  2. 表18-1に示すように、コンポーネントに追加ステップが必要な場合は、それらのステップを実行します。
同じホストまたは別のホストへのシステム・コンポーネントのリカバリ

Oracle HTTP Serverなどのシステム・コンポーネントを同じホストまたは別のホストにリカバリするには、次のようにします。

ただし、表18-1に示すように、一部のコンポーネントでは追加ステップが必要です。

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

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

ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリするには:

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

  2. 「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。

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

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

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

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

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

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

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

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

    ノート:

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

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

    1. Fusion Middleware Controlで、「WebLogicドメイン」メニューから、「環境」、「クラスタ」の順に選択します。

    2. 構成するクラスタを選択します。

    3. 「WebLogicクラスタ」メニューから、「管理」、「HTTP」の順に選択します。

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

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

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

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

Web層はOracle HTTP Serverで構成されています。次の各項目では、別のホストにリカバリする方法について説明します。

スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする

スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには:

  1. 「スタンドアロン・ドメイン・ホストの破損後のリカバリ」のステップ1 - 4を実行します。
  2. 次のディレクトリの構成ファイルを更新します。
    (UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instance_name

    たとえば、httpd.conf, admin.confおよびmod_wl_ohs.conf (必要な場合)のIPアドレスとホスト名を更新します。

  3. 「スタンドアロン・ドメイン・ホストの破損後のリカバリ」のステップ6 - 8を実行します。
WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする

Oracle WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには:

  1. 「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、ドメインをリカバリします。

  2. ホストBにあったOracle HTTP Serverインスタンスの構成を変更します。

    1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTPServer」を展開します。

    2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。

    3. 「Oracle HTTP Server」メニューから「管理」、「ポート構成」の順に選択します。

    4. 表の各ポートでポートを選択し、「編集」をクリックします。「IPアドレス」を変更します。

      「任意」を選択した場合、変更を行う必要はありません。

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

  3. Oracle HTTP Serverの各インスタンスについて、mod_wl_ohsワイヤリングを更新します。

    1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTP Server」を展開します。

    2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。

    3. 「Oracle HTTP Server」メニューから「管理」、「mod_wl_ohs構成」の順に選択します。

    4. 「ロケーション」のセクションで、「自動入力」をクリックします。

      WebLogic Serverの有効なエンドポイント位置がすべて表示されます。

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

  4. 障害が発生したマシン上にはないOracle HTTP Serverインスタンスに移動し、「起動」をクリックして、そうしたインスタンスをすべて再起動します。

  5. ホストC上の各Oracle HTTP Serverインスタンスに移動し、「起動」をクリックして起動します。

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

別のホストにOracle Forms Servicesをリカバリするには:

  1. 「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
  2. 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
  3. 前のステップのファイルを新しいホストにコピーします。
  4. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ2のファイルのパスが含まれるようにします。
    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
別のホストへのOracle Reportsのリカバリ

別のホストにOracle Reportsをリカバリするには:

  1. 「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
  2. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

    • nodemanager.properties。このファイルの場所は次のとおりです。

      (UNIX) DOMAIN_HOME/nodemanager
(Windows) DOMAIN_HOME\nodemanager

    • reports_ohs.conf。このファイルの場所は次のとおりです。

      (UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs_name/moduleconf
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instances\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>要素を変更して、新しいホスト名を使用します。

    • mbeans.xml。このファイルの場所は次のとおりです。

      (Unix) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF
(Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF
別のホストへのOracle Data Integratorのリカバリ

Oracle Data Integratorをリカバリするには、障害に応じて、次のトピックの一方または両方の手順に従います。

Oracle Data Integratorリポジトリのリカバリ

Oracle Data Integratorリポジトリを別のホストにリストアする必要がある場合は、次の手順を実行します。

  1. 「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
  2. ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。『Oracle Data Integratorでの統合プロジェクトの開発』のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのプライマリ・リポジトリの新しい接続を作成します。
  3. 作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。
  4. Oracle WebLogic Server構成内のOracle Data Integrator JEEエージェント・リポジトリ構成の場合は、新しいデータベース・ホストの場所と一致するようデータ・ソースを編集します。
  5. 次のWLSTオフライン・コマンドを使用して、Oracle Data Integratorスタンドアロン・エージェント・リポジトリ構成を更新します。
    cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_DIRECTORY')
cd('/JdbcSystemResource/OdiMasterRepository/JdbcResource/OdiMasterRepository/JDBCDriverParams/NO_NAME_0');
set('URL','NEW_JDBC_URL_TO_RECOVERED_DB');
updateDomain();
exit();
別のホストへのOracle Data Integratorエージェントのリカバリ

別のホストにOracle Data Integratorエージェントをリカバリするには:

  1. 「管理対象サーバー・ホストの破損後のリカバリ」の説明に従って管理対象サーバーをリストアすることによって、Oracle Data Integrator JEEエージェントをリストアします。
  2. 「コンポーネント・ホストの破損後のリカバリ」の説明に従って、Oracle Data Integratorスタンドアロン・システム・コンポーネントをリストアします。
  3. ODI Studioを使用して、各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。
  4. 次のコマンドを使用して、Oracle Data Integratorスタンドアロン・エージェントのホストおよびポート構成を更新します。
    cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_HOME')
cd('ODI/ODI_STANDALONE_AGENT_NAME')
set("ServerListenAddress",'UPDATED_HOST_NAME');
set("ServerListenPort",'UPDATED_PORT');
updateDomain();
exit();
  5. スタンドアロン・エージェントおよびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。
別のホストへのOracle WebCenter Contentのリカバリ

別のホストにOracle WebCenter Contentをリカバリするには:

  1. データベースを別のホストにリストアする必要がある場合は、「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
  2. 「管理サーバー・ホストの破損後のリカバリ」の説明に従って、ドメインをリストアします。
  3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
    cd /net/home/vault
tar -xf vault_backup_042012.tar
  4. 次のファイルを編集します。
    DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg

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

    HttpServerAddress=hostname:port_number

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

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

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

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

親トピック: ホスト破損後のリカバリ

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

Fusion Middleware Controlを別のホストにリカバリするには、システムMBeanブラウザを使用してプロパティを更新します。

  1. Fusion Middleware Controlの「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
  2. 「システムMBeanブラウザ」ペインで「アプリケーション定義のMBean」、「emoms.props」、「サーバー: AdminServer」、「アプリケーション: em」、そして「プロパティ」と展開します。
  3. 「emoms.properties」をクリックします。
  4. 「属性」ペインで「操作」タブを選択し、「SetProperty」をクリックします。
  5. 次のプロパティの値を新しいホスト名に変更します。

    • oracle.sysman.emSDK.svlt.ConsoleServerHost

    • oracle.sysman.emSDK.svlt.ConsoleServerName

    たとえば、「キー」に「oracle.sysman.emSDK.svlt.ConsoleServerHost」と入力します。次に、値として「host.example.com:7001_Management_Service」と入力します。

  6. 「呼出し」をクリックします。
mod_wl_ohs.confファイルの変更

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

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/mod_wl_ohs.conf
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name\mod_wl_ohs.conf

WebLogic ServerドメインのOracle HTTP Serverでは、このディレクトリは管理サーバーのドメイン・ホームにあります。スタンドアロン・ドメインのOracle HTTP Serverでは、このディレクトリはOracle HTTP Serverのドメイン・ホームです。

そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(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>
特定のコンポーネントの新しいマシンの作成

管理サーバーにリスニング・アドレスがある場合は、管理サーバーを起動する前に新しいホスト名の新規マシンを作成する必要があります。

次のステップを実行します。

  1. 新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。
    readDomain('DOMAIN_HOME')
machine = create('newhostname', 'Machine')
cd('/Machine/newhostname')
nm = create('newhostname', 'NodeManager')
cd('/Machine/newhostname/NodeManager/newhostname')
set('ListenAddress', 'newhostname')
updateDomain()
  2. 管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。
    readDomain('DOMAIN_HOME')
cd ('/Machine/newhostname')
machine = cmo
cd ('/Server/AdminServer')
set('Machine', machine)
updateDomain()
  3. WLSTを使用して、管理サーバーのリスニング・ポートを設定します。
    readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.setListenPort(8001)
updateDomain()
  4. 必要に応じて、WLSTを使用して管理サーバーのアドレス・リスニングを更新します。
    readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.getListenAddress()
cmo.setListenAddress('newhostname')
updateDomain()
exit()
Oracleインベントリの更新

多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。

(UNIX) ORACLE_HOME/oui/bin/attachHome.sh
(Windows) ORACLE_HOME\oui\bin\attachHome.cmd
Windowsレジストリのリカバリ

Windows上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、Oracle Fusion Middlewareに関連するすべてのWindowsレジストリ・キーを新しいホストにインポートする必要があります。(レジストリ・キーは、「Windowsレジストリ・エントリのバックアップ」でエクスポートしたものです。)

次のレジストリ・キーをリカバリします。

HKEY_LOCAL_MACHINE\Software\Oracle

さらに、次のレジストリ・キー内のOracleで始まる各ノードをリカバリします。 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services

前にエクスポートしたキーをインポートするには、次のコマンドを使用します。

regedit  /I  FileName

たとえば:

regedit /I C:\oracleregistry.reg

レジストリ・エディタのヘルプに説明されているように、キーのインポートにはレジストリ・エディタを使用することもできます。

データベース・ホストの破損後のリカバリ

データベースのリカバリの詳細は、「データベースのリカバリ」を参照してください。

親トピック: ホスト破損後のリカバリ