Re: Dataguard Exadata -> Database Appliance
Date: Wed, 16 Apr 2014 11:00:31 -0700
Message-Id: <E76B328E-16B3-4EF2-B609-0AD311EDF4E4_at_enkitec.com>
One thing that many people don't think about regarding DR to a non-Exadata system is HCC. While you can run a physical standby on a non-Exadata system, you will need to decompress objects that are compressed before you can actually query that data. This means 2 things for you - your DR system will need more storage space than the primary system (if you get 10X compression, that 100GB table is now 1TB), and you will need to account for that time needed to decompress into your SLA for DR. Decompression is CPU-intensive, so depending on how many CPUs you have, the longer it will take. This could take your time for a failover from minutes to hours, depending on what you have compressed.
While I wouldn't recommend going to a non-Exadata system for DR, make sure that you take these factors into account if you are going to go that way.
Andy Colvin
Practice Director
Enkitec
acolvin_at_enkitec.com
http://www.enkitec.com
http://blog.oracle-ninja.com
On Apr 15, 2014, at 11:41 AM, Bobby Curtis <curtisbl_at_gmail.com> wrote:
> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Freek D'Hooge
> Sent: Tuesday, April 15, 2014 2:19 PM
> To: development_at_the-playground.de
> Cc: ivanrs79_at_gmail.com; Chris.Stephens_at_adm.com; Hemant K Chitale; oracle-l_at_freelists.org
> 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_at_exitas.be
> tel +32(03) 443 12 38
> 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.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
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 16 2014 - 20:00:31 CEST