Re: Oracle DR Solution
Date: Thu, 1 Sep 2011 12:32:46 -0500
Message-ID: <CAFH+ifdF5RGkMYfuWsfPxFKum=51HFCiC5k6jRT5eBkFCVLU1A_at_mail.gmail.com>
Good point. I did have flashback enabled on the standby and used it several times when we'd opened the standby for activity, but I'm one of those people that needs a 'Plan B'. Always. Persistent pessimist? Maybe. But if 'Plan A' works, I'm really happy. If it doesn't, 'Plan B' has saved me more than once.
On Wed, Aug 31, 2011 at 2:26 PM, Sanjay Mishra <smishra_97_at_yahoo.com> wrote:
> David
>
> Am I making wrong assumption that delay surely was good in previous
> releases as now we have Flashback Database and so can flashback database to
> the point as long as we have sufficient Logs and setting.
>
> Yes One good point is that we can surely do switchover or even can failover
> and reinstate in Dataguard setup. Not very familiar as how storage snapshot
> works in terms of this failover testing. Anyone share his experience with
> Storage technology to failover and then stayed there for few days and
> comeback to Primary.
>
> Rgds
> Sanjay
>
> ------------------------------
> *From:* David Barbour <david.barbour1_at_gmail.com>
> *To:* smishra_97_at_yahoo.com
> *Cc:* "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>
> *Sent:* Wednesday, August 31, 2011 12:35 PM
> *Subject:* Re: Oracle DR Solution
>
> Something else you might want to consider is why your primary failed in the
> first place. In any High-Availability/Disater Recovery scenario, the
> database is or can be a single point of failure. If you have a corrupt
> database and you're replicating via storage snapshots or using DataGuard
> with automatic fail-over, you run the risk of ending up with a corrupt DB at
> both locations requiring a lot of downtime to restore to point-in-time.
>
> If you have an active/passive DataGuard setup with a delay in applying logs
> for instance, you have a chance to bring the DR site current until just
> prior to the failure before you open the DB for use.
>
> I had a similar requirement at my previous employer and we delayed log
> application for 60 minutes. It was a 7+TB enterprise SAP DB processing a LOT
> of data. We were located in Florida and particularly for hurricane season,
> maintained a DR site outside Atlanta. We practiced failing over at least
> twice a year, and actually switched over at other times for maintenance
> reasons. Applying the outstanding logs took 5 minutes at the most and we
> were generally able to perform a complete switchover in just under 10
> minutes.
>
>
> On Wed, Aug 31, 2011 at 10:58 AM, Sanjay Mishra <smishra_97_at_yahoo.com>wrote:
>
> Jason
>
> Yes it was my mistake to say no downtime but actually it is least downtime.
> Ofcourse we can use Fast Start failover to minimize the switcover/failover
> time based on business requirements and avoid some manual intervention.
>
> So What I can see is the Dataguard and Storage based replication as two
> main choices but want to see how Storage based can provide more better
> solution over dataguard on technical side and not on financial terms and
> what is best practices in critical online environment
>
> TIA
> Sanjay
>
> ------------------------------
> *From:* jason arneil <jason.arneil_at_gmail.com>
> *To:* saurabhmanroy_at_gmail.com
> *Cc:* oracle-l_at_freelists.org
> *Sent:* Wednesday, August 31, 2011 8:47 AM
>
> *Subject:* Re: Oracle DR Solution
>
> One drawback with the dataguard route is the "… no loss or downtime"
> requirement.
>
> Sure data guard and be configured to ensure no data loss, but it can't give
> you *no *downtime.
>
> Is that no downtime really a requirement? If you are serious about that,
> you have to go to some form of Active - Active setup across datacentres,
> with stretched RAC as a possibility.
>
> I'd also argue that there are few businesses that really in a catastrophic
> scenario can't afford a handful of minutes to enact a failover.
>
> jason.
>
> --
> http://jarneil.wordpress.com
>
>
>
> On 31 Aug 2011, at 11:35, saurabh manroy wrote:
>
> Extended/Stretch RAC is a low cost but rather incomplete DR solution.
> Low Cost: In-terms of number of resources need to maintain the environment.
> DataGuard maintenance needs additional skills (apart from knowing RAC).
> Also, not to forget licensing costs for DataGuard.
> Incomplete: Distance between nodes of cluster is still a major factor.
> Though 11g comes with preffred mirror read options, internode communication
> would still be an issue over long distance. So, less distance between nodes
> means, both sites would likely stop functioning in situations of: flood,
> earthquake etc.
>
> Since Cost is not an issue for Sanjay, Primary DB as a RAC cluster and
> Standby DB also a RAC cluster would be a better solution in my opinion.
>
> Regards,
> Saurabh Manroy
> http://smanroy.wordpress.com
>
>
> the reader of this email (and attachments) is not the intended recipient,
> you are hereby notified that any dissemination, distribution or copying of
> this communication is strictly prohibited. Please notify the sender of the
> error and delete the e-mail you received. Thank you.****
> ** **
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Sanjay Mishra
> *Sent:* Tuesday, August 30, 2011 3:28 PM
> *To:* oracle-l_at_freelists.org
> *Subject:* Oracle DR Solution****
> ** **
> Hi****
> ** **
> I am looking to see what is the best option to have DR solution that can be
> Primary with no loss or downtime. Looking for best practices even it is
> expensive solution. Appreciate for any document or link as I am sure lots
> has done work on it. One of the requirement is that database is around 10Tb
> and transaction logs will be be not more than 50G in an hour.****
> ** **
> 1. Can see 11g Active Dataguard which can be used for Reporting as well as
> DR solution****
> 2. Storage Replication****
> ** **
> Rgds****
> Sanjay****
>
> This email and any attachments are confidential and may also be privileged.
> If you are not the addressee, do not disclose, copy, circulate or in any
> other way use or rely on the information contained in this email or any
> attachments. If received in error, notify the sender immediately and delete
> this email and any attachments from your system. Emails cannot be guaranteed
> to be secure or error free as the message and any attachments could be
> intercepted, corrupted, lost, delayed, incomplete or amended. Standard
> Chartered PLC and its subsidiaries do not accept liability for damage caused
> by this email or any attachments and may monitor email traffic.
>
> Standard Chartered PLC is incorporated in England with limited liability
> under company number 966425 and has its registered office at 1 Aldermanbury
> Square, London, EC2V 7SB.
>
> Standard Chartered Bank ("SCB") is incorporated in England with limited
> liability by Royal Charter 1853, under reference ZC18. The Principal Office
> of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In
> the United Kingdom, SCB is authorised and regulated by the Financial
> Services Authority under FSA register number 114276.
>
> If you are receiving this email from SCB outside the UK, please click
> http://www.standardchartered.com/global/email_disclaimer.html to refer to
> the information on other jurisdictions.
>
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>
>
>
>
>
>
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Sep 01 2011 - 12:32:46 CDT