Oracle Exadata Database Service: 複数スタンバイ Data Guard 構成してみてみた

Last updated at 2025-02-26Posted at 2025-02-25

Oracle Exadata Database Service では、複数のスタンバイ・データベースを作成できます。この機能拡張により、プライマリ・データベースにリンクされた複数のローカル・スタンバイ・データベースおよびリモート・スタンバイ・データベースを作成および管理できるため、データ保護とディザスタ・リカバリの両方に柔軟に対応できます。ローカル・スタンバイ・データベースはデータ損失の最小化に役立ちますが、リモート・スタンバイ・データベースはリージョンの障害から保護します。

Oracle Data Guard は、1 つ以上のスタンバイデータベースを作成、維持、管理、監視し、運用中の Oracle データベースが災害やデータ破損に耐えられるようにする包括的なサービスセットを提供します。
Oracle Data Guard は、これらのスタンバイデータベースを本番データベースのコピーとして維持します。その後、計画停止または計画外停止により本番データベースが使用できなくなった場合、Oracle Data Guard は任意のスタンバイデータベースを本番ロールに切り替えて、停止に関連するダウンタイムを最小限に抑えることができます。Oracle Data Guard は、従来のバックアップ、リストア、およびクラスタ技術と組み合わせて使用することで、高度なデータ保護とデータ可用性を実現できます。Oracle Data Guard トランスポートサービスは、Oracle Streams や Oracle GoldenGate などの他の Oracle 機能でも使用され、ソースデータベースから 1 つ以上のリモート宛先への REDO の効率的で信頼性の高い転送を実現します。

Active Data Guard では次の主な機能があります。

リアルタイム問い合わせとDMLオフロード: リアルタイム問い合わせとデータ操作言語では、問い合わせ、レポート、随時更新のためにスタンバイ・データベースを使用するため、プライマリ・データベースに影響を与えません。
インメモリー・データベース・レプリケーション: インメモリーREDOレプリケーションでは、ディスク破損などの根本的な破損から確実に分離でき、レプリケートされたデータブロックの包括的な自動検証機能を利用できます。
自動ブロック修復: スタンバイ・データベースの破損したデータベースをユーザーに意識させることなく自動的にリカバリします。
アプリケーション・コンティニュイティ: リカバリ可能な停止の後に処理中のデータベース・トランザクションをリカバリすることで、エンドユーザーやアプリケーションへの停止の影響を排除します。
グローバル・データ・サービス（GDS）: 接続リクエストに対するロード・バランシングを提供して複数のレプリケートされたデータベースにサービス管理を分散し、Active Data Guardの読取りワークロードまたは読取り／書込みワークロードに応じて接続を有効にします。
Oracle Globally Distributed Database: データセットのセグメントを複数のデータベース（シャード・データベース）に分散し、オンプレミスまたはクラウド上のさまざまなコンピュータに配置します。また、グローバルに分散した直線的にスケーラブルなマルチモデル・データベースを実現します。

ということで、Exadata Database Service を複数使用して複数スタンバイData Guard構成して、Switchover, Failover, Reinstate してみてみます。

■ 構成図

今回 4つの Databseで Data Guard Groupを構成し、各 Database へ Zero Data Loss Autonomous Recovery Service (ZRCV) の自動バックアップを設定します。

Network関連は事前に作成しておき、今回はExadata Infrastructureから作成します。
　・ Remote VCN Peering 設定
　・ DNSピアリング(Forwarding) 設定

■ 前提条件

Data Guard を有効にする場合、新しいスタンバイデータベースをホストするために、スタンバイインスタンスに新しいデータベースホームを作成する必要があります。または、スタンバイインスタンスの既存のデータベースホーム内にスタンバイデータベースをプロビジョニングすることもできます。スタンバイシステムに必要なリソースの作成については、次のトピックを参照
　・ Exadata Cloud InfrastructureでOracle Data Guardを使用するための前提条件
　・Data Guard のネットワーク要件
　・パスワード要件
　・Exadata Cloud Infrastructure および Data Guard の既知の問題

Oracle Data Guard の詳細について、Oracle Database ドキュメントポータルを参照
・ Oracle Data Guard の概念と管理
・ Oracle Data Guard Broker の概念

■ Exadata Database Service 作成

前回作成した Exadata Database Serviceを4つ使用します。

■ Exadata Database Service作成確認

今回、図面のように 4つの Exadata Database VM Clusterを作成しておきます。

● VM Cluster確認

1) VMCluster_Tokyo

2) VMCluster_Aoyama

3) VMCluster_Osaka

4) VMCluster_Umeda

● Database: CDB_Tokyo 確認

Databaseは、作成したVMCluster_Tokyo から、他の VM Cluster へ Data Guardアソシエーションで Standby Databaseを作成していきます。

・CDB_Tokyo確認

■ スタンバイ CDB_Osaka 追加

● Database Home追加

1) VM Cluster: Database Home画面

2) データベース・ホームの作成画面

3) 作成中

4) 作成完了

● CDB_Tokyo から CDB_Osaka を Data Guard有効化

1) Primary DB CDB_Tokyo DB画面
プライマリロールを引き受けるデータベース CDB_Tokyo DB システムに移動し、「データベースの詳細」ページの「リソース」で、「Data Guard アソシエーション」を選択し、[Add Standby] をクリック

2) Add Standby 画面
「スタンバイの追加」ページで、Data Guard グループを構成します。
ここでは、新しいData Guard機能を備えた[新規Data Guard グループ・リソースの使用]を選択して作成します。

・ Data Guard experience選択
　　- 新規Data Guard グループ・リソースの使用: このオプションを使用すると、新しい Data Guard 構成が Data Guard グループ リソースとして作成されます。新しい API を備えたこのオプションは、複数のスタンバイ データベースの追加をサポートし、その他の拡張機能を提供します。
　　- 既存のData Guardアソシエーション・リソースの使用: 複数のスタンバイ データベースを追加することはできず、新しい API によって提供される拡張機能も利用できません。
・ ピア・リージョン: スタンバイ データベースを配置するリージョンを選択
・ Exadataインフラストラクチャの選択: 事前に作成したStandby用 Exadata Infrastructureを選択
・ クラスタの選択: 事前に作成したStandby用 Exadata VM Clusterを選択
・ Data Guard グループの詳細: Active Data Guard または Data Guard を選択
　　- Active Data Guard: リアルタイム クエリと DML オフロード、自動ブロック修復、スタンバイ ブロック変更追跡、Far Sync、グローバル データ サービス、アプリケーション継続性などの追加機能があります。Active Data Guard には Oracle Active Data Guard ライセンスが必要であることに注意してください。
・ 保護モード: 最大パフォーマンスまたは最大可用性のいずれかになります。これらのオプションの詳細については、 「Oracle Data Guard 保護モード」(https://docs.oracle.com/en/database/oracle/oracle-database/21/sbydb/introduction-to-oracle-data-guard-concepts.html#GUID-65DA4E2E-3666-4972-895C-EA45D043B127)を参照してください。
・ トランスポート タイプ:この Data Guard グループに使用される REDO トランスポート タイプ。これらのオプションの詳細については、 「REDO トランスポート サービス」(https://docs.oracle.com/en/database/oracle/oracle-database/21/sbydb/oracle-data-guard-redo-transport-services.html#GUID-0EC71C7D-A80B-40AA-93E5-28BB7E24ED31)を参照してください。
・ データベース ホームの選択: 既存のデータベース ホームを選択し、事前に作成したDatabase Homeを選択
・ 一意のデータベース名: DB_UNIQUE_NAME。この値は、プライマリ クラウド VM クラスターとスタンバイ クラウド VM クラスター全体で一意である必要があります。指定しない場合は、システムによって次のように一意の名前の値が自動的に生成されます。
・ データベース・パスワード: プライマリ データベースのデータベース管理者パスワードを入力します。スタンバイ データベースにも同じデータベース管理者パスワードを使用します。
・ TDEウォレット・パスワード: TDE ウォレット パスワードを入力
・ Oracle SID プレフィックス: INSTANCE_NAMEデータベース パラメータが作成されます。このINSTANCE_NAMEパラメータは SID とも呼ばれます。指定しない場合、SID プレフィックスはデフォルトで db_unique_name の最初の 12 文字になります。

3) Add Standby 中〜

4) Add Standby 完了

● 設定確認

DGMGRLで確認してみてみます。
Data Guardコマンドライン・インタフェース(DGMGRL)を使用すると、Data Guard Broker構成とその様々なメンバーを、コマンドラインから直接、あるいはバッチ・プログラムやスクリプトから管理できます。

1) DGMGRL接続

[oracle@exa-osaka01-server-vbn501 ~]$ dgmgrl system/<Password>
DGMGRL for Linux: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Wed Feb 5 15:05:59 2025
Version 23.6.0.24.10

Copyright (c) 1982, 2024, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "CDB_Osaka01"
Connected as SYSDG.

2) DGMGRL: ブローカ構成情報確認
ブローカ構成のサマリーおよびステータスを表示します。サマリーには、ブローカ構成に含まれるすべてのデータベースと、ファスト・スタート・フェイルオーバーのステータスなど、ブローカ構成自体に関するその他の情報が表示されます。

DGMGRL> show configuration verbose

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Tokyo01                - Primary database
    CDB_Osaka01                - Physical standby database
    dbrs_primary_cdb_tokyo01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)

  Properties:
    BystandersFollowRoleChange      = 'ALL'
    CommunicationTimeout            = '180'
    ConfigurationSimpleName         = 'cdb_dgconf'
    ConfigurationWideServiceName    = 'CDB_CFG'
    DrainTimeout                    = '0'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverLagGraceTime   = '0'
    FastStartFailoverLagLimit       = '30'
    FastStartFailoverLagType        = 'APPLY'
    FastStartFailoverPmyShutdown    = 'TRUE'
    FastStartFailoverThreshold      = '30'
    ObserverOverride                = 'FALSE'
    ObserverPingInterval            = '0'
    ObserverPingRetry               = '0'
    ObserverReconnect               = '0'
    OperationTimeout                = '30'
    PrimaryDatabaseCandidates       = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    TraceLevel                      = 'USER'

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS

3) DGMGRL: CDB_Tokyoデータベース情報確認
指定したデータベースとそのインスタンスに関する情報またはプロパティ値を表示します。

DGMGRL> show database verbose CDB_Tokyo01

Database - CDB_Tokyo01

  Role:                PRIMARY
  Intended State:      TRANSPORT-ON
  Redo Rate:           (unknown)

  Instance(s):
    CDB_Tokyo011
    CDB_Tokyo012

  Properties:
    AlternateLocation               = ''
    ApplyInstanceTimeout            = '0'
    ApplyInstances                  = '0'
    ApplyLagThreshold               = '30'
    ApplyParallel                   = 'AUTO'
    ArchiveLocation                 = ''
    Binding                         = 'OPTIONAL'
    DGConnectIdentifier             = 'CDB_Tokyo01'
    DelayMins                       = '0'
    FastStartFailoverTarget         = 'CDB_Osaka01'
    InconsistentLogXptProps         = '(monitor)'
    LogShipping                     = 'ON'
    LogXptMode                      = 'ASYNC'
    LogXptStatus                    = '(monitor)'
    MaxFailure                      = '0'
    NetTimeout                      = '30'
    ObserverConnectIdentifier       = ''
    PreferredApplyInstance          = ''
    PreferredObserverHosts          = ''
    RecvQEntries                    = '(monitor)'
    RedoCompression                 = 'DISABLE'
    RedoRoutes                      = '(CDB_Tokyo01:CDB_Osaka01,(DBRS_PRIMARY_CDB_Tokyo01 ASYNC PRIORITY=1,DBRS_ALTERNATE_CDB_Tokyo01 ASYNC PRIORITY=2))(CDB_Osaka01:(DBRS_PRIMARY_CDB_Tokyo01 ASYNC PRIORITY=1,DBRS_ALTERNATE_CDB_Tokyo01 ASYNC PRIORITY=2))'
    ReopenSecs                      = '300'
    SendQEntries                    = '(monitor)'
    SidName(*)
    StandbyAlternateLocation        = ''
    StandbyArchiveLocation          = ''
    StaticConnectIdentifier(*)
    TopWaitEvents(*)
    TransportDisconnectedThreshold  = '30'
    TransportLagThreshold           = '30'
    UserManagedParams               = ''
    (*) - Please check specific instance for the property value

  Log file locations(*):
    (*) - Check specific instance for log file locations.

Database Status:
SUCCESS

3) DGMGRL: CDB_Tokyoデータベース Switchover可能チェック確認
VALIDATE DATABASEコマンドを使用して、データベースがロール変更に即時対応可能かどうかを確認する、一連の徹底チェックを実行することができます。

DGMGRL>  validate database verbose CDB_Tokyo01

  Database Role:    Primary database

  Ready for Switchover:  Yes

  Flashback Database Status:
    Database     Status           Retention Target
    CDB_Tokyo01  On               1440
    CDB_Osaka01  On               1440

  Force Logging Status:
    Database     Status           Nonlogged Blocks
    CDB_Tokyo01  On               0

  Capacity Information:
    Database     Instances        Threads
    CDB_Tokyo01  2                2

  Managed by Clusterware:
    CDB_Tokyo01:  YES

  Temporary Tablespace File Information:
    CDB_Tokyo01 Temp Files:  3

  Data file Online Move in Progress:
    CDB_Tokyo01:  No

  Transport-Related Information:
    Transport On:  Yes

  Log Files Cleared:
    CDB_Tokyo01 Standby Redo Log Files:  Cleared

4) DGMGRL: CDB_Osakaデータベース情報確認

DGMGRL> show database verbose CDB_Osaka01

Database - CDB_Osaka01

  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:  23.00 KByte/s
  Active Apply Rate:   1.15 MByte/s
  Maximum Apply Rate:  1.19 MByte/s
  Real Time Query:     ON
  Instance(s):
    CDB_Osaka011 (apply instance)
    CDB_Osaka012

  Properties:
    AlternateLocation               = ''
    ApplyInstanceTimeout            = '0'
    ApplyInstances                  = '0'
    ApplyLagThreshold               = '30'
    ApplyParallel                   = 'AUTO'
    ArchiveLocation                 = ''
    Binding                         = 'OPTIONAL'
    DGConnectIdentifier             = 'CDB_Osaka01'
    DelayMins                       = '0'
    FastStartFailoverTarget         = 'CDB_Tokyo01'
    InconsistentLogXptProps         = '(monitor)'
    LogShipping                     = 'ON'
    LogXptMode                      = 'ASYNC'
    LogXptStatus                    = '(monitor)'
    MaxFailure                      = '0'
    NetTimeout                      = '30'
    ObserverConnectIdentifier       = ''
    PreferredApplyInstance          = ''
    PreferredObserverHosts          = ''
    RecvQEntries                    = '(monitor)'
    RedoCompression                 = 'DISABLE'
    RedoRoutes                      = '(CDB_Osaka01:CDB_Tokyo01)'
    ReopenSecs                      = '300'
    SendQEntries                    = '(monitor)'
    SidName(*)
    StandbyAlternateLocation        = ''
    StandbyArchiveLocation          = ''
    StaticConnectIdentifier(*)
    TopWaitEvents(*)
    TransportDisconnectedThreshold  = '30'
    TransportLagThreshold           = '30'
    UserManagedParams               = ''
    (*) - Please check specific instance for the property value

  Log file locations(*):
    (*) - Check specific instance for log file locations.

Database Status:
SUCCESS

5) DGMGRL: CDB_Osakaデータベース Switchover可能チェック確認

DGMGRL> validate database verbose CDB_Osaka01

  Database Role:     Physical standby database
  Primary Database:  CDB_Tokyo01

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    Database     Status           Retention Target
    CDB_Tokyo01  On               1440
    CDB_Osaka01  On               1440

  Force Logging Status:
    Database     Status           Nonlogged Blocks
    CDB_Tokyo01  On               0
    CDB_Osaka01  On               0

  Capacity Information:
    Database     Instances        Threads
    CDB_Tokyo01  2                2
    CDB_Osaka01  2                2

  Managed by Clusterware:
    CDB_Tokyo01:  YES
    CDB_Osaka01:  YES

  Temporary Tablespace File Information:
    CDB_Tokyo01 Temp Files:  3
    CDB_Osaka01 Temp Files:  3

  Data file Online Move in Progress:
    CDB_Tokyo01:  No
    CDB_Osaka01:  No

  Standby Apply-Related Information:
    Apply State:      Running
    Apply Lag:        0 seconds (computed 1 second ago)
    Apply Delay:      0 minutes

  Transport-Related Information:
    Transport On:  Yes
    Gap Status:    No Gap
    Transport Lag:  0 seconds (computed 1 second ago)
    Transport Status:  Success

  Log Files Cleared:
    CDB_Tokyo01 Standby Redo Log Files:  Cleared
    CDB_Osaka01 Online Redo Log Files:   Cleared
    CDB_Osaka01 Standby Redo Log Files:  Available

  Current Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups
              (CDB_Tokyo01)           (CDB_Osaka01)
    1         4                       4
    2         4                       4

  Future Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups
              (CDB_Osaka01)           (CDB_Tokyo01)
    1         4                       4
    2         4                       4

  Current Configuration Log File Sizes:
    Thread #   Smallest Online Redo      Smallest Standby Redo
               Log File Size             Log File Size
               (CDB_Tokyo01)             (CDB_Osaka01)
    1          4000 MBytes               4000 MBytes
    2          4000 MBytes               4000 MBytes

  Future Configuration Log File Sizes:
    Thread #   Smallest Online Redo      Smallest Standby Redo
               Log File Size             Log File Size
               (CDB_Osaka01)             (CDB_Tokyo01)
    1          4000 MBytes               4000 MBytes
    2          4000 MBytes               4000 MBytes

  Apply-Related Property Settings:
    Property                        CDB_Tokyo01 Value        CDB_Osaka01 Value
    DelayMins                       0                        0
    ApplyParallel                   AUTO                     AUTO
    ApplyInstances                  0                        0

  Transport-Related Property Settings:
    Property                        CDB_Tokyo01 Value        CDB_Osaka01 Value
    LogShipping                     ON                       ON
    LogXptMode                      ASYNC                    ASYNC
    Dependency                      <empty>                  <empty>
    Binding                         OPTIONAL                 OPTIONAL
    MaxFailure                      0                        0
    ReopenSecs                      300                      300
    NetTimeout                      30                       30
    RedoCompression                 DISABLE                  DISABLE

  Parameter Settings:
    Parameter                       CDB_Tokyo01 Value        CDB_Osaka01 Value
    DB_BLOCK_CHECKING               MEDIUM                   MEDIUM
    DB_BLOCK_CHECKSUM               TYPICAL                  TYPICAL
    DB_LOST_WRITE_PROTECT           TYPICAL                  TYPICAL

DGMGRL>

■ スタンバイ CDB_Aoyama, CDB_Umeda 追加

CDB_Osaka同様の手順で Primary Database CDB_Tokyoへ追加します。

● スタンバイ CDB_Aoyama, CDB_Umeda追加確認

各Databasae画面の Data Guard Group画面のリストに追加されれば追加完了です。

● DGMGRL: CDB_Aoyama, CDB_Umeda追加確認

DGMGRL> show configuration verbose

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Tokyo01 - Primary database
    CDB_Osaka01 - Physical standby database
    CDB_Umeda   - Physical standby database
    CDB_Aoyama  - Physical standby database

  Properties:
    BystandersFollowRoleChange      = 'ALL'
    CommunicationTimeout            = '180'
    ConfigurationSimpleName         = 'cdb_dgconf'
    ConfigurationWideServiceName    = 'CDB_CFG'
    DrainTimeout                    = '0'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverLagGraceTime   = '0'
    FastStartFailoverLagLimit       = '30'
    FastStartFailoverLagType        = 'APPLY'
    FastStartFailoverPmyShutdown    = 'TRUE'
    FastStartFailoverThreshold      = '30'
    ObserverOverride                = 'FALSE'
    ObserverPingInterval            = '0'
    ObserverPingRetry               = '0'
    ObserverReconnect               = '0'
    OperationTimeout                = '30'
    PrimaryDatabaseCandidates       = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    TraceLevel                      = 'USER'

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS

■ スタンバイ DatabaseへBackup を設定

自動 Exadata データベースバックアップは、Oracle Cloud Infrastructure によって管理されます。
Oracle 管理の自動バックアップ機能は、コンソールを使用して簡単にバックアップ設定を構成できるため、Oracle Cloud データベースをバックアップするための推奨される方法です。手動バックアップやバックアップストレージ管理タスクを実行する必要はありません。
Exadata データベースの自動バックアップの保存先として、Autonomous Recovery Service と Oracle Object Storage の 2 つが考えられます。
リカバリサービス（推奨）はOracle データベースに最新のサイバーセキュリティ保護を提供するオンプレミスの Oracle Zero Data Loss Recovery Applianceテクノロジーに基づく、完全に管理されたサービスです。独自の自動化機能により、Oracle データベースの変更がリアルタイムで保護され、実稼働データベースのオーバーヘッドなしでバックアップが検証され、任意の時点への高速で予測可能なリカバリが可能になります。
現在、バックアップが Object Storage で構成されている場合は、シームレスに Recovery Service に移行して、同じコストで高度な機能を実現できます。
Recovery Service の詳細については、「Oracle Database Autonomous Recovery Service について」を参照してください。
各Databaseへ自動バックアップの Zero Data Loss Autonomous Recovery Service (ZRCV)を設定します。

● ZRCV事前設定

次を参考に事前準備しておきます。

● 自動バックアップ設定

1) Database画面
Database画面のリソースにある Backupを選択し、[自動バックアップ]をクリック

2) 自動バックアップの構成画面
次の項目を入力し、[変更の保存]をクリック

・ 自動バックアップの有効化: チェックして有効化
・ バックアップの保存先: 自立型リカバリ・サービス(推奨)を選択
・ 保護ポリシー: 今回、事前に定義したカスタムポリシーを設定
・ リアルタイム・データ保護: チェックして有効化
・ データベース終了後の削除オプション
　　- 保護ポリシー保持期間に従ってバックアップを保持します: 
　　- バックアップを72時間保持し、その後削除します: 
・ 日次バックアップのスケジュール時間（UTC）:

2) 自動バックアップの構成中〜

3) 自動バックアップの構成完了〜

● DGMGRL: ZRCV追加確認

ZRCV追加すると Recovery appliance情報が追加されます。

DGMGRL> show configuration verbose

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Tokyo01                - Primary database
    CDB_Osaka01                - Physical standby database
      dbrs_primary_cdb_osaka01   - Recovery appliance (receiving current redo)
    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    CDB_Aoyama                 - Physical standby database
      dbrs_primary_cdb_aoyama    - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_tokyo01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

  Properties:
    BystandersFollowRoleChange      = 'ALL'
    CommunicationTimeout            = '180'
    ConfigurationSimpleName         = 'cdb_dgconf'
    ConfigurationWideServiceName    = 'CDB_CFG'
    DrainTimeout                    = '0'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverLagGraceTime   = '0'
    FastStartFailoverLagLimit       = '30'
    FastStartFailoverLagType        = 'APPLY'
    FastStartFailoverPmyShutdown    = 'TRUE'
    FastStartFailoverThreshold      = '30'
    ObserverOverride                = 'FALSE'
    ObserverPingInterval            = '0'
    ObserverPingRetry               = '0'
    ObserverReconnect               = '0'
    OperationTimeout                = '30'
    PrimaryDatabaseCandidates       = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    TraceLevel                      = 'USER'

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS

■ Switchover実行

スイッチオーバーにより、プライマリデータベースとスタンバイデータベースの役割が逆転します。
各データベースは、新しいロールでも引き続き Data Guard グループの一部です。スイッチオーバーにより、データ損失がなくなります。プライマリデータベースで計画メンテナンスを実行する前に、スイッチオーバーを使用できます。Data Guard グループを持つ Exadata データベース仮想マシンで計画メンテナンスを実行するには、通常、プライマリをスタンバイロールに切り替え、スタンバイでメンテナンスを実行してから、プライマリロールに切り替えます。

● Switchover前 DGMGRL確認

dgmgrl で Switchover前の状態を確認
1) dgmgrl接続

[oracle@exa-tokyo01-server-vbn501 ~]$ dgmgrl system/<Password>
DGMGRL for Linux: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Wed Feb 5 15:05:59 2025
Version 23.6.0.24.10

Copyright (c) 1982, 2024, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "CDB_Tokyo01"
Connected as SYSDG.

1) dgmgrl configuration確認
CDB_Tokyo が Primary Databaseであることを確認できます。

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Tokyo01                - Primary database
    CDB_Osaka01                - Physical standby database
      dbrs_primary_cdb_osaka01   - Recovery appliance (receiving current redo)
    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    CDB_Aoyama                 - Physical standby database
      dbrs_primary_cdb_aoyama    - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_tokyo01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 54 seconds ago)

● Switchover実行

1) Databseシステム Data Guard Group画面
Data Guard グループのメンバーであるスタンバイデータベースでスイッチオーバー操作を実行できます。
DB システムのData Guard Group画面で Data Guard グループ内のスタンバイデータベースを選択し、[アクション] アイコン (3 つのドット) をクリックし、[スイッチオーバー]をクリック

2) Switchover database ダイアログボックス画面
データベース管理者のパスワードを入力し、[Switchover]をクリック

3) Switchover 中〜

4) Switchover 完了

● Switchover後 DGMGRL確認

CDB_Tokyoから CDB_Osakaへ切り替わったことを確認できます。

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Osaka01                - Primary database
    CDB_Tokyo01                - Physical standby database
      dbrs_primary_cdb_tokyo01   - Recovery appliance (receiving current redo)
    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    CDB_Aoyama                 - Physical standby database
      dbrs_primary_cdb_aoyama    - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_osaka01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 46 seconds ago)

■ Faileover

フェイルオーバーは、既存のプライマリデータベースに障害が発生したり、アクセスできなくなったりした後に、スタンバイデータベースをプライマリロールに移行します。
フェイルオーバーによってデータが失われるかどうかは、保護モードと、プライマリデータベースの障害発生時にプライマリデータベースとターゲットスタンバイデータベースが同期されていたかどうかによって異なります。詳細については、Data Guard ドキュメントの「手動フェイルオーバー」を参照してください。

● Faileover 前 DGMGRL確認

dgmgrl で Switchover前の状態を確認

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Tokyo01                - Primary database
    CDB_Osaka01                - Physical standby database
      dbrs_primary_cdb_osaka01   - Recovery appliance (receiving current redo)
    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    CDB_Aoyama                 - Physical standby database
      dbrs_primary_cdb_aoyama    - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_tokyo01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 54 seconds ago)

● CDB_Tokyo から CDB_Osaka へ Failover 実行

2) Failover database ダイアログボックス画面
データベース管理者のパスワードを入力し、[Failover]をクリック

3) Failover 中〜

4) Failover 完了
CDB_Tokyoから CDB_Osakaへ切り替わったことを確認できます。
CDB_Osakaデータベースはプライマリの役割を引き継ぎ、古いプライマリの CDB_Tokyo役割は「無効なスタンバイ」として表示されます。

● Failover 後 DGMGRL確認

CDB_Tokyoから CDB_Osakaへ切り替わったことを確認できます。
古いプライマリの CDB_Tokyoは、ORA-16661: The standby database must be reinstated.状態になります。

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Osaka01                - Primary database
    CDB_Tokyo01                - Physical standby database (disabled)
      ORA-16661: The standby database must be reinstated.

    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    CDB_Aoyama                 - Physical standby database
      dbrs_primary_cdb_aoyama    - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_osaka01   - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_tokyo01   - Recovery appliance
    Warning: ORA-16685: database does not receive redo data

  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 5 second ago)

● CDB_Osaka から、CDB_Umeda　から、CDB_Aoyama へ Failover 実行

残りのずべて 1つのDatabaseを残して Failoverしてみてみます。
1) 1つを残して全て Failover 後画面
CDB_Aoyama以外のDatabaseの状態が、Disabled Standbyになっていることを確認できます。

2) 1つを残して全て Failover 後 DGMGRL確認
CDB_AoyamaがPrimary database それ以外のステータスは以外のDatabaseの状態は、ORA-16661: The standby database must be reinstated. になっていることを確認できます。

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Aoyama                 - Primary database
    CDB_Tokyo01                - Physical standby database (disabled)
      ORA-16661: The standby database must be reinstated.

    CDB_Osaka01                - Physical standby database (disabled)
      ORA-16661: The standby database must be reinstated.

    CDB_Umeda                  - Physical standby database (disabled)
      ORA-16661: The standby database must be reinstated.

    dbrs_primary_cdb_aoyama    - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_tokyo01   - Recovery appliance
    Warning: ORA-16685: database does not receive redo data

  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_umeda     - Recovery appliance
    Warning: ORA-16685: database does not receive redo data

  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_osaka01   - Recovery appliance
    Warning: ORA-16685: database does not receive redo data


Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 60 seconds ago)

■ Reinstate (復旧)

データベースを Data Guard グループのスタンバイロールに復元します。
障害の原因を修正した後、障害が発生したデータベースをサービス状態に戻すには、reinstate コマンドを使用します。

注記：1 つ以上のスタンバイデータベースを含む Data Guard グループの一部であるプライマリデータベースは終了できません。まずスタンバイデータベースを終了する必要があります。または、プライマリデータベースをスタンバイロールに切り替えてから、以前のプライマリを終了することもできます。
Data Guard 対応データベースを含む VM クラスタを終了することはできません。まず、Data Guard グループの一部であるスタンバイデータベースを終了する必要があります。

● CDB_Tokyo Reinstate 実行

1) Databseシステム Data Guard Group画面

2) Reinstate database ダイアログボックス画面

3) CDB_Tokyo Reinstate 中〜

4) CDB_Tokyo Reinstate 完了
CDB_Tokyo が Standby 状態へ復旧したことを確認

● Reinstate 後 DGMGRL確認

Reinstate した DB_Tokyo の ORA-16661: The standby database must be reinstated.の状態が回復し、DB_Tokyoの状態が Physical standby databaseへ正常になっていることを確認できます。

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Aoyama                 - Primary database
    CDB_Tokyo01                - Physical standby database
      dbrs_primary_cdb_tokyo01   - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_aoyama    - Recovery appliance

    CDB_Osaka01                - Physical standby database (disabled)
      ORA-16661: The standby database must be reinstated.

    CDB_Umeda                  - Physical standby database
      ORA-16661: The standby database must be reinstated.

  Members Not Receiving Redo:
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_umed   - Recovery appliance
    Warning: ORA-16685: database does not receive redo data

  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)
    Warning: ORA-16685: database does not receive redo data

  dbrs_primary_cdb_osaka01   - Recovery appliance
    Warning: ORA-16685: database does not receive redo data


Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 44 seconds ago)

● 全て復旧完了確認

残りのDatabaseをすべて Reinstateし、全て復旧完了したことを確認

DGMGRL> show configuration

Configuration - cdb_dgconf

  Protection Mode: MaxPerformance
  Members:
  CDB_Aoyama                 - Primary database
    CDB_Tokyo01                - Physical standby database
      dbrs_primary_cdb_tokyo01   - Recovery appliance (receiving current redo)
    CDB_Osaka01                - Physical standby database
      dbrs_primary_cdb_osaka01   - Recovery appliance (receiving current redo)
    CDB_Umeda                  - Physical standby database
      dbrs_primary_cdb_umeda     - Recovery appliance (receiving current redo)
    dbrs_primary_cdb_aoyama    - Recovery appliance

  Members Not Receiving Redo:
  dbrs_alternate_cdb_tokyo01 - Recovery appliance (alternate of dbrs_primary_cdb_tokyo01)
  dbrs_alternate_cdb_aoyama  - Recovery appliance (alternate of dbrs_primary_cdb_aoyama)
  dbrs_alternate_cdb_umeda   - Recovery appliance (alternate of dbrs_primary_cdb_umeda)
  dbrs_alternate_cdb_osaka01 - Recovery appliance (alternate of dbrs_primary_cdb_osaka01)

■ 参考

● 製品機能概要
　・ Exadata Database Service
　・ Active Data Guard
　・アプリケーション・コンティニュイティの詳細

● Engineered Systems Documentation
　・ Exadata Database Service on Dedicated Infrastructure
　・ Oracle Data GuardをExadata Cloud Infrastructureで使用する
　・ Oracle Exadata Database Serviceでのデータベースのバックアップとリカバリの管理
　・ Data Guard の操作

● Oracle Cloud Infrastructure Documentation
　・ Oracle Exadata Database Service on Dedicated Infrastructure
　・ Oracle Exadata Database Service on Dedicated Infrastructureの新機能

● Oracle Database Documentation
　・ Oracle Database ドキュメントポータル
　・ Oracle Data Guard の概念と管理
　・ Oracle Data Guard Broker の概念
　・ Data Guard Concepts and Administration
　・ Oracle Data Guard Broker
　・ Oracle Data Guardの保護モードの詳細
　・自動ブロック・メディア・リカバリによるデータ保護の詳細
　・ DBMS_ROLLINGの活用方法の詳細
　・ Data GuardおよびActive Data Guard MAAのベストプラクティス
　・ DMLをスタンバイ・データベースからプライマリ・データベースへ透過的にリダイレクトする方法

● Other Documentation
　・ High Availability Overview and Best Practices
　・ Active Data Guardとストレージのリモートミラー化の比較
　・グローバル・データ・サービス（GDS）の詳細
　・ Oracle Globally Distributed Databaseの詳細

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up