Note: The VERITAS Storage Foundation for the DB2 database manager might have dif

ferent operating system prerequisites. The platforms listed above is the prerequ
isite for the current DB2 release. Consult the VERITAS Storage Foundation for DB
2 support information for the prerequisite information.
The operating system, by default, caches file data that is read from and written
to disk. A typical read operation involves physical disk access to read the dat
a from disk into the file system cache, and then to copy the data from the cache
to the application buffer. Similarly, a write operation involves physical disk
access to copy the data from the application buffer into the file system cache,
and then to copy it from the cache to the physical disk. This default behavior o
f caching data at the file system level is reflected in the DB2 table space clau
se: FILE SYSTEM CACHING with the default value of "Yes". Since the DB2 database
manager 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 appropriatel
y. In some cases, caching at the file system level and in the DB2 buffer pools c
auses performance degradation because of the extra CPU cycles required to do the
double caching.
To avoid this double caching, most file systems have a feature that disables cac
hing at the file system level. This is generically referred to as non-buffered I
/O. On UNIX, this feature is commonly known as Direct I/O (or DIO). On Windows,
this is equivalent to opening the file with the FILE_FLAG_NO_BUFFERING flag. In
addition, some file systems such as IBM® JFS2 or VERITAS VxFS also support enhance
d Direct I/O, that is, the higher-performing Concurrent I/O (CIO) feature. The D
B2 database manager automatically takes advantage of CIO on file systems where t
his feature exists. These features might help to reduce the memory requirements
of the file system cache, thus making more memory available for other uses.
As stated above, the DB2 database manager automatically enables file system cach
ing when performing I/O. To disable it, you can use the CREATE TABLESPACE or ALT
ER TABLESPACE statements. Use the NO FILE SYSTEM CACHING clause to enable non-bu
ffered I/O, thus disabling file caching for a particular table space. Once non-b
uffered I/O is enabled, the DB2 database manager automatically determines which
of the DIO or CIO is to be used on all platforms. Given the performance improvem
ent in CIO, the DB2 database manager uses it whenever it is supported; there is
no user-interface to specify which one is to be used.
In order to obtain the maximum benefits of non-buffered I/O, it might be necessa
ry to increase the size of DB2 buffer pools to mitigate any loss of benefit from
file caching.
The recommended method of enabling non-buffered I/O is at the table space level,
using the DB2 implementation method. This method allows you to apply non-buffer
ed I/O on specific table spaces while avoiding any dependency on the physical la
yout of the database. It also allows the DB2 database manager to determine which
I/O is best used for each file, buffered or non-buffered.
The clauses NO FILE SYSTEM CACHING and FILE SYSTEM CACHING can be specified in t
he CREATE TABLESPACE and ALTER TABLESPACE statements to disable or enable file s
ystem caching, respectively. The default is FILE SYSTEM CACHING. In the case of
ALTER TABLESPACE, existing connections to the database must be terminated before
the new caching policy takes effect.
Example 1: CREATE TABLESPACE <table space name>...
By default, this new table space will be created using buffered I/O; the FILE SY
STEM CACHING clause is implied.
Example 2: CREATE TABLESPACE <table space name> ... NO FILE SYSTEM CACHING
The new NO FILE SYSTEM CACHING clause indicates that file system level caching w
ill be OFF for this particular table space.
Example 3: ALTER TABLESPACE <table space name> ... NO FILE SYSTEM CACHING
This statement disables file system level caching for an existing table space.
Example 4: ALTER TABLESPACE <table space name> ... FILE SYSTEM CACHING
This statement enables file system level caching for an existing table space.
This method of disabling file system caching provides control of the I/O mode, b
uffered or non-buffered, at the table space level. Note that I/O access to Long
Field (LF) and Large Objects (LOBs) will be buffered for both SMS and DMS contai
ners.
The GET SNAPSHOT FOR TABLESPACES command can be used to query the current settin
g of the file system caching clause. For example, the following is a snippet fro
m the DB2 GET SNAPSHOT FOR TABLEPSACES ON db1 output:
Tablespace name = USERSPACE1
Tablespace ID = 2
Tablespace Type = Database managed space
Tablespace Content Type = All permanent data. Large table spa
ce.
Tablespace Page size (bytes) = 4096
Tablespace Extent size (pages) = 32
Automatic Prefetch size enabled = Yes
Buffer pool ID currently in use = 1
Buffer pool ID next startup = 1
Using automatic storage = Yes
Auto-resize enabled = Yes
File system caching = Yes
Tablespace State = 0x'00000000'
Detailed explanation:
Normal
Tablespace Prefetch size (pages) = 32
Total number of pages = 256
Alternate methods to enable non-buffered I/O on UNIX
Some UNIX platforms support the disabling of file system caching at a file syste
m level by using the MOUNT option. Consult your operating system documentation f
or more information. However, it is important to understand the difference betwe
en disabling file system caching at the table space level and at the file system
level. At the table space level, the DB2 database manager controls which files
are to be opened with and without file system caching. At the file system level,
every file residing on that particular file system will be opened without file
system caching. Some platforms such as AIX have certain requirements before you
can use this feature, such as serialization of read and write access. While the
DB2 database manager adheres to these requirements, if the target file system co
ntains non-DB2 files, before enabling this feature, consult your operating syste
m documentation for any requirements.
In DB2 Version 8.1 FixPak 4, the registry variable DB2_DIRECT_IO disables file s
ystem caching for all SMS containers except for Long Field (LF), Large Objects (
LOBs), and temporary table spaces on AIX JFS2. With the ability to enable this f
eature at the table space level, starting in DB2 Version 8.2, this registry vari
able has been deprecated. Setting this registry variable in DB2 Version 9.1 is e
quivalent to altering all table spaces, SMS and DMS, with the NO FILE SYSTEM CAC
HING clause.
Alternate methods to enable non-buffered I/O on Windows
In previous DB2 releases, the performance registry variable DB2NTNOCACHE could b
e used to disable file system caching for all DB2 files. This option remains ava
ilable. The difference between DB2NTNOCACHE and using the NO FILE SYSTEM CACHING
clause is the ability to disable caching for selective table spaces.

--------------------------------------------------------------------------------
------
Buffer pool management
A buffer pool is memory used to cache table and index data pages as they are bei
ng read from disk, or being modified. The buffer pool improves database system p
erformance by allowing data to be accessed from memory instead of from disk. Bec
ause memory access is much faster than disk access, the less often the database
manager needs to read from or write to a disk, the better the performance. Becau
se most data manipulation takes place in buffer pools, configuring buffer pools
is the single most important tuning area. Only large objects and long field data
are not manipulated in a buffer pool.
When an application accesses a row of a table for the first time, the database m
anager places the page containing that row in the buffer pool. The next time any
application requests data, the database manager looks for it in the buffer pool
. If the requested data is in the buffer pool, it can be retrieved without disk
access, resulting in faster performance.
Memory is allocated for the buffer pool when a database is activated or when the
first application connects to the database. Buffer pools can also be created, d
ropped, and resized while the database is manager is running. If you use the IMM
EDIATE keyword when you use the ALTER BUFFERPOOL statement to increase the size
of the buffer pool, memory is allocated as soon as you enter the command if the
memory is available. If the memory is unavailable, the change occurs when all ap
plications are disconnected and the database is reactivated. If you decrease the
size of the buffer pool, memory is deallocated at commital time. When all appli
cations are disconnected, the buffer pool memory is de-allocated.
Note:
To reduce the necessity of increasing the size of the dbheap database configurat
ion parameter when buffer pool sizes increase, nearly all buffer pool memory, wh
ich includes page descriptors, buffer pool descriptors, and the hash tables, com
es out of the database shared memory set and is sized automatically.
To ensure that an appropriate buffer pool is available in all circumstances, DB2
(R) creates small system buffer pools, one with each page size: 4K, 8K, 16K, and
32K. The size of each buffer pool is 16 pages. These buffer pools are hidden fr
om the user. They are not present in the system catalogs or in the buffer pool s
ystem files. You cannot use or alter them directly, but DB2 uses these buffer po
ols in the following circumstances:
When a buffer pool of the required page size is inactive because insufficient me
mory was available to create it after a CREATE BUFFERPOOL statement was executed
with the IMMEDIATE keyword.
A message is written to the administration notification log. If necessary, table
spaces are remapped to a system buffer pool. Performance might be drastically r
educed.
When the ordinary buffer pools cannot be brought up during a database connect
This problem is likely to have a serious cause, such as out-of-memory condition.
Although DB2 will be fully functional because of the system buffer pools, perfo
rmance will degrade drastically. You should address this problem immediately. Yo
u receive a warning when this occurs and a message is written to the administrat
ion notification log.
Pages remain in the buffer pool until the database is shut down, or until the sp
ace occupied by a page is required for another page. The following criteria dete
rmine which page is removed to bring in another page:
How recently the page was referenced
The probability that the page will be referenced again by the last agent that lo
oked at it
The type of data on the page
Whether the page was changed in memory but not written out to disk (Changed page
s are always written to disk before being overwritten.)
In order for pages to be accessed from memory again, changed pages are not remov
ed from the buffer pool after they are written out to disk unless the space is n
eeded.
When you create a buffer pool, the default page size is the size specified when
the database was created unless you explicitly specify a page size other than th
e default page size. Because pages can be read into a buffer pool only if the ta
ble space page size is the same as the buffer pool page size, the page size of y
our table spaces should determine the page size that you specify for buffer pool
s. You cannot alter the page size of the buffer pool after you create it. You mu
st create a new buffer pool with a different page size.
The memory tracker, invoked by db2mtrk, allows you to view the amount of databas
e memory allocated to the buffer pools. The following sample db2mtrk output show
s one user-created buffer pool, identified by the number "1" in parentheses, and
four system buffer pools, identified by the page size in parentheses:
> db2mtrk -d
Tracking Memory on: 2005/10/24 at 12:47:26
Memory for database: XMLDB
utilh pckcacheh catcacheh bph (1) bph (S32K) bph (S16K) bph (S8K)
64.0K 576.0K 64.0K 4.2M 576.0K 320.0K 192.0K
bph (S4K) shsorth lockh dbh other
128.0K 0 640.0K 4.2M 192.0K
Note:
On 32-bit platforms that run Windows(R), you can create large buffer pools if yo
u have enabled Address Windowing Extensions (AWE) or Advanced Server and Data Ce
nter Server on Windows.