When you install DB2 Satellite Edition on a system that already has a production DB2 environment, the pre-Version 6 code is replaced, and the DB2 environment is migrated to Version 6. Because the system was already in production, it will be at a different state than a system that did not have DB2 on it before DB2 Satellite Edition was installed. For example:
By contrast, a newly installed system does not have this level of initial customization. For these new systems, you can use the Satellite Administration Center to define batches for the group to accomplish this customization when they first synchronize.
If the migrated systems and new satellites will be running the same end-user application, you will likely want them to be members of the same group. You do not, however, want the migrated systems to run the batch steps that a new system will run to perform the initial customization. The Satellite Administration Center supports this by allowing you to set an execution starting point for a satellite. In our example, you would set the execution starting point for the migrated satellite so that the initial customization scripts are bypassed.
In addition to the steps described in the Post-Installation Steps, there is one required migration step that is not completed by the Version 6 installation program; the databases created on a version of DB2 earlier than Version 6 are not migrated to the Version 6 format. Also, you may want to perform several optional post migration actions:
Because all migrated systems will have to have the same commands run on them, you can placed these commands in a one-time fix batch, that can then be run by all the migrated satellites. The fix batch would run the database migration command, and perform any post-migration steps that are required to get the migrated systems ready to start running group batches. When the satellite has run the fix batch, the satellite can be promoted from fix batch mode to group batch mode, during which time the execution starting point can be set.
Consider a sample scenario to outline the process that
will be required to successfully complete a sample migration. In this
scenario, you will migrate a set of systems running a DB2 Personal Edition
Version 5 environment to DB2 Satellite Edition, while at the same time
supporting the implementation of new systems running DB2 Satellite
Edition. Compare the state of these systems:
| State of the Satellite | Satellite migrated from Version 5 | Newly installed Satellite |
|---|---|---|
| Database needs migration | Yes | No |
| Database definitions require setup | No | Yes |
| Database and Database Manager configuration values require customization | Yes - to use new DB2 Version 6 features and DB2 Satellite Edition features. | The Database and Database Manager configuration values, which are optimized for DB2 Satellite Edition and its features, are set up when the system is installed. |
| Packages are invalid and need to be rebound | Yes | No |
| Bind application packages if needed | No | Possibly |
| Data replication has been defined | Yes | No |
Assume that once both types of satellites have reached a common state, they will then run group batches to accomplish ongoing administration and to run the data replication process.
Every satellite migrated from a pre-Version 6 environment will need to have its database migrated, and you may want to perform other optional post migration activities. You can accomplish this in one of two ways and you will have to decide which method is more appropriate for your environment:
You should use a fix batch because the results on each system can be easily tracked using the Satellite Administration Center. When you have decided on the method you will use and read the appropriate section, continue to the next section Migrating from Previous Versions of DB2.
Situations may exist where you will choose to use your own scripts, and an established technique to execute them, to migrate your databases to the Version 6 format, and to perform other customization in preparing the migrated satellite to join a group and start executing group batches. In this situation, the satellites do not have to run a fix batch. Instead you can:
The migrated satellite will now run group batches each time it synchronizes. You may want to have the satellite's end user run the synchronizer application in test mode, by running db2sync -t, to ensure that the satellite is set up to synchronize before the first production synchronization.
Two approaches that would be valid:
You should consider the first approach. The satellites to be migrated are known, and can be tracked until all of them have run the fix batch. As the migrated satellites complete the execution of the fix batch, then promote the migrated satellite for group batch execution, and set the point at which it would being running group batches. You may want to place the migrated systems in a special subgroup, for example migrated, when they are created so that their progress can easily be tracked using the sort and filter capabilities of the Satellite Details view.
Using this technique to handle migrated satellites, new satellites can be added to the group at any time, as the group batches they run would always perform the initial customization for them, without intervention from an administrator to set them up to run a special fix batch.
Using the scenario, as described in A Sample Scenario, and assuming that you create the database during installation, the setup group batch would contain the following steps to accomplish the initial customization of a new system:
An application version would be created for the group, and the setup batch would be associated with the application version. An update batch should be associated with the application version, which would contain scripts to run the data replication process.
As new satellites are defined in the group and connect for synchronization, the setup batch would be run to customize them, after which they would continue to run the update batch on each synchronization, which runs the data replication process.
To handle the systems migrated from a pre-Version 6 environment to DB2 Satellite Edition, you would use a fix batch. The fix batch should include the following steps:
A complete list of the post-database migration activities that can be performed may be found in Optional Post Migration Activities.
As discussed in Chapter 4, Cataloging Instances and Databases, the targets of the script execution must be cataloged on the satellite. The instance and database names must match those for on the Control Center's instance, as these will have been used to name targets when the targets are created using the Satellite Administration Center. In addition to other migration activities, the fix batch may have to catalog additional node and database directory entries so that all the targets of script execution are defined on the migrated satellite.
The systems migrated to DB2 Satellite Edition would have to be created using the Satellite Administration Center, and would be set up to run the fix batch on their initial connection. As outlined above, once this fix batch is run, these satellites can be promoted to run group batches and the initial step that they would run in each batch can be set.
Step by step, here is what you would do:
| Note: | Running the synchronization application in test mode will not cause the fix batch to run. |
After the fix batch has executed successfully, or produced satisfactory results, the migrated satellite is ready to run group batches. To have it start executing group batches, select the "Promote" action for the satellite, set its execution starting point as required and click on OK.
| Note: | If the fix batch produced satisfactory results but still failed in execution, you will need to enable the satellite for batch in addition to promoting it. |
The system will now execute group batches the next time it synchronizes.
| Note: | The information in the Migrating from Previous Versions of DB2 should be reviewed before beginning the process of migrating systems to DB2 Satellite Edition, and enabling these systems for group batch execution. |
[ Top of Page ]