Base Database Service/Exadata Database Service におけるData Guard解説 テクノロジー事業戦略統括 データベースソリューション部 2022 年 7 月 4日

1. Oracle Cloud 上でのOracle Database のデータベース冗長構成 2. Base Database Service / Exadata Database Service のData Guard自動Data Guard機能 3. 自動Data Guard構築 4. 自動Data Guard 構成の管理・運用 5. Data Guard構成パターン ー 発展編 Agenda Copyright © 2022, Oracle and/or its affiliates 2

Oracle Cloud上での Oracle Databaseの冗長構成 Oracle Active Data Guard / Data Guard 概要 Copyright © 2022, Oracle and/or its affiliates 3

Copyright © 2022, Oracle and/or its affiliates 4 データベースの停止時間の与える影響 35 万ドル 1時間あたりの停止時 間の平均コスト 1000 万ドル データセンターの計画 外停止や災害の平均 コスト 87 時間 年間平均停止時間 91% 過去24か月以内に データセンターの 計画外停止を経験した 企業の割合

データベースの可用性観点の提案/設計時に生じる典型的な課題 Copyright © 2022, Oracle and/or its affiliates 5 データベースの DR構成組むにはどうしたいいの？ SLAを高める・計画停止時間や障害時のRTO/RPOを短くするには、 どうしたらいいの？ DR環境持ちたいけれどコストは抑えたい DR環境の重要性は理解しているが、 普段使わない環境になかなかコストはさけない 切り替え作業が大変で、実際切り替えはしない データベースの 可用性と冗長構成 クラウドにDR環境保持(Hybrid) 切り替えの簡易性と重要性 利活用機能や 自動データ保護機能

高可用性、ディザスタ・リカバリおよびデータ保護 Oracle Maximum Availability Architecture (MAA) Copyright © 2022, Oracle and/or its affiliates 6 Scale out Data protection Reference architectures Deployment choices HA features, configurations and operational practices Customer insights and expert recommendations Production site Replicated site Replication Generic Systems Engineered Systems DBCS ExaCS/ExaCC Autonomous DB Flashback RMAN + ZDLRA Continuous availability Application Continuity Global Data Services Active replication Active Data Guard RAC Sharding ASM 24/7 GoldenGate Bronze Silver Gold Platinum

あらゆる障害シナリオに対処できるよう設計とテスト済み Exadata Maximum Availability Architecture Copyright © 2022, Oracle and/or its affiliates 7 最良のMAAデータベース・プラットフォーム | 最速のRACインスタンス/ノード障害リカバリ | 最速バックアップ-RMANによるストレージへのオフロード 詳細なASMミラー化統合 | 最速のData Guard REDO適用 | 一時停止を最小に抑えた完全な障害テスト 頻繁に更新されるヘルス・チェック HAフェイルオーバーの ためのローカル・スタン バイ データの整合性 チェックを伴う REDOベースの変 更レプリケーション LAN WAN Exadataシステム内 サイト内 ディザスタ・リカバリのた めのリモート・スタンバ イ 冗長化されたシステム 冗長化された データベース オンラインのパッチ適用、 再構成、拡張 サイト間 DATABASE IN-MEMORY DATABASE IN-MEMORY DATABASE IN-MEMORY 冗長化された ソフトウェア アクティブ・アクティ ブ・クラスター ストレージ/フラッ シュのミラ−化 冗長化された ハードウェア サーバー、ストレー ジ、フラッシュ、ネッ トワーク、電源 冗長化されたシステム 冗長化されたデータベース

要件に応じて計画停止/計画外停止を考慮した構成を検討 高可用性構成 Copyright © 2022, Oracle and/or its affiliates 8 RAC構成で DBバックアップ取得 DBシステム冗長構成 複数スタンバイ構成 複製サイトの複数スタンバイ構成 Primary Standby Region #1 Region #2 DB Backup (Object Storage) DB Backup (Object Storage) Primary Standby DB Backup (Object Storage) DB Backup (Object Storage) Data Guard/ Golden Gate DG/GG Data Guard/ Golden Gate ケース1 定期メンテナンス許容可能 + RTO/RPOがバックアップ・リスト アで満たせる ケース2 定期メンテナンス時や 障害時などの DB停止時間を短くしたい ケース3 サイト障害時にも 冗長構成をとった構成を 保ちたい ケース4 大規模・多重障害時も含め RPO/RTOを ゼロに近づけたい DB Backup (Object Storage) Primary Standby Region #1 Region #2 Standby DB Backup (Object Storage) Data Guard Data Guard RAC Region #1 Region #2 DB Backup (Object Storage) Replication DB Backup (Object Storage) Primary Region #1 Region #2 Standby DB Backup (Object Storage) Data Guard 高い可用性

代表的な方式 Oracle Cloud上でのOracle Databaseの冗長構成の方式 アクティブ-アクティブ・レプリカ Oracle GoldenGate レプリカ・データベース Oracle Active Data Guard データベースのクラスタリング Oracle Real Application Clusters 利用可能なエディション • Exadata Database Service : 利用可 • Enterprise Database Service: Extreme Performance 利用可能なエディション • Exadata Database Service : 利用可 • Base Database Service : • Data Guard : Enterprise Edition以上 • Active Data Guard : Extreme Performance 利用可能なエディション • Exadata Database Service : 利用可 • Base Database Service : 利用可 上記に加えて、Oracle GoldenGateライセン スが別途必要 Copyright © 2022, Oracle and/or its affiliates 9

Real Application Clusters/Active Data Guard/GoldenGate Oracle Databaseのデータベース冗長構成の方式の比較 Real Application Clusters Data Guard GoldenGate 概要 Oracle Databaseのクラスタリング機能 Oracle Databaseのレプリケーション機能 データベースのレプリケーション製品 データベースの 構成 １つのデータベース 複数の同じデータベース (フィジカル・スタンバイ) 異なるデータベースで、指定した範囲のデー タ同期 クラウドでの 利用 Oracle Cloud のPaaSのみで サポート。同一AD内のみ。 クラウド上での使用可否の制限なし クラウド上での使用可否の制限なし データ整合性 全インスタンスで同じデータにアクセスできる ような仕組み 同期ラグがあるため反映するまでは差分が 発生する 同期ラグがあるため反映するまでは差分が 発生する。また、両DB更新可能のため、差 分は発生する可能性あり 障害時の 切り替え 自動。数秒～数分(障害ケースやExadata かどうかで異なる) 手動(自動切り替え機能あり)。 数十秒～数分(障害ケースや適用ラグなど 状況で異なる) データベースの明示的な切り替えはない。ア プリ側で切り替えが必要 障害時のデータロス トの可能性 なし 同期転送：なし(単一障害) 非同期転送：あり得る 非同期転送のためあり得る データ保護 ASMでの冗長構成による処理継続、 データ破損の即時自動修復 ADGの自動ブロックメディアリカバリによる自 動修復(十数秒) - Copyright © 2022, Oracle and/or its affiliates 10

Oracle Database自身が持つレプリケーション機能でデータ保護・可用性の提供 + 適切なROIを実現 Oracle Active Data Guard / Data Guard プライマリDB スタンバイDB 同期 破損ブロックの 自動修復(※) レポーティング(※) バックアップ(※) ※Active Data Guardオプションが必要 データ保護 迅速な切り替え リソースの有効活用 スイッチオーバー フェイルオーバー REDO転送によって自動で同期がとられ ることで、データーベースを障害およびデー タ破損から保護 計画/計画外停止時に迅速に切り替え られることで、ダウンタイムを縮小し、業務 を継続 レポーティング、テストやバックアップ用途 でスタンバイ・データベースを活用可能 Copyright © 2022, Oracle and/or its affiliates 11

レプリカDBをData Guardで構成することのメリット • 自動データ同期によるデータ保護 • ブロック破損コピーの防止 • 自動ブロック破損修復 • 有事の迅速な切り替え • 切り替え後に壊れた旧プライマリを簡単 に復旧可能 • 参照系処理のオフロード • (19c-)更新処理も可能に • 普段から利用することによるレプリカ 側のデータ正常性の確認 • スナップショット・スタンバイに一時的 に切り替え検証利用 • 計画停止時のサービス継続 • 有事の切り替えに備えた正常性確認 • 定期的な切り替えを推奨 プライマリ スタンバイ → プライマリ 同期 切り替え 同期 計画停止 週末 22:00-08:00 データ保護(DR) リードレプリカ/検証 メンテナンス切り替え プライマリ スタンバイ プライマリ → スタンバイ スタンバイ → プライマリ 同期 切り替え Copyright © 2022, Oracle and/or its affiliates 12

Data Guard のユース・ケース DR環境・HA構成 クエリ・オフロード テスト環境 メンテナンスや移行 バックアップ処理のオフロード スナップ/クローンのソース ▶ 可用性レベルを向上した自動データ保護 ▶ 分析などの参照系のオフロード ▶ プライマリのバックアップ負荷削減 ▶ プライマリの複製時の負荷削減 ▶ 一時的に書き込み可能モードに変換してテスト ▶ メンテナンス、パッチ適用、移行などでダウンタイムを抑える Copyright © 2022, Oracle and/or its affiliates 13

Base Database Service/ Exadata Database Service の自動Data Guard機能 Data Guardアソシエーション概要 Copyright © 2022, Oracle and/or its affiliates 15

Data Guard アソシエーション Data Guard 構成をUI/APIから簡単に、構成・管理・切り替え・障害後の回復が可能 • サービス・インスタンス間でのDBレプリケーション • 同一コンパートメント内、同一サービス間、同一DBバージョン間 • 1つのプライマリ・データベースに対して、1つのフィジカル・スタンバイが管理可能 • Data Guard構成 • 管理のためにData Guard Broker機能が有効 • Active Data GuardかData Guardの構成時選択・切替が可能 • 最大パフォーマンスモードか最大可用性モードが選択可 • スタンバイ・データベースは自動バックアップ機能は無効 • 上記の構成外の場合、手動でData Guardを構築も可能 • 別コンパートメント間、異なるサービス間、複数スタンバイ(2～30)、 フィジカル・スタンバ イ以外、OnPとの構成など • ホワイトペーパー : Oracle Exadata Cloudを使用したディザスタ・リカバリ 自動Data Guard機能 OCI Documentation Exadata Cloud Service > How To Guide > Using Oracle Data Guard with Exadata Cloud Infrastructure OTN 連載もしもみなみんがDBをクラウドでうごかしたら第19回 DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS) 同期 Copyright © 2022, Oracle and/or its affiliates 16

Data Guard フィジカル・スタンバイの前提 プライマリとスタンバイで一致させる必要があるもの • Oracle Databaseのパッチレベル • データベース構造 (例:CDB構成 か Non-CDB構成か) • オプション機能のライセンス プライマリとスタンバイで一致させる必要はないもの • DB以外のS/W・H/Wバージョン (例:GI 19cとGI18c) • インスタンス数(例: RACとシングル、4ノードRACと2ノードRAC) • 仮想環境かベアメタル環境 など Doc ID 2183849.1: Oracle Data Guard Configuration Component Version Interoperability Doc ID 413484.1: Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration Oracle Data Guard 利用前提 Copyright © 2022, Oracle and/or its affiliates 17

OCI上のOracle DatabaseでData Guard 構成を検討する際に確認すること Data Guardが利用可能な構成か Data Guard(フィジカル・スタンバイ)前提条件 • プライマリとスタンバイで一致させる必要があるもの • Oracle Databaseのパッチレベル • データベース構造 (例:CDB構成かNon-CDB構成か) • オプション機能のライセンス 参照) MOS Doc ID 2183849.1、 Doc ID 413484.1 GoldenGateは異機種間レプリケーションが可能な製品 • ただし、フィジカル・レプリケーションではなく、 レプリカ先もActive(更新可能)であり非同期のため データ保護を目的として使う場合にデータ差分を 防ぐ仕組みは必要 別のソリューション検討(GoldenGateなど) 自動Data Guard機能が利用可能な構成か 自動Data Guard機能の前提条件 • Oracle Cloud Infrastructure内 • 同一コンパートメント内、同一DBバージョン間 • フィジカル・スタンバイを１つ管理 手動Data Guardを検討 • OnP、他OCIサービス、他社クラウド間など • 手動Data Guard構成の場合、Data Guardの管理も 手動で従来の方式を利用 • データベースの管理は、スタンバイのデータベース作成をツール (dbaasapi)から一度行うことで可能 ホワイトペーパー: Oracle Exadata Cloudを使用したディザスタ・リカバリ YES NO NO Copyright © 2022, Oracle and/or its affiliates 18

Base Database Service 自動バックアップ • UI/API による自動バックアップ構成は、スタンバイ・データベースでの有効化は可能だが、スタンバイ・ロールの期間は自 動バックアップは実行されない (自動バックアップは、プライマリ・ロールの状態でのみの実行となる) DBシステムの削除 • DGアソシエーションが有効な間は、DGアソシエーションに含まれるDBシステムの削除はできない。そのため、削除する 場合は先にスタンバイ・データベースのDBシステム削除(=DGアソシエーションの無効化)が必要 Data Guardアソシエーション有効化 – 注意事項 OCI Documentation Bare Metal and Virtual Machine DB Systems > Manage > Oracle Data Guard Association > Use Oracle Data Guard on a DB systems Copyright © 2022, Oracle and/or its affiliates 19

Exadata Database Service 自動バックアップ • UI/API または dbasscli による自動バックアップ構成は、スタンバイ・データベースでの有効化は可能だが、スタンバイ・ ロールの期間は自動バックアップは実行されない (自動バックアップは、プライマリ・ロールの状態でのみの実行となる) DBやVMクラスタの削除 • DGアソシエーションが有効な間は、DGアソシエーションに含まれるDBやVMクラスタの削除はできない。そのため、削除 する場合は先にスタンバイ・データベースの削除(=DGアソシエーションの無効化)が必要 Data Guardアソシエーション有効化 – 注意事項 OCI Documentation Exadata Cloud Service > How-to Guides> Using Oracle Data Guard with Exadata Cloud Infrastructure Copyright © 2022, Oracle and/or its affiliates 20

手動(コマンド)でData Guardを構築可能 • オンプレミスや他クラウドとのOCI外との Hybrid Data Guard構成 • Oracle Cloud内 • 別コンパートメント間、異なるサービス間、 複数スタンバイ(2～30)、 フィジカル・スタ ンバイ以外など Data Guardアソシエーション機能が利用できない場合 ap-tokyo-1 AD1 VCN VCN 別コンパートメント間 別サービス間 複数スタンバイ OnPや他クラウドと Hybrid DG 手順参考) ホワイトペーパー Oracle Exadata Cloudを使用したディザスタ・リカバリ Copyright © 2022, Oracle and/or its affiliates 21

管理範囲の差違：OCI ExadataのStorage Server の管理はオラクル • Storage Server Software のパッチは四半期ごとにアップデート S/Wバージョンの差異：クラウド上は提供可能なバージョンの最新版で構築済 • Doc ID 2333222.1: Exadata Cloud Service Software Versions • 開発やDRの場合は、オンプレミスと差違が生まれる可能性がある • Data Guardの場合は、プライマリとスタンバイでデータベースのパッチレベルを合わせる必要がある • Doc ID 2183849.1: Oracle Data Guard Configuration Component Version Interoperability データベースやストレージの構成の差異 : クラウド上は構成済の環境を利用 • デフォルトで表領域暗号化有効 • Doc ID 2359020.1: Oracle Database Tablespace Encryption Behavior in Oracle Cloud • 12c以上はデフォルトでCDB構成 • Doc ID 2528257.1 : Creating non-CDB databases using Oracle Database 12c on the Exadata Cloud Service • Exadata Smart Flash Cache はWrite-Backモード(変更不可)、HCモデルのみなど 運用・管理の方式やフローの差違 : 手順書やサポートフローなど Hybrid Data Guard構成での注意点 (1/3) Copyright © 2022, Oracle and/or its affiliates 22

運用・管理の方式やフローの差違 : 手順書やサポートフローなど • Data Guardの管理方法について • 手動でData Guardを構成した場合、 OCIコンソール(UI/API)など、OCIの標準ツールからのData Guard管理は行えません • OCI Database Services上のデータベースの管理自体は行えます • スイッチオーバーやフェイルオーバーなどのData Guard管理操作は、従来通りの管理方法(Data Guard Broker、SQL*Plusや Enterprise Manager Cloud Control)で行ってください • 参考 ) Monitoring a Data Guard Configuration (Doc ID 2064281.1) Hybrid Data Guard構成での注意点 (2/3) Copyright © 2022, Oracle and/or its affiliates 23

Oracle Database オプションの差異 (特にBYOLではない場合) • Exadata Database Service では、全てのオプションが利用可能 • Base Database Serviceでは、エディションごとに利用可能なオプションがセット • それ以外の環境では、オプションを必要に応じて保持しているケースがほとんど • 既存の環境で保持していないオプションについて • クラウド側で利用する場合、オンプレミスなどOCI外の環境側にもラインセスが必要 • Active Data Guard(ADG)を利用する場合、プライマリ側にもADGライセンスが必要 • クラウドに合わせて、利用しないオプションをオンプレミス側に追加する必要はない • その場合、既存環境で利用しているオプションのみクラウド上で利用可能 • Advanced Security Optionのライセンスは、基本双方で持つことが推奨 • 必要可否や挙動、必要となるケースがOracle Databaseのバージョンによって異なるので、詳細は下記MOS Noteを確認 • MOS Note Oracle Database Tablespace Encryption Behavior in Oracle Cloud (Doc ID 2359020.1) Hybrid Data Guard構成での注意点 (3/3) Copyright © 2022, Oracle and/or its affiliates 24

自動Data Guard構築 Data Guardアソシエーションの有効化 Copyright © 2022, Oracle and/or its affiliates 25

BaseDBの場合 (ComputeとDBが1対1) Exadata Database Serviceの場合 (ComputeとDBが1対N) Data Guard構築手順イメージ ①プライマリDBの DBシステムとDB作成 ② プライマリDBから Data Guardの有効化をして スタンバイDBのDBシステムと スタンバイDB作成 ①プライマリDBの VMクラスタを作成 ③スタンバイDBの VMクラスタ作成 ②プライマリDBを作成 ④プライマリDBから Data Guardの有効化をして スタンバイDB作成 Copyright © 2022, Oracle and/or its affiliates 26

Base Database Service プライマリ用のDBシステムが作成済み • 同一コンパートメント内にスタンバイ用のDBシステムが作られる ライセンス・タイプ • Data GuardはEnterprise Edition以上、Active Data GuardはExtreme Performance(プライマリ・スタンバイ でそろえる) • BYOL: Active Data Guardを利用する場合にはオプション・ライセンスが必要 Oracle Database バージョン/RU • プライマリおよびスタンバイ・データベースは Oracle Database バージョン/RU、パッチレベルを一致させる必要がある Data Guardアソシエーション有効化 – 確認事項・事前準備 OCI Documentation Bare Metal and Virtual Machine DB Systems > Manage > Oracle Data Guard Association > Use Oracle Data Guard on a DB systems Copyright © 2022, Oracle and/or its affiliates 27

Base Database Service IAMサービス・ポリシー • 管理ユーザーのIAMサービス・ポリシーでの権限が付与済 ネットワーク要件 • Data Guard を構成するDBCS間の通信 (TCP 1521 番ポート) を許可しておく • セキュリティ・リストのイングレスおよびエグレス・ルールを適切に構成 • 同一リージョン内での構成: 同一 VCN 内に、プライマリおよびセカンダリのサブネットを構成する • 異なるリージョン間での構成: RPC を使用したリモート VCN ピアリングを構成する • それぞれのリージョンに構成する VCN の CIDR が重複しないようにする Data Guardアソシエーション有効化 – 確認事項・事前準備 OCI Documentation Bare Metal and Virtual Machine DB Systems > Manage > Oracle Data Guard Association > Use Oracle Data Guard on a DB systems Copyright © 2022, Oracle and/or its affiliates 28

Exadata Database Service プライマリとスタンバイ用のVMクラスタが作成済み • 同一コンパートメント内にExadata Cloud Infrastructureを2つ ライセンス・タイプ • デフォルトでData GuardもActive Data Guardも使用可能 • BYOL: Active Data Guardを利用する場合にはオプション・ライセンスが必要 Oracle Database バージョン/RU • プライマリおよびスタンバイ・データベースは Oracle Database バージョン/RU、パッチレベルを一致させる必要があるた め、プライマリとするデータベースの Oracle Database バージョン/RU を、スタンバイとする VMクラスタにおいて準備をし ておく Data Guard 有効化時、既存のデータベース・ホームを選択する場合 • 同一バージョン/RU のデータベース・ホームを作成済みにしておく Data Guard 有効化時、新規データベース・ホームの作成で構成する場合 • 同一バージョン/RU の データベース・ソフトウェア・イメージを事前に準備しておく Data Guardアソシエーション有効化 – 確認事項・事前準備 OCI Documentation Exadata Cloud Service > How-to Guides> Using Oracle Data Guard with Exadata Cloud Infrastructure Copyright © 2022, Oracle and/or its affiliates 29

Exadata Database Service IAMサービス・ポリシー • 管理ユーザーのIAMサービス・ポリシーでの権限が付与済 ネットワーク要件 • Data Guard を構成するExadata Database Serviceのクライアント・サブネット間の通信 (TCP通信用のポート) を 許可しておく • セキュリティ・リストのイングレスおよびエグレス・ルールを適切に構成 • 同一リージョン内での構成: 同一 VCN 内に、プライマリおよびセカンダリのサブネットを構成する • 異なるリージョン間での構成: RPC を使用したリモート VCN ピアリングを構成する • それぞれのリージョンに構成する VCN の CIDR が重複しないようにする Cloud Tooling (dbaastools) バージョン • プライマリおよびスタンバイの環境において一致させる パスワード要件 • プライマリおよびスタンバイ・データベースにおける SYS パスワードおよび TDE ウォレット・パスワードは全て同一である必 要がある Data Guardアソシエーション有効化 – 確認事項・事前準備 OCI Documentation Exadata Cloud Service > How-to Guides> Using Oracle Data Guard with Exadata Cloud Infrastructure Copyright © 2022, Oracle and/or its affiliates 30

有効化の手順は、下記のチュートリアルをご参照ください Base Database Service OCI チュートリアル : Data Guardを構成しよう https://oracle-japan.github.io/ocitutorials/database/dbcs106-dataguard/ Exadata Database Service OTNブログ : DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS) https://blogs.oracle.com/otnjp/post/minamin-cloud-019-dbcs-exacs- dataguard Data Guard構築 : Data Guard アソシエーションの有効化 Copyright © 2022, Oracle and/or its affiliates 31

Data Guardアソシエーションで作成されるData Guardの構成 デフォルト設定値 変更可否 同期モード 同期 or 非同期を選択 〇 (UI/API) 保護モード 最大パフォーマンスモード or 最大可用 性モードを選択 〇 (UI/API) REDO圧縮 無効 〇 Data Guard Broker 有効 ×(無効化すると、DG構成はコンソール などのクラウド・ツールの管理外になりま す) 自動切り替え(ファスト・スタート・フェイルオーバー) 無効 〇 REDO適用の自動パラレル化(12.2以降) 有効 〇 Flashback Database 有効 △(無効化すると、”回復”機能が利用 できなくなるため非推奨) Copyright © 2022, Oracle and/or its affiliates 32

自動Data Guard構成の運用・管理 Data Guardアソシエーションの運用・管理機能 Copyright © 2022, Oracle and/or its affiliates 33

• OCIコンソール(UI)やAPIなどで簡単に運用・監視が可能 • クラウド・ツールでより詳細な運用・管理は、従来からの Data Guardの管理方法(Data Guard関連の機能や サービス)も利用可能 • Data Guard Broker (DGMGRL ユーティリティ) • Oracle Enterprise Manager Cloud Control • Oracle製品の管理ツール • MarketplaceからIaaS上のインストール済イメージも利用 可能 • SQL*Plus Data Guard 環境の運用・監視 運用 • ロール変更(スイッチオーバー、フェイルオーバーなど) • 旧プライマリの復旧(回復) 監視 • Data Guard関連構成・設定値の確認 • 同期状態の確認(REDO 転送ラグ、REDO 適用ラグ、 REDO適用性能など) プライマリ スタンバイ Copyright © 2022, Oracle and/or its affiliates 34

Control Plane Data Guard アソシエーションが有効な環境では、Data Guard Broker機能が有効 • Data Guard Broker は、Data Guard環境を管理す る仕組み(フレームワーク) • Data Guard Brokerのプロセスが、Data Guard 環境の管理・監視 • ユーザーは、OS上でDGMGRLユーティリティを利 用してData Guard環境の管理が可能 • OCIコンソール(UI)/APIでのData Guardの管理・運 用は、OS上のData Guard Brokerのプロセスと連携 • Data Guard Broker機能を無効化すると、 UI/APIなどを用いた管理ができなくなるため、無効 化しないでください Data Guardアソシエーションが有効な環境の管理 プライマリ スタンバイ Data Guard Broker構成 dmon dmon Cloud Tooling Cloud Tooling Broker プロセス Broker プロセス DGMGRL> #dbaascli/dbcli Copyright © 2022, Oracle and/or its affiliates 35

スイッチオーバー • メンテナンスなど主に計画停止に行うロール変換 • 各データベースが正常にオープン(またはマウント)さ れ、データが完全に同期をとれている場合に実施 可能 • 切り替え後もData Guard構成(スタンバイがある 状態)のまま、継続運用やロールを戻す(スイッチ バック)ことが可能 フェイルオーバー • 障害発生時など主に計画外停止で行うロール変換 • プライマリ・データベースが停止した状態など • 最大保護モード以外はデータ損失可能性あり • 旧プライマリは、新スタンバイとして同期がとれない 場合、スタンバイ・データベースとして復旧もしくは 再作成が必要 Data Guardの切り替えの種類 プライマリ → スタンバイ スタンバイ → プライマリ プライマリ スタンバイ → プライマリ Copyright © 2022, Oracle and/or its affiliates 36

スイッチオーバー • プライマリ側のコンソールから実施 フェイルオーバー • スタンバイ側のコンソールから実施 Data Guardの切り替えの種類 Copyright © 2022, Oracle and/or its affiliates 37

• フェイルオーバー後、旧プライマリはData Guard構成 から外れるため、スタンバイがない状態 • フェイルオーバーは、主に旧プライマリが利用できな い状態(壊れた状態)の際にスタンバイに切り替え がされるため、旧プライマリはData Guard構成か らはずれる • 「回復」機能でコンソール上から簡単に、旧プライマリを スタンバイとしてデータベースを回復させてData Guard 構成を再編成可能 • Flashback Databaseの機能を利用した仕組み で、 Data Guard Brokerによってワンコマンドで実 行される 旧プライマリの回復 プライマリ ①プライマリで障害発生、フェイルオーバー ②旧プライマリをFlashback Databaseで障害発生前の 時点に復旧 ③復旧後、スタンバイとしてData Guard構成へ追加。 過去時点に戻った分のデータ差分は自動で同期 同期 ②と③をコンソール/CLIから簡単に実行できる 切り替え スタンバイ →プライマリ 旧プライマリ プライマリ スタンバイ プライマリ Copyright © 2022, Oracle and/or its affiliates 38

回復 • プライマリ側から実施 旧プライマリの回復 Copyright © 2022, Oracle and/or its affiliates 39

* Data Guard対応(ADG or DG)、保護モード、転送モード、DB管理者パスワードの変更が可能 参考) Exadata Cloud API/CLI Alignment Matrix (Doc ID 2768569.1) Data Guard環境の運用・監視一覧 カテゴリ 内容 クラウド・ツール クラウド以外でも利用可能なツール コンソール(UI)/ API/CLI OS上のCLI (BaseDB: dbcli ExaDB-D:dbaascli) DG Broker DGMGRL SQL*Plus Enterprise Manager Cloud Control 運用 ロール切り替え (スイッチオーバー/フェイルオーバー) ✔ dbcli : - dbaascli : ✔ ✔ ✔ ✔ 回復 ✔ dbcli : - dbaascli : ✔ ✔ ✔ ✔ スナップショット・スタンバイへの変換 - - ✔ ✔ ✔ Data Guard関連構成/設定変更 一部(*) dbcli : - dbaascli : 一部(*) ✔ ✔ ✔ 自動切換え(ファスト・スタート・フェイルオーバー) - - ✔ - ✔ 監視 同期モードの確認 ✔ ✔ ✔ ✔ ✔ Data Guard関連構成/設定値の確認 - ✔ ✔ ✔ ✔ REDO 転送ラグ - ✔ ✔ ✔ ✔ REDO 適用ラグ ✔ ✔ ✔ ✔ ✔ REDO 適用性能の確認 ✔ ✔ ✔ ✔ ✔ Copyright © 2022, Oracle and/or its affiliates 40

最初にスタンバイ・データベースを終了(削除)しましょう • スタンバイ・データベースが紐づけられている(Data Guardアソシエーションが有効化)状態の時に、プライマリ・データベー スは終了(削除)不可 プライマリ・データベースだけ削除したい場合は、まずはロールを切り替えましょう • 想定ケース : プライマリ・データベースの環境の復旧が難しい場合など • 手順 1. スイッチ・オーバーもしくはフェイル・オーバーでロールを切り替え、削除対象のデータベースをスタンバイに変更 2. スタンバイ・データベースを削除 Data Guardアソシエーション構成内のデータベースを削除する場合 Copyright © 2022, Oracle and/or its affiliates 41

転送方式による違い  データ保護 • プライマリでのデータ更新はスタンバイへの転送完了 後に確定  パフォーマンス影響 • スタンバイへの転送時間に依存してプライマリの更新 処理が待機  データ保護 • プライマリで更新されたらスタンバイへの転送未完了で も確定  パフォーマンス影響 • プライマリへの更新処理はスタンバイへの転送を待機 しない Data Guardによるデータ保護の仕組み 同期転送 (SYNC) 非同期転送 (ASYNC) 3.応答 2.転送 4.確定 1.処理 1.処理 2.確定 2.転送 Copyright © 2022, Oracle and/or its affiliates 42

REDOログ転送モード 同期 同期(Fast Sync) 非同期 COMMIT時の動作 RFSプロセスがREDO情報をスタ ンバイREDOログファイルに記録 したACKを返すのを待機 （COMMITがスタンバイで永続 化されないとCOMMITが完了し ない） RFSプロセスがREDO情報をメモ リに記録したACKを返すのを待 機 （COMMITがスタンバイで受信 されないとCOMMITが完了しな い） RFSプロセスが受信したことを待 機しない DURABILITYの保証 データ・ロストしない プライマリとスタンバイが同時に 障害を起こさないという想定で データ・ロストしない プライマリ障害の内容によっては データ・ロストが起こり得る プライマリの性能影響 COMMITに影響 COMMITに影響 影響しない 主用途 同一データセンター内でのレプリ ケーション 同一データセンター内でのレプリ ケーション ディザスタ・リカバリー・サイト（東 京-大阪など） 転送設定 SYNC SYNC NOAFFIRM ASYNC 保護モード 最大保護、最大可用性 最大可用性 最大パフォーマンス パフォーマンス重視 データ保護重視 Copyright © 2022, Oracle and/or its affiliates 43

保護モードによる違い Data Guardによるデータ保護の仕組み 最大保護 最大可用性 最大パフォーマンス 確実なデータ転送の補償のために、スタン バイから応答が受信できないとプライマリは 処理を停止。 (12.2以降)複数スタンバ イがある場合、1つのスタンバイから応答が あれば継続 ユーザトランザクションがcommit されると制御はアプリケーションに戻 される パフォーマンス重視 データ保護重視 SYNC→ASYNC ASYNC SYNC 可用性を低下させないように、1つ以上 の同期スタンバイの確認がとれない場合、 最大パフォーマンス・モードと同様の動作 となる SYNC プライマリの性能を低下させないように、ト ランザクションのコミットとREDO転送・受 信は非同期で行われる Fast Sync(SYNC NOAFFIRM)の利用も可能 Copyright © 2022, Oracle and/or its affiliates 44

Data Guardアソシエーションが有効な環境のFRA領域の使用量/率について • Flashback Database機能がデフォルトで有効 • Data Guardアソシエーションが有効な環境では、回復(プライマリ・データベースの障害後の復旧)機能に必要 • Flashback Logの出力先に、Fast/Flash Recovery Area(FRA)領域が利用されるため、FRA領域の使用量/率が 無効時よりも多くなります • FRAのサイズ調整・拡張を検討 • DB_RECOVERY_FILE_DEST_SIZEパラメータの調整 • DBCSの場合はストレージでRECOのスケーリング など • 拡張ができない場合・難しい場合 • FRA内に削除可能なファイルがあれば、データベースが不要なファイルを自動で判断・削除します • それでもスペースを確保するのが難しい場合 • バックアップを取得、不要なファイルをRMANコマンドでチェック＆削除、要件に応じて保持期間(Retention Policy)の変更 • 詳細情報 • Doc ID 305648.1: What is a Flash / Fast Recovery Area and how to configure it ? • Doc ID 829755.1: Space issue in Fast / Flash Recovery Area - FRA Full • Doc ID 305812.1: Flash Recovery area - Space management Warning & Alerts Fast/Flash Recovery Area – FRA の運用 Copyright © 2022, Oracle and/or its affiliates 45

Data Guard構成パターン – 発展編 Copyright © 2022, Oracle and/or its affiliates 46

主な構成パターン 最小構成 マルチ・スタンバイ カスケード リモート・スタンバイ 大規模障害を見据えた災対環境 ローカル・スタンバイ 瞬時の切り替えや同期転送が可能な 近距離のスタンバイ マルチ・スタンバイ ローカル・リモートともにスタンバイを持ち、 状況に応じて切り替え。スタンバイごと に、同期・非同期を設定可 Far Sync(遠隔同期)スタンバイ 遠隔地スタンバイとの同期転送の中継 サーバーを置き、データ保護を高める カスケード・スタンバイ テスト用途などスタンバイとは別に レプリカを持ちたい場合 Copyright © 2022, Oracle and/or its affiliates 47

主な構成パターン – Base Database Service / Exadata Database Serviceの場合 最小構成 マルチ・スタンバイ カスケード リモート・スタンバイ 大規模障害を見据えた災対環境 ローカル・スタンバイ 瞬時の切り替えや同期転送が可能な 近距離のスタンバイ マルチ・スタンバイ ローカル・リモートともにスタンバイを持ち、 状況に応じて切り替え。スタンバイごと に、同期・非同期を設定可 Far Sync(遠隔同期)スタンバイ 遠隔地スタンバイとの同期転送の中継 サーバーを置き、データ保護を高める カスケード・スタンバイ テスト用途などスタンバイとは別に レプリカを持ちたい場合 Data Guardアソシエーションで可能 手動での設定・構築が必要 Copyright © 2022, Oracle and/or its affiliates 48

Far Sync(遠隔同期)インスタンス構成例 • 遠隔地の場合、システム性能とデータ保護のバランス から非同期モードが選択されるため、リカバリ不能な停 止によって生じる様々なレベルのデータ損失が発生 • Far Sync(遠隔同期)インスタンスを利用することで、 遠隔地スタンバイで実現が難しかった「データロスの可 能性を低くする構成」を実現 • クラウド・ツールは対応していないので、自動Data Guard機能の構成に手動で設定変更 • Far Sync(遠隔同期)インスタンス(12.1以降) • REDO転送の中継地となる、Active Data Guardの機能 • Far SyncインスタンスにはDBライセンス不要 (制御ファイルとログ・ファイルのみ保持) • Far Syncインスタンスの冗長化も可能 「リージョン間だけどRPOを高めたい(データロスの可能性を減らしたい) 」 ap-tokyo-1 AD1 VCN ap-osaka-1 AD1 VCN 同期 非同期 Copyright © 2022, Oracle and/or its affiliates 49

従来の課題 災害対策(DR)環境として遠隔地/長距離間でのData Guard構成でデータ損失ゼロを実現するには… • スタンバイ側に転送されたことを保証する同期モード(SYNC)を利用したいが、本番環境のパフォーマンス影響(コ ミット処理)が課題となり非同期モード(ASYNC)を利用 • 複数スタンバイ(ローカルを追加)はコストや複雑な管理手順が課題 → 多くのシステムでは、データベースのパフォーマンスに影響を与えるよりはデータ保護レベルを妥協せざるを得ず、結 果、リカバリ不能な停止によって生じる様々なレベルのデータ損失が発生 遠隔地/長距離間でのData Guard構成の課題 スタンバイへの転送 プライマリへの 書き込み 更新処理の待機時間 距離(ネットワーク性能)や スタンバイ側のI/O性能に依存 して増大 同期 非同期 Copyright © 2022, Oracle and/or its affiliates 50

遠隔地スタンバイで実現が難しかった「ゼロ・データロスのスタンバイ構成」を実現 • 同期転送のオーバーヘッド軽減 : 同期転送時のネットワーク・レイテンシを最小限に抑え、本番環境(プライマリ)へのパ フォーマンス影響(コミット処理) を最小化 • ゼロ・データロスの実現 : プライマリ停止時にもREDOデータは転送済のため遠隔地への転送を継続 • 最小限のファイル構成 : 制御ファイルとREDOログファイルのみ • シームレスなロール変換 : Far Syncインスタンスを意識せずロール変換の実行が可能 Far Sync(遠隔同期)インスタンス プライマリ スタンバイ 同期 Far Sync インスタンス 非同期 Active Data Guard 12.1~ Copyright © 2022, Oracle and/or its affiliates 51

特徴と前提 • Far Sync (遠隔同期)サーバーの前提 • 制御ファイルとログ・ファイルのみを保持するインスタンスのため、Oracle Databaseのライセンスは不要 • SGA用の小さなメモリとCPU (プライマリやスタンバイ同等は不要) • Active Data Guard ライセンスの機能 • プライマリとスタンバイで必要 • Active Data Guard 構成関連 • REDO転送先にできるスタンバイの数 : 最大29 • 保護モード : 最大可用性モード Far Sync (遠隔同期)インスタンス 一時ファイル Oracle Database Software データベースのサイズの大半を占める データファイルが不要 PFILE/SPFILE Oracle Netファイル 制御ファイル スタンバイ REDOログ データ ファイル オンライン REDOログ Copyright © 2022, Oracle and/or its affiliates 52

ファスト・スタート・フェイルオーバー構成 • デフォルトのData Guard構成の場合、障害時の切り替えは 手動で明示的に行う。RTOを考えた時に、迅速に切り替えら れるかを重要とし、自動で切り替えたいというケースもある • Data Guardのファスト・スタート・フェイルオーバー機能を利用 することで、自動フェイル・オーバーが可能 • OCIクラウド・ツールは対応していないので、手動で設定 • ファスト・スタート・フェイルオーバー概要 • Oracle Data Guard Broker の機能 • Data Guard Brokerが有効な環境で利用可能(ファスト・ス タート・フェイルオーバーはデフォルト無効) • オブサーバという監視プロセスが切り替えを判断 • オブサーバ・サーバーにはDBライセンス不要 • オブサーバの冗長化も可能(12.2以降) • Oracle Enterprise Manager Cloud Control でオブ ザーバーの監視が可能 「自動切り替えしたい」 Database System Database System Virtual Machine Observer Primary Database Standby Database Copyright © 2022, Oracle and/or its affiliates 53

障害時に自動的にData Guard の切り替えを実行し、可用性を高め業務を継続 • Data Guard Broker 構成が有効になっている環境で、 障害時に監視プロセス(オブザーバー)による自動切り替え 機能 • Data Guard Broker 構成 + オブザーバー • DG Broker≠ファスト・スタート・フェイルオーバー • アプリケーションからのコールによる実行も可能 • フェイルオーバー時の高速アプリケーション通知(FAN) により、クライアントに連携可能 • 旧プライマリの復旧も自動で行う • フェイルオーバー後に旧プライマリを自動で復旧(フラッ シュ・バック)し、スタンバイとしてData Guard 構成に組 み込む • フラッシュバック・データベースの有効必須 Data Guard ファスト・スタート・フェイルオーバー Data Guard Broker 構成 オブザーバー 障害検知→ 自動切り替え スタンバイ→ 新プライマリ Copyright © 2022, Oracle and/or its affiliates 54

オブザーバの可用性向上 • オブザーバーを複数持つことにより、ファスト・スタート・フェイルオー バーを常に有効に • 従来から、Enterprise Manager Cloud Control を使用 することにより、HA構成での別サーバー上へ切り替えることは 可能 • 最大３つまで起動可能 • １つがマスター、残りがバックアップ • マスター停止/通信不可時に、バックアップが昇格 • 各オブザーバーごとにログ出力 • 同一サーバー上で複数起動は不可 ファスト・スタート・フェイルオーバーでのオブサーバの冗長構成(12.2以降) Data Guard Broker 構成 オブザーバー バックアップ オブザーバ バックアップ オブザーバ Copyright © 2022, Oracle and/or its affiliates 55

No content