One of the main task as a DBA is working with objects. Since there are at least two environments (typically one or more for testing and one for production) DBA’s face the challenge of moving changes done in one environment to one or more other environment(s). Toad helps the DBA to undertake this comprehensive and time-consuming task with two very powerful features.
BTW – the features I am going to present are available for DB2 LUW and DB2 z/OS!
If you have made any changes such as CREATE’s, ALTER’s or DROP’s of objects in the test environment the next production database release means that you have to provide DDL scripts, which contain all or parts of these changes. But there are some bullets which have to be dodged:
· the single DDL statements need to be in the correct order
· an object needs to be dropped and recreated with a different definition (i.e. a new column in the middle of a table) so you have to be careful with the data in the target table
· objects have a different naming in their particular environment or have a completely different mapping, i.e. a table uses another tablespace
Toad for DB2 offers you two features for this: COMPARE and MIGRATE, which can be accessed via a right click on one or multiple objects like TABLESPACES, TABLES, INDEXES, PROCDURES or PL/SQL PACKAGES and so on. A wizard will start up and guides you through the configuration.
What are the differences between these two features and in which case I should use which feature?
Within the MIGRATE feature you can move objects from a source to a target environment. It generates the CREATE statements for the selected objects, their dependent and referenced objects, data and statistics and applies your transformation rules.
In the next step the target environment is specified, where you want to move the objects to:
Next you configure if you also want to migrate the dependent or referenced objects and how many levels below or above in the object hierarchy, the data, the statistics or if you want to run a DB2 RUNSTATS. Please be aware that the selection of the option “process of multiple object levels” needs a bit more time depending on the amount of objects. If a tablespace is migrated and you select “include objects that are dependent upon those originally selected” you will migrate also the tables of that tablespaces. With the multiple object level option also ALL dependent objects of the tables like indexes and views will be migrated as well. The same happens if you select the option “include objects referenced…”
Now we get an overview of all objects we are going to migrate and what will be migrated. The possible options available are:
· Only the objects definitions (DDL) and/or the associated data are migrated
· In addition, optionally the statistics can be migrated and/or DB2 RUNSTATS executed or neither of the two.
If you want to you can now change the objects to be migrated and the configuration of data and statistics for each object.
In the following “Define Transformation Rules” step you map the affected tablespace and its path, bufferpool, schema (storage group, database VCAT for DB2 z/OS) of the source environment to the corresponding objects in the target environment. Per default no changes are set, but you can configure the desired changes i.e. which tablespace should be used for tables in the target environment. Those objects don’t need to exist. For example: If you migrate a tablespace with all its tables from A to B and you want to give it another name you can specify this new name as a transformation rule. Or if you migrate multiple tables and you want to put them into another tablespace (or the tablespace path of source and target is different) – just specify the other tablespace in the target! For a future reference this scenario can be saved and loaded in case of re-use.
We are almost finished. We can specify the path where the DDL script(s) and report will be saved. In case you migrate with data option, two scripts are created: one for the export of the data in the source and another with the DDL and import in the target. The migration report is a good documentation of the migrated objects.
Since you are able to migrate objects (or more accurately DDL’s), data or statistics you can use the MIGRATE feature to migrate only data of tables or only the object statistics of the selected objects from A to B. I.e. in order to use the statistics of the production environment in your test environment to test the access paths of new packages– you can do it now with MIGRATE! So this feature is useful, if there are no corresponding objects in the target or if you want to place them somewhere else.
The COMPARE feature does an additional step: it compares the objects you want to move from the source environment with existing objects in the target environment and takes following action:
· If an object in the source does not exist in the target – it will be created in the target.
· If an object already exists in the target and the source object is different – the target object will be changed to equal the source.
· If an object does not exist in the source but in the target – the target object will be untouched.
To have an overview which objects are equal, different or exist in the one but not in the other environment you will get a comparison report like this where you can see which objects are equal or different and if you select an object the differences of the DDL are highlighted.
For COMPARE it might be useful to ignore some minor differences which you do not want to alter such as remarks or “not logged initially” differences. This can be done in the advanced options:
The COMPARE feature should be used, if there are existing objects, to which you want to apply changes.
So the bottom line is that Toad for DB2 can saves you a lot time for scripting and you can be sure that every object and dependent object is covered. No more deciding on how and where to export/import data – just configuring what you want and Toad does the correct scripting for you! Furthermore you can use the remote command execution feature in Toad to schedule the scripts on remote machines. This is described in one of my older blogs:
More ...
Category: Toad for IBM DB2