Copying Production data to DEV and TST
There has been a bit recently written in BLOGs and in the TwitterStream about whether to copy Production data around the SAP landscape or not. So I decided to write about the personal experiences of a NetWeaver infrastructure guy who has been cloning SAP systems since the R/2 days. (If you remember SAPUNLU and SAPRELU, like me, you also have grey hair!)
Examples of where system copies pay for themselves:-
- Creating training systems. Although CBT courses are all the rage now, for my money, there is nothing better than getting a feel for real navigation, real transaction data and real response times.
- Creating Volume and Stress systems. Unless you have properly sized tables, with representative data, your Mercury scripts will not be representative of real life response times.
- Applying Enhancement Packs. According to all the guides, EHP4 is a straightforward exercise. True if you try on a 200gb Sandbox ERP system – painfully untrue if you try on an 8tb Production cloned system. We found out the size of the biggest table EHPI can handle.
- Messing with the switch framework. The new switch framework is great, you can activate new functionality by running a single transaction. Tick the box, and the batch jobs will be initiated in the background to compile programs and convert data. Takes 2 minutes in a 200gb Sandbox – takes 2 hours in an 8tb Production cloned system. Take care here; the switch process cannot be reversed if you change your mind.
- Activating New GL in an ERP system. The New GL offers several functional enhancements including document splitting and real time integration with FI-CO. The conversion process must be performed and tested on the most up to date financial postings. Testing on a TST system gives wildly different results than on PRD. But you only get one chance on PRD (unless you have ultra fast backup and restore processes)
- Basis testing of database improvement initiatives such as online reorganisations, Oracle advanced index compression, Unicode conversions, Oracle partitioning, Oracle Flashback, Archiving, etc. Trying on a 200gb Sandbox is fine, but this is far from representative on an 8tb Production system.
Responsibilities when copying Production data
- Production data is still Production data when you copy it. You must control access to the cloned system or the copied data.
- HR data should be scrambled. There are legal and privacy implications here.
- All printing should be closely controlled, unless you want a bogus payslip, remittance advice or cheque being printed
- All SM59 connections in and out of the cloned system must be controlled.
- Login screens must be changed to prevent the cloned system being mistaken for Production.
Which tools should be used for copying a system?
I have used many, here is a list of my favourite tools:-
- Client export (or client copy). This is my old favourite, works well up to around 200gb providing you have plenty of disk IOPS and enough disk space in /usr/sap/trans. There are several profiles you can use here depending on what you are trying to achieve
- InfoShuttle. Works well for HR and Payroll data. Has a neat scrambling capability and allows selective copies between systems. Works well for low data volumes
- SAP Test Data migration Serer (TDMS). The latest offering from SAP works on ERP, CRM and BI systems. Can do selective copies based on date, company code etc. Has some scrambling capability, but these are optional extras. Works well on systems up to 2tb and long as you have flexible infrastructure (virtualisation capability) and a powerful Solution Manager (or other central) system. We extracted 24 months of Production data from a 6tb system into our DEV system over 3-4 days.
- Tape based homogenous System Copy and Migration. Works well if you have 2 spare Basis days and a target system with as much disk space as Production. Post copy tasks are labour intensive, but can be automated to some extent.
- Disk based system replication. We use FlashCopy SE to peel off a copy of our 8tb Production system in less than 4 hours (including system rename time). The target system is small (less than 100gb) because FlashCopy SE utilises a virtualised pointer based approach to cloning data. This weekend, we are performing the New GL conversion on the most current FlashCopy of Production data – without any disruption to Production at all. Next week, we will re-Flash and use the FlashCopy to test the application of EHP4.
Overkill or minimising risk?
You might call it overkill, but I call it a cost effective approach to controlling the risk of Production changes. My ultimate goal is to deploy FlashCopy SE across the entire Production SAP fleet. This will provide a vehicle to consistently clone all SAP systems in one hit (CRM, ERP, BI, SCM, EP etc). Taking the concept one step further, this process will form the foundation of a consistent recovery point across the entire suite of systems.
Learn more during the ‘meet the expert’ sessions at TechEd 2009 in Phoenix. I have 3 sessions booked where I will explain how Australia Post use FlashCopy SE as an integral part of our virtualisation roadmap. Bring your USB key for a copy of my favourite IBM-SAP Redbooks.