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
Requires Free Membership to View
When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.
Hannah Smalltree, Editorial Director
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
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
import
Start the import
Safeguarding the Version Database using native database tools (ex: for Oracle)
3. Use Oracle Import for to import the version database after the system refresh:
This was first published in April 2006
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.
file = '...'
R3trans -w <log file> <name of the control file Import>
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
# imp sapr3/sap PARFILE=VERSION.PAR