Oracle Database ApplianceによるOracle Data Guardのデプロイ

by user

on 28 марта 2017

Category: Documents

>> Downloads: 27

195

views

Report

Comments

Description

Download Oracle Database ApplianceによるOracle Data Guardのデプロイ

Transcript

Oracle Database ApplianceによるOracle Data Guardのデプロイ

Oracle Database Applianceによる
Oracle Data Guardのデプロイ
Oracle Database Applianceベア・メタルおよび仮想化プラットフォーム構成への適用
Oracleホワイト・ペーパー | 2015年1月
はじめに
Oracle Database Applianceは事前に構築、チューニングが行われ、すぐに使用可能なクラスタ化さ
れたデータベース・システムです。容易にデプロイ、操作、管理が行えるように最適に構成された
サーバー、ストレージ、ネットワーク、ソフトウェアが含まれます。Oracle Database Applianceは
規模を問わず、すべてが揃った理想的なデータベース・プラットフォームであり、世界トップのOr
acle Database、人気のOracle Real Application Clusters（Oracle RAC）データベース・オプション、
Oracle Clusterware、Oracle Automatic Storage Managementなどの強力で実績のあるOracleテクノ
ロジーが組み込まれています。Oracle Database Applianceではハードウェアとソフトウェアが統合
されているため、手作業で組み立てる非統合のソリューションに特有の複雑さを解消し、数週間か
ら数カ月かかっていたデプロイメントを数時間に短縮しました。構成や設定の誤りが原因で、最適
とは言えない、管理が困難なデータベース環境となるのを防ぎます。
スタンバイ・データベース環境が必要な理由
Oracle Database Applianceはそれ自体が可用性の高いシステムですが、スタンバイ・データベース
環境は計画停止時間および計画外停止時間に対する保護と同時に、プライマリ・データベース環境
が利用不能になった場合のデータ損失に対する保護を提供できます。また、適切なテクノロジーを
使用して、スタンバイ・データベースとプライマリ・データベースの同期を維持できるため、ユー
ザー・エラーからシステム障害、そして災害に至るまでの問題に対するシステム・パッチの適用な
どの計画的なメンテナンスの場合でも、データベースの運用をほぼ透過的に継続できます。このよ
うに、スタンバイ・データベースは、重要な本番システムの高可用性と保護を確保する上で常に鍵
となってきました。
オラクルでは、プライマリOracle Database Applianceシステムで動作するミッション・クリティカ
ルな本番システムに対応するスタンバイ・システムを独立した専用のOracle Database Applianceシ
ステムを使用してホストすることを推奨しています。
プライマリOracle Database Appliance
スタンバイOracle Database Appliance
図1 - 2つのOracle Database Applianceを使用したOracle Data Guardの設定
Oracle Data Guardを使用する理由
Oracle Data Guardがディザスタ・リカバリ・ソリューションとして推奨される理由は、Oracle Data
base Appliance上に配置されたデータベースを、データベースの"異常"または停止につながるデー
タベースまたはクラスタの障害、データ破損、災害、ユーザー・エラーから保護できるためです。
Oracle Data GuardとOracle Databaseの緊密な統合は、他のソリューションでは達成不可能な、これ
までにないレベルのデータ保護を実現します。Oracle Data Guardは、Oracle Database Enterprise E
ditionの一部として提供されます。Oracle Data Guardはデプロイメントが簡単で、1つ以上の同期コ
1
ピー（スタンバイ・データベース）を作成して維持するための管理、監視、および自動化を目的と
したソフトウェアを提供します。Oracle Data Guardを使用すると、何らかの理由で本番データベー
ス・システムが使用できなくなった場合に、データベースの可用性を容易に維持でき、また、計画
的な保守作業を実施している間の停止時間を、アプリケーションのワークロードをスタンバイ環境
に移行することによって最小限に抑えることができます。
Oracle Data Guardの使用によるさまざま利点
Oracle Data Guardを使用すれば、スタンバイ・データベース環境をアイドル状態にして無駄な容量
を確保する必要はありません。むしろ、スタンバイ・データベースは多くの有益な目的を果たすの
に非常に役立ちます。このような非常に多くの利点により、労力と投資の見返りとして得られる全
体的な収益を大幅に増大します。
Oracle Database Applianceへの移行 – 既存のデータベースをOracle Database Applianceに移行す
る場合、Oracle Data Guardを使用すれば、データベースをOracle Database Applianceに容易に移行
できます。Oracle Database Applianceでフィジカル・スタンバイ・データベースを設定するだけで、
古い環境から新しい環境にスイッチオーバーできます。これには、プラットフォーム間での移行も
含まれます。たとえば、現在Windowsで稼働しているデータベースをLinuxプラットフォームのOra
cle 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 Config
uration』を参照してください。
注：Oracle Data Guardを使用して、一時ロジカル・スタンバイ・データベースを使用してバージョ
ンの異なるデータベース間で移行を行うこともできます。
ディザスタ・リカバリ – Oracle Data Guardのフィジカル・スタンバイ・データベースは、災害対
策として理想的なソリューションです。災害のシナリオは、水道管や蒸気管の破裂、火災、ハリケ
ーン、破壊行為、地震、洪水、テロ行為に至るまでさまざまです。Oracle Data Guardのフィジカ
ル・スタンバイ・データベースは、保護データベースのコピーをブロック単位で保持します。何ら
かの理由によりプライマリ環境が利用できなくなった場合は、アプリケーションに対しデータベー
スの可用性を引き続き維持するために、スタンバイ環境をすばやくアクティブ化できます。
高可用性 – スタンバイ・データベースは、計画/計画外の停止/停止時間中の可用性を維持する上で
も有益です。このようなイベントには、構成変更、ハードウェア交換などのほか、データ破損、人
的エラーによる障害、その他の予期しないシステム・コンポーネントの障害や完全なシステム障害
などが含まれます。
データベース・ローリング・アップグレード – スタンバイ・データベースは、プライマリOracle
Database Applianceのパッチ・バンドルの適用と変更を行う場合の停止時間を最小限に抑えます。
パッチやその他の保守作業は、まずスタンバイ・データベースに適用して検証を行い、その後に本
番のワークロードがプライマリからスタンバイ・システムに切り替えます。データベースの停止時
間は、プライマリとスタンバイのロールを交換するのに必要な短い時間のみです。詳細については、
My Oracle Support（MOS）Note 1265700.1『Oracle Patch Assurance - Data Guard Standby-First Pat
ch Apply』を参照してください。
2
ワークロードとアクティビティのオフロード – スタンバイという名前が付いてはいますが、スタ
ンバイ環境をアイドル状態にする必要はありません。全体的な投資収益率を高めるために、積極的
に利用できます。フィジカル・スタンバイ・データベースを設置することで、いくつかの重要なア
クティビティをスタンバイ環境にオフロードできます。次にその例を挙げます。
•
読取り専用ワークロード – Oracle Active Data Guardオプションを使用すると、スタンバイ・デ
ータベースは読取り専用の問合せワークロードを受け付けることができ、スタンバイ・モードで
あってもプライマリ・データベースからのREDOログの更新を受け付けることができます。多く
の場合、読取り専用ワークロードをスタンバイ・データベースにオフロードすると本番ワークロ
ードを大幅に削減できるため、本番システムの全体的な処理能力が向上します。
•
バックアップ – Oracle Data Guardのフィジカル・スタンバイ・データベースはプライマリ・デ
ータベースのコピーをブロック単位で保持しているため、データベースのバックアップを完全に
スタンバイ環境にオフロードできます。したがって、障害またはデータベースの損失の発生時に、
これらのバックアップを透過的に使用して、プライマリ・データベースのリストアとリカバリを
行うことができます。Oracle Active Data Guardオプションのライセンスがある場合は、スタンバ
イ・データベースで高速増分バックアップが実行できるため、スタンバイ・データベースへのオ
フロード・バックアップ機能がさらに魅力的なものとなります。
•
ブロック修復 – フィジカル・スタンバイ・データベースのその他の利点として、ブロックが破損
した場合に自動リカバリが行える点が挙げられます。プライマリ/スタンバイ構成では、破損した
ブロックを自動的に修復でき、この操作はエンドユーザーおよびデータベース管理者に対して完
全に透過的に実行できます。ブロック修復機能もOracle Active Data Guardオプションの一部です。
スナップショット・スタンバイ – スナップショット・スタンバイ・データベースは、プライマ
リ・データベースの完全なデータ保護を実現する更新可能なスタンバイ・データベースです。この
データベースは、プライマリからのREDOデータを継続的に受信しますが、スタンバイ・データベ
ースがテスト用の読取り/書込みを受け付けている間は、適用プロセスが停止します。テストが完了
すると、1つのコマンドで、スタンバイ・データベースを元の状態に戻し、読取り/書込みモードで
受け付けている間に行われた変更を破棄し、蓄積されたREDOログを適用してプライマリ・データ
ベースと同じ最新の状態にします。
設定のベスト・プラクティス
このセクションでは、Oracle Database Appliance上でOracle Data Guardを設定する際の重要なベス
ト・プラクティスについていくつか説明します。Oracle Data Guardの一般的なベスト・プラクティ
ス（Oracle Database Appliance環境にも適用可能）の一覧については、『Oracle® Database High A
vailability Best Practices Guide 11g Release 2 (11.2)』の第8章「Configuring Oracle Data Guard」を
参照してください。
•
プライマリ・データベースとスタンバイ・データベースの構成を一致させる -- 一貫したサービ
ス・レベルを維持し、プライマリ・データベースとスタンバイ・データベースを透過的に使用す
るには、プライマリ・システムとスタンバイ・システムのリソース、設定、構成をできるだけ一
致させることが重要です。プライマリ・データベースとスタンバイ・データベースの構成が大き
く異なっていると、ロール移行の発生時に最善のパフォーマンスが得られないことや、想定外の
動作が発生することがあります。特に、以下の推奨事項を検討する必要があります。
3
o プライマリ・データベースとスタンバイ・データベースを独立したOracle Datab
ase Appliance上で実行 - プライマリ・データベースとスタンバイ・データベース
は、できれば地理的に離れた場所に設置された独立したOracle Database Appliance
装置上で実行させることを推奨します。
o プライマリ・データベースとスタンバイ・データベースを同じ構成内で実行 -- Or
acle Database Applianceでは、データベース構成としてOracle RACデータベース、
Oracle RAC One、およびSingle-Instance Enterprise Editionデータベースの3種類が
サポートされています。また、スタンバイ・データベースはプライマリ・データベ
ースと同じ構成タイプにする必要があります。したがって、プライマリ・データベ
ースをOracle RACデータベースとして構成する場合は、スタンバイ・データベース
もOracle RACデータベースとして構成する必要があります。
o プライマリ・インスタンスとスタンバイ・インスタンスで互いに類似した構成を
使用 -- プライマリ・データベースとスタンバイ・データベースのインスタンスは、
メモリ、CPU、ネットワーク、ストレージなどのデータベース・パラメータ設定に
ついて、相互に類似した構成にする必要があります。これにより、データベースの
ロールの切替え時に予測不可能な動作の発生を防止するのに役立ちます。また、オ
ペレーティング・システムの構成のカスタマイズを2つの環境でミラー化する必要
があります。
o ロール移行に対応できるようにプライマリ・データベースとスタンバイ・データ
ベースを事前に構成 -- プライマリ・データベースとスタンバイ・データベースは、
プライマリからスタンバイ、またスタンバイからプライマリへのロール移行中に、
要求される変更や必要な変更が最小限で済むように構成する必要があります。その
ため、プライマリ・データベースに実装されたすべてのデータベース機能とカスタ
マイズ項目は、事前にスタンバイ・データベースでも構成しておく必要があります。
•
プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベ
ースを構成 -- フラッシュバック・データベース機能は、ロール移行をすばやく行い、移行後に
データベースのロールを再設定するために必要な作業を軽減します。ベスト・プラクティスとし
て、プライマリ・データベースとスタンバイ・データベースの両方で、フラッシュバック・デー
タベースを構成する必要があります。
注：フラッシュバックをData Guard構成を再指定する目的でのみ使用する場合のベスト・プラクテ
ィスは、フラッシュバックの保存ターゲットをデフォルトの24時間から2時間に短縮することです。
•
スタンバイ・トラフィックに対応する専用ネットワークを使用 -- Oracle Database Applianceは
複数の冗長ネットワーク・インタフェースが事前に組み込まれた状態で出荷されます。必要に応
じて、スタンバイ・データベースのトラフィックに対応するための独立したネットワーク・パス
を作成して、ユーザーとアプリケーションに関連したワークロードのパフォーマンスに与える影
響を最小限に抑えることができます。Oracle Data Guardで必要なのは、プライマリ・データベー
スに対して行われた変更のみをプライマリ・データベースからスタンバイ・データベースに転送
することなので、ネットワークに必要以上の要件を強制するものではないことに注意してくださ
い。そのため、Oracle Data Guardのデプロイメントで、プライマリとスタンバイの間のREDOロ
グの転送のために独立したネットワーク・パスの確立が必要になることはそれほど多くありませ
ん。ただし、大容量のアプリケーションや組織のベスト・プラクティスや基準によっては、RED
Oログの転送用に独立したネットワーク・パスが必要になることもあります。このためにOracle
4
Database Applianceでは、各サーバー・ノードに対して追加のネットワーク・インタフェースを
提供しています。Oracle Database Applianceでのディザスタ・リカバリ用の専用ネットワークの
構成についての詳細は、MOS Note 1422563.1を参照してください。
•
特定のワークロードをスタンバイ・データベースにオフロードすることを検討 -- Oracle Recov
ery 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 Gua
rd用の以下のベスト・プラクティスが有益となる場合があります。
Client Failover Best Practices for Data Guard 11g
Release 2Active Data Guardのベスト・プラクティス
ロール移行のベスト・プラクティス
Maximum Availability Architectureホワイト・ペーパー：Preventing, Detecting, and Repairing Block
Corruption: Oracle Database 11g
Oracle DatabaseのMaximum Availability Architectureのベスト・プラクティスは以下で入手できます。
http://www.oracle.com/technetwork/jp/database/features/availability/maa-098142-ja.html
5
Oracle Database Applianceベア・メタルおよび仮想化プラットフォーム構成
Oracle Database Applianceはベア・メタル（非仮想化）プラットフォームまたは仮想化プラットフ
ォームとして構成できます。このホワイト・ペーパーに記載したOracle Data Guardのフィジカル・
スタンバイ設定プロセスは両方のOracle Database Appliance構成で使用できます。Oracle Database
Applianceの仮想化プラットフォームでは、構成手順はODA-BASEドメイン内で実行されます。また、
Oracle Database Applianceの仮想化プラットフォームで仮想LANを使用して、ディザスタ・リカバ
リ用に論理的に独立したネットワークを構成できます。
結論
Oracle Data GuardをOracle Database Appliancede使用すると、デプロイメントの初期段階から効果
的なディザスタ・リカバリ保護戦略をデプロイすることが可能になります。このホワイト・ペーパ
ーで説明したフィジカル・スタンバイの構成および設定プロセスはシンプルで、プライマリ・デー
タベースの停止時間を発生させることなく完了できます。スタンバイの作成手順の大部分は、Oracl
e Appliance Manager、Oracle Database Configuration Assistance（Oracle DBCA）、Oracle RMAN、
Oracle Data Guardなどのツールを使用することで自動化され、Oracle Database Applianceでスタン
バイ・データベースを設定する際に使用できます。このホワイト・ペーパーの付録Aには、参考の
ために完全な手順を示します。
6
付録A：Oracle Database Applianceでの設定例
サンプル環境
ここでは、後続のOracle Database Applianceを使用したData Guardの設定例で使用されるプライマ
リ・データベース環境およびスタンバイ・データベース環境のトポロジについて説明します。
図2 Oracle Database ApplianceでのOracle RACの構成トポロジ
プライマリOracle Database Appliance
スタンバイOracle Database Appliance
アプライアンス名
appliance#1
appliance#2
ホスト名
pnode1
クラスタ名
CLUSTER1
CLUSTER2
データベース名
Pdb
sdb
インスタンス名
pdb1
SCAN名とIP
pnode1-scan（10.1.27.2、10.1.27.3）
snode1-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
/u01/app/oracle/product/11.2.0.3/db_home1
/u01/app/oracle/product/11.2.0.3/db_home1
ARCHIVELOGモード
有効
有効
FORCE LOGGINGモード
有効
有効
pnode2
pdb2
snode1
sdb1
snode2
sdb2
ソフトウェアのインストール場所
Oracle Database
ソフトウェアのインストール場所
表1 - Oracle Databaseのネーミング規則の例
7
1. スタンバイREDOログの作成
スタンバイREDOログにはプライマリ・データベースから受け取ったREDOデータが記録されます。
オラクルは、Data Guard構成内のプライマリ・データベース上にスタンバイREDOログを作成して
おくことを推奨しています。これによって、スタンバイ・ロールにスイッチオーバーした後すぐに
REDOデータを受け取れる状態になります。
プライマリ・データベース上にスタンバイREDOログ（SRL）を作成します。スタンバイREDOログ
の各スレッドには、対応するオンラインREDOログのスレッドよりも少なくとも1つ多いREDOロ
グ・グループを割り当てる必要があります。次に例を示します。
$> sqlplus / as sysdba
SQL> alter database add standby logfile thread 1 group 9 size 1024M,
group 10 size 1024M, group 11 size 1024M, group 12 size 1024M,
group 13 size 1024M;
SQL> alter database add standby logfile thread 2 group 14 size
1024M, group 15 size 1024M, group 16 size 1024M, group 17 size
1024M, group 18 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モードの有効化
アーカイブとは、アクティブ・データベースのREDOログが循環式に上書きされる前に、アーカイ
ブ・ファイル形式でREDO情報を保存し、保護するプロセスのことです。Oracle Database Applianc
eで作成されたデータベースはデフォルトでアーカイブがオンになっています。しかし、データベ
ースをARCHIVELOGモードで実行することは必須ではありません。
プライマリ・データベースがARCHIVELOGモードで実行されていることを確認します。
SQL> archive log list
プライマリ/データベースがARCHIVELOGモードで実行されていない場合は、次のようにARCHIVELO
Gモードを有効にします。
8
Oracle Database Applianceで両方のインスタンスを停止します。
$ srvctl stop database –d pdb
1つのインスタンスを排他モードで起動し、マウントします。
SQL> startup mount exclusive;
アーカイブをオンにします。
SQL> alter database archivelog;
インスタンスを停止します。
SQL> shutdown immediate;
データベースを再起動します。
$ srvctl start database –d pdb
3. FORCE LOGGINGモードの有効化
FORCE LOGGINGを使用すると、NOLOGGING属性で実行されたデータベース操作を取得できます。
これにより、スタンバイ・データベースの整合性が確保されます。プライマリ・データベースでFO
RCE LOGGINGが有効化されていることを確認します。
SQL> select force_logging from v$database;
FORCE LOGGINGが有効化されていない場合は、次のコマンドで有効化します。
SQL> alter database force logging;
4. フラッシュバック・データベース機能の構成
Oracleフラッシュバック・データベース機能は未完了のデータベース・リカバリをすばやく行うた
めの代替方法を備えています。フラッシュバック・データベース機能の使用はオプションですが、
フェイルオーバーの後で、古いプライマリ・データベースの復元をすばやく行うためには非常に有
益です。そのため、スタンバイ・データベースへのフェイルオーバーを実行すると、古いプライマ
リ・データベースの修復が可能となり、古いプライマリ・データベースをスタンバイ・データベー
スとして再構築する必要はなく、フラッシュバックするだけで、それ以降Oracle Data Guardが再同
期するようになります。
プライマリ・データベースでフラッシュバック・データベース機能が有効化されているかどうかを
確認し、必要に応じて有効化します。
SQL> select flashback_on from v$database;
SQL> alter database flashback on;
9
フラッシュバック・データベース機能を有効化すると、ファスト・リカバリ領域（RECOディス
ク・グループ）の消費量が増加することに注意してください。フラッシュバック・ログによって使
用される領域は、パラメータ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'
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_UNI
QUE_NAME=sdb' scope=both sid='*';
REDOログ送信オプションについての詳細は、『Oracle Data Guard概要および管理』を参
照してください。
10
8. フェッチ・アーカイブ・ログ・サーバーの設定
データベースがスタンバイ・ロールで、プライマリ・データベースが欠落したログ・ファイルを送
信できない場合、スタンバイ・データベースはFAL_SERVER設定を使用してこれらの欠落したロ
グ・ファイルを取得できます。FAL_SERVERパラメータではOracle Netサービス名が使用されます。
SQL> alter system set FAL_SERVER=sdb scope=both sid='*';
スタンバイ環境の構成
このセクションではスタンバイ・データベースで実行する必要のある手順について説明します。ス
タンバイ環境でOracle Database Applianceシステムが設定されていることが前提となります。ベ
ア・メタルまたは仮想化プラットフォーム構成でのOracle Database Applianceの設定については、
『Oracle Database Appliance Setup Poster』を参照してください。URLは以下のとおりです。
http://docs.oracle.com/cd/E22693_01/doc.21/e41668.pdf
9. TNSエントリの設定
Oracle Netサービス名は、データベース間でREDO転送ができるように構成する必要があります。プ
ライマリ・データベースのtnsnames.oraファイルをスタンバイ・データベースのTNS別名エントリ
で更新します。Oracle Database Applianceでは、tnsnames.oraファイルはOracle Databaseホームの
network/adminディレクトリにあります。
PDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = primary-scan) (PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = pdb)))
SDB =
(DESCRIPTION =
(UT=A)
(ADDRESS = (PROTOCOL = TCP) (HOST = stanby-scan) (PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = sdb)))
10. 静的リスナー構成の作成
インスタンス化実行中にgridユーザーとして、スタンバイ・データベース上にRecovery Manager接
続用の静的リスナー・サービスを作成します。リスナー・ホームは、Grid Infrastructureのホーム
（/u01/app/11.2.0.3/grid/network/admin）にあることに注意してください。
11
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)))
11. リスナーの再起動
リスナーに変更を加えたら、リスナーを再起動する必要があります。
grid $> lsnrctl reload listener
12. 初期スタンバイ・パラメータ・ファイルの作成
スタンバイ・データベースのパラメータ・ファイル（$ORACLE_HOME/dbs/initsdb.ora）を作成し
ます。ORACLE_HOMEの環境変数が現在のホームを指していることを確認してください。次に例を
示します。
grid $> echo 'DB_NAME=sdb' > $ORACLE_HOME/dbs/initsdb.ora
13. パスワード・ファイルの作成
Oracle RMANの複製プロセス中に、補助インスタンスへのアクセスに使用するリモート認証のパス
ワード・ファイルを作成する必要があります。
oracle $> orapwd
file=/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/orapwsdb
password=<primary sysdba passwd>
14. 監査ディレクトリの作成
スタンバイ・データベースに監査ファイルの保存先ディレクトリを作成します。
$ mkdir –p /u01/app/oracle/admin/sdb/adump
15. スタンバイ・インスタンスの起動
NOMOUNT状態である最初のスタンバイ・ホスト上でスタンバイ・データベース・インスタンスを
起動して、インスタンス化の準備を行います。
$> export ORACLE_SID=sdb
$> sqlplus / as sysdba
SQL> startup nomount
12
16. ネットワーク接続の確認
この時点で、Oracle Netはプライマリ環境とスタンバイ環境の両方のTNS別名をスタンバイ環境か
ら解決できる必要があります。
$ tnsping pdb
$ tnsping sdb
$ sqlplus sys/<password>@//pnode1:1521/pdb as sysdba
スタンバイ・データベースのインスタンス化
このセクションでは、プライマリ環境とスタンバイ環境の設定が完了した後のスタンバイ・データ
ベースのインスタンス化について説明します。
17. データベースの複製
Oracle Recovery Managerを使用すると、DUPLICATE DATABASEコマンドでスタンバイ・データベー
スを作成できます。複製プロセスの一部として、パラメータ・ファイル、パスワード・ファイル、
制御ファイル、データベース・ファイルがプライマリ環境からスタンバイ環境にコピーされます。
スタンバイ操作に必要な適切なパラメータ設定の変更は、Oracle RMANのDUPLICATE DATABASEコ
マンドでも指定する必要があります。Oracle RMANによりプライマリのパラメータ・ファイルがコ
ピーされると、DUPLICATE DATABASEコマンドで指定したパラメータがそれに応じて変更されます。
パスワード・ファイルもコピーされるため、スタンバイ・データベースのパスワードはプライマ
リ・データベースと同じになります。
$rman
connect target sys/welcome1@//pnode1:1521/pdb
connect auxiliary sys/welcome1@//snode1:1521/sdb
run {
allocate channel p1 type disk;
allocate channel p2 type disk;
allocate channel p3 type disk;
allocate channel p4 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'
13
set audit_file_dest = '/u01/app/oracle/admin/sdb/adump'
set db_create_file_dest = '+DATA'
set log_archive_config="DG_CONFIG=(pdb,sdb)"
set diagnostic_dest="/u01/app/oracle"
set db_recovery_file_dest="+RECO"
set db_create_online_log_dest_1="+REDO"
set control_files="+DATA/sdb/control01.ctl"
set log_archive_dest_2 = 'service=pdb lgwr async register
valid_for=(online_logfiles, primary_role) db_unique_name=pdb'
set remote_listener = 'standby-scan:1521'
set fal_server='pdb'
nofilenamecheck;
}
18. フラッシュバック・データベースの有効化
スタンバイ・データベースでフラッシュバック・データベースを有効化し、必要に応じて保存期間
を調整します。次に例を示します。
SQL> alter database flashback on;
SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=120;
19. スタンバイのspfileをASMに移動
スタンバイのspfileをローカル・ファイル・システムからスタンバイ・データベースのAutomatic St
orage Management（ASM）に移動します。
$ export ORACLE_SID=sdb
RMAN> connect target /
RMAN> backup spfile;
RMAN> restore spfile to ‘+DATA/sdb/spfilesdb.ora’;
20. 管理リカバリ・モードの開始
次のように、スタンバイ・データベースでの管理リカバリをリアルタイム・モードで開始します。
SQL> alter database recover managed standby database disconnect;
14
または、次のように非リアルタイム・モードで管理リカバリ・モードを開始します。
SQL> alter database recover managed standby database using current l
ogfile disconnect;
リアルタイム適用ではREDO適用サービスは、現在のスタンバイREDOログがアーカイブされるのを
待たずに、受信したらすぐにREDOログをスタンバイ・データベースに適用できます。そのため、
スタンバイREDOログ・ファイルはフェイルオーバーまたはスイッチオーバーが発生した時点です
でに適用されているため、フェイルオーバーとスイッチオーバーの時間が短縮されます。
インスタンス化後の手順
以下の手順は、スタンバイ・データベースのインスタンス化の完了後に実行します。
21. Oracle Clusterwareによるスタンバイ・データベースの登録
ORACLE_HOME環境変数が正しく設定されていることを確認します。Oracle Clusterwareを使用して、
クラスタの1つのノードから実行されるシングル・インスタンスとしてスタンバイ・データベース
を登録します。
Active Data Guard以外の構成の場合：
$ srvctl add database –d sdb –o $ORACLE_HOME –p
"+DATA/sdb/spfilesdb.ora" –r physical_standby –s mount -c SINGLE –
x snode1
Active Data Guard構成の場合：
$ srvctl add database –d sdb –o $ORACLE_HOME –p
"+DATA/sdb/spfilesdb.ora" –r physical_standby –s 'read only' -c
SINGLE -x snode1
1. Oracle RACへのスタンバイ・データベースの変換
この手順は任意です。この段階では、スタンバイ・データベースはシングル・インスタンス・デー
タベースとして構成されています。プライマリ・データベースがOracle RACデータベースであった
場合、スタンバイ・データベースもOracle RACスタンバイに変換できます。rconfigツールを使用し
てシングル・インスタンス・データベースをOracle RACスタンバイ・データベースに変換する方法
については、付録Bを参照してください。
2. Data Guard Broker構成の設定
この手順は任意です。Data Guard Broker構成を作成すると、Data Guard環境全体を単一のエンティ
ティとして容易に管理できます。この構成はローカルとリモートの両方で使用可能な管理機能、保
守機能、監視機能を提供します。Data Guard Broker構成の設定についての詳細は、付録Cを参照し
てください。
15
3. 専用のDRネットワークの設定
この手順は任意です。REDO転送サービスを構成すると、専用のネットワークを使用できます。専
用のネットワーク・チャネルは、特にアプリケーションのネットワーク・トラフィックによってパ
ブリック・ネットワークで使用可能な帯域幅の大部分が消費されている場合に、REDO送信のパフ
ォーマンスを向上させるのに役立ちます。Data GuardのREDO転送用に専用のネットワーク・チャ
ネルを設定する方法については、MOS Note 1451810.1『Configuring Dedicated Disaster Recovery
Network on Oracle Database Appliance』を参照してください。
4. 構成と設定の確認
スタンバイ・データベースで内部データ・ディクショナリ・ビューを使用して、スタンバイ・デー
タベースの動作を確認できます。
$ 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#;
16
付録B：シングル・インスタンス・データベースからOracle RACへの変換
rconfigコマンドライン・ユーティリティを使用して、シングル・インスタンス・データベースをOr
acle RACデータベース、またはOracle RAC One Nodeに変換できます。
この機能を使用するには、次の手順を実行します。
構成XMLファイルの作成
convert.xmlとして保存する構成XMLファイルの例を以下に示します。このファイルは、システムで
の必要に応じて変更できます。
サンプルXMLファイルは$ORACLE_HOME/assistants/rconfig/sampleXMLディレクトリに格納されて
います。
注：変換が正しく行えることを確認するため、最初に変換オプションConvert verify="ONLY"を設定
してテスト変換を実行してください。
<?xml version="1.0" encoding="UTF-8"?>
<n:RConfig xmlns:n="http://www.oracle.com/rconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/rconfig
rconfig.xsd">
<n:ConvertToRAC>
<n:Convert verify="YES">
<n:SourceDBHome>/u01/app/oracle/product/11.2.0.4/dbhome_1</n:SourceDBH ome>
<n:TargetDBHome>/u01/app/oracle/product/11.2.0.4/dbhome_1</n:TargetDBH ome>
<n:SourceDBInfo SID="sdb">
<n:Credentials>
<n:User>sys</n:User>
<n:Password>welcome1</n:Password>
<n:Role>sysdba</n:Role>
</n:Credentials>
</n:SourceDBInfo>
<n:NodeList>
<n:Node name="stanby-node1"/>
<n:Node name="standby-node2"/>
17
</n:NodeList>
<n:InstancePrefix>sdb</n:InstancePrefix>
<n:SharedStorage type="ASM">
<n:TargetDatabaseArea></n:TargetDatabaseArea>
<n:TargetFlashRecoveryArea></n:TargetFlashRecoveryArea>
</n:SharedStorage>
</n:Convert>
</n:ConvertToRAC>
</n:RConfig>
rconfigツールの実行
変更が完了したら、ファイルを保存します。スタンバイ・データベースで次のコマンドを実行します。
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
18
付録C：Oracle Data Guard Broker構成の作成
このセクションでは、Oracle Data Guard Broker構成のプロセスを説明します。
静的登録を行うためのリスナーの構成
プライマリ・データベースとスタンバイ・データベースのすべてのインスタンスを静的に登録する
ためのリスナーを構成します。Oracle Database Applianceでは、リスナーはGrid Infrastructureホー
ムから実行されます。Oracle RACのプライマリ/スタンバイ構成の静的登録の例を以下に示します。
ノードpnode1：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = pdb_DGMGRL)
(ORACLE_HOME =
/u01/app/oracle/product/11.2.0.4/dbhome_1)
(SID_NAME = pdb1)))
ノードpnode2：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = pdb_DGMGRL)
(ORACLE_HOME =
/u01/app/oracle/product/11.2.0.4/dbhome_1)
(SID_NAME = pdb2)))
ノードsnode1：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = sdb_DGMGRL)
(ORACLE_HOME =
/u01/app/oracle/product/11.2.0.4/dbhome_1)
(SID_NAME = sdb1)))
ノードsnode2：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = sdb_DGMGRL)
19
(ORACLE_HOME =
/u01/app/oracle/product/11.2.0.4/dbhome_1)
(SID_NAME = sdb2)))
Data Guard Broker構成ファイルの設定
プライマリ・データベースとスタンバイ・データベースの両方でData Guard Broker構成ファイルの
格納場所を設定します。
ノードpnode1：
SQL> ALTER SYSTEM SET
DG_BROKER_CONFIG_FILE1='+DATA/BROKER/DR1.DAT'
SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET
DG_BROKER_CONFIG_FILE2='+RECO/BROKER/DR2.DAT'
SCOPE=BOTH SID='*';
ノードsnode1：
SQL> ALTER SYSTEM SET
DG_BROKER_CONFIG_FILE1='+DATA/BROKER/DR1.DAT'
SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET
DG_BROKER_CONFIG_FILE2='+RECO/BROKER/DR2.DAT'
SCOPE=BOTH SID='*';
Data Guard Brokerの有効化
プライマリ・データベースとスタンバイ・データベースの両方でData Guard Brokerを有効化します。
ノードpnode1：
SQL> ALTER SYSTEM SET DG_BROKER_START='TRUE' SCOPE=BOTH
SID='*';
ノードsnode1：
SQL> ALTER SYSTEM SET DG_BROKER_START='TRUE' SCOPE=BOTH
SID='*';
Data Guard Broker構成の作成
プライマリ・データベースのDB_UNIQUE_NAMEとそれに対応するTNS別名を使用して、プライマ
リでData Guard Broker構成を作成します。
20
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;
21
参考資料
OTNのOracle Database ApplianceのWebサイト
http://www.oracle.com/technetwork/jp/server-storage/engineered-systems/database-appliance/in
dex.html
OTNのOracle Real Application ClustersのWebサイト
http://www.oracle.com/technetwork/jp/database/options/clustering/overview/index.html
OTNのOracle ClusterwareのWebサイト
http://www.oracle.com/technetwork/jp/database/clusterware/overview/index.html
OTNのOracle Data GuardのWebサイト
http://www.oracle.com/technetwork/jp/database/options/active-data-guard/overview/index.html
Oracle Maximum Availability Architecture
http://www.oracle.com/technetwork/jp/database/features/availability/maa-098142-ja.html
『Oracle Data Guard概要および管理11gリリース2（11.2）』
http://docs.oracle.com/cd/E11882_01/server.112/e25608/toc.htm
My Oracle Support（MOS）Note 1075908.1
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1075908.1
OTNのOracle Database高可用性のWebサイト
http://www.oracle.com/technetwork/jp/database/features/availability/index.html
『Oracle® Database高可用性ベスト・プラクティス11gリリース2（11.2）』
http://docs.oracle.com/cd/E11882_01/server.112/e10803.pdf
22
Oracle Corporation, World Headquarters
海外からのお問い合わせ窓口
500 Oracle Parkway
電話：+1.650.506.7000
Redwood Shores, CA 94065, USA
ファクシミリ：+1.650.506.7200
CONNECT WITH US
blogs.oracle.com/oracle
facebook.com/oracle
twitter.com/oracle
oracle.com
Copyright © 2014, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載さ
れている内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述によ
る明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の
保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接
的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いか
なる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPA
RC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Device
sの商標または登録商標です。UNIXは、The Open Groupの登録商標です。0115
ホワイト・ペーパー・タイトル：Oracle Database ApplianceによるOracle Data Guardのデプロイ
2015年1月
著者：Ramasubramanian Athmanathan, Ravi Sharma
共著者：Oracle RAC Pack
Oracle Database ApplianceによるOracle Data Guardのデプロイ、Oracleホワイト・ペーパー