Re: Raw partitions on HPUX 10 and Oracle 7.3.2

"Michael J. Hillanbrand II" <mjhii_at_pop.erols.com> wrote:

>--
>All good stuff. No Proof. Just blind assertions - real scientists these folks.
 

>contact gil asherie at quest software - his partner
>Eyal Aronoff has the proof. gil_at_quests.com

If you want to prove something to me, you’ll have to do better than respond with sound bites.

All other things being equal, raw partitions ARE more efficient than writing to filesystems, period. You have removed a layer of software, and its corresponding overhead. This is not just my opinion either. Try asking some HP and Oracle consultants who specialize in benchmarking large systems. If you want names, I'll give them to you in e-mail.

The open questions are:

1. How much does "raw" really buy?
2. Is it worth the trouble?

The answer to #1 is, "It depends". It depends on your platform, number of bus converters (on an HP T5xx), distribution of controllers across the converters, number and type of SCSI controllers (single ended or fast/wide), number of drives per controller, drive speed, capacity, cache, etc., not to mention the pattern of database activity.

In other words, every system is different. Therefore, there is no absolute "proof", unless you plan to benchmark every application with both raw and filesystem versions of the same database.

For example, I suspect (but don’t "know" for lack of benchmarking) that going raw buys you LESS on a Sun SPARCServer than on an HP system. That’s because async I/O is available--and turned on by default--for both filesystem and raw on Sun. Life is good.

But in the HP environment, async I/O only happens if: 1. Your database is raw; 2. You include the asyncdsk driver via SAM and rebuild the UNIX Kernel; 3. You create the /dev/async pseudo device; 4. You add “use_async_io=true” to your init<sid>.ora file (7.3 only). Life is tough, relatively speaking.

This leads into question #2, is it worth the trouble? That’s a judgment call. There are still some caveats to consider before jumping into raw.

For small applications, low-volume applications, or on systems that don’t have LVM, I agree, stick with filesystems.

As you point out, disk striping can do wonders--for both filesystems and raw logical volumes. Converting a non-striped filesystem database to a striped filesystem database is the greater performance gain. All I’m saying is, striping AND raw would be even better than striping alone. But if you only choose one, striping should be the first choice.

If you have the money, buying high performance drives like EMC will definitely be the greater gain. (Rather like the muscle cars of the 1960’s. Aerodynamics? We don’t need no stinking aerodynamics!)

But if you are responsible for a large, high volume database, you better make sure you’ve eked out every possible performance gain. I’m working on a database now that is expected to begin life at 100GB, and then get serious. It’s on an HP T520 with 4 CPU’s, 1.5GB RAM, 10 F/W SCSI controllers across 5 bus converters--for starters. The database itself uses async I/O with striped, raw logical volumes on EMC drives. The EMC controller has 2GB cache, and will be expanded later to 4GB. Once we run out of CPU and memory expansion options (including the newly announced PA-RISC 8000 chip), the only other option I see is implementing Parallel Server. Unless I’ve missed something.

I’m open to suggestions for how to improve performance.

BTW, for those interested in raw, watch out for the "use_readv=true" init parameter. While it helps I/O performance in filesystems, it actually hurts raw I/O performance on Sun and HP--the two systems I know for sure--and possibly other platforms as well.

---
Bolen Coogler
DBA, BellSouth Information Systems