The database, recovery log, and storage pool volumes are closely related. The ADSM database contains information needed for server operations and information about client data that has been backed up, archived, and space-managed.
| Note: | The client data itself is stored in storage pools, not in the database. |
The database contains pointers to the locations of all client files in the ADSM storage pools.
Changes to the database are recorded in the recovery log in order to maintain a consistent database image. These changes are the result of transactions between clients and the server. Examples of activities that can occur in a transaction are: defining a management class or copy group, archiving or backing up a client file, and registering an administrator or a client node.
The database contains:
The recovery log contains information about updates that have not yet been committed to the database.
| Note: | If the database is unusable, the entire ADSM 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 20. "Protecting and Recovering Your Data" for steps that you can take to protect your database. |
Both the database and the recovery log have buffer pools. 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 ADSM forces log records to the recovery log.
Changes resulting from transactions are held in a buffer pool temporarily and not made to the database immediately. Therefore, the database and recovery log are not always consistent.
When all log records for a transaction are written to the recovery log, the server 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.
ADSM tracks all volumes defined to the database as one logical volume and all volumes defined to the recovery log as another logical volume. For example, in Figure 45, the database consists of four volumes: VOL1 through VOL4. ADSM tracks the database as a single logical volume.
|
To manage the database and recovery log effectively, you must understand the following concepts:
Not all of the space that is allocated for the database or recovery log volumes is available to be used for database and recovery log information. To calculate the available space, ADSM:
See "Step 1: Allocating Space for the Database and Recovery Log" for an example of how this calculation is used.
Assigned capacity is the portion of available space that can be used for database or recovery log information. During installation, the server automatically extends the database and recovery log so that assigned capacity matches 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 3: Extending the Capacity of the Database or Recovery Log" for details.
Utilization is the percent of the database or recovery log assigned capacity used at a specific time. Maximum percent utilized is the highest utilization since the utilization statistics were last reset.
For example, an installation performs most backups after midnight. Figure 46 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 46. An Example of Recovery Log Utilization
 |
Unless an unusually large number of objects are deleted, the database maximum percent utilized is usually close to the utilization percentage.