There are several factors that influence the performance of the
Move Volume utility. The following are items to consider when making
processing decisions to maximize the performance of the utility:
- Average object size
- Source and target optical device types
- Number of active utilities
- Primary or backup source volume
- Number of rows in the object directory table for the storage group
to which the source volume belongs
- Additional DB2 indexes defined (depending on activity currently
in progress)
- Level of the system workload and I/O to the source and target
devices
The Move Volume utility performs DB2 SELECTs from the object directory
tables (OSM_OBJ_DIR) to prepare the list of objects to be moved. Depending
on the current status of the table, DB2 might do a table space scan
or an index scan. With large DB2 tables, it is recommended that you
verify that DB2 is to use index scans to enhance the efficiency and
performance of the Move Volume utility.
The object selection is not overlapped with the read from optical
or tape, write to optical or tape, or directory update processes.
This means that the elapsed time to complete the MOVEVOL processing
consists of the time to select the objects and the time to update
the object directory tables after the object movement is complete.
The object selection process consists of executing DB2 SELECT
statements from the object directory tables. This process is limited
by the DB2 indexes available and the chosen access path. Without the
additional recommended indexes, the object selection process requires:
- At least one table space scan of the object directory table for
a single storage group associated with the primary volume processed
- A table space scan of all object directory
tables when a backup volume is processed.
Recommendation: Creating these additional
DB2 indexes enhances the performance for the Move Volume utility;
however, these indexes can negatively affect other OSMC process. After
MOVEVOL processing has completed, drop these additional indexes and
rebind the modified plans.
To improve performance for the Move Volume utility, perform the
following steps:
- Create an index on ODLSLOC and ODCLID for each storage group that
contains a primary volume that is being processed. For first backup
volumes, create an index on ODBKLOC and ODCLID for each storage group
that has a significant number of objects (more than 10␠000).
For second backup volumes, create an index on ODBK2LOC and ODCLID
for each storage group that has a significant number of objects (more
than 10␠000). Use the following SQL statements to define
additional DB2 indexes.
CREATE INDEX GROUPhlq.OBJDIRX4
ON GROUPhlq.OSM_OBJ_DIR
(
ODLSLOC ASC,
ODCLID ASC
)
USING VCAT cat_name
CLOSE NO
SUBPAGES 1
BUFFERPOOL BP1
PCTFREE 10;
CREATE INDEX GROUPhlq.OBJDIRX5
ON GROUPhlq.OSM_OBJ_DIR
(
ODBKLOC ASC,
ODCLID ASC
)
USING VCAT cat_name
CLOSE NO
SUBPAGES 1
BUFFERPOOL BP1
PCTFREE 10;
Where: cat_name is the name of the catalog used
under DB2. OAM does not create these indexes using the UNIQUE keyword.
Because moving data from a backup volume requires access to all of
the defined storage group directories, creation of the index on ODBKLOC
(instead of ODLSLOC as in above example) is important for all storage
groups that contain large numbers of objects (whether there are any
backup objects on the volume being processed or not).
- Execute RUNSTATS to collect data on the new indexes. See Tuning the DB2 databases for more information.
_______________________________________________________
- Modify and run CBRPBIND to rebind the following DB2 plans to their
packages for the affected storage group: CBRHSVOL, CBRHSBKV, CBRHSBCC,
CBRHSPCC, CBRHORCL, and CBRHCNTL. See CBRPBIND, CBRHBIND and CBRHGRNT for information on binding these plans.
_______________________________________________________
- Define data sets for the additional indexes. See CBRIALC0 for more information on defining these data sets.
//STEPxx EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSDUMP DD SYSOUT=*
//SYSIN DD *
DELETE
cat_name.DSNDBC.GROUPhlq.OBJDIRX4.I0001.A001
CLUSTER
PURGE
DELETE
cat_name.DSNDBC.GROUPhlq.OBJDIRX5.I0001.A001
CLUSTER
PURGE
SET LASTCC=0
SET MAXCC=0
DEFINE CLUSTER
(NAME(cat_name.DSNDBC.GROUPhlq.OBJDIRX4.I0001.A001)
LINEAR
SHAREOPTIONS(3 3)
VOLUMES(vol_ser)
CYLINDERS(pri_alloc sec_alloc)
UNIQUE )
DATA
(NAME(cat_name.DSNDBD.GROUPhlq.OBJDIRX4.I0001.A001))
DEFINE CLUSTER
(NAME(cat_name.DSNDBC.GROUPhlq.OBJDIRX5.I0001.A001))
LINEAR
SHAREOPTIONS(3 3)
VOLUMES(vol_ser)
CYLINDERS(pri_alloc sec_alloc)
UNIQUE )
DATA
(NAME(cat_name.DSNDBD.GROUPhlq.OBJDIRX5.I0001.A001))
/*
Where: vol_ser is the volume
serial the data set should be placed on; pri_alloc, sec_alloc is the number of primary and secondary
allocations for the data set; cat_name is
the name of the catalog used under DB2. These indexes are not created
using the UNIQUE keyword.
_______________________________________________________
- Run the Move Volume utility.
_______________________________________________________
- Drop the DB2 indexes used during MOVEVOL processing.
_______________________________________________________
- Execute RUNSTATS again.
_______________________________________________________
- Rebind the following DB2 plans: CBRHSVOL, CBRHSBKV, CBRHSBCC,
CBRHSPCC, CBRHORCL, and CBRHCNTL.
_______________________________________________________
Migrating objects from one media to another takes a significant
amount of time. With this in mind, there are some things that you
should consider that could save time and effort in the future.
- Define expiration criteria for all objects. This should reduce
the amount of data and time needed to perform migration to another
media.
- Adopt higher capacity media into your installation as soon as
it is introduced. If you write all objects to the highest capacity
media available, you might be able to avoid a media migration.
See CBRISQL0 for sample job control language (JCL).