Reducing the dg error discover and recover time
- From: Milo <xueyuan.luo@xxxxxxxxx>
- To: "Oracle Discussion List" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 20 Mar 2014 23:41:08 +0800
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:
- » Reducing the dg error discover and recover time - Milo
