standby缺失primary归档，手工同步恢复

         由于误删physical standby上来自primary db的归档日志，physical standby缺少还未应用到的archive log。

          此时，primary db也没有归档。考虑除了重建 standby外的其他方法。因为备份中保留压缩备份后的归档备份，所以，尝试从备份中恢复了archive log，然后实验了一下手工recover。期间发现standby的control file中没有backup set的信息（有archive log的），以前没注意过这个，在此记录一下。此外，切换成自动模式后，报 Failed to request gap sequence，其实gap的都已经存在在standby上了。这里需要手工注册。

 

恢复archive log到默认位置

RMAN>RESTORE ARCHIVELOG FROM SEQUENCE  13042  UNTIL SEQUENCE 13119;

(或 RMAN>RESTORE ARCHIVELOG FROM SEQUENCE  13042;)

SQL> startup nomount;

SQL> alter database mount standby database;

SQL> RECOVER AUTOMATIC STANDBY DATABASE;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

standby上注册

ALTER DATABASE REGISTER LOGFILE  '/data/archive/test/1_12844_690562326.dbf';

---附上一个批量生成
select 'ALTER DATABASE REGISTER LOGFILE  ''/data/archive/test/1_'||(rownum+12844 )||'_690562326.dbf'';'

from all_objects
where rownum <= 98;

---

另，来自http://zhaolinjnu.blog.sohu.com/55088738.html

除了上面的automatic方式，也可以执行recover cancel的恢复方式：
SQL> RECOVER STANDBY DATABASE UNTIL CANCEL;

这种方式有一个好处是，可以应用联机日志信息，有时主库因为存储损坏，可以拷贝本地硬盘的联机日志到备用库，而拷贝的这些联机日志存放的地方也不是数据库默认的地方，如果让oracle自动恢复，它会找不到这些联机日志，这时就需要手动指定联机日志的路径，让其恢复。待恢复完成，可以强制激活备用库。

 以上两种手动恢复模式automatic和 CANCEL都不需要对归档日志进行注册，自动管理恢复模式 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION 是需要的

---

查看相关信息，来自http://space.itpub.net/308563/viewspace-198067

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
 
PROCESS   STATUS
--------- ------------
ARCH      CONNECTED
ARCH      CONNECTED
MRP0      WAIT_FOR_GAP

SQL> select * from v$archive_gap;
 
   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1          5330           5331

ON PRIMARY:
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
 
PROCESS   STATUS
--------- ------------
ARCH      CLOSING
ARCH      CLOSING
LGWR      CLOSING

SQL> SHOW PARAMETER ARCHIVE

log_archive_dest_2                   string      SERVICE=STANDBY affirm lgwr ma
                                                 x_failure=1 noreopen net_timeout=60

SQL> select message from v$dataguard_status;

MESSAGE
--------------------------------------------------------------------------------
ORA-16198: LGWR received timedout error from KSR
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
LGWR: Network asynch I/O wait error 16198 log 2 service 'STANDBY'
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3135 when pinging standby STANDBY.
LGWR: Failed to archive log 2 thread 1 sequence 5330 (16198)
LGWR: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'STANDBY' (error 16
198)

SQL> SELECT PROCESS,STATUS FROM V$MANAGED_STANDBY;

PROCESS   STATUS
--------- ------------
ARCH      CLOSING
ARCH      OPENING
LGWR      WRITING

SQL> create or replace directory ARCHDIR as '+dgarch/wms/archivelog/2008_02_29';

Directory created.

SQL>  create or replace directory TEMPDIR as '/exp/tmparch';

Directory created.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('ARCHDIR','thread_1_seq_5331.291.647960215','TEMPDIR','1_5331_620945476.arc');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('ARCHDIR','thread_1_seq_5330.304.647958993','TEMPDIR','1_5330_620945476.arc');

PL/SQL procedure successfully completed.

其它，primary/standby环境：

x86_64

linux

oracle 10.2.0.4.0

记于2010年11月16日　

最后更新 2010年12月27日 　
 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23650854/viewspace-682649/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23650854/viewspace-682649/