Re: ODA 12.1.2 Databases on ACFS
Date: Tue, 27 Jan 2015 16:27:27 +0000
Message-ID: <512593236.767835.1422376046724.JavaMail.yahoo_at_mail.yahoo.com>
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_at_gmail.com>
To: dmarc-noreply_at_freelists.org
Cc: Oracle-L Freelists <oracle-l_at_freelists.org>
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_at_freelists.org> 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:
- Read the old data
- Write the old data to the snapshot pool location
- 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
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 27 2015 - 17:27:27 CET