Re: Re: Reducing the dg error discover and recover time

From: Milo <xueyuan.luo_at_gmail.com>
Date: Fri, 21 Mar 2014 10:14:04 +0800
Message-ID: <2014032110135859301125_at_gmail.com>



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_at_gmail.com> 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

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Mar 21 2014 - 03:14:04 CET

Original text of this message