Copy your SAP ERP system across platforms using DB2 redirected restore

With IBM® DB2® for Linux®, UNIX®, or Windows® Version 8 or later, you can use redirected restore operation to copy an SAP system from one platform to another. This article provides you with the step-by-step instructions on how to do this and describes the resources you need before you start.

Share:

Marianne Nesiem, DB2/SAP Integration Test and Support, IBM

Author photoMarianne Nesiem is a member of the IBM SAP Integration and Support Centre at the IBM Toronto Lab. Her current activities include testing of SAP R/3 with DB2 UDB and helping customers with problem analysis and troubleshooting. She is also a customer advocate, providing custom-tailored support for large customer accounts running SAP and DB2. She is a DB2 Certified Solutions Expert and a UNIX systems administrator, and has experience in application development on Java for databases and other applications.



12 November 2009 (First published 31 July 2003)

Also available in Portuguese

Important: Read the disclaimer before reading this article.

Introduction

This article provides a step-by-step guide you can use to perform a cross-platform heterogeneous system copy of an existing SAP system across different platforms using a redirected restore operation. This functionality is available in DB2 Version 8 or later. The article describes issues and concerns that may arise during the migration as well as important information you need to know to successfully complete the operation.

You may need to use a Heterogeneous System Copy to change operating system platforms or to duplicate a system. SAP recommends having such a copy when you need to build a test or training environment.

While using the instructions in this article, you must also use the appropriate SAP Installation manuals and SAP Homogeneous and Heterogeneous System Copy guides.


Overview

A System Copy between two systems running on the same operating system is called a Homogeneous System Copy and can be performed using the R3load tool or by using the DB2 redirected restore procedure.

A System Copy between two systems running on different operating systems or different DBMS systems is called a Heterogeneous System Copy. Prior to DB2 Version 8, you could only perform a Heterogeneous System Copy using the R3load tool provided by SAP.

With DB2 Version 8 and higher, you can use redirected restore to create a Heterogeneous System Copy between two systems running on different platforms as long as the endianness (big-endian or little-endian) of each system is the same. Except for the limitations described below, you can take a backup from any big-endian server and restore it to any other big-endian server. For example, you can restore a backup image from DB2 for HP-UX to DB2 for AIX® or Sun Solaris. With Windows® you are still limited to the same platform but you can move from 32bit to IA or AMD 64 bit.

Note: Endianness refers to the whether the most significant or least significant byte has the lowest address. Big-endian means that the most significant byte has the lowest address (the word is stored big-end-first). Most RISC processors are big-endian. Little-endian means that the least significant byte has the lowest address (the word is stored little-end-first). Intel microprocessors are little-endian.

Here are the limitations regarding copying of systems:

  • That is, you can restore a backup image from a lower DB2 version into a higher version, but not the opposite. For example, you can restore a V8 or V9 backup taken on a plinux system into a 9.5 system running on AIX. Note that this option is only possible with offline backups and no rollforward is possible.
  • You can restore a backup image taken on a 32 bit level system into a 64 bit level, but not the opposite.
  • You can restore a backup image taken from a non-automatic storage database into an automatic storage database system, but not the opposite.
Figure 1. Possible Heterogeneous System Copy combinations
Systems can be copied big-endian to big-endian, little-endian to little-ednian, or Windows 32-bit to Windows 64-bit.

if your systems are not included in the supported combinations, then you must perform a system copy using the R3load method.

The following sections explain the process of copying an SAP R/3 system from one platform (the source system) to another system (the target system) using redirected restore, as depicted in Figure 2.

Figure 2. Using DB2 redirected restore to copy your SAP system
A sample restore from a SAP R/3 source system on Solaris to DB2 backup, then to an SAP R/3 target system on AIX.

Use the procedure for a cross-platform Heterogeneous System Copy documented here as a reference along with the SAP installation manuals specific to your platform and to the SAP release you are currently running, as well as the appropriate IBM online documentation. In addition, you should review the following OSS notes:

  • OSS Note # 316353: lNST: 4.6D SAP Basis - Heterogeneous System Copy
  • OSS Note # 516246: INST: System Copy for SAP Systems based on SAP Web AS 6.20
  • OSS Note # 677447: INST: System Copy for SAP Systems based on SAP Web AS 6.30
  • OSS Note # 870863: Hom./Het.System Copy SAP NetWeaver 2004s
  • OSS Note # 1120872: Hom./Het.System Copy SAP NetWeaver 7.0 SR3
  • OSS Note # 73717: DB6: Tools for a System Copy
  • OSS Note # 122222: DB2 UDB: Redirected Restore via DB2 CLP
  • OSS Note # 628156: DB6: Cross-Platform System Copy using Backup/Restore
  • OSS Note # 1323791: DB6: Tips for the homogeneous system copy
  • OSS Note # 1125951: DB6:NW7.0 SR3/SAP Business Suite 2005 SR3 - UNIX
  • OSS Note # 1323791: DB6: Tips for the homogeneous system copy

Preparing to make the System Copy

Before starting the System Copy, you need to be aware of the following:

  • To make a System Copy, both systems must have the identical version of SAP and both systems must be on DB2 Version 8 or higher.
  • The source system must be in a consistent state before you make the copy. All release jobs should be set. No canceled or pending update requests should be in the system.
  • Create the logical volumes and file systems on the target DB2 system to match the sizes of the source database file systems. Note that the file system sizes you use may be different from those recommended in the SAP installation documentation, depending on the data volume of the source system. Refer to R/3 Installation on UNIX: IBM DB2 Universal Database for UNIX and Windows for more information.
  • You must contact SAP to obtain their requirements for the migration (for example, obtain the migration package or migration key, and have a certified consultant on site). For more information, please review OSS Note # 628156.
  • To run a System Copy on R/3 Enterprise 470, you must use the same SID for both the source and target systems. For higher SAP releases, you can change the SID, but you cannot change the connect user, the schema name, or the tablespace names. However, you can change the tablespace names after the installation using the command:
    db2 rename tablespace <OLD_NAME> to <NEW_NAME>
    Please review the SAP System Copy Guide for the SAP release you are using.

Step-by-step instructions

Release 4.7 or earlier

  1. Take a full DB2 backup of the source system. The backup can be online or offline. To obtain an offline backup, do the following:
    1. Shut down the SAP system.
    2. Check that no applications are connected to the database. Do this by entering the command:
      db2 list applications
      This command must return with:
      No data was returned by the database system monitor.
    3. Stop the DB2 instance by entering the command:
      db2stop
    4. Run the backup:
      db2 backup db <SID> to <backup directory>

      You should include the logs in the backup. This happens by default as of DB2 Version 8.2 and 9.5. Refer to the documentation for the backup database command in the information center for your version of DB2 (see the Resources section for a link).

  2. If your target SAP system is 4.6x or earlier, follow these steps:
    1. Follow the installation instructions in the SAP R/3 Homogeneous System Copy document provided by SAP. (Instead of CENTRDB.R3S or DATABASE.R3S, use the templates CEDBR3CP.R3S for a central and database server, or DBR3CP.R3S for a database server.)

      For example:
      ./R3SETUP -f CEDBR3CP.R3S

      The installation assistant will ask questions that you must answer according to your system's configuration. For guidelines on how to answer these questions, see R/3 Installation on UNIX: IBM DB2 Universal Database for UNIX and Windows.

    2. When R3SETUP stops at step EXITR3COPY_IND_DB6, run the redirected restore using one of the methods specified in the following section.
    3. Complete the installation as described in the SAP installation guide.
  3. If your target SAP system is 4.70, follow these steps:
    1. Install the central instance as described in SAP R/3 Enterprise 4.70 Installation on UNIX: DB2 Universal Database for UNIX and Windows.

      Important: Your target system must have the same SID as the source system.

    2. Before installing the database instance, follow the instructions in OSS Note 564720 to modify the control.xml file.
    3. Run the installation for the database instance by answering the questions as described in the guide until it stops before creating the database.
    4. Run the redirected restore using one of the methods specified in the following section.
    5. Complete the installation as described in the SAP installation guide.
  4. After the installation is complete, perform the following steps:
    1. Report loads in an SAP system are OS-dependent; you must delete these loads to complete the System Copy. The system will automatically re-create them at first access. To delete the report loads, enter the following commands from the operating system using the DB2 command line processor (CLP):
      • For 4.6x or earlier:
        db2 "delete from sapr3.d010l" 
        db2 "delete from sapr3.d010q"         
        db2 "delete from sapr3.d010y"         
        db2 "delete from sapr3.d010linf"
      • For 4.70:
        db2 "import from /dev/null of del replace into <schema_name>.repoload"
    2. The DB2 event monitors keep information on owners and permissions, which are kept in the database system catalog. To avoid having the event monitors connect to the owner of the source system (rendering them unusable in the target system), drop and recreate them with the instance owner of the target system (follow the instructions in OSS note 95282).

Releases based on NetWeaver 7.0(2004s) or higher

On the Source System:

  1. Take a full db2 offline or online backup of the source system as explained above. You should include the logs in the backup image, which is the default behavior as of DB2 Version 8.2 and 9.5. You need the logs because a rollforward is required following the restore on the target system.
  2. Optionally, you can create the export directory structure with labels, and you can archive SDM and application specific file system content. You can use SAPinst to perform this task. From the SAP Installation Master welcome screen, select:

    <System Release> --> Software Life-Cycle Options --> System Copy --> IBM DB2 for Linux, Unix, and Windows --> Source System Export --> <System Variant> --> <Technical Stack> --> Export Preparation

    By providing an export location, all the labels and directory structures will be created in that location and these files can be used in the target system.

    Screenshot of SAP Installation Master welcome screen showing selection path described above.
  3. In a Java® or a double stack system (ABAP+Java), you need to run a separate export for the Java engine to archive SDM and application specific contents. For more information about this step and the previous step, please review the SAP system copy guide for your release.

On the Target System:

  1. Run SAPinst and from the SAP Installation Master welcome screen, select:

    <System Release> --> Software Life-Cycle Options --> System Copy --> IBM DB2 for Linux, Unix, and Windows --> Target System Installation --> <System Variant> --> <Technical Stack>

    Screenshot of SAP Installation Master welcome screen showing selection path described above.
  2. Follow the normal installation procedure. When asked for a SID, either select the same SID as the source system, or a new SID.
  3. On the database specific screen, select Homogeneous System Copy (Database copy method)Screenshot of SAP Define Parameters step of SAP System > Database with selection described above made.
  4. Continue with the installation procedure. Enter the database ID, the database ports, and the connect user. Remember that the connect user must be identical to the source system, even if the SID is different.
  5. If you are installing a double stack system, you will be asked to enter the location of the Java export, as well as the username and password of the Java administrator. The information you enter must match the source system, but you can change it after the system copy. Screenshot of SAP Define Parameters step of Media Browser > Software Package Request showing Package Location selection.
  6. After you enter all the required parameters, the install continues up to the step where the restore is required. Screenshot of SAP Execute Service step of Task Progress showing Exit to restore database phase as in process.
  7. When the restore is required, you will see a Message Box pop-up as shown in the figure below. Select Cancel to abort the installation and run the database restore. Alternatively, you can leave the Message Box pop-up open, complete the restore from a separate window, and select OK when the restore is complete. Screenshot of Message Box pop-up where you can click Cancel or OK as described in this step
  8. If you made the selection in the previous step to abort the installation, you see another Message Box. Select Stop to confirm that you want to stop the installation and exit SAPinst. Screenshot of Message Box pop-up where you select Stop to confirm that you want to stop the installation
  9. Run the redirected restore using one of the methods specified in the following section.
  10. Restart SAPinst and continue the installation as described in the SAP installation guide for your release.
  11. if you changed the SID, you need to enter the following command to update the LOGARCHMETH1 database configuration parameter to point to the new SID:
db2 update database configuration for <NEW_SID> using LOGARCHMETH1 /db2/<NEW_SID>/log_archive

Redirected Restore methods

There are three different methods you can use to restore the database:

  • Generate a script using the SAP brdb6brt tool.

    From the source system, invoke the tool by issuing the following command:

    brdb6brt -s <SID> -bm RETRIEVE -user <instance_owner> -using <password>

    For example:

    brdb6brt -s LR1 -bm RETRIEVE -user db2lr1 -using PASS123

    The tool generates a script in the form SID_NODE000X.src. The tool also creates a file named SID_NODE000X.brp that includes a log of the steps performed. You can use this file to trace errors if they occur.

    Modify the generated script to fit the specifications of the target system. You can change the SID, storage paths, location of the log directory, etc. (note that if you are using automatic storage, there is no need to set container paths). After making your modifications, run the script from the CLP using the command:

    db2 -tvf <SID>_NODE0000.scr

    The Download section at the end of this article contains a link to a sample redirected restore script.

    You can also use the brdb6brt tool to create a backup and generate the restore script in one step. For more information on the script or on the brdb6brt tool, refer to the SAP DB6 Database Administration Guide.

  • Generate a script using DB2's redirected restore.

    You can invoke the restore utility through the DB2 command line processor (CLP) or the db2Restore application programming interface (API). To run it from the CLP, issue the following command on the target system:

     db2 restore db <SID> from <location> taken at 
    <timestamp> redirect generate script <script>.clp

    For example:

     db2 restore db LR1 from /backup/LR1 taken 
        at 20090804090733 redirect generate script LR1restore.clp

    Modify the generated script to fit the specifications of the target system. You can change the SID, storage paths, location of the log directory, etc. (note that if you are using automatic storage, there is no need to set container paths). After making your modifications, run the script from the CLP using the command:

     db2 -tvf LR1restore.clp
  • Alternatively, you can use the CLP to manually issue the redirected restore command and set the container paths (note that if you are using automatic storage, there is no need to set the container paths).

    For example:

    db2 restore database LR1 from /mnt/LR1backup taken at 20090914135805 redirect
    db2 restore database LR1 continue

Perform a rollforward

Upon completion of the restore, you must perform a rollforward on the database.

For example:

db2 rollforward db LR1 to end of logs

If there are no logs available or if there is no need to rollforward, you can issue the command with the stop option.

For example:

db2 rollforward db LR1 stop

Alternatively, you can add the rollforward command to the generated redirected restore script described previously.


Convert your system to automatic storage using DB2 9.7 Redirected Restore

Automatic storage is a feature that allows DB2 to control database growth without having to preset any specific sizes for the database or the tablespace containers. This results in less user interference and fewer interruptions due to space constraints during normal workload.

With releases of DB2 prior to 9.7 you could only enable automatic storage during database creation (this is the default behavior starting with DB2 Version 9.1). With DB2 9.7 you can also convert your database and tablespaces to use automatic storage after database creation.

You can use the system copy method to convert your database to automatic storage on the same system, or you can combine a system copy with a conversion to auto storage in one step by doing the following:

On the Source System:

  1. Issue the following command to enable automatic storage at the database level:
    db2 ALTER DATABASE <dbname> ADD STORAGE ON <path1> [<path2>,...,<pathn>]

    For example:

    db2 ALTER DATABASE LR1 ADD STORAGE ON ’/db2/LR1/sapdata1’,’/db2/LR1/sapdata2’,
             ’/db2/LR1/sapdata3’, ’/db2/LR1/sapdata4’
  2. Backup the database using the backup command as explained previously.

On the Target System:

  1. Enable automatic storage at the tablespace level during the restore by updating the redirected restore script or by running the restore at the command line as explained previously. Set the containers to use auto storage as follows:
    db2 set tablespace containers for <tablespace_id1> using automatic storage;
    db2 set tablespace containers for <tablespace_id2> using automatic storage;
    ...

    Note that the tablespace ID can be retrieved from the tablespace snapshot. It is also included in the generated redirected restore script.

    For example:

    db2 get snapshot for tablespaces on <db_name> |grep ”Tablespace ID”
  2. After the database has been fully converted to automatic storage, you should make a backup of it.

Conclusion

By providing step-by-step instructions and recommendations, this article helps you with your task of performing Heterogeneous system copies using the redirected restore method available in DB2.


Disclaimer

This article contains sample code. IBM grants you ("Licensee") a non-exclusive, royalty free, license to use this sample code. However, the sample code is provided as-is and without any warranties, whether EXPRESS OR IMPLIED, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. IBM AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE THAT RESULT FROM YOUR USE OF THE SOFTWARE. IN NO EVENT WILL IBM OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF IBM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.


Download

DescriptionNameSize
Code samplebrdb6brt.out40 KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=445965
ArticleTitle=Copy your SAP ERP system across platforms using DB2 redirected restore
publish-date=11122009