Bob Sneed makes a good point about direct I/O with regards to preparation for moving to RAC (should you find yourself in that position). I know exactly what he is talking about as I’ve seen people hit with the rude awakening of switching from buffered to unbuffered I/O while trying to implement RAC. The topic is related to the troubles people see when they migrate to RAC from a non-RAC setup where regular buffered filesystems are being used. Implementing RAC forces you to use direct I/O (or RAW) so if you’ve never seen your application work without the effect of external caching in the OS page cache, going to RAC will include this dramatic change in I/O dynamic. All this at the same time as experiencing whatever normal RAC phenomenon your application may hit as well.
In this blog entry, Bob says:
If you ever intend to move a workload to RAC, tuning it to an unbuffered concurrent storage stack can be a crucial first step! Since there are no RAC storage options that use OS-level filesystem buffering […]
Direct I/O
Bob stipulates “unbuffered concurrent” since Solaris has a lot of different recipes for direct I/O some of which do not throw in concurrent I/O automatically. If you’ve been following my blog, you’ve detected that I think it is a bit crazy that there are still technology solutions out there that do not automatically include concurrent I/O along with direct I/O.
Here are some links to my recent thread on direct I/O :
Standard File Utilities with Direct I/O
Oracle Direct I/O Brought to You By Deranged Monkeys
Direct I/O Can Crash Dataguard. Tricky ORA-01031.
DBWR with CIO on JFS2. Resource Starvation?
What Performs Better, Direct I/O or Direct I/O? There is No Such Thing As a Stupid Question!
Kevin Closson's Blog: Platforms, Databases and Storage 
0 Responses to “Experience Direct I/O Before Experiencing RAC”