本記事は、Oracle Cloud Infrastructure Advent Calendar 2022の Day24 のエントリーです。
闇の魔術に対する防衛術 Advent Calendar 2022 のエントリーではありません。
全てのDGアソシエーションで泣きたくない人たちへ
BaseDBの自動DataGuardアソシエーション機能（以下 DGアソシエーション）はOracleDatabaseに知見のないものでも簡単にDataGuard環境を作ることができる機能です。
本記事では、DGアソシエーションという闇の魔術に対する防衛術について、検証とSRの回答をもとに綴ってゆきます。
環境
- OCI BaseDB VMタイプ（ライセンスEE）
- DGアソシエーションでDataGuard構成（最大パフォーマンス）
DBの接尾辞に命名規則を適用しない
BaseDBのDBの名前は接尾辞（_nrt19cなど）を付与する仕組みになっており、プライマリ側についてはこの接尾辞をデプロイ時に指定できます。
しかし、DGアソシエーションを作成する画面には接尾辞を指定するフォームが存在せず、接尾辞についてはランダムで指定されてしまうため、命名規則が適用できません。
SYSユーザのパスワードを単純化しない
sysユーザのパスワードはBaseDBをデプロイする際に設定しますが、パスワードについては複雑さのルールが設けられていて、単純なパスワードは設定できません。
デプロイ後に、ユーザプロファイルを変更して、複雑さのルールを解除することは可能ですが、DGアソシエーションを使用する場合、SYSユーザのパスワードの複雑さはデプロイ時のそのままにしておくほうが良いでしょう。
OCIコンソールからDGアソシエーションを作成する時にプライマリと同じSYSユーザのパスワードの入力が必要になります。このWebフォームの入力チェックにパスワードの複雑さのルールが設定されており、たとえプライマリと同じパスワードだったとしても弾かれてしまいます。
自動フェイルオーバ機能が必要なら別途用意する
DGアソシエーションを使用して作成したDataGuardについてはOCIコンソールからの操作や機能で自動フェイルオーバについては提供されません。
SRからは得た回答としては、自動フェイルオーバをしたいなら、DGアソシエーションを使用せず、手組みでBaseDB同士をDataGuard構成してくださいね ということでした。
事前にスタンバイ側に自動バックアップ設定を仕込まない
前提として自動バックアップが動作するのはプライマリ側のみです。事前にスタンバイ側へスイッチオーバして、自動バックアップを設定しておこうと思うかもしれません。
しかし、SRからの回答によると、スタンバイ側に事前に自動バックアップの設定をすることは非推奨で、切り替えてから設定してくださいとのことでした。
※非推奨の理由は明言されませんでしたが、次の項目に記載のRMANのポリシーが残るからかもしれません。
スイッチオーバ後はスタンバイ側（元プライマリ）のRMANのポリシーをチェックする
スイッチオーバ後は、自動バックアップの設定が残ったスタンバイ（元プライマリ）ができてしまいます。この時に下記のRMANのポリシーが機能してしまい、アーカイブログが削除されず、スタンバイのREDO領域が枯渇する。というトラブルに発展してしまいました。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE' SHIPPED TO ALL STANDBY;
2022/12/22時点においては、SRからOCIコンソール側でスイッチオーバやフェイルオーバを行う限りにおいては、スタンバイ側で上記設定が残らないという回答を得ています。
しかし、OCIコンソール以外の方法でスイッチオーバを行う場合は、スタンバイのポリシーについて下記のように書き換える必要があるとのことです。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
ロール、適用ラグの表示を信用しすぎない
OCIコンソールのData Guardアソシエーションの画面でラグやロールが表示されます。
こちらの画面からスイッチオーバやフェイルオーバも実施できるのですが、実施してもなかなか画面上のロールが更新されないことを何度か確認しています。操作実施後に、CLI(dgmgrl)などで確認できるようにしておくと安心です。
また、適用ラグについては30秒以上の適用ラグが発生していた際も正しく取得できていなかったため、こちらも確認手段を準備しておきましょう。ｄｇｍｇｒｌやSQLなどで確認できます。
- フィジカルスタンバイ問い合わせ 転送ラグ
select name,value,time_computed,datum_time from v$dataguard_stats where name='transport lag' and value > '+00 00:01:00';- フィジカルスタンバイ問い合わせ 適用ラグ
select name,value,time_computed,datum_time from v$dataguard_stats where name='apply lag' and value > '+00 00:01:00';
CLIでのスイッチオーバ、フェイルオーバの手段を準備しておく
OCIコンソールからフェイルオーバを行い、何かしらの原因で実行できなかった場合画面には ”SRに連絡してください”というメッセージが表示され、詳細なエラーについては表示されず、自力での解決はできません。
OracleとしてはOCIコンソールでできる操作はOCIコンソールでしてくださいというのが推奨ですが、CLI(dgmgrlなど)で切り替えできる方法を準備しておくべきでしょう。
データベース・ソフトウェアイメージを活用する
DGアソシエーションでスタンバイを作成すると、その時点で最新のDBシステム（GI）とOracleDatabaseのパッチが適用されたインスタンスが作成されてしまいます。つまり、プライマリ側が19.16でスタンバイ側が19.17という状態が発生します。
これを回避するためには、プライマリと同じバージョンのデータベース・ソフトウェアイメージを作成しておき、DGアソシエーションの作成時に指定することでOracleDatabaseについてはプライマリと同じバージョンを維持できます。
DBシステム（GI）についてはコントロールできず、プライマリとスタンバイでDBシステムの適用パッチが異なってしまいます。SRに聞いたところによると、19cという限りにおいてはそれほど問題はないとのことです。（そんなこと保証できる？）
BaseDBの再構築を運用として許容する
DGアソシエーションというよりは、BaseDBの話ですが、そもそもBaseDBのVMの場合、自動バックアップから既存のサーバにデータをリストアできず、新規インスタンスの作成しかできません。
※自動バックアップを使用している場合、”バックアップ”からではなく、”リストア”メニューから既存のDBサーバにリストアを行うことはできます。
自動バックアップで取得されるのはDBのデータであって、OSのシステム領域ではないので新規インスタンスを作成する場合、DBのデータ以外は再構築が必要となります。
Oracle側でブートボリュームは1週間に一度バックアップをとっていますが、これも、既存のDBサーバに対してリストアはできず、新しくBaseDBをデプロイすることになるという回答でした。
ちなみに、/u01領域が存在するボリュームについてはOracle側ではバックアップをとっていないとのことです。
大量のデータをインポートする場合は、スタンバイを削除する
既ににDataGuardを構成した後で、大量のデータをインポートする場合、自動バックアップポリシーによって、バックアップ前のアーカイブログの削除が抑制されているため、アーカイブログによってプライマリのREDO領域が枯渇します。
ユーザ側でアーカイブログを削除することは推奨ではないため、どうするかというと、スタンバイを終了させて、プライマリにデータをインポートしてからスタンバイを作成してくださいというのがSRからの回答でした。
もちろんDataGuardの構成を維持しつつ、従来の方法でアーカイブログを削除する方法は存在するのですが、少なくともBaseDBの担当に確認してもそれを案内はしてくれません。
おわりに
今年は、DBAがジョインしたことやOracleDB用のSlackチャネルを設けたこともあり、より深くBaseDBやDGアソシエーションへの理解を深めることができた1年でした。
みなさん。ハッピークリスマス＆ハッピーニューイヤー