8/23のアップデートでAmazon RDS for Oracleにおいて、リードレプリカインスタンスに対して Oracle Data Guard の機能であるスイッチオーバのマネージドな実行および自動バックアップがサポートされるようになりました。
（レプリカインスタンスの自動バックアップについては「選択できるようになった」だけなので説明は割愛しますが、レプリカインスタンスの自動バックアップをONにしておかないとスイッチオーバはできないのでご注意ください）
今までのRDS for Oracleのリードレプリカインスタンスは、昇格（Promote）することはマネージドで実行可能でしたが、スイッチオーバは実行できませんでした。本アップデートで実行できるようになりましたので、使い勝手等ご紹介します。
なお、RDS for Oracleの概要や前提については Amazon RDS での Oracle レプリカの使用ついて を参照ください。
従来のスイッチオーバ
厳密にはスイッチオーバではないですが、レプリカインスタンスを選択し、アクションで「昇格」を押下することで、レプリカインスタンスがスタンドアロンインスタンスに昇格します。
レプリカインスタンスがスタンドアロンインスタンスに昇格したら、クライアント側からスタンドアロンインスタンスに接続することで、スイッチオーバと同等の動作を実行することが可能です。
（レプリカインスタンスをプライマリに昇格させたタイミングで、Oracle Data Guardのデータ同期は破棄されます。再度データ同期させるには、スタンドアロンインスタンスから改めてリードレプリカを作成する必要があります）
マネージドなスイッチオーバ
Enterprise EditionのRDS for Oracleを起動し、リードレプリカを作成します。
リードレプリカが作成されると、コンソール上は以下のようにソースとレプリカのインスタンスが確認できます。
レプリカインスタンスの詳細を確認すると、以下のように表示されます。（レプリカインスタンスのレプリカモードは今回はマウントで作ってます）
ちなみにコンソール上からは確認できませんが、レプリカのプロテクションモードは「MAXIMUM PERFORMANCE」となっており、変更できません。（プロテクションモードについてはOracleのマニュアルを参照ください）
SQL> select protection_mode from v$database;
PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE
さて、コンソールからレプリカ側のインスタンスを選択し、アクションを押下すると、以下のようにメニューが表示されます。
ここで、「昇格」の下に「Switch over replica」というメニューが追加されています。
「Switch over replica」を押下すると、次のような確認メッセージが表示されます。
チェックボックスをチェックし「Switch over replica」を押下するとスイッチオーバが開始されます。
※レプリカ要件やレプリカの準備が完了していないとここでエラーが出ます
数分待つと、コンソール上でもスイッチオーバしたインスタンスが「ソース」となり、元のインスタンスが「レプリカ」となります。
スイッチオーバが完了するとコンソール上にも以下のように表示されます。
これでスイッチオーバの操作は完了です。
レプリカとなったインスタンスをソースに戻したい場合には、同じ動作を再度行うだけで、非常に簡単にスイッチオーバ動作を行うことができます。
まとめ
従来の構成ではData Guardの構成（データ同期）を保ったままのスイッチオーバはできませんでした。
そのため、プライマリ側でテストやメンテを実施するためには、レプリカを新しいスタンドアロン データベースとして昇格させてから、新しいレプリカを作成してレプリケーション構成を維持する必要がありました。
本アップデートによりレプリカを再作成することなくデータベースの役割を単純に逆にすることが可能となり、メンテナンス時等のオペレーションの手間や時間を削減することが可能となりました。
従来の機能（レプリカ側のスタンドアロンインスタンスへの昇格）も引き続き使えますので、従来の機能が必要な場合には従来の機能を、スイッチオーバの機能が必要な場合には新しい機能を利用することで、システム運用の幅が広がることになると思います。
（おまけ）スイッチオーバの時間
クライアントから ソース レプリカ それぞれのインスタンスに接続し、自身のユニークネーム（DB_UNIQUE_NAME）とSYSDATEをテストテーブルに書き込む処理を１秒おきに繰り返して、スイッチオーバが始まりソース側に書き込みができなくなった時間とスイッチオーバが終わり（元の）レプリカに書き込みができた時間を評価しました。
結論から言うと、レプリカがリードオンリーモードの方がだいぶ速く利用可能となることが確認できました。
Active Data Guardモードの場合（レプリカがリードオンリー）
レプリカがリードオンリーモードの時にスイッチオーバすると、大体30秒弱程度で（元の）レプリカに書き込みが可能となりました。
ID DBN TIME
---------- ------------ -------------------------------------------------------
（略）
201 ORACLE02_A 25-AUG-22 12.13.04.000000 AM
202 ORACLE02_A 25-AUG-22 12.13.05.000000 AM
221 ORACLE02_B 25-AUG-22 12.13.31.000000 AM
222 ORACLE02_B 25-AUG-22 12.13.31.000000 AM
223 ORACLE02_B 25-AUG-22 12.13.32.000000 AM
（略）
通常のData Guardモードの場合（レプリカがマウント）
レプリカがマウントモードの時にスイッチオーバすると、大体2分程度で（元の）レプリカに書き込みが可能となりました。
ID DBN TIME
---------- ------------ -------------------------------------------------------
（略）
1344 ORACLE02_A 25-AUG-22 05.29.10.000000 PM
1345 ORACLE02_A 25-AUG-22 05.29.11.000000 PM
1346 ORACLE02_A 25-AUG-22 05.29.12.000000 PM
1353 ORACLE02_B 25-AUG-22 05.31.01.000000 PM
1354 ORACLE02_B 25-AUG-22 05.31.01.000000 PM
1355 ORACLE02_B 25-AUG-22 05.31.02.000000 PM
（略）
（おまけ）マルチAZとリードレプリカの目的の違い
| マルチAZ | リードレプリカ | マウントされたレプリカ |
|---|---|---|
| 主な目的は高可用性 | 主な目的はスケーラビリティ | 主な目的はリージョン間の災害対策 |
| 同期レプリケーション | 非同期レプリケーシヨン | 非同期レプリケーシヨン |
| プライマリインスタンスのみがアクティブ | すべてのリードレプリカにアクセス可能。読み込みのスケーリングに使用可能 | ユーザーアクセス不可 |
| 異なる AZ 間の配置となる | ソースDB と同一AZ / 異なるAZ / 異なるリージョンに配置可能 | ソースDB と同一AZ / 異なるAZ / 異なるリージョンに配置可能 |
| 問題が検出された場合のスタンバイへの自動フェイルオーバー |
Data Guard構成を維持したままレプリカへのマネージドなスイッチオーバ レプリカインスタンスのスタンドアロンインスタンスへの昇格も可能 |
Data Guard構成を維持したままレプリカへのマネージドなスイッチオーバ レプリカインスタンスのスタンドアロンインスタンスへの昇格も可能 |
| RDSでサポートされる全てのOracleデータベースエディション | 要 Oracle Enterprise Edition と Active Data Guard オプション | 要 Oracle Enterprise Edition |