Check yur fax... Oracle does NOT recommend cooked nor raw files. In
_ORACLE for Sun Performance Tuning Tips_ manual, it lists the tradeoffs
between the two issues. I summarize that below.
*All* high-capacity production Oracle databases I've worked with have
been stored on a cooked fs. And believe me I've setup and/or fixed some
really hairy Oracle7/8 configs. :) The ease of maintenance on a cooked
fs always outweighted the performance gain on a raw fs.
It is *much* cheaper to buy new hardware to support a cooked fs when it
gets loaded, than it is to pay an admin to support and maintain an
Oracle db on one or more raw partitions.
Jeff
Paraphrased excerpts from _ORACLE for Sun Performance Tuning Tips_:
Tip No. 1: Use async I/O (AIO)
Presumably under Linux this would be the threaded POSIX libaio
Tip No. 2: Use a Logical Volume Manager (LVM)
Here it refers to Online DiskSuite, which is the same as
Linux's md driver.
Tip No. 3: Use readv()
Manual notes that readv() on raw partitions is slower than
on cooked fs's.
Tip No. 5: Use RAID
Manual notes RAID5 enhances read performance, penalizes
write performance. (no surprises there)
Tip No. 7: Using UFS vs. Raw Partitions
Advantages of UFS [cooked]:
* Easier to use from operational perspective
* Sequential reads benefit substantially on lighter-load systems, because
* fs read-ahead kicks in when it detects large seq reads
* data ends up in kernel buffer cache
* fs blocksize can be chosen to match Oracle block size
Disadvantages of UFS:
* extra buffer copies. This becomes very evident under high load
* under heavy load, contention for buffers ends up becoming the
main bottleneck
* more work to be done by the pagedaemon that flushes data to fs
* more memory sacrificed to the buffer cache
Tip No. 8: Using direct I/O
Manual notes solaris 2.4 doesn't implement this.
[interesting non disk-related tips follow; gives us an idea of where
Linux should be, what it should do....]
Tip No. 9: Use processor affinity/binding on SMP systems
Tip No. 10: Tune spin count on SMP to reduce latch contention
Tip No. 11: Use Real-time scheduling
Tip No. 17: Using Intimate Shared MEmory (ISM)
Manual notes Sun's Intimate Shared Memory feature allows
idfferent processes attaching to the same shared memory address
to share the same page table. This avoids page table steealing
and threading and thus enhances db performance.
Tip No. 21: Use out-of-band breaks with SQL*Net TCP/IP
Tip No. 23: TCP/IP Performance issues
Packet size used internally by SQL*Net v2 is 2K.
-- Jeff Garzik Typhoon, Cyclone, Diablo, and INN http://www.spinne.com/usenet/ News tuning and consulting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html