RE: filesystemio_options setting
Date: Fri, 16 May 2008 11:27:05 -0400
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.
-- 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,Received on Fri May 16 2008 - 10:27:05 CDT
> 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
> 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