Administrator's Guide

Estimating and Monitoring Database and Recovery Log Space Requirements

The size of your ADSM database depends on the number of client files to be stored and how ADSM manages them. If you can estimate the maximum number of files that might be in server storage at any time, you can use the following information to come up with a useful database size estimate:

• Each version of a file that ADSM stores requires about 400 to 600 bytes of database space.

• Each cached or copy storage pool copy of a file requires about 100 to 200 bytes of database space.

• Overhead could increase the required space up to an additional 25%.

In the example below, the computations are probable maximums. In addition, the numbers are not based on the use of file aggregation. In general, the more that small files are aggregated, the less the required database space. For information about how to affect aggregation, see "How ADSM Stores Files in a Storage Pool Hierarchy". Assume the following numbers for an ADSM system:

Versions of files

Backed up files

Up to 500 000 client files might be backed up. And storage policies call for retaining 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.

The space required for all backed up, archived, and space-managed files at 600 bytes per file is:

(1 500 000 + 100 000 + 200 000) x 600 = 1.0GB

Cached and copy storage pool files

Cached copies

Caching is enabled in the disk storage pool. The disk pool has a capacity of 5GB and uses the default high migration threshold (90%) and low migration threshold (70%). Thus, if migration begins at 90% and stops at 70%, 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

Cached and copy storage pool files, then, require about 0.4GB of database space.

Overhead

Up to this point approximately 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, then, should be approximately 2.1GB.

If it is not practical to estimate the number of files to be covered by your storage management policies, 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 ADSM 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 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.

Note:

The maximum number of concurrent client sessions is set in the server options.

Begin with at least 12MB for the recovery log. If you will be using the database backup and recovery functions in roll-forward mode, you should begin with at least 25MB. See "Database Backup" and "Estimating the Size of the Recovery Log" for more information.

Monitoring the Database and Recovery Log

After your ADSM system is operational, you should monitor the database and recovery log to see if you should add or delete space.

You can reset the maximum utilization counters for the database and recovery log to monitor daily utilization. To set the maximum utilization percentage equal to the current utilization, you might want to reset the utilization statistics 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 maximum utilization statistic for the database, enter:

reset dbmaxutilization

To display information about the database or recovery log, issue the QUERY DB or QUERY LOG respectively. 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 pages for details about the following entries:

• Available space, page "Available Space"
• Assigned capacity, page "Assigned Capacity"
• Utilization and maximum utilization, page "Utilization"

On the basis of the these queries, you may decide to adjust the size of the database or recovery log. If utilization is high, you may want to add space. If utilization is low, you may want to delete space. See "Adding Space to the Database or Recovery Log" or "Deleting Space from the Database or Recovery Log".