Re: ODA 12.1.2 Databases on ACFS
- From: "Kevin Closson" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "ora_kclosson@xxxxxxxxx" for DMARC)
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 27 Jan 2015 16:27:26 +0000 (UTC)
You are right, Seth. It's not just a Linux box with Oracle, ASM and ACFS. But
it is, in fact, just an OL box and the fact that Oracle licenses the market
domonant RDBMS differently on this stack of pizza boxes differently than OL on
someone else's stack of pizza boxes *should* make Oracle's customers upset.
Especially since "someone else's" in the collective towers over the volumes
represented by ODA shipments. To put it another way, people *want* to buy Brand
XYZ and *have to run* Oracle Database. For this reason there should be a lot
more rage about these pricing tricks.
But...
From: Seth Miller <sethmiller.sm@xxxxxxxxx>
To: dmarc-noreply@xxxxxxxxxxxxx
Cc: Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
Sent: Monday, January 26, 2015 6:43 AM
Subject: Re: ODA 12.1.2 Databases on ACFS
Thanks Mladen. I appreciate your feedback.
ODA is certainly not just a Linux box with Oracle, ASM and ACFS. And yes, it is
RAC.
Seth Miller
On Mon, Jan 26, 2015 at 6:07 AM, Mladen Gogala <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
On 01/25/2015 11:40 PM, Seth Miller wrote:
As of release 12.1.2.0 of the ODA software, all database are created on ACFS
(CloudFS) by default.
Has anyone implemented this strategy outside of the ODA?
If you have used this on ODA or otherwise, do you have any feedback on it?
Are you utilizing the snapshot ability?
Seth Miller
I have tested ACFS on a normal Oracle 12c RAC system with 2 Dell boxes,
connected to a NetApp filer. The systems were running RHEL 6.5, 64bit. LUNs
were "scsified" (no ASMLib) and put into ASM. The kernel had no problems
building the ACFS drivers and the database performance was quite good, but
there . ACFS One notable omission is that there is no defragmenter, which is
not very important for a database, but is important if you want to keep other
types of files which are frequently created and deleted, like archive logs.
Snapshots, however, are CoW (copy on write) and that method has known drawback
of tripling the IO rate for writes because the kernel has to do the following:
1) Read the old data
2) Write the old data to the snapshot pool location
3) Write the new data.
That is what "copy-on-write" means. You will do that for every FS block and for
every snapshot. If there are two snapshots of your database, the system will do
6 IO operations for every write request. With all due respect to Dell, their IO
throughput is not unlimited, so the whole thing slows down considerably.
Fortunately, SAN manufacturers, like NetApp have much smarter strategy known as
"deferred write snapshot" which was used instead.
Personally, I have installed Oracle 12c on Fedora 20 with Brtfs, precisely in
order to test snapshots. The results show the same problem as above. My desktop
box slows down to a crawl when inserting a million rows into the database using
Perl script to avoid the well known PL/SQL optimization with commits within the
loop. In addition to that, once you use the files on ACFS, there is no
balancing keeping the files populated to the same level. Since this was only a
test configuration, the production DB is still running 11.2.0.4, the client
eventually decided to use ASM instead of ACFS. I have no experience with ODA,
but my understanding is that it is a Linux box with Oracle, ASM & ACFS, no RAC.
--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
