SAP System Cloning & Copy, what is it all about?


Every SAP customer needs to make a copy their SAP Production system, for a wide variety of reasons, ranging from refresh of the Production database for new development work, to creation of a sandbox for testing new patches or version, to have a functional or load testing environment using the latest Production data, to creating a training environment.

All SAP customers are typically familiar with how to perform a system copy, which is in fact SAP’s recommended way of making a duplicate for the purposes mentioned above.


But the problem is that SAP’s traditional system copy is such a time consuming and resource intensive process that most customers don’t do it very often, such is the high level of pain and trauma that this sort of operation can cause.  It is quite common to hear customers state that “we only do system copies once or twice a year” and “it takes anywhere between 3 to 7 days for us to fully complete a system copy”.

So several vendors, including EMC, have unveiled various SAP system cloning and copy solutions to address this challenge and offer the SAP customer something more manageable.

In this first of a series of several blog posts, I will discuss why SAP system copies are such painful exercises, as well as review what would make for a good SAP system copy solution and point out which EMC technology could be used to address this requirement.  I will eventually conclude with a complete explanation of EMC’s own SAP Intelligent Cloning solutions.

In an ideal world, making a copy or clone of the SAP Production system should be a one-push-button operation, akin to the mythical Easy Button (of Staples fame).  But what makes this such a difficult thing to achieve is the fact that each SAP customer’s needs can be different, and there are varying degrees of complicated pre-processing and post-processing activities which must be performed, depending on purpose of the copy, in order to make it useful to the SAP customer.

OK, so why is a SAP system copy such a resource intensive operation?  It’s because the CPU of the SAP Production server has to process the copying of the data from the source database to a destination database.  Depending on how large the database is and how busy the Production system is, this copy operation could take hours and while the copying operation is underway, the performance of the Production database server and the storage subsystem will adversely be impacted.

What’s needed is a SAP system copy solution which does not put any overhead on the Production database server, and which can very quickly make a copy of the SAP database (we’re talking of copying terabytes of data in minutes and not hours).  There are many vendors which offer solutions which can copy the data very fast, such as using snapshot technologies as an example.  But only EMC offers a solution which copies the data very fast and put no overhead on the SAP Production database server: on a VMAX with Enginuity 5875, TimeFinder Snap allows for the creation of up to 128 independent snaps of database very quickly, and since the creation of the copy is done at the storage array level using the SYMCLI, the SAP Production database server is not even involved, and therefore there is no CPU overhead requirement or implication whatsoever.

Then once the copying has been done, you have a lot more work to do in order for the copied version to become usable. Of course, unless the copy is purely for backup purposes, either to tape or disk, or as a point in time copy or snapshot, SAP customers need to perform quite a bit of post cloning activities (such as changing the instance name from PRD to QAS, changing the path names for data files, turning off printers and cancelling current print jobs, cancelling existing pre-scheduled batch jobs, redirecting RFC destinations, and so on) before the copy of the SAP database can be turned over to the group which had requested it.


This post-cloning work is often done manually be SAP Basis personnel, and it is very difficult, and almost impossible, to automate with scripts since many of these tasks involves login into SAP using the SAP GUI and executing transactions.  SAP customers often lament that this post-cloning work can take days and it's the reason why making SAP system copy is such a painful exercise.

In the next blog post, I will discuss what’s involved in these SAP post cloning tasks, including when to execute or not the infamous BDLS job (which could take days no matter what), what is commonly being done by SAP customers, and how various vendors including EMC handle the pre and post-cloning tasks.

In subsequent blog posts, I will review if and how snapshots of SAP Production database can be used as point in time (PIT) copies for easy recovery, but I will also discuss how PIT can perhaps be much better handled by RecoverPoint CDP.

Next blog post: what are some of the post-cloning activities and how are they being handled?


Stay tuned!


Tim K. Nguyen

SAP Global Technical Evangelist & EMC Cloud Architect

EMC Solutions Group