You can change a database by using a deployment script, which is
a set of changes that a user, or group of users, wants to effect at a single
point in time.
You can use the Deployment Script Editor to change a database schema. The
following figure illustrates the Overview Page of the Deployment Script Editor:

Figure 1. The Deployment Script Overview Page
The tabs of the Deployment Script Editor contain actions that you can use
to perform your database change.
- Overview tab
- The overview tab provides an overview of your change management project.
You can view your connection information, the last action that was performed
in the change cycle, your deployment script contents, as well as deployment
and verification options.

The purpose of the Last Action, or deployment
script state, is to indicate the last action performed and help to indicate
the next action to perform. A history of actions for any particular change
is stored in the deployment script XML. The sequence of states can be reviewed
later on if the deployment script for each change is being saved for auditing
purposes. The states are cleared when the deployment script is reset. The
following is a list of states that might be displayed in the Last Action field:
- New
- The deployment script is in the new state when it is first created or
after is has been reset. This state indicates little customization has been
done to the script. The likely actions from this state are to edit the target
model or add a source model on the Models tab of the Deployment Script Editor.
- Modeled
- The modeled state is reached when you edit the target model. The likely
action from this state is to generate your change commands.
- Migrated
- The deployment script is put in this state after you use the migrate option
to copy data objects from a source model to the target model. The likely action
from this state is to generate your change commands.
- Refreshed Base Model
- The deployment script is put in this state after the base model has been
refreshed. The base model would need to be refreshed if a change has been
made to the database catalog since the time that the deployment script was
constructed. The baseline is checked against the database catalog when you
attempt to deploy your change commands. The likely action from this state
is to compare your base and target models in order to forward fit any necessary
changes.
- Generated
- The Generated state is reached when you either generate your change commands
by using the Generate Change Commands wizard or when you select the data migration
option. The likely actions from this state are to deploy your change commands
or to generate data migration commands.
- Deployed
- The deployed state is reached after you deploy your change commands. The
next possible actions are to reset the deployment script, commit your changes
and tag the files in your library control system, undo your changes, or refresh
your base model.
- Undo
- The undo state is reached after you have reversed your changes. The next
possible actions after undo are to reset the deployment script, commit your
changes using Eclipse Team, or to fix the problem that made it necessary to
undo your changes.
- Multiple Provisioned
- The multiple provision state is reached after you have deployed your changes
to multiple databases.

The Outline view also displays
the state of your deployment script in parentheses as well as a check mark
next to each completed step.
- Data Models tab
- You can specify and compare your base and target models from the Data
Models tab. Click Compare Base and Target Models to
display the Comparison Editor. The models that you are comparing are displayed
as follows:
Table 1. How models are displayed in
the Comparison EditorType of Analysis |
Left side of the Comparison Editor |
Right side of the Comparison Editor |
Impact analysis |
Base model |
Target model |
Migration analysis |
Model from another environment |
Target model |
- Change Commands tab
- Use the Change Commands tab to generate the change
commands that are necessary to change a database (DDL, export and import commands,
and maintenance commands for runstats, rebind, and flush package). Specify
the order of your commands for deployment, and deploy the commands against
the database catalog. The order of commands is important. For example, export
commands must be deployed before the change command delta DDL files because
the data needs to be exported before the destructive changes occur. Import
commands and maintenance commands should be issued at the end and must be
at the bottom of the list.
You can also use this tab to generate the change
commands (DDL, export and import commands, and maintenance commands) that
are necessary to undo the change.
- Undo Changes tab
- Use the Undo Changes tab to verify the undo commands
necessary to back out your changes, specify the order of your commands for
deployment, and deploy the undo commands against the database catalog.
- XML Source tab
- Use the XML Source tab to view the XML for the
change commands that DB2® Change Management Expert will
deploy against your database catalog.
- Multiple Deployment tab
- Use the Multiple Deployment tab to deploy your
changes to multiple databases at one time. This tab is only displayed after
a deployment script is created and then selected for deployment to multiple
databases. DB2 Change Management Expert also
supports generation of data preservation commands and maintenance commands
during multiple deployment.
In general, the process of using a deployment script to change a database
schema consists of the following steps:
- Changing your target model
- Generating your change commands
- Deploying your change commands
The details of the process are as follows:
- Changing your target model
- The deployment script always references a base and a target model. These
are models of the same database but potentially at different points in time.
You
can edit your target model in a variety of different ways. It can be edited
by using the Data Project Explorer, the Data Model Editor, the Comparison
Editor, or the Diagram Editor. You can edit the properties of your database
objects by using the Properties View.
You can also migrate object definitions
from other databases. The primary way to migrate objects from other databases
is to add the source model to the Data Models page of the Deployment Script
Editor and click Migrate. The migrate action displays
the Comparison Editor.
Compare your base and target models before you
generate your change commands. This will allow you to quickly review the differences
that your changes will create between your models.
- Generating your change commands
- The Generate Change Commands wizard is located on
the Change Commands page of the Deployment Script Editor. If you make changes
to your target model, you should regenerate the change commands before you
deploy them to the target database. You can specify your data preservation
commands in the Generate Change Commands wizard.
- Deploying your change commands
- From the Overview page of the Deployment Script Editor, click Deploy
changes to the target database to deploy your changes to the database
catalog. The change commands are issued against your DB2 database. You can
also deploy your changes from the Change Commands tab.
Resetting and reusing a deployment script
After you have deployed your changes to a database, you can reuse the
same deployment script for deploying another set of changes. To do this, you
will have to reset the deployment script by selecting . The reset operation will reload
the base and target models so that they are current. You can also specify
new schema and database element filters for the new deployment process. The
other deployment script elements, such as delta DDL file, export command file,
and so on, that were created during the previous change management process
will be deleted. The state of the deployment script will be reset to New.