Tivoli Storage Manager for Windows: Administrator's Reference

DSMSERV UNLOADDB (Unload the Database)

Use this command to recover the contents of the database when the server is offline. This command unloads the database in key order so when the database is reloaded the space required for the database is minimized. A database audit could be required after the database is reloaded.

After DSMSERV UNLOADDB processing is complete, perform the following steps:

  1. |Issue the DSMSERV LOADFORMAT command to reinitialize the database |and recovery log.
  2. Issue the DSMSERV LOADDB command to reload the database.
  3. Issue the DSMSERV AUDITDB command to locate and correct any database inconsistencies.

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

You must have a device configuration file that includes the definition for this device class, and any libraries and drives needed. You must also specify the name of that device configuration file by using the DEVCONFIG option in your server options file. The device configuration file should be available if you had previously included a DEVCONFIG option in the server options file and then started the server. If the device configuration file has been lost or was never created, create the device configuration file manually with an editor. For information on how to create a device configuration file manually, see Administrator's Guide.

Consider the following before unloading the database:

Note:
After a server database is loaded or restored the Server-to-Server communication verification token has been 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 server database. For servers that have been defined for Server-to-Server communications, you must issue an UPDATE SERVER command with the server name and the FORCESYNC parameter = YES.

Syntax

>>-DSMSERV UNLOADDB--DEVclass--=--device_class_name------------->
 
   .-Scratch--=--Yes-----.
>--+---------------------+-------------------------------------->
   '-Scratch--=--+-Yes-+-'
                 '-No--'
 
>--+---------------------------------+-------------------------->
   |                 .-,-----------. |
   |                 V             | |
   '-VOLumenames--=----volume_name-+-'
 
   .-CONSISTENT--=--Yes-----.
>--+------------------------+----------------------------------><
   '-CONSISTENT--=--+-Yes-+-'
                    '-No--'
 
 

Parameters

DEVclass
Specifies the device class to which the database information will be written. |You cannot use a device class with a device type of NAS.

VOLumenames
Specifies the volumes to use to dump the database. This parameter is optional, but must be specified if SCRATCH=NO. If you do not specify this parameter and SCRATCH=YES is specified or assumed, scratch volumes are used.

TSM does not record the use of volumes by the DSMSERV UNLOADDB command in the volume history file. Therefore, you must record the volume names used and specify them in the exact same order on a future DSMSERV LOADDB command.

Possible values are:

volume_name
The names of one or more volumes to use to dump the database. Specify multiple volumes by separating volume names with commas and no intervening spaces. The volumes will be used in the order in which they are listed.

FILE:file_name
The name of a file that contains a list of the volumes to use to dump the database. Enter each volume name on a separate line in the file. List the volumes in the order in which they are to be used.

Scratch
Specifies whether or not scratch volumes can be used for unloading the database. The default value is YES.

Yes
Scratch volumes can be used. If you include a list of volumes on the VOLUMENAMES parameter, scratch volumes are used only if there is not enough space to unload the database on the volumes specified. If the device type associated with the specified device class is FILE, file names for the scratch volumes are generated based on a time stamp.

No
Scratch volumes cannot be used. You must include a list of volumes on the VOLUMENAMES parameter to contain all of the database data.

Consistent
Specifies whether server transaction processing should be suspended so that the unloaded database is a transactionally-consistent image. The default is YES.

Yes
Specifies that a database audit will not be required when you reload the database; because during unloading, you preserved a transactionally-consistent database.

No
Specifies that when reloading the database, a database audit will be required because during unloading a transactionally-consistent database image was not maintained. CONSISTENT=NO should only be used when the CONSISTENT=YES fails.

Examples

Task 1

Unload the database to tapes named DB0001, DB0002, DB0003:

  1. Halt the server, if it is not already offline. This command can only be used when the server is offline.
  2. Ensure that the DEVCONFIG option has been specified in the server options file. The device configuration file must contain the device class, library, and drive definitions needed for the unload operation.
  3. Label the tape(s) using the DSMLABEL utility. For example:
    dsmlabel -drive=mt3.0.0.0
    
  4. Issue the DSMSERV UNLOADDB command.

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

Task 2

Unload the database using tapes listed in a file named ADSM.VOLLIST.

Command:
dsmserv unloaddb devclass=tapeclass
 volnames=file:adsm.vollist


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