Oracle Cloudへのディザスタ・リカバリ

Transcription

1 Oracle Cloud へのディザスタ リカバリ 本番はオンプレミス DR はクラウド Oracle ホワイト ペーパー 2018 年 2 月

2 目次 はじめに... 1 Data Guard および Active Data Guard によるクラウドへのディザスタ リカバリ... 2 Oracle Cloud での DR の有効化... 2 サービス レベル要件... 4 セキュリティ要件... 4 データベース 動作環境 前提条件... 6 デプロイメント プロセス Oracle Database Cloud Service にサブスクライブする Oracle インスタンスを作成する オンプレミスのプライマリ データベース動作環境を準備する Oracle Cloud の動作環境の準備 Data Guard スタンバイのインスタンス化 Data Guard のヘルス チェックを実行する 実行時監視を有効にする REDO 転送圧縮を有効化する ( オプション ) DR の動作 DR の準備状況の検証 スタンバイ データベースの使用による計画メンテナンス中の停止時間の短縮 クラウドへのフェイルオーバー / スイッチオーバー オンプレミスへのスイッチバック アプリケーション層への接続 フル スタック フェイルオーバー : アプリケーション層とデータベース層 結論 付録 付録 A Data Guard の実行時監視問合せ 付録 B Oracle Restart のインストール ORACLE PUBLIC CLOUD でのディザスタ リカバリ 本番はオンプレミス DR はクラウド

3 付録 C TCP ソケット サイズの設定 付録 D インスタンス化 付録 E Recovery Manager の DUPLICATE を使用したスタンバイ データベースの作成 付録 F Data Guard Broker 付録 G ヘルス チェック問合せ 付録 H スタンバイ データベースからスナップショット スタンバイへの変換 付録 I クライアント フェイルオーバーの構成 付録 J ウォレットの作成と分散 付録 K Oracle Database Backup Cloud Service からのスタンバイのインスタンス化 付録 L ー rsync_copy.sh スクリプトのセットアップと使用方法 ORACLE PUBLIC CLOUD でのディザスタ リカバリ 本番はオンプレミス DR はクラウド

4 はじめに Oracle Maximum Availability Architecture(Oracle MAA) は プライベート クラウド パブリック クラウドまたはハイブリッド クラウドにデプロイされる Oracle データベースのデータを保護し可用性を高めるためのベスト プラクティス構想です Oracle Data Guard および Oracle Active Data Guard により バックアップからのリストアではリカバリ時間目標 (RTO) を達成することのできないデータベースのディザスタ リカバリ (DR) を実現できます これらのソリューションを利用して本番データベース ( プライマリ データベース ) の同期レプリカ ( スタンバイ データベース ) を物理的に離れた場所に 1 つ以上デプロイし ミッション クリティカルなデータの高可用性 包括的なデータ保護 およびディザスタ リカバリを実現します 有効なディザスタ リカバリ計画には リモート データセンターの設置 装置の整備 および管理が関係しており かなりのコストがかかる可能性があります Oracle Cloud は スタンバイ データベースをホスティングするための優れた代替手段であり DR サイトを設置していない場合や リモート データセンターの管理に伴うコストや煩雑さを避けたい場合に最適です 既存の本番データベースはオンプレミスに残し DR 用のスタンバイ データベースを Oracle Cloud 上にデプロイします このデプロイメント モードは 一般にハイブリッド クラウド実装と呼ばれます 要件に応じて Data Guard と Active Data Guard のどちらかのスタンバイをクラウド上にデプロイするよう選択できます ハイブリッド クラウド DR 構成の場合には 特有の考慮事項がいくつかありますが 他の Data Guard デプロイメントの場合と同じ Oracle MAA のベスト プラクティスが適用されます この Oracle MAA 構想では Oracle MAA のベスト プラクティスについて詳しく説明し Database as a Service を使用して Oracle Cloud 上に DR をデプロイする手順の概要を示します このホワイト ペーパーの対象読者は Oracle Database Data Guard または Active Data Guard および Oracle Database のバックアップとリカバリに関する知識を持つ技術者です またこのホワイト ペーパーでは Oracle Cloud で提供されるサービスについての基本的な理解があることも前提としています 1 Oracle Database Cloud Service は 特定の構成において オンプレミスとクラウドの間に Hybrid Data Guard をデプロイできるようになっています ドキュメント 2 を参照してください ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

5 Data Guard および Active Data Guard によるクラウドへのディザスタ リカバリ Oracle Cloud 3 では お客様に固有の要件に応じて Platform as a Service(PaaS) Infrastructure as a Service(IaaS) Software as a Service(SaaS) などの広範なクラウド サービスを提供できます オンプレミス システムのディザスタ リカバリ (DR) は Oracle Database Cloud Service 4 (PaaS) を使用してデプロイします Oracle Database Cloud Services を使用したクラウドへの 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 Services のすべてのエディション (Enterprise High Performance および Extreme Performance) でサポートされています Active Data Guard は Data Guard の機能を拡張したもので データ保護および可用性を目的とし た高度な機能のほか 読取り専用ワークロードやバックアップを本番データベースからオフロードする機能も備えています Active Data Guard は Extreme Performance Database Cloud Service と Exadata Service に組み込まれています ハイブリッド構成で使用する場合は オンプレミス システムでも Active Data Guard のライセンスを取得する必要があります Active Data Guard でライセンス提供される機能について詳しくは Oracle ソフトウェアのライセンスに関するドキュメント 5 を参照してください 特に記載がない限り このホワイト ペーパーで説明する手順は Data Guard と Active Data Guard の両方に適用されます Data Guard および Active Data Guard について詳しくは Oracle Technology Network の Data Guard ホームページおよび Active Data Guard ホワイト ペーパー 6 を参照してください 注 :Data Guard は Oracle Database Cloud Service - 仮想イメージ サービス レベルを使用してデプロイすることもできます 仮想イメージ サービス レベルは 開発インスタンスまたはテスト インスタンスの場合には適切ですが この基本サービスに組み込まれている自動化のレベルが低くツールも少ないため オンプレミスの本番データベースの DR としては推奨されません Oracle Cloud での DR の有効化 クラウドで DR を有効化してオンプレミス データベースを保護するには Oracle Database Cloud Service で Data Guard スタンバイ データベースをインスタンス化する必要があります インスタンス化されると Data Guard により オンプレミスのプライマリ データベースとクラウドのスタンバイ データベースの同期が維持されます Oracle Cloud は オンプレミス データベースが何らかの理由で使用できなくなった場合のディザスタ リカバリで必要とされるバックエンド インフラストラクチャと機能をすべて備えています これには 次のものが含まれます ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

6 1. スタンバイ データベースを監視し 大きな問題の発生時にアラートを発信する機能 付録 A を参照してください 2. スタンバイ データベースをアクティブ化して DR の準備状況を検証し 同期されたスタンバイ データベースに変換して戻す機能 3. オンプレミスのデプロイメントと同じ Oracle MAA のベスト プラクティスの利用 このホワイト ペーパーで説明されている ハイブリッド クラウド デプロイメントに固有の Oracle MAA の追加ベスト プラクティスの使用 4. 計画メンテナンスや計画外停止の期間に 本番データベースをクラウド内のスタンバイ データベースにスイッチオーバー ( 計画イベント ) またはフェイルオーバー ( 計画外イベント ) する機能 障害が発生したオンプレミス データベースの修復後に そのデータベースをクラウド内の新しい本番データベースと自動的に再同期させ 本番データベースをオンプレミス データベースに切り替える機能 5. Data Guard のスイッチオーバーまたはフェイルオーバーに続いて オンプレミスのアプリケーション層から Oracle Cloud の新しいプライマリ データベースにデータベース接続をフェイルオーバーする機能 6. サイトが完全に停止した場合に アプリケーション層とデータベース層の両方を Oracle Cloud にフェイルオーバーし Oracle Cloud で本番アプリケーションが正常に実行できるようにする機能 7. ディザスタ リカバリ以外のユースケースに対応可能な Oracle Cloud 内のスタンバイ データベースの柔軟性 たとえば 読取り専用本番ワークロードをクラウドにオフロードしたり 開発やテストを実施したり シン プロビジョニングされたデータベース クローンのソースとして使用したり バックアップをクラウドにオフロードしたりすることができます ( 図 1 を参照 ) 図 1: ハイブリッド クラウド : ディザスタ リカバリ 3 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

7 サービス レベル要件 ハイブリッド クラウド デプロイメントは 定義上 ユーザー管理の環境です 管理者は 可用性 データ保護 およびパフォーマンスについて 所定の構成およびアプリケーションの場合に期待する実際的なサービス レベルを決める必要があります サービス レベルは すべての Data Guard 構成に適用される ディザスタ リカバリに関係した次の 3 つの次元ごとに設定する必要があります» 可用性 : リカバリ時間目標 (RTO) は 停止した場合の最大許容停止時間を表します これには 停止を検出し データベースとアプリケーションの両方の接続をフェイルオーバーしてサービスが再開されるまでに必要な時間が含まれます» データ保護 : リカバリ ポイント目標 (RPO) は 許容可能な最大データ損失量を表します 望ましい RPO を達成できるかどうかは 次の要因に左右されます» ネットワークのデータ量に対する使用可能な帯域幅» 信頼性が高く中断することのない送信を実現するネットワークの能力» Data Guard で使用される転送方式 ( データ損失をほぼゼロに抑える非同期方式 またはデータ損失をゼロに抑える同期方式のいずれか )» パフォーマンス : スタンバイ システムでプロビジョニングされている計算 メモリ I/O などの能力がオンプレミスの本番システムよりも劣っていると データベースの応答時間がフェイルオーバー後に変わる可能性があります 管理者がコストを削減するために意図的に少ないリソースでスタンバイ システムを構成し DR モード中はサービス レベルが低下することを容認している場合に この状態が発生します Oracle MAA のベスト プラクティスでは プライマリとスタンバイの両方を同容量のリソースで構成し フェイルオーバー後も応答時間が変わらないようにすることを推奨しています クラウドでは高速プロビジョニングが使用可能なため 安定状態では少ない容量でデプロイされ フェイルオーバーが必要になった場合には新しいプライマリが高速にスケールアップされるようにする という中間的な構成が可能です 注 :DR に関連したサービス レベルに関係なく Oracle Cloud で作成されるすべてのスタンバイ データベース インスタンスは 該当する Database Cloud Service 7 によって定義されるサービス ディスクリプションに準拠しています セキュリティ要件 Oracle MAA のベスト プラクティスでは オラクルの透過的データ暗号化 (TDE) を使用してプライマリ データベースとスタンバイ データベースを暗号化するよう推奨しています TDE に変換することにより すべての DATA/INDEX 表領域における格納データの自動暗号化と クラウドとの間でのレプリケーションにおけるユーザー データの REDO 変更の移動時暗号化を有効化できます TDE によって暗号化されないその他の REDO 変更 ( 暗号化されていない表領域からのデータなど ) の移動時暗号化では Oracle Net の暗号化も必要となります ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

8 Oracle Cloud にデプロイされる本番データベースはデフォルトで暗号化されるため ディザスタ リカバリで使用されるハイブリッド クラウド デプロイメントの場合 格納データの暗号化のために TDE を使用することは必須ではありません ただし レプリケーション時にすべての REDO に移動時暗号化を行う場合は Oracle Net の暗号化が必要です これにより ハイブリッド クラウド構成のオンプレミス本番データベースを使用している場合は TDE を使用するかどうかを要件に応じて決めることができます 暗号化されるクラウド データベースと暗号化されないオンプレミス データベースを共存させることは可能ですが 技術的な注意事項とライセンスに関する考慮事項がいくつかあります 詳しくは MOS Doc ID を参照してください TDE を使用してデータを保護することは システムのセキュリティを強化する上で重要です ただしユーザーは いずれの暗号化ソリューションを使用する場合であっても 以下に示す特定の考慮事項があることを認識している必要があります» CPU オーバーヘッドの増大 : 暗号化では 暗号化された値と復号された値を計算するための追加の CPU サイクルが必要となります ただし TDE は データベースのキャッシング機能を利用し Intel や SPARC の CPU で処理される AES のハードウェア アクセラレーションを利用することによって オーバーヘッドが最小限に抑えられるように最適化されています 大半の TDE ユーザーは TDE を有効化した後の本番システムのパフォーマンスへの影響がほとんどないことを認めています パフォーマンスのオーバーヘッドに関して詳しくは Oracle Database Advanced Security ガイド 8 を参照してください» データ圧縮率の低下 : 元のプレーン テキスト データに関する情報が一切開示されないため 暗号化されたデータはわずかしか圧縮されていません そのため TDE で暗号化されたデータの圧縮率は どのような圧縮方式を適用した場合でも低くなります したがって TDE 暗号化は REDO 転送圧縮で使用することは勧められません ただし Oracle Advanced Compression や Hybrid Columnar Compression といった Oracle データベースの圧縮テクノロジーと TDE を併用する場合は 暗号化の前に圧縮が実行されるため 圧縮と暗号化の両方の利点を活かすことができます» 鍵の管理 : 暗号化の強度は 暗号化に使用される鍵の強度によって決まります さらに 暗号化鍵を失うことは その鍵によって保護されているすべてのデータを失うことと同じです 暗号化が有効になっているデータベースの数が少ない場合は 鍵とそのライフサイクルを比較的簡単に追跡できます しかし 暗号化されるデータベースの数が増えれば 鍵の管理もより難しくなります 数多くの暗号化データベースを使用する場合は オンプレミスで Oracle Key Vault 9 を使用して TDE マスター鍵を保管および管理することを推奨します ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

9 データベース 動作環境 前提条件 ハイブリッド クラウド DR 構成の前提条件を表 1 のサポート マトリックスに示します オペレーティング システム オンプレミス Linux Windows またはSolaris X86(Data Guardのクロス プラットフォームの互換性については My Oracle Support Note を参照 ) Oracle Database* Oracle Database Enterprise Edition (64 ビット ) ( または ) Oracle Database Enterprise Edition (64 ビット ) ( または ) Oracle Database Enterprise Edition (64 ビット ) Oracle Database Cloud Service Oracle Enterprise Linux(64 ビット ) Data Guard: Database as a Service( または ) 仮想イメージ : Enterprise High Performance および Extreme Performance の各エディション Active Data Guard: Database as a Service( または ) 仮想イメージ : Extreme Performance Edition ( または ) Exadata Cloud Service RAC RAC または非 RAC RAC** または非 RAC 10 物理 / 仮想物理または仮想仮想 データベース サイズ クラウド ターゲットでサポートされるサイズ DBCS(OCI-C): バックアップありで 4.6 TB*** バックアップなしで 12 TB*** Exadata Cloud Service: バックアップありで最大 TB**** バックアップなしで最大 TB**** 暗号化 オプション データを明示的または暗黙的に暗号化または復号する場合は オンプレミスで TDE のライセンスを取得する必要があります 詳しくは MOS Doc ID を参照してください OCIについて詳しくは Oracle Databases 12.2 以上の場合 新しい表領域は暗号化されます 詳しくは MOS Doc ID を参照してください 表 1: サポート マトリックス * プライマリ データベースとスタンバイ データベースとでは バージョンが同じか非常に近い Oracle Database を使用することを強く推奨します Oracle Cloud 環境では オンプレミスでは検出されない特定のソフトウェア アップデートが存在する可能性があるため 互換ソフトウェアの少々の違いは許容されます ** 可用性によります 最新情報については Oracle Database Cloud Service のドキュメントを参照してください *** 変更される場合があります 最新情報については Oracle Database Cloud Service のドキュメントを参照してください **** Oracle Exadata X7.2 フル ラック仕様に基づきます 将来変更される場合があります ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

10 オンプレミスから Oracle Cloud へのデータ転送では Oracle FastConnect によって提供されるパブリック ネットワークまたは高帯域オプションが使用されます Oracle Exadata Cloud( データベース層 ) および Oracle Dedicated Compute( アプリケーション層 ) では 仮想プライベート ネットワーク (VPN) のオプションも使用可能です 将来的に可用性を高めるため ネットワークと VPN の追加オプションも計画されています 最新情報については Oracle Network Cloud Service 11 を参照してください デプロイメント プロセス 1. Oracle Database Cloud Serviceにサブスクライブする Oracle Database Cloud Service 12 にサブスクライブすることから始めます 通常これは 前払い式のサブスクリプションとして一定期間提供されます サブスクリプション アクティブ化 およびサービス作成について詳しくは DBaaS クラウドのドキュメント 13 を参照してください 2. Oracleインスタンスを作成するサービスのアクティブ化後は サービス コンソールからデータベース インスタンスを作成できます データベース サービスの作成について詳しくは DBCS クラウド ドキュメントの 14 Database Cloud Service のライフ サイクルの管理を参照してください 注 : クラウド VM で自動生成スクリプトと構成を保持するため 構成に含めるスタンバイ DB の名前をサービス名および SID として入力することを推奨します この例では STBY をサービス名および SID として使用します 3. オンプレミスのプライマリ データベース動作環境を準備する 次のステップを実行して Hybrid Data Guard のオンプレミスの動作環境を準備します 3.1 オンプレミス ネットワークの準備 アクセス権を設定するオンプレミスのファイアウォールでは オンプレミス システムと Oracle Cloud VM の間で ssh と Oracle Net のトラフィックを許可することが必要になります DR シチュエーションの Data Guard では クラウド インスタンスからオンプレミスのデータベースにアクセスする必要があるため iptables などの機能を使用してクラウドの IP アドレスからのアクセスには制限を設けつつ プライマリ データベースのリスナー ポートを開いておく必要があります ネットワーク アドレス変換 (NAT) およびファイアウォールを通過するアクセスに関するネットワーク セキュリティ ポリシーは企業ごとに異なるた ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

11 め ネットワーク管理者は 以下のセクションに示すクラウド側のネットワーク構成に類似 した操作を実行することが必要になります Exadata Service で仮想プライベート ネットワーク (VPN) を使用すると 構成が簡素化されます 名前解決を設定するアプリケーション層では Oracle Cloud VM への名前解決が設定されている必要があります この設定は /etc/hosts のような静的ファイルを使用するか Oracle Cloud インスタンスのパブリック IP アドレスが正しく解決されるようにオンプレミス DNS を設定することによって行うことができます オンプレミスとクラウドの間でプロンプトレス ssh を設定するプロンプトレス ssh を双方向に設定する必要があります クラウド環境からオンプレミス環境への ssh 鍵を生成します 注 : クラウドのデプロイメント時にプライマリ マシンの公開鍵が使用されたと想定します Oracle Cloud 環境で ssh 鍵を生成し ファイルをクラウドにコピーします $ ssh-keygen $ scp ~/.ssh/id_rsa.pub oracle@<onpremisesip>:~/.ssh/id_rsa.pub_cloud オンプレミス プライマリ データベース動作環境で 生成された鍵をプロンプトレス ssh 接続用の authorized_users ファイルにコピーします $ cat ~/.ssh/id_rsa.pub_cloud >> ~/.ssh/authorized_users $ chmod 700 ~/.ssh/authorized_users TCP ソケットのバッファ サイズを設定する TCP ソケットのバッファ サイズを増やすと 場合によっては REDO 転送を向上させることができます TCP ソケット サイズの設定方法については 付録 C を参照してください Oracle Net による暗号化を設定する / リスナーを検証する WAN 上でプレーンテキストが可視状態にならないよう保護するには オンプレミスとクラウドのすべてのマシンで $ORACLE_HOME/network/admin に格納されている sqlnet.ora ファイルに次のエントリを入力します 8 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

12 SQLNET.ENCRYPTION_SERVER = requested SQLNET.CRYPTO_CHECKSUM_SERVER = requested SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1) SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128) SQLNET.ENCRYPTION_CLIENT = requested SQLNET.CRYPTO_CHECKSUM_CLIENT = requested SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, AES192, AES128) Data Guard 構成では プライマリとスタンバイのデータベース間で情報が双方向に伝送されます これには 基本設定を行い ネットワークをチューニングし プライマリとスタンバイの両方のデータベースでポートを開く必要があります LISTENER という名前のデフォルトのリスナーを使用します このドキュメントで概説する手順では デフォルトのリスナー名 (LISTENER) を使用することを前提としています 検証するには オンプレミスのマシンから次のコマンドを実行します 予期される結果が表示されます $ lsnrctl show current_listener grep Current Listener Current Listener is LISTENER オンプレミスのマシンから次のコマンドを実行してリスナー ポートを検証します 予期される結果が表示されます $ lsnrctl stat grep 'Connecting to' Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=(1521))) 3.2 オンプレミスのプライマリ データベースの準備 Oracle ホームとパッチを検証する環境が異なる Oracle Database ソフトウェアのホーム間のパッチの違いは Standby-First 互換である必要があります 2 つのサイトの間で $ORACLE_HOME/OPatch/opatch lspatches の出力を比較し それぞれの側で不足している Standby-First 互換ではないパッチ ( オンプレミスでインストールされていてクラウドにはインストールされていないパッチと クラウドにインストールされていてオンプレミスにはインストールされていないパッチ ) をすべて適用します まだインストールされていない場合 こちらから OPatch の Master Note を参照できます クラウド VM に対するパッチの一部はクラウドに固有のものとして示されており そのためオンプレミス システムとは関連がありません 注 :Exadata Cloud Service を使用する場合の Exadata バンドル パッチの適用については Data Guard Standby-First パッチの適用について述べられている My Oracle Support Note を参照してください 9 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

13 3.2.2 アーカイブ ログ モードを有効にする Data Guard によるレプリケーションで使用するプライマリ データベースは ARCHIVELOG モードで実行されている必要があります データベースのアーカイブ モードの変 更について詳しくは Oracle Database 管理者ガイド を参照してください REDO ログを適切にサイジングするオンライン REDO ログとスタンバイ REDO ログでは REDO ログ サイズとして 1 GB と ピーク REDO レート / 分 x 20 分で算出されるサイズのうち 大きいほうの値を使用する必要があります ピーク REDO レートを求めるには バッチ処理 四半期 または年末処理などのピーク ワークロード期間中の AWR レポートを参照してください 平均値ではなく ピーク値のワークロードを使用することが非常に重要です ( 平均値を使用するとピークの REDO レートが明確ではなくなり REDO ログのプロビジョニングのサイズが過度に小さくなることがあります ) 表 1 に REDO レートと最小推奨 REDO ログ サイズの簡単な対応表を示します 表 1: 推奨 REDOログ サイズ EMまたはAWRのレポートによ 推奨 REDOログ グループサイズ るピークREDOレート 1 MB/ 秒以下 1 GB 5 MB/ 秒以下 4 GB 25 MB/ 秒以下 16 GB 50 MB/ 秒以下 32 GB 50 MB/ 秒超 64 GB スタンバイ REDO ログを作成する 1. 現時点でプライマリ データベースでスタンバイ REDO ログ (SRL) が作成されていないことを確認します ログが存在し 以下の要件を満たしている場合 追加の SRL は不要です SQL> select count(1) from v$standby_log; COUNT(1) ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

14 2. SRL は オンライン REDO ログ (ORL) の最大サイズと同じサイズで作成する必要があります ORL のサイズを集計するには 次の問合せを実行します この例において すべての SRL のサイズは GB( つまり 4 GB) です SQL> select max(bytes) from v$log; MAX(BYTES) さらに スタンバイ REDO ログに関する MAA のベスト プラクティスは オンライン REDO ログのグループと同じ数以上のスタンバイ REDO ログ グループを作成することです したがって 以下の例のように ORL グループが 3 つある場合は SRL グループを少なくとも 3 つ作成する必要があります SQL> select thread#,count(group#) from v$log group by thread#; THREAD# COUNT(GROUP#) 注 : 前の問合せにスレッドが複数存在する場合 プライマリ データベースは Oracle Real Application Cluster(RAC) であり インスタンスごとに次の手順を繰り返す必要があります 4. また 現在の ORL の最大グループ数も把握しておく必要があります ORL と SRL は同じ名前空間に存在しているため グループ番号を共有することはできません この例では SRL グループの番号付けが 4 から始まります SQL> select max(group#) from v$log; MAX(GROUP#) 最後に 収集した情報に基づいて SRL グループを追加します SQL> alter database add standby logfile thread 1 group 4 ( +RECO ) size , group 5 ( +RECO ) size , group 6 ( +RECO ) size , group 7 ( +RECO ) size ; +RECO は 使用する ASM ディスクグループで置き換えるか ASM を使用しない場合は <path>/<filename> で置き換えます ( 一般には ORL と同じ場所です ) MAA ベスト プラクティスでは SRL を ORL のように複製しません Grid Infrastructure をインストールする ( 必要な場合 ) 付録 B Oracle Restart のインストール を参照してください 11 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

15 3.2.6 透過的データ暗号化を使用するようにデータベースを変換する Data Guard のプライマリおよびスタンバイ データベースは 相互に物理的なレプリカになっています クラウドのスタンバイ データベースの格納データを暗号化する場合は まずオンプレミスのプライマリ データベースを暗号化する必要があります Oracle MAA のベスト プラクティスには Oracle Database または Oracle Database 12c 16 の場合に 最短の停止時間で TDE に変換するための指針が含まれています 4. Oracle Cloud の動作環境の準備 Hybrid Data Guard の場合 クラウド データベース インスタンスのデフォルトのデプロイメントは構成されません 以下の手順を実行して環境を準備します 4.1 Oracle Cloud Database の準備 Oracle ホームとパッチを検証する環境が異なる Oracle Database ソフトウェアのホーム間のパッチの違いは Standby-First 互換である必要があります 2 つのサイトの間で $ORACLE_HOME/OPatch/opatch lspatches の出力を比較し どちらかの側で不足している Standby-First 互換ではないパッチ ( オンプレミスでインストールされていてクラウドにはインストールされていないパッチと クラウドにインストールされていてオンプレミスにはインストールされていないパッチ ) を適用します まだインストールされていない場合 こちらから OPatch の Master Note を参照できます クラウド VM に対するパッチの一部はクラウドに固有のものとして示されており そのためオンプレミス システムとは関連がありません 注 :Exadata Cloud Service を使用する場合の Exadata バンドル パッチの適用については Data Guard Standby-First パッチの適用について述べられている My Oracle Support Note デフォルトのデータベースを削除するクラウド サービスの初期デプロイメントでは そのインスタンスの作成時に入力された名前でデフォルトのデータベースが作成されます ここでの例では STBY を使用しました このデータベースは 次のコマンドを使用して削除する必要があります 使用するパスワードは デプロイメントの Web ツールで指定したパスワードです $dbca -silent -deletedatabase -sourcedb STBY -sysdbausername sys -sysdbapassword <passwd> ja.pdf ja.pdf 12 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

16 4.1.3 Grid Infrastructure をインストールする ( まだインストールされていない場合 ) 付録 B Oracle Restart のインストール を参照してください 4.2 クラウド ネットワークの準備 TCP ソケットのバッファ サイズを設定する TCP ソケットのバッファ サイズを増やすと 場合によっては REDO 転送を向上させることができます TCP ソケット サイズの設定方法については 付録 C を参照してください アクセス ルールを作成するクラウドでのポート接続の安全性を確保することは重要です ssh アクセスを有効にし またアクセス ルールに従って特定のオンプレミス IP アドレスだけがクラウド内のリスナー ポートにアクセスできるようにします Oracle Database Cloud Service コンソールで作成したデータベース サービスのアクセス ルール ページに移動します 図 2 を参照してください 図 2: データベース サービスのドロップダウン メニュー ポート 1521 にはデフォルトのアクセス ルールが 2 つ定義されています ora_p2_dblistener は 公開インターネットからのオープン アクセスを許可するように定義されており デフォルトでは無効になっています 2 番目の ora_trusted_hosts_dblistener はデータベースのローカル ホストに対して定義されており 有効になっています 13 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

17 図 3: デフォルトのアクセス ルール デフォルトのルールはそのまま残し オンライン ドキュメントから アクセス ルールの 作成によるポート アクセスの有効化または制限の説明に従って ポート 1521 の新しい ルールを追加します 図 4 にアクセス ルールの例を示します 図 4: アクセス ルールの例 14 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

18 4.2.3 Oracle Cloud Net による暗号化の設定 Oracle Cloud データベースのインスタンスは デフォルトで 通信時にパケットを暗号化する Oracle Net による暗号化用に設定されています $ORACLE_HOME/network/admin/sqlnet.ora ファイルでは 以下のように設定されている必要があります 後述しますが オンプレミスの場合にも同様の設定が必要とされます SQLNET.ENCRYPTION_SERVER = required SQLNET.CRYPTO_CHECKSUM_SERVER = required SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1) SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128) SQLNET.ENCRYPTION_CLIENT = requested SQLNET.CRYPTO_CHECKSUM_CLIENT = requested SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, AES192, AES128) このドキュメントで概要を示す手順では オンプレミスのプライマリ データベースがまだ既存の Data Guard Broker 構成の一部になっていないことを前提としています オンプレミス データベースの既存のブローカ構成が存在する場合は 管理者がブローカについての情報を事前に得ており 既存のブローカ構成に新しいスタンバイ データベースを追加する方法を知っていることを前提とします Data Guard Broker の設定について詳しくは 付録 F を参照してください 次の問合せに対する戻り値が 'NOCONFIG 以外の場合は 既存のブローカ構成を意味します SQL> select decode(count(1),0,'noconfig') from v$dg_broker_config; 5. Data Guardスタンバイのインスタンス化上記の例に示すように デフォルトのデータベース インスタンスは Oracle Database Cloud Service を最初にサブスクライブするときに自動的に作成されます デフォルトのデータベースは Data Guard スタンバイ データベースとして使用することができず 前の手順で削除しました クラウド内の Data Guard スタンバイは 次のいくつかの方法でインスタンス化できます» オンプレミスのプライマリからインスタンス化する» Oracle Database Backup Cloud Service からインスタンス化する» 数十から数百 TB クラスの大規模データベースの場合は ( このホワイト ペーパーの発行時点では可用性を制御して ) バルク インポート機能を使用します 5.1 オンプレミスのプライマリ データベースからのインスタンス化このスタンバイ作成モードを図 5 に示します オンプレミスの本番データベースを使用して クラウド内のスタンバイ データベースをインスタンス化します 付録 D インスタンス化 では アクティブなオンプレミス プライマリ データベースからスタンバイ データベースをインスタンス化するための手順が詳しく説明されています 15 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

19 図 5:Recovery Manager の DUPLICATE を使用したオンプレミスのプライマリのインスタンス化 5.2 Oracle Database Backup Cloud Service からインスタンス化するこのスタンバイ作成モードを図 6 に示します Oracle Database Backup Cloud Service(Oracle DBCS) 17 に保存されているオンプレミスのプライマリ データベースのバックアップを使用し Recovery Manager の RESTORE コマンドと RECOVERY コマンドを使用してスタンバイ データベースを作成します バックアップからリストアするには 同じパスワードまたは TDE 鍵が必要です 図 6:Oracle Database Backup Cloud Service を使用したインスタンス化 Oracle Backup Service からスタンバイ データベースを作成する手順については 付録 K を参照してください ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

20 6. Data Guardのヘルス チェックを実行するスタンバイをインスタンス化したら ヘルス チェックを実行して Data Guard データベース ( プライマリとスタンバイ ) が Oracle MAA のベスト プラクティスに準拠していることを確認します ヘルス チェックは 毎月実施するとともに データベースのメンテナンスの前後にも実施するようお勧めします Data Guard 構成のヘルス チェックは いくつかの方法で実施できます Oracle MAA スコアカードオラクルでは 次の 2 つの自動化されたヘルス チェック ツールを提供しており ハードウェア プラットフォームのタイプごとに My Oracle Support からダウンロードすることができます» ORAchk: 汎用プラットフォームに適用可能 (Database Cloud Service に最適 ) 18» exachk:oracle Exadata Database Machine に適用可能 (Exadata Cloud Service に最適 ) 19 自動化された各チェック機能には Data Guard 構成の多数の主要なベスト プラクティスおよびその他多くのチェック項目について報告する Oracle MAA スコアカードが組み込まれています これらの自動化ツールは Data Guard 構成だけでなく システム全体の包括的なヘルス チェックでも使用することを強く推奨します ヘルス チェックの結果は 最新の情報に基づいて定期的に更新されます 必ず ご使用のプラットフォームに該当する最新バージョンのヘルス チェック ツールをダウンロードしてください Data Guard 固有の問合せ (Oracle Database 11g 以降で利用可能 ) 付録 G ヘルス チェック問合せ には Data Guard 構成のヘルス チェックに使用可能な Data Guard 固有の一連の問合せが サンプル出力と一緒に記載されています Data Guard の VALIDATE DATABASE(Oracle Database 12c 以降で利用可能 ) Data Guard に固有のヘルス チェックをもっとも包括的に実施するには Data Guard Broker の VALIDATE DATABASE コマンドを使用することを強く推奨します VALIDATE DATABASE により 構成チェックが広範に実施され 構成でスイッチオーバーやフェイルオーバーの準備ができているかどうかが検証されます ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

21 例 : DGMGRL> validate database stby; Database Role: Primary Database: Physical standby database pri Ready for Switchover: Ready for Failover: Yes Yes (Primary Running) VALIDATE DATABASE コマンド 20 によって実効される広範なチェックについて詳しくは Data Guard Broker のドキュメントを参照してください 7. 実行時監視を有効にする Data Guard 構成の実行時ステータスを監視するオプションは 2 つ用意されており コマンドラインによって問い合わせる方法か Enterprise Manager Cloud Control を使用する方法を選択できます オプション 1: コマンドラインによる監視ハイブリッド DR 構成で 管理者によって設定されたデータ保護 (RPO) と可用性 (RTO) のサービス レベルを確実に達成できるようにするには 監視とアラート発行の機能が必要です Data Guard 構成の実行時の状態の主要な側面を監視するための一連の問合せについて詳しくは 付録 A を参照してください» 転送ラグ» 適用ラグ» プライマリ / スタンバイ接続ステータス» Data Guard の全体的なステータスとロール移行の準備状態管理者は 値がサービス レベルしきい値を超えた場合にはアラートが送信されるようにするなどの 構成の監視を自動化するスクリプトを作成する必要があります Enterprise Manager 12c を使用する場合は このような手動での作業は必要ありません オプション 2:Enterprise Manager 12c または 13 Oracle Enterprise Manager 12c または 13 により クラウドのライフサイクル全体にわたる複雑な管理タスクを合理化および自動化することができます オンプレミスの管理者はクラウド サービスを監視および管理することができ クラウドの管理者はオンプレミスのサービスを監視および管理することができます ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

22 Oracle Cloud サービスを提供する Oracle Cloud 仮想ホストに管理エージェントをデプロイすることにより 他のターゲットの場合と同様の方法で Oracle Cloud ターゲットを管理することができます 管理エージェントとオンプレミスの Oracle 管理サービス インスタンスとの間の通信は外部の干渉から安全に守られます (Enterprise Manager Cloud Control 12c Release 1( ) 以上が必要です ) Oracle Database と Fusion Middleware PaaS のターゲットを管理するためのサポートに加え Oracle Cloud 仮想ホスト上の JVM を監視するための JVMD のサポートも提供されます Oracle Cloud Management には 以下の機能が含まれます» 自動化されたエージェントのデプロイメントと構成» データベースと Java の PaaS インスタンスの監視» 通知とチケット発行の統合を含むインシデント管理» 検索とインベントリ オンプレミス インスタンスとクラウド インスタンス間の比較 構成履歴 コンプライアンスなどの構成管理» オンプレミスと Oracle Cloud の間でのクローニング» Oracle Cloud データベース インスタンスのワンオフ パッチ適用 Enterprise Manager は 以下に関して Data Guard 環境を監視および管理するためのシンプルなインタフェースです» Data Guard のステータス» 転送ラグ» 適用ラグ» データベース ロール移行の推定所要時間» プライマリまたはスタンバイがアクセス可能かどうかアラートは 任意のイベントの発生時に または上記のメトリックが所定のしきい値を超えた場合に通知されるようにカスタマイズできます 21 Hybrid Cloud Management を有効化する方法については Enterprise Manager Cloud Control 管理者ガイド を参照してください 注 : このホワイト ペーパーの発行日現在では Enterprise Management Cloud Control を使用したハイブリッド クラウド DR 構成の管理のサポートは認定されていません この制限が解除されたかどうかを確認するには このホワイト ペーパーの最新バージョンをダウンロードするか Enterprise Manager のドキュメントで最新情報を確認してください ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

23 8. REDO 転送圧縮を有効化する ( オプション ) オンプレミス システム用の Oracle Advanced Compression のライセンスを取得している場合は 圧縮されていない REDO ボリュームよりも使用可能なネットワーク帯域幅の方が小さければ REDO 転送圧縮を使用できます REDO 転送圧縮が推奨されるのは プライマリとスタンバイの CPU に十分な余裕があっても プライマリとスタンバイの間のネットワーク帯域幅が狭いという環境の場合のみです REDO 転送圧縮を使用したいと思っても プライマリ データベースのパフォーマンスへの影響が心配な場合は Oracle 12c の Active Data Guard Far Sync を使用するという追加オプションを選択し 圧縮のオーバーヘッドをオンプレミスにデプロイされている Far Sync インスタンスにオフロードすることができます 詳しくは Oracle MAA ベスト プラクティス ペーパー Oracle Active Data Guard Far Sync: いかなる距離でもデータ損失ゼロ 22 を参照してください 注 : 暗号化された REDO は圧縮できないため TDE で暗号化されたデータベースに REDO 転送圧縮を使用しても利点はほとんどありません DR の動作 クラウドへの DR を正常に設定したら スタンバイで DR の準備ができているかどうかを検証できる ほか 以下のメンテナンス タスクを実行することができます 1. DR の準備状況の検証 2. スタンバイ データベースの使用による計画メンテナンス中の停止時間の短縮 3. クラウドへのフェイルオーバー / スイッチオーバー 4. オンプレミスへのフェイルバック / スイッチバック 5. アプリケーション層への接続 1. DRの準備状況の検証ベスト プラクティスは Active Data Guard を使用して読取り専用ワークロードをスタンバイ データベースにオフロードし スタンバイで本番稼働の準備ができていることをアプリケーションレベルで検証し続けることです これにより Data Guard の適用プロセスで実行される継続的な Oracle ブロックレベルの検証に加えて 一定レベルの保証が得られます また (Data Guard スナップショット スタンバイを使用して ) スタンバイを定期的に読取り / 書込みモードにし 読取り / 書込みの本番ワークロードをサポートする準備ができていることを検証することもベスト プラクティスです DR システムは本番システムと同様にサイジングされることが多いため 本番前の最終レベルでのパッチおよびアップグレードの機能テストとパフォーマンス テストでも スナップショット スタンバイを使用可能です スナップショット スタンバイはプライマリ データベースから REDO を受信し続け 後で使用するために REDO をアーカイブし それにより常時データを保護します ただし テストの進行中にフェイルオーバーが必要になった場合のリカバリ時間 (RTO) は スナップショット スタンバイを元のスタンバイ データベースに変換するために必 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

24 要とされる時間だけ長くなります スタンバイがスナップショット モードになっている場合は ( プライマリ本番データベースから受信し後で使用するためにアーカイブされた REDO ログと スナップショット スタンバイによって生成される最新の REDO ログおよびフラッシュバック ログを保持するため ) ファスト リカバリ領域として追加のストレージが必要になります スタンバイをスナップショット スタンバイに変換し 戻すための手順は 付録 H に記載されています Data Guard スナップショット スタンバイ 23 についてさらに詳しくは Oracle ドキュメントを参照してください 必要に応じて 完全なエンド ツー エンドの DR テストとして クラウドへの実際のスイッチオーバーまたはフェイルオーバー操作を実行することもできます 詳しくは クラウドへのフェイルオーバー / スイッチオーバー を参照してください 2. スタンバイ データベースの使用による計画メンテナンス中の停止時間の短縮クラウド上のスタンバイ データベースを使用し いくつかの方法でプライマリ本番データベースの計画停止時間を短縮できます Standby-First Patch Apply: 徹底的な検証のため 多くのパッチをまずフィジカル スタンバイ データベースに適用できます 停止時間を最小限に抑えるために まずスタンバイにパッチを適用し 次に本番データベースをスタンバイ データベースに切り替え それから元のプライマリ データベースにパッチを適用する作業が行われることがよくあります Standby-First 対象のパッチ ( パッチの read-me に記載 ) を適用する場合 異なるパッチ バージョンで稼働しているプライマリとスタンバイの間の Data Guard による物理レプリケーションがサポートされます また パッチに関して予期せぬ問題が発生した場合にはパッチが適用されていないバージョンに直ちにフォールバックできるよう 一定期間は異なるパッチ バージョンのプライマリとスタンバイを稼働させることもできます Standby-First プロセスを適用可能なパッチについて詳しくは My Oracle Support Note Oracle Patch Assurance - Data Guard Standby-First Patch Apply 24 を参照してください データベースのローリング アップグレード :Oracle Cloud におけるスタンバイの利点を活かすことができるもう 1 つのユースケースは データベースのローリング アップグレードを行う場合で これにより データベースの新しいパッチセットへのアップグレードや Oracle のリリース全体のアップグレードの際に 停止時間を短縮することができます Oracle 11g と Oracle 12c で使用される一時ロジカル プロセスでは フィジカル スタンバイ データベースを一時的にロジカル スタンバイに変換し ロジカル スタンバイを新しいバージョンにアップグレードして検証し 準備ができたら Data Guard スイッチオーバーを実行します スイッチオーバーが完了すると 元のプライマリ データベースは 同様に新しいリリースで動作している同期されたフィジカル スタンバイに変換されます 詳しくは Oracle 11g の Oracle Database ローリング アップグレード Oracle 25 Data Guard フィジカル スタンバイ データベースの使用または Oracle 12c DBMS_Rolling 26 を参照してください ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

25 3. クラウドへのフェイルオーバー / スイッチオーバー Data Guard のスイッチオーバー ( 計画イベント ) やフェイルオーバー ( 計画外イベント ) は いつでも手動で実行することができます また ファスト スタート フェイルオーバーを設定することによる Data Guard のフェイルオーバーの自動化も選択できます スイッチオーバーとフェイルオーバーにより Data Guard 構成におけるデータベースのロールが逆転し クラウドのスタンバイがプライマリになり 元のオンプレミスのプライマリがスタンバイ データベースになります Data Guard のロールの移行について詳しくは Oracle MAA のベスト プラクティス 27 を参照してください アプリケーション層のフェイルオーバーについては このホワイト ペーパーの アプリケーション層への接続 セクションを参照してください スイッチオーバーは常に データを失わないことが保証された計画イベントとなります スイッチオーバーを実行するには Data Guard Broker で以下のコマンドを実行します DGMGRL> validate database stby; Database Role: Primary Database: Ready for Switchover: Ready for Failover: Physical standby database pri Yes Yes (Primary Running) DGMGRL> switchover to <target standby>; フェイルオーバーは プライマリ データベースで障害が発生することを想定した計画外イベントです 使用可能なプライマリのすべての REDO が適用された後 スタンバイ データベースが即時にプライマリ データベースに変換されます フェイルオーバーの後 古いプライマリ データベースはフィジカル スタンバイとして復旧する必要があります これは フラッシュバック データベースと Data Guard Broker を有効にすることによって簡単に行うことができます フェイルオーバーと復旧を実行するには Data Guard Broker で以下のコマンドを実行します DGMGRL> failover to stby; Performing failover NOW, please wait... Failover succeeded, new primary is "stby" 復旧前に 古いプライマリの 1 つのインスタンスで startup mount を実行します SQL> shutdown abort SQL> startup mount DGMGRL> reinstate database pri Reinstating database "pri", please wait... Data Guard Broker を使用したロール移行について詳しくは Oracle Database 11g 28 または 12c 29 用の Broker のドキュメントを参照してください ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

26 4. オンプレミスへのスイッチバック 本番データベースをオンプレミス データベースに移行する準備ができたら フェイルオーバー / ス イッチオーバーのプロセスで述べられているのと同じロール移行手順を再び適用します 5. アプリケーション層への接続ハイブリッド クラウド DR 構成では オンプレミスのアプリケーション層と Oracle Cloud に存在するリモート データベースとの間で発生するネットワーク待機時間による影響を理解しておくことは重要です これは特に アプリケーション層をオンプレミスに残したまま本番をクラウド スタンバイにスイッチオーバーまたはフェイルオーバーする場合や オンプレミスのアプリケーション層からクラウド上の Active Data Guard へのリモート読取り専用接続が行われる場合が関係します 一部のアプリケーションはデータベースとのやり取りが特に多いため リモート接続を行う場合の実質的なパフォーマンスのオーバーヘッドが大きくなります WebLogic ベースのアプリケーションなどのその他のアプリケーションは メタデータをデータベース自体に格納します 理想的なのは アプリケーション層でリモート接続の待機時間を許容できるようにすることです 安定状態での稼働中 アプリケーション層は オンプレミスのプライマリ データベースで実行されているサービスにアクセスします アプリケーション接続は クラウドへのスイッチオーバーまたはフェイルオーバーに続いて 新しいプライマリ データベースに自動的にリダイレクトされます アプリケーション層のフェイルオーバーの自動化は 以下のようにして実行されます» Oracle Net の接続記述子に適切なデータベース サービスが記述されているいずれかのデータベースに自動的に接続されるよう アプリケーション層を事前設定します» オンプレミスのアプリケーション サーバーと Oracle Cloud データベース サーバーの間のネットワーク接続性は データベースの各層と同様に設定されています 以下の前提条件を満たす必要があります» アプリケーション層では Oracle Cloud VM への名前解決を設定する必要があります この設定は /etc/hosts のような静的ファイルを使用するか Oracle Cloud インスタンスのパブリック IP アドレスが正しく解決されるようにオンプレミス DNS を設定することによって行うことができます また オンプレミスのファイアウォールでは オンプレミス システムと Oracle Cloud VM の間の ssh および Oracle Net アクセスを許可するように適切に設定されたアクセス制御リストが必要になります» オンプレミスのファイアウォールは Oracle Cloud VM からオンプレミス マシンへのインバウンド ssh 接続を許可するように設定する必要があります» ロール固有のデータベース サービスは 適切なサービスが自動的に起動するように事前設定され プライマリ ロールで機能しているデータベースでのみ実行することができます» Oracle Fast Application Notification(FAN) により または代わりに tcp のタイムアウトを慎重に設定することにより 停止発生時にはクライアントが障害を起こしたデータベースとの接続をすぐに切断し クラウド上の新しいプライマリ データベースに自動的に再接続されるようにすることができます 23 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

27 新しいプライマリ データベースへのアプリケーション層の自動フェイルオーバーの設定について詳しくは 付録 I に記載されています アプリケーション層でリモート接続の待機時間を許容できない場合 またはプライマリ サイト全体を使用できない場合は アプリケーション層とデータベース層の両方を Oracle Cloud にフェイルオーバー / スイッチオーバーすることが必要になります Oracle Cloud には アプリケーション層をホストする Infrastructure-as-a-Service(IaaS) として以下 30 の 2 種類の計算機能が用意されています» ネットワークから分離された専用ハードウェアで実行される Dedicated Compute Cloud Service» オンデマンドでスケーラブルな計算リソースを提供する Compute Cloud Service 6. フル スタック フェイルオーバー : アプリケーション層とデータベース層 Oracle Compute Service は オンプレミス アプリケーション層の DR コピーを Oracle Cloud でホストできるようにすることで Oracle Database PaaS を補完します 適切なレベルの計算サービスを使用してアプリケーション バイナリをインストールし サイトが完全停止した場合でも クラウドにフル スタック フェイルオーバーできるようにします オンプレミスのアプリケーション層でローカル ファイル システムに永続データも書き込むような処理は一般的ではありません アプリケーション層とデータベース層のフル スタック フェイルオーバーでは どちらの場合も Oracle Database の外部のファイル システムに存在するデータベース データとすべてのアプリケーション層データの両方をクラウドにレプリケートする必要があります Oracle Database に存在するデータは Data Guard と Active Data Guard によってレプリケートされます Oracle Database の外部に存在するファイル システム データをレプリケートするには 別の手段を使用する必要があります Active Data Guard のライセンスを取得している場合 および Extreme Performance または Exadata のクラウド サービスのどちらかを利用している場合は オンプレミスのアプリケーション層から Oracle Database File System(DBFS) にファイル システム データを定期的にコピーするオプションを選択できます DBFS にコピーされれば Active Data Guard ですべてのデータを Oracle Cloud にレプリケートできるため フル スタック DR 保護を実現できます ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

28 以下の図に クラウドへのフル スタック DR の流れを示します 図 7:DBFS と Oracle Active Data Guard を使用したフル スタック DR DBFS 31 は データベースの各表に格納されるファイルおよびディレクトリを処理する標準のファイル システム インタフェースです DBFS は ローカル ファイル システムのように見える共有ネットワーク ファイル システムを提供する点において NFS と似ています DBFS の場合 サーバーは Oracle Database です ファイルは SecureFiles LOB としてデータベース表に格納されます DBFS にファイル システムのデータを定期的にコピーする処理は rsync を使用するスクリプトによって自動化されます これは 1 つの場所から別の場所へファイルのコピーや同期を行うために一般に使用される シンプルなユーティリティです rsync_copy.shi スクリプトは My Oracle Support Note で公開されています このプロセスではプロンプトレス ssh を使用します 管理者が指定した任意の間隔で実行するように cron でスケジュールされます このスクリプトは プライマリ サイト上で実行してオンプレミスのアプリケーション サーバーから DBFS にデータをコピーするように構成されています また アプリケーション ファイルを最新の状態で維持するため クラウド上で実行して DBFS からリモート アプリケーションサーバーにデータをコピーするようにも構成されています (DBFS は スタンバイ データベースで読取り専用で開かれている必要があります したがって Active Data Guard が必要です ) ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

29 rsync と DBFS の組み合わせによってネットワーク構成も簡素化され オンプレミスとクラウドのデータは 単一接続での Active Data Guard によるレプリケーションによって自動的に同期されます フル スタック ロール移行を実施するためのセットアップ要件 指示 および手順については 付録 L を参照してください Active Data Guard のライセンスを取得していない場合や DBFS を使用することができない場合は データセンターとクラウドの間に 2 つ目のセキュアなネットワーク接続を構成することにより rsync を使用してオンプレミスから Oracle Cloud に直接コピーする方法を選択できます rsync は 無償で入手できるオープン ソースのファイル同期ユーティリティで 帯域幅効率に優れた差分転送方式が採用されています ファイルやディレクトリを同期するために一般に使用される有効な手段ですが 書込み順序やファイル システム トランザクションの順序は保証されません ファイル システムとディレクトリは 相互に相対的なおよそのポイントインタイム順になります 同様に すべてのファイルとデータベースの間でのポイントインタイム同期も実行されません 結論 ハイブリッド クラウド構成のディザスタ リカバリは オンプレミスの本番データベースと Oracle Data Guard または Active Data Guard によって同期された Oracle Cloud 上の DR コピーで構成されています Oracle Cloud 上でのディザスタ リカバリにより 遠隔施設の所有および管理に伴うコストと煩雑さが解消されるとともに スタンバイ システムやソフトウェアといった資本への出費をなくすことができます ディザスタ リカバリで Data Guard または Active Data Guard を使用することにより 停止時間と リモート バックアップに依存したサービスのリストアという潜在的なリスクがなくなります 本番データベースは Oracle Cloud 上ですでに稼働している 本番データベースの同期済みコピーに直ちにフェイルオーバーされます クラウド上のスタンバイ データベースは ディザスタ リカバリで利用できるだけでなく 開発およびテストでクローン データベースをシードするとともに オンプレミス本番データベースから読取り専用ワークロードをオフロードする目的でも使用可能です 26 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

30 付録 付録 A Data Guard の実行時監視問合せ このホワイト ペーパーの公開時点において Hybrid 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 stby; Database - stby Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag:0 seconds (computed 1 second ago) Apply Lag: 0 seconds (computed 1 second ago) Average Apply Rate:20.00 KByte/s Real Time Query: ON Instance(s): stby1 stby2 (apply instance) Database Status: SUCCESS 転送または適用機能に関して問題がある場合 ステータスは WARNING または ERROR になります スタンバイ データベースの ApplyLagThreshold プロパティおよび TransportLagThreshold プロパティを設定すると 同じ方法 (Database Status) でラグを監視できるようになります これらのプロパティは それぞれ秒単位で表現されます これらのプロパティを 0 以外の値に設定すると その値を超過したときに Database Status が WARNING に変わります SQL*Plus による監視 REDO 転送と REDO Apply を検証するには Data Guard では基本的に REDO がプライマリから転送され それからスタンバイに適用されます 以下の問合せを使用して これらの機能が正しく作動しているかどうかを検証できます 27 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

31 プライマリ データベースの問合せ :Data Guard 転送の現在の状態 : プライマリ データベースがスタンバイに REDO を送信していることを検証するには プライマリ データベースで以下の問合せを実行します STATUS は VALID になることが期待されます STATUS が VALID ではない場合は 補足情報とともに ERROR と表示されます RAC プライマリ データベースの場合に各プライマリ インスタンスを検証するには gv$archive_dest_status を使用する必要があります SQL> select sysdate,status,error from v$archive_dest_status where type='physical'; SYSDATE STATUS ERROR mar :42:10 VALID スタンバイ データベースの問合せ : スタンバイ適用の現在の状態 スタンバイでは 適用なしで 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 mar :43:44 OPEN_READ-ONLY MANAGED REAL TIME APPLY NO GAP Data Guard のパフォーマンス ( スタンバイ ラグ ) 正常に書き込まれてはいても スタンバイに適用されていない REDO は適用ラグと呼ばれます 適用ラグは スタンバイでリソースが不足していることを示し 多くの場合 I/O または CPU の競合が原因となっています REDO はスタンバイに存在しており フェイルオーバー前に適用可能なため 適用ラグは潜在的なデータ損失を示すものではありません ただし転送ラグが存在する場合は REDO の受信とスタンバイの REDO ログへの書込みが適切なタイミングで行われていないことを意味し プライマリが失われると書き込まれていないデータも失われる可能性があります 転送ラグの原因として多いのはネットワークの待機時間ですが スタンバイでのリソース不足の結果である可能性もあります 以下の問合せにより どちらのラグであっても その存在とサイズを確認できます スタンバイ データベースの問合せ : 適用および転送のタイムラグの監視 28 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

32 適用ラグまたは転送ラグを特定するには 以下の問合せを実行します A VALUE of :00:00 indicates no lag. SQL> 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 06/18/ :26:29 06/18/ :26:27 apply lag :00:00 06/18/ :26:29 06/18/ :26:27 スタンバイ データベースの問合せ : 転送ラグのサイズの監視 以下の問合せを使用し 転送ラグが発生している場合に スタンバイがプライマリから何ブロック遅れているのかを確認できます SQL> select t.thread#,t.last_redo_sequence#,t.last_redo_block, s.thread#, 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# スタンバイ データベースの問合せ : スタンバイ適用プロセスの監視 SQL> select sysdate,process,status,thread#,sequence#,block# from v$managed_standby where status!='idle'; SYSDATE PROCESS STATUS THREAD# SEQUENCE# BLOCK# mar :58:31 ARCH CLOSING mar :58:31 ARCH CONNECTED mar :58:31 ARCH CLOSING mar :58:31 ARCH CLOSING mar :58:31 MRP0 APPLYING_LOG ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

33 スタンバイ データベースの問合せ : リカバリの監視 ( 高度な監視 ) 以下の問合せを使用して 適用率や適用ラグなどの適用プロセスに関する貴重な情報を収集することができます gv$recovery progress により インスタンスが存続する間の各リカバリ起動の履歴が ( インスタンスが再起動されるまで ) 保持され この問合せでは直前の起動のメトリックのみが選択されます 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 JUN-15 Active Apply Rate KB/sec JUN-15 Average Apply Rate KB/sec 1 18-JUN-15 Maximum Apply Rate KB/sec JUN-15 Redo Applied Megabytes 0 18-JUN-15 Last Applied Redo SCN+Time 0 18-JUN-15 Active Time Seconds JUN-15 Elapsed Time Seconds JUN Standby Apply Lag Seconds 1 30 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

34 付録 B Oracle Restartのインストール Oracle Grid infrastructure は Oracle Data Guard のアプリケーション フェイルオーバーに不可欠の機能です デフォルトでは スタンドアロン構成の Oracle Database Service では Oracle Grid Infrastructure はインストールされないため 12.1 または 11.2 の該当するドキュメントの説明に従って手動でインストールする必要があります 以降の構成手順では Oracle Restart のインストールと設定が完了していることを前提に説明します 注 :Oracle Grid Infrastructure 用のインストール ソフトウェアはクラウド サービス上に存在しないため OTN からダウンロードしてインストールする必要があります ソフトウェアは Firefox で OTN から Oracle Public Cloud VM に直接ダウンロードするか オンプレミスにダウンロードしてから scp で Oracle Public Cloud VM にコピーすることもできます 注 :Oracle Restart Oracle RAC One Node または Oracle RAC と一緒にインストールされる Grid Infrastructure(GI) は ハイブリッド構成が正常に機能するために必須のものではありませんが このドキュメントの手順では GI がインストールされていることを前提としています したがって GI がインストールされていることを前提とするコマンドは GI がインストールされていない場合と異なります それらの代替コマンドは示されていません また 高速アプリケーション フェイルオーバー (FAN) 機能の場合には GI が必要です Grid Infrastructure なしで FAN を構成することはできません スワップ領域の追加インストーラ ソフトでは メモリが 16 GB 未満のシステムの場合 スワップ領域はメモリ容量と等しいと認識しています Oracle Public Cloud VM のデフォルト構成のスワップ領域は 4 GB しかないため スワップ ファイルを使用して追加のスワップ領域を構成する必要があります これらの手順は root ユーザーとして実行する必要があります 1. Oracle Public Cloud VM のメモリとスワップ領域の容量 ( どちらも kb 単位 ) を確認します この例の場合 スワップ領域は 4 GB メモリはおよそ 7.4 GB です MemTotal: kb # swapon -s Filename Type Size Used Priority /dev/xvdb3 partition 新規ファイル用のスペースが十分にあることを確認します この例の場合 追加のスワップ ファイルのサイズはおよそ 3.4 GB です # df -k / Filesystem 1K-blocks Used Available Use% Mounted on /dev/xvdb % / 31 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

35 3. 割り当てられたスワップ領域とスワップに使用されるメモリの差以上のサイズがある空のファイルを作成します # dd if=/dev/zero of=/extraswap bs=1m count= /etc/fstab をバックアップします cp /etc/fstab /etc/fstab.mybackup 5. /etc/fstab を編集して スワップ用の新規行を追加します /extraswap swap swap defaults 新規のスワップ ファイルをスワップに追加します # swapon -a 7. 新しいスワップ領域が使用可能なことを確認します # swapon -s Filename Type Size Used Priority /dev/xvdb3 partition /extraswap file インストーラの実行 インストール手順については 12.1 または 11.2 の該当するドキュメントを参照してください ssh 接続を介して Oracle Public Cloud VM でインストーラを実行するには X11 転送を有効にする必要があります opc ユーザーから root としてログインし /etc/ssh/sshd_config で以下を設定します» X11forwarding yes» X11DisplayOffset 10» X11UseLocalhost yes root として SSH デーモンを再起動します $ service sshd stop $ service sshd start Oracle Public Cloud VM に接続している場合は 以下のオプションを使用して信頼できる接続を識別します $ ssh -o ServerAliveInterval=100 -Y oracle@<ipc VM IP address> 32 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

36 Oracle Restart をインストールする場合 :» インストール オプション Install Oracle Grid Infrastructure Software Only を選択する» /u01/app/< >/grid にソフトウェアをインストールする» RAC 構成ではないため NTP に関する警告を無視する リスナーの構成 Oracle Restart のインストールが完了したら ORACLE_HOME/network/admin ディレクトリから新 しい GRID_HOME/network/admin ディレクトリに listener.ora をコピーします $ lsnrctl stop listener $ cp $ORACLE_HOME/network/admin/listener.ora /u01/app/12.1.0/grid/network/admin/listener.ora リスナーを Grid Infrastructure に追加して起動します $ srvctl add listener -listener listener -oraclehome /u01/app/12.1.0/grid $ srvctl start listener 以降の構成手順では Oracle Restart のインストールと設定が完了していることを前提に説明します 33 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

37 付録 C TCP ソケット サイズの設定 次のコマンドを root として実行して オンプレミス システムおよびクラウド インスタンス用の TCP ソケットのサイズを確認します # /sbin/sysctl -a egrep net.core.[w,r]mem_max net.core.wmem_max = net.core.rmem_max = # /sbin/sysctl -a egrep net.core.[w,r]mem_max net.core.wmem_max = net.core.rmem_max = 必要に応じて すべてのソケットの最大サイズを 10 MB( ) に調整します オンプレミス システムの場合のソケットの調整方法について詳しくは オペレーティング システム ガイドを参照してください クラウド インスタンスの場合は 次のコマンドを実行します # sysctl -w net.core.rmem_max= # sysctl -w net.core.wmem_max= Oracle Public Cloud のドキュメントで説明されているように Oracle と同じ ssh 鍵を使用して ops ユーザーに接続することでプロビジョニングされたクラウド インスタンスに root として接続でき その後 'sudo su -' を実行します ssh opc@<cloudip> [-i <key>] sudo su - 付録 D インスタンス化以下の手順に従ってインスタンス化を完了します ここでの手順では デプロイメント プロセスの手順 1~4 が正常に完了していることを前提としています 1. 環境を設定する データベース サービスのデプロイメント時に選択した ORACLE_SID が スタンバイ データベースで使用される ORACLE_SID と異なる場合 : /home/oracle/.bashrc ファイルを編集し ORACLE_SID を編集して意図するインスタンス名に設定します $ vi ~/.bashrc #change export ORACLE_SID=STBY #to export ORACLE_SID=<target sid name> 34 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

38 2. REDO 転送用の TNS エントリを設定する» REDO 転送が正常に行われるようにするには プライマリとスタンバイの両方の tnsnames.ora ファイルに各データベースのエントリが含まれている必要があります 以 下の例の太字の値を 構成に沿った値で置き換えて使用してください» 注 : プライマリ データベースのオンプレミス tnsnames.ora には サーバー名が HOST になっている TNS エントリがすでに含まれていることがあります その場合は サー バー名の代わりにホストの IP アドレスを使用するようエントリを変更してください /etc/hosts を使用して名前解決 (root ユーザーから変更 ) を行うこともできます» 注 : オンプレミス環境とクラウド環境の間にはサーバー名を IP アドレスに解決する DNS が存在しないため IP アドレス ( または /etc/hosts) が使用されます 名前解決を /etc/hosts またはオンプレミス DNS を使用して設定した場合 ここでは hostnames を代 用できます <primary db_unique_name> = " (DESCRIPTION = (SDU=65536) (RECV_BUF_SIZE= ) (SEND_BUF_SIZE= ) (ADDRESS = (PROTOCOL = TCP)(HOST = <primary IP address>)(port = {1521 <port#>})) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <primary db_unique_name>) ) ) <standby db_unique_name> = (DESCRIPTION = (SDU=65536) (RECV_BUF_SIZE= ) (SEND_BUF_SIZE= ) (ADDRESS = (PROTOCOL = TCP)(HOST = <standby IP address>)(port = {1521 <port#>})) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standby db_unique_name>) ) ) 35 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

39 3. 静的リスナーを構成する» スタンバイ データベースの最初のインスタンス化には 静的リスナーが必要です 静的リスナーにより 所定のインスタンスを開始するためにデータベースが停止している間でも インスタンスにリモート接続することができます クラウド VM 上の静的リスナーの構成では 以下の手順を参照できます 詳しくは MOS を参照してください 注 : 以下の手順では リスナー名を LISTENER と想定しています» 変数を置き換えてから クラウド VM の listener.ora に次のエントリを追加します listener.ora は $ORACLE_HOME/network/admin にあります Grid Infrastructure が使用されている Oracle 12c を使用している場合は このリスナー エントリをインスタンス化の後に削除する必要があります SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = < ローカル インスタンス名 >) (ORACLE_HOME = < ローカルの Oracle ホーム >) (SID_NAME = < ローカル インスタンス名 >) ) )» 11.2 構成の場合は Data Guard Broker でも静的リスナーが必要になります 変数を置き換えてから SID_LIST に次の SID 記述を追加します (SID_DESC = (GLOBAL_DBNAME = < ローカル インスタンス名 >_DGMGRL) (ORACLE_HOME = < ローカルの Oracle ホーム >) ) (SID_NAME = < ローカル インスタンス名 >) Oracle Data Guard Broker では clusterware を使用してインスタンスを再起動するため Oracle Restart Oracle RAC One Node または Oracle RAC によって管理される Oracle Data Guard Broker 構成では Oracle Database 以降 静的な "_DGMGRL" エントリは不要になっています» 最後に 次のコマンドでリスナーを再ロードします $ $ORACLE_HOME/bin/lsnrctl reload < リスナー名 > 4. 監査ディレクトリを作成する クラウドのスタンバイ データベースの監査ファイル ディレクトリを oracle として作成します $ mkdir -p /u01/app/oracle/admin/< スタンバイ データベース名 >/adump 36 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

40 5. 補助データベース パスワード ファイルと init.ora を作成する スタンバイ データベースのインスタンス化に使用される補助インスタンスのパスワード ファイルを作成します $ $ORACLE_HOME/bin/orapwd file='$oracle_home/dbs/orapw<instance_name>' password=${passwd} force=y さらに 補助インスタンスを起動するための init ファイルを作成します $ echo db_name=<primary db_name> > /tmp/aux.pfile $ echo db_unique_name=<standby db_name> >> /tmp/aux.pfile $ echo sga_target=800m >> /tmp/aux.pfile 注 : この pfile の sga のサイズは プライマリと一致する必要はありません インスタンス化プロセス中に 適切な値で新しい spfile が生成されます この補助 pfile は 補助インスタンスを起動するためだけに使用されます 6. 補助インスタンスを起動する 補助インスタンスは プライマリ サイトとスタンバイ サイト間の通信を有効にする一時的なインスタンス ( 単なるメモリ構造体 ) です プライマリでファイルをコピーして補助インスタンスをデータベースに変えることができるようになるまでのプレースホルダーと考えることができます この補助インスタンスは 以下のコマンドで起動します $ export ORACLE_SID=<standby instance name (STBY)> $ sqlplus / as sysdba SQL> startup nomount pfile='/tmp/aux.pf ile' ORACLE instance started. Total System Global Area bytes Fixed Size Variable Size Database Buffers Redo Buffers bytes bytes bytes bytes 注 : 使用されている pfile は 前の手順で生成したものです 37 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

41 7. TDE ウォレットを配布するオンプレミスからクラウドに TDE ウォレット ファイルをコピーし $ORACLE_HOME/sqlnet.ora ファイルで ENCRYPTION_WALLET_LOCATION として定義されているディレクトリに格納します この場所は ファイルを編集して変更可能です 注 : オンプレミスの TDE には Advanced Security オプションが必要です 8. インスタンス化するアクティブなデータベースから Recovery Manager の DUPLICATE を使用してスタンバイ データベースをインスタンス化します 付録 E には クラウドのスタンバイをインスタンス化するためのスクリプトが掲載されています クラウドでスタンバイ データベースが作成された後にこれらの追加パラメータを手動で設定し データベースを再起動します これらの値は プライマリとスタンバイの両方のデータベースで設定することが推奨されていますが 少なくともスタンバイでは設定する必要があります 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='*'; 注 :DB_BLOCK_CHECKSUM DB_BLOCK_CHECKING および DB_LOST_WRITE_PROTECT はブロックの破損防止に役立つパラメータです 保護機能のため一覧にある設定を行うことを推奨しますが DB_BLOCK_CHECKING はパフォーマンスに影響を与える可能性があり 値を選択するときにはこの点を考慮する必要があります DB_BLOCK_CHECKING は 値を FALSE にするとオフになります 注 :LOG_BUFFER を 256 MB に設定すると オンライン REDO ログからディスク I/O を実行することなく メモリからの REDO 読取りで非同期 REDO 転送を実行できるようになります 38 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

42 9. データベースを Oracle Restart に登録する データベースを作成した後は そのデータベースを Oracle Restart に登録する必要があります スタンバイ側 $srvctl add database -d <standby db_unique_name> -c SINGLE <result of hostname -s> -oh <oracle home> -r physical_standby -s <mount open> 10. クライアントのフェイルオーバーを構成する クライアントのフェイルオーバーの構成について詳しくは 付録 I を参照してください 11. Data Guard Broker を構成する 付録 F には Data Guard Broker を設定するためのスクリプトが記載されています 付録 E の内容は オンプレミス サーバーのファイルに貼り付け 指定された変数を設定した後に実行することができます すでに値が指定されている変数 ('<>' 以外の値 ) は クラウド デプロイメントを表すものなのでそのまま残すことができ 変更する必要はありません 設定する必要がある変数の設定値は Recovery Manager の DUPLICATE スクリプトで使用されているのと同じ値にすることができます 39 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR

43 付録 E Recovery Manager の DUPLICATE を使用したスタンバイ データベースの作成 この付録の内容は クラウド サーバーの任意の名前のシェル スクリプトに貼り付け 指定された変数を設定した後に実行することができます すでに値が指定されている変数 ('<>' 以外の値 ) は クラウド デプロイメントを表すものなのでそのまま残すことができ 変更する必要はありません 注 : プライマリ データベースの複数のマウント ポイントにファイルが分散している場合は 説明にあるとおり追加の変更が必要になります アクティブなプロセスからの複製についてさらに詳しくは MOS を参照してください アクティブなスクリプトからの Recovery Manager の DUPLICATE 実行 以下のスクリプトをコピーし 環境に合わせて変更を加え シェルに貼り付けて実行します このスクリプトでは Oracle Managed Files がオンプレミスで使用されていることを前提としています #!/bin/bash function gen_rman { echo "connect target sys/${passwd}@${premises_dbnm}" echo "connect auxiliary sys/${passwd}@${cloud_dbnm}" echo "run {" echo "allocate channel prmy1 type disk;" echo "allocate auxiliary channel stby1 type disk;" echo "allocate auxiliary channel stby2 type disk;" echo "allocate auxiliary channel stby3 type disk;" echo "allocate auxiliary channel stby4 type disk;" echo "duplicate target database for standby from active database" echo "spfile" echo "PARAMETER_VALUE_CONVERT= '${PREMISES_DBNM}', '${CLOUD_DBNM}'" echo "set db_unique_name='${cloud_dbnm}'" echo "set control_files='/u02/app/oracle/oradata/${cloud_dbnm}/control01.ctl','/u03/app/orac le/fast_recovery_area/${cloud_dbnm}/control02.ctl'" echo "set audit_file_dest='/u01/app/oracle/admin/${cloud_dbnm}/adump'" echo "set local_listener='(address=(protocol=tcp)(host=${cloud_ip})(port=${cloud_port}))'" echo "set fal_server='${premises_dbnm}'" echo "set log_file_name_convert='${premises_file_loc}/${premises_dbnm}', '${CLOUD_FILE_LOC}/${CLOUD_DBNM}', '${PREMISES_RECOV_LOC}/${PREMISES_DBNM}', '${CLOUD_REDO_LOC}/${CLOUD_DBNM}'" echo "set db_file_name_convert='${premises_file_loc}/${premises_dbnm}', '${CLOUD_FILE_LOC}/${CLOUD_DBNM}'" echo "set db_create_online_log_dest_1='${cloud_file_loc}'" echo "set db_create_online_log_dest_2='${cloud_redo_loc}'" echo "set db_create_file_dest='${cloud_file_loc}'" echo "set db_recovery_file_dest='${cloud_recov_loc}'" echo "set diagnostic_dest='/u01/app/oracle/diag/rdbms'" echo "set db_domain=''" echo "section size 10M" echo "dorecover" echo ";" echo "}" } export passwd='<sys password>' export PREMISES_DBNM='<Premise db_unique_name>' export PREMISES_IP='<Premises IP address>' export PREMISES_PORT='1521' 40 ORACLE PUBLIC CLOUD でのディザスタ リカバリ - オンプレミスでの本番 クラウドでの DR