Administrator's Reference
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:
- Issue the DSMSERV FORMAT command to reinitialize the database and recovery
log.
- Issue the DSMSERV LOADDB command to reload the database.
- 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:
- Before unloading the database to sequential access media, estimate how
much media is required. If you do not know, use the size of your
existing database volumes.
- Record the order in which the volumes are mounted during DSMSERV UNLOADDB
processing. The volume order is important during DSMSERV LOADDB
processing so that the volumes can be remounted in the same order. To
ensure that volumes are mounted in the correct order, prelabel the volumes
with information that indicates the order in which they have been
mounted. For example, label tapes as DSM001, DSM002, DSM003, and so on
to indicate the order in which data is stored on the tape volumes.
- When unloading, you can use scratch volumes to ensure that there is space
to store the database. If you use scratch volumes, record the label
names and sequence for each volume mounted during the unloading
process.
- Obviously, the server recovery log is not accessed during the unloading
process. Therefore, database entries that were not written to the
database at the time of the unloading are not recorded. During recovery
from a catastrophic failure, the most recent database updates may not be
recoverable.
Syntax
>>-DSMSERV UNLOADDB----DEVclass--=--device_class_name----------->
>-----+----------------------------------------+---------------->
| .-,------------. |
| V | |
'-VOLumenames--=------volnameslist--+----'
.-Scratch--=--Yes-----. .-CONSISTENT--=--Yes-----.
>-----+---------------------+---+------------------------+-----><
'-Scratch--=--+-Yes-+-' '-CONSISTENT--=--+-Yes-+-'
'-No--' '-No--'
Parameters
- DEVclass
- Specifies the device class to which the database information will be
written.
- VOLumenames
- Specifies the volumes to use to unload 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:
- volnameslist
- The names of one or more volumes to use to unload the database.
Specify multiple volumes by separating volume names with commas and no
intervening spaces. You must list the volumes in the order in which you
want the volumes 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
trasactionally-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:
- Halt the server, if it is not already offline. This command can
only be used when the server is offline.
- 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.
- Label the tape(s) using the DSMLABEL utility. For example:
dsmlabel -drive=mt3.0.0.0
- 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 ]