Re: To ODA or Not?
Date: Sat, 28 Mar 2015 00:07:47 -0400
Message-ID: <CAAaXtLAaGO9iE5A1rDFXpjAkC06BoiE7qzO7kP4K8gMc2N-QHg_at_mail.gmail.com>
Despite constant "sky is falling" messages coming from certain listers, the ODA is very easy to manage.
I hope you don't mean me.
You don't need to be an expert in Linux. You don't need to be an expert in ACFS or ASM. You need to have a good understanding of the database (and Oracle VM if you go that route) and you need to learn oakcli (the command line utility to manage the ODA) and that's pretty much it.
I have little hands-on experience with ODA, but this is exactly what I would expect. I worked with Exadata for about 2 years, and spent 99% of my time working on the database, rather than the infrastructure. Well, aside from applying patches and replacing failed disks, anyway. There was little or nothing to do in terms of RAC or ASM, at least once the system is initially configured.
That's the whole point to having an appliance. You get it, you set it up the way you are told to, and then you (mostly) leave it alone and let it do its thing.
There were a few things we needed to do at the OS level on Exadata. The most memorable was diagnosing and fixing problems in OSwatcher that caused it to chew up a large portion of the CPU on the storage cells and to fill the filesystem with garbage. We happened to have the Linux expertise needed, so we tackled it directly, and gave the "answer" to Oracle Support. Sites with less expertise might choose to do it the other way.
Frankly, I expect most people will be quite happy with ODA.
On Fri, Mar 27, 2015 at 10:45 PM, Seth Miller <sethmiller.sm_at_gmail.com> wrote:
> Jeff,
>
> You are correct, you do not need to use RAC. You mentioned you weren't
> going to use RAC many posts ago so I'm not sure why it keeps coming up.
>
> Despite constant "sky is falling" messages coming from certain listers,
> the ODA is very easy to manage. You don't need to be an expert in Linux.
> You don't need to be an expert in ACFS or ASM. You need to have a good
> understanding of the database (and Oracle VM if you go that route) and you
> need to learn oakcli (the command line utility to manage the ODA) and
> that's pretty much it.
>
> Seth Miller
>
> On Fri, Mar 27, 2015 at 7:11 PM, Jeff Chirco <backseatdba_at_gmail.com>
> wrote:
>
>> Well we are not licensed for RAC nor will we want to. Is that a
>> requirement? I thought no I had a conversation with the PM at an event and
>> I believe he said you didn't need to use RAC, the second server could be
>> used as a failover which I guess is like RAC but not a full Oracle RAC
>> environment. Maybe that is what you are referring to.
>>
>> On Fri, Mar 27, 2015 at 5:02 PM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com
>> > wrote:
>>
>>> You *will* be using RAC, once you move to ODA. Things may have changed
>>> since the first generation of ODA, but the last time I checked (which was
>>> the release of the first generation), the use of some-form-of-RAC was
>>> mandatory. As was the use of Enterprise Edition, even though the hardware
>>> is "small" enough to qualify for Standard Edition.
>>>
>>> RAC-one-node was acceptable at the time, and probably still is now.
>>> Further, even if your system is built on RAC, nothing requires you to start
>>> more than one instance per database. If your database has only one
>>> instance, it might *technically* be a RAC database, but the existence
>>> of RAC will have no material affect on your applications. You really only
>>> see significant affects once you have two or more instances running.
>>>
>>> On Fri, Mar 27, 2015 at 7:22 PM, Jeff Chirco <backseatdba_at_gmail.com>
>>> wrote:
>>>
>>>> We are not using RAC here.
>>>>
>>>> On Fri, Mar 27, 2015 at 4:22 PM, Jeff Chirco <backseatdba_at_gmail.com>
>>>> wrote:
>>>>
>>>>> HI Mladen,
>>>>> Thank you for this information. This helps. As far as the redo logs,
>>>>> if you put them on the flash storage drive does that help with concerns to
>>>>> the snapshots?
>>>>> I am still unsure how the snapshot technology works on the ODA. Is it
>>>>> similar to NetApp and using SnapManager for Oracle which basically puts all
>>>>> the tablespaces in backup mode and then "snaps" the volume and then puts
>>>>> the tablespaces out of backup mode?
>>>>>
>>>>> On Fri, Mar 27, 2015 at 3:18 PM, Mladen Gogala <
>>>>> dmarc-noreply_at_freelists.org> wrote:
>>>>>
>>>>>> On 03/27/2015 05:07 PM, Seth Miller wrote:
>>>>>>
>>>>>> Jeff,
>>>>>>
>>>>>> You are in luck. The latest release of the ODA uses ACFS for the
>>>>>> database storage which has snapshot/clone technology similar to NetApp.
>>>>>> ACFS and all of its snapshotting capabilities are included.
>>>>>>
>>>>>> Well, that is not exactly true. ACFS uses COW (Copy-On-Write)
>>>>>> snapshots which will triple your IO rates on writes. When you write to a
>>>>>> file system with the snapshot, the machine must:
>>>>>>
>>>>>> 1. Read the old data (first I/O operation)
>>>>>> 2. Write the old data to snapshot pool block (second IO operation)
>>>>>> 3. write the new data to the FS (third IO operation).
>>>>>>
>>>>>> Not all snapshot technologies are created equal. SAN manufacturers
>>>>>> like NetApp usually use so called "deferred write", while file systems like
>>>>>> BRTFS, ZFS and ACFS use COW. I would be vewy, vewy cawefull with COW
>>>>>> snapshots, as they can significantly slow your system down, especially if
>>>>>> redo logs are on the file system with a snapshot.
>>>>>>
>>>>>> --
>>>>>> Mladen Gogala
>>>>>> Oracle DBAhttp://mgogala.freehostia.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Mar 28 2015 - 05:07:47 CET