2018年12月02日

[Oracle Database or GoldenGate Advent Calendar 2018] Oracle on Hyper-V 2018

charade_oo4oと申します。今年は「Oracle Database or GoldenGate Advent Calendar 2018」へ参加致します。

 <2018年>

今年はOracleとMicrosoftのリリースに振り回された印象です。
Oracle Databaseは12.2も18も3ヶ月毎のラピッドリリースとなっていました。
セキュリティパッチは半年分しか出ません。

Microsoftは春と秋の2回ともリリースが遅れました。
Windows Server 2019に対応したOracle Databaseも、そのうち出てくるのでしょうか。

個人的には、今年はData Guardと奮闘しました。
12.2 CDBだった事も苦労した一因でした。
躓いた点を書き残したいと思います。

Data Guardの検証でもHyper-Vを活用しました。

 <Data Guardの作り方>

Data Guardを構築する際に、2点決める必要があります。
1.Oracle Enterprise Managerを使用するか。
2.Data Guard Brokerを使用するか。

Oracle Enterprise Managerを使う場合、Data Guard Brokerを使う事になります。
Oracle Enterprise Managerの利点は、ベストプラクティスを簡単に適用出来る事です。
プライマリDBの初期化パラメータ変更やスタンバイREDOログ追加を実行出来ます。
欠点は後述します。

Data Guard Brokerの利点は、自動フェイルオーバーが可能な点です。
それらの機能が必要な場合、Data Guard Brokerは必須となるので、悩む必要はありません。
欠点は、Data Guardのコマンドを直接実行出来ず、DGMGRLやWEB画面から操作する必要があります。
余計な層が一枚入っている様な感じでした。

今回は、検証時点ではOracle Enterprise Managerを使用しましたが、本番環境はどちらも使用しませんでした。
というより、Oracle Enterprise Managerでは構築出来ない構成(プライマリDB:RAC、スタンバイDB:単一)でした。
単一インスタンスのスタンバイDBにファイルシステムを使用していると、Data Guard構築のウィザードが警告を出して続行出来ませんでした。
Oracle Enterprise Managerではなく、RMANとSQL*Plusを使用した構築は可能でした。

 <Data GuardとRAC>

マニュアルを見直すと、12.2以降、単一プライマリと複数スタンバイの組み合わせが不可になっていました。
過去バージョンでは可だった構成が不可となるので、バージョンアップで問題が発生する可能性もあります。

https://docs.oracle.com/cd/E57425_01/121/SBYDB/rac_support.htm
12.1では単一・複数、プライマリ・スタンバイ、4通りの組み合わせが全て可。

https://docs.oracle.com/cd/E82638_01/sbydb/configuring-data-guard-standby-databases-in-oracle-RAC.html
12.2では単一プライマリと複数スタンバイの組み合わせが不可。

 <PDB単位でのData Guard>

12.2から追加された初期化パラメータENABLED_PDBS_ON_STANDBYで、PDB単位にスタンバイDBでの複製を有効・無効に設定する事が出来る様になりました。
但し、このパラメータ設定が有効となるタイミングに癖がありました。
マニュアルを読んだ際には、スタンバイDB側で動的に変更できるので、設定する度にPDBへのREDO Applyを有効・無効にするのかと思っていました。
しかし、このパラメータ設定が有効となるタイミングは、CREATE PLUGGABLE DATABASE実行時のみでした。
CREATE PLUGGABLE DATABASEのSTANDBYS=NONE,ALLと変わりません。

では作成したPDBを、後からスタンバイDBでの複製を有効・無効に設定する事は出来ないのか?
下記コマンドで後から変更可能でした。
ALTER PLUGGABLE DATABASE 〜 ENABLE/DISABLE RECOVERY
ENABLED_PDBS_ON_STANDBYも、STANDBYSも、裏ではENABLE/DISABLE RECOVERYしている様です。

更なる注意点として、Data Guard新規構築時には、全PDBを有効化する必要があります。
RMANのDUPLICATEコマンドでは、初期化パラメータENABLED_PDBS_ON_STANDBYが効かず、SKIP PLUGGABLE DATABASE、PLUGGABLE DATABASEオプションも使用できません。

https://docs.oracle.com/cd/E82638_01/rcmrf/DUPLICATE.html
注意: スタンバイ・データベースを作成する際に、SKIP TABLESPACE、TABLESPACE、SKIP PLUGGABLE DATABASE、PLUGGABLE DATABASEオプションは使用できません。

特定PDBのみ複製を有効化する場合でも、スタンバイDB側のストレージのサイジングは少なくともプライマリDBの全データファイルが収まる容量が必要です。

 <PDBフラッシュバック>

Q.プライマリDBのPDBをフラッシュバックするとどうなるのでしょうか?
A.スタンバイDBのCDB全体でREDO Applyが停止します。

https://docs.oracle.com/cd/E82638_01/sbydb/examples-of-using-oracle-data-guard.html
プライマリでPDB PITRまたはPDBフラッシュバックを実行し、操作の開始に関するREDOが初めて検出されると、スタンバイでのMRPはエラーORA-39874に続いて補助エラーORA-39873で終了します。

マニュアルは判り辛い書き方です。
Data Guardの詳細を理解していないと、MRP終了=CDB全体でのREDO Apply停止 に結びつかないと思います。

Data Guardのデータ同期最終時刻はV$DATAGUARD_STATSから確認可能です。
今回はこのビューを使用して、REDO Applyの監視を行いました。

 <リフレッシュ可能なクローンPDB>

今回は採用しませんでしたが、リフレッシュ可能なクローンPDBは、内部的にはData Guardと同様にメディアリカバリを行います。
PDB単位でのData Guardの代わりに、リフレッシュ可能なクローンPDBを使用するという方法も考えられます。
PDBフラッシュバック時にCDB全体のREDO Applyが停止してしまう問題にも対処出来ます。
H/W移行時にリフレッシュ可能なクローンPDBを使用して、ダウンタイムを減らすという方法も面白そうです。

 <2019年>

19cは12.2ファミリーのターミナルパッチなので、今後数年間使われる事になると思います。
より便利なDBになる事を期待しています。


posted by charade at 00:00| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。