Chapter 18.

Managing the Database and Recovery Log

The Tivoli Storage Manager database contains information that is needed for server operations and information about client data that has been backed up, archived, and space-managed. The database does not store client data. Instead, the database points to the locations of the client files in the storage pools. The database includes information about: Note: If the database is unusable, the entire Tivoli Storage Manager server is unavailable. If a database is lost and cannot be recovered, the backup, archive, and space-managed data for that server is lost. See Chapter 22, Protecting and Recovering Your Server for steps that you can take to protect your database. The recovery log contains information about database updates that have not yet been committed. Updates can include activities such as defining a management class, backing up a client file, and registering a client node. Changes to the database are recorded in the recovery log to maintain a consistent database image. The following shows authority requirements for tasks in this chapter:
Task Required Privilege Class

Client nodes and administrators Policies and schedules Server settings Locations of client files on server storage Server operations (for example, activity logs and event records)

Manage disk volumes used by the database and recovery log System or unrestricted storage Display information about the database and recovery log Any administrator

See the following sections:

Concepts: How Tivoli Storage Manager Processes Transactions How Tivoli Storage Manager Manages Space The Advantages of Using Journal File System Files

Tasks: "Estimating and Monitoring Database and Recovery Log Space Requirements" "Increasing the Size of the Database or Recovery Log" "Decreasing the Size of the Database or Recovery Log" "Optimizing Database and Recovery Log Performance"

Note: Mirroring of the database and recovery log is described in the chapter on data protection. See Mirroring the Database and Recovery Log. In this chapter, most examples illustrate how to perform tasks by using a Tivoli Storage Manager command-line interface. For information about the commands, see Administrator's Reference, or issue the HELP command from the command line of a Tivoli Storage Manager administrative client. Tivoli Storage Manager tasks can also be performed from the administrative Web interface. For more information about using the administrative interface, see Quick Start.

How Tivoli Storage Manager Processes Transactions

To support multiple transactions from concurrent client sessions, the server holds transaction log records in the recovery log buffer pool until they can be written to the recovery log. These records remain in the buffer pool until the active buffer becomes full or Tivoli Storage Manager forces log records to the recovery log. Changes resulting from transactions are held in the buffer pool temporarily and are not made to the database immediately. Therefore, the database and recovery log are not always consistent. When all records for a transaction are written to the recovery log, Tivoli Storage Manager updates the database. The transaction is then committed to the database. At some point after a transaction is committed, the server deletes the transaction record from the recovery log.

How Tivoli Storage Manager Manages Space

Tivoli Storage Manager tracks all volumes defined to the database as one logical volume and all volumes defined to the recovery log as another logical volume. In Figure 53, the database consists of four volumes: VOL1 through VOL4, which the server tracks as a single logical volume. Figure 53. A Server Database

To manage the database and recovery log effectively, you must understand the following concepts: Available space Assigned capacity Utilization

Available Space
Not all of the space that is allocated for the volumes of the database or of the recovery log can be used for database and recovery log information. The server subtracts 1MB from each physical volume for overhead. The remaining space is divided into 4MB partitions. For example, you allocate four 25MB volumes for the database. For the four volumes, 4MB are needed for overhead leaving 96MB of available space as shown in figure Figure 54: Figure 54. An Example of Available Space

Assigned Capacity
Assigned capacity is the available space that can be used for database or recovery log information. During installation, the assigned capacities of the database and recovery log match the available space. If you add volumes after installation, you increase your available space. However, to increase the assigned capacity, you must also extend the database or recovery log. See Step 2: Extending the Capacity of the Database or Recovery Log for details.

Utilization
Utilization is the percent of the assigned capacity in use at a specific time. Maximum percent utilized is the highest utilization since the statistics were reset. For example, an installation performs most backups after midnight. Figure 55 shows that utilization statistics for the recovery log were reset at 9 p.m. the previous evening and that the maximum utilization occurred at 12 a.m. Figure 55. An Example of Recovery Log Utilization

Unless many objects are deleted, the database maximum percent utilized is usually close to the utilization percentage.

The Advantages of Using Journal File System Files

Tivoli Storage Manager supports both journaled file system (JFS) files and raw logical volumes as database, recovery log, and disk storage pool volumes. JFS files have the following advantages: JFS locks open files, and other applications cannot write to them. However, raw volumes are not locked, and any application can write to them. Tivoli Storage Manager tries to prevent starting more than one instance of the same server from the same directory, but it can be done. If you are using raw volumes, both server instances can simultaneously update the same information. This could cause errors in the database, recovery log, or storage pool raw volumes. After a database, recovery log, or storage pool volume is defined, you cannot change its size. Size information determines where data is placed and whether volumes have been modified by other applications or utilities. However, smit lets you increase the sizes of raw volume. If the volume is defined before its size is increased, Tivoli Storage Manager cannot use the volume or its data. For database and recovery log volumes you should use Tivoli Storage Manager mirroring rather than AIX mirroring. If you use AIX mirroring for database and recovery log volumes, you may have a problem with raw volumes, but not with JFS files. AIX tracks mirroring activity by writing control information to the first 512 bytes of USER area in a raw volume. This is not a problem for database and recovery log volumes, but Tivoli Storage Manager control information is also written in this area. If AIX overwrites this control information when raw volumes are mirrored, Tivoli Storage Manager may not be able to vary the volume online. Note: Tivoli Storage Manager mirroring only supports database and recovery log volumes. Disk storage pool volumes are not supported by Tivoli Storage Manager mirroring. The use of JFS files for database, recovery log, and storage pool volumes requires slightly more CPU than is required for raw volumes. However, JFS read-ahead caching improves performance.

Estimating and Monitoring Database and Recovery Log Space Requirements

The size of the database depends on the number of client files to be stored and the method by which the server manages them. If you can estimate the maximum number of files that might be in server storage at any time, you can estimate the database size from the following information: Each stored version of a file requires about 400 to 600 bytes of database space. Each cached or copy storage pool file requires about 100 to 200 bytes of database space. Overhead could require up to 25% in additional space.

In the example below, the computations are probable maximums. In addition, the numbers are not based on the use of file aggregation. In general, aggregation of small files reduces the required database space. For details about aggregation, see How the Server Groups Files before Storing. Assume the following numbers for a Tivoli Storage Manager system: Versions of files Backed up files Up to 500 000 client files might be backed up. Storage policies call for keeping up to 3 copies of backed up files: 500 000 files x 3 copies = 1 500 000 files Archived files Up to 100 000 files might be archived copies of client files. Space-managed files Up to 200 000 files migrated from client workstations might be in server storage. Note: File aggregation does not affect space-managed files. At 600 bytes per file, the space required for these files is: (1 500 000 + 100 000 + 200 000) x 600 = 1.0GB Cached and copy storage pool files Cached copies Caching is enabled in a 5GB disk storage pool. The pool's high and low migration thresholds are 90% and 70% respectively. Thus, 20% of the disk pool, or 1GB, is occupied by cached files. If the average file size is about 10KB, about 100 000 files are in cache at any one time. 100 000 files x 200 bytes = 19MB Copy storage pool files All primary storage pools are backed up to the copy storage pool: (1 500 000 + 100 000 + 200 000) x 200 bytes = 343MB Therefore, cached files and copy storage pool files require about 0.4GB of database space. Overhead About 1.4GB is required for file versions and cached and copy storage pool files. Up to 50% additional space (or 0.7GB) should be allowed for overhead. The database should then be approximately 2.1GB.

If you cannot estimate the numbers of files, you can roughly estimate the database size as from 1% to 5% of the required server storage space. For example, if you need 100GB of server storage, your database should be between 1GB and 5GB. See Estimating Space Needs for Storage Pools for details. During SQL queries of the server, intermediate results are stored in temporary tables that require space in the free portion of the database. Therefore, the use of SQL queries requires additional database space. The more complicated the queries, the greater is the space required. The size of the recovery log depends on the number of concurrent client sessions and the number of background processes executing on the server. The maximum number of concurrent client sessions is set in the server options. Attention: Be aware that the results are estimates. The actual size of the database may differ from the estimate because of factors such as the number of directories and the length of the path and file names. You should periodically monitor your database and recovery log and adjust their sizes as necessary. Begin with at least a 12MB recovery log. If you use the database backup and recovery functions in rollforward mode, you should begin with at least 25MB. See Database and Recovery Log Protection and Estimating the Size of the Recovery Log for more information.

Monitoring the Database and Recovery Log

You should regularly monitor the database and recovery log to see if you should add or delete space. To monitor daily utilization, you might want to reset the maximum utilization counters each day. Utilization statistics are reset in two ways: Automatically when the server is restarted By issuing the RESET DBMAXUTILIZATION or RESET LOGMAXUTILIZATION commands

For example, to reset the database utilization statistic, enter: reset dbmaxutilization If the SELFTUNEBUFPOOLSIZE server option is in effect, the buffer pool cache hit ratio statistics are reset at the start of expiration. After expiration, the buffer pool size is increased if the cache hit ratio is less than 98%. The increase in the buffer pool size is in small increments and may change after each expiration. The change in the buffer pool size is not reflected in the server options file. You can check the current size at any time using the QUERY STATUS command. Use the SETOPT BUFPOOLSIZE command to change the buffer pool size. To display information about the database or recovery log, issue the QUERY DB or QUERY LOG. For example: query db The server displays a report, like this: +-------------------------------------------------------------------------------+ |Available Assigned Maximum Maximum Page Total Used %Util Max. | | Space Capacity Extension Reduction Size Pages Pages %Util |

| (MB) (MB) (MB) (MB) (bytes) | |--------- -------- --------- --------- ------- --------- --------- ----- ---- | | 96 96 0 92 4,096 24,576 86 0.3 0.3 | +-------------------------------------------------------------------------------+ See the indicated sections for details about the following entries: Available space, "Available Space" Assigned capacity, "Assigned Capacity" Utilization and maximum utilization, "Utilization"

If utilization is high, you may want to add space (see Increasing the Size of the Database or Recovery Log). If utilization is low, you may want to delete space (see Decreasing the Size of the Database or Recovery Log). Note: You can also use a DEFINE SPACETRIGGER command to automatically check whether the database or recovery log exceeds a utilization percentage that you specify. See Automating the Increase of the Database or Recovery Log for details.

Increasing the Size of the Database or Recovery Log

As your requirements change, you can increase or decrease the sizes of the database and recovery log. You can automate the process of increasing the sizes, or you can perform all the steps manually. See Automating the Increase of the Database or Recovery Log or Manually Increasing the Database or Recovery Log. Attention: Do not change the size of an allocated database or recovery log volume after it has been defined. If you change the size of a volume, Tivoli Storage Manager may not initialize correctly, and data may be lost. Note: Significantly increasing the recovery log size could significantly increase the time required to restart the server, back up the database, and restore the database.

Automating the Increase of the Database or Recovery Log

You can automate the process of increasing the database and recovery log sizes. With a DEFINE SPACETRIGGER command, you can specify the following: Utilization percentages at which the database or recovery log size is to be increased The size of the increase as a percentage of the current database or recovery log size The prefix to be used for a new volume The maximum size allowed for the database or recovery log

For example, assume that you have a 100GB database and a 3GB recovery log. You want to increase the database size by 25 percent when 85 percent is in use, but not to more than 200GB. You also want to increase the recovery log size by 30 percent when 75 percent is in use, but not to more than 5GB. Note: There is one time when the database or recovery log might exceed the maximum size specified: If the database or recovery log is less than the maximum size when expansion begins, it continues to the full expansion value. However, no further expansion will occur unless the space trigger is updated. To add the new volumes to the /usr/lpp/adsmserv/bin/ directory, issue the following commands: define spacetrigger db fullpct=85 spaceexpansion=25 expansionprefix=/usr/lpp/adsmserv/bin/ maximumsize=200000 define spacetrigger log fullpct=75 spaceexpansion=30 expansionprefix=/usr/lpp/adsmserv/bin/ maximumsize=50000 The server then monitors the database or recovery log and, if the utilization level is reached, does the following: Displays a message (ANR4413I or ANR4414I) that states the amount of space required to meet the utilization parameter specified in the command. Allocates space for the new volume. Defines the new volume. Extends the database or recovery log. If a volume is mirrored and there is enough disk space, the preceding steps are also performed for the mirrored copies.

Notes: 1. The maximum size of the recovery log is 13GB. The server will not automatically extend the recovery log beyond 12GB. 2. An automatic expansion may exceed the specified database or recovery log maximum size but not the 13GB recovery log limit. However, after the maximum has been reached, no further automatic expansions will occur. 3. A space trigger percentage may be exceeded between the monitoring of the database or recovery log and the time that a new volume is brought online. 4. If the server creates a database or recovery log volume and the attempt to add it to the server fails, the volume is not deleted. After the problem is corrected, you can define it with the DEFINE DBVOLUME or DEFINE LOGVOLUME command. 5. Automatic expansion will not occur during a database backup. 6. The database and recovery log utilization percentage may not always be below the space trigger value. The server checks utilization after a database or recovery log commit. Also, deleting database volumes and reducing the database does not activate the trigger. Therefore, the utilization percentage can exceed the set value before new volumes are online. 7. Setting a maximum size does not mean that the database and recovery log will always be less than that value. The value is a threshold for expansion. The server does not automatically expand the database or recovery log if its size is greater than the maximum size. The server checks the size and allows expansion if the database or recovery log is less than the maximum size. The server only checks the size that results after expansion to ensure that maximum recovery log size is not exceeded.

Recovering When the Recovery Log Runs Out of Space

If the log mode is set to ROLLFORWARD and either the recovery log is too small or the database backup trigger is set too high, the recovery log could run out of space before database operations complete. If this happens, you may need to stop the server without enough recovery log space to restart the server. In some cases, the server halts itself. To restart the server, first format a new volume (see Using the DSMFMT Command to Format Volumes). Then use the DSMSERV EXTEND LOG command to extend the size of the recovery log. For example, after formatting a 21MB volume named new.reclog, extend the recovery log by issuing the following command: dsmserv extend log new.reclog 20 After the server is running, you can do the following: Back up the database, which frees the recovery log space Adjust the size of the recovery log, the database backup trigger, or both

Manually Increasing the Database or Recovery Log

To add space to the database or recovery log, do the following: Step 1: Creating Database and Recovery Log Volumes Step 2: Extending the Capacity of the Database or Recovery Log

Step 1: Creating Database and Recovery Log Volumes

You can allocate space and define a database or recovery log volume in a single operation. For example, to allocate a 100MB database volume named VOL5 in the /usr/lpp/adsmserv/bin directory and define the volume, enter: define dbvolume /usr/lpp/adsmserv/bin/vol5 formatsize=100 The available space of the database increases to 196MB, but the assigned capacity remains at 96MB. For Tivoli Storage Manager to use the space, you must extend the capacity (see Step 2: Extending the Capacity of the Database or Recovery Log). To verify the change, query the database or recovery log. For example, to query the database, enter: query db The server displays a report, like this: +-------------------------------------------------------------------------------+ |Available Assigned Maximum Maximum Page Total Used %Util Max. | | Space Capacity Extension Reduction Size Pages Pages %Util | | (MB) (MB) (MB) (MB) (bytes) |

|--------- -------- --------- --------- ------- --------- --------- ----- ---- | | 196 96 100 92 4,096 24,576 86 0.3 0.3 | +-------------------------------------------------------------------------------+ The value in the Maximum Extension field should equal the available space of the new volume. In this example, a 101MB volume was allocated. This report shows that the available space has increased by 100MB; the assigned capacity is unchanged at 96MB; and the maximum extension is 100MB. Figure 56 illustrates these changes. Figure 56. Adding Volumes Increases Available Space

You can also query the database and recovery log volumes to display information about the physical volumes that make up the database and recovery log. Notes: 1. The maximum size of the recovery log is 13GB, and the maximum size of the database is 530GB. If you allocate a volume that would cause the recovery log or database to exceed these limits, the subsequent DEFINE DBVOLUME or DEFINE LOGVOLUME command for the volume will fail. 2. For performance reasons, define more than one volume for the database and recovery log, and put these volumes on separate disks. This allows simultaneous access to different parts of the database or recovery log. 3. To use disk space efficiently, allocate a few large disk volumes rather than many small disk volumes. In this way, you avoid losing space to overhead processing. If you already have a number of small volumes and want to consolidate the space into one large volume, see Decreasing the Size of the Database or Recovery Log. 4. To protect database and recovery log volumes from media failure, use mirroring. See Mirroring the Database and Recovery Log for details.

Using the DSMFMT Command to Format Volumes

You can still use the DSMFMT utility to allocate a database or recovery log volume. You would then issue the DEFINE DBVOLUME or DEFINE LOGVOLUME command without the FORMATSIZE parameter, and extend the database or recovery log (see Step 2: Extending the Capacity of the Database or Recovery Log). To allocate an additional 101MB to the database as volume VOL5, enter: > dsmfmt -db vol5 101

Step 2: Extending the Capacity of the Database or Recovery Log

The database and recovery log are extended in 4MB increments. If you do not specify the extension in 4MB increments, the server rounds up to the next 4MB partition. For example, if you specify 1MB, the server extends the capacity by 4MB. To increase the capacity of the database by 100MB, enter: extend db 100 After the database has been extended, the available space and assigned capacity are both equal to 196MB, as shown in Figure 57. Figure 57. Extending the Capacity of the Database

You can query the database or recovery log (QUERY DB and QUERY LOG commands) to verify their assigned capacities. The server would display a report, like this: +-------------------------------------------------------------------------------+ |Available Assigned Maximum Maximum Page Total Used %Util Max. |

| Space Capacity Extension Reduction Size Pages Pages %Util | | (MB) (MB) (MB) (MB) (bytes) | |--------- -------- --------- --------- ------- --------- --------- ----- ---- | | 196 196 0 192 4,096 50,176 111 0.2 0.2 | +-------------------------------------------------------------------------------+

Decreasing the Size of the Database or Recovery Log

You may want to delete database or recovery log volumes for a number of reasons. For example: You have a significant amount of space that is unused. You want to consolidate a number of small volumes, each of which may have unusable space, into one large volume. To create a volume, see Increasing the Size of the Database or Recovery Log.

When you delete a database or recovery log volume, Tivoli Storage Manager tries to move data from the volume being deleted to other physical volumes in the database or recovery log. To delete space, perform the following steps: 1. Determine if you can delete one or more volumes ("Step 1: Determining If Volumes Can Be Deleted"). 2. Reduce the capacity of the database or recovery log to free existing space (Step 2: Reducing the Capacity of the Database or Recovery Log). 3. Delete the volume ("Step 3: Deleting a Volume from the Database or Recovery Log").

Step 1: Determining If Volumes Can Be Deleted

To determine if volumes can be deleted from the database or recovery log, check the volume sizes and the amount of unused space. To check the sizes of the volumes in the database, enter: query dbvolume format=detailed The server displays the following type of information: +-------------------------------------------------------------------------------+ |Volume Name (Copy 1): VOL1 | | Copy Status: Sync'd | |Volume Name (Copy 2): |

| Copy Status: Undefined | |Volume Name (Copy 3): | | Copy Status: Undefined | |Available Space (MB): 24 | |Allocated Space (MB): 24 | | Free Space (MB): 0 | +-------------------------------------------------------------------------------+ In this example, VOL1, VOL2, VOL3, and VOL4 each have 24MB of available space, and VOL5 has 100MB. To determine if there is enough unused space to delete one or more volumes, enter: query db The server displays the following type of report. +-------------------------------------------------------------------------------+ |Available Assigned Maximum Maximum Page Total Used %Util Max. | | Space Capacity Extension Reduction Size Pages Pages %Util | | (MB) (MB) (MB) (MB) (bytes) | |--------- -------- --------- --------- ------- --------- --------- ----- ---- | | 196 196 0 176 4,096 50,176 4,755 9.5 9.5 | +-------------------------------------------------------------------------------+ The Maximum Reduction field shows the assigned capacity not in use. In this example, you could reduce the database by up to 176MB. This is enough space to allow the deletion of VOL1, VOL2, VOL3, and VOL4. If there is not enough space on the remaining volumes, allocate more space and define an additional volume, as described in Increasing the Size of the Database or Recovery Log and continue with Step 2: Reducing the Capacity of the Database or Recovery Log.

Step 2: Reducing the Capacity of the Database or Recovery Log

The database or recovery log capacity is reduced in 4MB increments. For example, based on the utilization of the database assume that VOL5 alone could contain all the data. To reduce the database by the amount of available space in VOL1 through VOL4, 96MB, enter: reduce db 96

Reducing capacity is run as a background process and can take a long time. Issue a QUERY PROCESS command to check on the status of the process. After reducing the database by 96MB, the assigned capacity is 100MB, and the maximum extension is 96MB, as shown in the following example: +-------------------------------------------------------------------------------+ |Available Assigned Maximum Maximum Page Total Used %Util Max. | | Space Capacity Extension Reduction Size Pages Pages %Util | | (MB) (MB) (MB) (MB) (bytes) | |--------- -------- --------- --------- ------- --------- --------- ----- ---- | | 196 100 96 92 4,096 24,576 86 0.3 0.3 | +-------------------------------------------------------------------------------+

Step 3: Deleting a Volume from the Database or Recovery Log

After you reduce the database or recovery log, use the smaller size for a few days. If the maximum utilization does not exceed 70%, you can delete the extra volumes. Note: You cannot delete volumes if there is not enough free space for the server to move data from the volume being deleted to other physical volumes in the database or recovery log. In our example, you determined that you can delete the four 24MB volumes from the database. You have reduced the database by 96MB. To delete VOL1 through VOL4 from the database, enter: delete dbvolume vol1 delete dbvolume vol2 delete dbvolume vol3 delete dbvolume vol4 The server moves data from the volumes being deleted to available space on other volumes, as shown in Figure 58. Figure 58. Deleting Database Volumes

After the data has been moved, these volumes are deleted from the server.

Optimizing Database and Recovery Log Performance

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: Improved performance of the server database dump and load functions Improved performance of the database audit functions Improved use of database space Reorganization of fragmented page allocations Improved performance of long-running scans of the database

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.

Adjusting the Database Buffer Pool Size

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 10% of available real storage.

Manually Adjusting the Database Buffer Pool Size

Perform the following steps to track the database buffer pool statistics and adjust the buffer pool size:

Step 1: Reset Database Buffer Pool Utilization Statistics

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

Step 2: Monitor the Database Buffer Pool

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:

Buffer Pool Pages The number of pages in the database buffer pool. This value is determined by the server option for the size of the database buffer pool. At installation, the database buffer pool is set to 2048KB, which equals 128 database pages. Total Buffer Requests The number of requests for database pages since the server was last started or the buffer pool was last reset. If you regularly reset the buffer pool, you can see trends over time. Cache Hit Pct The percentage of requests for cached database pages in the database buffer pool that were not read from disk. A high value indicates that the size of your database buffer pool is adequate. If the value falls below 98%, consider increasing the size of the database buffer pool. For larger installations, performance could improve significantly if your cache hit percentage is greater than 99%. Cache Wait Pct The percentage of requests for database pages that had to wait for a buffer to become available in the database buffer pool. When this value is greater than 0, increase the size of the database buffer pool.

Step 3: Adjust the Database Buffer Pool

Use the BUFPOOLSIZE server option to set the size of the database buffer pool.

Adjusting the Recovery Log Buffer Pool Size

Do the following to adjust the size of the recovery log buffer pool:

Step 1: Monitor 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: Log Pool Pages The number of pages in the recovery log buffer pool. This value is set by the server option for the size of the recovery log buffer pool. At installation, the default setting is 128KB, which equals 32 recovery log pages. Log Pool Pct. Util The percentage of pages used to write changes to the recovery log after a transaction is committed. A value below 10% means that the recovery log buffer pool size is adequate. If the percentage increases, consider increasing the recovery log buffer pool size. Log Pool Pct. Wait The percentage of requests for pages that are not available because all pages are waiting to write to the recovery log. If this value is greater than 0, increase the recovery log buffer pool size.

Step 2: Adjust the Recovery Log Buffer Pool

Use the LOGPOOLSIZE server option to set the size of the recovery log buffer pool.

Reorganizing the Database

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.

Procedure: Reorganizing the Database

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: 1. Ensure that a current device configuration file exists. This file contains a copy of the device class, library, and drive definitions. These definitions are needed for the DSMSERV LOADDB utility. You must specify the name of the device configuration file by using the DEVCONFIG option in the server options file. See Saving the Device Configuration File. Also see Administrator's Reference for details on the option and the command. 2. Before unloading the database, estimate how many tapes you will need: o If the server is not running, use the size of your existing physical database volumes as an estimate of how many tapes to use. o If the server is running, you can use the following steps to estimate the number of tapes required: a. Request information about the database by using the following command: b. query db c. Using the output of the QUERY DB command, multiply the Used Pages by the Page Size to determine space occupied by the database. d. Use the result to estimate the number of tapes of a specific device class that you will need to unload the database. The space required will likely be less than your estimate. 3. Halt the server if it is still running. 4. With the server not running, issue the DSMSERV UNLOADDB utility to unload the database to tape. For example: 5. dsmserv unloaddb devclass=tapeclass scratch=yes Note: Keep track of the order in which the tape volumes are written when the database is unloaded. You must specify the volume names in the same order when you reload the database using the DSMSERV LOADDB utility. For this task, you can either: Review the output generated by the DSMSERV UNLOADDB utility and record the order of the volumes. o Manually view the volume history file to identify the tape volumes containing the unloaded database. The volumes have a volume type of DBDUMP. See Saving the Volume History File for details. (Do not restart the server and issue QUERY VOLHISTORY at this step.) 6. Format the database and recovery log. For example: 7. dsmserv loadformat 2 logvol1 logvol2 1 dbvol1 This utility prepares the existing server database for the DSMSERV LOADDB utility. 8. Reload the database using the volumes that contain the data from the unload operation. For example: 9. dsmserv loaddb devclass=tapeclass volumenames=db001,db002,db003 For the volume names, ensure that you do the following: o o Enter the volume names in the same order in which they were used for the DSMSERV UNLOADDB utility. Separate the volume names with a comma and no intervening spaces. o