You’ve done the Proof of Concept (PoC) and now everyone clamors to put the system into production. Some see the application running after the PoC and ask you to link it in to the network. Yet, you know that you put this system together, and the finishing touches were done with chewing gum and bailing wire.
Looking at the production system, everyone can see that the source application has been receiving data since you started the PoC. How is that new data going to get into the application? The bottom line is that it really can’t. The referential integrity issues alone would stop you and of course, you can’t go and apply the applications log files (unless they are in character form).
What are your options here? You could export all of the data that has changed during the period, but how do you distinguish or even find the data that has changed? Not to mention, when you apply the changed data, new data still comes in. What are you going to do with that?
The solution is a migration of the actual production system while it runs. There are various techniques to do this but all require you to assure the boss that everything will be OK. You know now that you can do the migration (the POC proved that) but how will it be done on the production system. Most importantly, how do you minimize downtime? How long is the downtime going to be?
So, now is the time to take those lessons learned in the PoC and apply them to the migration process. What does this mean? In the PoC process you probably moved a part of the system, and then moved another part. You discovered you need to adjust the tuning of the server’s operating system and then the DBA told you that you forgot a link. This was followed by problems in the execution of the application that required analysis and correction. (See? bailing wire and chewing gum.)
Luckily, you documented all of the changes and determined the proper implementation sequence (or at least you think it is the proper implementation sequence). You also discovered that you can parallelize a lot of the steps and reduce the down time of the application. Meanwhile, you have management asking when you can have the application migrated to the new platform. For instance, at one site we were moving a retail program, RETEK, and Thanksgiving was fast approaching. They needed the extra horsepower to handle the Christmas rush, and they had to input all of the Christmas marketing programs into the system.
To answer these questions and address the concerns, execute a rehearsal of what you plan to do for the actual migration. Plan is the operative word here.
Take what you learned from the PoC and organize it into a coherent plan with the events sequenced correctly. Plan on running as many tasks as you can in parallel. Plan on doing as many tasks as you can before you have to shut down the production system for the cutover.
Back in the day when export/import was all that was available for the migration of an Oracle database, I would build the target database, create all of the production tablespaces as small I could, and create the users. Then, I could ‘ADD DATA FILE’ in parallel until each tablespace was big enough for the data. After that, I would create all of the tables with enough extents to hold all the data (we don’t want Oracle to use time having to extend the tables while the production system is down). With the tables, I could create and compile all of the Packages and Procedures. I then turned off all referential integrity constraints and Triggers. Only then was the production system put into single user mode for the export of the data. All we needed to export were the rows of data; no indices. Once the data was inserted, we fired off the index create statements, and ran them in parallel. Once the indices were completed, the referential integrity constraints were ‘ENABLED’, thus setting off another round of index building.
Now that you've moved the application, you'll need to run your the application in your test harness for regression testing. The testing will 'prove' that the migration is complete.
A final check of the database, and it opened up. Here is an illustration of the process I just described.
Today, you can use GoldenGate or Streams for Oracle database migration or you can use Replication Server for Sybase. GoldenGate allows you to run the production and the new database in parallel, and even roll the migration back to the original database in the event that something goes wrong.
Wouldn’t it be better if that ‘something that goes wrong’ occurred when you executed the rehearsal of the migration of the Q/A database? A little patience will result in greater likelihood of complete success.
Here are the rehearsal steps in a flow chart:
Now that you’ve done the rehearsal, documented every step, and developed scripts to automate every process that can be automated, you are ready to plan the actual production migration and answer the question, ‘When is the application going to be ready on the cheaper platform?’
Comments