Siebel Database Upgrade Guide for DB2 for z/OS > Preparing a Development Environment for a Siebel Upgrade >

About Moving Tables

Upgrades: All upgrades.

Environments: Development environment only.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

Some of the Siebel tables will have columns added to them as part of the upgrade. When this happens, the length of the record will increase, which might cause it to require a larger table space or bufferpool. Moving the identified tables to a new, larger, and differently named table space allows you to maintain the model of multiple tables for each table space which is present for all pre-7.7 schemas.

Before you move the tables, you must remove any standard or custom views using an SQL DROP command.

NOTE:  If you remove an object that you want to reapply to the database after the upgrade is completed, make sure that you can rebuild it. For example, you can obtain a view definition from the DB2 catalog before removing the view so that you can re-create it after the tables have been moved to a larger table space. You can also use third-party products or other methods to preserve objects that are to be reapplied to the upgraded database.

Complete the following procedure to find the views that are defined on a table. The example in the procedure assumes that you are creating a new 16K table space within the same database as the older, smaller table space.

To find views that are defined on a table

• Run the following SQL statement to produce the list of views:

  select * from sysibm.sysVIEWdep

  WHERE Bcreator = 'yourschema'

  AND BNAME IN ('S_ASSET', 'S_PROD_INT');

This SQL statement produces the drop statements into a sequential data set:

SELECT DISTINCT 'DROP VIEW '||'yourschema.'||V.DNAME||' ;'

FROM SYSIBM.SYSVIEWDEP V

WHERE V.BNAME IN ('S_ASSET', 'S_PROD_INT')

AND V.BNAME = 'S_ASSET'

AND BCREATOR = 'yourschema';

To process these drop statements on the z/OS host, you must create a PDS member with the output from the preceding statement. Then submit this member through DSNTEP2 using JCL.

If you are using the preconfigured storage control file, you do not have to move any tables as a preupgrade task. This is because the existing schema is not being preserved and all tables will be recreated in the 1:1:1 model.