現在、既存の3ノードRACクラスターのハードウェアを交換しています。このシステムは、2ノードのRACスタンバイデータベースのプライマリでもあります。ハードウェアを交換するために、私の計画では、クラスターを一時的に6ノード構成、3台の古いサーバーと3台の新しいサーバーに拡張する予定です。新しいハードウェアでインスタンスを実行し、アプリケーションを新しいインスタンスに接続したら、古いインスタンスを停止して古いサーバーを廃止し、3ノード構成に戻します。
クラスターを6つのノードすべてに拡張した後、先週末、新しいノードで新しいインスタンスを起動しました。私の生活を楽にするために、私はこの作業にDBCAを活用しました。 DBCAを起動した後、RACデータベースで作業することを選択し、次に[インスタンス管理]、[新しいインスタンスの追加]の順に選択しました。ウィザードをウォークスルーすると、DBCAにすべての詳細を処理させます。シンプルに聞こえます。
今朝、いつものアーカイブラグレポートを受け取りました。次のようになります：
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
これを1日2回受信トレイに送信します。一目見ただけで、スタンバイがプライマリからトランザクションを受信して適用しているかどうかを判断できます。すべてのスタンバイデータベースを4時間の適用遅延に設定しました。そして、私のプライマリでは、ARCHIVE_LAG_TARGETが1時間に設定されています。これは、適用の遅延が4時間以上、5時間以内であることを意味します。上記のように、5時間の最大適用ラグを大幅に超えた2つのスタンバイデータベースがあります。上記では、1日21時間の適用ラグでスタンバイがあります！だから私はすぐに何かがおかしいことに気づきました。そして、ロケット科学者は、新しいインスタンスをプライマリに追加することがおそらく問題の原因であることを知る必要はありませんでした。
この投稿の冒頭で述べたように、私は2ノードのRACスタンバイシステムを持っています。 1つのインスタンスは「applyinstance」であり、もう1つのインスタンスは比較的アイドル状態です。適用インスタンスのアラートログに、次のエラーメッセージが表示されました。
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
スタンバイデータベースをSTANDBY_FILE_MANAGEMENT=AUTOに設定しているので、メッセージの最初の部分は意味があります。 RACデータベースに新しいインスタンスを追加するときは、そのインスタンス専用のUndoテーブルスペースを提供する必要があります。また、そのインスタンスのスレッド専用のオンラインREDOロググループも提供する必要があります。 DBCAは、ファイルの元に戻すとやり直しの構造に関する質問を具体的にしてくれました。上記のアラートログの内容では、スタンバイがデータファイル342を正常に追加したことがわかります。これは私のUndoテーブルスペースです。しかし、スタンバイはオンラインREDOログを追加できませんでした。スタンバイでオンラインREDOログを自動的に追加できるようにする場合は、OMFパラメーターを指定する必要がありますが、これはやりたくありません。オンラインREDOログ・ファイルの追加でエラーが発生したため、スタンバイがメディアのリカバリーを停止しました。スタンバイはまだログを受信しています。
Metalinkで、またはこの問題を解決する方法についてGoogle検索を行っても、あまり見つかりませんでしたが、MediaRecoveryを復旧して実行するために行った手順は次のとおりです。スタンバイデータベース上（これはapplyインスタンスで実行しましたが、RACスタンバイデータベース内のすべてのインスタンスで実行可能である必要があります）：
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Managed Recoveryが中止されたことがわかっているので、これはショックではありません。しかし、完全を期すために、このステップを含めました。現在トランザクションを適用しているスタンバイにREDOログを追加する必要がある場合は、この手順が必要になります。
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
上記はまさにプライマリで実行されたものです。プライマリで行ったのとまったく同じように、スタンバイにREDOログを追加する必要があります。プライマリに追加されたREDOロググループごとに繰り返します。プライマリRACデータベースに3つのインスタンスを追加したので、ここに3つのスレッドを追加する必要があります。
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
管理されたリカバリを開始します。これですべてが正常になり、適用インスタンスのアラートログで確認できます：
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
適用遅延が短くなっていることも確認できます。スタンバイで、次を発行します。
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
フィジカル・スタンバイ・データベースのオンラインREDOログを管理する方法の背景情報については、Metalinkノート740675.1スタンバイでのオンラインREDOログを参照してください。