standby端收到了归档日志，但是不自动做Media Recovery

jadesuper

备库上报错：
alter database recover managed standby database disconnect from session
Sun Jan 10 14:03:32 2010
Attempt to start background Managed Standby Recovery process (stdby1)
MRP0 started with pid=29, OS id=17433
Sun Jan 10 14:03:32 2010
MRP0: Background Managed Standby Recovery process started (stdby1)
Sun Jan 10 14:03:37 2010
Managed Standby Recovery not using Real Time Apply
Sun Jan 10 14:03:39 2010
Media Recovery Waiting for thread 2 sequence 13
Fetching gap sequence in thread 2, gap sequence 13-13
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
Sun Jan 10 14:03:39 2010
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc:
ORA-01034: ORACLE not available
Sun Jan 10 14:03:39 2010
Completed: alter database recover managed standby database disconnect from session



Sun Jan 10 14:04:09 2010
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
Sun Jan 10 14:04:09 2010
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc:
ORA-01034: ORACLE not available
Sun Jan 10 14:04:29 2010
Managed Standby Recovery not using Real Time Apply
Sun Jan 10 14:04:39 2010
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
Sun Jan 10 14:04:39 2010
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc:
ORA-01034: ORACLE not available
Sun Jan 10 14:05:10 2010
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
Sun Jan 10 14:05:10 2010
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc:
ORA-01034: ORACLE not available
Sun Jan 10 14:05:40 2010
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
Sun Jan 10 14:05:40 2010
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc:
ORA-01034: ORACLE not available
Sun Jan 10 14:06:10 2010
FAL[client]: Failed to request gap sequence
GAP - thread 2 sequence 13-13
DBID 118726872 branch 707821078
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------


在备库上查看trc文件：
bash-2.04#
bash-2.04#
bash-2.04#
bash-2.04# cat /u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc
/u01/app/oracle/admin/stdby/bdump/stdby1_mrp0_17433.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters and Data Mining options
ORACLE_HOME = /u01/app/oracle/db_1
System name:    HP-UX
Node name:      hp183
Release:        B.11.11
Version:        U
Machine:        9000/800
Instance name: stdby1
Redo thread mounted by this instance: 1
Oracle process number: 0
Unix process pid: 17433, image: oracle@hp183

Async driver not configured  : errno=13
*** SERVICE NAME) 2010-01-10 14:03:32.640
*** SESSION ID140.1) 2010-01-10 14:03:32.640
ARCH: Connecting to console port...
*** 2010-01-10 14:03:32.640 60679 kcrr.c
MRP0: Background Managed Standby Recovery process started
*** 2010-01-10 14:03:37.650 1011 krsm.c
Managed Recovery: Initialization posted.
Recovery target incarnation = 7, activation ID = 119673322
Influx buffer limit = 12480 (50% x 24960)
Start recovery at thread 2 ckpt scn 1291928 logseq 13 block 2
*** 2010-01-10 14:03:39.128
Media Recovery add redo thread 2
*** 2010-01-10 14:03:39.182
Media Recovery add redo thread 1
*** 2010-01-10 14:03:39.185 1011 krsm.c
Managed Recovery: Active posted.
*** 2010-01-10 14:03:39.243 60679 kcrr.c
Media Recovery Waiting for thread 2 sequence 13
*** 2010-01-10 14:03:39.247 60679 kcrr.c
Fetching gap sequence in thread 2, gap sequence 13-13
*** 2010-01-10 14:03:39.431 60679 kcrr.c
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
ORA-01034: ORACLE not available
*** 2010-01-10 14:04:09.630
*** 2010-01-10 14:04:09.630 60679 kcrr.c
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
ORA-01034: ORACLE not available
*** 2010-01-10 14:04:39.817
*** 2010-01-10 14:04:39.817 60679 kcrr.c
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
ORA-01034: ORACLE not available
*** 2010-01-10 14:05:10.011
*** 2010-01-10 14:05:10.011 60679 kcrr.c
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
ORA-01034: ORACLE not available
*** 2010-01-10 14:05:40.214
*** 2010-01-10 14:05:40.214 60679 kcrr.c
FAL[client, MRP0]: Error 1034 fetching archived redo log from PROD
ORA-01034: ORACLE not available
*** 2010-01-10 14:06:10.235
-----------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-----------------------------------------------------------
bash-2.04#


查看备库上有arch_13_2_707821078.arc，，
主库上却没有这个。。
很奇怪。。
应该怎么做呢 ？？

renxiao2003

我也想知道，帮你顶一下。

leelangco

先断开
在重新建立一次连接

flutter

我遇到过类似问题，可以把主库重启一下。

flutter

你的错误1034好奇怪，我的从来没有。

先查询v$archive_gap，如果有日志缺失，哪肯定只有LTS，没有LAS。

若无缺失，启动STANDBY到RECOVER模式，观察LAS。

再不LAS，可重启主库，再观察LAS。

jadesuper

FAL[client]: Failed to request gap sequence
GAP - thread 2 sequence 10-10
DBID 118726872 branch 707938639
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
Mon Jan 11 08:37:50 2010
RFS[3]: Possible network disconnect with primary database
Closing latent archivelog for thread 1 sequence 13
EOF located at block 76 low SCN 0:1334599 next SCN 0:1335845
Latent archivelog '/u01/arch/arch_13_1_707938639.arc'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/u01/arch/arch_13_1_707938639.arc';


原因找到：
主库这边是rac，两个节点开机的时候，b节点的目录没有自动mount到a节点的nfs上，导致b节点上的归档日志存放在了b节点的目录下。
然后手动mount上时，就造成归档日志丢失。。
解决办法：
将b节点存放在本地归档目录下的归档日志scp到a节点的归档目录下，重启主库即可。

[ 本帖最后由 jadesuper 于 2010-1-12 14:26 编辑 ]

jadesuper

加油。。

[ 本帖最后由 jadesuper 于 2010-1-12 14:26 编辑 ]