oracle database applianceによるoracle data guardの構成

Oracleホワイト・ペーパー

2012年4月

Oracle Database Applianceによる Oracle Data Guardの構成

目次

目次 ............................................................................. 2

はじめに ......................................................................... 2

スタンバイ・データベース環境が必要な理由 ....................................... 2

Oracle Data Guardを使用する理由 ............................................... 3

Oracle Data Guardの使用によるさまざまな利点 ....................................... 3

セットアップのベスト・プラクティス ............................................... 5

結論 ............................................................................. 7

付録A：Oracle Database Applianceの設定例.......................................... 8

サンプル環境 .................................................................. 8

スタンバイ環境の構成 ......................................................... 12

スタンバイ・データベースのインスタンス化 ...................................... 14

インスタンス化が完了した後の手順 ............................................. 16

付録B：シングル・インスタンス・データベースからOracle RACへの変換 ................ 17

付録C：Oracle Data Guard Broker構成の作成 ........................................ 19

参考資料 ........................................................................ 22

Oracle Database ApplianceによるOracle Data Guardの構成

2

はじめに

Oracle Database Applianceは、サーバー、ストレージ、ネットワーキング、ソフトウェアを含むク

ラスタ化データベース・システムです。事前に構築とチューニングが完了しており、すぐに使用で

きます。オラクルは、配置、運用、管理が容易になるようにこのシステムを最適化しました。Oracle

Database Applianceは中小規模の実装に最適なデータベース・プラットフォームであり、Oracle

Database、Oracle Real Application Clusters（Oracle RAC）、Oracle Clusterware、Oracle Automatic

Storage Management（Oracle ASM）などの強力で実績のあるOracleテクノロジーが組み込まれてい

ます。Oracle Database Applianceではハードウェアとソフトウェアが統合されているため、手作業

で組み立てる非統合のソリューションに特有の複雑さを解消し、数週間から数ヶ月かかる配置を数

時間に短縮しました。さらに、構成や設定の誤りが原因で、最善とは言えない、管理が困難なデー

タベース環境になるのを防止しています。

スタンバイ・データベース環境が必要な理由

Oracle Database Applianceはそれ自体が高可用性のシステムですが、スタンバイ・データベース環

境は、計画停止時間および計画外停止時間に対する保護と同時に、プライマリ・データベース環境

が使用できなくなった場合のデータ損失に対する保護を提供できます。また、適切なテクノロジー

を使用して、スタンバイ・データベースとプライマリ・データベースの同期を維持することが可能

であるため、ユーザー・エラーからシステム障害、そして災害に至るまで、問題に直面した場合で

も、データベースの運用をほぼ透過的に継続できます。このように、スタンバイ・データベースは、

重要な本番システムの高可用性と保護を確保する上で、常に中心となってきました。

オラクルは、プライマリOracle Database Applianceシステムを実行している1つ以上のミッション・

クリティカルな本番データベースに対応するスタンバイ・データベースを、独立した専用のOracle

Database Applianceシステムを使用してホストすることを推奨しています。

図1： 2つのOracle Database Applianceを使用したOracle Data Guardのセットアップ


3

Oracle Data Guardを使用する理由

Oracle Data Guardが障害時リカバリ・ソリューションとして推奨される理由は、Oracle Database

Applianceにあるデータベースを、データベースの"異常"または停止の原因となるデータベースやク

ラスタの障害、破損、災害、ユーザー・エラーから保護できるためです。Oracle Data GuardとOracle

Databaseの緊密な統合は、他のソリューションでは達成不可能な、これまでにないレベルのデータ

保護を実現します。お客様は、Oracle Database Enterprise Editionの一部としてOracle Data Guard

を利用できます。Oracle Data Guardは配置が簡単で、1つ以上の同期コピー（スタンバイ・データ

ベース）を作成して維持するための管理、監視、自動化を目的としたソフトウェアを提供します。

Oracle Data Guardを使用すると、何らかの理由で本番データベース・システムが利用できなくなっ

た場合に、データベースの可用性を簡単に維持でき、また、計画された保守アクティビティを実施

している間の停止時間を、アプリケーション・ワークロードをスタンバイ環境に移動することによっ

て最小化できます。

Oracle Data Guardの使用によるさまざまな利点

Oracle Data Guardを使用すれば、スタンバイ・データベース環境をアイドル状態にして無駄な容量

を確保する必要はありません。むしろ、スタンバイ・データベースは、多くの有用な目的を果たす

のに非常に役立ちます。Oracle Data Guardを使用してスタンバイ・データベースを実装することに

は、いくつもの利点があります。これら非常に多くの利点により、労力と投資の見返りとして得ら

れる全体的な収益を大幅に増大します。

Oracle Database Applianceへの移行 – Oracle Data Guardは、Oracle Database Applianceへの

移行を容易にします。もう1つのOracle Database Appliance上にフィジカル・スタンバイ・デー

タベースを作成するだけで、古い環境から新しい環境へスイッチオーバーできるようになります。

これには、異なるプラットフォーム間での移行も含まれます。たとえば、現在Windows上で稼働し

ているデータベースをLinuxプラットフォームのOracle Database Applianceに移行するには、2

つの環境の間にOracle Data Guardをセットアップしてスイッチオーバーするだけで済みます。こ

の方法でのプラットフォーム移行は、テスト後に何らかの理由でスイッチバックが必要となった

場合に、それを実行できる柔軟性があります。Data Guardを使用したプラットフォーム移行の詳

細については、My Oracle Support（MOS）Note 413484.1『Data Guard Support for Heterogeneous

Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。

また、Oracle Data Guardでは、一時ロジカル・スタンバイ・データベースを使用して、バージョ

ンの異なるデータベース間で移行を行うこともできます。

障害時リカバリ – Oracle Data Guardのフィジカル・スタンバイ・データベースは、災害対策と

して理想的なソリューションです。災害のシナリオは、水道管や蒸気管の破裂、火災、台風、破

壊行為から、地震、洪水、テロに至るまでさまざまです。Oracle Data Guardは、本番データベー

スのコピーをブロック単位で維持します。何らかの理由でプライマリ環境が利用できなくなった

場合は、データベースの可用性を引き続き維持するために、スタンバイ環境をすぐにアクティブ

化できます。


4

高可用性 – スタンバイ・データベースは、計画停止や計画外停止の間（構成の変更、ハードウェ

アの交換など）、およびデータの破損、人為的エラーによる障害、予期しないシステム障害が発

生している間に、可用性を維持するのに役立ちます。

データベース・ローリング・アップグレード – スタンバイ・データベースは、プライマリOracle

Database Applianceに特定のパッチを適用して変更を加える場合の停止時間を最小化します。

パッチまたは他の保守作業は、最初にスタンバイ・データベースに適用して検証を行い、その後

で本番データベースをスタンバイ・データベースに切り換えます。停止時間は、プライマリとス

タンバイのロールを変更するために必要な短時間だけとなります。詳細については、My Oracle

Support（MOS）Note 1265700.1『Oracle Patch Assurance - Data Guard Standby-First Patch Apply』

を参照してください。

ワークロードとアクティビティのオフロード – スタンバイ環境をアイドル状態にする必要はあ

りません。スタンバイ環境は、全体の投資収益率を最大化するのに活用されます。フィジカル・

スタンバイ・データベースを設置することで、いくつかの重要なアクティビティをスタンバイ環

境にオフロードできます。

読取り専用問合せ – Oracle Active Data Guardオプションを使用すると、スタン

バイ・データベースは、問合せワークロードを受け付けることができ、スタンバイ・

モードであってもプライマリ・データベースからの更新を受け入れます。多くの場

合、この機能は、本番ワークロードの大部分をスタンバイ・データベース環境にオ

フロードするのに役立ち、システムの全体的な処理能力が向上します。

バックアップ – フィジカル・スタンバイ・データベースはプライマリ・データベー

スのコピーをブロック単位で維持しているので、データベースのバックアップをス

タンバイ環境に完全にオフロードできます。したがって、障害やデータベースの損

失が発生したときに、これらのバックアップを透過的に使用して、プライマリ・デー

タベースのリストアとリカバリを行うことができます。なお、Oracle Active Data

Guardのライセンスがある場合は、スタンバイ・データベースで高速増分バックアッ

プを実行できるので、スタンバイ・データベースへのオフロード・バックアップ機

能がさらに魅力的なものとなります。

ブロック修復 – フィジカル・スタンバイ・データベースが持つ他の利点の1つとし

て、ブロック破損のシナリオにおけるリカバリ処理を自動的に提供する機能があり

ます。プライマリ/スタンバイ構成では、破損ブロックの自動修復が可能で、この操

作は完全に透過的に実行できます。この機能はOracle Active Data Guardオプショ

ンの一部です。

スナップショット・スタンバイ – スナップショット・スタンバイ・データベースは、プライマ

リ・データベースの完全なデータ保護を実現する更新可能なスタンバイ・データベースです。こ

のデータベースは、プライマリ・データベースからREDOデータを継続的に受け取りますが、スタ

ンバイ・データベースがテスト用の読取り/書込みを受け付けている間は、適用プロセスが停止し

ています。テストが完了すると、1つのコマンドで、スタンバイ・データベースを元の状態に戻し、

読取り/書込みを受け付けている間に行われた変更を破棄し、蓄積されたREDOログを適用してプラ

イマリ・データベースと同じ最新の状態にします。


5

セットアップのベスト・プラクティス

ここでは、Oracle Database Appliance上でOracle Data Guardをセットアップする際の重要なベス

ト・プラクティスについていくつか説明します。Oracle Data Guardの一般的なベスト・プラクティ

ス（Oracle Database Appliance環境にも適用可能）の完全なリストについては、『Oracle® Database

高可用性ベスト・プラクティス11gリリース2（11.2）』の第8章Oracle Data Guardの構成を参照し

てください。

プライマリ・データベースとスタンバイ・データベースの構成を一致させる－一貫したサービ

ス・レベルの維持およびプライマリ・データベースとスタンバイ・データベースの透過的な使用

を実現するには、2つのシステム間でリソース、設定、構成をできる限り一致させることが重要で

す。プライマリ・データベースとスタンバイ・データベースの間で構成が著しく異なっていると、

ロール移行が発生したときに、最善のパフォーマンスが得られないことや、予期しなかった動作

が起こることがあります。具体的には、以下のような推奨事項があります。

プライマリ・データベースとスタンバイ・データベースを独立したOracle Database

Appliance上で実行－プライマリ・データベースとスタンバイ・データベースを、

独立したOracle Database Applianceユニット上で実行することが推奨されています。

この場合、プライマリ・データベースを1つのOracle Database Applianceユニット

に配置し、スタンバイ・データベースを別のOracle Database Applianceユニット（地

理的に離れた場所にあることが好ましい）に配置する必要があります。

プライマリ・データベースとスタンバイ・データベースを同じ構成で実行－ Oracle

Database Applianceでは、Oracle RACデータベース、Oracle RAC One Node、Single

Instance Enterprise Editionデータベースといった3つの異なるデータベース構成

をサポートしています。また、スタンバイ・データベースは、プライマリ・データ

ベースと同じ種類の構成にする必要があります。したがって、プライマリ・データ

ベースをクラスタ・データベース（Oracle RAC）として構成する場合は、スタンバ

イ・データベースもクラスタ・データベース（Oracle RAC）として構成する必要が

あります。

プライマリ・インスタンスとスタンバイ・インスタンスで互いに類似した構成を使

用－プライマリ・データベースとスタンバイ・データベース上のインスタンスは、

データベース・パラメータの設定に関して互いに類似した構成にする必要がありま

す。これは、データベースのロールを切り換える際に、予測不可能な動作の発生を

防止するのに役立ちます。

ロール移行に対応できるようにプライマリ・データベースとスタンバイ・データベー

スを事前に構成－プライマリ・データベースとスタンバイ・データベースは、プ

ライマリからスタンバイおよびその逆のロール移行中に、要求または必要とされる

変更が最小限になるように構成する必要があります。したがって、プライマリ・デー

タベースに実装する機能はすべて、事前にスタンバイ・データベース側で構成して

おく必要があります。


6

プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベー

スを構成－フラッシュバック・データベース機能は、迅速なロール移行を可能にし、移行後に

データベースのロールを再設定するために必要な労力を削減します。ベスト・プラクティスとし

て、プライマリ・データベースとスタンバイ・データベースの両方で、フラッシュバック・デー

タベースを構成する必要があります。ただし、Data Guard構成の再指定だけを目的としてフラッ

シュバック・データベースを使用する場合のベスト・プラクティスは、フラッシュバックの保持

ターゲットをデフォルトの24時間から2時間に短縮することです。

スタンバイ・データベースのトラフィックに対応する専用ネットワークを使用－ Oracle Database

Applianceは、複数の冗長ネットワーク・インタフェースが事前に組み込まれた状態で出荷されます。

必要であれば、スタンバイ・データベースのトラフィックに対応するための独立したネットワーク・

パスを作成して、ユーザーとアプリケーションに関連したワークロードのパフォーマンスに与える影

響を最小限にできます。Oracle Data Guardで必要なのは、プライマリ・データベースに加えられた変

更のみをプライマリ・データベースからスタンバイ・データベースに転送することなので、ネットワー

クに関して必要以上の不要な要件を強制するものではないことに注意してください。したがって、

Oracle Data Guardを配置する場合、プライマリ・データベースとスタンバイ・データベース間でREDO

ログを転送するために独立したネットワーク・パスの確立が必要になることはそれほど多くありませ

ん。しかし、一部の大容量アプリケーションでは、REDOログの転送用に独立したネットワーク・パス

が必要となることもあります。Oracle Database Applianceでは、このようなネットワークを構成でき

るように、各サーバー・ノードに対して、1GbEのパブリック・インタフェースの他に3つの追加ネット

ワーク・インタフェース（10GbEインタフェースを含む）を提供しています。Oracle Database Appliance

上で障害時リカバリを目的とした専用ネットワークを構成するための詳細情報については、MOS Note

1451810.1を参照してください。

特定のワークロードをスタンバイ・データベースにオフロードすることを検討－ Oracle

Recovery Manager（Oracle RMAN）は、プライマリ・データベースとスタンバイ・データベースに

またがって透過的に機能します。スタンバイ・データベースは、プライマリ・データベース環境

からのバックアップのオフロードに活用されるべきです。Oracle Active Data Guard構成を使用

すると、問合せワークロードのスタンバイ環境へのオフロードが可能になります。さらに、スタ

ンバイ・データベースは、ブロック破損を透過的に修復できるようにします。

Oracle Active Data Guardの利用を考慮 – Oracle Active Data Guardは、スタンバイ・データ

ベースが読取り専用操作を受け付けることを可能にし、さらに管理リカバリ（スタンバイ・デー

タベース側のREDO転送とアプリケーション）を同時にアクティブにします。この機能は、プライ

マリ環境からのワークロードをスタンバイ・データベースに分散するのに役立ち、スタンバイ・

データベースの投資収益率が向上します。Oracle Active Data Guardによって、スタンバイ・デー

タベースで高速増分バックアップを使用することも可能になります。高速増分バックアップは、

バックアップ時間枠を数時間から数分に短縮することもあり得ます。

Oracle DatabaseのOracle Maximum Availability Architecture（Oracle MAA）ベスト・プラクティ

スを確認－ Data Guard環境の配置と使用状況によって異なりますが、以下に示すOracle Data

Guardを役立てるための追加的なベスト・プラクティスを確認できます。

a. 『Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database

11g Release 2』Oracle Maximum Availability Architectureホワイト・ペーパー


7

b. 『 Oracle Active Data Guard Oracle Data Guard 11g』 Oracle Maximum Availability

Architectureホワイト・ペーパー

c. Oracle Database高可用性ベスト・プラクティス11gリリース2（11.2）の8.4 Oracle Data Guard

のロール移行のベスト・プラクティス

d. 『Preventing, Detecting, and Repairing Block Corruption: Oracle Database 11g』Oracle

Maximum Availability Architectureホワイト・ペーパー

Oracle Databaseの Oracle Maximum Availability Architectureベスト・プラクティスは、

http://www.oracle.com/technetwork/database/features/availability/oracle-database-maa-bes

t-practices-155386.htmlから入手できます。

結論

Oracle Data GuardをOracle Database Applianceで使用すると、初期配置の段階から、効果的な障

害時リカバリ保護戦略を配置することが可能になります。このホワイト・ペーパーで概要を説明し

たフィジカル・スタンバイの構成プロセスはシンプルで、プライマリ・データベースで停止時間を

発生させることなく完了できます。フィジカル・スタンバイを作成する手順の大部分は、Oracle

Appliance Manager、Oracle Database Configuration Assistance（Oracle DBCA）、Oracle RMAN、

Oracle Data Guardを使用することで自動化されます。自動化によって、エラーまたは不適切な構成

の危険性を除去できます。プライマリ・データベースとスタンバイ・データベースの作成は、プラ

イマリ・データベースを最初に配置する際に実行できます。


8

付録A：Oracle Database Applianceの設定例

サンプル環境

ここでは、Oracle Database Applianceを使用したData Guardの設定例において採用されている、プ

ライマリおよびスタンバイ・データベース環境のトポロジについて説明します。

図2： Oracle Database Appliance上にあるOracle RACの構成トポロジ

表1： Oracle Databaseのネーミング規則の例

プライマリOracle Database Appliance スタンバイOracle Database Appliance

アプライアンス名 appliance#1 appliance#2

ホスト名 slcac456 slcac457 slcac458 slcac459

クラスタ名 CLUSTER1 CLUSTER2

データベース名 pdb sdb

インスタンス名 pdb1 pdb2 sdb1 sdb2

SCAN名とIPアドレス slcac456-scan（10.1.27.2、10.1.27.3） slcac458-scan（10.1.27.4、10.1.27.5）

Oracle Grid Infrastructure ソフト

ウェアのインストール場所

/u01/app/11.2.0.3/grid /u01/app/11.2.0.3/grid

Oracle Databaseソフトウェアの

インストール場所

/u01/app/oracle/product/11.2.0.3/db_home1 /u01/app/oracle/product/11.2.0.3/db_home1

ARCHIVELOGモード有効有効

FORCE LOGGINGモード有効有効


9

1. スタンバイREDOログを作成

オラクルは、Data Guard構成の中にあるプライマリ・データベース上にスタンバイREDOログを作

成しておくことを推奨しています。これによって、スタンバイ・ロールにスイッチオーバーした

後すぐにREDOデータを受け取れる状態になります。

プライマリ・データベース上にスタンバイREDOログ（SRL）を作成します。スタンバイREDOログ

の各スレッドに対して、オンラインREDOログの対応するスレッドより少なくとも1つ多いREDOロ

グ・グループを割り当てる必要があります。

$> sqlplus / as sysdba

SQL> alter database add standby logfile thread 1 group 7 size

1024M, group 8 size 1024M, group 9 size 1024M, group 10 size

1024M;

SQL> alter database add standby logfile thread 2 group 11

size 1024M, group 12 size 1024M, group 13 size 1024M, group

14 size 1024M;

オンラインREDOログの数とそれらのサイズを確認するには、次の問合せを使用します。

SQL> select group#, thread#, bytes from v$log;

スタンバイREDOログのサイズは、REDOログのサイズと一致している必要があることに注意してく

ださい。スタンバイREDOログは、REDOディスク・グループ内に作成する必要があります。

スタンバイREDOログ内にある各ログ・ファイルのサイズとログ・グループの数を確認するには、

次の問合せを使用します。

SQL> select group#, thread#, bytes from v$standby_log;

2. プライマリ・データベースでARCHIVELOGモードを有効化

プライマリ・データベースがARCHIVELOGモードで実行されていることを確認します。

SQL> archive log list

プライマリ・データベースがARCHIVELOGモードで実行されていない場合は、ARCHIVELOGモードを

有効にします。

Oracle Database Applianceで、両方のインスタンスを停止します。

$ srvctl stop database –d pdb

SQL> startup mount exclusive;

SQL> alter database archivelog;

SQL> shutdown immediate;

$ srvctl start database –d pdb


10

3. FORCE LOGGINGモードを有効化

FORCE LOGGINGモードが有効であることを確認します。プライマリ・データベースでFORCE LOGGING

モードが有効になっていない場合は、FORCE LOGGINGモードを有効にします。

SQL> select force_logging from v$database;

SQL> alter database force logging;

4. フラッシュバック・データベース機能を構成

フラッシュバック・データベース機能の使用はオプションではありますが、フェイルオーバーの

後で古いプライマリ・データベースをより素早く再構成するために、Oracleデータベースのフ

ラッシュバック・データベース機能を使用することが推奨されています。したがって、スタンバ

イ・データベースへのフェイルオーバーを実行すると、古いプライマリ・データベースの修復が

可能となり、再構築の必要はなく、フラッシュバックするだけで、それ以降Oracle Data Guard

が再同期するようになります。

プライマリ・データベースでフラッシュバック・データベース機能が有効になっているかどうか

を確認し、必要であればフラッシュバック・データベース機能を有効にします。

SQL> select flashback_on from v$database;

SQL> alter database flashback on;

フラッシュバック・データベース機能を有効にすると、ファスト・リカバリ領域（FRA）の消費量が

増加することに注意してください。フラッシュバック・ログによって使用される領域は、パラメータ

DB_FLASHBACK_RETENTION_TARGETに目標値（分単位）を設定することで制御できます。

SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=120

scope=both sid='*';

5. スタンバイ・ファイル管理を有効化

プライマリ・データベースがデータファイルを追加または切り離した場合、スタンバイ・データ

ベースでも対応するアクションが自動的に実行される必要があります。この操作を自動化するに

は、スタンバイ・ファイル管理を有効にします。

SQL> alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both

sid='*';

6. リモート特権ログインを有効化

プライマリ・データベースの各インスタンスが、リモート・ログイン・パスワード・ファイルを

用いて構成されていることを確認します。Oracle Database Applianceがこの設定を含むデータ

ベースを配置することに注意してください。初期化パラメータREMOTE_LOGIN_PASSWORDFILEは、

exclusiveに設定する必要があります。このパラメータを次のように変更する必要がある場合は、

変更を有効にするためにインスタンスを再起動します。

$ sqlplus / as sysdba

SQL> show parameter remote_login_passwordfile

SQL> alter system set remote_login_passwordfile='exclusive'


11

scope=spfile sid='*';

7. REDO転送サービスを設定

Oracle Data GuardのREDO転送メカニズムは、Oracle Net接続を使用してデータベース間でREDO

ログを送信します。REDO転送を有効にするには、LOG_ARCHIVE_DEST_nパラメータを設定します。

たとえば、次の設定は、ログ送信を有効にし、LGWRを非同期モードで使用します。

SQL> alter system set log_archive_dest_2='SERVICE=sdb LGWR

ASYNC REGISTER VALID_FOR=(online_logfile,primary_role)

REOPEN=60 DB_UNIQUE_NAME=sdb' scope=both sid='*';

8. フェッチ・アーカイブ・ログ・サーバーを設定

データベースがスタンバイ・ロールで動作しているときに、プライマリ・データベースが欠落し

ているログ・ファイルを送信できない場合、スタンバイ・データベースは、FAL_SERVER設定を使

用してこれらの欠落したログ・ファイルを取得できます。FAL_SERVERパラメータでは、Oracle Net

サービス名を使用します。

SQL> alter system set FAL_SERVER=sdb scope=both sid='*';

SQL> alter system set remote_login_passwordfile=exclusive

scope=spfile;


12

スタンバイ環境の構成

ここでは、スタンバイ・データベース側で実行する必要がある手順について説明します。

1. TNSエントリを設定

Oracle Netサービス名は、データベース間でREDO転送ができるように構成する必要があります。

プライマリ・データベースのtnsnames.oraファイルを、スタンバイ・データベースのTNS別名エ

ントリで更新します。Oracle Database Applianceでは、tnsnames.oraファイルはOracle Database

ホームのnetwork/adminディレクトリにあります。

PDB =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = slcac456-scan)

(PORT = 1521))

(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =

pdb)))

SDB =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = slcac458-scan)

(PORT = 1521))

(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =

sdb)))

2. 静的リスナーの構成を作成

gridユーザーとして、インスタンス化の実行中に、スタンバイ・データベース上にRecovery

Manager接続用の静的リスナー・サービスを作成します。リスナー・ホームがGrid Infrastructure

ホーム（/u01/app/11.2.0.3/grid/network/admin）にあることに注意してください。

SID_LIST_LISTENER =

(SID_LIST = (SID_DESC = (GLOBAL_DBNAME = sdb)

(ORACLE_HOME =

/u01/app/oracle/product/11.2.0.3/dbhome_1)(SID_NAME = sdb))

3. リスナーを再起動

リスナーに変更を加えた後は、リスナーを再起動する必要があります。

$> srvctl stop listener

$> srvctl start listener


13

4. 初期スタンバイ・パラメータ・ファイルを作成

スタンバイ・データベース内に、パラメータ・ファイルpfile（$ORACLE_HOME/dbs/initsdb.ora）

を作成します。次に例を示します。

SQL> CREATE PFILE = 'initsdb.ora' FROM SPFILE;

5. パスワード・ファイルを作成

Oracle RMANの複製プロセスの実行中に、補助インスタンスへのアクセスに使用するリモート認

証のパスワード・ファイルを作成する必要があります。

$> orapwd

file=/u01/app/oracle/product/11.2.0.3/dbhome_1/dbs/orapwsdb

password=<primary sysdba passwd>

6. 監査ディレクトリを作成

スタンバイ・データベース上に、監査ファイルの保存先ディレクトリを作成します。

$ mkdir –p /u01/app/oracle/admin/sdb/adump

7. スタンバイ・インスタンスを起動

NOMOUNT状態になっている最初のスタンバイ・ホスト上でスタンバイ・データベース・インスタ

ンスを起動して、インスタンス化の準備を行います。

$> export ORACLE_SID=sdb

$> sqlplus / as sysdba

SQL> startup nomount

8. ネットワーク設定を確認

この段階で、Oracle Netは、プライマリ環境とスタンバイ環境の両方のTNS別名を、スタンバイ

環境から解決できる必要があります。

$ tnsping pdb

$ tnsping sdb

$ sqlplus sys/<password>@//slcac456:1521/pdb as sysdba


14

スタンバイ・データベースのインスタンス化

ここでは、プライマリ環境とスタンバイ環境で設定が完了した後のスタンバイ・データベースのイ

ンスタンス化について説明します。

1. データベースを複製

Recovery Managerを使用すると、DUPLICATE DATABASEコマンドでスタンバイ・データベースを作

成できます。複製プロセスの一部として、プライマリ・インスタンスからパラメータ・ファイル、

パスワード・ファイル､制御ファイル、データベース・ファイルがコピーされ、スタンバイ環境

にセットアップされます。

スタンバイ動作に必要な適切なパラメータ設定の変更は、Oracle RMANコマンドの中でも指定す

る必要があります。Oracle RMANがプライマリ・パラメータ・ファイルをコピーすると、それに

応じて、提供するパラメータが変更されます。

さらに、パスワード・ファイルもコピーされるので、スタンバイ・データベースはプライマリ・

データベースと同じパスワードを使用します。そのため、前項で作成したパスワードと同一であ

る必要はありません。

$rman

connect target sys/welcome1@//slcac456:1521/pdb

connect auxiliary sys/welcome1@//slcac458:1521/sdb

run {

allocate channel p1 type disk;




allocate auxiliary channel s1 type disk;

duplicate target database for standby from active database

dorecover

spfile

parameter_value_convert='/pdb','/sdb'

set db_unique_name = 'sdb'

set cluster_database = 'false'

set audit_file_dest = '/u01/app/oracle/admin/sdb/adump'


15

set db_create_file_dest = '+DATA'

set log_archive_dest_2 = 'service=pdb lgwr async register

valid_for=(online_logfiles, primary_role) db_unique_name=pdb'

set remote_listener = 'slcac458-scan:1521'

set fal_server='pdb'

nofilenamecheck;

}

2. フラッシュバック・データベースを有効化

スタンバイ・データベース上でフラッシュバック・データベースを有効にし、必要に応じて保存

期間を調整します。

SQL> alter database flashback on;

SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=120;

管理リカバリ・モードを開始します。

SQL> alter database recover managed standby database using

current logfile disconnect;

3. スタンバイspfileをASMに移動

スタンバイspfileをスタンバイ・データベース上のAutomatic Storage Managementに移動します。

$ export ORACLE_SID=sdb

RMAN> connect target /

RMAN> backup spfile;

RMAN> restore spfile to ‘+DATA/sdb/spfilesdb.ora’;

4. 管理リカバリ・モードを開始

次のように、管理リカバリ・モードを開始します。

SQL> alter database recover managed standby database using

current logfile disconnect;


16

インスタンス化が完了した後の手順

スタンバイのインスタンス化が完了した後は、以下の手順を実行します。

1. スタンバイ・データベースをOracle Clusterwareに登録

ORACLE_HOME環境変数が正しく設定されていることを確認します。スタンバイ・データベースを

シングル・インスタンスとしてOracle Clusterwareに登録し、クラスタのノードの1つから実行

します。

$ srvctl add database –d sdb –o $ORACLE_HOME –p

"+DATA/sdb/spfilesdb.ora" –r physical_standby –s mount –c

SINGLE -x slcac458

2. スタンバイ・データベースをOracle RACに変換

この手順はオプションです。この段階では、スタンバイ・データベースはシングル・インスタン

ス・データベースとして構成されています。プライマリ・データベースがOracle RACデータベー

スだった場合、スタンバイ・データベースもOracle RACスタンバイ・データベースに変換できま

す。rconfigツールを使用してシングル・インスタンス・データベースをOracle RACスタンバイ・

データベースに変換する方法については、付録Bを参照してください。

3. Oracle Data Guard Broker構成を設定

この手順はオプションです。Data Guard Broker構成を作成すると、Data Guard環境を単一のエ

ンティティとしてより簡単に管理することが可能になります。この構成は、ローカルとリモート

の両方で使用できる管理機能、保守機能、監視機能を提供します。Data Guard Broker構成を設

定する方法については、付録Cを参照してください。

4. 専用のDRネットワークを設定

この手順はオプションです。Oracle Data GuardのREDO転送サービスを構成すると、専用ネットワー

クを使用できます。専用ネットワーク・チャネルは、REDO転送のパフォーマンスを向上させるのに役

立ちます。特に、アプリケーションのネットワーク・トラフィックが、パブリック・ネットワークの

利用可能な帯域幅の大部分を消費している場合に有効です。Data GuardのREDO転送サービス用に専用

のネットワーク・チャネルを設定する方法については、MOS Note 1451810.1『Configuring Dedicated

Disaster Recovery Network on Oracle Database Appliance』を参照してください。

5. 構成と設定を確認

スタンバイ・データベースでは、内部データ・ディレクトリ・ビューを使用してスタンバイ・デー

タベースの動作を確認できます。

$ srvctl config database -d sdb

SQL> select database_role, switchover_status from v$database;

SQL> select thread#, sequence#, applied from v$archived_log

order by sequence#;


17

付録B：シングル・インスタンス・データベースからOracle RACへの変換

rconfigコマンドライン・ユーティリティを使用すると、シングル・インスタンス・データベースを

Oracle RACデータベースに変換すること、またはOracle RAC One Nodeに変換することができます。

この機能を使用するには、以下の手順を実行します。

構成XMLファイルを作成

convert.xmlとして保存されている構成XMLファイルのサンプルを以下に示します。このファイルは、

使用中のシステムに合うように変更できます。

サンプルの構成XMLファイルは、$ORACLE_HOME/assistants/rconfig/sampleXMLディレクトリにあり

ます。

注：最初は、変換オプションConvert verify="ONLY"を設定してテスト変換を実行し、変換が正常に

完了できることを確認してください。

rconfigツールを実行

変更が完了した後は、ファイルを保存します。スタンバイ・データベース上で、次のコマンドを実


18

行します。convert.xmlは、上記の手順で構成したXML入力ファイルの名前です。

$ rconfig convert.xml

Oracle Cluster Ready Servicesのリソースを更新

Oracle Cluster Ready Services（Oracle CRS）のリソースは、変換後のデータベースに対応できる

ように更新する必要があります。

$ srvctl modify database -d stby -r physical_standby -s mount

構成を確認

スタンバイ・データベースの構成を確認します。

$ srvctl config database -d stby


19

付録C：Oracle Data Guard Broker構成の作成

ここでは、Oracle Data Guard Broker構成の作成手順を説明します。

静的登録を行うためのリスナーを構成

プライマリ・データベースとスタンバイ・データベースのすべてのインスタンスを静的に登録する

ためのリスナーを構成します。Oracle Database Applianceでは、リスナーはGrid Infrastructure

ホームから実行されます。Oracle RACプライマリ/スタンバイ構成の静的登録の例を以下に示します。

slcac456の場合：

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC = (GLOBAL_DBNAME = pdb_DGMGRL)

(ORACLE_HOME =

/u01/app/oracle/product/11.2.0.3/dbhome_1)

(SID_NAME = pdb1)))


SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC = (GLOBAL_DBNAME = pdb_DGMGRL)

(ORACLE_HOME =


(SID_NAME = pdb2)))


SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = sdb_DGMGRL)

(ORACLE_HOME =


(SID_NAME = sdb1)))


20


SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC = (GLOBAL_DBNAME = sdb_DGMGRL)

(ORACLE_HOME =


(SID_NAME = sdb2)))

Data Guard Broker構成ファイルを設定

プライマリ・データベースとスタンバイ・データベースの両方で、Data Guard Broker構成ファイル

の場所を設定します。


SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1='+DATA' SCOPE=BOTH

SID='*';

SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2='+RECO' SCOPE=BOTH

SID='*';


SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1='+DATA' SCOPE=BOTH

SID='*';

SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2='+RECO' SCOPE=BOTH

SID='*';

Data Guard Brokerを有効化

プライマリ・データベースとスタンバイ・データベースの両方で、Data Guard Brokerを有効にします。


SQL> ALTER SYSTEM SET DG_BROKER_START='TRUE' SCOPE=BOTH SID='*';


SQL> ALTER SYSTEM SET DG_BROKER_START='TRUE' SCOPE=BOTH SID='*';


21

Data Guard Broker構成を作成

プライマリ・データベースのDB_UNIQUE_NAMEおよびそれに対応するTNS別名を使用して、プライマ

リ・データベース上にData Guard Broker構成を作成します。

DGMGRL> connect sys/welcome1;

DGMGRL> CREATE CONFIGURATION 'ODADGConfig' AS

> PRIMARY DATABASE IS 'PDB'

> CONNECT IDENTIFIER is PDB;

Data Guard Broker構成にスタンバイ・データベースを追加

スタンバイ・データベースのDB_UNIQUE_NAMEを使用して、構成にスタンバイ・データベースを追加

します。

DGMGRL> ADD DATABASE 'SDB' AS

> CONNECT IDENTIFIER IS SDB;

構成を有効化

Data Guard Broker構成を次のようにして有効化します。

DGMGRL> enable configuration;

構成を確認

次のコマンドを実行して、作成された構成を確認します。

DGMGRL> show configuration;

DGMGRL> show database verbose prim;

DGMGRL> show instance verbose prim1;

DGMGRL> show instance verbose prim2;

DGMGRL> show database verbose stby;

DGMGRL> show instance verbose stby1;

DGMGRL> show instance verbose stby2;


22

参考資料

1. Oracle Database ApplianceのOTN Webサイト

http://www.oracle.com/technetwork/server-storage/engineered-systems/database-applianc

e/overview/index.html

2. Oracle Real Application ClustersのOTN Webサイト

http://www.oracle.com/technetwork/jp/database/clustering/overview/index.html

3. Oracle ClusterwareのOTN Webサイト

http://www.oracle.com/technetwork/jp/database/clusterware/overview/index.html

4. Oracle Data GuardのOTN Webサイト

http://www.oracle.com/technetwork/jp/database/dataguardoverview-093007-ja.html

5. Oracle Maximum Availability Architecture

http://www.oracle.com/technetwork/jp/database/features/availability/maa-best-practice

s-355197-ja.html

6. Oracle Data Guard概要および管理11gリリース2（11.2）

http://docs.oracle.com/cd/E16338_01/server.112/b56302/title.htm

7. My Oracle Support（MOS）Note 1075908.1

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=107 5908.1

8. Oracle Database High AvailabilityのOTN Webサイト

http://www.oracle.com/technetwork/jp/database/focus-areas/availability/index.html

9. 『Oracle® Database高可用性ベスト・プラクティス11gリリース2（11.2）』

http://docs.oracle.com/cd/E16338_01/server.112/b65088/title.htm

Oracle Database Applianceによる

Oracle Data Guardの配置

2012年4月

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores,

CA 94065

U.S.A.

お問い合わせ窓口

Oracle Direct

0120-155-096

oracle.com/jp/direct

Copyright © 2012, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予

告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を

問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。

オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。

本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によって

も再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。0112

Intelおよび Intel Xeonは Intel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC

International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録

商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。

oracle database applianceによるoracle data guardの構成

Technology

current logfile disconnect

alter database flashback

sysdba sql

slcac458 sql

sql

dgmgrl

server dedicated

sqlplus