RE: filesystemio_options setting

To expand upon this a little bit, for redundancy's sake Oracle writes multiple copies of a given block, between the redo logs, archive logs, datafiles, etc. In a filesystem cache scenario, you're gonna end up with a lot of unnecessary duplicate blocks of memory sitting around doing nothing, while Oracle can know that a block is a block and just cache it once.

This, on a somewhat related note, turns out to be the same problem with using storage-level or OS-level replication - because they just see blocks of data, you end up with a pile of unnecessary data being replicated across the wire. There are advantages to storage-level replication too, but efficiency in database environments is not one of them.

Matt

--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito_at_gridapp.com
http://www.gridapp.com



-----Original Message-----
From: oracle-l-bounce_at_freelists.org on behalf of Finn Jorgensen
Sent: Fri 5/16/2008 11:17 AM
To: adar666_at_inter.net.il
Cc: oracle-l_at_freelists.org
Subject: Re: filesystemio_options setting
 
Adar,



> By bypassing the file system cache you need to access the storage system

> more often.

> The storage system needs to keep in it's cache the blocks previously held

> in the file system cache, effectively decreasing the hit ration for the

> cache.

> This increase the number of physical I/Os and thats leads to degradation.

<snip>

The assumption we've all been making here is that by going to direct
IO you move the part of memory that had been used as a filesystem
cache to the SGA/db cache. The idea is Oracle is better at managing
the cache of it's data than some filesystem which has no idea what's
accessing it's data. That negates your logic because the same amount
of memory is being used as cache, except now Oracle manages all of it.

Thanks,
Finn
--
http://www.freelists.org/webpage/oracle-l




--
http://www.freelists.org/webpage/oracle-l