We investigated this at my previous employer. The primary setup there was EBiz 11.5.10.1 DB 10.2.0.3 (ish) - 3 node RAC Apps Tier 3 dual processors boxes The standby worked just fine with FORCE LOGGING. What we couldn't do adequately back then was DR for the apps tier. It's no coincidence that a 3 node RAC had 3 apps nodes as well, since some of the comms was instance specific - using pipes. This is addressed by having a shared APPL_TOP, but if that isn't an option for you - as it wasn't really for us - then DG was a bit of a pointless exercise. I think I'd probably want to be on EBiz R12 (and a minimum of 11.5.10.2 and tech stack 6) before trying to do DR using standby sites for Ebiz. If your budget reaches to it then stretch RAC and 2 data centres might be a better bet. We used tapes :) On Thu, May 13, 2010 at 6:54 PM, Goulet, Richard <Richard.Goulet@xxxxxxxxxxx > wrote: > Have a question from one of the other folks here who is dealing solely > with EBS. They recently created a data guard standby database (play type) > and went to try a failover to see how the app server would behave. Again > this is a play environment so errors are expected. What she did not expect > is that when failing over the database the system complained about block > corruption. We consequently figured out the it was due to the master db not > having forced logging enabled so we know the master cause. But we did check > around the db and found a very large number of application tables that had > nologging set. This e think is rather odd and is either a foul-up on the > development side at Oracle or something they did deliberately for one reason > or the other. We're now wondering if setting forded logging on at the > database level is going to cause us performance or other problems. So, is > anyone out there running EBS with a DG standby and forced logging on the > master??? What effects are you seeing??? > > *Dick Goulet*** > Senior Oracle DBA/NA Team Lead > PAREXEL International > 900 Chelmsford St, Suite 310 > Lowell, MA 01821 > 978.614.2857 > *Richard.Goulet@xxxxxxxxxxx* > ***http://www.parexel.com* <http://www.parexel.com/>** > > *The information transmitted in this communication is intended only for > the person or entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon, this information by > persons or entities other than the intended recipient is prohibited. If you > received this in error, please destroy any copies, contact the sender and > delete the material from any computer.* > > -- Niall Litchfield Oracle DBA http://www.orawin.info