Very large database on 32 bit SLES9?

I did not expect more from a polyserve employee. You have to say so, I
understand.

Am Donnerstag 24 August 2006 18:02 schrieb Kevin Closson:
In doubt, consider choosing ASM as backend! ASM can handle
this, and you will skip the imponderabilities of a file
system this way.

"Imponderabilities of a file system"? databases
have been created in filesystems for 30 years. The highest
majority of all databases are sitting in a filesystem
today (ufs,vxfs,ext3, etc). What does this statement mean?
How can something that is fresh technology immediately
invalidate the majority of current production systems and
the majority over the last 30 years? And even
maintains a program called the Validated Third Party CFS
program to ensure customers have choices. Non-CFS filesystems
are certified by the S vendor.

considers blocks written as physically written
a cache below blows up this strategy.

This is a non-issue. Ext3, XFS and PolyServe (since I mentioned it),
all support direct I/ (filesystemio_options=DirectI). But even that
aside, it is only RAC that absolutely requires direct I/ The
original post could not have been about RAC since the database
is currently in Ext3.

Non-RAC instances are executing in tremendous numbers all around
the world in buffered filesystems today direct I/ That works
just fine since the writes are synced with either the SYNC
open flag or by calling fsync depending on the port. I don't
recommend using a buffered filesystem, but only for the sake
of how inefficient it is to double buffer and the cost of
the memcopy operations to/from the S buffer into the user
address space on every database I/