StorageTek 312564001 用户手册
DB2 Manager User Guide
9
StorageTek
Proprietary
request. Standard DB2 processing then requires the use of a cursor
mechanism in order to access each row from the result table, rows being
retrieved via an SQL FETCH command. In cases where rows in the result
table have been migrated from DB2 to Archive Manager, the resulting FETCH
commands may generate one or more tape mounts in order to service the
application program’s SQL request. Access to rows is not necessarily
performed in the physical sequence in which migrated rows are stored in the
Archive Manager database – this may generate an excessive amount of tape
mount activity, with a correspondingly negative effect on application response
times.
mechanism in order to access each row from the result table, rows being
retrieved via an SQL FETCH command. In cases where rows in the result
table have been migrated from DB2 to Archive Manager, the resulting FETCH
commands may generate one or more tape mounts in order to service the
application program’s SQL request. Access to rows is not necessarily
performed in the physical sequence in which migrated rows are stored in the
Archive Manager database – this may generate an excessive amount of tape
mount activity, with a correspondingly negative effect on application response
times.
For this reason, implementation of DB2 Manager for migration of data from a
DB2 table may not be suitable in instances where applications process the
table in the following manner:
DB2 table may not be suitable in instances where applications process the
table in the following manner:
• Sequential processing of the table. This can occur if the application
needs to access all rows in the table (e.g. for historical data analysis), or if
access to specific rows in the table is not performed via index processing.
access to specific rows in the table is not performed via index processing.
• Many rows are required to satisfy a single SQL command. If migrated
rows are among those required to satisfy the SQL command, then
extended response times may be encountered.
extended response times may be encountered.
Note that use of Archive Manager disk copy processing (where copies of
objects in the Archive Manager database are held in sequential disk
datasets) is enabled, then the above restrictions will not necessarily apply.
objects in the Archive Manager database are held in sequential disk
datasets) is enabled, then the above restrictions will not necessarily apply.
Only one DB2 Manager control region is started per MVS system – this will
support access to migrated rows from multiple DB2 subsystems executing on
that MVS system.
support access to migrated rows from multiple DB2 subsystems executing on
that MVS system.
Product Functions
The functions supplied by the DB2 Manager product can be categorized into
three main areas:
three main areas:
1. Migration of rows from a DB2 table.
2. Enabling of access to migrated rows.
3. Management of migrated rows.
These functions are discussed in the following sections.
Row migration
The primary function of DB2 Manager is to enable individual rows from within
a DB2 table to be migrated from DB2 to an Archive Manager database.
Migrated rows will be stored as part of a standard Archive Manager object in
the Archive Manager database, and will be replaced in the VSAM tablespace
dataset by an 18-byte archive “stub” which will contain information about the
location of the row in the Archive Manager database. This will allow space
a DB2 table to be migrated from DB2 to an Archive Manager database.
Migrated rows will be stored as part of a standard Archive Manager object in
the Archive Manager database, and will be replaced in the VSAM tablespace
dataset by an 18-byte archive “stub” which will contain information about the
location of the row in the Archive Manager database. This will allow space