50 DB2 Nuggets #14 : Expert Advice - Continuous availability and DB2 migration using InfoSphere Replication Server

Body

Continuous availibility is the concept that enables 24/7 access to IT-enabled business functions, processes and applications.
And minimizing planned downtime is what business and IT departments consider seriously nowadays.
Especially, minimizing and setting the appropriate downtime is a bit challenging decision in case of DB2 version upgrade or migration to another system, because we also need to consider the time for getting back to original system in preparation for any unexpected problem after the planned change works. 

I would like to give an idea in this blog  for those kinds of cases which had been already proven and done from a very clever customer’s real migration project.

Typically, we use 'db2 upgrade' command or ‘export/import’ for the database migration. And once the database starts to operate in new system and version, it’s really hard and tricky to make a decision for reverting to previous system when there are some problems in new environment.

By using InfoSphere Replications Server (IRS), we can consider to try following steps and ideas in terms of reducing the downtime. 

< While current systems is operating>

1. Configure the uni-directional mapping of all tables for both current system to new system and new system to current system.
    New system to current system mapping will be used just in case that new system has some problems after the migration.
 
2. About 7 days before the new system open, start the IRS capture processes with cold start mode and stop quickly just to let DB2 identifies the transaction log timestamp and sequence number that IRS needs to catch up.

3. Export all table data and load to new systems.
    At this step, we need to monitor the current system load and control the concurrent export works.

4. Start IRS to catch up the data up to current time.
    As we marked the start time point in step 2, IRS will replicate the data by ignoring the data, which had been already moved to new system by export and load works.
    If you worry about possible impact with IRS capturing to current system, we can choose to start the IRS only in the nighttime.

<Downtime for new system open>
5. For system open on new system, we just need to stop the business database systems and configure the applications servers to use new database system.

    If you feel like checking the row count of all tables, you may need to take additional time depending on the elapsed time for counting the rows of the biggest tables.

<After new system is launched for real business application>
6. And the next step is just starting up the new database.
    In preparation for possible significant problems, we can enable the IRS table mapping from new database system to old systems.
   As old system catches up data transactions in new system by IRS, we can quickly revert to old system exactly same way in steps 5 and 6.
 

As we can see, this way provides the effective way to save the typical downtime with DB2 migration and easy way to get back to old system as well. Of course, you can continue to use the new system and remove the old system once all relevant departments give the confirmation that the new system runs normally.

If you want to consider this way for your upcoming migration project case, you can refer to the ‘Q Replication’ sections of DB2 Information Center for getting more details about IRS.