Lots of you use DB2 on SAN storages either from IBM or EMC or other third party. Most of SAN storages have their own caching which is to enhance the performance. After working with many DB2 users, I have found that these file system caching is not used properly to use DB2 efficiently.
The following is just a rule of thumb that you can apply while talking to your storage administrator to turn on or off READ/WRITE cache at the controller level.
DB2 Feature Read cache enabled Write cache enabled DB2 LOGS No Yes DB2 Temporary table spaces No Yes DB2 DMS table spaces Yes Yes DB2 SMS table spaces No Yes
If you are using Windows platform, you can turn off file system caching for LOGS by enabling DB2 registry variable DB2NTNOCACHE.
If you are creating table spaces, you can specify NO FILE SYSTEM CACHING clause in your CREATE TABLE SPACE or ALTER TABLE SPACE command. DB2 manages its own data caching using buffer pools, the caching at the file system level is not needed if the size of the buffer pool is tuned appropriately. DB2 attempts to use Concurrent I/O (CIO) wherever possible. It will use Direct I/O (DIO) or buffered I/O on systems where where CIO is not supported. CIO and DIO improve memory performance because these settings allow DB2 to bypass caching at the file system level. This process reduces CPU overhead and makes more memory available to the database instance.
DB2 9.5 uses NO FILE SYSTEM CACHING on new table spaces be default but not on the ones that you migrated from previous versions so you should use ALTER TABLE SPACE to turn it off.
ALTER TABLESPACE table space name ... NO FILE SYSTEM CACHING
CIO is better than DIO and CIO is only supported on JFS2 on Aix. You should not enable CIO on your sqllib directory but should definitely enable it on your LOGS and archive logs directory where logs are stored and archived.