Refresh a Development system from a Production system

[Former Member]

Hi

Our developers want to refresh the Dev system by doing a copy back of the Live system. We have done this for the QA system before (database restore, change SID, post steps etc) but never for the DEV system.

I have seen thread which talks about preserving the versions history (as per SAP note 130906); are there any other additional steps that need to be taken / any documentation for doing this? The R/3 system copy documentation only says: "If you have made modifications in your development system, do not copy your quality

assurance or production system onto the development system. Otherwise, all versions of

the modifications will be lost." I can't find any useful information about copying back to DEV.

Thanks

Ross

[Former Member · Accepted solution]

We have a system called Clone & Test which we use for copying data between systems.

This "scambles" sensitive Payroll and Personnel data, for Audit reasons!

[Former Member]

I know Ross has moved on to greener pastures but in case anyone comes across this thread. A possible way to remove the data is by client copy if you don't want ANY master or transaction data from PRD. Say your development client is client 100. Do a SAP_CUST client copy to a new client 200. You could make 200 your new development client and delete client 100 or do a SAP_CUST copy back to 100 and it will delete all the master & transaction data in 100, then delete 200. Then of course DB reorg's to shrink the actual database.

[Former Member]

Hi all.

We have refreshed PRD into DEV due to degradation of this environment and due to simplification of Unicode Conversion of our landscape.

We know that this might not be the optimus procedure, but once we've done it, we are now facing the task of reducing the large amount of data in DEV.

We have been told to archive the data through standard archive procedures, but we would like to speed up this process (particularly slow in our landscape). We are thinking on truncating the big tables of the system (probably saving some data, for 2007 for example) then performing export/import reduce the database size.

Anyone has faced and succesfully acomplished this task? Is it complex? Risky?

Any help would be greatly apreciated.

Antonio Romero

BAMESA

[Former Member]

Closing as reached max open questions allowed... sorry, never got a full answer and since left the company

[Former Member]

Ross

We had same requirement couple of years ago, refresh dev with a production system. We used note 130906 and preserved version history before copy. If I remember correctly we were able to retrieve and activate old versions besides just version history.. I don't have full details as it was done too long ago.

Before taking chances, I would create new Dev instance and export version history. Then refresh new dev instance with prod and import version history for testing.

Warm Regards

Raghu G

[Former Member]

Many thanks for everyone's reply... think I will need to put this information to the business and see what they think of the risks etc.

Cheers

Ross

[Former Member]

Hi Ross,

Although it is possible to copy back onto the DEV system, I would be weary about doing it, especially if requested by developers. SAP does not recommend the idea of refreshing development system. But customers have done it when they decided that the DEV system is hopelessly <expletive>.

Copying PRD is a common way of achieving the goal of refreshing DEV, the drawback of this is the fact that PRD has data. The hardware platform that DEV resides may not have enough capacity to contain the data, let alone to make several clients by copying the PRD client to make a real DEV system. At the same time, you will lose the version information of your repository objects.

Keeping the old DEV around will allow people to log on to do version research. This may not be as costy as people think, because DEV is normally small and should not use much system resources since there will not be many users on it at all (if there are any), you can actually let the OLD DEV on the same server co-exist with the new DEV or anywhere you will have spare resources to do it.

An alternative way of refreshing DEV is to copy your PRD client to DEV. This can be done by performing a client export from your production client (with client dependent and independent configuration), and import it into the DEV clients. Unless you decide that client independent configuration need not to be copied, remote copy methods should not be used because it will not copy client-independent configuration. Since neither client export/import nor remote-client copy touches repository objects, the version information will be preserved.

In reality, though, one should examine why there is need to refresh a DEV system in the first place. In my experience, it is usually because the DEV system is out of synch with the rest of the landscape. The most common reason for this is that changes were made directly in QAS and/or PRD systems. Unless this problem is cleaned up with stricter procedures -- i.e. never do it -- then you will be in the same hole again in short order.

Best Regards,

Matt

[zobair]

Dear Friends,

We would like to refresh our DEV system from PRD system.

In fact, our DEV system becomes a Sandbox (a lot of transport requests are not released, local objects are created and system is unstable...)

Recently, developers started developing directly in PROD system !!!

DEV, QAS & PRD systems are not aligned anymore.

My question, do we still have to follow instructions describes in note 130906? I mean "Export/Import the version database"? Is there any sense?

My second question is related to this sentence:

The version history of changed SAP objects in particular, and customer objects is important for future SAP upgrades.

What is the impact on an Upgrade? (we are going to upgrade our landscape)

Is there an impact only on the standard objects or also on Z-objects? Latest object version is not enough?

Many thanks for your help.

Regards,

Zobair