しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。”しばちょう”こと柴田長（しばた つかさ）です。
何故、ココまで記事を書いて来なかったのか？と突っ込まれても仕方がないぐらい引き延ばしてきましたが、Oracle Databaseの高可用性機能の代表とでも言える、Data Guard構成を組んでみたいと思います。一つ以上のPhysical Standby Databaseを用意して、いつでも切り替えられる状態にしておけば、Prima
ry Database側に万が一の障害時にも慌てることなく対応することができるようになるでしょう。
Data Guardとは、簡単に言えば、本番データベース（Primary Database）の完全なコピー・データベース（Standby Database）を提供する機能です。Primary Databaseで生成されたRedoデータをStandby Databaseへ自動的に転送+適用することで、常に同じデータの状態を維持させることが可能です。よって、万が一、Primary Databaseに障害が発生しても、Standby Database側をPrimaryロールへ昇格させることで本番システムのダウンタイムを極小化することが可能となりますし、パッチ適用時に順番に適用することができるので、メンテナンスに伴うシステム停止時間も短くすることが可能になるでしょう。
Data Guardのメリットや、ストレージのリモート・コピー機能に対する優位性等は非常に多いのですが、それは私の過去の講演資料を参照してみてください。おそらく、この連載を読んで頂いている方の多くは、文章よりもコマンド大好き技術者が多いと思いますので、さっそく、前回学習した「RMANバックアップからのデータベースの複製」の手順に少し手を加える形でPrimary Databaseへの影響を極力排除した方法を使って、Physical Standby Databaseの作成を試してみましょう。（今回作成するData Guard構成は、Redoデータを非同期で転送するASYNCモードの構成ですが、構築後に同期転送（SYNC）モードへ切り替えることが可能なので、作成手順としては同じになります。）とは言え、Data Guard構成を組む手順は世の中に溢れていると思うので、今回は2ノードRACデータベースのStandby Databaseを構築する手順をプラスしたいと考えています。DuplicateコマンドでStandby Databaseを作成した後に、実際に運用できる状態まで持って行くのは意外と面倒なので、その部分を紹介しておきたいと思います。（RACを解説した記事を書いたことないけど、そこは愛嬌で許してください）
私は、Oracle Database 19c Enterprise Editionのデータベースを使って以下の演習を実施しています。DBRU19.8.0上のCDBの2ノードRACデータベースにおいて、データファイル格納用の+DATA01と、バックアップ関連ファイル格納用の+RECO01という、2つのASMディスク・グループがある環境で、動作確認を行っています。
再掲となりますが、今回は次に示している、複製するデータベースのタイプはType2で、実行方式はB-3となります。
- DUPLICATEコマンドで複製（作成）するデータベースのタイプ
- (Type1) ソース（複製元）データベースのコピー・データベース
- (Type2) ソース（複製元）データベースをプライマリ・データベースとするData Guard環境におけるスタンバイ・データベース
- DUPLICATEコマンドの実行方式
- (A) Active duplication
- 主な特徴
- DUPLICATE … FROM ACTIVE DATABASEコマンド
- マウント or オープン状態のソース（複製元）データベースに、TARGETとして接続が必須
- 複製先データベース（補助インスタンス）に、AUXILIARYとして接続が必須
- (A-1) イメージ・コピーを使用
- コマンド実行時にソース（複製元）データベース上から必要なデータファイルを読み、イメージ・コピー形式で、複製先の補助データベースへ転送されるプッシュベースの方法
- (A-2) バックアップ・セットを使用
- コマンド実行時にソース（複製元）データベース上から必要なデータファイルを読み、バックアップ・セット形式で、複製先の補助データベースが取得するプルベースの方法
※ 次のいずれかの条件を満たす場合のみ(A-2)の動作となり、それ以外は(A-1）の動作が自動選択される。
・DUPLICATE … FROM ACTIVE DATABASEコマンドにUSING BACKUPSET, USING COMPRESSED BACKUPSET句またはSECTION SIZE句が含む
・割り当てられた補助チャネルの数が、割り当てられたターゲット・チャネルの数と同じか、それ以上の場合
- コマンド実行時にソース（複製元）データベース上から必要なデータファイルを読み、バックアップ・セット形式で、複製先の補助データベースが取得するプルベースの方法
- 主な特徴
- (B) Backup-based duplication
- 主な特徴
- DUPLICATE … FROM ACTIVE DATABASEコマンドではない
- 取得済みバックアップを使ってデータベースを複製する方式であり、TARGET接続やカタログ接続は、あくまでバックアップの情報を把握する目的
- 複製先データベース（補助インスタンス）に、AUXILIARYとして接続が必須
- (B-1) ソース（複製元）データベースにTARGETとして接続（TARGET接続有り + CATALOG接続は任意）
- (B-2) ターゲット接続を行わない（TARGET接続無し + CATALOG接続有り）
- (B-3) ターゲット・データベースを持たず、リカバリ・カタログ接続も行わない（TARGET接続無し + CATALOG接続無し）
- 主な特徴
- (A) Active duplication
演習0. 第57回の演習2～5の手順に従って、Primary Databaseにおいて適切なRMANバックアップを取得し、必要に応じて、作成するStandby Databaseインスタンスからアクセス可能な場所にコピーしてください。ただし、SPFileの個別バックアップも追加で取得してください。
# Primary DBが稼働するDBサーバー上のASMインスタンスへ接続するための環境変数を設定 $ export ORACLE_SID=+ASM1 $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/19.0.0.0/grid $ export PATH=$PATH:$ORACLE_HOME/bin # asmcmdユーティリティを起動して、バックアップを格納するディレクトリを作成 $ asmcmd ASMCMD> cd +DATA01 ASMCMD> mkdir BKUP ### ソース・データベース（Primary DB）において、RMANバックアップの実行 $ export ORACLE_SID=dbm021 $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1 $ export PATH=$ORACLE_HOME/bin:$PATH $ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS" $ rman target / connected to target database: DBM02 (DBID=1036374939) RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 ; # 検証目的のために、一旦、全バックアップを削除（本番環境では不用意に実行しないでください） delete noprompt force backup of database ; delete noprompt force backup of controlfile ; delete noprompt force datafilecopy all ; # 全データファイルのオンライン・バックアップを実行 BACKUP DEVICE TYPE DISK FORMAT '+DATA01/BKUP/%U' INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE ; # データファイルのバックアップ後に、制御ファイルのバックアップを個別に取得する BACKUP DEVICE TYPE DISK FORMAT '+DATA01/BKUP/%U' TAG 'controlfile' CURRENT CONTROLFILE ; # SPFileのバックアップを個別に取得する BACKUP DEVICE TYPE DISK FORMAT '+DATA01/BKUP/%U' TAG 'controlfile' SPFILE ; # アーカイブログもバックアップしておく BACKUP DEVICE TYPE DISK FORMAT '+DATA01/BKUP/%U' ARCHIVELOG ALL ; # 再び、Primary DBが稼働するDBサーバー上のASMインスタンスへASMCMDユーティリティで接続 $ export ORACLE_SID=+ASM1 $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/19.0.0.0/grid $ export PATH=$PATH:$ORACLE_HOME/bin $ asmcmd ASMCMD> # Standby Database側のBackup Location（+DATA01/BKUP/）直下へリモート・コピー ### CDB用データファイル cp +RECO01/DBM02/DATAFILE/SYSAUX.1342.1077187063 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/sysaux.bk cp +RECO01/DBM02/DATAFILESYSTEM.1341.1077187063 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/system.bk cp +RECO01/DBM02/DATAFILEUNDOTBS1.1340.1077187087 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs1.bk cp +RECO01/DBM02/DATAFILEUNDOTBS2.1328.1077187087 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs2.bk cp +RECO01/DBM02/DATAFILEUSERS.610.1077187185 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/users.bk ### PDB$SEED用データファイル cd +RECO01/DBM02/BFD247E899F2FFDCE05347047A0A4F1A/DATAFILE cp SYSAUX.1093.1077187127 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/sysaux_s.bk cp SYSTEM.1111.1077187127 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/system_s.bk cp UNDOTBS1.1035.1077187135 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs1_s.bk ### PDB1用データファイル cd +RECO01/DBM02/BFD32B18990C4D0DE05347047A0A7568/DATAFILE cp SYSAUX.517.1077187143 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/sysaux_p1.bk cp SYSTEM.1017.1077187135 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/system_p1.bk cp TBS0.1006.1077187113 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/tbs0_p1.bk cp UNDOTBS1.305.1077187143 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs1_p1.bk cp UNDO_2.914.1077187149 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undo_2_p1.bk cp USERS.620.1077187185 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/users2_p1.bk ### PDB2用データファイル cd +RECO01/DBM02/C09EC9246D0DA186E05346047A0A1397/DATAFILE cp SYSAUX.851.1077187157 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/sysaux_p2.bk cp SYSTEM.916.1077187149 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/system_p2.bk cp TBS2.661.1077187179 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/tbs2_p2.bk cp UNDOTBS1.720.1077187157 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs1_p2.bk cp UNDO_2.719.1077187165 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undo_2_p2.bk ### PDB3用データファイル cd +RECO01/DBM02/C0DCDCD4644B386EE05346047A0AB205/DATAFILE cp SYSAUX.705.1077187171 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/sysaux_p4.bk cp SYSTEM.718.1077187165 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/system_p4.bk cp TBS0.1124.1077187113 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/tbs0_p4.bk cp UNDOTBS1.695.1077187171 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undotbs1_p4.bk cp UNDO_2.662.1077187179 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/undo_2_p4.bk cp USERS.550.1077187187 sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/users_p4.bk ### 制御ファイル、SPFILE、そしてアーカイブログのバックアップも同様にリモート・コピー cp +DATA01/BACKUP/xxxxxxxx sys/<password>@<standby_db_node#1>.+ASM1:+DATA01/BKUP/xxxxxxxx.bk ...(省略)...
いつもと同様の指の準備体操・・・というレベル感では無かったですね。そして、丸投げ感が半端ない演習問題で大変申し訳ございません。今回の連載は全15演習を予定しており、この演習を分割して解説しているわけにはいかないという点をご理解頂ければ助かります。とはいえ、ほぼ基本的に第57回の演習2~演習5の復習とはなっているものの、2点だけ新しいコマンドが登場しているので、そこだけ解説させてください。
一つ目は、SPFILEの個別バックアップですね。これは全く問題ないと思います。「こんなことができるんだ」と言う、薄っすらとした記憶を持っておいて頂けると良いかな程度です。
二つ目は、かなり興味深いコマンドで、asmcmdユーティリティのcpコマンドです。「えっ？前回も利用したけど・・・」と思って頂いた方、とても嬉しいですねーありがとうございます。はい、確かに前回も利用しましたが、あくまで、同一ASMインスタンスが管理する別のASMディスク・グループ間でのファイル・コピーでしたね。今回は、asmcmdユーティリティで接続しているローカルのASMインスタンスではなく、異なるクラスタ上で稼働するASMインスタンスが管理するASMディスク・グループへのリモート・ファイル・コピーなのですよ！！コレ、意外と紹介されている文献は少ない気がするので（調べていませんけど）、ここで是非覚えてしまってください。
私なりに汎用的なコマンド例を書いてみましたので参考にしてみてください（実行時に改行は外してください）。念のため、<> で囲ってある項目を説明しておきますね。って、頑張って整理してみたものの、やはりさすがのOracle Database ドキュメント！asmcmdのcpコマンドのサンプルも含めて掲載されていました（泣）
ASMCMD> cp <Local ASM Diskgroup Name>/<Full Path1>/<File Name1> sys/<ASM SYS password>@<Remote Node>.<Remote ASM Instance Name>:<Remote ASM Diskgroup Name>/<Full Path2>/<File Name2>
- <Local ASM Diskgroup Name> : asmcmdで接続しているローカルのASMインスタンスが管理していて、コピー対象のファイルが格納されているASMディスク・グループ名（省略可）
- <Full Path1> : コピー対象のファイルが格納されているディレクトリのフルパス（省略可）
- <File Name1> : コピー対象のファイル名
- <ASM SYS password> : コピー先（リモート）の別のクラスタ上で稼働しているASMインスタンスのSYSユーザーのパスワード
- <Remote Node>: コピー先（リモート）のASMインスタンスが稼働しているホスト名
- <Remote ASM Instance Name> : コピー先（リモート）のASMインスタンスの名前
- <Remote ASM Diskgroup Name> : コピー先（リモート）のASMディスク・グループ名
- <Full Path2> : コピー先のディレクトリのフルパス
- <File Name2> : コピー先でのファイルの名前
演習1. Primary Databaseの状態（特に、Data Guard構成を組む上で必要となる設定）を確認してください。
$ export ORACLE_SID=dbm021 $ sqlplus / as sysdba SQL> -- PDBの確認 show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 PDB1 READ WRITE NO 4 PDB2 READ WRITE NO 5 PDB4 READ WRITE NO -- アーカイブ・ログ・モードの確認 archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 7 Next log sequence to archive 10 Current log sequence 10 -- Force Loggingの確認 select FORCE_LOGGING from V$DATABASE ; FORCE_LOGGING --------------------------------------- NO -- Flashback Loggingの確認 select flashback_on from v$database ; FLASHBACK_ON ------------------ YES -- Online Redo Log (ORL)の確認 select GROUP#, THREAD#, BYTES/1024/1024, MEMBERS from V$LOG order by 1, 2 ; GROUP# THREAD# BYTES/1024/1024 MEMBERS ---------- ---------- --------------- ---------- 1 2 4096 1 2 2 4096 1 3 1 4096 1 4 1 4096 1 5 1 4096 1 6 1 4096 1 7 2 4096 1 8 2 4096 1 -- Standby Redo log (SRL)の確認 select GROUP#, THREAD#, BYTES/1024/1024 from V$STANDBY_LOG order by 1, 2; no rows selected -- Password Fileの確認 col FILE_NAME for a60 select FILE_NAME, FORMAT, IS_ASM from V$PASSWORDFILE_INFO ; FILE_NAME FORMAT IS_AS ------------------------------------------------------------ ------ ----- +DATA01/DBM02/PASSWORD/pwddbm02.750.1069759245 12 TRUE
はい、こちらは私がData Guard構成を組む前に、Primary Databaseで一通り確認する情報となります。一つ一つのコマンドはそれほど難しくないと思いますが、確認している理由は、Data Guard構成を組む上で絶対に理解しておいて頂きたいものばかりですので、以下に記載しておきますね。
- PDBの確認
- 実は、この確認は必要ありません。Primary Databaseに対するPhysical Standby DatabaseをRMANのduplicateコマンドで作成する際には、CDB or 非CDBであることを気にする必要が無いからです。理由は、バージョン19cにおいては、RMANのduplicateコマンドでのStandby Databaseを作成はPDBの部分複製（一部のPDBだけをStandby Databaseに含める）をサポートしていないからです。バックアップおよびリカバリ・リファレンスで、duplicateコマンドの「FOR STANDBY」句を参照して頂くと、次の注意書き（あくまでPhysical Standby Database作成時に限定した文章）が記載されています。
注意: RMANは、PDBの部分複製をサポートしていません。したがって、スタンバイ・データベースの作成時にSKIP TABLESPACE、TABLESPACE、SKIP PLUGGABLE DATABASEおよびPLUGGABLE DATABASEオプションを使用できません。
- 補足しておくと、冒頭に再掲させて頂いたduplicateコマンドの解説において、「複製するデータベースのタイプがType1（Standbyではなく、コピー・データベース）で、実行方式はA（Active Duplication方式）」の場合は、PDBの部分複製できる（SKIP PLUGGABLE DATABASE または、PLUGGABLE DATABASEオプションが使用できる）はずです。
- 実は、この確認は必要ありません。Primary Databaseに対するPhysical Standby DatabaseをRMANのduplicateコマンドで作成する際には、CDB or 非CDBであることを気にする必要が無いからです。理由は、バージョン19cにおいては、RMANのduplicateコマンドでのStandby Databaseを作成はPDBの部分複製（一部のPDBだけをStandby Databaseに含める）をサポートしていないからです。バックアップおよびリカバリ・リファレンスで、duplicateコマンドの「FOR STANDBY」句を参照して頂くと、次の注意書き（あくまでPhysical Standby Database作成時に限定した文章）が記載されています。
- アーカイブ・ログ・モードの確認
- ここは絶対に譲れません。確実にアーカイブ・ログ・モードで運用されていることを確認してください。
- Force Loggingの確認
- この設定も、基本的に、Data Guard構成を組むのであれば設定しておくべきです。
- APPENDヒント句付でINSERT処理を行った場合、RedoとUNDOデータが生成されないから高速であると、過去に紹介した記憶が・・・と思って、探してみたら、第4回の演習7の解説に記載されていました。が、Data Guard構成は、RedoデータをPrimaryからStandbyへ転送して同期する仕組みなので、全てのオペレーションで強制的にRedoデータを生成させるために、Force Loggingの設定が推奨されています。もしも、Force Loggingが設定されていない場合は同期することが出来なくなるので、Redoデータ以外で同期させる解消方法を実施する必要があります。この方法に関しては、次回以降の回で紹介したいと思います。
- ちなみに、Oracle Database 18cで、新たなLoggingモードが二つ実装されていますが、少々難しくなる印象なので、まずは、従来からのForce Loggingを有効化してみるところから始めた方が良いと思います。もちろん、ご興味のある方は、「Oracle Data Guard 概要および管理」をご参照ください。
- Flashback Loggingの確認
- Data Guard構成を組む際には必要ありませんが、Data Guard構成を運用していく上では設定しておいた方が良いでしょう。
- Primary Databaseに万が一の障害が発生した際に、フェイル・オーバーを実施する可能性がありますが、このフェイル・オーバー実施後の元Primary Databaseはどうなるでしょうか？簡単に言えば残骸デス。でも、新規のStandby Databaseとして利用したいですよね？そのような場合に備えて、このFlashback Loggingを有効化しておくと、短時間で新Standbyとして利用再開させることができるオペレーションが行えるようになるのです！
- Flashback Databaseについては、第19回 フラッシュバック・データベースによる論理障害からの復旧を参照してください。
- Online Redo Log (ORL)の確認
- 既存のORLの構成（グループ数、サイズ、メンバー数等）を把握するために実施しています。
- 個人的には各インスタンスに4つ以上のRedoグループを保持するようにしています。なぜ3つじゃダメなのか？きっと3つでも大丈夫ですが、明確に記憶の無い過去の経験から、4つ以上に差せているんでしょうね。
- Standby Redo log (SRL)の確認
- Physical Standby Databaseは、Primary Databaseで生成されたRedoデータを受信するわけですが、受信したものをORLとは別のSRLに書き込んで保存します。
- 基本的には、ORLと同じグループ数とサイズにしておくと問題は起きません。（メンバー数は関係ありませんので、可用性の観点だけで考慮してください）
- 今はPrimary Database（正確には、Primary ロールで動作している）かもしれませんが、ロールを入れ替える（スイッチ・オーバーとか、フェイル・オーバーとか言います）ことで、Standby Database（Standbyロール）で動作する可能性があります。そういう意味で、Primary Databaseでも、SRLを作成しておく必要があるのです。
- また、この後、duplicateコマンドでPhysical Standby Databaseを作成するわけですが、元となるソース・データベース上にSRLが作成されている場合、duplicateのタイミングでStandby Database側にもSRLが自動作成されます。よって、duplicateコマンド実行前（今回のケースではバックアップ実行前）に、Primary Database側にSRLを作成しておくと手間が省けます。
- Password Fileの確認
- Primary Databaseで使用しているパスワード・ファイルの場所を正確に把握します。
- Data Guard Physical Standby Databaseでは、Primary Databaseで使用しているパスワード・ファイルと完全に同じコピーを使わせる必要があります。
- 「Redoデータを転送する」と言うのは「リモートのデータベースにログインする」を意味しています。と書くと、なんとなく間の良い方は気付かれると思いますが、要は、Redoデータを転送する際に同じパスワード・ファイルを使って通信できるようにしているわけです。このパスワード・ファイルをコピーしないで、SYSユーザーのパスワードを同じに設定したら良いのでは？と思って昔試したことがありますが、結論は、Redoデータの転送に失敗しましたね。
と、ここまで書いてきて既に3時間以上が経過していますが、まだ演習1の解説が終わったところですか・・・少し文章を書き過ぎているかもしれません。読み辛かったら本当にごめんなさい。でも、とても大切なことを間違いなくお伝えしたい気持ちで書いていますので、長文になってしまうかもしれませんが、お付き合いいただけると嬉しいです。さあ、頑張りましょう。
演習2. 演習1の結果を元に、Primary DatabaseをData Guard構成へ組み込む準備（強制ロギングの有効化、スタンバイRedoログの作成）をしてください。
$ export ORACLE_SID=dbm021 $ sqlplus / as sysdba SQL> -- Force Loggingの確認 alter database force logging ; select FORCE_LOGGING from V$DATABASE ; FORCE_LOGGING --------------------------------------- YES -- Standby Redo log (SRL)の作成 alter database add standby logfile thread 1 size 4096M; alter database add standby logfile thread 1 size 4096M; alter database add standby logfile thread 1 size 4096M; alter database add standby logfile thread 1 size 4096M; alter database add standby logfile thread 1 size 4096M; alter database add standby logfile thread 2 size 4096M; alter database add standby logfile thread 2 size 4096M; alter database add standby logfile thread 2 size 4096M; alter database add standby logfile thread 2 size 4096M; alter database add standby logfile thread 2 size 4096M; -- Standby Redo log (SRL)の確認 select GROUP#, THREAD#, BYTES/1024/1024 from V$STANDBY_LOG order by 1, 2; GROUP# THREAD# BYTES/1024/1024 ---------- ---------- --------------- 9 1 4096 10 1 4096 11 1 4096 12 1 4096 13 1 4096 14 2 4096 15 2 4096 16 2 4096 17 2 4096 18 2 4096
この演習2のコマンドは問題なく実施できたかと思います。そして、特に解説も必要無いと思うので、先を急ぎましょう。スピードアップ！！
演習3. Primary DatabaseのData Guard構成に関連する初期化パラメータを確認、変更してください。
$ export ORACLE_SID=dbm021 $ sqlplus / as sysdba SQL> -- 現状の確認 set lines 300 pages 50000 tab off trim on col NAME for a30 col VALUE for a150 select INST_ID, NAME, VALUE from GV$PARAMETER where upper(NAME) in ( 'LOG_ARCHIVE_CONFIG', 'LOG_ARCHIVE_DEST_1', 'LOG_ARCHIVE_DEST_2', 'LOG_ARCHIVE_DEST_3', 'LOG_ARCHIVE_DEST_STATE_1', 'LOG_ARCHIVE_DEST_STATE_2', 'LOG_ARCHIVE_DEST_STATE_3', 'LOG_ARCHIVE_FORMAT', 'REMOTE_LOGIN_PASSWORDFILE', 'DB_RECOVERY_FILE_DEST', 'DB_RECOVERY_FILE_DEST_SIZE', 'FAL_CLIENT', 'FAL_SERVER', 'STANDBY_FILE_MANAGEMENT', 'DB_NAME', 'DB_UNIQUE_NAME', 'AUDIT_FILE_DEST', 'DIAGNOSTIC_DEST', 'REMOTE_LISTENER', 'CLUSTER_INTERCONNECTS') order by 2, 1 ; INST_ID NAME VALUE ---------- ------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------- 1 audit_file_dest /u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/audit 2 audit_file_dest /u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/audit 1 cluster_interconnects 192.168.20.65:192.168.20.66 2 cluster_interconnects 192.168.20.67:192.168.20.68 1 db_name dbm02 2 db_name dbm02 1 db_recovery_file_dest +RECO01 2 db_recovery_file_dest +RECO01 1 db_recovery_file_dest_size 14249099264000 2 db_recovery_file_dest_size 14249099264000 1 db_unique_name dbm02 2 db_unique_name dbm02 1 diagnostic_dest /u01/app/oracle 2 diagnostic_dest /u01/app/oracle 1 fal_client 2 fal_client 1 fal_server 2 fal_server 1 log_archive_config 2 log_archive_config 1 log_archive_dest_1 location=USE_DB_RECOVERY_FILE_DEST valid_for=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=dbm02 ALTERNATE=LOG_ARCHIVE_DEST_2 2 log_archive_dest_1 location=USE_DB_RECOVERY_FILE_DEST valid_for=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=dbm02 ALTERNATE=LOG_ARCHIVE_DEST_2 1 log_archive_dest_2 location=+DATA01 valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dbm02 ALTERNATE=LOG_ARCHIVE_DEST_1 2 log_archive_dest_2 location=+DATA01 valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dbm02 ALTERNATE=LOG_ARCHIVE_DEST_1 1 log_archive_dest_3 2 log_archive_dest_3 1 log_archive_dest_state_1 ENABLE 2 log_archive_dest_state_1 ENABLE 1 log_archive_dest_state_2 ALTERNATE 2 log_archive_dest_state_2 ALTERNATE 1 log_archive_dest_state_3 ENABLE 2 log_archive_dest_state_3 ENABLE 1 log_archive_format %t_%s_%r.dbf 2 log_archive_format %t_%s_%r.dbf 1 remote_listener scan01:1521 2 remote_listener scan01:1521 1 remote_login_passwordfile EXCLUSIVE 2 remote_login_passwordfile EXCLUSIVE 1 standby_file_management MANUAL 2 standby_file_management MANUAL
はい、こちらの初期化パラメータ一が、私がData Guardを組む前に確認しているものですので参考にしてみてください。記事が長くなってしまうので、SQL文だけでも良いかと思ったのですが、折角の機会なので、出血大サービス？と言うことで、具体的なパラメータ値まで掲載しています。また、今回の私の環境は、2ノードRACデータベースなので、INST_ID列に「1」と「2」が表示されています。RACをご利用されたことのある方であれば問題ないところだと思いますが、念のため解説しておくと、2ノードRACデータベースとは、2つのデータベース・インスタンスで1つのデータベースが構成されていることを意味しており、各インスタンスに設定するパラメータ値をそれぞれ設定することができます。「1」は一つ目のインスタンスのパラメータ、「2」は二つ目のインスタンスのパラメータですね。それぞれ設定できるとは言え、初期化パラメータによっては共通な値に設定されている必要があるもの、逆に、絶対に異なる値に設定しなければならないものがありますので、この辺りは慣れていくしかないところですかね・・・
今回登場している初期化パラメータを一つ一つ解説したいところですが、変更が必要となるパラメータに限定して、次の変更コマンドと共に簡単に説明しておきますね。
-- パラメータ変更 alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbm02,dbm02s)' scope=both sid='*' ; alter system set LOG_ARCHIVE_DEST_3='SERVICE=DBM02S ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbm02s' scope=both sid='*' ; alter system set FAL_CLIENT='DBM02' scope=both sid='*' ; alter system set FAL_SERVER='DBM02S' scope=both sid='*' ; alter system set STANDBY_FILE_MANAGEMENT='AUTO' scope=both sid='*' ;
- LOG_ARCHIVE_CONFIG
- Data Guard構成を組むデータベースのDB_UNIQUE_NAMEをカンマ区切りで指定しておきます。
- LOG_ARCHIVE_DEST_n
- このパラメータは様々な用途で使われるのでとても難しいですが、Redoデータの出力先・転送先と覚えておくと良いでしょう。
- LOG_ARCHIVE_DEST_1は、アーカイブ・ログの出力設定を示しています。
- 「location=USE_DB_RECOVERY_FILE_DEST」で、db_recovery_file_destパラメータに指定されている場所へアーカイブ・ログを指定
- 「valid_for=(ALL_LOGFILES,ALL_ROLES)」によって、このデータベースがPrimary RoleであってもStandby Roleであっても、ORLとSRLに対して、このパラメータ設定を有効化しています
- 「ALTERNATE=LOG_ARCHIVE_DEST_2」は、もしも指定の場所へアーカイブ・ログを出力できなかった場合の代替先を指定しています
- LOG_ARCHIVE_DEST_2は、LOG_ARCHIVE_DEST_1の代替先です。
- LOG_ARCHIVE_DEST_3だけが、Data GuardのRedoデータの転送設定となります。
- 結論としては、Primary Role時に生成されたRedoデータを「SERVICE=DBM02S」に対して、「ASYNC」で転送する設定です。
- 「SERVICE=DBM02S」は、Redoデータを転送する先のデータベースへ接続するための接続識別子で、$ORACLE_HOME/network/admin/tnsnames.oraに定義しておきます。
- 「ASYNC」は、Redoデータを非同期モードで転送します。同期モードを選択する場合、「SYNC AFFIRM」、「SYNC NOAFFIRM」(=Fast Sync)の何れかを設定しますが、これについては、次回以降、別途説明する機会を設けたいと考えています。
- 「VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)」は、このデータベースがPrimary Roleのときに限定して、ORLに対して、このパラメータ設定を有効化しています。
- 「DB_UNIQUE_NAME=dbm02s」は、自分自身のDB_UNIQUE_NAMEを指定します。（お決まりの設定で、理由をきちんと考えたことが無いです）
- FAL_CLIENT
- 自分のDB_UNIQUE_NAMEを設定しておきます。
- FAL_SERVER
- Data Guard構成を組む相手のDB_UNIQUE_NAMEを設定しておきます。
- 3つ以上のデータベースで、Data Guardを組む場合には、もう少しパラメータの理解が必要となります。
- STANDBY_FILE_MANAGEMENT
- Primary Database側でデータファイルが追加作成された際に、Standby Database側でも自動的に対象のデータファイルを追加作成させたい場合に、このパラメータの値を「AUTO」に設定しておきます。
- デフォルトの「MANUAL」の場合、Primary Database側でデータファイルが追加作成された際に、Standby Database側ではデータファイルが自動追加作成されないので、同期が止まることになります。その際は、手動での対処が必要となるので、基本的には「AUTO」に変更した方が良いでしょう。
演習4. Primary DatabaseのPassword Fileを補助インスタンス用に適切なディレクトリへコピーしてください。
### asmcmdユーティリティでASMディスク・グループ上のPassword Fileを一旦、ローカルディスク上へコピーする $ export ORACLE_SID=+ASM1 $ asmcmd ASMCMD> cp +DATA01/DBM02/PASSWORD/pwddbm02.750.1069759245 /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/orapwdbm02s ASMCMD> exit ### Password FileをStandby Databaseを稼働させるDBサーバー上にリモート・コピーする ### 今回は、Standby側も2ノードRACなので、2つのDBサーバーへそれぞれコピーする $ cd /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs $ scp orapwdbm02s1 <Standby_db_node#1>:$PWD/orapwdbm02s1 $ scp orapwdbm02s1 <Standby_db_node#2>:$PWD/orapwdbm02s2
演習1の解説部分にも記載しましたが、Primary Databaseで使用しているパスワードファイルをStandby Databaseでも使用させる必要がありますので、上記のオペレーションを実施しています。
ちなみに、演習問題に、いきなり「補助インスタンス」が登場していますが、こういうのが意外と理解しづらいと個人的には思います。「補助インスタンスとは補助であり、本物ではない」です。これからduplicateコマンドで作成するPhysical Standby Databaseが本物であり、そのduplicateコマンドを実行する際に必要となる一時的な仮のインスタンスを補助インスタンスと読んでいます。実態は、Standby Databaseが稼働するDBサーバー上で、ORACLE_SID環境変数にStandby Databaseのインスタンス名を指定して仮の初期化パラメータファイルを読み込んで、NOMOUNTモードで起動したインスタンスです。
よって、補助インスタンスをNOMOUNTモードで起動する際に、自動的にパスワードファイルが読み込まれるように、適切なディレクトリ上に、適切な名前に変更しておく必要があります。適切なディレクトリとは、補助インスタンスを起動するDBサーバー上の「$ORACLE_HOME/dbs」直下です。適切な名前とは「”orapw” + “ORACLE_SID”」です。今回の私の補助インスタンス名は「dbm02s1」となるので、適切なパスワードファイルの名前は「orapwdbm02s1」となります。（2ノードRAC環境でも、補助インスタンスはシングル・インスタンスとなります）
演習5. 念のため、Standby Database用に必要なディレクトリを作成してください。
ssh oracle@<Standby_db_node#1> "mkdir -p /u01/app/oracle/admin/dbm02s/adump" ssh oracle@<Standby_db_node#2> "mkdir -p /u01/app/oracle/admin/dbm02s/adump" ssh oracle@<Standby_db_node#1> "mkdir -p /u01/app/oracle/diag/rdbms/dbm02s/dbm02s1" ssh oracle@<Standby_db_node#2> "mkdir -p /u01/app/oracle/diag/rdbms/dbm02s/dbm02s2"
はい、あくまで念のためですので、説明は割愛しますー
演習6. 補助インスタンス用の初期化パラメータ・ファイルを作成してください。
$ vi /tmp/pfileAUX.ora *.DB_NAME='dbm02' *.DB_UNIQUE_NAME='dbm02s' *.DB_BLOCK_SIZE=8192 *.MEMORY_TARGET=4g *.REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
「えっ？これだけで良いの？」って驚いて頂けた方、ありがとうございます。はい、これだけで補助インスタンスは起動できますからね。
「でも、前回の連載第57回では、もっと指定しましたよね？癖もあったし・・・」と更に考えて頂けた方、是非今後一緒に仕事をさせてください。お願いします！
理由は、この後の演習8で、いよいよ、duplicateコマンドを実行することになるのですが、そのコマンドの中で「SPFILE」オプションを指定することを予定しています。このオプションを使用することでバックアップからSPFILEがリストアされますので、ここで用意する初期化パラメータ・ファイルは、あくまで補助インスタンスを起動するためのもので、Standby Database用ではないからですね。とはいえ、DB_NAMEとDB_UNIQUE_NAMEパラメータだけは、きっちりとStandby Database用に設定しておきましょうね。
ちなみに、しれっと書いておきますが（あまりにも目立たないと困るので、赤文字で協調しておきますが）、duplicateコマンド実行時に複製されるファイルの一覧は、こちらに記載されています。
演習7. Standby Databaseを稼働させるDBサーバー1号機上で補助インスタンスをNOMOUNTモードで起動し、Password Fileを読み込んでいることを確認してください。
$ export ORACLE_SID=dbm02s1 $ env | grep ORA ORACLE_SID=dbm02s1 ORACLE_BASE=/u01/app/oracle ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1 $ sqlplus / as sysdba SQL> startup nomount pfile='/tmp/pfileAUX.ora' ; ORACLE instance started. Total System Global Area 4293488712 bytes Fixed Size 8904776 bytes Variable Size 3523215360 bytes Database Buffers 553648128 bytes Redo Buffers 207720448 bytes set lines 160 pages 50000 tab off trim on col FILE_NAME for a60 select FILE_NAME, FORMAT, IS_ASM from V$PASSWORDFILE_INFO ; FILE_NAME FORMAT IS_ASM ------------------------------------------------------------ ------------------ --------------- /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/orapwdbm02s1 12 FALSE
pfileオプション付きでインスタンスを起動することはほとんど無いので意外と使い方を忘れているかもしれませんが、特に大きな問題はないでしょう。演習4でコピーしてきたパスワードファイルも問題なく自動的に読み込まれていることが確認出来ています。もし、この段階でパスワードファイルが読み込まれていない場合は、演習4の解説を読んでみてくださいね。
何となく解説が簡素化してきたような気がしますが、気にしない気にしない。。。と言うことで、いざ、duplicateコマンドを実行してみましょう！
演習8. 補助インスタンスを起動したDBサーバー上で、RMANユーティリティでターゲット接続無し、カタログ接続無しで補助インスタンスへ接続し、バックアップ・ファイルだけを用いたスタンバイ・データベースの作成を実行してください。
$ export ORACLE_SID=dbm02s1 $ rman auxiliary / RMAN> duplicate database 'DBM02' DBID 1036374939 for standby backup location '+DATA01/BKUP/' dorecover spfile set DB_UNIQUE_NAME='dbm02s' set LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=dbm02s ALTERNATE=LOG_ARCHIVE_DEST_2' set LOG_ARCHIVE_DEST_2='location=+DATA01 valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dbm02s ALTERNATE=LOG_ARCHIVE_DEST_1' set LOG_ARCHIVE_DEST_3='SERVICE=DBM02 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbm02' set FAL_SERVER='DBM02' set FAL_CLIENT='DBM02S' set AUDIT_FILE_DEST='/u01/app/oracle/admin/dbm02s/adump' set INSTANCE_NUMBER='1' set CONTROL_FILES='+DATA01/DBM02S/CONTROLFILE/standby_controlfile.ctl' ;
はい、無事にDUPLICATEコマンドの実行が完了できた方、おめでとうございます！作成されたデータベースの中身を未だ確認はしてはいませんが、コマンドが正常終了しているので問題無く作成されていることでしょう。もし失敗してしまった方、慌てる必要はありませんよ。なぜならば、本番データベースには接続していませんので。( ← 前回57回の連載でのduplicateコマンド成功時の解説から複製してみた）
前回の解説文を複製して楽をしつつ、今回の私のDUPLICATEコマンドについて解説しておきます。コチラのマニュアルも参考にしてみてください。
$ export ORACLE_SID=dbm02s1
$ rman auxiliary /
- RMANユーティリティを起動していますが、TARGET句によるTARGET接続無し、CATALOG接続も無く、あくまで、環境変数ORACLE＿SIDに設定した補助インスタンスdbm02s1への接続しかしていません。
RMAN>
duplicate database ‘DBM02’ DBID 1036374939 for standby
- Primary Databaseとなる、ソース（複製元）データベース名とDBIDを指定し、「for standby」句を指定することで、Data Guard Physical Standby Databaseの作成を指示しています。
ソース・データベースのDBIDは、演習0でRMANユーティリティを起動した際に出力されているものをメモしておくと便利でしょう。もちろん、ソース・データベースへ接続して、V$DATABASEビューで確認しても良いです。
backup location ‘+DATA01/BKUP/’
- この句で、バックアップが配置されている場所を指定します。今回は、’+DATA01/BKUP/’直下に、バックアップ一式を配置しておきましたよね。
dorecover
- 作成されたStandby Databaseをリカバリしてくれるオプションですが、指定しておきましょう。（個人的に指定しなかったことがない）
spfile
- 演習6の解説で述べた通り、この句を指定しておくことで、バックアップ内のSPFILEがリストアされます。
- この句を指定したにも関わらず、BACKUP LOCATION内にSPFILEのバックアップが存在しない場合、duplicateコマンドが失敗します。
- SPFILE以外にもコピーされるファイルがありますが、その一覧は、こちらに記載されています。
set <Parameter Name> = <Value>
- リストアされたSPFILE内に設定されている初期化パラメータを上書きしたい場合に、パラメータ毎に指定します。
- DB_UNIQUE_NAME、CONTROL_FILES、FAL_SERVERパラメータ辺りは、Standby Database用に必ず上書きしましょう。
ちなみに、私のDUPLICATEコマンドには含めていませんが、Primary DatabaseとStandby Databaseで利用するASMディスク・グループ名が異なる場合は、DB_FILE_NAME_CONVERTやLOG_FILE_NAME_CONVERTパラメータの指定して、複製されるデータファイルのパスを変更する必要があります。ただし、この句では、ASMディスク・グループ名しか変換出来ず、そのディレクトリ名は変換することは不可能である点はご留意ください。
なお、今回のDUPLICATEコマンド実行中は補助インスタンスに対するオペレーションしか実行されませんので、とても安心感がありますね。また、その過程において、SPFILEを作成したり、制御ファイルをリストアして再起動したり、データファイルをリストアしてリカバリが自動的に行われていきます。これらのRMANの出力を見ていると、実際に実行されるコマンドを確認出来るので、おおよその流れは把握することが出来ますので、興味のある方は、是非ともRMANの出力メッセージを追ってみてください。
演習9. 複製されたデータベースの名前、インスタンス名、ロールを確認してください。必要に応じて、Flashback Loggingも有効化しておきましょう。
$ export ORACLE_SID=dbm02s1 $ sqlplus / as sysdba SQL> select NAME, DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from V$DATABASE ; NAME DB_UNIQU OPEN_MODE DATABASE_ROLE FLASHBACK_ON --------- -------- -------------------- ---------------- ------------------ DBM02 dbm02s MOUNTED PHYSICAL STANDBY NO -- Flashback Loggingの有効化 (必須ではないですが、柴田推奨） alter database flashback on ; select NAME, DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE, FLASHBACK_ON from V$DATABASE ; NAME DB_UNIQU OPEN_MODE DATABASE_ROLE FLASHBACK_ON --------- -------- -------------------- ---------------- ------------------ DBM02 dbm02s MOUNTED PHYSICAL STANDBY YES
如何でしょうか？見事に、Phsycal Standby Databaseが完成していますね！わーい。
Primary Database側でFlashback Loggingを有効化していたとしても、完成したStandby DatabaseはFlashback Loggingが無効化されていますので、必要に応じて、忘れないうちに有効化しておきましょう。演習1の解説でも述べたように、Data Guard環境であれば、有効化しておいた方がメリットが大きいでしょう。
この時点では、実は2ノードRACデータベースとしては稼働しておらず、あくまで、シングル・インスタンスなStandby Databaseです。これをここから2ノードRAC化していきますので、もう少しお付き合いください。
演習10. Standby DatabaseのSPFileからPFILEを生成して適切に編集した後、ASMディスク・グループ上にSPFILEを作成してください。
SQL> -- SPFILEから編集用PFILEを生成 create pfile='/tmp/pfileSTB.ora' from spfile ; shutdown immediate ; $ vi /tmp/pfileSTB.ora ----- ### 先頭に[*]が付いていて、かつ、次のパラメータが存在している場合は削除 *.instance_number *.thread *.undo_tablespace ### 次のように、先頭に付いているPrimary Databaseのインスタンス名[dbm021][dbm022]をStandby Databaseのインスタンス名[dbm02s1][dbm02s2]に変更 dbm021.undo_tablespace='UNDOTBS1' --> dbm02s1.undo_tablespace='UNDOTBS1' dbm022.undo_tablespace='UNDOTBS2' --> dbm02s2.undo_tablespace='UNDOTBS2' dbm021.thread=1 --> dbm02s1.thread=1 dbm022.thread=2 --> dbm02s2.thread=2 dbm021.instance_number=1 --> dbm02s1.instance_number=1 dbm022.instance_number=2 --> dbm02s1.instance_number=2 dbm021.cluster_interconnects='xxxx' --> dbm02s1.cluster_interconnects='xxxx' dbm022.cluster_interconnects='yyyy' --> dbm02s2.cluster_interconnects='yyyy' ----- ### SPFILE格納用ディレクトリを作成 ASMCMD> mkdir +DATA01/dbm02s/parameterfile SQL> -- SPFILEをASMディスク・グループ上に作成 create spfile='+DATA01/dbm02s/parameterfile/spfiledbm02s.ora' from pfile='/tmp/pfileSTB.ora' ; ### RACを構成する全ノード上において、デフォルトで読み込まれるPFILEを作成し、SPFILEのパスを記述しておく <standby_db_node#1> $ rm -rf $ORACLE_HOME/dbs/spfiledbm02s1.ora $ echo "SPFILE='+DATA01/dbm02s/parameterfile/spfiledbm02s.ora'" > $ORACLE_HOME/dbs/initdbm02s1.ora" <standby_db_node#2> $ rm -rf $ORACLE_HOME/dbs/spfiledbm02s2.ora $ echo "SPFILE='+DATA01/dbm02s/parameterfile/spfiledbm02s.ora'" > $ORACLE_HOME/dbs/initdbm02s2.ora"
さあ、ラストスパートです！じゃんじゃんコマンドを打ちまくっていきましょう。
慎重な作業が必要となるのが、初期化パラメータファイルの編集作業となります。コマンド実行例内にもコメントを記載していますので、そちらを参考にしてみてください。SPFILEはPrimary Databaseのバックアップからリストアされたものなので、Primary Databaseのインスタンス名が記載されています。このままでは、それらの初期化パラメータは、Standby Databaseインスタンス上では有効化されないので、指示通りにStandby Databaseのインスタンス名に変更する作業は絶対に実施してくださいね。
演習11. Standby DatabaseのPassword Fileも、Standby Databaseからアクセス可能なASMディスク・グループ上にコピーしてください。
ASMCMD> mkdir +DATA01/dbm02s/password cp /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/orapwdbm02s1 +DATA01/dbm02s/password/orapwdbm02s
はい、大丈夫ですよね？一点補足するならば、このASMディスク・グループ上のパスワードファイルの名前は何でも良いです。演習4でファイル名に拘ったのは、インスタンス起動時に自動的に読み込まれるようにするためであって、この演習でASMディスク・グループ上にコピーしたパスワードファイルは、その目的ではありませんので。あくまで次の演習12でCRSリソースとしてデータベース・リソースを登録するのですが、Oracle Clusterwareが認識しておくべきパスワード・ファイルとなります。
演習12. srvctlユーティリティを使用して、作成したPhysical Standby DatabaseをCRSリソースとしてOracle Clusterwareに登録してください。
$ srvctl add database -db dbm02s -oraclehome /u01/app/oracle/product/19.0.0.0/dbhome_1 -dbtype RAC -dbname dbm02 -role physical_standby -spfile "+data01/dbm02s/parameterfile/spfiledbm02s.ora" -pwfile "+data01/dbm02s/password/orapwdbm02s" $ srvctl add instance -db dbm02s -instance dbm02s1 -node <standby_db_node#1> $ srvctl add instance -db dbm02s -instance dbm02s2 -node <standby_db_node#1>
RACをご利用されたことがある方でも、もしかしたら実行したことが無いかもしれませんね。DBCAユーティリティ等でRACデータベースを作成したりすると、自動的にCRSリソースとして登録されたはずなので。でも、そんな難しく考えなくて良いです。
まずは、「add database」でデータベース・リソースを登録して、そのデータベース・リソースに対して、全インスタンス（今回は2ノードRACなので2つのインスタンス）を追加すれば良いだけです。データベース・リソースを登録する際に、演習10と11でASMディスク・グループ上に用意したSPFILEとPassword Fileのパスを指定しますし、「-role」オプションには「physical_standby」を設定しておきましょう。
演習13. Physical Standby DatabaseをMOUNTモードで起動し、Redo適用プロセス（MRP）を起動してください。
### MOUNTモードで起動（全インスタンスが起動） $ srvctl start database -db dbm02s -startoption mount SQL> -- MRPプロセスの起動（Redo適用開始） alter database recover managed standby database disconnect from session ; -- MRPプロセスの起動状況を確認 set linesize 170 pages 50000 tab off trim on col VALUE for a32 select PROCESS,PID,STATUS,THREAD#,SEQUENCE# from V$MANAGED_STANDBY where PROCESS='MRP0'; PROCESS PID STATUS THREAD# SEQUENCE# --------- ------------------------ ------------ ---------- ---------- MRP0 374286 APPLYING_LOG 2 155 -- Redo転送のラグ、適用ラグを確認 select SOURCE_DB_UNIQUE_NAME, NAME, VALUE, UNIT from V$DATAGUARD_STATS ; SOURCE_DB_UNIQUE_NAME NAME VALUE UNIT -------------------------------- -------------------------------- -------------------------------- ------------------------------ transport lag +00 00:00:00 day(2) to second(0) interval apply lag +00 00:00:00 day(2) to second(0) interval apply finish time day(2) to second(3) interval estimated startup time 26 second
Data Guardの操作の話に入り始めていますが、深くは次回以降にするとして、今回はさらっと解説します。（既に5時間ぶっ通しで原稿を書いているので・・・）
srvctl start databaseコマンドで、Standby Databaseの全インスタンスをマウント・モードで起動します。
次に、MRPプロセスを起動させるalter database recover managed standby…コマンドを実行していますが、このプロセスが起動することで、受信済みのRedoデータの適用を開始します。つまりは、「同期を開始する」と言う意味ですね。「このMRPプロセスが起動していないとData Guardとしては意味がないの？」と言う質問があるかもしれませんが、答えは「そうではない」です。
MRPプロセスが起動していなくても、Standby Databaseインスタンスが一つでも起動していれば、Primary Databaseの全インスタンスからのRedoデータは受信していますので、Primary Database側が障害でダウンしても、その直前までに生成されたRedoデータは、Standby側で受信済みです（Redo転送が正常であれば）。つまりは、受信済みのRedoデータを適用さえすれば、ユーザーデータの更新が失われることは無いのです。MRPプロセスは、あくまで受信済みのRedoデータの適用を担当する役割ですね。
MRPの稼働状況を見極めるために、私は、V$MANAGED_STANDBYのSTATUS列の値を確認しています。「APPLYING＿LOG」となっていれば、まず問題はないですね。
また、Redo転送が遅いのか、Redo適用が遅いのかを判断するためには、V$DATAGUARD_STATSを確認しますので、こちらも覚えておいてくださいね。
あ、ちなみに、MRPプロセスは、基本的にはStandby Database側の一つのインスタンス上で稼働させて、一つのインスタンス上でRedoデータの適用を行います。しかし、それではRedo適用のスピードが追い付かないケースに対応するために、最近、Standby Database側の全インスタンスを使ってRedo適用させるマルチ・インスタンス・リカバリ？を選択できるように機能拡張されています。とはいえ、一つのインスタンス上でRedo適用させるだけでも十分な適用スピード（H/W性能にも依存しますが、2014年ぐらいだったかに、200～300MB/秒以上のRedo適用性能を経験したことがあります）なので、マルチ・インスタンス・リカバリを使わざるを得ないケースは、あまり多くは無いかと個人的には思います。Primary Database側のRedo生成スピードが100MB/秒を超えるワークロードはありますけど、あまり見ないのが正直なところですね。
演習14. 今更ですが、Primary Database上で、Data Guard構成が正常に組まれているかを確認してください。
### Primary Database側で確認
SQL>
set linesize 250 pages 5000 tab off
col FORCE_LOGGING for a6
col FLASHBACK_ON for a6
select DBID, NAME, DB_UNIQUE_NAME, DATABASE_ROLE, PROTECTION_MODE, CURRENT_SCN, FLASHBACK_ON, FORCE_LOGGING from V$DATABASE ;
DBID NAME DB_UNIQU DATABASE_ROLE PROTECTION_MODE CURRENT_SCN FLASHB FORCE_
---------- --------- -------- ---------------- -------------------- ----------- ------ ------
1036374939 DBM02 dbm02 PRIMARY MAXIMUM PERFORMANCE 154454851 YES YES
select * from V$DATAGUARD_CONFIG ;
DB_UNIQUE_NAME PARENT_DBUN DEST_ROLE CURRENT_SCN CON_ID
------------------------------ ------------------------------ ----------------- ----------- ----------
dbm02 NONE PRIMARY DATABASE 154427249 0
dbm02s dbm02 PHYSICAL STANDBY 154427124 0
set linesize 200 pages 5000 tab off
col DEST_NAME for a20
col DB_UNIQUE_NAME for a8
col TARGET for a8
col RECOVERY_MODE for a25
col GAP_STATUS for a10
select A.DEST_ID, A.DEST_NAME, A.DB_UNIQUE_NAME, B.DATABASE_MODE, B.RECOVERY_MODE,
A.TRANSMIT_MODE, A.AFFIRM, A.TARGET, A.STATUS, A.LOG_SEQUENCE, A.APPLIED_SCN,
B.GAP_STATUS, A.ERROR, B.ERROR
from V$ARCHIVE_DEST A, V$ARCHIVE_DEST_STATUS B
where A.DEST_ID=B.DEST_ID
and A.TARGET in ('STANDBY', 'REMOTE') ;
DEST_ID DEST_NAME DB_UNIQU DATABASE_MODE RECOVERY_MODE TRANSMIT_MOD AFF TARGET STATUS LOG_SEQUENCE APPLIED_SCN GAP_STATUS
---------- -------------------- -------- --------------- ------------------------- ------------ --- -------- --------- ------------ ----------- ----------
ERROR ERROR
----------------------------------------------------------------- -----------------------------------------------------------------
3 LOG_ARCHIVE_DEST_3 dbm02s MOUNTED-STANDBY MANAGED REAL TIME APPLY ASYNCHRONOUS NO STANDBY VALID 151 154445440 NO GAP
set linesize 200 pages 5000 tab off
col PID for a10
select NAME, PID, TYPE, ROLE, ACTION, CLIENT_PID, CLIENT_ROLE, THREAD#, SEQUENCE#, BLOCK#, BLOCK_COUNT, DELAY_MINS, DEST_ID, DBID, DGID, INSTANCE
from V$DATAGUARD_PROCESS
order by 1 ;
NAME PID TYP ROLE ACTION CLIENT_PID CLIENT_ROLE THREAD# SEQUENCE# BLOCK# BLOCK_COUNT DELAY_MINS DEST_ID DBID DGID INSTANCE
----- ---------- --- ------------------------ ------------ ---------- ---------------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ---------- ----------
ARC0 133590 KSB archive local IDLE 0 none 0 0 0 0 0 0 0 0 0
ARC1 133772 KSB archive redo IDLE 0 none 0 0 0 0 0 0 0 0 0
ARC2 133958 KSB archive redo IDLE 0 none 0 0 0 0 0 0 0 0 0
ARC3 134109 KSB archive redo IDLE 0 none 0 0 0 0 0 0 0 0 0
LGWR 127144 KSB log writer IDLE 0 none 0 0 0 0 0 0 0 0 0
TMON 127249 KSB redo transport monitor IDLE 0 none 0 0 0 0 0 0 0 0 0
TT00 133535 KSV gap manager IDLE 0 none 1 151 0 0 0 3 0 0 0
TT01 133678 KSV redo transport timer IDLE 0 none 0 0 0 0 0 0 0 0 0
TT02 134333 KSV async ORL multi OPENING 0 none 1 151 0 0 0 3 1036374939 0 0
TT03 134395 KSV heartbeat redo informer IDLE 0 none 0 0 0 0 0 0 0 0 0
TT05 134468 KSV async ORL single WRITING 0 none 1 151 130295 1 0 3 1036374939 0 0
もう残りの体力が無いので、細かな解説は割愛させて頂きますが（将来、書き直すかもしれませんが）、上記で実行しているSQLを、皆さんのPC内に保存しおいてもらえると、とても便利かなと思っています。ここまで体験してきて頂いた方であれば、コマンドと結果を見て頂ければ、どんな情報が出力されているのかをご理解いただけると信じています。
演習15. MRPプロセスを起動してるStandby Database上で、V$DATAGUARD_PROCESSビューに問合せてください。
### Standby Database側で実行 SQL> set linesize 200 pages 5000 tab off col PID for a10 select NAME, PID, TYPE, ROLE, ACTION, CLIENT_PID, CLIENT_ROLE, THREAD#, SEQUENCE#, BLOCK#, BLOCK_COUNT, DELAY_MINS, DEST_ID, DBID, DGID, INSTANCE from V$DATAGUARD_PROCESS order by 1 ;
最後の演習問題は、演習14で実行した最後のSQLをStandby Database側でも実行してみよう。と言うものです。正直、オマケです。出力される行数が多いので、こちらに結果は掲載しておりませんの、ご興味のある方は、是非、ご自身の環境にて試してみてくださいねー
さてさて、如何でしたでしょうか？
Data Guard構成の組み方は、今回ご紹介した方法だけではなく様々な方法がありますが、私が良く利用する方法を今回はご紹介させて頂きました。滅茶苦茶長い回となってしまいましたが、最後までお付き合い頂きまして大変ありがとうございました。少しでも皆様のデータベース管理作業の参考になれば大変嬉しいです。演習問題15個と言うのは、過去最大数かもしれませんし、解説も頑張らせて頂いたつもりですが、完成した記事を見ると、意外と自分が思っていたよりも短かったりするのは何故ですかね？？？
と言う子で、ここまで書き切ったところで、過去、何故、私自身、Data Guardに関連する記事を書いていなかったのかを理解できたような気がします。おそらく、「書き出したら止まらない」「書きたいことが一杯あり過ぎて収集が付かない」「大変」と、過去の自分は逃げていたのでしょうね。しかし、今回ようやくData Guardの構築をご紹介できたことで、次回以降の3~4回は、このData Guardネタでお届けできればと考えておりますので、次回も楽しみにしていてくださいね！それでは、また次回お会いしましょう！