Introduction
Developers and customizing consultants often need representative transaction data -- both in terms of quantity and quality -- in their development system. This is especially true in two-system SAP landscapes (SAP landscape with only a development and production system, no quality assurance). In almost every SAP environment, after several months or years, the discrepancy between the data in the development and production system becomes problematic, as it makes ongoing development and customising difficult or nearly impossible.
Two procedures exist to refresh transaction data in the development system: client copy or client transport and a database copy. Both of them have serious drawbacks:
-- Client copy using remote function calls or client transport.
Although this might be feasible in small environments, it has many disadvantages:
* It can cause inconsistencies between client-dependent and client-independent data (or overwrites the client-independent data of the development system if client-independent customising was included).
* Both the source and target clients are unavailable during the client copy. The source client is unavailable during the client export if client transport is used.
* The process is too slow for copying large production clients.
-- A database refresh in which the development system is completely overwritten with a backup of the productive system:
* SAP strongly recommends always retaining the development system, as it contains the version history of all repository objects. The version history of changed SAP objects in particular, and customer objects is important for future SAP upgrades. This document describes a workaround in which the complete version database of the development system can be exported and imported again after the system copy.
Prerequisites and restrictions
Prior to the refresh, all change requests that exist in the development system must be imported into the production system, or they must be deleted. The reason is that the version management refers to a change request number. If you restore version tables containing references to change requests that no longer exist, problems may occur.
The version data of the source system is completely lost. If there were differences between the two systems (e.g. repairs to SAP objects) then all record of these will disappear. Furthermore the source (e.g. production) system should not contain any repairs that were not also applied in the development system.
To avoid conflicts the source and target system should be at the same support package level.
As an extra precaution, it might be wise to export the version tables of the source system before the import of the version data from the old development system.
After the refresh, check, and if necessary, change the transport number range in E070L.
You can only transport ALL versions. All versions existing in the import system are deleted!
Procedure
The export and import of the Version Database can be carried out using R3trans or database tools.
Safeguarding the Version Database using R3trans
1. Create a control file for R3trans with the following contents:
export
file = '<FILENAME>'
<FILENAME> is the name of the file into which the export should be carried out
delete from vrsd
select * from vrsd
delete from vrsx
select * from vrsx
delete from vrsx2
select * from vrsx2
# Release 4.5A and above
delete from vrsmodisrc
select * from vrsmodisrc
# Release 4.6A and above
delete from vrsx3
select * from vrsx3
# Release 6.40 and above
delete from vrsx4
select * from vrsx4
NOTE: The delete statements have no effect on the system. These commands are specific to R3trans.
2. Use R3trans to export the version database :
R3trans -w
3. After the system copy, use R3trans to import the version database:
Modify the control file created earlier. Change the export statement into import. The remaining contents of the control file remains the same.
import
file = '...'
Start the import
R3trans -w <log file> <name of the control file Import>
Safeguarding the Version Database using native database tools (ex: for Oracle)
Safeguarding and restore the Version Database is probably much easier and faster with native database tools. This is an example with the standard Oracle export and import tools (exp and imp)
1. Create a parameter file with the following contents : (for example VERSION.PAR)
INDEXES=Y
COMPRESS=Y
GRANTS=Y
ROWS=Y
CONSTRAINTS=Y
TABLES=(vrsd,vrsx,vrsx2,vrsx3,vrsx4,vrsmodisrc)
2. Use Oracle Export for to export the version database:
# exp sapr3/sap PARFILE=VERSION.PAR
3. Use Oracle Import for to import the version database after the system refresh:
# imp sapr3/sap PARFILE=VERSION.PAR
