Re: Manual Standby as alternative to dataguard

I agree with these sentiments completely--a true HA solution requires force logging. At my last job, we had a major SAN failure, and two out of twenty databases didn't failover correctly. The cause--a vendor supplied script run on those two instances specificed "NOLOGGING"--that's all it took.

This was a company that had a very solid change management process in place, but given the amount of changes its impossible to catch everything.

Like Rik says below, the impact of  logging is fairly minimal, so just go ahead and do it.

Joe D'Antoni
Synthes USA 




________________________________
From: Ric Van Dyke <ric.van.dyke_at_hotsos.com>
To: Mathias Magnusson <mathias.magnusson_at_gmail.com>; sanjeev m <sanjeevorcle_at_gmail.com>
Cc: Jurijs Velikanovs <j.velikanovs_at_gmail.com>; niall.litchfield_at_gmail.com; oracle-l_at_freelists.org
Sent: Wednesday, June 17, 2009 7:31:22 AM
Subject: RE: Manual Standby as alternative to dataguard


I believe that the original problem is that the business folks are under the impression that NOLOGGING does something that it doesn’t..
 
The bottom line is that once an object has the NOLOGGING attribute turned on, the only things that are not logged are actions that involve the direct load code.  So actions like a direct load via SQL Loader, or an append insert.  Other then that all actions are still logged even with NOLOGGING turned on.  So unless the business it doing a lot of direct load type work, turning on FORCE LOGGING will likely not change the way the application works at all. If it does do a lot of direct load work then yes it will be affected.  How much would need to be tested to see, but yes the direct loads will slow down because they are now being logged with FORCE LOGGING turned on.  There are some other nuances to having it off, like if you create it with it set to off then the objects creation isn’t logged, so the object would get created on the standby, the apply process will need to skip any actions on that object if they appear in the redo stream. 
 
As to the argument about can you have a DR solution with FORCE LOGGING off, I believe that it’s creating a lot more work to have it turned off then its worth.  To make it work you have to be able to now manually do the action that wasn’t logged on the primary.  Maybe thru RMAN backups, or recreating the standby once and a while, or keeping track of all the direct path operations and applying them just after activating the standby but before you allow users to connect, any choice you pick is not going to be easy and has a possibility for a mistake which leaves you with inconsistent or flat out wrong data.   If you’re serious about having a DR site then FORCE LOGGING turned on isn’t optional.  From a technical point of view, yes the apply process will run just fine with it on or off, but from a business and logical point of view it is very important which setting FORCE LOGGING is set to. 
 
-----------------------
Ric Van Dyke
Hotsos Enterprises
-----------------------
 
Hotsos Symposium 
March 7 – 11, 2010 
Be there.
 
 

________________________________

From:mathiasmag_at_gmail.com [mailto:mathiasmag_at_gmail.com] On Behalf Of Mathias Magnusson
Sent: Wednesday, June 17, 2009 12:35 AM
To: sanjeev m
Cc: Jurijs Velikanovs; niall.litchfield_at_gmail.com ; Ric Van Dyke ; oracle-l_at_freelists.org
Subject: Re: Manual Standby as alternative to dataguard
 
Let's go back to the actual problem. What do you do in the transactions that causes this to be a problem? No-logging and forcing it only affects a limited number of operations. Could it be that it is not clearly understood by the business users when this actually would have an effect on the performance?
 
And by the way, I believe posting data recieved in MetaLink of cound in articles there is not allowed and could cause your support contract to be revoked..

Mathias


      

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