しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。”しばちょう”こと柴田長（しばた つかさ）です。
Oracle Databaseの高可用性機能の代表とでも言えるData Guardの記事に突入し、前回の第58回の連載では、Primary Databaseへの影響を極力排除した方法を使ったPhysical Standby Databaseの作成を試してみましたが、いかがでしたか？
最終的なduplicateコマンドを実行するまでに、RMANバックアップを取得して、Standby Databaseが稼働するサーバー側へコピーしておく等、必要な準備が少し多い印象を持った方もいらっしゃるかもしれませんね。
そこで、今回ご紹介するPhysical Standby Datatabaseの作成方法は、duplicateコマンド実行中に、稼働中のPrimary Databaseへアクセスして必要なデータファイルを読み取るので、事前にRMANバックアップを取得していない環境でも利用できる方式を試し、その手順の違いについて体験してみましょう。（第58回の手順と比較して、前述の通り事前のRMANバックアップやファイル転送が必要無い点が楽になりますが、補助インスタンスへの接続設定が追加で必要になります。それ以外の手順はほとんど同じですー）
前回の再掲となりますので、次の段落は読み飛ばして頂いて構いません。
Data Guardとは、簡単に言えば、本番データベース（Primary Database）の完全なコピー・データベース（Standby Database）を提供する機能です。Primary Databaseで生成されたRedoデータをStandby Databaseへ自動的に転送+適用することで、常に同じデータの状態を維持させることが可能です。よって、万が一、Primary Databaseに障害が発生しても、Standby Database側をPrimaryロールへ昇格させることで本番システムのダウンタイムを極小化することが可能となりますし、パッチ適用時に順番に適用することができるので、メンテナンスに伴うシステム停止時間も短くすることが可能になるでしょう。Data Guardのメリットや、ストレージのリモート・コピー機能に対する優位性等は非常に多いのですが、それは私の過去の講演資料を参照してみてください。
私は、Oracle Database 19c Enterprise Editionのデータベースを使って以下の演習を実施しています。DBRU19.8.0上のCDBの2ノードRACデータベースにおいて、データファイル格納用の+DATA01と、バックアップ関連ファイル格納用の+RECO01という、2つのASMディスク・グループがある環境で、動作確認を行っています。
また、下記のDuplicateコマンドの詳細については再々掲となりますが、今回は赤文字で示している、複製するデータベースのタイプはType2で、実行方式はA-1となります。
- 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. Primary Databaseにおいて、RMANバックアップが一切ない状態であることを確認してください。（RMANバックアップの事前取得不要であることを証明する目的なので、実際にバックアップを削除する必要はありません）
### ソース・データベース（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 ; # データファイルのコピーバックアップの存在確認 list datafilecopy all ; specification does not match any datafile copy in the repository # 各種バックアップの存在確認 list backup summary ; specification does not match any backup in the repository
繰り返しになりますが、あくまで今回体験する手順として「事前にRMANバックアップが必要無い」ことを証明する目的で、こちらの演習を試して頂きました。なので、皆さんのデータベース環境上にRMANバックアップが存在していたとしても、削除する必要はありませんのでご安心ください。（もちろん、本番環境でのバックアップはシステムの高可用性を維持する大切なものなので、不用意にRMANバックアップを削除することは、私は責任を取れませんので、お止めください）
この演習で登場した2つのLISTコマンドは使用頻度が非常に高いので、絶対に知っておくべきですし、何も見なくてもタイピング出来るとカッコいいですね。
では、指の体操はこれぐらいにして、本編へ進んでいきましょう。
演習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 201 Next log sequence to archive 204 Current log sequence 204 -- Force Loggingの確認 select FORCE_LOGGING from V$DATABASE ; FORCE_LOGGING --------------------------------------- YES -- 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; 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 -- 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
前回（第58回の連載）の記事を読んで頂いている方は復習になったかと思います。（今回は、ほとんど復習がメインになりそうです・・・すいません）私が今回利用した環境は、既にData Guard構成を組む前のPrimary Databaseの設定が全て行われている環境（前回使った環境）なので、何も変更する必要がありません。とはいえ、ケアレスミスを避ける目的で、念のための確認をする癖は付けておきましょう。
もしも、各情報の意味や設定の目的が不明な方は、是非、前回（第58回の連載）の演習2をご確認くださいね。
演習2. 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 DBM02 2 fal_client DBM02 1 fal_server DBM02S 2 fal_server DBM02S 1 log_archive_config DG_CONFIG=(dbm02,dbm02s) 2 log_archive_config DG_CONFIG=(dbm02,dbm02s) 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 SERVICE=DBM02S ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbm02s 2 log_archive_dest_3 SERVICE=DBM02S ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbm02s 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 AUTO 2 standby_file_management AUTO
はい、「変更してください」と書きましたが、私の環境は前述の通り、変更する必要がありませんでしたので、変更後のパラメータ設定値を上記には掲載しております。ちなみに、Data Guard環境として特に変更が必要となるパラメータを次にあげておきますが、各パラメータの説明は、前回（第58回の連載）の演習3をご確認ください。（今回の記事は、大分楽をさせてもらっていてゴメンナサイ）
- LOG_ARCHIVE_CONFIG=’DG_CONFIG=(dbm02,dbm02s)’
- LOG_ARCHIVE_DEST_3=’SERVICE=DBM02S ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbm02s’
- FAL_CLIENT=’DBM02′
- FAL_SERVER=’DBM02S’
- STANDBY_FILE_MANAGEMENT=’AUTO’
演習3. 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
こちらの演習問題と実行例は、完全に前回（第58回の連載）の演習4と同じです。Data Guard Physical Standby Databaseでは、Primary Databaseで使用しているパスワード・ファイルと完全に同じコピーを使わせる必要がありますので、ここでキッチリとコピーしておきましょう。決して、Primary側のパスワードと同じパスワードを指定した新しいパスワード・ファイルをStandby側で独自に作成しないでくださいね。
演習4. 念のため、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"
こちらも完全に前回（第58回の連載）の演習5と同じです。って、前回の繰り返しばかりじゃないかーって、そろそろ突っ込んで頂いて構いません。言い訳はしません。はい、その通りです。演習6まで（演習6も含む）は、RMANバックアップの取得と転送以外は、前回と全く同じ手順なのですね。なので、もう少しの間、復習がてら読んでいただくか、前回と異なる手順が登場する演習7の少し前まで読み飛ばして頂いても構いません。（ご案内が遅くなりまして、申し訳ございませんデス）
演習5. 補助インスタンス用の初期化パラメータ・ファイルを作成してください。
$ vi /tmp/pfileAUX.ora *.DB_NAME='dbm02' *.DB_UNIQUE_NAME='dbm02s' *.DB_BLOCK_SIZE=8192 *.MEMORY_TARGET=4g *.REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
こちらも完全に前回（第58回の連載）の演習6と同じです。が、少しコメントさせてくださいね。
上記のたった5つの初期化パラメータだけで、補助インスタンスを起動させることができます。しかし、もちろん、Standby Database用の初期化パラメータとしては不足しています。では、「いつ、Standby Database用の初期化パラメータ・ファイルを用意するのか？」と言う質問を受けたとしたら、あなたは何と答えますか？
そう、答えは「用意しなくて良い」ですね。覚えていましたかね？ duplicateコマンドでは「SPFILE」オプションを指定することが可能であり、このオプションを使用することで（今回の例では）Primary DatabaseのSPFILEをベースとして、Standby Database用のSPFILEが作成されるからですね。とはいえ、DB_NAMEとDB_UNIQUE_NAMEパラメータだけは、この補助インスタンス用の初期化パラメータ・ファイル内で、きっちりとStandby Database用に設定しておきましょう。
演習6. Standby Databaseを稼働させるDBサーバー1号機上で補助インスタンスをNOMOUNTモードで起動し、Password Fileを読み込んでいることを確認してください。
### Standby Databaseを稼働させるDBサーバー1号機上での操作 $ 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
こちらの演習も、完全に前回（第58回の連載）の演習7と同じですね。なので、特に解説は不要かと思います。
前回は、この後、RMANユーティリティで補助インスタンスへのみ接続し、duplicateコマンドの実行すれば良かったのですが、今回の手順では「静的リスナーの構成」と「その静的リスナー経由で補助インスタンスへ接続できる確認」が追加されています。その理由に関して、少し解説させてください。
簡単に言ってしまえば、今回の手順でduplicateコマンドを実行する際にどのデータベースへ接続しておくべきか？という観点で考えて頂ければ答えがなんとなくわかると思います。
この後の演習8の問題文を先に掲載してしまいますが、「RMANユーティリティでPrimary Databaseに対してターゲット接続し、補助インスタンスへも同時に接続してください。」であり、つまり、2つのデータベースに対して同時に接続しなければなりません。私も含め、DB管理者の皆様がLinux/Unixサーバー上で多用する「sqlplus / as sysdba」コマンドがありますが、このコマンドでは環境変数「ORACLE_SID」にセットされているデータベース・インスタンスへネットワーク・リスナーを使用せずに、ローカル接続（別名、Beq接続、ベク接続、Bequeathプロトコルでの接続）することになります。しかし、同時に複数のインスタンス名をORACLE_SIDにセットすることは、私が知る限り不可能なので、この演習8の同時接続を実現するためには、一つはローカル接続を利用するにしても、もう一つはリスナー経由で接続する必要があるのですね。
ちなみに、前回（第58回の連載）は、Primary Databaseへの接続無しで、補助インスタンスへ接続する方式だったので、Standby Databaseを構築するサーバー側でRMANユーティリティを起動して、補助インスタンスへリスナーを使用しないローカル接続を使用していました。よって、リスナーの構成が必要無かったのですね。
また、最近の主流は動的リスナーと言って、特にリスナーの設定をしていなくても、そのサーバー上で起動したDBインスタンスの持つサービスが起動すると、自動的にリスナーに登録される仕組みを利用されていると思います。しかし、これは、「サービスが起動する」=「インスタンスがオープン状態」を意味します。今回の補助インスタンスはNOMOUNTモードで起動しているので、オープンしていませんね。よって、動的リスナーには登録されていませんので、静的リスナーに事前登録をする必要があるわけです。
と言うことで、次の演習では、静的リスナーの構成と接続確認を行ってみましょう。
演習7. 補助インスタンスへPrimary Databaseから接続するためだけの目的で、静的リスナーを構成し、接続確認を行ってください。
##### 補助インスタンスを起動したStandby Databaseを稼働させるDBサーバー1号機上での操作 $ vi $ORACLE_HOME/network/admin/listener.ora --- LISTENER_AUX= (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = <Standby DB Host Name>)(PORT = 1530)(IP = FIRST)) ) ) SID_LIST_LISTENER_AUX = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = dbm02s) (ORACLE_HOME = /u01/app/oracle/product/19.0.0.0/dbhome_1) (SID_NAME = dbm02s1) ) ) --- $ lsnrctl start LISTENER_AUX LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 08-SEP-2021 15:40:43 Copyright (c) 1991, 2020, Oracle. All rights reserved. Starting /u01/app/oracle/product/19.0.0.0/dbhome_1/bin/tnslsnr: please wait... TNSLSNR for Linux: Version 19.0.0.0.0 - Production System parameter file is /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/listener.ora Log messages written to /u01/app/oracle/diag/tnslsnr/<Standby DB Host Name>/listener_aux/alert/log.xml Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xxx.yyy.zzz.70)(PORT=1530))) Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<Standby DB Host Name>)(PORT=1530)(IP=FIRST))) STATUS of the LISTENER ------------------------ Alias LISTENER_AUX Version TNSLSNR for Linux: Version 19.0.0.0.0 - Production Start Date 08-SEP-2021 15:40:43 Uptime 0 days 0 hr. 0 min. 0 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/listener.ora Listener Log File /u01/app/oracle/diag/tnslsnr/<Standby DB Host Name>/listener_aux/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xxx.yyy.zzz.70)(PORT=1530))) Services Summary... Service "dbm02s" has 1 instance(s). Instance "dbm02s1", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully
如何ですか？初めて静的リスナーを構成した方もいらっしゃると思うので、少しだけ解説しておきます。
リスナーの定義ファイルlistner.oraは、$ORACLE_HOME/network/adminディレクトリの下にあります。存在していなければ、作成しちゃってください。もし存在していれば、追記する形で上記の設定を組み込んでくださいね。
私の例では、新規リスナーである、LISTENER_AUXのエントリをまず追加しています。ここで、このLISTENER_AUXが起動した際にリッスンするIPアドレス（ホスト名でもOK）とポート番号を定義します。もちろん、Primary Databaseサーバー上のOracleプロセスから通信可能なIPアドレス/ポート番号を指定してくださいね。
次に、SID_LIST_LISTENER_AUXと言う名前のエントリーがありますが、これは、「SID_LIST_<リスナー名>」とご認識ください。すると、接頭辞が「SID_LIST」になっていますから、このエントリー内に静的にリッスンすべきインスタンス名をリストしておけば良さそうな香りがしてきますね。と言うことで、補助インスタンスのGLOBAL_NAME（デフォルト・サービス名）、ORACLE_HOME、SID_NAME（インスタンス名）の3つのパラメータをセットしています。このリスナーへの接続失敗する例としては、GLOBAL_NAME（デフォルト・サービス名）に、インスタンス名を設定してしまっているケースが良く見られますのでご注意ください。非RAC（シングル）データベースでは、GLOBAL＿NAMEにインスタンス名を指定しても問題ないケースがほとんどですが、RACデータベースの場合、データベース名とインスタンス名は必ず異なります。RACを構成するインスタンス名はデータベース名にインスタンス番号が付いたものになるので。
konolistener.oraの編集が終わったら、後は、「lsnrctl start <リスナー名>」で追加したリスナーを起動させてみましょう。グチャグチャと色々出力されますが、重要なのは最後の方に出力された次の2行ですね。GLOBAL_NAMEとSID_NAMEに設定したサービス名とインスタンス名が出力されていれば、問題ありません。
Service “dbm02s” has 1 instance(s).
Instance “dbm02s1“, status UNKNOWN, has 1 handler(s) for this service…
ちなみに、ちょっとお恥ずかしい話になりますが、マニュアル「バックアップおよびリカバリ・ユーザーズ・ガイド」には、まさにこの連載にうってつけのセクション「25.3.4 ソース・データベースと補助インスタンス間のOracle Net接続の確立」が存在しますが、ここから更に、静的リスナーの登録に関して、次の文章と共に別の資料へのリンクが張られています。しかし・・・
Oracle Netの接続を確立し静的リスナーを設定する手順
データベースに接続するようにクライアントを構成し、リスナーの静的サービス情報を追加するには、Oracle Database管理者ガイドの手順を実行します。
実は、「Oracle Database管理者ガイド」ではなく、「Net Services管理者ガイド」の間違いだと私は思います。なぜならば、Net Services管理者ガイドにしか静的なサービス登録に関する説明を見つからなかったからです。うーん。。。恥ずかしい。
少し説明が長くなってしまいましたが、構成した静的リスナーを経由して、補助インスタンスへ接続できることも確認しておきましょう。
### Primary Databaseサーバー側での操作 $ vi $ORACLE_HOME/network/admin/tnsnames.ora AUX = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = <Standby DB Host Name>)(PORT = 1531)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbm02s) (INSTANCE_NAME = dbm02s1) ) ) $ sqlplus sys/xxxxxxx@AUX as sysdba SQL> select INSTANCE_NAME from V$INSTANCE ; INSTANCE_NAME ------------- dbm02s1
リスナー経由で接続する方式はいくつかありますが、今回はオーソドックスに、tnsnames.oraファイルに接続設定を追加してみました。こちらは特に問題ないですよね？個人的に気に入らないのは、listener.ora内でサービス名を設定するのはGLOBAL_NAMEパラメータでしたけど、tnsnames.oraの場合はそのまんまSERVICE_NAMEなんですよね。これまたお恥ずかしい限りです・・・。Oracle Databaseのお茶目な一面として覚えておいてください。
でもって、補助インスタンスに対してsqlplus で接続できましたかね？ここで指定しているSYSユーザーのパスワードは、もちろん、Primary Databaseの物と同じですよね。パスワード・ファイルをコピーしたんだもの。
と言うことで、いよいよ、お待ちかねのduplicateコマンドを次の演習で実行してみましょう。
演習8. 補助インスタンスを起動したDBサーバー上で、RMANユーティリティでPrimary Databaseに対してターゲット接続し、補助インスタンスへも同時に接続してください。その後、バックアップ・ファイルだけを用いたスタンバイ・データベースの作成を実行してください。
### Primary Databaseサーバー上での操作 $ export ORACLE_SID=dbm021 $ rman target / auxiliary sys/xxxxxxx@AUX connected to target database: DBM02 (DBID=1036374939) connected to auxiliary database: DBM02s (not mounted) RMAN> duplicate target database for standby from active database 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' ;
RMANユーティリティ起動時に、Primary Databaseをターゲットとしてローカル接続しつつ、auxiliaryオプションを使用して補助インスタンスに対してリスナー経由で接続しています。同時接続、面白いですねー！あとは、duplicateコマンドを実行するわけですが、こちらについて解説しておきますが、前回（第58回の連載）との大きな違いは、バックアップの置き場所を指定する「backup location」句が無くなっているという点ですね。
$ export ORACLE_SID=dbm021
- 繰り返しになりますが、Primary Databaseをターゲットとして接続するため、環境変数ORACLE_SIDにはこの操作を行っているサーバー上で稼働しているPrimary Databaseインスタンス名を指定しています。
$ rman target / auxiliary sys/xxxxxxx@AUX
- RMANユーティリティを起動しています。TARGET句によるTARGET接続先はローカルのPrimary Databaseのインスタンス（ORACLE_SIDに設定されているインスタンス名）、auxiliary句による補助インスタンス接続先はリスナー経由としています。
- RMANユーティリティでのSYSユーザーで接続する際には、「as sysdba」句は不要な点にご注意ください。
RMAN>
duplicate target database for standby from active database
- 「for standby」句を指定することで、Data Guard Physical Standby Databaseの作成を指示しています。
- 「from active database」句によって、現在ターゲット接続しているデータベースをベースから必要なファイルをコピーするように指示しています。
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と完全に同じになる場合には、「NOFILENAMECHECK」オプションを指定する必要があります。しかし、データファイルをASMディスク・グループで管理されている方は、基本的にはOracle Managed Files（OMF）によって、実際のデータファイル名は採番されているので、「NOFILENAMECHECK」オプションを指定しなくても良いはずです。また、同一ホスト上でStandby Databaseを作成するときには「NOFILENAMECHECK」句は外しておいた方が良いです。その理由は・・・「NOFILENAMECHEKCK」オプションを設定していると、「RMANによってターゲット・データベースのデータファイル、一時ファイルまたはオンライン・ログが上書きされ、破損する場合があります。」とこちらのマニュアルに記載されています。逆を言えば、「NOFILENAMECHEKCK」オプションを設定していなければ、この上書きする可能性を排除出来ますので、もし不安であれば設定を外すことをお薦めします。
また、duplicate実行中にエラーが発生して処理が中断してしまった場合には、補助インスタンス側をshutdown abortして停止した後、補助インスタンスが所有している制御ファイルやデータファイルを削除してください。その後、もう一度、空の補助インスタンスをNOMOUNTモードで起動させれば、再びduplicate文を実行することが可能となります。ただし、duplicate文のエラーが発生したタイミングによっては、初期化パラメータ・ファイルが編集されてしまっている場合もありますので、改めて、演習5でご紹介した５つのパラメータに絞った初期化パラメータ・ファイルを作成し直してから、NOMOUNTモードで起動して上げてください。
くれぐれも、Primary Database側のデータファイルを削除しないよう、細心の注意を払って作業してくださいね。私は責任を取ることができませんので。そういう自分は、正直言えば、このActive Databaseを使ったduplicateコマンドで、Primary Databaseを壊したことがあります（泣笑））そういう点が、今回の手順で元も怖い部分ですし、私が、Primary Databaseへの影響を極力排除した前回（第58回の連載）の手順を先に体験して頂いた理由でもあったりします。
と言うことで、無事に今回もData GuardのPhysical Standby Databaseが作成できたでしょうか？duplicate完了後の手順は、前回の演習9以降と完全に同じなので、完全に割愛させて頂きたいと思いますので、必要に応じて、前回（第58回の連載）をご参照頂ければ幸いです。
さてさて、如何でしたでしょうか？
前回と重複する内容がほとんどだったかと思いますが、前回とは異なるduplicateコマンドでのPhysical Standby Databaseの作成を体験して頂きました。最後までお付き合い頂きまして大変ありがとうございました。少しでも皆様のデータベース管理作業の参考になれば大変嬉しいです。次回もData Guardネタでお届けできればと考えておりますので、楽しみにしていてくださいね！それでは、またお会いしましょう！