RE: [Exadata] How do you use FlashDisk ?
Date: Sun, 20 Mar 2011 09:09:50 -0400
Message-ID: <018901cbe700$190f7210$4b2e5630$_at_rsiz.com>
The next sentence:
"Testing has shown that moving redo logs on to EFDs results in a low percentage of improvement."
The article, as with your question, is indeed about guns and butter choices in the general case. That two adjacent sentences contradict one another is also not my point. I think they meant it is a misconception that moving online redo logs will benefit throughput more than moving some other things. That they will benefit is clear, as they document in the very next sentence. The question is how much, and I really wish they had shared what a "low" percentage is. The last time I did comprehensive testing it was about 7% increased throughput when log buffer flushes were only driven by log 1/3 full or timeout (not small commits and not using a silly small buffer to magnify the results). The percentage improvement should be marginally better if you have frequent small commits. Any you shouldn't use a silly small log buffer at all. A sufficient size log buffer is the primary reason the percentage improvement is "small."
If you have a lot of acreage dedicated to online redo logs to get sufficient IO/s to simultaneously support flushing the redo buffer (as on every commit, which if the redo devices are mixed with other storage may mean a seek on each and every commit [though some commits, to be fair, may be batched]) and reading to redo log to the archives, then it may be an economically correct decision to put online redo logs on electronic storage.
You need an actual test of your workload and pricing out the amount of online redo log you plan to have versus the hard disk saved in terms of spindle count, not mere acreage, to make this determination. And if you have big update jobs that barely fit (or miss by a little) in your "batch" window, a 7% improvement might be a grand thing for a small price. The value of keeping "batch" operations out of your morning shift arrival logon window only awaits a little Method-R analysis of your important interactive jobs with and without competition from the tail end of batch to help you access whether this should be important to you.
In agreement with the overall theme, you might get much better percentage throughput increases with other uses of electronic persistent media. But putting online redo logs on electronic media definitely makes them faster, as all the experimental data anyone has ever shown me indicates (including this article). Whether it is a good economic choice for your actual operational system has to be tested.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Greg Rahn
Sent: Saturday, March 19, 2011 2:02 PM
To: jkstill_at_gmail.com
Cc: robertgfreeman_at_yahoo.com; surachart_at_gmail.com; Oracle-L_at_freelists.org
Subject: Re: [Exadata] How do you use FlashDisk ?
"It is a common misconception that Oracle online redo logs will benefit by
moving them on EFDs, whereas all the experimental data indicates the
opposite position"
page 17
http://www.emc.com/collateral/hardware/white-papers/h5967-leveraging-clariio
n-cx4-oracle-deploy-wp.pdf
On Sat, Mar 19, 2011 at 10:53 AM, Jared Still <jkstill_at_gmail.com> wrote:
>
>
> On Sat, Mar 19, 2011 at 6:58 AM, Robert Freeman
> <robertgfreeman_at_yahoo.com>
> wrote:
>>
>> Flash disks for WRITE operations are actually not that fast. I don't
>> have the performance numbers here, but you really don't buy anything
>> in terms of write performance with flash disks. So I would not
>> recommend them for a disk group that will contain, say, online redo logs.
>
> Interesting observation Robert.
> From the two guys at LSI that test flash memory with Oracle:
> "Online redo logs are best handled by Hard Disk Drives because of the
> sequential writes"
-- Regards, Greg Rahn http://structureddata.org -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Sun Mar 20 2011 - 08:09:50 CDT