Reducing the dg error discover and recover time

From: Milo <xueyuan.luo_at_gmail.com>
Date: Thu, 20 Mar 2014 23:41:08 +0800
Message-ID: <2014032023410203056723_at_gmail.com>

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

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Mar 20 2014 - 16:41:08 CET