This topic of best practices will focus on the how to plan for, and implement “minimum down time” migrations of your Source Database Platform into the SAP Sybase ASE Platform. The architecture and high-level planning steps presented in this blog should help you understand how we can implement this technology and how best to use this technology wisely to achieve our results: keeping the business operational during the migration period.
First a bit of housekeeping – this talk will be for “Custom” or “Non-SAP” applications only. While SAP Applications will be considering this technology the nuances of Non-SAP compared to SAP are best left for another topic.
What do we mean by “minimum down time?”
Minimum Down Time is akin to starting on our migration trek by implementing small understandable steps. Migration with minimum down time is never a “big bang” or turn the switch migration. Through my past blogs you should understand that migration of one Database Server to another involves the porting of the schema or tables, the data records and the compiled code inside the Source to the Target. While we can freeze the schema creation and the compiled code to bring over in a relatively short time, the time in the migration duration or outage is the initial load of data from Source to the Target.
We have two phases to our migration of data: Phase 1, the Materialization Phase and Phase 2, everything after the Materialization Phase. The Materialization Phase involves:
- the movement of data out of the Source Server ,
- the movement into the Target Server,
- generating target specific indexes and statistics.
During this materialization phase (aka initial data load) we need to have the Target System isolated free from no data manipulation to allow these activities to complete in the shortest time possible.
Here is the crux of the issue we are trying to solve.
For very large database instances in the Materialization Phase, the allowable migration cutover time (as dictated by an outage window given by the Business) could be exceeded. The second issue is the Servers need to be frozen during this process. Complicating the migration design, some Business’ cannot be inoperatable for more than a couple of minutes.
The Materialization Phase tasks can be parallelized to reduce this outage however, the issue still remains, there is an outage. The tool we chose must be capable of not only materializing the data from Source to Target but be capable of doing this with no descernable Source Database Server outage. The goal is to have the Source Server be “business as usual” during the migration data implementation.
Lets summarize what we need from a migration tool for minimum downtime:
- ability to let the data materialize from Source to Target
- ability to let the Source be unhindered for normal business processing during phase 1 and phase 2.
While there are multple tools that can solve this puzzle, as this blog is “Best Practises when migrating to the SAP Sybase ASE Server“, the tool presented here is the minimum downtime architecture solution provided by SAP Sybase Replication Server. The SAP Sybase Replication Server product provides real-time data replication from the Source Server to the Target Server. While the SAP Sybase Replication Server product is completely open as to different vendor databases on the Source and/or Target we will present an architecture that features a non-ASE Source being data replicated to the SAP Sybase ASE Server.
Shown is a simple architecture featuring Replication Server that can be used for our migration example.
In this example we are featuring one way replication from Source to the SAP ASE Server. We can by default of this architecture, set up bi-directional replication to allow a “back out” strategy to our migration. In bi-directional replication, the “Source” now becomes where the records are originated from, or in other words the Database Server where the Applications are currently connected to.
To allow a timely load of data from Source to Target, SAP Global Service Consultants can use any third-party tools you may have or we can construct a flat file load. While Replication Server can materialize data in Phase 1, we generally perform this outside of Replication Server to make this faster. But keep in mind we are talking about having enough time to do this migration implementation at our leausure – so any method you choose (fast or slow) if you follow this implementation design we have architected this solution for your convienience.
Lets walk through an implementation of this technology so you can understand the “how” of this minimum down time solution. High-level activites with a why it is a “minimum down-time” solution and data validity are featured in the below table.
|Activity||Why minimum downtime?|
|Build target ASE Server||Source Server unaffected by reads.|
|Build Replication Server||Source unaffected, only logs are touched|
|Build replication publish and subscribe scripts with autocorrection||Source unaffected, replication is transparent by reading Source Database logs.|
|Stop replication connection to Target ASE||Source unaffected. We are saving all records from the Source especially those that may be missed by the Phase 1 Materialization operation.|
|Truncate data on target side||Source not touched.|
|Phase 1: Read data on source side||Source data being read only, ad-hoc records being recorded by the transaction logs and stored in Replication Server|
|Phase 1: Write or Materialize data on target side||Source unaffected. We are saving all records from the Source especially those that may be missed by the Phase 1 Materialization operation.|
|Resume replication connection to target.||Source unaffected. We are now applying records that were missed by the Phase 1 Materialization operation.|
|Done.||Source unaffected. Steady State achieved|
|Cutover Client Application to point to new Target Server||Minimal downtime experienced in time taken to disconnect to original Source and reconnect to Target|
The take away points on the above table is the fact that one can build, materialize and have continued transfer of data from the source to the target with none or minimal downtime. The only downtime we experience is when we need to affect the envionment outside of the Database Servers.
Obviously one can see that for some migrations this planning of minimal downtime does promote a more involved setup and monitoring of migration processes. With any designs there are pros and cons.
If you have any additional questions or comments on this Migration Implementation concept please do not hestiaite to contact myself or the SAP Global Services Team.
please don’t forget ……..
Follow the “Database Services Content
Learn more about SAP Database Services here http://www.sap.com/services-and-support/data-and-technology/database-services.epx