Well, I have not had any problems with lns due to the quantity of redo being generated, but I have had a problem where for an really bad reason the archive log disk on the standby "filled" up. It stalled the primary database which started spitting out ORA-00257 errors. So be careful that not only the primary disk fill, but the standby as well. In my case our Unix admin slapped another duhveloper's hands for me. Dick Goulet Senior Oracle DBA/NA Team Lead PAREXEL International -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of D'Hooge Freek Sent: Tuesday, September 21, 2010 3:16 PM To: Brandon.Allen@xxxxxxxxxxx; Andrew Kerber; oracle-l@xxxxxxxxxxxxx Subject: RE: Real-time Apply in DataGuard Allen, With lgwr async you still have the possibility to impact your primary datatase (although you need to have a really bad situation, before it will emerge): With lgwr async your lns process is reading from the online redo logfile and sends the redo vectors to the standby database. If all is fine, the lns process is just behind the poin the point where the lgwr is writing. However, if your network latency to the standby db is to high for the amount of redo you are generating, the lns process can fall behind. In the case that the lns process is so far behind that it is still reading from logfile n, while the lgwr is already writing to logfile n+2, then an optimization kicks in and the lns process will skip the logfile n+1 (it will be transferred via the arch process). However, if the lns process is even further behind and the lgwr wants to start writing to the logfile from which the lns process is still reading, then the database will halt until the lns process has finished reading that logfile. Regards, Freek D'Hooge Uptime Oracle Database Administrator email: freek.dhooge@xxxxxxxxx tel +32(0)3 451 23 82 http://www.uptime.be disclaimer: www.uptime.be/disclaimer -- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Allen, Brandon Sent: dinsdag 21 september 2010 19:42 To: Andrew Kerber; oracle-l@xxxxxxxxxxxxx Subject: Real-time Apply in DataGuard I'm starting a new thread specific to real-time apply. That is my fear - that by using real-time apply we might impact the performance or availability of the production database if there are network problems between the primary and standby. We had problems with that the last time I tried to implement Data Guard in 9.2.0.4, but according to the documentation it sounds like that shouldn't happen anymore in 10.2. For example, from page 22 of the doc linked below: "In Oracle Database 10g Release 2, the new LGWR ASYNC behavior eliminates the potential to stall the production database" http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-dataguardnetworkbestpr-134557.pdf Has anyone done any testing to confirm if network problems can impact performance of the primary when using real-time apply in 10.2 (10.2.0.4.3 specifically in my case)? I'll be testing it myself soon, but am still curious to know what others have found. Thanks, Brandon From: Andrew Kerber [mailto:andrew.kerber@xxxxxxxxx] I have never implemented real-time apply, but it is my understanding that there are performance issues when there are problems with the network On Tue, Sep 21, 2010 at 11:16 AM, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote: Why not use real-time apply instead? ________________________________________ Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l