RE: resync

Let me see if I understand the operational parameters:

1. Your network to the physical standby functions continually, but lacks bandwidth the keep up with peak load generation of redo.
2. You'd rather not have the next commit hang until another archive log has been transmitted and made free for re-use.

If you can predict the duration of redo log generation that exceeds your network bandwidth, then you can configure enough on line redo logs to get past the load peak without hanging the database.

Given the relatively high amount of storage per spindle on modern disk systems, going very high with the number and total amount of on line redo logs is a pretty cheap way to protect against this type of peak wrap. Of course your standby is farther and farther transiently behind, but if you wanted a protection level of maximum protection you would configure a faster network link to your standby.

Still, it seems strange that you HAD to manually archive. Was that actually required, or did you simply do that to more immediately release the hang? Adding another log on the fly should also have worked (and probably sooner).

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Denny Koovakattu
Sent: Tuesday, October 11, 2005 6:50 PM
To: oracle-l_at_freelists.org
Cc: 'zhuchao_at_gmail.com'; Mladen Gogala
Subject: RE: resync

All,

  I am trying to catch up on my email, so this might have already been discussed.

Version: 9.2.0.4
Protection: MAXIMUM PERFORMANCE
log_archive_max_processes=2
log_archive_dest_2="SERVICE=standby_alias LGWR ASYNC REOPEN=60" log groups = 3
log file size = 1G

  I have seen this behavior recently with a really slow (NOT broken) network.
All the archiver processes were busy copying the archive log files over to the
standby and none were available to archive the last log group. The database was
hung until we manually archived the logfiles. (Haven't experimented to find a
workaround since we are working on fixing the network.)

Regards,
Denny

--
Denny Koovakattu


Quoting "Gogala, Mladen" <MGogala_at_allegientsystems.com>:



> In this case it is. I have a RAC database on Solaris and I am maintaining

> two standby instances: one physical and one logical.

>

> The latter one is called "reporting database". I've had all kinds of

network


> calamities but my primary database was never hung.

>

> If you have different experience, let's hear it, documented with OS and DB

> versions and the exact description. I cannot accept

>

> patronizing tone on its own, without any additional arguments. In addition

> to that, to know how oracle works it is sometimes,

>

> just sometimes, advisable to read the documentation.

>

>

>

> --

>

> Mladen Gogala

>

> Ext. 121

>

>   _____

>

> From: zhu chao [mailto:zhuchao_at_gmail.com]

> Sent: Wednesday, October 05, 2005 8:27 AM

> To: Mladen Gogala

> Cc: David Sharples; peterdixon001_at_hotmail.com; oracle-l_at_freelists.org

> Subject: Re: resync

>

>

>

> Hi, Gogala,

>

>    Oracle is not always working as documented, you know:).

>

>    We did configure optional, and primary database archive process did

hang


> and locked that redo log on primary.

>

>    I have seen several cases like that.

>

>

>

>





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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


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