DB2 Version 9.7 for Linux, UNIX, and Windows

Table space containers use concurrent I/O or direct I/O by default

The default I/O mechanism for table space containers on most AIX®, Linux, Solaris, and Windows platforms is CIO/DIO (concurrent I/O or direct I/O). This default provides an increase of throughput over buffered I/O on heavy transaction processing workloads and rollbacks.

The FILE SYSTEM CACHING or NO FILE SYSTEM CACHING attribute specifies whether I/O operations are to be cached at the file system level:

If large object (LOB) data is inlined, then it is accessed as regular data and uses the I/O method (buffered or non-buffered) specified for the table space FILE SYSTEM CACHING attribute.

If large object (LOB) data is not inlined, then the following statements apply:

The following interfaces contain the FILE SYSTEM CACHING attribute:

When this attribute is not specified on the CREATE TABLESPACE statement, or on the CREATE DATABASE command, the database manager processes the request using the default behavior based on the platform and file system type. See File system caching configurations for the exact behavior. For the sqlecrea() API, a value of 0x2 for the field sqlfscaching field, instructs the database manager to use the default setting.

The following tools currently interpret the value for FILE SYSTEM CACHING attribute:
  • GET SNAPSHOT FOR TABLESPACES command
  • db2pd -tablespaces command
  • db2look -d <dbname> -l command
For db2look, if the FILE SYSTEM CACHING attribute is not specified, the output does not contain this attribute.

Example

Suppose that the database and all related table space containers exist on an AIX JFS file system and the following statement was issued:
    DB2 CREATE TABLESPACE JFS2
If the attribute was not specified, the database manager uses NO FILE SYSTEM CACHING.