Richard Elling wrote:
On Thu, 2006-05-11 at 10:27 -0700, Richard Elling wrote:
On Thu, 2006-05-11 at 10:31 -0600, Gregory Shaw wrote:
A couple of points/additions with regard to oracle in particular:
When talking about large database installations, copy-on-write may
or may not apply. The files are never completely rewritten, only
changed internally via mmap(). When you lay down your database, you
will generally allocate the storage for the anticipated capacity
required. That will result in sparse files in the actual filesystems.
This is counter to my Oracle experience, which I'll admit is dated.
Oracle will zero-fill the tablespace with 128kByte iops -- it is not
sparse. I've got a scar. Has this changed in the past few years?
I hit [send] too soon. Here is a writeup on how I got scarred, and
healed :-) I wrote it up so that hopefully someone else would be
spared the agony. I guess Peter didn't read Sun BluePrints :-O
http://www.sun.com/blueprints/0400/ram-vxfs.pdf
Don't blame me, I wasn't at Sun at the time. :) It does, however, sound much
like what happened to me other than the fact the server and database were a
couple orders of magnitude bigger in my case. And we weren't using VxFS so
discovered_direct_io wasn't an option. Having a multi-terabyte database lock
up is a great way to learn how important performance is to some people... ;) I
just hope ZFS doesn't have this problem with multi-terabyte databases.
- Pete
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
