![]() |
![]() |
Over time, the database size and organization can change to the point that performance is degraded. Unloading and reloading the database can have the following benefits:
The database and recovery log buffer pool sizes can also affect performance. A larger database buffer pool can improve performance. A larger recovery log buffer pool reduces how often the server forces records to the recovery log.
See Reorganizing the Database for more information about restoring database efficiency.
You can let Tivoli Storage Manager dynamically adjust the size of the database buffer pool or you can adjust it manually. If you specify YES for the SELFTUNEBUFPOOLSIZE server option, the database buffer pool is dynamically adjusted. The cache hit ratio statistics for the buffer pool are reset at the beginning of expiration. After expiration processing completes, the buffer pool size is adjusted dynamically.
Server expiration processing resets the database buffer pool before the next processing starts and examines if the database buffer pool cache hit ratio is above 98%. If the cache hit ratio is lower than 98%, the database buffer pool will be increased; if it is higher, the buffer pool size will not change. Increasing the database buffer pool will not be more than 50% of region size.
VSAM I/O pages can be fixed to allow a faster throughput of data for operations involving the database, the recovery log, and all storage pool volumes. Specifying a size for the VSAM pages can significantly reduce the locking and unlocking of VSAM pages while operations are occuring to and from disk storage pool volumes.
Perform the following steps to track the database buffer pool statistics and adjust the buffer pool size:
Reset the buffer pool statistics. Initially, you might want to reset the statistics twice a day. Later, you can reset them less often. To reset, enter:
reset bufpool
To see if the database buffer pool is adequate for database performance, enter:
query db format=detailed
The server displays a report, like this:
+--------------------------------------------------------------------------------+ | Available Space (MB): 196 | |Assigned Capacity (MB): 196 | |Maximum Extension (MB): 0 | |Maximum Reduction (MB): 176 | | Page Size (bytes): 4,096 | | Total Pages: 50,176 | | Used Pages: 4,755 | | %Util: 9.5 | | Max. %Util: 9.5 | | Physical Volumes: 5 | | Buffer Pool Pages: 128 | | Total Buffer Requests: 1,193,212 | | Cache Hit Pct.: 99.73 | | Cache Wait Pct.: 0.00 | +--------------------------------------------------------------------------------+
Use the following fields to evaluate your current use of the database buffer pool:
Use the BUFPOOLSIZE server option to set the size of the database buffer pool.
Do the following to adjust the size of the recovery log buffer pool:
To see how the recovery log buffer pool size affects recovery log performance, enter:
query log format=detailed
The server displays a report, like this:
+--------------------------------------------------------------------------------+ | Available Space (MB): 12 | |Assigned Capacity (MB): 12 | |Maximum Extension (MB): 0 | |Maximum Reduction (MB): 8 | | Page Size (bytes): 4,096 | | Total Pages: 3,072 | | Used Pages: 227 | | %Util: 7.4 | | Max. %Util: 69.6 | | Physical Volumes: 1 | | Log Pool Pages: 32 | | Log Pool Pct. Util: 6.25 | | Log Pool Pct. Wait: 0.00 | +--------------------------------------------------------------------------------+
Use the following fields to evaluate the log buffer pool size:
If this value is greater than 0, increase the recovery log buffer pool size.
Use the LOGPOOLSIZE server option to set the size of the recovery log buffer pool.
Over time, database volumes become fragmented. You can restore the efficiency of the database and improve database performance by reorganizing the database using database unload and reload processing. By reloading the database, you compress and reorganize it.
Attention: Before you begin this procedure, perform a backup of your database. If an outage occurs while you are loading and reloading your database, you can use your backup copy for recovering the database.
The DSMSERV UNLOADDB operation assumes that the Tivoli Storage Manager database is usable and reads device information from the database, not from the device configuration file. A database dump operation (DSMSERV DUMPDB), on the other hand, does not assume a usable database and reads from the device configuration file.
To reorganize the database, follow these steps:
query db
dsmserv unloaddb devclass=tapeclass scratch=yes
dsmserv loadformat 2 logvol1 logvol2 1 dbvol1
This utility prepares the existing server database for the DSMSERV LOADDB utility.
dsmserv loaddb devclass=tapeclass volumenames=db001,db002,db003For the volume names, ensure that you do the following: