Re: Question - standby database from Exadata to non-exadata ?

From: Seth Miller <sethmiller.sm_at_gmail.com>
Date: Thu, 19 Jul 2018 11:28:02 -0500
Message-ID: <CAEueRAXzdwrJs+Mugm9ryR9=F8cvO98Dzi9gBr_Yd0kXeJYFrA_at_mail.gmail.com>



Chris,

Thanks for clarifying. I wanted to make sure I had all of the information so I didn't make some ignorant blanket statement like Pure can't be used because it doesn't support HCC.

I work with a number of Exadata customers and the handful that are using HCC, use it for very specific objects and databases.

Yes, HCC should factor into your considerations, but using HCC on certain objects does not prevent you for using your external compute and storage for those databases not using HCC.

Seth

On Thu, Jul 19, 2018 at 8:08 AM Chris Taylor < christopherdtaylor1994_at_gmail.com> wrote:

> Seth,
>
> We haven't got that far yet. We don't have the Exadata machine in our
> datacenter quite yet.
>
> I was 'thinking' about not using HCC if we wanted to be able to have an
> additional standby on different storage (and clone the dev/test/qa envs
> from that standby). But, that seems silly as we would be limiting our
> functionality in Production for the sole purpose of being able to build
> dev/test/qa environments on separate storage and losing out on the HCC
> capability.
>
> Chris
>
>
> On Wed, Jul 18, 2018 at 3:37 PM Seth Miller <sethmiller.sm_at_gmail.com>
> wrote:
>
>> Chris,
>>
>> You mentioned Advanced Compression but did not mention Hybrid Columnar
>> Compression. Am I correct to assume you are *not* using HCC in Exadata?
>>
>> Seth
>>
>> On Wed, Jul 18, 2018 at 12:50 PM Chris Taylor <
>> christopherdtaylor1994_at_gmail.com> wrote:
>>
>>> Out of curiosity, I assume you use TDE and Advanced Compression on the
>>> Exadata side. What storage are you using on the standby commodity hardware
>>> and are you using the same datafile compression & TDE on the commodity
>>> hardware for the standby?
>>>
>>> Chris
>>>
>>>
>>> On Wed, Jul 18, 2018 at 11:47 AM Ls Cheng <exriscer_at_gmail.com> wrote:
>>>
>>>> response in-line
>>>>
>>>> On Wed, Jul 18, 2018 at 2:36 PM, Chris Taylor <
>>>> christopherdtaylor1994_at_gmail.com> wrote:
>>>>
>>>>> We're gearing up for a massive migration to an Exadata machine and in
>>>>> the process we're going to be freeing up a lot of our previous hardware and
>>>>> storage. The current storage is Pure m70.
>>>>>
>>>>> What we 'thought' we were going to do was something like this (high
>>>>> level):
>>>>> 1. Migrate DB to Exadata
>>>>> 2. Rebuild standby dbs on non-exadata using the now freed up Pure
>>>>> storage
>>>>> 3. Clone dev/test/staging environments from Standby DB on Pure
>>>>>
>>>>> HOWEVER, I'm not sure that's doable as Exadata uses TDE and Advanced
>>>>> Compression. It doesn't appear that Pure likes using AC at the DB layer
>>>>> and instead prefers managing the compression and deduplication internally.
>>>>>
>>>>> Question(s):
>>>>> 1. Has anyone here built a standby on different hardware from Exadata
>>>>> when primary is on Exadata?
>>>>>
>>>> *I do, I have recently (a few months) helped a customer migrate from
>>>> Sparc platform to Exadata quarter rack x6-2 in primary site and commodity
>>>> intel Dell servers in DR site.*
>>>>
>>>>> 2. If so, what issues (gotchas) did you run into that we may need to
>>>>> consider?
>>>>>
>>>> *No, no gotchas as long as you don use Cell functionalities such as
>>>> HCC. Some of migrated database is running since December 2017 and so far we
>>>> have not hit any issues.*
>>>>
>>>>> 3. Does this sound like a 'bad idea' already? My gut is telling me
>>>>> this may be a bad idea.
>>>>>
>>>> *Well if you talk with Oracle Sales or presales they will tell you this
>>>> is a bad idea mainly because your DR site has not got the same power as
>>>> primary site. In my customer case they were willing to have less powered DR
>>>> site, they assumed once in DR they can only have 30% primary site's
>>>> capacity*
>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jul 19 2018 - 18:28:02 CEST

Original text of this message