oracle (raw|cooked) lv performance white papers?

[Doug O'Leary]

Hey;

Hopefully, this won't start a religious war. I'm looking for documented tests and/or white papers that compare/contrast oracle's performance under HPUX 11.i and 11.23 between raw and cooked filesystems. The most recent one I could find is an Oracle/HP white paper from 04/04.

The readers' digest version of that is that raw volumes are still faster - up to 92% faster under heavy workload as referenced on page 7 of the document.

I honestly don't have a horse in this race; I couldn't care less whether the dbas use raw or cooked. I did say I'd try to locate some white papers that compare/contrast them and, so far, have found only the one.

Is anyone aware of any other documented studies comparing/constrasting oracle performance using raw and cooked logical volumes?

Thanks for your time and help.

Doug O'Leary

[Steven E. Protter]

Shalom Doug,

Someone here, A. Clay Stepenson did some real life testing raw versus cooked.

As I recall, He used Oracle on 10.20 11.00 and 11.11 raw versus cooked filesystem. the performance advantage was negligible on 11.11

How the test results come out when Oracle runs test depends on the conditions.

As the OS improves over time, I've found that any performance benefits from raw filesystems is outweighed by the lack of flexibility that raw filesystems present. OS cold backups are possible on filesystems, not on raw filesystems.

SEP

[sysadm_1]

Cooked file system is better in perspective of management.Like backup , restore,volume management etc.Our DBA always prefer cooked filesystem instead of raw.


-sysadm-

[Doug O'Leary]

Hey;

I appreciate the posts. As I mentioned, though, I'm looking for documented studies with detailed test plans that we could use to determine how close they are to our environment.

It'll all get distributed with the caveat that the only way to be sure would be to test the SAP application on both cooked and raw filesystems. Others' tests are great, but you'll never know for sure until you're playing with your own application.

Thanks again.

Doug

[Hein van den Heuvel]

Doug, how about posting a pointer to the exact whitepaper you found, so that we talk about about the exact same one?

I _strongly_ doubt the validity of up to 92% fast. That must have been a crazy/bad/unnatural test.

I actually performed several RAW vs Cooked for a large SAP 3-tier benchmark with Oracle RAC backend in 2002. This was for HP under Tru64 Unix, the only Unix I know with a native cluster aware filesystem such that you can actually run RAC coooked. While the results where published (see link below), we could not publish the studies/detail experiment.
All I have to offer here is that the differences were in the few percent range at best (due to Direct IO?). We opted for raw, to err on the safe side mostly.
And in our setup Raw restores were easier to manage and quicker to do than cooked backup restores. ( Since this was a benchmark, we probably restored 10x more often than we made backups :-).

fwiw,
Hein.

http://www.sap.com/solutions/benchmark/sd1_results.htm

[Chan 007]

Doug,

This link provided what you are looking for.

http://www.oracle.com/technology/deploy/performance/pdf/TWP_Oracle_HP_files.pdf

Chan

[Doug O'Leary]

Hey;

I found the 92% rather surprising myself based on all the other feedback that I'd heard that stated that filesystem performance was closing in on raw. That was pretty much the reason for the post - to find any other documented tests that either validated or refuted the findings of that one.

The link that Chan 007 provided is the link to the test that I found. If you check out the 2nd paragraph on page 7, it states:

"The raw database transactional throughput with async IO has a performance improvement for the Heavy Workload of 92% over the filesystem with the following options:"...

I would guess that's best case raw vs worst case filesystem, but it's still a pretty stunning number.

Thanks for the posts.

Doug

[Alzhy]

Doug,

I also used the same HP White Paper for a client who faced a dilemma of making a decision on how to proceed. That customer followed the WP's findings. It was at first difficult as I had to educate the DBAs and their admins that managing RAW storage (w/ VxVM and LVM) is really not that difficult. The trick that hastened their understanding of RAW storage is I actually walked them through converting a mid-sized cooked DB to raw.. simple dd's of individual files to VxVM vols and established a number of links... The DBAs were equaly happy as the only thing they needed to change was to enable asyncIO and db writers.

Unfortunately I could not provide you a publicly available WP but HP's findings is generally true. Even HP-UX Gerformance Guru when I approached him at the 2004 HP World simply mentioned that RAW simply beats cooked (of whatever kind)...

[Doug O'Leary]

Hey;

Thanks for the post. My client is actually pondering going the other way - from raw to cooked filesystems based on the conventional wisdom that the performance gain of using raw filesystems is negligible. So far, I haven't found any documented evidence that backs up the conventional wisdom...

Still searching. Thanks again.

Doug

[A. Clay Stephenson]

There are so many variables in this that the only data that I would trust would be my code on my hardware. Adding to the difficulty is that not only does one have to consider database caching (SGA) and buffer cache (OS) but also one must consider the caching of the disk array (and the on-disk cache of the disks in the array). It's even possible that subsequent runs of the same code will yield different results simply from the state of the various caches as a result of prior runs. This is not unlike the suspicion with which those of us in the physical sciences view experiments in the life sciences. There are so many variables that it's difficult at times to know what one is actually measuring. This is the reason that whenever I mention my performance results I always emphasize on my equipment and with my data.

Just as an example, not long ago our DBA's were having a performance problem so they started doing all their normal stuff. Database buffer cache hit rates were extremely high and the logical and physical read rates from the OS perspective were low. Actually, the low i/o rates with respect to the OS was a big clue. I immediately suspected bad (inefficient SQL) code and it turned out that a join was being done that essentially re-read the same data over and over -- so that the code was reading data it already "knew". This code would have been a dog no matter what the hardware or disk strategy. I mention this only to say that long before you worry about disk layout, database tuning, OS tuning, raw vs. cooked, ... worry about the code.