The issues for the cutover without replication approach are described in the following sections:
Upgrade all databases to release 12.5 at the same time. A cutover without replication is common in small organizations for development or production servers. It may be used in larger organizations when you are able to schedule sufficient downtime.
Base fallback on the amount of time needed to restore earlier databases. For example, if users need the system Monday at 8 a.m. and the restoration takes 8 hours, the validation test must pass by Sunday at midnight.
Remember to include client fallback time in the calculation.
You can use dump database or bcp out before an upgrade to prepare for fallback.
Plan a way to capture transactions after cutover to be used in case of fallback. If you go into production and then need to back off, you will have to restore all the transactions that occurred after the last dump/load.
For a development system, simple validation may be adequate. However, for a production system, the test suite must address both update correctness and performance acceptability.
See Chapter 7, “Test: Ensuring Stability and Performance” for more information on testing.
You might want to validate over a 3-day weekend if possible.
Consider making daily bcp dumps of the databases. You can then load the dumps into the earlier server to fall back. Keep in mind:
You may need to modify the databases to support incremental bcp dumps.
Earlier servers 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 apply 12.5 schema enhancements.
For information about scheduling backups of user databases, see the System Administration Guide.
There should not be any user impact during migration. The more stringent the validation test is, the less likely you will have bridging issues.
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.
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.5 issues.
For a production system, be prepared to postpone or back off if needed.
