Re: To ODA or Not?
- From: Seth Miller <sethmiller.sm@xxxxxxxxx>
- To: Backseat DBA <backseatdba@xxxxxxxxx>
- Date: Fri, 27 Mar 2015 21:45:26 -0500
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@xxxxxxxxx> 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@xxxxxxxxx>
> 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@xxxxxxxxx>
>> wrote:
>>
>>> We are not using RAC here.
>>>
>>> On Fri, Mar 27, 2015 at 4:22 PM, Jeff Chirco <backseatdba@xxxxxxxxx>
>>> 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@xxxxxxxxxxxxx> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
Other related posts:
