Tivoli Header

Administrator's Reference

DSMSERV LOADDB (Reload the Database)

Use this command to reload a dumped Tivoli Storage Manager database in optimal order. No other server activity is allowed while reloading the database. Perform the applicable steps in this order:

  1. When recovering from a failure reinstall Tivoli Storage Manager using the DSMSERV LOADFORMAT and create a new database and recovery log. This keeps the original database and log volumes intact in case you must repeat the dump and load.

    Attention: Do not reinitialize DISK storage pool volumes.

  2. Save the current sequential volume history to a file. The load process regresses the sequential volume history information. The saved copy should be printed or copied to a safe location. The information in the dataset will be needed after the database is reloaded. If the data is not printed or copied, key information may be lost when the server is restarted after loading the database.
  3. The DSMSERV LOADDB utility specifies a device class to be used when reading the database information. Ensure that a device configuration file that includes the definitions for this device class and for any required libraries and drives is available.

    Attention: The DSMSERV LOADDB command only supports the use of manual libraries (LIBTYPE=MANUAL in the DEFINE LIBRARY command).

  4. Run the DSMSERV LOADDB utility.
  5. A message at the end of the output from the DSMSERV LOADDB indicates if you must audit the database. If the server was halted with the HALT command with the quiesce parameter and allowed to end normally before running the DSMSERV DUMPDB utility, an AUDITDB utility will not normally be required when the database is loaded using the DSMSERV LOADDB utility. Otherwise, run the DSMSERV AUDITDB utility to ensure that the database is returned to a synchronized state after it is reloaded. If there was any storage pool volume activity after the dump, audit the volumes by using the AUDIT VOLUME command. (The AUDIT VOLUME command is run from the command prompt with the server running in normal mode.)
Note:
When a database is loaded or restored, the server-to-server communication verification token is changed. The verification token is an attribute of the database and is not stored in the database itself. Part of the token is the install date and time for the database. For servers that have been defined for server-to-server communications, you must issue an UPDATE SERVER command with FORCESYNC=YES.

Syntax

>>-DSMSERV LOADDB--DEVclass--=--device_class_name--------------->
 
                       .-,-----------.
                       V             |
>----VOLumenames--=--+---volume_name-+-+-----------------------><
                     '-FILE:file_name--'
 
 

Parameters

DEVclass (Required)
Specifies the device class to be used when reading the database information.

VOLumenames (Required)
Specifies the volumes needed to load the database. Possible values are:

volume_name
The names of the volumes. To specify multiple volumes, separate the names with commas and no intervening spaces. List the volumes in the order in which they were used for the DSMSERV DUMPDB command.

FILE:file_name
The name of a file that contains a list of the volumes. Each volume name must be on a separate line in the order in which they were used for the DSMSERV DUMPDB command.

Examples

Task 1

Load the database from the DB0001, DB0002, and DB0003 tapes.

Command:
dsmserv loaddb devclass=tapeclass 
volumenames=db0001,db0002,db0003

Task 2

Load the database using tapes listed in the ADSM.VOLLIST file.

Command:
dsmserv loaddb devclass=tapeclass 
volumenames=file:adsm.vollist


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]