I have been involved in a few switchover tests. Depending on the type of company, there may well be regulatory requirements with regard to failover/switchover testing. Most of these are quarterly or bi-annual. On Thu, Aug 18, 2011 at 10:41 AM, Mark W. Farnham <mwf@xxxxxxxx> wrote: > It seems you've gotten good advice on the encryption. > > One side issue: You mention a "primary site" plus one physical standby. > > Since this is a new project, the time is right to consider the systems > being > symmetric with a reasonably frequent planned switchover, including "close > to > the database servers" application servers at both sites. > > If your intent is merely data recovery in the event of a site or regional > disaster, that may be overkill, since it is quite possible to test data > recovery without doing a switch or re-instantiation. > > But if your intent is business continuation, such as for a global > operation, > then you really do want switching the live site location to be a practiced > and well understood process from network locations of the intranet and > internet access points all the way through database access. And don't > forget > duplication of any monitoring and notification workstations. > > Once a week or once a month might be enough to keep you in practice, as > long > as you also do a pair of swaps under routine conditions when there is a > software release or equipment change. > > Finding out that you missed the implication of a software or hardware > change > when the "primary" site is in flames or a dusty crater is not good timing. > Finding out that a switch won't work when you really don't have to go > through with the switch is a much better plan. > > When a project is new, there is much less cost to putting this policy in > effect and it is natural to provision the sites equally. If management then > judges that business continuation assurance is not worth the ongoing cost, > then at least it is done with eyes wide open and a clear understanding that > being able to get nearly all the data restored is very different from being > able to continue business operations. > > Regards, > > mwf > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] > On Behalf Of Robertson Lee - lerobe > Sent: Thursday, August 18, 2011 11:01 AM > To: oracle-l@xxxxxxxxxxxxx > Subject: RE: Hi again > > To confirm, this will be on 11g r2 > > And many thanks for those who have replied thus far > > > -----Original Message----- > From: Robertson Lee - lerobe > Sent: 18 August 2011 13:58 > To: oracle-l@xxxxxxxxxxxxx > Subject: Hi again > > Hi Guys, > > I haven't been around for a while but have been given a new project to set > up and I thought I would ask all you good folks on here for some guidance. > :-) > > Basically, what I need to do (or at least investigate initially), is to set > up a DataGuard configuration, Primary plus one Physical Standby and while > the data within the database itself is not to be encrypted, they have asked > if encrypted redo transporting is an option. > > Never done anything like this before (lucky me eh?) so if anyone could > offer > suggestions/white papers/idiot guides etc I would be most grateful > > I have seen various docs showing me how to set up the actual data guard > piece which seems fairly straightforward, I guess its more the encryption > piece I cannot really nail down through Google etc.... > > I assume, if it is possible it is going to need Advanced Security Option > installing ? > > Oracle 10gr2 (or possibly 11g, waiting to find out for definite) on > RHEL. V 5.2 > > Cheers > > Lee > > . > *************************************************************************** > The information contained in this communication is confidential, is > intended > only for the use of the recipient named above, and may be legally > privileged. > > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. > > If you have received this communication in error, please resend this > communication to the sender and delete the original message or any copy of > it from your computer system. > > Thank You. > > **************************************************************************** > > -- > //www.freelists.org/webpage/oracle-l > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'