The issues for the parallel-with-replication approach are described in the following sections:
The following general method can be used to perform a parallel upgrade with replication:
Install a new copy of ASE 12.5
Copy in or load pre-release 12.5 databases
Use Replication Server to maintain both sets of databases. The 12.5 system becomes the primary server, and you maintain the pre-12.5 system as a warm standby.
Plan for all users to reconnect to the earlier version server after you take ASE 12.5 offline. Make TCP/IP address and port changes where appropriate.
Test the fallback process as part of the application test suite. This suite should do both of the following:
Insert data into ASE 12.5. The data must be replicated and available in the earlier server.
Execute the fallback script.
Consider making daily bcp dumps of the databases. To fall back, 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 pre-release 12.x.
Do not apply schema enhancements.
For information about scheduling backups of user databases, see the System Administration Guide.
Additional tips:
Upgrade Replication Server first.
Be sure the applications are using the correct server. For details on the interfaces file and the $DSQUERY environment variable, see the configuration guide for your platform.
Remember to include client fallback time in the calculation.
For 24x7 sites, load time delays can impact synchronization. Consider replicating to ASE 12.5 and then switching servers.
Since the parallel with replication approach is best for high availability applications, it is imperative that the test suite address both update correctness and performance acceptability. Execute this suite before switching users to the new system.
See Chapter 7, “Test: Ensuring Stability and Performance” for more information on testing.
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.
There should not be any user impact during migration. The more stringent the validation test is, the less likely you are to have bridging issues.
To ensure correct updates and acceptable performance, test the replicated environment.
See the Replication Server product manuals for more information.
The environment used for ASE 12.5 needs to be more powerful to handle the query and replication loads. See the Replication Server configuration guide for your platforms by going to the Replication Server product manuals.
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 theSystem 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.
Developing and running the replication facility, validation and performance suite, and fallback script requires significant effort. If your environment already uses replication, this effort will be notably easier.
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.
