ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Fusion Middlewareの管理
12c (12.1.3)
E56229-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

16 バックアップとリカバリの概要

この章では、Oracle Fusion Middlewareのバックアップおよびリカバリの概要(Oracle Fusion Middlewareコンポーネントに関するバックアップおよびリカバリの推奨事項を含む)について説明します。

内容は次のとおりです。

16.1 Oracle Fusion Middlewareのバックアップとリカバリの理解

An Oracle Fusion Middleware環境は、様々なコンポーネントおよび構成で成り立ちます。通常のOracle Fusion Middleware環境は、Oracle SOA SuiteなどのJavaコンポーネントが含まれるOracle WebLogic Serverドメイン、およびIdentity Managementコンポーネントが含まれるWebLogic Serverドメインで構成されます。

Oracle Fusion Middleware環境内のインストールでは、構成情報、アプリケーションおよびデータの同期が保たれ、相互に依存します。たとえば、構成を変更すると、構成ファイル内の情報が更新されます。アプリケーションをデプロイすると、ドメインまたはクラスタ内のすべての管理対象サーバーへのデプロイが必要な場合があります。

したがって、バックアップおよびリカバリを実行するときは、Oracle Fusion Middleware全体の環境を考慮することが重要になります。Oracle Fusion Middleware環境全体を一度に、その後定期的にバックアップしてください。そうすれば、ファイルやデータなどが失われた場合でも、環境を一貫性のある状態にリストアできます。

次の各項目では、バックアップとリカバリを理解するために重要な概念について説明します。


関連項目:

Oracle WebLogic Serverドメイン、管理サーバー、管理対象サーバーとクラスタ、およびノード・マネージャの概念の詳細は、『Oracle Fusion Middlewareコンセプトの理解』を参照してください。

16.1.1 管理サーバーで発生した障害の影響

管理サーバーで発生した障害が、ドメイン内の管理対象サーバーの操作に影響を与えることはありませんが、管理者がドメインの構成を変更できなくなります。管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが同様に影響を受けることがあります。

管理対象サーバー・インスタンス(クラスタ化されているものも、そうでないものも)が実行されている場合に、そのドメインの管理サーバーが使用できなくなっても、管理対象サーバーは継続して実行されます。周期的に、これらの管理対象サーバーは管理サーバーへの再接続を試みます。クラスタ化された管理対象サーバー・インスタンスでは、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバーの機能を引き続き使用できます。

管理対象サーバーを初めて起動する場合は、管理サーバーに接続して構成のコピーを取得する必要があります。これで、管理サーバーが実行されていない場合でも、管理対象サーバーを起動できます。この場合、管理対象サーバーでは、起動構成用にドメインの構成ファイルのローカル・コピーが使用され、周期的に管理サーバーとの接続が試行されます。管理サーバーに接続されると、管理対象サーバーの構成状態が管理サーバーの構成状態に同期されます。

16.1.2 管理対象サーバーの独立(MSI)モード

管理対象サーバーでは、ドメイン構成のローカル・コピーが保持されます。管理対象サーバーは、起動時に管理サーバーに接続し、管理対象サーバーが前回停止してからドメイン構成に変更が行われた場合は、その変更を取得します。管理対象サーバーが起動時に管理サーバーに接続できない場合は、ローカルにキャッシュされている構成情報を使用できます。これは、管理対象サーバーが前回停止した時点での構成です。管理サーバーに接続して構成の更新を確認できずに起動した管理対象サーバーは、管理対象サーバーの独立(MSI)モードで実行されます。デフォルトでは、MSIモードが有効になっています。ただし、初めて起動する場合は、管理サーバーが停止しているとキャッシュされた構成を使用できないため、管理対象サーバーはMSIモードでも起動できません。

16.1.3 管理対象サーバーでの構成の変更

構成の変更は、次の場合に管理対象サーバーで更新されます。

  • 管理対象サーバーが再起動するたびに、管理サーバーから最新の構成が取得されます。これは、その管理対象サーバーが実行されているノードのノード・マネージャが停止している場合でも行われます。管理対象サーバーの再起動時に管理サーバーが使用できない場合、およびMSI(管理対象サーバーの独立)モードが管理対象サーバーで有効になっている場合は、管理対象サーバーは構成のローカル・コピーを読み取って起動し、管理サーバーが使用可能になったときに管理サーバーと同期します。デフォルトでは、MSIモードが有効になっています。

  • 構成の変更、アプリケーションのデプロイまたは再デプロイ、トポロジの変更など、管理上の変更がアクティブ化されるたびに、管理サーバーから管理対象サーバーに最新の構成がプッシュされます。管理対象サーバーが実行されていない場合は、管理対象サーバーが起動したときに、管理サーバーから管理対象サーバーに最新バージョンの構成がプッシュされます。

16.2 Oracle Fusion Middlewareのディレクトリ構造

次に、Oracle Fusion Middleware Infrastructureをインストールした場合のOracle Fusion Middlewareのディレクトリ構造の簡易ビューを示します。

ascon_dt_011.pngの説明が続きます
図ascon_dt_011.pngの説明

16.3 バックアップおよびリカバリで使用するツール

Oracle Fusion Middleware環境のバックアップまたはリカバリに使用できるものは、次のとおりです。

構成ファイルのバックアップ・コピーを作成するようにOracle WebLogic Serverを構成することもできます。これによって、構成の変更を元に戻す必要がある場合や、ほとんど可能性はなくとも構成ファイルが破損した場合のリカバリが簡単になります。管理サーバーの起動時に、構成ファイルを格納したconfig-booted.jarという名前の.jarファイルが保存されます。構成ファイルを変更した場合、変更前のファイルは、ドメイン・ディレクトリの下のconfigArchiveディレクトリに、config-1.jarなどの続き番号が付けられた.jarファイルとして保存されます。ただし、構成アーカイブは常に、管理サーバー・ホストのローカルとして保存されます。アーカイブは外部の場所にバックアップすることをお薦めします。

16.4 Oracle Fusion Middlewareコンポーネントのバックアップおよびリカバリに関する推奨事項

表16-1では、各Oracle Fusion Middlewareコンポーネントにおいて、バックアップおよびリカバリする必要がある項目について説明します。次の点に注意してください。

表16-1では、Oracle Fusion Middlewareコンポーネントでのバックアップとリカバリの推奨事項について説明します。

表16-1 バックアップとリカバリの推奨事項

コンポーネント データベースへの依存性 バックアップに関する推奨事項 リカバリに関する推奨事項 追加情報

Oracle WebLogic Server

デフォルトでは、いずれのデータベース・リポジトリにも依存しません。ただし、Oracle WebLogic Serverにデプロイされたアプリケーションでは、データ・ソースとしてデータベースが使用される場合があります。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

サーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。

Oracle WebLogic Server JMS

JMSがデータベース・ベースの場合のみ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

第16.4.1項を参照してください。

Oracle Web Services Manager

データベース・ベースのMDSリポジトリを使用する場合は、MDSスキーマ。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。

Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、ファイル・コピー・メカニズムを使用してバックアップします。

管理対象サーバー

Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、バックアップからリストアします。

NA

Oracle Platform Security Services

データベース・ベースのOracle Platform Securityリポジトリを使用する場合は、OPSSスキーマ。Oracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryリポジトリ。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。

Oracle Platform SecurityでOracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryをバックアップします。

第18.2.6.1項にリストされているファイル。

Oracle User Messaging Service

UMSスキーマ

Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。

ドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)

第18.3.5.5.1項または第18.3.5.5.2項の説明に従って、構成変更を実行します。

Oracle HTTP Server

なし

Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。

管理サーバー・ドメイン・ディレクトリ

NA

Oracle SOA Suite

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

ホスト破損の詳細は、第18.3.5.4項を参照してください。

データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。

Oracle B2B

MDSスキーマ

Oracle B2B構成ファイルに変更が行われた場合は、管理サーバー・ドメイン・ディレクトリ、Oracleホームおよび製品ホーム

管理対象サーバー

Xengine.tar.gzファイルの詳細は、第18.2.6.2項を参照してください。

Oracle BPEL Process Manager

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。

Oracle Business Activity Monitoring

MDSスキーマおよびSOAINFRAスキーマ

Oracleホーム、管理サーバー・ドメイン・ディレクトリ、管理対象サーバー・ディレクトリ。

障害の程度に応じて、管理対象サーバーとOracleホームのいずれかまたは両方

NA

Oracle Business Process Management

MDSスキーマ

管理サーバー・ドメイン・ディレクトリおよびOracle BPEL Process Managerと同じデータ(第16.4.2項を参照)。

Oracle BPEL Process Managerと同じデータおよび管理対象サーバー

NA

Oracle Business Rules

MDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

soa-infraアプリケーションがデプロイされている管理対象サーバー

NA

Oracle Managed File Transfer

MFTスキーマおよびMDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

Oracle Service Bus

レポート機能が有効な場合、Oracle Service Busは、ユーザー指定のスキーマにWLI_QS_REPORT_DATAおよびWLI_QS_REPORT_ATTRIBUTEという2つの表を作成します。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理対象サーバー

Oracle Mediator

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

soa-infraアプリケーションがデプロイされている管理対象サーバー

Oracle Enterprise Scheduler

ESSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

NA

Oracle Event Processing

MDSスキーマ(.cqlxファイルを1つのMARにパッケージ化して格納)

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理対象サーバー

NA

Oracle Data Integrator

ODI_REPOスキーマ

Oracleホーム、Oracle Data Integratorがドメインにインストールされている場合はドメイン、およびスタンドアロン・エージェントがインストールされている各マシンのODI_Oracle_Home/oracledi/agentフォルダ

管理対象サーバーとOracleホームのいずれかまたは両方。

環境にOracle Data Integratorスタンドアロン・エージェントまたは開発者向けOracle Data Integratorが含まれている場合は、第18.2.1項の説明に従ってOracleホームをリストアします。

環境に管理対象サーバーにデプロイされたOracle Data Integratorが含まれている場合は、第18.2.5項の説明に従って管理対象サーバーをリストアします。

ホストの破損からリカバリするには、第18.3.5.6項を参照してください。

Oracle Data Service Integrator

MDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理サーバー・ドメイン

NA

16.4.1 Oracle WebLogic Server JMSのバックアップとリカバリの推奨事項

ファイル・ベースのJMSを使用している場合は、ストレージのスナップショット技術を使用して一貫性のあるオンライン・バックアップを取ります。または、ファイル・システムのコピーを使用してオフライン・バックアップを実行することもできます。

JMS永続ストアがファイルベースの場合は、バックアップからリカバリします。JMS永続ストアがデータベース・ベースの場合は、必要に応じて、データベースを直近の時点にリカバリします。次の点に注意してください。

  • JMSデータは常に、できるだけ最新に保つようにします。これを実現するには、データベース・ベースの永続性を確保する場合はOracle Databaseのポイント・イン・タイム・リカバリ機能を使用して直近の時間にリカバリするか、またはSAN/NASなど可用性の高いRAID対応ストレージ・デバイスを使用します。

  • ファイル・ベースのJMSを使用している場合は、ストレージのスナップショットを使用してリカバリできます。

  • どのような理由であれ、JMSデータを前の時点にリストアする必要がある場合、リストアによって影響が及ぶ可能性があります。システムの状態を前の時点にリストアすると、メッセージを複製する可能性だけでなく、メッセージを失う可能性もあります。この場合に失われたメッセージは、システムのリストア時点の前または後にエンキューされていた未処理のメッセージです。

    重複メッセージを処理しないようにするには、リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージを排出する必要があります。


    注意:

    メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージの他に、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。

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

    2. 新しいメッセージが生成されたり宛先に挿入されたりしないように、また失効したメッセージを排出する前に宛先から消費されないようにするため、リカバリの前に、起動時の生成、挿入、消費の各操作を休止するようにJMSサーバーを構成します。これを行うには:

      1. 「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」をクリックします。

      2. 「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。

      3. 「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。

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

    リカバリ後に実行する手順は次のとおりです。

    1. 永続ストアのリカバリ後に、管理対象サーバーを起動します。

    2. 次の手順を実行して、失効したメッセージをJMS宛先から排出します。

      1. 「サービス」を開いてから「メッセージング」を開き、「JMSモジュール」を開きます。

      2. JMSモジュールを選択して、ターゲットを選択します。

      3. 「モニタリング」を選択して、「メッセージの表示」を選択します。

    3. 「すべて削除」をクリックします。

    4. 次の手順を実行して、操作を再開します。

      1. 「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」を開きます。

      2. 「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。

      3. 「構成: 全般」ページで「詳細」をクリックします。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択解除します。

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

    永続ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールでは、操作のインポート、エクスポート、移動および削除を、管理コンソール、MBeanおよびWLSTから実行できます。

    キューイングの他に、パブリッシュおよびサブスクライブも使用するアプリケーションの場合は、キューに加えてトピック・サブスクリプションを操作する必要があります。

16.4.2 Oracle BPEL Process Managerのバックアップおよびリカバリに関する推奨事項

グローバル・フォルト・ポリシー、ワークフローのコールバック・クラス、スーツケースの外部にある可能性のあるリソース・バンドルに対する変更など、構成に変更があった場合はその変更後にデータベースをバックアップします。また、データベースは、新しいコンポジットのデプロイまたはコンポジットの再デプロイの後にもバックアップします。

必要に応じて、データベースを直近の時点にリカバリします。ポイント・イン・タイム・リカバリを使用すると、最新のプロセス定義および進行中のインスタンスがリストアされます。ただし、これによってプロセスの手順が再実行される場合があります。できるかぎり、Oracle BPEL Process Managerの冪等プロセスを使用することをお薦めします。冪等以外のプロセスがシステムに含まれている場合は、それらをデハイドレーション・ストアからクリーンアップしてからOracle Fusion Middlewareを起動する必要があります。詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。

インスタンスでは、プロセス定義とアーティファクトがすべてデータベースから取得されるため、データベースを最新の状態にリカバリした後で構成をリカバリする必要はありません。インスタンスは、引き続き正常に機能します。

再デプロイしたコンポジットの場合、データベースのリカバリによって、デハイドレーションされた進行中のプロセスとそれに対応する定義との整合性が確保されます。これは、デハイドレーションされたインスタンスも格納されているデータベース・リポジトリにプロセス定義が格納されているためです。

16.5 前提と制限

次の前提と制限は、このマニュアルに記載されているバックアップおよびリカバリ手順に適用されます。第17.2項に一覧表示されている制限も参照してください。


関連項目:

Cold Failover ClusterまたはDisaster Recoveryを使用している場合、詳細は、Disaster Recoveryガイドを参照してください。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次