Re: Re: Reducing the dg error discover and recover time
- From: Milo <xueyuan.luo@xxxxxxxxx>
- To: Balázs Papp <balage.papp@xxxxxxxxx>
- Date: Fri, 21 Mar 2014 10:14:04 +0800
Hi, Balazs
I will try latter.
Thanks for your comments.
Best Regards,
Milo
From: Balázs Papp
Date: 2014-03-21 00:01
To: xueyuan.luo
CC: Oracle Discussion List
Subject: Re: Reducing the dg error discover and recover time
Hi,
the REOPEN option for LOG_ARCHIVE_DEST_N specifies how long the redo transport
should wait before it tries to reconnect to a failed destination. It is set to
300 seconds by default, but you can lower this value as needed.
http://docs.oracle.com/cd/E16655_01/server.121/e17640/log_arch_dest_param.htm#SBYDB01113
To trigger the check manually, you can use "alter system set
log_archive_dest_state_N=enable;", even if its enabled already (and waiting for
the above timeout).
Regards,
Balazs Papp
On Thu, Mar 20, 2014 at 4:41 PM, Milo <xueyuan.luo@xxxxxxxxx> wrote:
Hi, guys
Is there any ways to quickly trigger the check on data guard primary db when
there is network or any other reason fail to transfer archive log to standby?
See this example:
primary db: db_unique_name=stdby
standby db: db_unique_name=prim
1. standby alert log:
Thu Mar 20 22:32:06 2014
MRP0: Background Managed Standby Recovery process started (prod)
Managed Standby Recovery not using Real Time Apply
Thu Mar 20 22:32:11 2014
Completed: alter database recover managed standby database disconnect from
session
Thu Mar 20 22:32:11 2014
Media Recovery Waiting for thread 1 sequence 33
Thu Mar 20 22:35:26 2014
Using STANDBY_ARCHIVE_DEST parameter default value as /oradata/arch/prim/
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 22595
RFS[1]: Identified database type as 'physical standby'
Thu Mar 20 22:35:26 2014
RFS LogMiner: Client disabled from further notification
RFS[1]: Archived Log: '/oradata/arch/prim/1_34_842720624.arc'
Thu Mar 20 22:35:26 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 22597
RFS[2]: Identified database type as 'physical standby'
Thu Mar 20 22:35:26 2014
RFS[1]: Archived Log: '/oradata/arch/prim/1_35_842720624.arc'
RFS[1]: Archived Log: '/oradata/arch/prim/1_36_842720624.arc'
RFS[1]: Archived Log: '/oradata/arch/prim/1_37_842720624.arc'
Thu Mar 20 22:35:26 2014
RFS[2]: Archived Log: '/oradata/arch/prim/1_33_842720624.arc'
Thu Mar 20 22:35:28 2014
Media Recovery Log /oradata/arch/prim/1_33_842720624.arc
Media Recovery Log /oradata/arch/prim/1_34_842720624.arc
Media Recovery Log /oradata/arch/prim/1_35_842720624.arc
Media Recovery Log /oradata/arch/prim/1_36_842720624.arc
Media Recovery Log /oradata/arch/prim/1_37_842720624.arc
Media Recovery Waiting for thread 1 sequence 38
From the highlight part, we see that after start the applying, it seems took 3
minus to recover from the error or issue.
2. primary db, archive log process trace file
There is some trace file from the archive log process on primary
database(service name stdby) shows that :
*** 2014-03-20 22:32:18.961
kcrrwkx: nothing to do (start)
*** 2014-03-20 22:33:24.076
kcrrwkx: nothing to do (end)
*** 2014-03-20 22:35:29.341
RFS network connection lost at host 'prim'
Error 3113 detaching RFS from standby instance at host 'prim'
Ignoring kcrrvnc() detach error 3113
Redo shipping client performing standby login
*** 2014-03-20 22:35:29.371 64561 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
kcrrwkx: nothing to do (end)
*** 2014-03-20 22:37:21.423
kcrrwkx: nothing to do (start)
So times the time took 5 more minus, so I wonder if there any way to reduce
this (discover & recover) time, just for interest.
Any comment is welcome. :)
Best Regards,
Milo
Other related posts:
- » Re: Re: Reducing the dg error discover and recover time - Milo
