4 障害時リカバリ・サイトの設定と管理
Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて確認し、本番サイトおよびスタンバイ・サイトを設定する方法について学習します。
ノート:
スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。『Oracle Site Guard管理者ガイド』を参照してください。
この章の内容は次のとおりです。
- サイトの設定
Oracle障害時リカバリ・サイトの設定方法を確認します。 - 本番サイトの作成
Oracle SOAエンタープライズ・デプロイメント・トポロジで本番サイトを作成する方法を確認します。 - スタンバイ・サイトの作成
スタンバイ・サイトを作成する方法を確認します。 - 非対称スタンバイ・サイトの作成
非対称Oracle Fusion Middleware障害時リカバリ・トポロジを作成する方法を確認します。 - サイトの操作および管理の実行
Oracle Fusion Middleware障害時リカバリ・トポロジを操作および管理する方法を確認します。 - 障害時リカバリのためのOracle Site Guardの使用
Oracle Site Guardは、2つの障害時リカバリ・サイト間でスイッチオーバーとフェイルオーバーを編成します。 - Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用
Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。
4.1 サイトの設定
Oracle障害時リカバリ・サイトを設定する方法を学習します。
本番サイトの作成を開始する前に、次の点を確認します。
-
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
-
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します。
-
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
- ディレクトリ構造とボリュームの設計
障害時リカバリ・トポロジで推奨されるディレクトリ構造について確認します。 - ストレージ・レプリケーションの設定
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定する方法を確認します。 - データベースのインストールおよび構成
Oracle SOA Suiteエンタープライズ・デプロイメントでOracle Database 11.2またはOracle Database 12.1 MAAデータベースをインストールおよび構成する方法を確認します。
親トピック: 障害時リカバリ・サイトの設定と管理
4.1.1 ディレクトリ構造とボリュームの設計
障害時リカバリ・トポロジで推奨されるディレクトリ構造について学習します。
このドキュメントで推奨されるディレクトリ・レイアウトと異なるものを選択できますが、採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。
次の一覧では、ディレクトリとディレクトリ環境変数について説明します。
-
ORACLE_BASE
: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。 -
ORACLE_HOME
: この関連ディレクトリ・パスは、Oracle Fusion Middlewareが存在する場所を指します。 -
WL_HOME
: この環境変数と関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。 -
PROD_DIR
: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。 -
DOMAIN
ディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。各種のWebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。 -
ORACLE_INSTANCE
: Oracleインスタンスには、1つ以上のシステム・コンポーネントが含まれます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
「Oracle SOA Suiteに推奨されるディレクトリ構造」を参照してください。
この項には次のトピックが含まれます:
- Oracle SOA Suiteに推奨されるディレクトリ構造
Oracle SOA Suiteに推奨されるディレクトリ構造について確認します。 - Oracle SOA Suiteに推奨されるボリューム設計
Oracle SOA Suiteに推奨されるボリューム設計について確認します。
親トピック: サイトの設定
4.1.1.1 Oracle SOA Suiteに推奨されるディレクトリ構造
Oracle SOA Suiteに推奨されるディレクトリ構造について学習します。
Oracle Fusion Middlewareでは、単一のバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのOracleホーム(それぞれに、各製品スイートのWL_HOME
とORACLE_HOME
がある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。複数のボリュームによって実現する保護はこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
ボリューム設計の詳細は、次の項を参照してください。
親トピック: ディレクトリ構造とボリュームの設計
4.1.1.2 Oracle SOA Suiteに推奨されるボリューム設計
Oracle SOA Suiteに推奨されるボリューム設計について学習します。
図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
図4-2 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム
「図4-2 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム」の説明
図4-3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム
「図4-3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム」の説明
このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
-
製品の冗長バイナリ・ファイルを格納する2つのOracleホーム用にボリュームを2つプロビジョニングします(表4-1の
VOLFMW1
およびVOLFMW2
)。 -
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-1の
VOLADMIN
)。 -
管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-1の
VOLSOA1
およびVOLSOA2
)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。 -
JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-1の
VOLDATA
)。ドメイン全体で1つのボリュームが、ドメインのすべてのノードでマウントされます。 -
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-1の
VOLWEB1
およびVOLWEB2
)。 -
Oracle HTTP Serverのドメイン・ホーム用に各ノードでボリュームを1つプロビジョニングします(表4-1の
VOLOHS1
およびVOLOHS2
)。ノート:
Web層のホストには、通常、ローカル・ストレージが推奨されます。この構成を定期的に他のアプリケーション層のボリュームにレプリケートして、スタンバイに同期したり、本番WebホストからスタンバイWebホストに直接同期することができます。
表4-1に、図4-2および図4-3に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-1 Oracle SOA Suiteのボリューム設計に関する推奨事項
層 | ボリューム名 | マウントされるホスト | マウント・ポイント | 備考 |
---|---|---|---|---|
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリおよびその他の共有構成(デプロイメント・プラン、アプリケーション、キーストアなど)のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム |
コンシステンシー・グループに関する推奨事項は、次を参照してください。
- Oracle SOA Suiteに推奨されるコンシステンシー・グループ
Oracle SOA Suiteに推奨されるコンシステンシー・グループについて確認します。
親トピック: ディレクトリ構造とボリュームの設計
4.1.1.2.1 Oracle SOA Suiteに推奨されるコンシステンシー・グループ
Oracle SOA Suiteに推奨されるコンシステンシー・グループについて学習します。
Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。
-
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2の
DOMAINGROUP
)。 -
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2の
RUNTIMEGROUP
)。 -
Oracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2の
FMWHOMEGROUP
)。
表4-2に、図4-2に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-2 Oracle SOA Suiteのコンシステンシー・グループ
層 | グループ名 | メンバー | 備考 |
---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracleホーム用のコンシステンシー・グループ |
4.1.2 ストレージ・レプリケーションの設定
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定する方法を学習します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次のようにします。
-
スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。
-
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
-
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します。
ノート:
-
シンボリック・リンクを本番サイトに設定した場合、シンボリック・リンクはスタンバイ・サイトにのみ設定する必要があります。
-
シンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
-
-
本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
-
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
-
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
-
Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。
-
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
-
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
親トピック: サイトの設定
4.1.3 データベースのインストールおよび構成
Oracle SOA Suiteエンタープライズ・デプロイメントでOracle Database 11.2またはOracle Database 12.1 MAAデータベースをインストールおよび構成する方法を学習します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用されるOracle Databaseの設定に関する推奨事項と考慮事項は、「データベースに関する考慮事項」を参照してください。
4.1.3.1 Oracle Database 11.2または12.1 MAA環境のインストールおよび構成
Oracle Maximum Availability Architecture (MAA)は、計画停止の停止時間を短縮し、計画外停止を防止、検出およびリカバリするOracleの包括的なアーキテクチャです。
Real Application Clusters (RAC)およびData Guardは、プライマリ・サイトにRACデータベースが含まれ、セカンダリ・サイトにRAC物理スタンバイ・データベースが含まれるデータベースMAAソリューションの基礎を提供します。
この項では、次の項目について説明します。
ヒント:
また、この項のタスクの多くはOracle Enterprise Manager Cloud Control (Cloud Control)を使用して実行することもできます。
Cloud Controlを使用したデータベースの設定および管理は、ダウンタイムの制御および障害時リカバリ操作の簡略化に役立ちます。
Enterprise Manager Cloud Control 12cのインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
Cloud Controlを使用したOracle Data Guardの設定の詳細は、Oracle Enterprise Manager Cloud Control 12cによるOracle Data Guardの設定および管理を参照してください。
親トピック: データベースのインストールおよび構成
4.1.3.1.1 前提条件
次の前提条件が満たされていることを確認してください。
-
スタンバイ・サイトのOracle RACクラスタおよび自動ストレージ管理(ASM)インスタンスが作成済です。
-
スタンバイ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。
-
Oracle RACデータベースが
archivelog
モードで実行されています。 -
スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
-
共有
ORACLE_HOME
構成では、TNS_ADMIN
ディレクトリはローカルの非共有ディレクトリである必要があります。
4.1.3.1.2 Oracle Data Guard環境の説明
この項で示す例には、表4-3で説明する環境変数が含まれています。
表4-3 プライマリおよびスタンバイ・データベースで使用される変数
変数 | プライマリ・データベース | スタンバイ・データベース |
---|---|---|
データベース名 |
|
|
SOAデータベースのホスト名 |
|
|
データベースの一意の名前 |
|
|
インスタンス名 |
|
|
サービス名 |
|
|
4.1.3.1.3 プライマリ・データベースの複製の手順
次のステップに従って、Oracle Data Guardの設定用のプライマリ・データベースを準備します。
ノート:
Oracle Data Guardの設定の前提条件の詳細は、『Oracle Data Guard Broker』の前提条件に関する項を参照してください。
-
プライマリ・データベースで強制ロギングを使用可能にします。
SQL> alter database force logging; SQL> select name, log_mode, force_logging from v$database; NAME LOG_MODE FOR ---------- ---------------- ------- PSOA ARCHIVELOG YES
-
オンラインREDOログと同じサイズのスタンバイREDOログをプライマリ・データベースに作成します。Duplicateコマンドは、スタンバイ・データベースでスタンバイREDOログを自動的に作成します。
**INTERNAL XREF ERROR**に示すように、同じ数に1つ加えた追加のREDOログを各スレッドで使用することをお薦めします。
-
スタンバイ・ノード1で、例4-1に示すように、スタンバイ・データベースの静的
SID
エントリを提供し、プライマリ(soa1
)と同じORACLE_SID
の値を持つリスナー(たとえば、LISTENER_DUPLICATE
)を作成し、起動します。listener.ora
ファイルへの次のパスを提供します。GRID_HOME
/network/admin/listener.ora
-
次のコマンドを実行して、
GRID_HOME/bin
::からlsnrctl
を使用し、リスナーを起動および検証します。lsnrctl start listener_duplicate lsnrctl status listener_duplicate
-
スタンバイ・ノード2で、例4-2に示すように、スタンバイ・データベースの静的
SID
エントリを提供し、プライマリ(soa2
)と同じORACLE_SID
の値を持つリスナー(たとえば、LISTENER_DUPLICATE
)を作成し、起動します。listener.ora
ファイルへの次のパスを提供します。GRID_HOME
/network/admin/listener.ora
ノート:
リスナーはクラスタ・レベルで構成され、すべてのノードがリスナーのポートおよび環境設定を継承します。したがって、
TNS_ADMIN
ディレクトリ・パスはすべてのノードで同じ値を持ちます。共有
ORACLE_HOME
構成では、TNS_ADMIN
ディレクトリはローカルの非共有ディレクトリである必要があります。これらのネットワーク・ファイルはIFILES
として含まれます。次のステップを実行して、それぞれインスタンス
SOA1
およびSOA2
を持つSOADC1.DBHOST1
およびSOADC1.DBHOST2
の2ノード・クラスタに共有ORACLE_HOME
のTNS_ADMIN
を設定します。-
各ノードにローカル・ネットワーク・ディレクトリを作成します。たとえば、
/
local_network_dir
/network_admin
などです。 -
各ノードの場所
/
local_network_dir
/network_admin
にローカルlistener.ora
ファイルを作成します。 -
ローカル
listener.ora
ファイルに、LISTENER_duplicate
パラメータの値を追加します。 -
共通
listener.ora
ファイルのGRID_HOME
/network/admin
に、IFILE
パラメータ値を次のように追加します。IFILE=/local_network_dir/network_admin/listener.ora
-
-
次のコマンドを実行して、リスナーを起動および検証します。
lsnrctl start listener_duplicate lsnrctl status listener_duplicate
-
プライマリ・ノードのデータベース・ホームに、ステップ3で作成したリスナーに接続するためのOracle Net別名を作成します。例4-3を参照してください。
たとえば、
GRID_HOME/bin/tnsping dup
です。 -
REDOトランスポート用のOracleパスワード・ファイル認証を構成します。次の要件を満たすことを確認します。
-
remote_login_passwordfile
をEXCLUSIVE
に設定します。SQL> show parameter remote_login_passwordfile NAME TYPE VALUE --------------------------------- -------------- -------------------------------- remote_login_passwordfile string EXCLUSIVE
-
プライマリ・パスワード・ファイルを補助インスタス用の場所にコピーします。
-
-
スタンバイ・ホストの
ORACLE_HOME/dbs
ディレクトリで、次のパラメータを使用してpfile、initsoa1.ora
を作成します。db_name=soa db_unique_name=ssoa sga_target=5g
-
すべてのスタンバイ・ホストに
soa
データベースの監査ディレクトリを作成します。mkdir -p /u01/app/oracle/admin/soa/adump
-
スタンバイ・ホスト上の
ssoa
データベースにアクセスするために、Oracle Net別名をすべてのプライマリ・ホストに作成します。すべてのホストに
psoa
およびssoa
用のOracle Net別名があることを確認します。作成するすべての別名は、VIPノードではなくスキャン・リスナーを参照する必要があります。また、local_listener
変数がプライマリ・ホストの別名に設定されている場合は、スタンバイ・サイトに、プライマリ・ホスト上のローカル・リスナーを指す変数の詳細を入力します。例4-4と例4-5を参照してください。ノート:
-
プライマリ・ノード2 (
SOADC1.DBHOST2
)では、次のように、プライマリ・ノード2のVIP
を指すようにpsoa_local_listener
のHOST
値を更新します。psoa_local_listener = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=prmy2-vip)(PORT = 1521)) ) )
-
共有Oracleホームを使用している場合は、2つのノードの
VIP
をlocal_listenerパラメータに追加します。たとえば:
psoa_local_listener = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=prmy1-vip)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP) (HOST=prmy2-vip)(PORT = 1521)) ) )
-
スタンバイ・ノード2 (
SOADC2.DBHOST2
)では、次のように、スタンバイ・ノード2のVIP
を指すようにssoa_local_listener
のHOST
値を更新します。ssoa_local_listener = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=stby2-vip)(PORT = 1521)) ) )
-
共有Oracleホームを使用している場合は、2つのノードのVIPを
local_listener
パラメータに追加します。たとえば:
ssoa_local_listener = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=stby1-vip)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP) (HOST=stby2-vip)(PORT = 1521)) ) )
-
-
スタンバイ・ホストで、
ORACLE_SID
をプライマリ・データベースと同じ値(ORACLE_SID=soa1
)に設定し、ステップ9で作成したスタンバイPFILE
,を使用してスタンバイ・データベースでstartup nomount
コマンドを実行します。 -
値を取得するには、次の問合せを使用します。
SQL> select p.inst_id,instance_name, name,value from gv$parameter p, gv$instance i where p.inst_id=i.inst_id and p.name='cluster_interconnects';
INST_ID INSTANCE_NAME NAME VALUE 1 dbm1 cluster_interconnects 192.168.44.225 2 dbm2 cluster_interconnects 192.168.44.226 -
プライマリ・ホストでパラメータ
cluster_interconnects
が設定されている場合は、これを無効にします。SQL> alter system reset cluster_interconnects scope=spfile sid='soa1'; SQL> alter system reset cluster_interconnects scope=spfile sid='soa2';
-
プライマリ・ホストで、Recovery Manager (RMAN)スクリプトを実行して、コマンド
duplicate target database for standby from active database
を使用してプライマリ・データベースを複製します。ノート:
このコマンドは、環境によって異なります。コマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベースの複製に関する項を参照してください。
例4-6を参照して、異なるディスクグループ名を持つ2つのシステム間でのデータの複製方法を理解します。
例4-7を参照して、同じディスクグループ名
+DATA
を持つ2つのシステム間でのデータの複製方法を理解します。 -
ステップ14で説明するように、プライマリ・ホストでパラメータ
cluster_interconnects
を無効にした場合は、spfile
で元の値に戻す必要があります。 -
(オプション) ステップ3で作成したリスナーを停止し、削除します。
例4-1 静的SIDを持つリスナーを作成および起動するスクリプト
LISTENER_duplicate = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost1) (PORT = 1521)(IP = FIRST)))) SID_LIST_LISTENER_duplicate = (SID_LIST = (SID_DESC = (SID_NAME = soa1) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))
例4-2 静的SIDを持つリスナーを作成および起動するスクリプト
LISTENER_duplicate = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost2) (PORT = 1521)(IP = FIRST)))) SID_LIST_LISTENER_duplicate = (SID_LIST = (SID_DESC = (SID_NAME = soa2) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))
例4-3 Oracle Net別名を作成するスクリプト
dup = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost1) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = soa1)))
例4-4 プライマリ・ノード1 (SOADC1.DBHOST1)のサンプルtnsnames.oraファイル
psoa = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL= TCP) (HOST=prmy-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = psoa) ) ) ssoa = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=stby-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ssoa) ) ) psoa_local_listener = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=prmy1-vip)(PORT = 1521)) ) )
例4-5 スタンバイ・ノード1 (SOADC2.DBHOST1)のサンプルtnsnames.oraファイル
psoa = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL= TCP)(HOST=prmy-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = psoa) ) ) ssoa = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=stby-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ssoa) ) ) ssoa_local_listener = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP) (HOST=stby1-vip)(PORT = 1521)) ) )
例4-6 異なるディスクグループ名を持つ2つのシステム間でのデータの複製
rman <<EOF connect target sys/password; connect auxiliary sys/password@dup; run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile parameter_value_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby' set db_file_name_convert '+DATA_prmy','+DATA_stby' set db_unique_name='ssoa' set db_create_online_log_dest_1='+DATA_stby' set db_create_file_dest='+DATA_stby' set db_recovery_file_dest='+RECO_stby' set log_file_name_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby' set control_files='+DATA_stby/ssoa/standby.ctl' set local_listener='ssoa_local_listener' set remote_listener='stby-scan:1521'; } EOF
例4-7 同じディスクグループ名+DATAを持つ2つのシステム間でのデータの複製
rman <<EOF connect target sys/password; connect auxiliary sys/password@dup; run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile set db_unique_name='ssoa' set control_files='+DATA/ssoa/standby.ctl' set local_listener='ssoa_local_listener' set remote_listener='stby-scan:1521'; } EOF
例4-8 サンプルREDOログ
SQL> alter database add standby logfile thread 1 group 9 size 500M, group 10 size 500M, group 11 size 500M; SQL> alter database add standby logfile thread 2 group 12 size 500M, group 13 size 500M, group 14 size 500M;
4.1.3.1.4 スタンバイ・データベースのRAC構成の完了の手順
スタンバイ・データベースでRAC構成を完了するには、「プライマリ・データベースの複製のステップ」のステップを実行します。さらに、次のステップを実行します。
-
スタンバイ・データベースで一時パラメータ・ファイルを作成します。
SQL> create pfile='/tmp/p.ora' from spfile;
-
スタンバイ・データベースの
+DATA_stby
にSPFILE
を作成します。SQL> create spfile='+DATA_stby/ssoa/spfilessoa.ora' from pfile='/tmp/p.ora';
-
デフォルト・ファイルを削除します。
$rm /u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/spfilesoa1.ora
-
すべてのスタンバイ・ホストに
initsoa
n
.ora
ファイルを作成します。ファイルは、ステップ2で作成したSPFILE
の場所を指す必要があります。soadc2.dbhost1
ファイルで、次を追加します。cat /u01/app/oracle/product/11.2.0/dbs/initsoa1.ora spfile='+DATA/ssoa/spfilesoa.ora
-
スタンバイ・システムで、マウント状態のインスタンスを再起動します。
startup mount
-
次のようにRACデータベースをCRSに登録します。
srvctl add database -d ssoa –o /u01/app/oracle/product/11.2.0/db_1 srvctl add instance -d ssoa -i soa1 -n soadc2.dbhost1 srvctl add instance -d ssoa -i soa2 -n soadc2.dbhost2 srvctl modify database –d ssoa –r physical_standby
4.1.3.1.5 Data Guard Broker構成の作成
この項では、Data Guard構成の作成の基本的なステップについて説明します。
Data Guard Brokerの詳細は、Oracle Data Guardのインストールに関する項の手順を参照してください。
Data Guard Broker構成を作成するには、次のステップを実行します。
例4-9 dgmgrlへのアクセスによるプライマリ・ホストのData Guard Broker構成の作成
dgmgrl sys/password
DGMGRL> create configuration 'dg_config' as
primary database is 'psoa'
connect identifier is psoa;
Configuration "dg_config" created with primary database "psoa"
DGMGRL> add database 'ssoa' as
connect identifier is ssoa;
Database "ssoa" added
DGMGRL> enable configuration;
Enabled.
- Data Guard Broker構成の検証
- データベースのスイッチオーバーおよびスイッチバックのテスト
データベースのスイッチオーバーおよびスイッチバックを実行できます。
4.1.3.1.5.1 Data Guard Broker構成の検証
次のステップを実行して、Data Guard Broker構成が正常に作成されたことを確認します。
例4-10 Data Guard Broker構成の検証
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: psoa- Primary database ssoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
親トピック: Data Guard Broker構成の作成
4.1.3.1.5.2 データベースのスイッチオーバーおよびスイッチバックのテスト
データベースのスイッチオーバーおよびスイッチバックを実行できます。
Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行
Oracle Data Guard Brokerを使用してスイッチオーバー操作を実行するには、次のタスクを完了します。
-
「Data Guard Broker構成の作成」の手順を使用して作成したOracle Data Guard Broker構成を検証します。
構成を検証するには、次のコマンドを実行します。
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: psoa- Primary database ssoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
-
SWITCHOVER
コマンドを実行して、プライマリ・データベースとスタンバイ・データベースのロールを入れ替えます。**INTERNAL XREF ERROR**では、Data Guard Brokerが、古いプライマリ・データベースの停止および再起動を、スイッチオーバー操作の一部として自動的に実行する方法を示します。DGMGRL> switchover to 'ssoa'; Performing switchover NOW, please wait... New primary database "ssoa" is opening... Operation requires shutdown of instance "psoa1" on database "psoa" Shutting down instance "psoa1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "psoa1" on database "psoa" Starting instance "psoa1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "ssoa"
-
スイッチオーバーの完了後、
SHOW CONFIGURATION
コマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: ssoa- Primary database psoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
SQL Plusを使用したスイッチオーバー操作の実行
次の操作を実行して、新しく作成したフィジカル・スタンバイ・データベースとプライマリOracle RACデータベース間でデータベースを正しくスイッチオーバーまたはスイッチバックします。
ノート:
Oracle Data Guard Brokerのスイッチオーバーおよびフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』のスイッチオーバーおよびフェイルオーバー操作に関する項を参照してください。
親トピック: Data Guard Broker構成の作成
4.2 本番サイトの作成
Oracle SOAエンタープライズ・デプロイメント・トポロジで本番サイトを作成する方法を学習します。
本番サイトを作成する前に:
-
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
-
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します。
-
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
- 本番サイトの作成
トポロジの本番サイトを作成します。 - Oracle Fusion Middlewareアクティブ-パッシブ・デプロイメントのデータ・ソースの構成
Oracle Fusion Middlewareが使用するデータ・ソースを構成し、プライマリ・データベースのフェイルオーバーまたはスイッチオーバーの場合に接続のフェイルオーバーを自動化します。
親トピック: 障害時リカバリ・サイトの設定と管理
4.2.1 本番サイトの作成
トポロジの本番サイトを作成します。
ノート:
この項では、Oracle SOA Suiteトポロジの本番サイトの作成方法について説明します。異なるトポロジの本番サイトを作成する場合は、Install a Production Environment: Plan, Install & Configure an Enterprise Deploymentカテゴリに記載されている適切なOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドを参照してください。『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、本番サイトをインストールおよび構成します。
次の項で、本番サイトのインストールおよび構成を実行する方法について説明します。
- ボリュームおよびコンシステンシー・グループの作成
共有ストレージ・デバイスでボリュームおよびコンシステンシー・グループを作成します。 - 物理ホスト名およびホスト名別名の設定
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。 - Oracle SOA Suiteのインストールおよび構成
Oracle SOA Suiteをインストールおよび構成します。
親トピック: 本番サイトの作成
4.2.1.1 ボリュームおよびコンシステンシー・グループの作成
共有ストレージ・デバイスでボリュームおよびコンシステンシー・グループを作成します。
共有ストレージ・デバイスにボリュームおよびコンシステンシー・グループを作成するには、 「Oracle SOA Suiteに推奨されるボリューム設計」を参照してください。
親トピック: 本番サイトの作成
4.2.1.2 物理ホスト名およびホスト名別名の設定
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。
本番サイトおよびスタンバイ・サイトのホスト名の計画の詳細は、「ホスト名の計画」を参照してください。
親トピック: 本番サイトの作成
4.2.1.3 Oracle SOA Suiteのインストールおよび構成
Oracle SOA Suiteをインストールおよび構成します。
Oracle SOA Suiteをインストールおよび構成するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照し、次の変更を適用してください。
- 共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。
- 物理および仮想ホスト名の別名を使用して、本番およびスタンバイ・サイトを設定します。
- JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。
- 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーおよび管理対象サーバーのホスト名検証をオフにする詳細な手順は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
- ホスト名の検証をオフにしない場合、「スタンバイ・サイトの自己署名証明書およびキーの更新」のステップに従って、ノード・マネージャの通信を構成します。
- ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
親トピック: 本番サイトの作成
4.2.2 Oracle Fusion Middlewareアクティブ-パッシブ・デプロイメントのデータ・ソースの構成
Oracle Fusion Middlewareが使用するデータ・ソースを構成し、プライマリ・データベースのフェイルオーバーまたはスイッチオーバーの場合に接続のフェイルオーバーを自動化します。
ドメインで使用されているすべてのデータ・ソース(JDBC永続性ストア、リース・データ・ソースおよびカスタムデータ・ソースを含む)を構成します。GridLink
データ・ソースは、スタンバイ・データベースに関する情報を含むように変更する必要があります。
-
ONS構成を更新して、本番およびスタンバイ両方のサイトONSを含めます。
次の例に示すように、ONSアドレス・リストの項目はカンマで区切る必要があります。
prmy-scan:6200,stby-scan:6200
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。次の例は、成功した場合の接続通知を示しています。
Connect test for prmy-scan:6200 succeeded.
-
JDBC URLを更新して、両方のサイトに適切なサービスを含めます。
データベースがData Guardを使用するOracle Fusion Middleware SOAアクティブまたはパッシブ構成のSOAデータ・ソースのサンプルJDBC URLを次に示します。
jdbc:oracle:thin:@ (DESCRIPTION= (CONNECT_TIMEOUT=15) (RETRY_COUNT=5) (RETRY_DELAY=5) (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))) (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )
「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。次の例は、成功した場合の接続通知を示しています。
Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.
-
OPSSセキュリティ・ストアのJDBC URLを更新して、両方のサイトに適切なサービスを含めます。
ステップは次のとおりです。-
APPHOST1
にサインインし、$ASERVER_HOME/config/fmwconfig
フォルダに移動します。 -
jps-config-jse.xml
およびjps-config.xml
ファイルのバックアップ・コピーを取ります。 -
両方のファイルを編集して、プロパティ
name="jdbc.url"
の値を、データソースで使用される適切なJDBC URLを使用して更新します。 -
管理サーバーと管理対象サーバーを再起動します。
-
JDBC URLが正しく更新されたことを確認するには、Enterprise Managerコンソールに移動します。
-
「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
-
「セキュリティ・ストア」を展開し、「データベースURL」が更新されていることを確認します。
-
-
BI専用: このコマンドは、中間層データベースの接続詳細を同期し、接続詳細の変更時にBIコンポーネントが中間層データベースにアクセスできることを確認します。コマンドの場所:
DOMAIN_HOME/bitools/bin/sync_midtier_db.sh
ノート:
UNIXの場合、これをプライマリ・ホストで実行する必要があります。中間層データベース接続詳細を同期するには、次のようにします。-
同期スクリプトを実行します。
DOMAIN_HOME/bitools/bin/sync_midtier_db.sh
-
スクリプトには、更新されるデータ・ソースが表示されます。
-
管理対象サーバーおよびBIシステム・コンポーネントを再起動します。
-
親トピック: 本番サイトの作成
4.3 スタンバイ・サイトの作成
スタンバイ・サイトを作成する方法を学習します。
スタンバイ・サイトを作成するために、Oracle SOAエンタープライズ・デプロイメント・トポロジを例として使用します。
この項には次のトピックが含まれます:
- スタンバイ・サイトの準備
スタンバイ・サイトで操作できるように準備します。 - スタンバイ・サイトの自己署名証明書およびキーの更新
Oracle WebLogic管理サーバーでホスト名の検証を有効にしている場合、スタンバイ・サイトの証明書の適切なトラスト・ストアおよびキー・ストアを更新します。 - スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
親トピック: 障害時リカバリ・サイトの設定と管理
4.3.1 スタンバイ・サイトの準備
スタンバイ・サイトで操作できるように準備します。
スタンバイ・サイトで操作できるように準備するには、次のようにします。
-
「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名を正しく設定します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。
-
共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します
-
本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
- 中間層のホストの設定
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトにインストールされているソフトウェアがスタンバイ・サイトにレプリケートされます。
親トピック: スタンバイ・サイトの作成
4.3.1.1 中間層のホストの設定
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトにインストールされているソフトウェアがスタンバイ・サイトにレプリケートされます。
スタンバイ・サイトの中間層ホストを設定するには:
- 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。
- 本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。
- スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
- ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
親トピック: スタンバイ・サイトの準備
4.3.2 スタンバイ・サイトの自己署名証明書およびキーの更新
Oracle WebLogic管理サーバーでホスト名の検証を有効にしている場合、スタンバイ・サイトの証明書の適切なトラスト・ストアおよびキー・ストアを更新します。
証明書は、スタンバイ・サイトのノード専用に作成する必要があります。
ノードの証明書の作成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の中間層とハードウェア・ロード・バランサ間のSSL通信の有効化に関する項を参照してください。
これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してタスクを実行する方法を紹介します。
ノート:
この項には次のトピックが含まれます:
- 自己署名証明書の生成
自己署名証明書を生成する方法を確認します。 - キー・ストアへの証明書のインポート
utils.ImportPrivateKey
ユーティリティを使用して証明書をキー・ストアにインポートします。 - トラスト・キー・ストアの作成
トラスト・キー・ストアを作成し、keytool
ユーティリティを使用して証明書をインポートします。
親トピック: スタンバイ・サイトの作成
4.3.2.2 キー・ストアへの証明書のインポート
utils.ImportPrivateKey
ユーティリティを使用して証明書をキー・ストアにインポートします。
utils.ImportPrivateKey
ユーティリティを使用して証明書をキー・ストアにインポートするには:
親トピック: スタンバイ・サイトの自己署名証明書およびキーの更新
4.3.2.3 トラスト・キー・ストアの作成
トラスト・キー・ストアを作成し、keytool
ユーティリティを使用して証明書をインポートします。
トラスト・キー・ストアを作成し、証明書をそこにインポートするには:
親トピック: スタンバイ・サイトの自己署名証明書およびキーの更新
4.3.3 スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
スタンバイ・サイトを検証するには:
- 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
- スイッチバック操作を実行します。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。
- スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
親トピック: スタンバイ・サイトの作成
4.4 非対称スタンバイ・サイトの作成
非対称Oracle Fusion Middleware障害時リカバリ・トポロジを作成する方法を学習します。
非対称トポロジは、本番サイトとスタンバイ・サイトで異なる障害時リカバリ構成です。障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトと本番サイトの相違点は、スタンバイ・サイトのリソースの数が本番サイトより少ないという点です。
このドキュメントの前述の章で対称トポロジの設定方法を確認してください。対称トポロジの設定に使用する概念の多くは、非対称トポロジを設定する際にも有効です。
この項には次のトピックがあります。
- 非対称スタンバイ・サイトの作成
Oracle Fusion Middleware障害時リカバリ・トポロジの非対称スタンバイ・サイトを作成します。 - 非対称スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
親トピック: 障害時リカバリ・サイトの設定と管理
4.4.1 非対称スタンバイ・サイトの作成
Oracle Fusion Middleware障害時リカバリ・トポロジの非対称スタンバイ・サイトを作成します。
本番サイトは、図4-2に示されているOracle SOA Suiteエンタープライズ・デプロイメントとして想定します。非対称スタンバイ・サイトは本番サイトと異なるものになります。
非対称スタンバイ・サイトを作成するには:
-
本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。
ノート:
スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。
-
次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。
-
本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。「ディレクトリ構造とボリュームの設計」を参照してください。
-
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
ボリューム設計の詳細は、「Oracle SOA Suiteに推奨されるボリューム設計」を参照してください。
-
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
Oracle中央インベントリ・ディレクトリの詳細は、「OracleホームとOracleインベントリ」を参照してください。
-
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
-
本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。「本番サイトの作成」を参照してください。
-
-
スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。このステップは重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。
ノート:
ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。
本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。
-
共有ストレージを構成して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。
-
本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。
-
ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次のステップを実行します。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
-
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
-
この時点で、本番サイトのOracle Fusion Middlewareインスタンスのインストールがスタンバイ・サイトにレプリケートされています。スタンバイ・サイトは、次のすべての項目に該当する状態となります。
-
Oracle Fusion Middlewareインスタンスは、本番サイトと同じボリューム上の同じOracleホーム・ディレクトリにインストールされています。また、ホストでは、Oracleホーム・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
-
Oracle中央インベントリ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle中央インベントリ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
-
Oracle HTTP Serverの静的HTMLページ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle HTTP Serverの静的HTMLページ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
-
スタンバイ・サイトのOracle Fusion Middlewareインスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。
ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトを作成するには、次のトピックを参照してください。
- ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成
ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成します。
親トピック: 非対称スタンバイ・サイトの作成
4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成
ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成します。
このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteエンタープライズ・デプロイメントとして想定します。「サイトの設定」から「ディレクトリ構造とボリュームの設計」では、この本番サイトと共有ストレージ・システムのボリュームを設定する方法および必要なマウント・ポイントの作成方法について説明しています。
図4-4に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。
図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。
図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-4の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。
この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。
「非対称スタンバイ・サイトの作成」に記載されているステップに従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。
非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-1のボリューム設計に関する推奨事項と表4-2のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。
非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトでは、WEBHOST2とSOAHOST2が存在しないため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。
親トピック: 非対称スタンバイ・サイトの作成
4.4.2 非対称スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
スタンバイ・サイトを検証するには:
- 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
- Oracle Data Guardを使用して、データベースをスイッチオーバーします。
- スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
親トピック: 非対称スタンバイ・サイトの作成
4.5 サイトの操作および管理の実行
Oracle Fusion Middleware障害時リカバリ・トポロジを操作および管理する方法を学習します。
この項には次のトピックが含まれます:
- 本番サイトおよびスタンバイ・サイトの同期化
本番サイトで中間層の変更を導入した場合に、本番サイトとスタンバイ・サイトの同期化を強制的に実行する方法を確認します。 - スイッチオーバーの実行
スイッチオーバー操作は、スタンバイ・サイトを本番ロールとして設定します。 - スイッチバックの実行
スイッチバック操作は、現在の本番サイトとスタンバイ・サイトのロールを元に戻します。 - フェイルオーバーの実行
フェイルオーバー操作は、本番サイトが使用できなくなった場合に、スタンバイ・サイトを本番ロールとして設定します。 - スタンバイ・サイトのテスト
スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、これを使用してスタンバイ・サイトをテストする方法を確認します。 - テストでのピアツーピアのファイル・コピーの使用
テスト環境でユーティリティrsync
を使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。
親トピック: 障害時リカバリ・サイトの設定と管理
4.5.1 本番サイトおよびスタンバイ・サイトの同期化
本番サイトで中間層の変更を導入した場合に、本番サイトとスタンバイ・サイトの同期化を強制的に実行する方法を学習します。
通常の操作では、スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトで中間層の変更を導入した場合(本番サイトに新しいアプリケーションをデプロイした場合など)、同期化を強制的に実行します。ストレージ・レプリケーション・テクノロジを使用して同期化を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期化は、Oracle Data Guardによって管理されます。
親トピック: サイトの操作および管理の実行
4.5.2 スイッチオーバーの実行
スイッチオーバー操作は、スタンバイ・サイトを本番ロールとして設定します。
本番サイトを停止したり(メンテナンスを実行する場合など)、現在のスタンバイ・サイトを本番サイトにすることを計画している場合に、この操作が必要になります。
スイッチオーバー操作を実行するには:
これで、前のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトでメンテナンスを実行できるようになりました。元の本番サイトでメンテナンスを実行した後、将来、そのサイトを本番サイトとしてもスタンバイ・サイトとしても使用できます。
ノート:
このノートはBI固有のシステムにのみ適用されます。
スイッチオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。
oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
-
次のようなselect文を使用して一時表領域を指定します(ここで、
BIS17V1
はOracle Business Intelligence RCU接頭辞です)。select username,temporary_tablespace from dba_users where username like 'BIS17V1%'
前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACE
BIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMP
BIS17V1_STB.....BIS17V1_IAS_TEMP
BIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMP
BIS17V1_MDS.....BIS17V1_IAS_TEMP
BIS17V1_IAU.....BIS17V1_IAS_TEMP
BIS17V1_BIPLATFORM......BIS17V1_IAS_TEMP
BIS17V1_OPSS.....BIS17V1_IAS_TEMP
-
スイッチオーバー後、内容およびデータファイルも含め、表領域
BIS17V1_IAS_TEMP
が削除されます。 -
一時表領域
BIS17V1_IAS_TEMP
を一時ファイルとして、(たとえば)/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbf
の場所に250MBのサイズで作成します。 -
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
親トピック: サイトの操作および管理の実行
4.5.4 フェイルオーバーの実行
フェイルオーバー操作は、本番サイトが使用できなくなった場合に、スタンバイ・サイトを本番ロールとして設定します。
フェイルオーバー操作を実行するには:
ノート:
フェイルオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
-
次のようなselect文を使用して一時表領域を指定します(ここで、
BIS17V1
はOracle Business Intelligence RCU接頭辞です)。select username,temporary_tablespace from dba_users where username like 'BIS17V1%'
前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACE
BIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMP
BIS17V1_STB.....BIS17V1_IAS_TEMP
BIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMP
BIS17V1_MDS.....BIS17V1_IAS_TEMP
BIS17V1_IAU.....BIS17V1_IAS_TEMP
BIS17V1_BIPLATFORM......BIS17V1_IAS_TEMP
BIS17V1_OPSS.....BIS17V1_IAS_TEMP
-
フェイルオーバー後、内容およびデータファイルも含め、表領域
BIS17V1_IAS_TEMP
が削除されます。 -
場所内の一時ファイルとして、一時表領域
BIS17V1_IAS_TEMP
を作成します。たとえば、サイズ250 mで/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbf
です。 -
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして再度使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
親トピック: サイトの操作および管理の実行
4.5.5 スタンバイ・サイトのテスト
スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、これを使用してスタンバイ・サイトをテストする方法を学習します。
通常のOracle Fusion Middleware障害時リカバリ構成では、次のものを使用します。
-
ストレージ・レプリケーション。これを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。
-
Oracle Data Guard。これを使用して本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。
-
スタンバイ・サイト。本番サイトが使用できなくなった場合に、これを本番ロールとして使用します。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定したメンテナンスの場合など)、スイッチオーバー操作(「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。
通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。
スタンバイ・サイトをテストする別の方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイト共有ストレージをテストで使用します。
この代替テスト方法を使用するには:
-
共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回のみテストする場合、これは1回かぎりのクローン操作にできます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトの読取り専用ボリュームの、スタンバイ・サイトの読取り/書込みクローン・ボリュームへの定期的クローニングを設定できます。
-
スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。
-
12c以降のデータベースについては、次のステップに従って、スナップショット・スタンバイ・データベースを確立します。
-
REDO適用がアクティブな場合は、取り消します。
-
データベースがマウントされ、オープンしていないことを確認します。
-
高速リカバリ領域が構成されていることを確認します。フラッシュバック・データベースを有効化する必要はありません。
変換を実行するには、次のSQLコマンドを実行します。
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
-
読取り/書込みモードでスナップショット・スタンバイをオープンするには、次のSQLコマンドを実行します。
SQL> ALTER DATABASE OPEN READ WRITE;
-
-
11gデータベースについては、次のステップに従って、スナップショット・スタンバイ・データベースを確立します。
-
REDO適用がアクティブな場合は、取り消します。
-
データベースがマウントされ、オープンしていないことを確認します。
-
変換を実行するには、次のSQLコマンドを実行します。
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
データベースは変換の完了後にディスマウントされます。
-
データベースを再起動します。
-
-
-
Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。
-
スタンバイ・サイトのコンピュータで、次のステップに従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。
-
読取り専用の共有ストレージ・ボリュームをアンマウントします。
-
クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。
-
-
スタンバイ・サイトをテストする前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように
/etc/hosts
ファイルを変更します。 -
スタンバイ・サイトのテストを実行します。
スタンバイ・サイトのテストが完了したら、次のステップに従って、元の本番サイトを本番サイトとして再度使用します。
-
スタンバイ・サイトの読取り専用共有ストレージ上のボリュームを指すようにスタンバイ・サイト・コンピュータのmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態にリセットします。
-
クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。
-
読取り専用の共有ストレージ・ボリュームをマウントします。
これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。
-
-
本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。
-
Oracle Database 10.2以降については、次のステップに従います。
-
アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。
SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO POINT standbytest; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE;
-
管理リカバリを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
-
スタンバイ接続先を再度有効にし、ログを切り替えます。
SQL> ALTER SYSTEM SET LOG ARCHIVE DEST STATE 2=ENABLE;
-
-
Oracle Database 12cの場合、フィジカルおよびスナップショット・スタンバイ・データベースの管理に関する項のステップに従って、レプリケーションを再度設定します。
-
-
元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように
/etc/hosts
ファイルを変更します。
親トピック: サイトの操作および管理の実行
4.5.6 テストでのピアツーピアのファイル・コピーの使用
テスト環境でユーティリティrsync
を使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。
テスト環境で中間層のコンポーネントをレプリケートする代替方法は、rsync
ユーティリティ(ピアツーピア・ファイル・コピーを使用)を使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。rsync
ユーティリティの使用は、対称トポロジのコンテキストで説明されています。
Oracle Fusion Middlewareコンポーネントの障害保護と障害時リカバリの場合、ストレージ・レプリケーションの使用とrsync
ユーティリティの使用には多数の類似点があるため、Oracle Fusion Middleware障害時リカバリ・トポロジにおけるOracle Data Guardでのストレージ・レプリケーションを確認してください。
ノート:
ストレージ・レプリケーション・テクノロジの使用とrsync
ユーティリティの使用の次の重要な相違点に注意して、中間層のファイル・システムをレプリケートしてください。
-
ストレージ・レプリケーションの使用時は、本番サイトで前のスナップショットが作成された時点まで変更をロールバックできます。
rsync
ユーティリティの使用時は、レプリケートされた本番サイトのデータによってスタンバイ・サイトのデータが上書きされるため、レプリケーションをロールバックすることはできません。 -
ストレージ・レプリケーションの使用時は、共有ストレージ・システムで各ホスト・クラスタについて設定したボリュームによって、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間でそのホスト・クラスタのデータの整合性が保証されます。
rsync
ユーティリティの使用時は、データの整合性は保証されません。
これらの相違点があるため、rsync
ユーティリティは本番環境ではサポートされておらず、テスト環境のみでサポートされています。
この項には次のトピックが含まれます:
- Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用
Oracle Fusion Middleware障害時リカバリにおいてUNIXrsync
ユーティリティおよびOracle Data Guardを使用する方法を確認します。
親トピック: サイトの操作および管理の実行
4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用
Oracle Fusion Middleware障害時リカバリにおいてUNIX rsync
ユーティリティおよびOracle Data Guardを使用する方法を学習します。
ノート:
Oracle Database用のOracle Data Guardの設定方法の詳細は、「データベースに関する考慮事項」を参照してください。
次の項では、rsync
ユーティリティおよびOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジで本番サイトとスタンバイ・サイト間で保護および強制的に同期化を実行する方法について説明します。
- Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用
UNIXrsync
ユーティリティを使用して、Oracle Fusion Middleware中間層コンポーネントを保護およびリカバリします。 - フェイルオーバー操作およびスイッチオーバー操作の実行
rsync
ユーティリティの使用時にフェイルオーバーまたはスイッチオーバー操作を実行する方法を確認します。
親トピック: テストでのピアツーピアのファイル・コピーの使用
4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用
UNIX rsync
ユーティリティを使用して、Oracle Fusion Middlewareの中間層コンポーネントを保護およびリカバリします。
rsync
ユーティリティを使用するには:
4.6 障害時リカバリのためのOracle Site Guardの使用
Oracle Site Guardは、2つの障害時リカバリ・サイト間のスイッチオーバーおよびフェイルオーバーを編成します。
Oracle Site Guardでは、次のことを行います。
-
企業データの高可用性、データ保護および障害時リカバリを保証します。
-
スイッチオーバーやフェイルオーバーなどのOracle Site Guard操作を実行します。プライマリ・サイトが計画停止または計画外停止のため使用不可となった場合、スイッチオーバーまたはフェイルオーバー・プロセスはOracle Site Guardを使用して開始する必要があります。
Oracle Site Guardの使用方法の詳細は、Oracle Site Guard管理者ガイドを参照してください。
親トピック: 障害時リカバリ・サイトの設定と管理
4.7 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用
Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードします。
パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。
Oracle Fusion Middlewareのパッチを適用するには:
- 開始時の状態が保持されるように、本番サイトのバックアップを実行します。
- パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。
- パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。
- パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があるため、このステップを必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。
- これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。
ノート:
パッチは、Oracle Fusion Middleware 12c障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。
同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。
親トピック: 障害時リカバリ・サイトの設定と管理