Problem solve Get help with specific problems with your technologies, process and projects.

Safeguarding the version database during a refresh of the development system

Learn how to retain the version database after a system copy in this detailed step-by-step guide from administration guru Bert Vanstechelman.

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 = '&ltFILENAME>'

    &ltFILENAME> 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 &ltlog file> &ltname 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
 

This was last published in April 2006

Dig Deeper on SAP workflow development

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close