Tivoli Header
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 LOADFORMAT 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: This database unload operation assumes that the
Tivoli Storage Manager database is usable and reads device information from
the database, not from the device configuration file. A database dump
operation (DSMSERV DUMPDB), on the other hand, does not assume a usable
database and reads from the device configuration file.
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.
- The DSMSERV UNLOADDB utility requires standard label tapes if you are
unloading to tape.
- 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--| A |---------------------->
.-CONSISTENT--=--Yes-----.
>--+------------------------+----------------------------------><
'-CONSISTENT--=--+-Yes-+-'
'-No--'
A
.-Scratch--=--Yes-----.
|--+---------------------+-------------------------------------->
'-Scratch--=--+-Yes-+-'
'-No--'
>--+-------------------------------------+----------------------|
| .-,-----------. |
| V | |
'-VOLumenames--=--+---volume_name-+-+-'
+-FILE:file_name--+
'-FILE:DD:ddname--'
Parameters
- DEVclass
- Specifies the device class to which the database information will be
written.
- 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.
Tivoli Storage Manager 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. When
enclosed in single quotation marks ('), specifies the fully qualified
dataset name. Without quotation marks, the complete dataset name is
assumed to be the user ID associated with the job that is running the server
from which the command is issued followed by the specified name.
- FILE:DD:ddname
- Specifies name of the DD statement that defines the location of a dataset
containing the list of volumes names. 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 a tape named DB0001.
- Halt the server, if it is not already offline. This command can
only be used when the server is offline.
- Issue DSMSERV UNLOADDB.
Sample JCL:
//DUMPDB JOB ,REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//TIVSM EXEC PGM=ANRSERV,PARM='/UNLOADDB DEV=CART VOL=DB0001',
// DYNAMNBR=300,
// TIME=NOLIMIT
//OPT DD DSN=TIVSM.OPTIONS,DISP=SHR,FREE=CLOSE
//DSMAMENG DD DSN=TIVSM.ANRMSG(ANRMENU),DISP=SHR
//HLPAMENG DD DSN=TIVSM.ANRHLP(ANRHENU),DISP=SHR
//DSK DD DSN=TIVSM.DISKLOG,DISP=SHR
Task 2
Unload the database to a file in the device class named FLAT, which has a
device type of FILE.
- Halt the server, if it is not already offline. This command can
only be used when the server is offline.
- Issue DSMSERV UNLOADDB.
Sample JCL:
//TIVSM01 JOB ,
// REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//TIVSM01 EXEC PGM=ANRSERV,DYNAMNBR=300,TIME=NOLIMIT,
// PARM='/UNLOADDB DEVCLASS=FLAT'
//OPT DD DSN=TIVSM.OPTIONS,DISP=SHR,FREE=CLOSE
//DSMAMENG DD DSN=TIVSM.ANRMSG(ANRMENU),DISP=SHR
//HLPAMENG DD DSN=TIVSM.ANRHLP(ANRHENU),DISP=SHR
//DSK DD DSN=TIVSM.DISKLOG,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
Task 3
Unload the database to tapes DBD010, DBD011, and DBD012.
- Halt the server, if it is not already offline. This command can
only be used when the server is offline.
- Issue DSMSERV UNLOADDB.
Sample JCL:
//UNLOAD JOB ,REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//TIVSM EXEC PGM=ANRSERV,PARM='/UNLOADDB VOL=FILE:DD:DBDATA',
// DYNAMNBR=300,
// TIME=NOLIMIT
//OPT DD DSN=TIVSM.OPTIONS,DISP=SHR,FREE=CLOSE
//DSMAMENG DD DSN=TIVSM.ANRMSG(ANRMENU),DISP=SHR
//HLPAMENG DD DSN=TIVSM.ANRHLP(ANRHENU),DISP=SHR
//DSK DD DSN=TIVSM.DISKLOG,DISP=SHR
//* -------------------------------------------------------
//* Unload To Scratch Tapes
//* -------------------------------------------------------
//DBDATA DD *
DBD010
DBD011
DBD012
/*
//
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]