RE: Dataguard Exadata -> Database Appliance
- From: "Bobby Curtis" <curtisbl@xxxxxxxxx>
- To: <freek.dhooge@xxxxxxxxx>, <development@xxxxxxxxxxxxxxxxx>
- Date: Tue, 15 Apr 2014 14:41:18 -0400
This has been an interesting thread. With the adoption of engineered systems,
there comes more choices and flexibility. As many have already pointed out;
using an Exadata for the primary and then a smaller platform (ODA or commercial
hardware) for DR will work. The downside is that you will take a performance
hit not only in the features that Exadata provides (smart scans, etc), but more
with capacity and ability to meet customer demands. I would have to ask, what
is your expected Service Level Agreement (SLA) for this environment? Once
that is in hand, then drive towards a DR solution to match.
Ideally and if possible, the best approach would be to use Exadata on both
sides of the equation. This is not always possible due to budgetary
constraints and often times proper solutions get downgraded. Someone
mentioned it earlier and I agree with them; if this is the case, recommend
keeping a paper trail on the decision with regards to direction with DR. It
will only protect you and help you if something was to happen and DR was needed
with/without the expect capacity.
Just my 2 cents.
Bobby
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Freek D'Hooge
Sent: Tuesday, April 15, 2014 2:19 PM
To: development@xxxxxxxxxxxxxxxxx
Cc: ivanrs79@xxxxxxxxx; Chris.Stephens@xxxxxxx; Hemant K Chitale;
oracle-l@xxxxxxxxxxxxx
Subject: Re: Dataguard Exadata -> Database Appliance
Hi,
For me it depends on what is expected from the DR environment.
If management is fully aware that it will only will allow to run in a somewhat
restricted way, I don't have much problem in using lesser hardware for a DR
site.
Just make sure you have a paper trail confirming their awareness ;-)
I have seen the combination exadata primary - oda standby being proposed
before, with virtualization enabled on the ODA
Reason behind is is that you can run on a minimal set of CPU's activated on the
standby site and only activate the rest when doing a failover.
As the primary site at that point no longer exists, you could argue that you
don't need additional db licenses.
(Now, that is something I would like to see confirmed in writing from Oracle
LMS ;-) )
Kind regards,
--
Freek D'Hooge
Exitas NV
Senior Oracle DBA
email: freek.dhooge@xxxxxxxxx <mailto:freek.dhooge@xxxxxxxxx>
tel +32(03) 443 12 38
http://www.exitas.be <http://www.exitas.be/>
On di, 2014-04-15 at 19:40 +0200, Martin Bach wrote:
Hello all,
This is an interesting thread!
I think an important point is missing here though. Exadata, especially since
11.2.3.3 <http://11.2.3.3> .0, will make very elegant choices when it comes to
caching data in the Smart Flash Cache. You will see very decent response times.
You will also notice that smart scans will benefit from intelligent caching.
This works so well that I had to rewrite some of my demos.
Those features do not exist outside the Exadata platform. Outside of Exadata
you get no smart IO either, so when you are in the uncomfortable position where
you actually have to invoke DR you could well be in trouble because your DR
site does not perform adequately. And there is more hidden trouble like for
example IORM you can't have outside of Exadata...
Not using identical hardware for DR is a risk in my opinion. The OPs question
is similar in concept to reusing your old production kit for DR. It too might
work while in the standby role, but will cost likely not support the production
workload (it is the old kit for a reason).
Hope this helps,
Martin
Other related posts:
