IBM OS/390 User Manual
8.2.1.3 Database Administrators (DBAs)
As with the previous two groups discussed, there are really more similarities
than differences between the two products for the DBA. The design methodology
is the same, whether you prefer normalization or some other technique. The
optimizer selects access paths basically the same way, relieving the DBA from
making this choice. Differences show up in some of the detail work of database
design. Differences exist in the areas of database object sizes, SQL limits,
locking levels, DRDA considerations, referential integrity definitions, and data
formats. SQL/DS is a subset of DB2 in these areas except an SQL/DS table
definition can contain one or more LONG VARCHAR columns that could
materialize an actual row length that exceeds the 32K limit of a DB2 row. If you
do have this situation, you will need to redesign this table to fit within the 32K
row limit of DB2 and modify the programs appropriately that use this data.
than differences between the two products for the DBA. The design methodology
is the same, whether you prefer normalization or some other technique. The
optimizer selects access paths basically the same way, relieving the DBA from
making this choice. Differences show up in some of the detail work of database
design. Differences exist in the areas of database object sizes, SQL limits,
locking levels, DRDA considerations, referential integrity definitions, and data
formats. SQL/DS is a subset of DB2 in these areas except an SQL/DS table
definition can contain one or more LONG VARCHAR columns that could
materialize an actual row length that exceeds the 32K limit of a DB2 row. If you
do have this situation, you will need to redesign this table to fit within the 32K
row limit of DB2 and modify the programs appropriately that use this data.
8.2.1.4 System Administrators
There are more differences in this area than in the previous areas. This is
primarily due to environmental differences in the VSE and the OS/390 platforms.
Both systems provide the entire complement of systems management, utilities
and integrity services expected of a robust RDBMS. However, implementation
may be different.
primarily due to environmental differences in the VSE and the OS/390 platforms.
Both systems provide the entire complement of systems management, utilities
and integrity services expected of a robust RDBMS. However, implementation
may be different.
In both systems, normally all database changes caused by the execution of SQL
statements are logged. However, when running SQL/DS in a single user
environment this logging is optional and when you have an SQL/DS storage pool
with the NOLOG attribute this logging is not done. Both of these capabilities are
not available in DB2 and will have to be evaluated and mapped to a different
DB2 implementation.
statements are logged. However, when running SQL/DS in a single user
environment this logging is optional and when you have an SQL/DS storage pool
with the NOLOG attribute this logging is not done. Both of these capabilities are
not available in DB2 and will have to be evaluated and mapped to a different
DB2 implementation.
Since recovery capabilities and procedures are very different between SQL/DS
and DB2, you must re-evaluate your needs and design a recovery procedure
using the DB2 facilities. This also applies to Utilities.
and DB2, you must re-evaluate your needs and design a recovery procedure
using the DB2 facilities. This also applies to Utilities.
The following is provided to help you in mapping SQL/DS utility functions to DB2
utility functions:
utility functions:
•
Reorganize a table
SQL/DS - DBSU UNLOAD/RELOAD
DB2
- REORG utility
•
Update table statistics
SQL/DS - UPDATE STATISTICS SQL statement
DB2
- RUNSTAT utility
•
Load data into a table
SQL/DS - DBSU LOAD
DB2
- LOAD utility
•
Unload data to a user defined sequential file
SQL/DS - DBSU DATAUNLOAD
DB2
- not supported
While both SQL/DS and DB2 operate from the same relational basis of viewing
data as tables, the underlying storage structures used differ. At the logical level,
a DB2 database is composed of one or more tablespaces which in turn are
composed of one or more tables, and indexspaces, which contain one index. In
SQL/DS, both tables and indexes are stored together in dbspaces.
data as tables, the underlying storage structures used differ. At the logical level,
a DB2 database is composed of one or more tablespaces which in turn are
composed of one or more tables, and indexspaces, which contain one index. In
SQL/DS, both tables and indexes are stored together in dbspaces.
180
VSE to OS/390 Migration Workbook