If you are using Database Managed Storage (DMS) device containers for your table spaces, you need to understand the following so you can effectively administer your environment:
Table data read from disk is normally available in the database's buffer pool (see "Managing the Database Buffer Pool"). In some cases, a data page can be freed from the buffer pool before the application has actually used that page. (This can happen if the buffer pool space is required for other data pages.) For table spaces using system managed storage (SMS), when the database manager subsequently requests the page from the file system, the file system may still have that page in its own cache. This can eliminate I/O that would otherwise have been required.
Table spaces using database managed storage (DMS) device containers do not use the file system or its cache. As a result, you may wish to increase the size of the database buffer pool and reduce the size of the file system cache to offset the fact that double buffering is not being done with DMS table spaces that use device containers.
If you notice, through the use of system-level monitoring tools, that I/O is higher for a DMS table space using device containers compared to the equivalent SMS table space, this difference could be due to the double buffering discussed above.
When an application retrieves either LOB or LONG data, the database manager does not use its buffers to cache the data. Every time an application needs one of these pages, the database manager must retrieve it from disk.
If LOB or LONG data is stored in SMS or DMS-file table spaces, then there is a chance that the operating system may cache the pages in main memory and thus it will be accessed more quickly (because it is faster to retrieve pages from main memory than from disk).
Because system catalogs contain some LOB columns, it is recommended that you keep them in SMS (or alternatively in DMS-file) table spaces.