How common is a client copy from PRD to QAS and DEV to refresh the data?

[laurie_mcginley]

We are looking at doing a client copy from our PRD:100 system to 2 of the QAS clients. And then from there doing a copy to our DEV testing client. So 3 system landscape. MSSQL Server on Win 2003 and using ECC5. PRD database is about 70 GB.

I know we have done this only a couple of times over the last couple of years to freshen data in our QAS and TEST systems. We use the SAP_APPX profile.

As the new BASIS admin, I'd like to know is this a common method for updating / refreshing clients. What issues/concerns might I need to address. There will be no pending transports from QAS to PRD, but there are a couple of transports, still modifiable, in the DEV system. These are workbench transports I believe.

I will be shutting down QAS friday evening to get a full off-line backup before the copy. I also plan on switching the database to SIMPLE mode so as not to have transaction logs blowing up during the copy.

I am scheduling a test run using the Resources option tonight. I plan to run the copy fro PRD late Saturday night during non-business hours.

Thanks for your insights and advice.

Laurie McGinley

[laurie_mcginley]

Thank-you all for your suggestions and input. We are progressing well with the refresh now.

Laurie

[Former Member]

My suggestion:

You have n no. of clients in DEV.....

2 clients 100 and 200 in QAS....

1 productive client in PRO i.e. 100....

Then fist export the client 200 (non-productive) from QAS, that will export the client (Have a look at client copy method export and import), then do a system copy from PRO to QAS.

You will get 100 client into your QAS with same data of PRO, then perform a client import(200) which you exported in first.

Finally you will get procutive client 100 with full data of PRO and non-productive client 200.

Regards,

NIck Loy

[Former Member]

If your business is okay with longer downtimes, then you can go for remote client copy or client export and import.

But on going it will become very risk process to refresh the data (day by day the size of DB will increase)

So I suggest you to just check the size of other client (non productive) in your QAS, just export that client.

Then do a QAS refresh....After that you can import the client into QAS.

Regards,

Nick Loy

[laurie_mcginley]

Nick, I don't quite understand the process you have outlined:

+So I suggest you to just check the size of other client (non productive) in your QAS, just export that client.

Then do a QAS refresh....After that you can import the client into QAS.+

What do you mean by export the QAS client?

Is the QAS refresh a system copy from PRD?

Thanks

[Former Member]

Hi Laurie,

I think you have enough info for doing a client copy. You may also define parallel processes so that the CC does not take much time.

Also if you are asking the frequency of the CC, then it depends on the customer how often they want to have the refresh. Usually its better to refresh the clients with production data once in 3 or 6 months so that the developers and testers have enough data to test.

You also need to check the SP level of all the three systems to be same. Also the network between systems should be 100%.

I do not see any other issues for doing a client copy.

Revert if any doubts.

Best Regards

Raghu

[Former Member]

Hello,

Refreshing data/client in DEV or QA systems based on a remote client copy of production data is not my preferred way of working.

To be 100% sure that your client in DEV or QA is consistent (data) you should also lock your production system to prevent someone or a batch job to make changes to the data.

This action is often forgotten.

A client copy just copies table per table, when it takes for example 10 hours no one can make any changes in PRD during this timeframe to obtain a consist client on DEV or QA.

Data in your production environment also grows, this means that your future client copies will take more and more time.

It is very difficult to estimate how long they will take.

My preferred way of refreshing data in DEV or QA is a full system refresh based on a backup of the production system.

Major advantage :

- No impact for users in PRD (no need to lock the system)

- No impact on system resources in PRD

- DEV or QA are always in a consistent state after the restore.

Take a look at the homogeneous system copy guides from SAP on how to do this.

[http://service.sap.com/instguides |http://service.sap.com/instguides ]

-> SAP Components

-> SAP Business Suite Applications -> SAP ERP

-> SAP ERP 6.0

-> Installation

You will find there all system copy copies per type of SAP system.

I hope this is usefull.

Wim

[Former Member]

Hello ,

I go with Wim .And it's the proper way to do the system refresh .

For your more info , you can use backup and restore from PRD to QA or DEV . you can also find it in the Microsoft website .

After restoration of the Database , the schema of DB has to be changed from PRD to QA or DEV . For this the easy way to change the schema by using the SAP tool which is very reliable for doing it , and you can find the info. regarding this tool in the SAP Note :- Note 683447 - SAP Tools for MS SQL Server . Thanks ! A A

[laurie_mcginley]

Thank-you for your quick responses.

Regarding using client copy and activity in PRD, I am planning on running this over night so no users, and that night no batch jobs, so I think it would be ok.

Regarding the homogeneous system copy. I've done this in the past to create a sandbox system. My concern is that in our QAS system there are other clients, TRNG, that I don't want to replace. And our DEV system also has a different set of clients. The homogeneous system copy would replace those with the PRD structure of only the 1 (100) client. I'm also not fully sure how the issues of logical names and CUA would be effected by using a homogeneous system copy. Are there not other structures that may be effected by doing it? So that tweaking the QAS and DEV system will require a fair amount of post copy cleanup? Maybe there is more to the system copy that I'm not aware of that makes it preferred...?

Thanks

Laurie

[Former Member]

Hi,

I have done System refresh by both method and both are ok. It depends on your need.

What I observe Your database size is only 74GB. So, You can go for Client copy (But prefer Client Export & Import). Because your Production server client will get locked if go for Remote/Local client copy.

All methods are tested and OK.

Regards

DK