|
Author's name: Neil Johnson Author's name: Harvinder
Kumar Author's Email: oracle@thirdchimp.net |
Date written: 26-June-2005 Oracle version(s): All |
|
Both Oracle and Unix have a buffer cache - is there a relationship between the two, what should we consider when both of these are present? (Coincidentally, two answers arrived simultaneously – partly because I lost track of WIP) |
|
In short there is no direct relationship between the Oracle and Unix buffer caches aside from the fact they both cache data to prevent physical IO. With regard to data stored in Oracle data files Oracle's buffer cache mostly eliminates the need for the Unix buffer cache however, with a little effort, you can get the best out of both of them.
There are two aspects to consider:
There is a good description of asynchronous and direct IO in the the Database Performance Tuning Guide linked to at the foot of this page.
In general it is probably a good idea to allow your Oracle home to sit in a file system that uses the Unix cache but put your database files into file systems that utilise direct IO (if supported) to bypass the Unix cache (save for a few oddities such as temporary tablespace data**).
Eg (taken from AIX):
[oracle:PROD] /u01/app/oracle/product/10.1.0 >mountnode mounted mounted over vfs date options
-------- --------------- --------------- ------ ------------ ---------------
...
/dev/lvora01 /u01 jfs2 Jun 23 15:48 rw,log=/dev/loglv01
/dev/lvora02 /u02 jfs2 Jun 23 15:48 rw,dio,log=/dev/loglv02
/dev/lvora03 /u03 jfs2 Jun 23 15:48 rw,dio,log=/dev/loglv03
...
Here /u01 uses the Unix buffer cache and contains $ORACLE_BASE (/u01/app/oracle) and certain specific oracle database files (/u01/oradata). /u02 upwards are then all set to bypass the Unix buffer cache - you can see this from the "dio" parameter under options. This could also be "cio" which means concurrent IO and utilises direct IO plus an extra tune around file inode serialisation.
In summary, if your Unix system supports direct IO to bypass the Unix buffer cache then you should at least try it out. You could potentially free up CPU time and memory to be used by other processes. It is generally understood that a system with well configured file systems in regard to the Unix buffer cache can rival the performance of raw data files however, having never used a raw file system, I cannot confirm either way.
* Bear in mind that there is a good chance your disks are actually logical units in a SAN which will also have its own hefty cache.
** Temp is a good example of why the Unix buffer cache is useful as the data to be written is not cached by Oracle and will more often than not be read back in the near future - the buffer cache can satisfy this request. Redo logs are similar in that they are written to by LGWR and read again by ARCH.
Unix File system has a buffer cache and Oracle also maintains its own cache. The buffers are being copied from Kernel Space(File system buffer cache) to User Space(Oracle Buffer Cache). This operation generates a lot of overhead. But in case of raw devices, a write to a raw device bypasses the Unix Buffer Cache , the data is transferred direct from Oracle buffer to the disk. So, write performance enhanced with the use of raw devices.
Database Performance Tuning Guide