The issues for a phased cutover are described in the following sections:
Change only one application and database to release 12.5 at a time.
Consider making daily bcp dumps of the databases. To fall back, you can then load the dumps into the earlier server. Keep in mind:
You may need to modify the databases to support incremental bcp dumps.
The earlier server cannot read release 12.5 backup files. You need to create bcp or other scripts to move tables back to the earlier server.
Do not use release 12.5 schema enhancements until the conversion succeeds.
For information about scheduling backups of user databases, see the System Administration Guide.
Ensure that the application test suite addresses both update correctness and performance acceptability. Also ensure that you do the following:
Maintain the directories/libraries for both releases.
Make sure the applications are using the correct server.
After successful validation, consider having users enter production queries with the production toolset. A good time to do so is after hours or during production lulls.
See Chapter 7, “Test: Ensuring Stability and Performance” for more information on testing.
There should not be any user impact during migration. The more stringent the validation test is, the less likely you will have bridging issues.
The earlier server cannot read release 12.5 backup files. You need to create bcp or other scripts to move tables back to pre-release 12.5.
Do not use release 12.5 schema enhancements until the
conversion succeeds.
Be sure to account for any increased release 12.5 memory requirements that apply to your configuration. For more information, see:
The installation guide for your platform. It gives basic RAM requirements.
Chapter 6, “Implement: Making Database Administration Changes”.
Details on configuring memory and data caches in the System Administration Guide
Information on how to configure memory for performance in the Performance and Tuning Guide.
Here are some additional tips:
Execute performance measurements on a system with similar capabilities.
For a production system, execute the performance suite during off hours.
For a development system, you may want to add a short period to the development schedule for release 12.x issues.
For a production system, be prepared to postpone or back off if needed.
Be sure to notify users when you will be taking applications or databases offline.
