Embed Size (px)
Citation preview
Oracle Cloudでのディザスタ・リカバリ 本番とDRをクラウドで
Oracleホワイト・ペーパー | 2016年7月
Oracle Public Cloudでのディザスタ・リカバリ
目次 はじめに 1 Data GuardおよびActive Data Guardによるクラウドでの ディザスタ・リカバリ 2 Oracle CloudでのDRの有効化 2
スタンバイ・データベースをインスタンス化するための方法 3 DRの準備状況の検証 4 スタンバイ・データベースの使用による計画メンテナンス時の
停止時間の短縮 4 サービス・レベル要件 5 セキュリティ要件 6 Data Guardの実行時監視 6 MAAのデプロイメントおよび実行する操作手順 8 Oracle Cloud ServiceのMAA事例 10
操作手順 11 サイト停止のテストと結果 12 結論 12 付録A：事例詳細 13
プライマリ・サイトのセットアップ 13 手順：Data Guardでのプライマリ・サイトの準備 16 手順：セカンダリ・サイトのセットアップ 20 手順：サイト・テスト 33 手順：スタンバイへのサイト・テスト 33 手順：スイッチオーバー 33 手順：フェイルオーバー 34 手順：スタンバイの復旧 35
付録B ‒ Data Guardのヘルス・チェック 36 付録C ‒ Data Guardの実行時監視問合せ 37
Oracle Public Cloudでのディザスタ・リカバリ
付録D ‒ ヘルス・チェックの問合せ 40 付録E ‒ クライアント・フェイルオーバーの構成 43 付録F ‒ ウォレットの作成と分散 43 付録G ‒ Database Backup Cloud Serviceからのスタンバイのインスタンス化 46
1 | Oracle Public Cloudでのディザスタ・リカバリ
はじめに Oracle Maximum Availability Architecture（MAA）はベスト・プラクティスのブループリントで、Oracleにおける実証済みの高可用性テクノロジー、専門家による推奨事項、およびカスタマー・エクスペリエンスに基づいています。MAAの目的は、プライベート・クラウド、パブリック・クラウド、およびハイブリッド・クラウド上で、コストと複雑さを最小限に抑えながら最適な高可用性を実現することです。Oracle Data GuardおよびOracle Active Data Guardは、バックアップからリストアする方法ではリカバリ時間目標（RTO）を達成できないデータベースに対して、ディザスタ・リカバリ（DR）を実行できるようにします。これらのソリューションを使用して本番データベース（プライマリ・データベース）の1つまたは複数の同期レプリカ
（スタンバイ・データベース）を物理的に別々の場所にアプリケーション層とともにデプロイすると、高可用性、包括的なデータ保護、ミッション・クリティカルなデータのディザスタ・リカバリを実現できます。
Data GuardスタンバイまたはActive Data Guardスタンバイのどちらをクラウドにデプロイするかは、要件に基づいて選択できます。クラウドDR構成には固有の考慮事項がいくつかありますが、この構成にも他のData Guardデプロイメントと同じOracle MAAベスト・プラクティスが適用されます。このOracle MAAブループリントでは、Oracle MAAベスト・プラクティスについて詳しく説明するとともに、Java Cloud ServiceおよびDatabase Cloud Serviceを使用してOracle CloudにDRをデプロイする手順概要について、事例を用いて説明します。このホワイト・ペーパーは、Oracle WebLogic Server、Oracle Database、Data GuardまたはActive Data Guard、およびOracle Databaseのバックアップとリカバリに関する知識を持っている技術者を対象にしています。また、Oracle Cloud1で利用できるサービスに関して基本知識を持っていることを前提としています。
このホワイト・ペーパーに示している手順概要と事例は、地理的に離れたクラウド・データセンターにそれぞれ関連付けられた2つの別々のアイデンティティ・ドメインにデプロイされる、プライマリ・データベース、スタンバイ・データベース、および冗長アプリケーション層の手動デプロイメントに対応しています。この手順は、Oracle Database Cloud Service用に最近導入された新しいツールを使用した、Data GuardまたはActive Data Guardの自動デプロイメントには適用されません（Exadata Serviceと同様の自動化が将来的に提供される予定です）。自動化ツールを使用したデプロイメントのOracle MAAベスト・プラクティスは現在作成中であり、提供可能になった時点でOracle Technology Networkに公開される予定です。
事例では、永続的な状態はすべてデータベース内に格納されることを前提としているため、その他の状態をセカンダリ・サイトにレプリケートする必要はありません。
1 https://cloud.oracle.com/ja_JP/home
2 | Oracle Public Cloudでのディザスタ・リカバリ
Data GuardおよびActive Data Guardによるクラウドでの ディザスタ・リカバリ Oracle Cloud 2では、具体的な顧客要件に合わせて調整したさまざまなクラウド・サービス・セットをPlatform as a Service（PaaS）、Infrastructure as a Service（IaaS）、およびSoftware as a Service（SaaS）として提供しています。データセンター間のディザスタ・リカバリ（DR）は、Oracle Database Cloud ServiceまたはExadata Service（PaaS）を使用してデプロイします。
Oracle Database Cloud Serviceを使用してクラウドでDRを実現するオプションには、次の2種類があります。
» Enterprise Edition ServiceまたはHigh Performance Serviceを利用するData Guard
» Extreme Performance ServiceまたはExadata Serviceを利用するActive Data Guard
Data GuardはOracle Database Enterprise Editionに付属しており、Oracle Database Cloud ServiceのすべてのEnterprise Edition（Enterprise、High Performance、Extreme Performance）およびExadata Serviceでサポートされています。
Active Data GuardはData Guardの機能を拡張したもので、データ保護および可用性を目的とした高度な機能のほか、読取り専用ワークロードやバックアップを本番データベースからオフロードする機能も備えています。Active Data GuardはExtreme Performance Database Cloud ServiceおよびExadata Serviceに含まれています。プライマリとスタンバイの両方のサービスを、Extreme Performance Database Cloud ServiceまたはExadata Serviceを使用してプロビジョニングする必要があります。Active Data Guardでのライセンス対象の機能について、詳しくはOracleソフトウェアのライセンスに関するドキュメント3を参照してください。
特に記載がない限り、このホワイト・ペーパーで説明している手順はData GuardとActive Data Guardの両方に適用されます。Data GuardおよびActive Data Guardについて、詳しくはOracle Technology NetworkのData GuardホームページおよびActive Data Guardのホワイト・ペーパー4を参照してください。
このホワイト・ペーパーに示している手順概要と事例は、地理的に離れたクラウド・データセンターにそれぞれ関連付けられた2つの別々のアイデンティティ・ドメインにデプロイされる、プライマリ・データベース、スタンバイ・データベース、および冗長アプリケーション層の手動デプロイメントに対応しています。この手順は、Oracle Database Cloud Service用に最近導入された新しいツールを使用した、Data GuardまたはActive Data Guardの自動デプロイメントには適用されません。自動化ツールを使用したデプロイメントのOracle MAAベスト・プラクティスは現在作成中であり、提供可能になった時点でOracle Technology Networkに公開される予定です。
Oracle CloudでのDRの有効化 クラウドでDRを有効化するには、Oracle Database Cloud ServiceでData Guardスタンバイ・データベースをインスタンス化する必要があります。インスタンス化すると、Data Guardによってプライマリ・データベースとスタンバイ・データベースの同期が維持されます。
2 http://www.oracle.com/jp/cloud/overview/index.html 3 https://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC141 4 http://www.oracle.com/technetwork/jp/database/availability/active-data-guard-wp-12c-1896127-ja.pdf
3 | Oracle Public Cloudでのディザスタ・リカバリ
Oracle Cloudは、プライマリ・サイトが何らかの理由で使用できなくなった場合に、ディザスタ・リカバリに必要となるすべてのバックエンド・インフラストラクチャと機能を備えています。次のような機能を備えています。
1. スタンバイ・データベースを監視し、大きな問題が発生したときにアラートを発行する機能。
2. スタンバイをアクティブ化し、DRの準備状況を検証してから、同期された状態にスタンバイを戻す機能。
3. オンプレミスのデプロイメントと同じOracle MAAベスト・プラクティスの利用。このホワイト・ペー
パーで説明しているクラウド・デプロイメントに固有のOracle MAAベスト・プラクティスの使用。
4. 計画メンテナンスや計画外停止のときに、本番データベースをクラウド内のスタンバイ・データベース
にスイッチオーバー（計画イベント）またはフェイルオーバー（計画外イベント）する機能。障害が発
生したプライマリ・データベースが修復されたら、自動的にクラウド内の新しい本番データベースと再
同期させて、本番データベースを元のデータベース・サービスにスイッチバックする機能。
5. サイトが完全に停止した場合に、アプリケーション層とデータベース層の両方をフェイルオーバーさせ、
Oracle Cloud内で本番アプリケーションを実行できるようにする機能。
6. Oracle Cloud内のスタンバイ・データベースをディザスタ・リカバリ以外のユースケースにも使用でき
る柔軟性。たとえば、読取り専用の本番ワークロードをクラウドにオフロードする、開発やテストに使
用する、シン・プロビジョニングされたデータベース・クローンのソースとして利用する、バックアッ
プをクラウドにオフロードするなどの目的に利用できます（図1を参照）。
図1：Oracle Public Cloudでのディザスタ・リカバリ
スタンバイ・データベースをインスタンス化するための方法 クラウド内でData Guardスタンバイをインスタンス化するには、次のいずれかの方法を使用します。
プライマリ・データベースから複製する
プライマリの本番データベースを使用してスタンバイ・データベースをインスタンス化します。「手順：セカンダリ・サイトのセットアップ」に、アクティブなオンプレミス・プライマリ・データベースからスタンバイをインスタンス化するための詳細な手順を示しています。
4 | Oracle Public Cloudでのディザスタ・リカバリ
Oracle Database Backup Cloud Serviceからリストアする
Oracle Database Backup Cloud Service5に格納されている本番データベース・バックアップを使用し、RMANのrestoreコマンドとrecoveryコマンドでスタンバイ・データベースを作成できます。バックアップからのリストアには、同じパスワードまたはTDEキーが必要です。
DRの準備状況の検証 ベスト・プラクティスは、Active Data Guardを使用して読取り専用ワークロードをスタンバイ・データベースにオフロードし、スタンバイが本番稼働できる状態になっていることをアプリケーションレベルで絶え間なく検証することです。こうすることで、Data Guardの適用プロセスで絶えず実行されるOracleブロックレベルの検証に加えて、確実度が1段階上がります。
また、スタンバイを定期的に読取り/書込みモード（Data Guardスナップショット・スタンバイを使用）にし、読取り/書込みの本番ワークロードをサポートできる状態になっていることを検証することもベスト・プラクティスです。DRシステムは本番システムと同様にサイジングされることが多いため、本番前の最終段階のパッチ/アップグレードの機能テストおよびパフォーマンス・テストにもスナップショット・スタンバイを使用できます。REDOがプライマリ・データベースからスナップショット・スタンバイに継続的に送信され、後の使用に備えてそこでアーカイブされるため、データは常に保護されます。ただし、テスト中にフェイルオーバーが必要になった場合は、スナップショット・スタンバイをスタンバイ・データベースに戻すために要する時間の分だけリカバリ時間（RTO）が長くなります。スタンバイがスナップショット・モードの場合は、ファスト・リカバリ領域として追加のストレージが必要です（プライマリの本番データベースから受信したREDOを後の使用に備えてアーカイブし、スナップショット・スタンバイで生成された最新のREDOログとフラッシュバック・ログを保持するため）。Data Guardスナップショット・スタンバイについて、詳しくはOracleのドキュメント6を参照してください。
必要に応じて、エンドツーエンドの全体的なDRテストとして、クラウドに対して実際にスイッチオーバー操作またはフェイルオーバー操作を実行できます。
スタンバイ・データベースの使用による計画メンテナンス時の停止時間の短縮 クラウド上のスタンバイ・データベースを利用してプライマリの本番データベースの計画停止時間を短縮する方法として、いくつかのオプションが用意されています。
Standby-first Patch Apply
徹底的に検証するために、多くのパッチを最初にフィジカル・スタンバイに適用できます。停止時間を最小限に抑えたい場合は、最初スタンバイにパッチを適用し、本番をスタンバイ・データベースに切り替えてから、元のプライマリにパッチを適用することが多いです。パッチがStandby-firstの対象である場合（パッチのREADMEに記載）は、異なるパッチ・バージョンで実行されているプライマリとスタンバイに対してData Guardの物理レプリケーションを実行できます。また、パッチによって予期しない問題が発生した場合に、パッチを適用していないバージョンへ高速にフォールバックできるように、一定期間はプライマリとスタンバイを異なるパッチ・バージョンで実行させることもできます。Standby-firstプロセスの対象となるパッチについて、詳しくは、My Oracle Support Note 1265700.1『Oracle Patch Assurance - Data Guard Standby-First Patch Apply7』を参照してください。
5 https://cloud.oracle.com/ja_JP/database_backup 6 https://docs.oracle.com/cd/E57425_01/121/SBYDB/manage_ps.htm#BACIEJJI 7 https://support.oracle.com/epmos/faces/DocumentDisplay?id=1265700.1
5 | Oracle Public Cloudでのディザスタ・リカバリ
データベース・ローリング・アップグレード
Oracle Cloudのスタンバイのもう1つの有益なユースケースとして、新しいデータベース・パッチセットへのアップグレードやOracleリリース全体のアップグレードを行うときに、停止時間を短縮するためにデータベース・ローリング・アップグレードに使用するということがあります。一時ロジカル・プロセスをOracle 11gおよびOracle 12cで使用し、フィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイに変換し、ロジカル・スタンバイを新しいバージョンにアップグレードして検証を実施した後、準備ができたらData Guardスイッチオーバーを実行します。スイッチオーバーが完了したら、元のプライマリ・データベースを、同じく新しいリリースで動作している同期済みのフィジカル・スタンバイに変換します。詳しくは、Oracle 11gの『Database Rolling Upgrades Made Easy』8または「Oracle 12c DBMS_Rolling」9を参照してください。
サービス・レベル要件 管理者は、可用性、データ保護、およびパフォーマンスについて、所定の構成およびアプリケーションで現実味のあるサービス・レベル予測を決定する必要があります。サービス・レベルを設定する必要があるのは、ディザスタ・リカバリに関連する次の3つの各領域であり、これらはすべてのData Guard構成に該当します。
» 可用性：リカバリ時間目標（RTO）は、停止が発生した場合に許容できる最大停止時間を表します。これには、停止を検出するのにかかる時間と、サービスを再開するようにデータベースとアプリケーションの両方の接続をフェイルオーバーさせるのにかかる時間が含まれます。
» データ保護：リカバリ・ポイント目標（RPO）は、許容できる最大データ損失量を表します。望ましいRPOを達成できるかどうかは、次の要因に左右されます。
» ネットワーク・トラフィック量に対する、使用可能な帯域幅
» 中断のない安定した送信を提供するための、ネットワークの能力
» 使用するData Guard転送方式（データ損失をほぼゼロに抑える非同期方式、またはデータ損失をゼロに抑える同期方式のいずれか）
» パフォーマンス：スタンバイ・システムの計算能力、メモリ、I/Oなどの能力がプライマリ・システムより劣っていると、フェイルオーバー後にデータベースの応答時間が変わる場合があります。これが発生するのは、コストを削減するために管理者が意図的に少ないリソースでスタンバイ・システムを構成し、DRモードの間はサービス・レベルが低下することを容認している場合です。Oracle MAAベスト・プラクティスでは、フェイルオーバー後も応答時間が変わらないようにするために、プライマリとスタンバイの両方の容量が同じになるように構成することを推奨しています。クラウドでは迅速にプロビジョニングできるため、安定状態では容量を少なめにデプロイし、フェイルオーバーが必要になった場合は新しいプライマリを迅速にスケールアップするという中間的な方法が可能です。
注：DRに関連するサービス・レベルに関係なく、Oracleクラウドで作成されるすべてのデータベース・インスタンスは、該当するDatabase Cloud Service10で定義されているサービス・ディスクリプションに準拠します。
8 http://www.oracle.com/technetwork/jp/database/maa-wp-11g-upgrades-made-easy-326438-ja.pdf 9 https://docs.oracle.com/cd/E57425_01/121/SBYDB/dbms_rolling_upgrades.htm 10 http://www.oracle.com/us/corporate/contracts/paas-iaas-public-cloud-2140609.pdf
6 | Oracle Public Cloudでのディザスタ・リカバリ
セキュリティ要件 Oracle MAAベスト・プラクティスでは、プライマリ・データベースおよびスタンバイ・データベースをOracle Transparent Data Encryption（TDE）で暗号化することを推奨しています。TDEに変換すると、すべてのDATA/INDEX表領域に暗号化が自動的に適用され、クラウドへのレプリケーション時にはユーザー・データのREDO変更に暗号化が適用されます。TDEで暗号化されていない他のREDO変更（SYSTEMやSYSAUXなどの暗号化されていない表領域のデータなど）にも移動時暗号化を適用するには、Oracle Netも暗号化する必要があります。
注：Data GuardおよびActive Data GuardではREDOベースのレプリケーションが使用されます。これは、プライマリ・データベースで生成されたREDOの送信とスタンバイ・データベースへの変更適用を、Oracleメディア・リカバリを使用して実行するプロセスです。つまり、プライマリ・データベースとスタンバイ・データベースは、ブロック単位で互いにまったく同じコピーとなります。スタンバイ・データベースをTDEで暗号化する場合は、プライマリ・データベースもTDEで暗号化する必要があります。
TDEによるデータ保護は、システムのセキュリティを強化する上で重要な部分です。ただし、どの暗号化ソリューションを使用する場合でも、次のような考慮事項があることを認識しておく必要があります。
» CPUオーバーヘッドの増加：暗号化する場合は、暗号化された値および複合化された値を計算するために追加のCPUサイクルが必要です。ただし、TDEは、データベース・キャッシュ機能を利用したりインテルCPUおよびSPARC CPUに搭載されているAESのハードウェア・アクセラレーションを活用することで、オーバーヘッドを最小にするように最適化されています。ほとんどのTDEユーザーでは、TDEを有効化した後も、本番システムのパフォーマンスへの影響がほとんど見られていません。パフォーマンス・オーバーヘッドが懸念される場合は、『Oracle Database Advanced Securityガイド』11を参照してください。
» データ圧縮率の低下：元のプレーン・テキスト・データに関する情報が一切明かされないため、暗号化されているデータはほとんど圧縮されません。そのため、TDEで暗号化されたデータにどのような圧縮を適用しても、圧縮率は低くなります。したがって、TDE暗号化を使用する場合は、REDO転送の圧縮は併用しないでください。ただし、Oracle Advanced CompressionやHybrid Columnar CompressionといったOracleデータベースの圧縮テクノロジーとTDEを併用する場合は、暗号化の前に圧縮が実行されるため、圧縮と暗号化の両方の利点が得られます。
» 鍵の管理：暗号化の強度は、暗号化に使用する鍵と同程度しかありません。また、暗号化鍵を失うことは、その鍵で保護されているすべてのデータを失うことと同じです。暗号化を有効にしているデータベースの数が少なければ、鍵とそのライフサイクルを追跡するのは比較的容易です。しかし、暗号化データベースの数が増えるにつれて、鍵の管理は徐々に難しい課題になっていきます。大量の暗号化データベースを所有している場合は、オンプレミスのOracle Key Vault12を使用してTDEのマスター鍵を格納および管理することを推奨します。
Data Guardの実行時監視 Data Guard構成の実行時ステータスを監視する方法として、コマンドラインによる問合せとEnterprise Manager Cloud Controlの2つのオプションが用意されています。
11 https://docs.oracle.com/cd/E49329_01/network.121/b71313/asotrans_faq.htm#sthref252 12 http://www.oracle.com/us/products/database/security/key-vault/overview/index.html
7 | Oracle Public Cloudでのディザスタ・リカバリ
オプション1：コマンドラインによる監視
管理者が設定したデータ保護（RPO）と可用性（RTO）のサービス・レベルをハイブリッドDR構成で確実に満たすには、監視とアラート発行が必要です。
Data Guard構成の実行時の状態に関わる次の重要な側面を監視する一連の問合せについては、「付録C ‒ Data Guardの実行時監視問合せ」を参照してください。
» 転送ラグ
» 適用ラグ
» プライマリ/スタンバイ接続のステータス
» Data Guard全体のステータスとロール移行の準備状況
管理者は、構成の監視を自動化するスクリプトを作成し、値がサービス・レベルしきい値を超えたらアラートが送信されるようにする必要があります。Enterprise Manager 12cを使用する場合は、このような手動作業は必要ありません。
オプション2：Enterprise Manager 12cまたは13
Oracle Enterprise Manager 12cまたは13は、クラウドのライフサイクル全体にわたって複雑な管理タスクを効率化および自動化します。
Oracle Cloudのサービスを提供するOracle Cloud仮想ホストに管理エージェントをデプロイすることにより、Oracle Cloudターゲットを他のターゲットと同様に管理できます。管理エージェントとオンプレミスのOracle管理サービス・インスタンスとの間の通信が外部から干渉される恐れはありません（Enterprise Manager Cloud Control 12c Release 1 （ 12.1.0.5 ） 以 上 が 必 要 で す ） 。 Oracle Database お よ び Fusion Middleware PaaSのターゲットの管理サポートに加え、Oracle Cloud仮想ホスト上のJVMの監視用にJVMDのサポートも提供されます。
Oracle Cloud Managementには以下の機能が含まれます。
» 自動化されたエージェントのデプロイおよび構成
» データベースおよびJavaのPaaSインスタンスの監視
» 通知とチケット発行の統合を含むインシデント管理
» 検索とインベントリ、オンプレミス・インスタンスとクラウド・インスタンス間の比較、構成履歴、コンプライアンスなどの構成管理
» オンプレミスとOracle Cloud間のクローニング
» Oracle Cloudデータベース・インスタンスのワンオフ・パッチ適用
Enterprise Managerを使用すると、シンプルなインタフェースでData Guard環境の次のような側面を監視および管理できます。
» Data Guardのステータス
» 転送ラグ
» 適用ラグ
» データベース・ロール移行の推定所要時間
» プライマリまたはスタンバイがアクセス可能かどうか
8 | Oracle Public Cloudでのディザスタ・リカバリ
任意のイベントを通知したり、上記メトリックが所定のしきい値を超えた場合に通知したりするように、アラートをカスタマイズできます。詳しくは、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
MAAのデプロイメントおよび実行する操作手順 このホワイト・ペーパーでは、出発点としてプライマリ・データベースとアプリケーションが稼働中であることを前提としており、地理的に分散されたデュアル・サイトのDR構成に移行することを目的としています。
以下の図に、デプロイメントを最初の単一サイトの実装から、セットアップ、テスト、最終的なデュアル・サイトMAAデプロイメントと進めるにつれて通過する状態を示します。システムの構成は状態ごとに固有となるため、次の状態に移るためには一連の手順を実行する必要があります。
図2：サイトの状態と操作手順 次の表に、操作手順の概要を示します。
表1：操作手順の説明
操作手順
（それぞれが事例の操作例に関連） 説明
手順：Data Guardでの最初のサイトの準備 Data Guardを使用するためにプライマリ・サイトを準備します（既存のデプロイメントを
想定。事例の手順例については、「最初のサイトのセットアップ」を参照）。
手順：セカンダリ・サイトのセットアップ セカンダリ・サイトのデータベース・スタンバイとアプリケーションを確立します。
手順：サイト・テスト サイト・テストを実行するためにスタンバイ・サイトを準備します。
手順：スタンバイへのサイト・テスト サイト・テストを実行するサイトをスタンバイ・モードに戻します。
手順：スイッチオーバー 現在のスタンバイ・サイトがプライマリになり、現在のプライマリ・サイトがスタンバイ
になるように、ロールを切り替えます。
手順：フェイルオーバー 現在のスタンバイ・サイトをプライマリ・モードに切り替えます。現在のプライマリ・サ
イトは停止しているか使用不可になっていると仮定します。
手順：スタンバイの復旧 フェイルオーバー後に、古いプライマリ・サイトをスタンバイとして復旧させます。
9 | Oracle Public Cloudでのディザスタ・リカバリ
次の表に、それぞれの状態でのデータベース構成を示します。
表2：各サイト状態におけるデータベース構成
サイト状態 データベース - Data Guard
サイトAが準備完了、サイトBなし Not configured
サイトAがプライマリ、サイトBがセットアップ サイトAがプライマリ、サイトBがフィジカル・スタンバイ。
アプリケーション・セットアップ中は、サイトBはスナップショット・スタンバイ。
サイトAがプライマリ、サイトBがテスト サイトAがプライマリ、
サイトBがスナップショット・スタンバイ。
サイトAがプライマリ、サイトBがスタンバイ サイトAがプライマリ、
サイトBがフィジカル・スタンバイ。
サイトBがプライマリ、サイトAが停止 フェイルオーバーによってサイトBがプライマリ、サイトAが停止。
サイトBがプライマリ、サイトAがスタンバイ サイトBがプライマリ、
サイトAがフィジカル・スタンバイ。
サイトAがプライマリ、サイトBが停止 フェイルオーバーによってサイトAがプライマリ、サイトBが停止。
サイトBがプライマリ、サイトAがテスト サイトBがプライマリ、
サイトAがスナップショット・スタンバイ。
サイトのスイッチオーバー後またはフェイルオーバー後のアプリケーション・アクセス
アプリケーションへのアクセスに、JCSインスタンスのパブリック・ネットワークIPアドレスを使用しており、このアドレスはサイトAとサイトBで異なります。プライマリ・サイトが停止してスタンバイ・サイトへのフェイルオーバーが実行された場合、セカンダリ・サイトでアプリケーションが起動されたら、アプリケーションへの接続にアプリケーション・クライアント（ユーザー、クライアント側アプリケーション）は別のアドレスを使用する必要があります。DNSプッシュまたはインテリジェントなクライアント側アプリケーション・コードを使用すると、アドレス変更をエンドユーザーからマスクできますが、これを行う方法はユーザーの環境によって大きく異なるため、このドキュメントでは説明していません。
10 | Oracle Public Cloudでのディザスタ・リカバリ
Oracle Cloud ServiceのMAA事例 この項では、前述したMaximum Availability Architectureを、それぞれがDatabase Cloud Service（DBCS）インスタンスとJava Cloud Service（JCS）インスタンスを使用する、地理的に分散された2つのサイトで構成されたシステムにデプロイする方法について説明します。
事例では、標準的なJavaベース・アプリケーションを示すためにMedRecを使用しています。MedRecはWebLogic Serverに付属しているエンドツーエンドのサンプルJava EEアプリケーションで、独立している一元化された医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者がさまざまなクライアントで患者データを管理するためのフレームワークが用意されています。データ格納は、アプリケーションのみがアプリケーション・データベースMEDREC PDBに対して行ったため、他のストレージ・アーチファクトのレプリケーションは不要でした。この事例では、MEDRECアプリケーションのシングル・テナント・バージョンを使用しました。
プライマリ・サイト（サイトA）を米国イリノイ州シカゴに配置し、セカンダリ・サイト（サイトB）を米国バージニア州アシュバーンに配置しました。2つのサイトは約600マイル離れています。
図3に、構成したシステムの概要を示します。
図3：Oracle Public Cloudでのディザスタ・リカバリ構成例
11 | Oracle Public Cloudでのディザスタ・リカバリ
次の表は、この事例に使用したシステム・パラメータをまとめたものです。
表3：事例のシステム・パラメータ
システム サイトA サイトB
Oracle Cloudドメイン domaina domainb
Oracle Cloudユーザー [email protected] [email protected]
Oracle Cloudパスワード Acme1234# Acme1234#
データベース・システム・パスワード （すべてのデータベース）
Acme1234# Acme1234#
JCSインスタンス jcsa 2 OCPU jcsb 2 OCPU
WLSソフトウェア・バージョン 12.2.1.0 12.2.1.0
WebLogicユーザー weblogic weblogic
WebLogicパスワード Acme1234# Acme1234#
JCSバックアップ・コンテナ jcsaContainer jcsbContainer
アプリケーションDBCSインスタンス appdba Extreme Performance 2 OCPU appdbb Extreme Performance 2 OCPU
アプリケーションDBCSソフトウェア・バージョン 12.1.0.2 12.1.0.2
アプリケーション・データベース名 APPDB APPDB
一意のアプリケーション・データベース名 APPDB APPDBB
アプリケーション・プラガブル・データベース MEDREC MEDREC
アプリケーション・インスタンス名 APPDB APPDB
アプリケーション・バックアップ・コンテナ appdbaContainer appdbbContainer
JCS DBCSインスタンス infraa Standard Edition 1 OCPU infrab Standard Edition 1 OCPU
JCSデータベース・バージョン 12.1.0.2 12.1.0.2
JCSデータベース名 INFRAA INFRAB
JCSプラガブル・データベース INFRA INFRA
JCSインスタンス名 INFRAA INFRAB
JCSデータベース・バックアップ・コンテナ infraaContainer infrabContainer
操作手順 システム全体をセットアップおよびテストするために実行した詳細な手順については、「付録A：事例詳細」に示しています。
12 | Oracle Public Cloudでのディザスタ・リカバリ
サイト停止のテストと結果 プライマリ・サイトのすべてのサーバーを突然停止させて、サイトのフェイルオーバーを実行しました。アプリケーションをDR構成の一部として両方のサイト（プライマリとセカンダリ）のJCSインスタンスにデプロイしたため、サイトのスイッチオーバー時またはフェイルオーバー時にアプリケーションの再構成や再デプロイメントはありませんでした。サイトBにルーティングされるエンドユーザー・トラフィックを処理するために、スタンバイ・サイトのWLS管理対象サーバーを起動しただけでした。
サイト停止の観察
サイトの停止時にすべてのユーザーが失われたため、スタンバイ・サイトでサービスをリストアするためにサイトのフェイルオーバー手順を実行しました。「手順：フェイルオーバー」に記載されているフェイルオーバー手順を実行し、各手順にかかった時間を記録しました。「表4：計画外サイト停止のリカバリ時間」に、この時間を示しています。
表4：計画外サイト停止のリカバリ時間
リカバリ手順 経過時間（秒） 累計時間（秒） 説明
データベース・フェイルオーバー 37 37 Data Guard Brokerを使用
MEDRECアプリケーションの起動 63 100
最初のユーザー・ログイン 5 105
スクリプトを使用して1つの手順から次の手順まで遅延なくプロセスの各手順を実行する場合は、リカバリの実行にかかる合計時間は100秒（最初のユーザー・ログインを除く）と推定されます。
結論 クラウド構成でのディザスタ・リカバリには、冗長アプリケーション層、本番データベース、およびOracle Data GuardまたはActive Data Guardで同期したOracle Cloud上のDRコピーを使用します。Oracle Cloudでのディザスタ・リカバリを採用すると、リモート施設の所有および管理に要するコストと複雑さが解消されるほか、スタンバイ・システムおよびスタンバイ・ソフトウェアにかかる資本コストも不要になります。
Data GuardまたはActive Data Guardをディザスタ・リカバリに使用することで停止時間がなくなり、サービスをリストアするにはリモート・バックアップに頼らざるを得ないという潜在的なリスクもなくなります。つまり、Oracle Cloud上ですでに稼働している本番データベースの同期済みコピーに本番がただちにフェイルオーバーされます。クラウド上のスタンバイ・データベースはディザスタ・リカバリに使用できるだけでなく、開発およびテスト用クローンのシード・データベースとしてや、読取り専用ワークロードを本番データベースからオフロードするためにも使用できます。
13 | Oracle Public Cloudでのディザスタ・リカバリ
付録A：事例詳細 この付録では、事例のセットアップ時と停止テスト時に実行した詳細な手順を示しています。「プライマリ・サイトのセットアップ」は、参照用に示しています。セットアップは、アプリケーションごとに異なります。
プライマリ・サイトのセットアップ 参照用に、サイトAをプロビジョニングして構成するために次の手順を実行します。
1. Oracle Cloud Serviceインスタンスをプロビジョニングする
1.1. ストレージ・コンテナを作成する
次のコマンドを実行し、認証トークンを取得します。
export SCSDOMAIN=domaina export [email protected] export SCSPASSWORD=’acme1234#’ curl -v -X GET \
-H "X-Storage-User: Storage-${SCSDOMAIN}:${SCSUSER}" \ -H "X-Storage-Pass: ${SCSPASSWORD}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/auth/v1.0
次のコマンドで、認証トークンを設定します。
export SCSAUTH=<token returned from previous step>
次のコマンドを実行し、ストレージ・コンテナを作成します。
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/jcsaContainer
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/infraaContainer
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/appdbaContainer
1.2. JCS用DBCSインスタンスをプロビジョニングする
「Database Cloud Service」→「Service Console」を選択してサイトBのJCS用のDBCSインスタンスを作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表5：事例のサイト'B'のJCSパラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Database Cloud Service
Billing Frequency 毎月
Release Software Release 12.1.0.2
Edition Software Edition Standard Edition
Service Details Service Configuration Service Name infraa
Shape OC3 - 1 OCPU, 7.5 GB RAM
Timezone (UTC) Coordinated Universal Time(UTC)
SSH Public Key key.pub
Database Configuration Usable Database Storage (GB) 25
14 | Oracle Public Cloudでのディザスタ・リカバリ
Administration Password Acme1234#
DB Name INFRAA
PDB Name INFRA
Character Set AL32UTF8
National Character Set AL16UTF16
Database Clustering with RAC オフ
Standby Database with Data Guard
オフ
Enable Oracle Goldengate オフ
Include “Demos” PDB オフ
Backup and Recovery Configuration
Backup Destination Both Cloud Storage and Local Storage
Cloud Storage Container Storage-domaina/infraaContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
1.3. アプリケーション用DBCSインスタンスをプロビジョニングする
「Database Cloud Service」→「Service Console」を選択してDRのDBCSインスタンス作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表6：事例のDatabase Cloud Service（DBCS）パラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Database Cloud Service Billing Frequency
Billing Frequency Monthly
Release Software Release 12.1.0.2
Edition Software Edition Enterprise Edition – Extreme Performance
Service Details Service Configuration Service Name appdba
Shape OC4-2 OCPU, 15 GB RAM
Timezone (UTC) Coordinated Universal Time(UTC)
SSH Public Key key.pub
Database Configuration Usable Database Storage (GB) 25
Administration Password **********
DB Name APPDB
PDB Name MEDREC
Character Set AL32UTF8
National Character Set AL16UTF16
Database Clustering with RAC オフ
Standby Database with Data Guard
オフ
15 | Oracle Public Cloudでのディザスタ・リカバリ
Enable Oracle Goldengate オフ
Include “Demos” PDB オフ
Backup and Recovery Configuration
Backup Destination Both Cloud Storage and Local Storage
Cloud Storage Container Storage-domainb/appdbaContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
1.4. JCSインスタンスをプロビジョニングする
「Jave Cloud Service」→「Service Console」を選択してサイトAのJCSインスタンスを作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表7：事例のサイト'A'のJCSパラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Java Cloud Service
Billing Frequency 毎月
Software Release 12.2.1.0
Software Edition Enterprise Edition
Service Details Service Configuration Service Name jcsa
Domain Partiitons 0
Shape OC4 - 2 OCPU, 25 GB RAM
SSH Public Key key.pub
WebLogic Username weblogic
パスワード Acme1234#
Deploy Sample Application オフ
Database Configuration Name infraa
PDB Name INFRA
Administrator User Name SYS
パスワード Acme1234#
Backup and Recovery Configuration Cloud Storage Container Storage-domaina/jcsaContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
2.アプリケーションをインストールして構成する
2.1. 暗号化されたアプリケーション表領域を作成する
次のコマンドをsysdbaとして実行し、サイトAのアプリケーション・データベース・インスタンス（appdba）上の暗号化を適用したMEDREC PDBに、MEDRECアプリケーション・データの格納に使用するDATA表領域を作成します。
ALTER SESSION SET CONTAINER = MEDREC;
16 | Oracle Public Cloudでのディザスタ・リカバリ
CREATE BIGFILE TABLESPACE "DATA" DATAFILE '/u02/app/oracle/oradata/APPDB/MEDREC/MEDREC_data01.dbf' SIZE 3221225472 AUTOEXTEND ON NEXT 1073741824 MAXSIZE 33554431M LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE ENCRYPTION using 'AES256' DEFAULT STORAGE(ENCRYPT) SEGMENT SPACE MANAGEMENT AUTO;
2.2. サイトAのJCSインスタンスとアプリケーションDBCSインスタンスの間のセキュリティ・ルールを作成する
JCSインスタンス（jcsa）とAPPDB DBCS DBリスナー（セキュリティ・アプリケーション）の間にセキュリティ・ルールを作成します。
各サイトのアプリケーションからデータベースへのトラフィックを、DBCSインスタンスおよびJCSインスタンスのパブリックIPアドレスではなく、内部ホスト名を使用して内部IPアドレスによってルーティングすることを推奨します。Oracle Public Cloudでのセキュリティ・ルールの構成について、詳しくはOracle Compute Cloudのドキュメントを参照してください。
2.3. MEDRECアプリケーションをインストールする
簡潔にするため、MEDRECアプリケーションの詳細なインストール手順は省略しています。
JCSインスタンスにデプロイするアプリケーションにJMSおよびJTAが必要な場合は、Oracle Data Guardを使用してデータがディザスタ・リカバリ・イベントから保護されるように、これらのすべての実行時アーチファクトをデータベース内に外部化することを推奨します。
データベース永続ストレージについて、詳しくは「JMSサーバーと永続ストアの構成」および「トランザクション・ログを永続化するためのデータベース・ストアの構成」参照してください。
手順：Data Guardでのプライマリ・サイトの準備 この手順の目的は、DR用にプライマリ・サイトを準備することです。以下に、実行する手順を示します。
1. Grid InfrastructureをインストールしてOracle Restartを構成する
1.1. Grid Infrastructureソフトウェアをインストールする
Oracle Grid InfrastructureソフトウェアをサイトAのデータベース・ホスト（appdba）にインストールし、Oracle Restartを構成します。
インストール時に、次のオプションを選択しました。
» インストール・オプション：Install Oracle Grid Infrastructure Software Only
» 言語：English
» Oracle ASMオペレータ：dba
» Oracleベース：/u01/app/oracle
» ソフトウェア・インストール場所：/u01/app/12.1.0/grid
インストール中に、特定の前提条件チェックがエラーになったため、「Fix & Check Again」をクリックして修正スクリプト（runfixup.sh）を生成しています。この修正スクリプトをrootユーザーとして実行して、必要なインストール前手順を完了します。
» 修正スクリプトを実行してZeroconfチェックを修正
17 | Oracle Public Cloudでのディザスタ・リカバリ
また、インストール中に発生した次の3つの警告を無視しています。
» 不十分なスワップ領域
» NTP（単一インスタンスには不要）
» タスクresolv.confの整合性
root.shスクリプトを実行し、出力結果に、Oracle Restartの構成を完了するために実行した追加のスクリプトが記録されます。
Oracle Grid Infrastructure（GI）は、Oracle Data Guardのアプリケーション・フェイルオーバー機能に不可欠な構成要素となっています。単一インスタンスの場合、GIによってOracle Restart機能が提供されます。
Grid Infrastructureは、スタンドアロン構成のOracle Database Cloud Serviceではインストールされないため、12.1または11.2の該当するドキュメントの手順に従って手動でインストールする必要があります。Oracle Grid infrastructureソフトウェアは、Oracle eDeliveryからダウンロードできます。Firefoxブラウザを使用して、DBCSインスタンスにソフトウェアを直接ダウンロードできます。
注：この事例で実行している手順では、GIがインストールおよび構成済みであることを前提としています。Grid Infrastructure（GI）はDRが正しく機能するための絶対条件ではありませんが、このホワイト・ペーパーの手順では、GIがインストールされていることを前提としています。代替コマンドを使用できますが、記載していません。GIは、高速アプリケーション通知（FAN）機能に必要です。
ssh接続を使用してOPC VMでOracleインストーラを実行するには、X11フォワーディングを有効化する必要があります。opcユーザーでrootとしてログインし、/etc/ssh/sshd_configファイルで次の行を設定します。
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
rootとしてsshデーモンを再起動します。
service sshd stop
service sshd start
OPC VMに接続するときには、次のオプションを使用して信頼できる接続であることを示します。
ssh -o ServerAliveInterval=100 -Y oracle@<IPC VM IP address>
1.2. Oracle Restartでデータベース・リスナーを構成する
サイトAのデータベース・ホスト（appdba）で、oracleユーザーとして次のコマンドを実行します。
lsnrctl stop listener cp $ORACLE_HOME/network/admin/listener.ora \ /u01/app/12.1.0/grid/network/admin/listener.ora
srvctl add listener -listener listener -oraclehome /u01/app/12.1.0/grid srvctl start listener
この事例で実行している手順では、すべてのデータベース・サーバーのデータベース・リスナーがポート1521でリスニングすることを前提としています。
1.3. Oracle Restartでデータベースを構成する
srvctl add database -d APPDB -oraclehome $ORACLE_HOME -startoption open
データベースを起動し、次のようにsrvctlコマンドでデータベースのステータスを確認します。
18 | Oracle Public Cloudでのディザスタ・リカバリ
srvctl status database -d APPDB Database is not running. srvctl start database -d APPDB srvctl status database -d APPDB Database is running.
2. オペレーティング・システムとデータベースを構成する
2.1. TCPソケット最大サイズを設定する
Oracle Public Cloudのドキュメントに記載されているように、opcユーザーに接続してsudoコマンドを使用すると、プロビジョニングしたクラウド・インスタンスにrootでアクセスできます。
sudo -s
サイトAのデータベース・ホスト（appdba）で、rootユーザーとして次のコマンドを実行します。
sysctl -w net.core.rmem_max=10485760 sysctl -w net.core.wmem_max=10485760
また、インスタンスの再起動時に変更が保持されるように、/etc/sysctl.confファイルを編集して変更を反映します。
2.2. オンラインREDOログのサイズを設定する
Database Cloud Serviceにデフォルトで作成されるREDOログは1GBであり、今回のテストには十分としています。
オンラインREDOログは、次の計算式を使用してサイジングする必要があります。ただし、1GB未満にはしないでください。
ピークREDO生成量/分×20
REDO生成量を求めるには、バッチ処理、四半期末処理、年末処理などのピーク・ワークロード期間中のAWRレポートを参照してください。平均ではなくピーク・ワークロードを使用することが非常に重要です
（平均を使用すると、ピークREDO生成量が分からず、REDOログのプロビジョニングが過小になりすぎる場合があります）。
2.3. スタンバイREDOログを作成する
サイトAのアプリケーション・データベース（APPDB）で、sysユーザーとして次のコマンドを実行します。
alter database add standby logfile thread 1 group 4 '/u04/app/oracle/redo/stbyredo04.log' size 1073742336;
alter database add standby logfile thread 1 group 5 '/u04/app/oracle/redo/stbyredo05.log' size 1073742336;
alter database add standby logfile thread 1 group 6 '/u04/app/oracle/redo/stbyredo06.log' size 1073742336;
alter database add standby logfile thread 1 group 7 '/u04/app/oracle/redo/stbyredo07.log' size 1073742336;
select * from v$logfile;
スタンバイREDOログ（SRL）に関するMAAベスト・プラクティスは、作成するSRLグループの数をオンラインREDOログ（ORL）グループの数+1とすることです。Oracle RACの場合は、これを各スレッドに対して行う必要があります。各スレッドに含まれているREDOログ・グループの数を特定するには、次の問合せを使用します。
19 | Oracle Public Cloudでのディザスタ・リカバリ
select thread#, count(group#) from v$log group by thread#;
SRLは、一番大きいORLと同じサイズで作成する必要があります。グループ番号はORLと共有されるため、SRLはORLよりも大きいグループ番号で作成されます。一番大きいORLのサイズおよび現在一番大きいグループ番号を取得するには、次の問合せを実行します。
select max(bytes), max(group#) from v$log;
MAAベスト・プラクティスは、SRLを二重化しないことです。
2.4. データベースを暗号化する（オプション）
初期セットアップ時に、MEDREC PDBに暗号化を適用してDATA表領域を作成しました（「2.1.暗号化された アプリケーション表領域を作成する」を参照）。
Data Guardのプライマリ・データベースとスタンバイ・データベースは、相互の物理レプリカです。クラウド内のスタンバイ・データベースを静止時に暗号化するには、まずプライマリを暗号化する必要があります。Oracle MAAベスト・プラクティスでは、Oracle Database 11.213またはOracle Database 12c14の場合に、最小限の停止時間でTDEに変換する方法を説明しています。最小限の停止時間で変換する方法について、詳しくは次のMAAホワイト・ペーパーを参照してください。
http://www.oracle.com/technetwork/jp/database/availability/tde-conversion-dg-3045460-ja.pdf.
2.5. 強制ロギングとフラッシュバック・データベースを有効化し、推奨されるMAAデータベース・パラメータを設定する
サイトAのアプリケーション・データベース（APPDB）で、sysユーザーとして次のコマンドを実行します。
alter database force logging; alter database flashback on; alter system set DB_FLASHBACK_RETENTION_TARGET=120 scope=both sid='*'; alter system set remote_login_passwordfile='exclusive' scope=spfile sid='*'; alter system set DB_BLOCK_CHECKSUM=FULL; alter system set DB_BLOCK_CHECKING=MEDIUM; alter system set DB_LOST_WRITE_PROTECT=TYPICAL; alter system set LOG_BUFFER=256M scope=spfile sid='*'; alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=spfile sid='*';
注：DB_BLOCK_CHECKSUM、DB_BLOCK_CHECKING、およびDB_LOST_WRITE_PROTECTは、ブロックの破損防止に役立つパラメータです。保護の成果を得るために、ここに示されているように設定することを推奨しますが、DB_BLOCK_CHECKINGはパフォーマンスに影響を与える可能性があるため、値を選択する際には考慮が必要です。値をFALSEにするとDB_BLOCK_CHECKINGはオフになります。
注：LOG_BUFFERを256MBに設定すると、非同期REDO転送時にメモリからREDOが読み取られるようになり、ディスクI/Oを実行してオンラインREDOログから読み取る必要がなくなります。
2.6. アーカイブ・ログ・モードを有効化する
サイトAのアプリケーション・データベース（APDDB）で、sysユーザーとして次のコマンドを実行します。
alter system set log_archive_dest_1= 'location=USE_DB_RECOVERY_FILE_DEST valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=APPDB' scope=both sid='*';
shutdown immediate
13 http://www.oracle.com/technetwork/jp/database/availability/tde-conversion-11g-2531187-ja.pdf 14 http://www.oracle.com/technetwork/jp/database/availability/tde-conversion-12c-2537297-ja.pdf
20 | Oracle Public Cloudでのディザスタ・リカバリ
startup mount alter database archivelog; alter database open; alter system archive log current;
データベースのアーカイブ・ログ・モードを変更するには、データベースの再起動が必要です。
手順：セカンダリ・サイトのセットアップ この手順では、セカンダリ・サイトをデプロイメントします。「手順：Data Guardでの最初のサイトの準備」で実行した手順が完了していることを前提としています。
1. セカンダリ・サイトでOracle Cloud Serviceを確立する
1.1 DRサイトのOracle Database Cloud Serviceにサブスクライブする
セカンダリ・サイトをアシュバーンに配置することを決定したため、そのサイトのOracle Database Cloud Service15へのサブスクリプションを保護します。
サブスクリプション、アクティブ化、サービス作成について、詳しくはDBaaSクラウドのドキュメント16を参照してください。
1.2 データベース・バックアップとJCSバックアップのストレージ・コンテナを作成する
次のコマンドを実行し、認証トークンを取得します。
export SCSDOMAIN=domainb export [email protected] export SCSPASSWORD=acme1234 curl -v -X GET \
-H "X-Storage-User: Storage-${SCSDOMAIN}:${SCSUSER}" \ -H "X-Storage-Pass: ${SCSPASSWORD}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/auth/v1.0
次のコマンドで、認証トークンを設定します。
export SCSAUTH=<token returned from previous step>
次のコマンドを実行し、ストレージ・コンテナを作成します。
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/jcsbContainer
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/infrabContainer
curl -v -X PUT \ -H "X-Auth-Token: ${SCSAUTH}" \ https://${SCSDOMAIN}.storage.oraclecloud.com/v1/Storage-${SCSDOMAIN}/appdbbContainer
15 http://docs.oracle.com/cloud/latest/dbcs_dbaas/index.html 16 http://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBI/GUID-1A380E9C-6DE2-4042-8A31-B43A0081B194.htm#CSDBI3312
21 | Oracle Public Cloudでのディザスタ・リカバリ
1.3. アプリケーション用Oracle Databaseサービス・インスタンスを作成する
「Database Cloud Service」→「Service Console」を選択してDRのDBCSインスタンス作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表8：事例のDBCSパラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Java Cloud Service
Billing Frequency 毎月
Release Software Release 12.1.0.2
Edition Software Edition Enterprise Edition
Service Details Service Configuration Service Name jcsa
Shape OC4 - 2 OCPU, 15 GB RAM
Timezone (UTC) Coordinated Universal Time(UTC)
SSH Public Key key.pub
Database Configuration Usable Database Storage (GB) 25
Administration Password **********
DB Name APPDB
PDB Name MEDREC
Character Set AL32UTF8
National Character Set AL16UTF16
Database Clustering with RAC オフ
Standby Database with Data Guard
オフ
Enable Oracle Goldengate オフ
Include “Demos” PDB オフ
Backup and Recovery Configuration Backup Destination Both Cloud Storage and Local Storage
Cloud Storage Container Storage-domaina/jcsaContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
1.4. データベースのパッチ・レベルを同期化する
両方のデータベース・ホスト（appdbaおよびdbb）で、oracleユーザーとして次のコマンドを実行します。結果を比較し、同じであることを確認します。
$ORACLE_HOME/OPatch/opatch lspatches
プライマリ・データベースのOracleホームのOracleパッチセットはスタンバイ・データベースと同じである必 要 が あ り 、パ ッ チ も同 じで あ る 必 要 があ り ま す。 2 つ の サ イ ト の ‘$ORACLE_HOME/OPatch/opatch lspatches’の出力を比較し、それぞれに不足しているパッチを適用します。
22 | Oracle Public Cloudでのディザスタ・リカバリ
1.5. デフォルト・データベースを削除または再割当てする
次のコマンドを使用し、サイトBのアプリケーション・データベース・インスタンスに作成されたデフォルト・データベースを削除します。
dbca -silent -deleteDatabase -sourceDB APPDB -sysDBAUserName sys -sysDBAPassword Acme1234#
cd /u03/app/oracle/fast_recovery_area rm -rf APPDB
デフォルト・データベース・インスタンスは、Oracle Database Cloud Serviceの作成時に自動的に作成されます。このデータベースは、Data Guardスタンバイ・データベースとしては使用できません。削除するか、または別の目的に再利用できます。
1.6. ネットワーク・セキュリティを構成する
サイトBにアクセスできるようにするために、サイトAで「Oracle Compute Cloud Service」→「Service Console」→「Network」タブを使用して次のネットワーク構成を作成します。
表9：サイト‘A’のネットワーク構成
タイプ 名前 オプション 値
Security IP List appdbb IP List < appdbb’s public IP address>
Security Rule appdbb2appdba Status Enabled
Security Application appdba/db_1/ora_dblistener
Source Security IP List appdbb（上記で作成）
Destination Security List appdba/db_1/ora_db
サイトAにアクセスできるようにするために、サイトBで「Oracle Compute Cloud Service」→「Service Console」→「Network」タブを使用して次のネットワーク構成を作成します。
表10：サイト‘B’のネットワーク構成
タイプ 名前 オプション 値
Security IP List appdba IP List < appdba’s public IP address>
Security Rule appdba2appdbb Status Enabled
Security Application appdbb/db_1/ora_dblistener
Source Security IP List appdba（上記で作成）
Destination Security List appdbb/db_1/ora_db
Data Guardが適切に機能するためには、プライマリ・サイトとスタンバイ・サイトのデータベース・サーバー間にOracle Net通信が必要です。アプリケーション・サーバーや他のサーバーも、Oracle Netでデータベースにアクセスすることが必要となる可能性があります。他のすべてのサーバーに対しては、アクセスを許可しないでください。
23 | Oracle Public Cloudでのディザスタ・リカバリ
2. Grid InfrastructureをインストールしてOracle Restartを構成する
2.1. Grid Infrastructureソフトウェアをインストールする
サイトAと同じ方法で、Oracle Grid InfrastructureソフトウェアをサイトBのデータベース・ホスト（appdba）にインストールしました（「1.1.Grid Infrastructureソフトウェアをインストールする」を参照）。
2.2. Oracle Restartでデータベース・リスナーを構成する
サイトBのアプリケーション・データベース・ホスト（appdbb）で、oracleユーザーとして次のコマンドを実行します。
lsnrctl stop listener cp $ORACLE_HOME/network/admin/listener.ora \ /u01/app/12.1.0/grid/network/admin/listener.ora
srvctl add listener -listener listener -oraclehome /u01/app/12.1.0/grid srvctl start listener
3. オペレーティング・システムとデータベースを構成する
3.1 ソース・ファイルを準備する
スクリプトを使用し、データベースを構成して複製し、Data Guard Brokerを構成し、bashソース・ファイルを共有しました。次 のよう にして、サ イトA の データ ベース・ホストのoracleユ ーザーにファイル~/script.envを作成します。
export passwd='<sys password of the app database>' export DB_NAME='appdb' export A_DBNM='<Site A’s database unique name; in this case study it is ‘APPDB’>' export A_PUB_IP='<Site A’s database public IP address>' export A_PRIV_HOSTNAME='<Site A’s database private HOSTNAME >' export A_PORT='1521'
export A_DB_DOMAIN='<Site A’s DB_DOMAIN>' export B_DBNM=' Site B’s database unique name; in this case study it is ‘APPDBB’'
export B_PUB_IP='<Site B’s database public IP address>' export B_PRIV_HOSTNAME='<Site B’s database private HOSTNAME>' export B_PORT='1521' export B_DB_DOMAIN='<Site A’s DB_DOMAIN>' export A_FILE_LOC='/u02/app/oracle/oradata' export A_RECOV_LOC='/u03/app/oracle/fast_recovery_area' export A_REDO_LOC='/u04/app/oracle/redo'
export B_FILE_LOC='/u02/app/oracle/oradata' export B_RECOV_LOC='/u03/app/oracle/fast_recovery_area'
export B_REDO_LOC='/u04/app/oracle/redo'
export B_BASE='/u01/app/oracle'
このファイルを、サイトBのデータベース・ホストのoracleユーザーにコピーします。
24 | Oracle Public Cloudでのディザスタ・リカバリ
3.2. TCPソケット最大サイズを設定する
サイトAのデータベース・ホスト（appdba）で、rootユーザーとして次のコマンドを実行します。
sysctl -w net.core.rmem_max=10485760 sysctl -w net.core.wmem_max=10485760
また、インスタンスの再起動時に変更が保持されるように、/etc/sysctl.confファイルを編集して変更を反映します。
Oracle Public Cloudのドキュメントに記載されているように、opcユーザーに接続してsudoコマンドを使用すると、プロビジョニングしたクラウド・インスタンスにrootでアクセスできます。
sudo -s
3.3. Oracle Netの暗号化を構成する
appdbaからappdbbにウォレットをコピーします。
appdbaで、oracleユーザーとして次のコマンドを実行します。
cd /u01/app/oracle/admin tar -czf /tmp/APPDB.tgz APPDB
appdbaからappdbbに/tmp/APPDB.tgzファイルをコピーしました。appdbbで、oracleユーザーとして次のコマンドを実行します。
cd /u01/app/oracle/admin tar -xzf /tmp/APPDB.tgz
次 の パ ラ メ ー タ を 、 サ イ ト A と サ イ ト B の ア プ リ ケ ー シ ョ ン ・ デ ー タ ・ ホ ス ト の$ORACLE_HOME/
network/admin/sqlnet.oraファイルに追加します。
SQLNET.ENCRYPTION_CLIENT = requested SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, AES192, AES128)
ウォレットを作成および分散させる手順については、「付録F ‒ ウォレットの作成と分散」を参照してください。
DBCSインスタンスに作成されるデフォルト・データベースの場合は、ウォレットの作成はDBCSインスタンス作成の一部として行われます。
3.4. REDO転送のTNSエントリを構成する
次のエントリを、両方のサイトのデータベース・ホスト（adddbaおよびappdbb）のtnsnames.oraファイルに構成しました。両方のデータベース・ホストで、oracleユーザーとして次のコマンドを実行します。
. ~/script.env cat >> $ORACLE_HOME/network/admin/tnsnames.ora <<EOF ${A_DBNM} = (DESCRIPTION =
(SDU=65536) (RECV_BUF_SIZE=10485760)
(SEND_BUF_SIZE=10485760) (ADDRESS = (PROTOCOL = TCP)(HOST = ${A_PUB_IP})(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ${A_DBNM}.${A_DB_DOMAIN})
) )
25 | Oracle Public Cloudでのディザスタ・リカバリ
${B_DBNM} = (DESCRIPTION = (SDU=65536) (RECV_BUF_SIZE=10485760) (SEND_BUF_SIZE=10485760) (ADDRESS = (PROTOCOL = TCP)(HOST = ${B_PUB_IP})(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ${B_DBNM}.${B_DB_DOMAIN})
) )
EOF
tsnnames.oraファイルを確認し、重複するAPPDB別名を削除します。
REDO転送を適切に実行するためには、プライマリとスタンバイの両方のtnsnames.oraファイルに各データベースのエントリが必要です。
注：プライマリ・データベースについては、サイトAのDBCSインスタンスのtnsnames.oraに、HOSTにサーバー名が入ったTNSエントリがすでにある場合があります。その場合は、IPアドレスを使用するように、そのエントリのサーバー名を変更するだけで構いません。
注：サーバー名をIPアドレスに解決するDNSがないため、IPアドレスを使用しています。
3.5. 静的リスナーを構成する
サイトBのデータベース・ホスト（appdbb）で、oracleユーザーとして次のコマンドを実行します。
. ~/script.env cat >> /u01/app/12.1.0/grid/network/admin/listener.ora <<EOF SID_LIST_LISTENER = (SID_LIST = (SID_DESC =
(GLOBAL_DBNAME = ${B_DBNM}.${B_DB_DOMAIN}) (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1) (SID_NAME = ${DB_NAME})
) ) EOF
サイトBのデータベース・ホスト（appdbb）で、oracleユーザーとして次のコマンドを実行します。
/u01/app/12.1.0/grid/bin/lsnrctl reload
静的リスナーは、スタンバイ・データベースの最初のインスタンス化に必要です。データベースが停止しているときに、静的リスナーを使用してインスタンスにリモート接続し、所定のインスタンスを起動できます。以下の手順を実行すると、クラウドVMの静的リスナーを構成できます。詳しくは、MOS 1387859.1を参照してください。
Oracle Data Guard Brokerによるインスタンスの再起動にはClusterwareが使用されるため、Oracle Restart、Oracle RAC One Node、またはOracle RACで管理されているOracle Data Guard Broker構成では、Oracle Database 12.1.0.2の時点から静的な"_DGMGRL"エントリは必要なくなりました。
11.2の構成では、Data Guard Brokerに静的リスナーが必要です。
26 | Oracle Public Cloudでのディザスタ・リカバリ
Site A: SID_LIST_LISTENER = (SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = <${A_DBNM}_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1) (SID_NAME = ${DB_NAME})
) )
Site B: SID_LIST_LISTENER = (SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = <${B_DBNM}) (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1) (SID_NAME = ${DB_NAME})
) (SID_DESC = (GLOBAL_DBNAME = <${B_DBNM}_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1) (SID_NAME = ${DB_NAME})
) )
4. スタンバイ・データベースをインスタンス化する
2016年7月より前に作成されたデータベース・インスタンスには、rootユーザーとして次のコマンドを実行し、サイトAとサイトBの両方で、対応するmtu設定を手動で構成する必要があります。
ip link set eth0 mtu 1500
echo "ip link set eth0 mtu 1500" >> /etc/rc.local
2016年7月以降に作成されたデータベース・インスタンスには、この手順を実行しないでください。
4.1. 補助データベースのパスワード・とパスワード・ファイルを作成する
サイトBのデータベース・ホスト（appdbb）で、oracleユーザーとして次のコマンドを実行します。
. ~/script.env cd $ORACLE_HOME/dbs $ORACLE_HOME/bin/orapwd file='$ORACLE_HOME/dbs/orapw${DB_NAME}' password=${passwd}
force=y cat > /tmp/aux.pfile << EOF db_name=${DB_NAME} db_unique_name=${B_DBNM} db_domain=${B_DB_DOMAIN} sga_target=800M
EOF
このpfileのsgaのサイズをプライマリと一致させる必要はありません。正しい値が設定された新しいspfileが、インスタンス化のプロセスで生成されます。この補助pfileは、補助インスタンスを起動するためにのみ使用されます。
4.2. 補助インスタンスを起動する
サイトBのデータベース・ホストでoracleユーザーとして次のコマンドを実行し、補助インスタンスを起動します。
. ~/script.env
27 | Oracle Public Cloudでのディザスタ・リカバリ
export ORACLE_SID=${DB_NAME} sqlplus "/ as sysdba" <<EOF startup nomount pfile='/tmp/aux.pfile' EOF
補助インスタンスは、プライマリ・サイトとスタンバイ・サイトとの間の通信を可能にする一時的なインスタンス（単なるメモリ構造）です。プライマリでファイルをコピーして補助インスタンスをデータベースにすることができるまでの、プレースホルダのようなものです。
4.3. スタンバイ・データベースの監査およびファイルの場所を作成する
サイトBのデータベース・ホストで、oracleユーザーとして次のコマンドを実行します。
. ~/script.env mkdir -p ${B_BASE}/admin/${B_DBNM}/adump
mkdir ${B_FILE_LOC}/${B_DBNM} mkdir ${B_FILE_LOC}/${B_DBNM}/pdbseed mkdir ${B_FILE_LOC}/${B_DBNM}/MEDREC mkdir ${B_RECOV_LOC}/${B_DBNM}
mkdir ${B_REDO_LOC}/${B_DBNM}
4.4. スタンバイ・データベースを作成する
プライマリ・データベースから複製して、スタンバイ・データベースをインスタンス化します。
サイトBのデータベース・ホストからoracleユーザーとして次のスクリプトを実行し、RMAN複製スクリプトを作成します。
. ~/script.env cat >/tmp/${B_DBNM}.rman <<EOF connect target sys/${passwd}@${A_DBNM}
connect auxiliary sys/${passwd}@${B_DBNM}
run { allocate channel prmy1 type disk; allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
allocate auxiliary channel stby3 type disk;
allocate auxiliary channel stby4 type disk; duplicate target database for standby from active database spfile
PARAMETER_VALUE_CONVERT= '${A_DBNM}', '${B_DBNM}' set db_unique_name='${B_DBNM}' set control_files='${B_FILE_LOC}/${B_DBNM}/control01.ctl', '${B_RECOV_LOC}/${B_DBNM}/control02.ctl'
set audit_file_dest='${B_BASE}/admin/${B_DBNM}/adump' set local_listener='(ADDRESS=(PROTOCOL=tcp)(HOST=${B_PRIV_HOSTNAME})(PORT=${B_PORT}))' set fal_server='${A_DBNM}' set log_file_name_convert='${A_REDO_LOC}','${B_REDO_LOC}/${B_DBNM}', '${A_REDO_LOC}}/${A_DBNM}','${B_REDO_LOC}/${B_DBNM}'
set db_file_name_convert='${A_FILE_LOC}/${A_DBNM}', '${B_FILE_LOC}/${B_DBNM}' set db_create_file_dest='${B_FILE_LOC}' set db_create_online_log_dest_1='${B_REDO_LOC}' set db_recovery_file_dest='${B_RECOV_LOC}' set db_recovery_file_dest_size='40G' set diagnostic_dest='${B_BASE}'
28 | Oracle Public Cloudでのディザスタ・リカバリ
set db_domain='$B_DB_DOMAIN' set STANDBY_FILE_MANAGEMENT='AUTO' section size 10M
dorecover ; } EOF
注：複数のマウント・ポイントにファイルが分散されている場合は、db_file_name_convertのエントリがさらに必要になります。データファイルへのパスごとに、‘<primary path>/${PRIMARY_DBNM}’、'${secondary path}/${SECONDARY_DBNM}'のペアが必要です。データファイルへのパスは、‘select name from
v$datafile;’でプライマリ・データベースから取得します。
注：複数のマウント・ポイントにログ・ファイルが分散されている場合は、log_file_name_convertのエントリがさらに必要になります。ログ・ファイルへのパスごとに、‘<primary path>/${PRIMARY_DBNM}’、'${secondary path}/${SECONDARY_DBNM}'のペアが必要です。ログ・ファイルのパスは、‘select member
from v$logfile;’でプライマリ・データベースから取得します。
サイトBのデータベース・ホスト（appdbb）から、oracleユーザーとして複製スクリプトを実行します。
. ~/script.env
rman << EOF @/tmp/${B_DBNM}.rman EOF
複製プロセス中に次のエラーが発生しますが、このエラーは無視して構いません。
ORA-38757: Database must be mounted and not open to FLASHBACK.
サイトAのデータベース・ホスト（appdba）からoracleとして次のコマンドを実行し、適切なファイル名変換パラメータをプライマリ・データベースに設定します。
. ~/script.env sqlplus / as sysdba <<EOF alter system set log_file_name_convert='${B_REDO_LOC}/${B_DBNM}','${A_REDO_LOC}', '${B_REDO_LOC}}/${B_DBNM}','${A_REDO_LOC}/${A_DBNM}'
scope=spfile sid='*'; alter system set db_file_name_convert='${B_FILE_LOC}/${B_DBNM}', '${A_FILE_LOC}/${A_DBNM}' scope=spfile sid='*';
EOF
4.5. Oracle Restartでデータベースを構成する
. ~/script.env
. ~/script.env srvctl add database -db ${B_DBNM} -dbname ${DB_NAME} \ -oraclehome $ORACLE_HOME -startoption open \ -instance APPDB
4.6. 新しいスタンバイ・データベースでフラッシュバックを有効化する
サイトAのデータベース・ホスト（appdba）からoracleとして次のコマンドを実行し、ブローカを構成します。
29 | Oracle Public Cloudでのディザスタ・リカバリ
. ~/script.env sqlplus -s sys/${passwd}@${B_DBNM} as sysdba <<EOF alter database flashback on;
EOF
4.7. Data Guard Brokerを構成する
サイトAのデータベース・ホスト（appdba）からoracleとして次のコマンドを実行し、ブローカを構成します。
. ~/script.env sqlplus -s sys/${passwd}@${A_DBNM} as sysdba <<EOF alter system set dg_broker_start=FALSE; alter system set dg_broker_config_file1='${A_FILE_LOC}/${A_DBNM}/dr1.dat'; alter system set dg_broker_config_file2='${A_RECOV_LOC}/${A_DBNM}/dr2.dat'; alter system set dg_broker_start=TRUE;
EOF
sqlplus -s sys/${passwd}@${B_DBNM} as sysdba <<EOF alter system set dg_broker_start=FALSE; alter system set dg_broker_config_file1='${B_FILE_LOC}/${B_DBNM}/dr1.dat'; alter system set dg_broker_config_file2='${B_RECOV_LOC}/${B_DBNM}/dr2.dat'; alter system set dg_broker_start=TRUE;
EOF
sleep 30
create configuration 'DGconfig' as primary database is ${A_DBNM} dgmgrl sys/${passwd}@${A_DBNM} <<EOF create configuration 'DGconfig' as primary database is ${A_DBNM} connect identifier is ${A_DBNM};
add database ${B_DBNM} as connect identifier is ${B_DBNM}; rem !!The following 2 commands must be uncommented for 11g databases!! rem edit database ${A_DBNM} set property RedoRoutes='(LOCAL:${B_DBNM} ASYNC)'; rem edit database ${B_DBNM} set property RedoRoutes='(LOCAL:${A_DBNM} ASYNC)'; EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance; enable configuration; exit
EOF
この事例で実行している手順では、プライマリ・データベースが既存のData Guard Broker構成に含まれていないことを前提としています。プライマリ・データベースに対応した既存のData Guard Broker構成がある場合は、管理者はこの構成を削除するか、この構成に新しいスタンバイ・データベースを追加する方法を把握している必要があります。
次の問合せで戻り値が‘NOCONFIG’以外の場合は、既存のData Guard Broker構成があることを意味します。
select decode(count(1),0,'NOCONFIG') from v$DG_BROKER_CONFIG;
4.8. Data Guardのヘルス・チェックを実行する
「付録B ‒ Data Guardのヘルス・チェック」を参照してください。
30 | Oracle Public Cloudでのディザスタ・リカバリ
4.9. 実行時監視を有効化する
「付録C ‒ Data Guardの実行時監視問合せ」を参照してください。
31 | Oracle Public Cloudでのディザスタ・リカバリ
5. アプリケーションをインストールしてテストする
5.1. スタンバイをスナップショット・スタンバイに変換する
プライマリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
convert database APPDBB to snapshot standby;
5.2. サイトBのJCSインスタンスとアプリケーションDBCSインスタンスの間のセキュリティ・ルールを作成する
JCSインスタンス（jcsb）とAPPDBB DBCS DBリスナー（セキュリティ・アプリケーション）の間にセキュリティ・ルールを作成します。
各サイトのアプリケーション・データベースへのトラフィックを、DBCSインスタンスおよびJCSインスタンスのパブリックIPアドレスではなく、内部ホスト名を使用して内部IPアドレスによってルーティングすることを推奨します。Oracle Public Cloudでのセキュリティ・ルールの構成について、詳しくはOracle Compute Cloudのドキュメントを参照してください。
5.3. 新しいサイトでアプリケーションをインストール、構成、テストする
「Database Cloud Service」→「Service Console」を選択してサイトBのJCSインフラストラクチャDBCSインスタンスを作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表11：サイト‘B’のDBCSパラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Database Cloud Service
Billing Frequency 毎月
Release Software Release 12.1.0.2
Edition Software Edition Standard Edition
Service Details Service Configuration Service Name infrab
Shape OC3 - 1 OCPU, 7.5 GB RAM
Timezone (UTC) Coordinated Universal Time(UTC)
SSH Public Key key.pub
Database Configuration Usable Database Storage (GB) 25
Administration Password Acme1234#
DB Name INFRAB
PDB Name INFRA
Character Set AL32UTF8
National Character Set AL16UTF16
Database Clustering with RAC オフ
Standby Database with Data Guard
オフ
Enable Oracle Goldengate オフ
Include "Demos" PDB オフ
Backup and Recovery Configuration Backup Destination Both Cloud Storage and Local Storage
32 | Oracle Public Cloudでのディザスタ・リカバリ
Cloud Storage Container Storage-domainb/infrabContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
「Jave Cloud Service」→「Service Console」を選択してサイトBのJCSインスタンスを作成する際、「Create Service」ボタンをクリックし、以下のパラメータを指定します。
表12：サイト‘B’のJCSパラメータ
ページ カテゴリ オプション 値
Subscription Type Service Level Oracle Java Cloud Service
Billing Frequency 毎月
Software Release 12.2.1.0
Software Edition Enterprise Edition
Service Details Service Configuration Service Name jcsb
Domain Partiitons 0
Shape OC4 - 2 OCPU, 25 GB RAM
SSH Public Key key.pub
WebLogic Username weblogic
パスワード Acme1234#
Deploy Sample Application オフ
Database Configuration Name infraa
PDB Name INFRA
Administrator User Name SYS
パスワード Acme1234#
Backup and Recovery Configuration Cloud Storage Container Storage-domainb/jcsbContainer
Cloud Storage User Name [email protected]
Cloud Storage Password Acme1234#
簡潔にするため、MEDRECアプリケーションの詳細なインストール手順とテスト手順は省略しています。
JCSインスタンスにデプロイするアプリケーションにJMSおよびJTAが必要な場合は、Oracle Data Guard DR構成を使用してデータがディザスタ・リカバリ・イベントから保護されるように、これらのすべての実行時アーチファクトをデータベース内に外部化することを推奨します。
データベース永続ストレージについて、詳しくは「JMSサーバーと永続ストアの構成」および「トランザクション・ログを永続化するためのデータベース・ストアの構成」を参照してください。
5.4. 新しいサイトでアプリケーションを停止する
簡潔にするため、MEDRECアプリケーションの詳細な停止手順は省略しています。
33 | Oracle Public Cloudでのディザスタ・リカバリ
5.5. スナップショット・スタンバイをフィジカル・スタンバイに変換する
プライマリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
convert database APPDBB to physical standby;
手順：サイト・テスト この手順を、スタンバイ・モードになっているサイトAまたはサイトBに適用できます。この事例の手順例として、サイトBで実行したサイト・テストを示しています。
1. スタンバイをスナップショット・スタンバイに変換する
プライマリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
convert database APPDBB to snapshot standby;
2. アプリケーションを起動してテストする
簡潔にするため、MEDRECアプリケーションの詳細な起動手順とテスト手順は省略しています。
手順：スタンバイへのサイト・テスト 以下の手順を、現在サイト・テスト・モードになっているサイトAまたはサイトBに適用できます。この事例の手順例として、サイトBで実行した手順を示しています。
1. テスト対象のアプリケーションを停止する
簡潔にするため、MEDRECアプリケーションの詳細な停止手順は省略しています。
2. スタンバイをフィジカル・スタンバイに変換する
プライマリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
convert database APPDBB to physical standby;
手順：スイッチオーバー スイッチオーバー手順を使用して、サイトAからサイトBにまたはサイトBからサイトAにスイッチオーバーを実行できます。ここでは、サイトAからサイトBに対して実行したスイッチオーバーの手順例を示しています。
出発点として、サイトAでアプリケーションが起動されて実行されており、サイトAのデータベース・サーバーを使用できることを前提としています。
以下の手順を実行します。
1. アプリケーションを停止する
簡潔にするため、MEDRECアプリケーションの詳細な停止手順は省略しています。
34 | Oracle Public Cloudでのディザスタ・リカバリ
2. Data Guardのスイッチオーバーを実行する
セカンダリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
switchover to APPDBB;
Data Guardのスイッチオーバー（計画イベント）またはフェイルオーバー（計画外イベント）をいつでも手動で実行できます。ファスト・スタート・フェイルオーバーを構成して、Data Guardのフェイルオーバーを自動化することも選択できます。スイッチオーバーを実行すると、Data Guard構成におけるデータベースのロールが逆になり、スタンバイがプライマリになり、元のプライマリがスタンバイ・データベースになります。Data Guardのロール移行について、詳しくはOracle MAAベスト・プラクティス17を参照してください。
3. 新しいプライマリ・サイトでアプリケーションを起動する
簡潔にするため、MEDRECアプリケーションの詳細な起動手順は省略しています。
手順：フェイルオーバー フェイルオーバー手順を使用して、サイトAからサイトBにまたはサイトBからサイトAにフェイルオーバーを実行できます。ここでは、サイトAからサイトBに対して実行したフェイルオーバーの手順例を示しています。
出発点として、サイトAに重大な障害が発生し、サイトAのデータベース・サーバーを使用できなくなったため、スイッチオーバーを実行できないことを前提としています。
以下の手順を実行します。
1. Data Guardのフェイルオーバーを実行する
セカンダリ・アプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
failover to APPDBB;
2. 新しいプライマリ・サイトでアプリケーションを起動する
簡潔にするため、MEDRECアプリケーションの詳細な起動手順は省略しています。
17 http://www.oracle.com/technetwork/jp/database/availability/maa-roletransitionbp-2621582-ja.pdf
35 | Oracle Public Cloudでのディザスタ・リカバリ
手順：スタンバイの復旧 フェイルオーバーを実行した後で、復旧手順を使用して、以前のプライマリ・データベースをスタンバイ・データベースとして復旧します。サイトAまたはサイトBで同じ手順を使用できます。ここでは、サイトBへのフェイルオーバー後にサイトAで実行した復旧の手順例を示しています。
1. データベースのマウントを起動する
サイトAのアプリケーション・データベース（appa）で、sysユーザーとして次のコマンドを実行します。
shutdown abort startup mount
2. スタンバイ・データベースを復旧する
サイトAのアプリケーション・データベース（APPDB）で、ログインしているsystemユーザーとして、Data Guard Brokerコマンドライン・インタフェース（dgmgrl）で次のコマンドを実行します。
reinstate database APPDB;
36 | Oracle Public Cloudでのディザスタ・リカバリ
付録B – Data Guardのヘルス・チェック スタンバイをインスタンス化したら、ヘルス・チェックを実行してData Guardデータベース（プライマリとスタンバイ）がOracle MAAベスト・プラクティスに準拠していることを確認します。ヘルス・チェックは、月に1回実行するとともに、データベースのメンテナンス作業の前後にも実行することを推奨します。Data Guard構成の状態をチェックする方法として、以下の方法があります。
Oracle MAAスコアカード
Oracleは自動ヘルス・チェック・ツールをいくつか提供しており、これらのツールはハードウェア・プラットフォームのタイプごとにMy Oracle Supportからダウンロードできます。
» ORAchk：汎用プラットフォームに適用可能（Database Cloud Serviceに最適）18
» exachk：Exadata Database Machineに適用可能（Exadata Cloud Serviceに最適）19
それぞれの自動チェックには、さまざまなチェック項目に加えてData Guard構成に関する多数の重要なベスト・プラクティスについてレポートする、Oracle MAAスコアカードが含まれています。
これらの自動ツールを使用して、Data Guard構成だけでなくシステム全体の包括的なヘルス・チェックを行うことを強く推奨します。ヘルス・チェックは、最新情報によって定期的に更新されます。使用しているプラットフォームに適用可能な、最新バージョンのヘルス・チェックをダウンロードするようにしてください。
Data Guard固有の問合せ（Oracle Database 11g以降で利用可能）
Data Guard構成の状態を検証するために使用できるData Guard固有の一連の問合せが、「付録C ‒ Data Guardの実行時監視問合せ」に出力例とともに記載されています。
Data GuardのVALIDATE DATABASE（Oracle Database 12c以降で利用可能）
Data Guard固有のヘルス・チェックをもっ とも包括的 に行う場合は、Data Guard BrokerのVALIDATE DATABASEコマンドを強く推奨します。VALIDATE DATABASEを使用すると広範な構成チェックが実行され、スイッチオーバーまたはフェイルオーバーがいつでもできる構成になっているかどうかが検証されます。
例：
DGMGRL> validate database APPDBB; Database Role: Physical standby database Primary Database: pri
Ready for Switchover: Yes Ready for Failover: Yes (Primary Running)
VALIDATE DATABASEコマンド20で実行される広範なチェックについて、詳しくはData Guard Brokerのドキュメントを参照してください。
18 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2 19 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1 20 https://docs.oracle.com/cd/E57425_01/121/DGBKR/dbresource.htm#DGBKR3855
37 | Oracle Public Cloudでのディザスタ・リカバリ
付録C – Data Guardの実行時監視問合せ このホワイト・ペーパーの公開時点では、Data Guard構成のスタンバイ・データベースを監視するには、コマンドでの問合せとスクリプトを使用する必要があります。監視する際の基本的な推奨事項として、次のようなものがあります。
1) REDO転送が機能しており転送ラグがないことを検証する - これは、REDOが適切なタイミングでスタンバイに送信されていることを意味します。
2) REDO Applyが機能しており適用ラグがないことを検証する - これは、受信時にREDOが適切なタイミングで適用されていることを意味します。
これらはいずれも、Data Guard BrokerまたはSQL*Plus問合せを使用して監視できます。
Data Guard Brokerによる監視 Data Guardによる監視では、show database <standby db_unique_name>コマンドで表示されるDatabase Statusに注目する必要があります。Database StatusがSUCCESSであれば、何も問題がないと考えられます。
DGMGRL> show database APPDBB; DGMGRL> Database - appdbb Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 2 seconds ago)
Apply Lag: 0 seconds (computed 2 seconds ago)
Average Apply Rate: 1.00 KByte/s Real Time Query: ON Instance(s): APPDB
Database Status: SUCCESS
転送または適用の機能に問題がある場合は、ステータスがWARNINGまたはERRORになります。
スタンバイ・データベースのApplyLagThresholdプロパティとTransportLagThresholdプロパティを設定すると、同じ手法（Database Status）でラグを監視できます。これらのプロパティはいずれも秒単位で表されます。これらのプロパティを0（ゼロ）以外の値に設定すると、値が上回ったときにDatabase StatusがWARNINGに変更されます。
SQL*Plusによる監視
REDO転送およびREDO Applyの検証
Data Guardでは基本的に、REDOがプライマリから転送されてからスタンバイに適用されます。以下に示す問合せを使用すると、これらの機能が正しく動作しているかどうかを検証できます。
プライマリ・データベースの問合せ：Data GuardREDO転送の現在の状態
プライマリ・データベースからスタンバイにREDOが送信されていることを検証するには、プライマリ・データベースで次の問合せを実行します。STATUSがVALIDであることが求められます。STATUSがVALID以外の場合は、追加情報とともにERRORと表示されます。プライマリ・データベースがOracle RACの場合に各プライマリ・インスタンスを検証するには、gv$archive_dest_statusを使用する必要があります。
38 | Oracle Public Cloudでのディザスタ・リカバリ
SQL> select sysdate,status,error from v$archive_dest_status where type='PHYSICAL'; SYSDATE STATUS ERROR -------------------- --------- ---------- 13-mar-2015 10:42:10 VALID
スタンバイ・データベースの問合せ：スタンバイへのREDO適用の現在の状態
スタンバイでは、REDOは受信されているが適用されていないことがあります。そのため、検証の一環として上記の問合せを実行します。スタンバイ・データベースでREDO適用が実行されていることを検証するには、次の問合せを実行します。RECOVERY_MODEが‘MANAGED REAL TIME APPLY’であれば、REDOは受信されると適用されています。GAP_STATUSは、プライマリからのREDO転送に欠落があるかどうかを示します。
SQL> select sysdate,database_mode,recovery_mode, gap_status from
v$archive_dest_status where type='PHYSICAL';
SYSDATE DATABASE_MODE RECOVERY_MODE GAP_STATUS
-------------------- --------------- ----------------------- ----------
13-mar-2015 10:43:44 OPEN_READ-ONLY MANAGED REAL TIME APPLY NO GAP
Data Guardのパフォーマンス（スタンバイ・ラグ）
正常に書き込まれたREDOがスタンバイに適用されていない状態を適用ラグと呼びます。適用ラグは、スタンバイのリソースが不足していることを示しており、よくある原因としてI/OまたはCPUの競合が挙げられます。REDOはスタンバイに存在し、フェイルオーバーの前に適用できるため、適用ラグが発生していてもデータ損失の可能性があるという意味ではありません。ただし、転送ラグが発生している場合は、スタンバイでのREDOの受信とREDOログへの書込みがタイミングよく行われていないことを意味するため、プライマリが失われると、書込みが完了していないデータが失われる可能性があります。
転送ラグはネットワーク待機時間が原因で発生することが多いですが、スタンバイのリソース不足が原因となることもあります。次の問合せを実行すると、いずれかのラグの発生状況とサイズを確認できます。
スタンバイ・データベースの問合せ：適用と転送のタイムラグの監視
適用ラグまたは転送ラグを特定するには、次の問合せを実行します。値が‘+00 00:00:00’の場合、ラグは発生していません。
select name,value,time_computed,datum_time from v$dataguard_stats where name like '%lag%';
NAME VALUE TIME_COMPUTED DATUM_TIME ------------- -------------------- ------------------------------ -------------------- transport lag +00 00:00:00 06/18/2015 09:26:29 06/18/2015 09:26:27
apply lag +00 00:00:00 06/18/2015 09:26:29 06/18/2015 09:26:27
スタンバイ・データベースの問合せ：転送ラグのサイズの監視
次の問合せを使用すると、転送ラグが発生している場合に、ブロック単位でどのくらいスタンバイがプライマリから遅れているかを確認できます。
s.sequence#, s.block# from v$thread t,
39 | Oracle Public Cloudでのディザスタ・リカバリ
gv$managed_standby s where s.process='LNS' and
t.LAST_REDO_SEQUENCE#=s.sequence#;
s.sequence#, s.block# from v$thread t,
gv$managed_standby s where s.process='LNS' and
t.LAST_REDO_SEQUENCE#=s.sequence#;
THREAD# LAST_REDO_SEQUENCE# LAST_REDO_BLOCK THREAD# SEQUENCE# BLOCK#
---------- ------------------- --------------- ---------- ---------- ----------
1 453 482 1 453 482
2 406 786 2 406 786
スタンバイ・データベースの問合せ：スタンバイの適用プロセスの監視
SQL> select sysdate,process,status,thread#,sequence#,block# from v$managed_standby where status!='IDLE'; SYSDATE PROCESS STATUS THREAD# SEQUENCE# BLOCK#
-------------------- --------- ------------ ---------- ---------- ----------
13-mar-2015 10:58:31 ARCH CLOSING 2 403 1
13-mar-2015 10:58:31 ARCH CONNECTED 0 0 0
13-mar-2015 10:58:31 ARCH CLOSING 1 449 1
13-mar-2015 10:58:31 ARCH CLOSING 2 402 4096
13-mar-2015 10:58:31 MRP0 APPLYING_LOG 2 404 1614
スタンバイ・データベースの問合せ：リカバリの監視（高度な監視）
次の問合せを使用すると、適用プロセスに関する貴重な情報（適用率、適用ラグなど）を収集できます。gv$recovery progressには、インスタンス存続中（インスタンスを再起動するまで）の履歴がリカバリの起動ごとに保持されます。この問合せでは、直前の起動のメトリックのみ選択しています。
S SQL> select start_time, item, units, sofar from gv$recovery_progress where
START_TIME in (select max(START_TIME) from v$recovery_progress);
START_TIM ITEM UNITS SOFAR --------- -------------------------------- -------------------------------- ---------- 18-JUN-15 Active Apply Rate KB/sec 23 18-JUN-15 Average Apply Rate KB/sec 1 18-JUN-15 Maximum Apply Rate KB/sec 24 18-JUN-15 Redo Applied Megabytes 0 18-JUN-15 Last Applied Redo SCN+Time 0 18-JUN-15 Active Time Seconds 42 18-JUN-15 Elapsed Time Seconds 576 18-JUN-15 Standby Apply Lag Seconds 1
40 | Oracle Public Cloudでのディザスタ・リカバリ
付録D – ヘルス・チェックの問合せ 「Data Guardのヘルス・チェック」で述べたように、Data Guard構成に対してベスト・プラクティスの定期的
なチェックを実行し、ベスト・プラクティスに準拠していることを確認する必要があります。「Data Guardのヘルス・チェック」で概説した自動化ツールは定期的に更新されるため、このツールを使用することを強く推奨します。ただし、ツールがない場合は次の問合せを実行できます。『Monitoring a Data Guard Configuration』（Doc ID 2064281.1）も参照してください。
スタンバイREDOログ（SRL）のヘルス・チェック
SRLに関しては、いくつかの異なるベスト・プラクティスがあります。
1. SRLグループの数は、スレッドごとに、オンラインREDOログ（ORL）グループの数+1である必要があり
ます。プライマリ・データベースとスタンバイ・データベースで次の問合せを実行します。
SQL> select thread#,count(group#)from v$log group by thread#;
THREAD# COUNT(GROUP#)
---------- ------------- 1 4
SQL> select thread#,count(group#)from v$standby_log group by thread#;
THREAD# COUNT(GROUP#) ---------- -------------
1 5
2. ログ・ファイル（ORLおよびSRL）はすべて同じサイズである必要があります。次の問合せを実行しま
す。この問合せでは、同じ1つの値が返される必要があります。
SQL> select distinct bytes from v$log;
SQL> select distinct bytes from v$log;
BYTES ---------- 4294967296
SQL> select distinct bytes from v$standby_log;
BYTES
----------
4294967296
41 | Oracle Public Cloudでのディザスタ・リカバリ
3. SRLグループのメンバーは1つのみである必要があります。次の問合せを実行して、すべてのグループの
count列が1であることを確認します。
SQL> select group#,count(member) from v$logfile where type='STANDBY' group by group#;
GROUP#
COUNT(MEMBER)
---------- -------------
5 1
6 1
7 1
8 1
9 1
フラッシュバック・データベースと強制ロギング
フェイルオーバー操作から容易に復旧できるように、フラッシュバック・データベースを有効化することを推奨します。次の問合せを実行して検証します。結果が‘YES’である必要があります。
SQL> select flashback_on from v$database;
FLASHBACK_ON ------------------ YES
nologgingを指定した問合せがプライマリ・データベースで実行された場合にデータが失われないようにするために、強制ロギングを有効化することを推奨します。次の問合せを使用して検証します。
SQL> select force_logging from v$database;
FORCE_LOGGING --------------------------------------- YES
その他のパラメータ
次のパラメータが適切に設定されていることを確認します。リカバリ時のパフォーマンスへの影響が大きすぎると思われる場合は、DB_BLOCK_CHECKINGをFALSEのままにしても構いません。
SQL> show parameter checking
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_checking string MEDIUM
SQL> show parameter checksum
42 | Oracle Public Cloudでのディザスタ・リカバリ
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------ db_block_checksum string FULL
SQL> show parameter lost_write
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_lost_write_protect string typical
SQL> show parameter disk_asynch_io
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
disk_asynch_io boolean TRUE
LOG_ARCHIVE_MAX_PROCESSES
LOG_ARCHIVE_MAX_PROCESSESの設定を、リモートの送信先の数（ほとんどの場合は1）にスレッド/インスタンスの数（Oracle RACの場合のみ2以上）を足した値と等しい数にする必要があります。次の問合せを使用して、現在の正しい設定を確認できます。
SQL> show parameter log_archive_max_processes
NAME TYPE VALUE
------------------------------------ ----------- ------------------------
log_archive_max_processes integer 2
SQL> select ((select count(1) from v$archive_dest where
TARGET='STANDBY') + (select count(distinct thread#) from v$log))
PROPER_LOG_ARCHIVE_MAX_PROC from dual;
PROPER_LOG_ARCHIVE_MAX_PROC ---------------------------
2
43 | Oracle Public Cloudでのディザスタ・リカバリ
付録E – クライアント・フェイルオーバーの構成 クライアント・フェイルオーバー（障害発生後にアクティブなプライマリ・データベースにクライアントを再接続するプロセス）の自動化には、Data Guardのフェイルオーバーの一環としてデータベース・サービスを新しいプライマリ・データベースに再配置する処理、クライアントをTCPタイムアウトから抜けさせるために障害が発生したことをクライアントに通知する処理、クライアントを新しいプライマリ・データベースにリダイレクトする処理が含まれます。構成方法は、クライアント・フェイルオーバーのOracle MAAベスト・プラクティスを紹介しているホワイト・ペーパー、Database 11g用21およひOracle Database 12c用22に詳しく記載されています。これらのホワイト・ペーパーを参照して環境を適切に構成してください。
付録F – ウォレットの作成と分散
12cでのウォレットの作成と分散
1. 暗号化ウォレットを作成します。
プライマリおよびスタンバイのすべてのノードのsqlnet.oraにウォレットの場所を設定します。
ENCRYPTION_WALLET_LOCATION =
(SOURCE = (METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/TDE/$ORACLE_SID)
)
)
NOTE: Using ORACLE_SID in the directory path ensures that all databases do not share the wallet. If there is just one database on the system the ORACLE_SID is not necessary.
2. 適切なORACLE_SIDを使用して、対応するディレクトリをすべてのノードに作成します。
$mkdir -p /u01/app/oracle/admin/TDE/$ORACLE_SID
3. 新しいSQL*Plusセッションを起動します。これにより、選択されるsqlnet.oraが変わります。
4. パスワードベースのキーストアを作成します。
SQL>ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'/u01/app/oracle/admin/TDE/<ORACLE_SID>' IDENTIFIED BY "AbCdEfGh!";
21 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf 22 http://www.oracle.com/technetwork/jp/database/availability/client-failover-2280805-ja.pdf
44 | Oracle Public Cloudでのディザスタ・リカバリ
注：パスワードの文字列は必ず二重引用符（" "）で囲みます。
5. ウォレットを開きます。
SQL>ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "AbCdEfGh!";
6. 暗号化鍵を設定します。
SQL>ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "AbCdEfGh!" WITH
BACKUP USING 'TDE';
7. 自動ログイン・ウォレットを作成します。
自動ログイン・ウォレットがあると、データベースを起動するときに手動でウォレットを開く必要がなくなります。
SQL>ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
'/u01/app/oracle/admin/TDE/$ORACLE_SID' IDENTIFIED BY “AbCdEfGh!”;
8. プライマリおよびスタンバイのすべてのノードに、キーストア・ディレクトリに生成されたファイルを
コピーします。ファイルを各ノードにコピーします。 $scp /u01/app/oracle/admin/TDE/$ORACLE_SID/*
oracle@<host>:/u01/app/oracle/admin/TDE/<SID_NAME>/
9. すべてのノードでウォレットが開いていることを確認します。
SQL> select * from gv$encryption_wallet; INST_ID WRL_TYPE WRL_PARAMETER STATUS
---------- -------------------- --------------------------------------------- ----------------------------------- ------------------
1 file /u01/app/oracle/admin/TDE/primary1
OPEN
11gR2でのウォレットの作成と分散
1. 暗号化ウォレットを作成します。
プライマリおよびスタンバイのすべてのノードのsqlnet.oraにウォレットの場所を設定します。
ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/TDE/$ORACLE_SID)
)
)
45 | Oracle Public Cloudでのディザスタ・リカバリ
2. 適切なORACLE_SIDを使用して、対応するディレクトリをすべてのノードに作成します。
$mkdir -p /u01/app/oracle/admin/TDE/$ORACLE_SID
3. 新しいSQL*Plusセッションを起動します。これにより、選択されるsqlnet.oraが変わります。
4. マスター暗号化鍵を設定します。
SQL>ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "AbCdEfGh!"
注：パスワードの文字列は必ず二重引用符（" "）で囲みます。
5. 自動ログイン・ウォレットを作成します。
自動ログイン・ウォレットがあると、データベースを起動するときに手動でウォレットを開く必要がなくなります。
$ orapki wallet create -wallet /u01/app/oracle/admin/TDE/$ORACLE_SID - auto_login
6. プライマリおよびスタンバイのすべてのノードに、キーストア・ディレクトリに生成されたファイルを
コピーします。ファイルを各ノードにコピーします。 $ scp /u01/app/oracle/admin/TDE/$ORACLE_SID/* oracle@<host>:/u01/app/oracle/admin/TDE/<SID_NAME>/
7. すべてのノードでウォレットが開いていることを確認します。
SQL> select * from gv$encryption_wallet; INST_ID WRL_TYPE WRL_PARAMETER STATUS ---------- -------------------- --------------------------------------------- ----------------------------------- ------------------ 1 file /u01/app/oracle/admin/TDE/primary1 OPEN
46 | Oracle Public Cloudでのディザスタ・リカバリ
付録G – Database Backup Cloud Serviceからのスタンバイのインスタンス化 ここでは、Oracle Database Backup Cloud Serviceからデータベースを作成するときに必要となる手順について説明します。ソース・データベースのDBIDを把握している必要があります。また、CONTROLFILEをAUTOBACKUPでバックアップしておく必要があります。
1. Cloud VMにCloud Backup Toolをインストールします。
プライマリ・データベース・マシンの場合と同じ方法で、Oracle Public Cloud VMでライブラリとウォレットを作成しておく必要があります。次の手順でライブラリ（libopc.so）をダウンロードし、Oracleウォレットおよびopc<SID>.ora構成ファイルを作成します。
例：
$ mkdir -p /u01/app/oracle/OPC/wallet
$ mkdir -p /u01/app/oracle/OPC/lib
$ export ORACLE_SID=stby
$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1 $ java -jar opc_install.jar -serviceName <defined service name> - identityDomain <backup service domain> -opcId '<[email protected]>' -opcPass '<OPC password>' -walletDir /u01/app/oracle/OPC/wallet -libDir
/u01/app/oracle/OPC/lib Oracle Database Cloud Backup Module Install Tool, build 2015-05-12 Oracle Database Cloud Backup Module credentials are valid.
Oracle Database Cloud Backup Module wallet created in directory
/u01/app/oracle/OPC/wallet.
Oracle Database Cloud Backup Module initialization file /u01/app/oracle/product/12.1.0/dbhome_1/dbs/opcstby.ora created. Downloading Oracle Database Cloud Backup Module Software Library from file opc_linux64.zip. Downloaded 23169388 bytes in 20 seconds. Download complete.
2. プライマリ・データベースからDBIDを取得します。 SQL> select dbid from v$database;
DBID
----------
812240971
47 | Oracle Public Cloudでのディザスタ・リカバリ
3. Oracle Public Cloud VMでインスタンスを起動し、DBIDとパスワードを設定し、バックアップからspfile
をリストアし、リストアしたspfileからpfileを作成します。
$ rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Fri Jul 24 12:25:24 2015 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database (not started)
RMAN> startup nomount force startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/12.1.0/dbhome_1/dbs/initstby.ora'
starting Oracle instance without parameter file for retrieval of spfile Oracle instance started
Total System Global Area 1073741824 bytes
Fixed Size 2932632 bytes Variable Size 281018472 bytes Database Buffers 784334848 bytes Redo Buffers 5455872 bytes
RMAN> set dbid 812240971; executing command: SET DBID
RMAN> set decryption identified by <password used when taking backup>;
executing command: SET decryption RMAN> run { allocate channel dev1 device type sbt parms='SBT_LIBRARY=/u01/app/oracle/OPC/lib/libopc.so'; restore spfile TO '/tmp/spfile.ora' from autobackup;
}
allocated channel: dev1
channel dev1: SID=12 device type=SBT_TAPE channel dev1: Oracle Database Backup Service Library VER=3.15.1.16
Starting restore at 24-JUL-15
48 | Oracle Public Cloudでのディザスタ・リカバリ
channel dev1: looking for AUTOBACKUP on day: 20150724 channel dev1: looking for AUTOBACKUP on day: 20150723 channel dev1: AUTOBACKUP found: c-812240971-20150723-00 channel dev1: restoring spfile from AUTOBACKUP c-812240971-20150723-00 channel dev1: SPFILE restore from AUTOBACKUP complete Finished restore at 24-JUL-15 released channel: dev1
RMAN> create pfile='/tmp/pfile' from spfile='/tmp/spfile.ora'; Statement processed
RMAN> exit
Recovery Manager complete.
4. pfileを編集し、少なくとも以下の変更を加えます。
» ダブル・アンダースコアの'<primary>.__*'パラメータをすべて削除する
» マウント・ポイント/u02および/u03を使用してcontrol_filesを変更する
*.control_files='/u02/app/oracle/oradata/<db_unique_name>/control01.ctl','
/u03/app/oracle/fast_recovery_area/<db_unique_name>/control02.ctl'
» 次の行を記載どおりに変更または設定する
*.db_create_file_dest='/u02/app/oracle/oradata'
*.db_create_online_log_dest_1='/u02/app/oracle/oradata'
*.db_create_online_log_dest_2='/u04/app/oracle/redo'
*.db_recovery_file_dest='/u03/app/oracle/fast_recovery_area'
*.dg_broker_start=FALSE *.log_archive_dest_1='location=USE_DB_RECOVERY_FI
LE_DEST','valid_for=(ALL_LOG FILES, ALL_ROLES)' *.diagnostic_dest='/u01/app/oracle'
» • 次の行を削除する（存在する場合）
*.dg_broker_config_file1
*.dg_broker_config_file2
*.db_domain
*.fal_server
*.log_archive_config
49 | Oracle Public Cloudでのディザスタ・リカバリ
» 使用する環境に応じて、以下を変更する
*.db_unique_name=’<standby_db_unique_name>’
*.local_listener='LISTENER_STBY'
*.audit_file_dest='/u01/app/oracle/admin/<standby_db_unique_name>/adump'
*.db_file_name_convert='< datafile location >', '/u02/app/oracle/oradata' *.log_file_name_convert='< logfile location 1 >', '/u04/app/oracle/redo',
'< logfile location 2 >', '/u02/app/oracle/oradata'
注：複数のマウント・ポイントにファイルが分散されている場合は、db_file_name_convertのエントリがさらに必要になります。データファイルへのパスごとに、‘<primary path>/${PRIMARY_DBNM}’、'${secondary path}/${SECONDARY_DBNM}'のペアが必要です。データファイルへのパスは、‘select name from v$datafile;’でプライマリ・データベースから取得します。
注：複数のマウント・ポイントにログ・ファイルが分散されている場合は、log_file_name_convertのエントリがさらに必要になります。ログ・ファイルへのパスごとに、‘<primary path>/${PRIMARY_DBNM}’、'${secondary path}/${SECONDARY_DBNM}'のペアが必要です。ログ・ファイルのパスは、‘select member from v$logfile;’でプライマリ・データベースから取得します。
5. adump、制御ファイル、およびデータファイル用のディレクトリを作成します。
$mkdir -p /u01/app/oracle/admin/<standby_db_unique_name>/adump
$mkdir -p /u02/app/oracle/oradata/<db_unique_name>/
$mkdir -p /u03/app/oracle/fast_recovery_area/<db_unique_name>
6. 編集済みのpfileから新しいspfileを作成し、データベースを再起動します。
$ rman target / Recovery Manager: Release 12.1.0.2.0 - Production on Fri Jun 3 14:13:16 2016 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. connected to target database: APPDB (DBID=812240971, not open) RMAN> create spfile from pfile='/tmp/pfile'; Statement processed RMAN> startup nomount force;
50 | Oracle Public Cloudでのディザスタ・リカバリ
Oracle instance started Total System Global Area 838860800 bytes Fixed Size 2929936 bytes Variable Size 608176880 bytes Database Buffers 222298112 bytes Redo Buffers 5455872 bytes
7. プライマリのバックアップからスタンバイ制御ファイルをリストアします。
RMAN> set dbid 812240971; executing command: SET DBID
RMAN> set decryption identified by welcome1; executing command: SET decryption
RMAN> run { allocate channel dev1 device type sbt parms='SBT_LIBRARY=/u01/app/oracle/OPC/lib/libopc.so'; restore standby controlfile from autobackup; alter database mount;
}
allocated channel: dev1
channel dev1: SID=12 device type=SBT_TAPE
channel dev1: Oracle Database Backup Service Library VER=3.15.1.16
Starting restore at 03-JUN-16 channel dev1: looking for AUTOBACKUP on day: 20150724 channel dev1: looking for AUTOBACKUP on day: 20150723 channel dev1: AUTOBACKUP found: c-812240971-20150723-00 channel dev1: restoring control file from AUTOBACKUP c-812240971-20150723-00 channel dev1: control file restore from AUTOBACKUP complete output file name=/u02/app/oracle/oradata/stby/control01.ctl output file name=/u03/app/oracle/fast_recovery_area/stby/control02.ctl Finished restore at 03-JUN-16
Statement processed released channel: dev1
RMAN> exit
51 | Oracle Public Cloudでのディザスタ・リカバリ
8. 新しい制御ファイルを使用してOracle RMANに再接続し、バックアップ・サービスからデータベースを
リストアします。
$ rman target / Recovery Manager: Release 12.1.0.2.0 - Production on Fri Fri Jun 3 14:13:16 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. connected to target database: PRI (DBID=812240971, not open)
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/u01/app/oracle/OPC/lib/libopc.so, ENV=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/opcstby.ora)';
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/home/oracle/OPC/lib/libopc.so, ENV=(OPC_PFILE=/home/oracle/app/oracle/product/12.1.0/dbhome_1/dbs/opcpri.ora )';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/u01/app/oracle/OPC/lib/libopc.so, ENV=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_1/db/opcstby.ora)'; new RMAN configuration parameters are successfully stored
RMAN> set decryption identified by
<password used for backup>;
executing command: SET decryption using target database control file instead of recovery catalog
RMAN> run { set newname for database to '/u02/app/oracle/oradata/stby/datafile/%b'; restore database;
switch datafile all;
}
2> 3> 4> 5>
executing command: SET NEWNAME
52 | Oracle Public Cloudでのディザスタ・リカバリ
Starting restore at 03-JUN-16 using channel ORA_SBT_TAPE_1 using channel ORA_DISK_1
channel ORA_SBT_TAPE_1: starting datafile backup set restore channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set channel ORA_SBT_TAPE_1: restoring datafile 00001 to /u02/app/oracle/oradata/stby/datafile/system01.dbf channel ORA_SBT_TAPE_1: restoring datafile 00003 to /u02/app/oracle/oradata/stby/datafile/sysaux01.dbf channel ORA_SBT_TAPE_1: restoring datafile 00004 to /u02/app/oracle/oradata/stby/datafile/undotbs01.dbf channel ORA_SBT_TAPE_1: restoring datafile 00006 to /u02/app/oracle/oradata/stby/datafile/users01.dbf channel ORA_SBT_TAPE_1: reading from backup piece 5dqcoqd8_1_1
channel ORA_SBT_TAPE_1: piece handle=5dqcoqd8_1_1 tag=TAG20150723T104704 channel ORA_SBT_TAPE_1: restored backup piece 1 channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:02:55 Finished restore at 03-JUN-16
datafile 1 switched to datafile copy input datafile copy RECID=5 STAMP=885912874 file name=/u02/app/oracle/oradata/stby/datafile/system01.dbf datafile 3 switched to datafile copy input datafile copy RECID=6 STAMP=885912875 file name=/u02/app/oracle/oradata/stby/datafile/sysaux01.dbf datafile 4 switched to datafile copy input datafile copy RECID=7 STAMP=885912876 file name=/u02/app/oracle/oradata/stby/datafile/undotbs01.dbf datafile 6 switched to datafile copy input datafile copy RECID=8 STAMP=885912877 file name=/u02/app/oracle/oradata/stby/datafile/users01.dbf
RMAN> exit
Recovery Manager complete.
9. Data Guard Brokerの構成を完了します。例として、「4.7.Data Guard Brokerを構成する」を参照してくだ
さい。
Copyright © 2016, Oracle and/or its affiliates.All rights reserved..
本文書は情報提供のみを目的として提供されており、記載内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証する
ものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含
み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直
接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のた
めにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,
Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。
UNIXは、The Open Groupの登録商標です。0615
海外からのお問い合わせ窓口： 電話：+1.650.506.7000
ファクシミリ：+1.650.506.7200
