Best Practices for Migrating SAP Systems to Oracle Infrastructure--Part 5: SAP Database Migration Method 3--Oracle RMAN Cross-Platform BACKUP and RESTORE

Version 2

    by Jan Brosowski, Andris Perkons, and Pierre Reynes (with contributions from Victor Galis and Hans-Jürgen Deneke)

     

    This article, Part 5 of the series, provides a practical guide to migrating Oracle Database instances as a part of an SAP migration using Oracle Recovery Manager (Oracle RMAN) cross-platform BACKUP and RESTORE. This method performs an offline Oracle Database migration from any platform to Oracle SuperCluster storage servers or to an Oracle Automatic Storage Management (Oracle ASM) destination.

     

    Introduction

     

    This article is Part 5 of a six-part series that provides best practices and recommendations for migrating a complete SAP system to an Oracle platform (in this example, to Oracle SuperCluster M7). A team of Oracle engineers and SAP experts worked together to test and tune different migration methods, compiling the step-by-step procedures and guidance given in these articles.

     

    The articles in this "Best Practices for Migrating SAP Systems to Oracle Infrastructure" series are located here:

    OOS_Logo_small125.png
    in collaboration with
    OSC_Logo_small125.png
    Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

     

     

    Understanding Cross-Platform BACKUP and RESTORE

     

    Oracle Recovery Manager (Oracle RMAN) provides a comprehensive foundation for efficiently backing up and recovering Oracle Database instances, including databases within SAP environments. SAP supports the usage of Oracle RMAN within the restrictions published in SAP Note 105047 (access to SAP Notes requires logon and authentication to the SAP Marketplace).

     

    In general, Oracle RMAN can be used for backup, restore, and recovery, but the Oracle RMAN features for cross-platform backup and restore operations can be used only in conjunction with the Oracle Database 12c (or newer) release. This limitation is the biggest restriction for the cross-platform backup/restore migration method for SAP environments. For migrating databases created with previous Oracle Database releases, one of the two other methods (documented in other articles in this series) must be used instead.

     

    The newly introduced Oracle RMAN options BACKUP FOR TRANSPORT and BACKUP TO PLATFORM offer a wide variety of methods that can be used to transport SAP databases to new platforms. This article focuses on migrating a complete database to a new platform. Additional methods that migrate specific tablespaces are not covered, because they are very similar to using transportable tablespaces. How to use these methods to migrate tablespaces is easily derived from the article "Part 4: SAP Database Migration Method 2—Transportable Tablespaces."

     

    Both the BACKUP FOR TRANSPORT and BACKUP TO PLATFORM options accomplish the same task, but they differ in one important aspect:

     

    • BACKUP FOR TRANSPORT generates a generic set of files that can be restored on any platform. If a conversion to the endian format of the destination platform is necessary, it is performed on the destination side. Note that the endian format conversion is available only for backups of SAP-specific tablespaces and not for whole databases.
    • BACKUP TO PLATFORM generates a set of files that can be properly restored only on the specified destination platform. This is because endian format conversions are performed on the source side.

     

    The examples in this article use the first alternative, BACKUP FOR TRANSPORT. In most migration scenarios, the destination is a more powerful environment. Typically, it can better handle the processing overhead of an endian format conversion when it is offloaded to the destination side.

     

    There are two ways of using Oracle RMAN cross-platform BACKUP and RESTORE for SAP migrations. Depending on the endianness of the platforms, you can choose to migrate the complete database (if both platforms have the same endianness) or migrate the SAP-specific tablespaces only.

     

    The overall process of using a cross-platform BACKUP for migration is quite simple and consists of three steps:

     

    • Step 1: Creating a full database backup using Oracle RMAN on the source system
    • Step 2: Transporting the backup files to the destination system
    • Step 3: Restoring the database backup files on the destination system

     

    These are the same steps as for backing up any non-SAP database for transport, because the entire database, including all tablespaces, is moved. There is no need to make sure that all transported objects are completely contained within the set of tablespaces being transported, as there is with a transportable tablespaces (TTS) migration.

     

    Before this article describes the three migration steps in detail, consider the factors that influence how long a system migration takes as well as the downtime required. There are several factors that influence the duration of the backup and restore processes:

     

    • The number of database files and their size. Because the entire database is exported, its size and the number of database files influence the length of the Oracle RMAN BACKUP process. Reducing the database size by reorganizing it before the actual migration can potentially speed up the process.
    • The performance of the source and destination file systems. Because the data files must be copied entirely to backup files, both the read performance of the file systems containing the source data files, as well as the write performance of the file systems containing the created backup files, is relevant. In addition, during the restore operation on the destination side, the read performance of the backup file location is relevant, as well as the write performance of the database file system.
    • The bandwidth and method used to copy data files from the source to the destination. If the backup files need to be copied over to the destination, their size will impact the copy time needed. If the destination can access the backup files via the network (for example, via an NFS mount), additional time for the copy is not required.
    • CPU speed. Oracle RMAN always includes mechanisms to protect data integrity during copy processes, and it also supports options to encrypt or compress backup sets. The speed of these operations is highly dependent on CPU performance.

     

    Cross-Platform Backup/Restore Migrations: Same Endian Format

     

    Backing up and restoring an entire database is a fast and efficient way to migrate the database, but it comes with the restriction that source and destination platforms must share the same endian format (either big endian or little endian). Listing 1 shows how to display the endianness of various platforms.

     

    SQL> select platform_name, endian_format from V$TRANSPORTABLE_PLATFORM

     

    PLATFORM_NAME                            ENDIAN_FORMAT

    ---------------------------------------- ---------------

    Solaris[tm] OE (32-bit)                  Big

    Solaris[tm] OE (64-bit)                  Big

    Microsoft Windows IA (32-bit)            Little

    Linux IA (32-bit)                        Little

    AIX-Based Systems (64-bit)              Big

    HP-UX (64-bit)                          Big

    HP Tru64 UNIX                            Little

    HP-UX IA (64-bit)                        Big

    Linux IA (64-bit)                        Little

    HP Open VMS                              Little

    Microsoft Windows IA (64-bit)            Little

    IBM zSeries Based Linux                  Big

    Linux x86 64-bit                        Little

    Apple Mac OS                            Big

    Microsoft Windows x86 64-bit            Little

    Solaris Operating System (x86)          Little

    IBM Power Based Linux                    Big

    HP IA Open VMS                          Little

    Listing 1: Listing platform endianness.

     

    This article gives an example of moving from an AIX system to Oracle SuperCluster, which both use big-endian format, so a complete database Oracle RMAN BACKUP and RESTORE is possible.

     

    Step 1. Creating a full backup using Oracle RMAN on the source platform.

     

    The first step is to generate a complete backup of the source database using Oracle RMAN. This requires downtime of the SAP system, because the Oracle RMAN option BACKUP FOR TRANSPORT (and BACKUP TO PLATFORM) requires the database to be in read-only mode. Shut down the SAP application (not shown in Listing 2) and the database, and then re-open the database in read-only mode, as shown in Listing 2.

     

    SQL> SHUTDOWN IMMEDIATE;

    SQL> STARTUP MOUNT;

    SQL> ALTER DATABASE OPEN READ ONLY;

    Listing 2: Opening the database in read-only mode.

     

    After putting the database in read-only mode, start the Oracle RMAN backup process using BACKUP FOR TRANSPORT, as shown in Listing 3:

     

    RMAN> BACKUP FOR TRANSPORT

            AS COMPRESSED BACKUPSET

            FORMAT '/nfs_share/CROSS/ALL/sap_DB_COMPRESSED_%U.bck'

            DATABASE;

    Listing 3: Initiating the backup process.

     

    In this example, the backup set is created on an NFS share that is accessible from both the source and destination systems. Make sure to set the correct mount options for file systems used by Oracle RMAN. For more details, refer to section "NFS Mounts for Oracle RMAN" in Oracle Support Document 1567137.1. (Access to Oracle Support Documents requires logon and authentication to My Oracle Support.)

     

    The Oracle RMAN backup process starts a compressed backup that requires a license for the Oracle Advanced Compression option. To perform an uncompressed backup, remove the line AS COMPRESSED BACKUPSET from the command shown in Listing 3, using the level of parallelism specified in Oracle RMAN's configuration. For each channel, Oracle RMAN will create a separate file. To make these files unique, the placeholder %U in the filename will be replaced by a unique string.

     

    Use the following command to check the level of parallelism specified in Oracle RMAN's configuration:

     

    RMAN> show all;

    using target database control file instead of recovery catalog

    RMAN configuration parameters for database with db_unique_name PR1 are:

    ...

    CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;

    ...

    Listing 4: Checking the parallelism level in the Oracle RMAN configuration.

     

    Additional optimizations can be applied at different levels to speed up the export process, for example:

     

    • Compression: Using compression, as shown in Listing 3, will increase the CPU load, while reducing the amount of write IOPS and the size of the files created. During our tests, IOPS were the limiting factor rather than CPU utilization. In fact, the time savings for IOPS were significantly higher than the needed CPU time for compression, even on five-year old CPUs. Therefore, using compression is recommended whenever possible.
    • Parallelism: The level of parallelism must be adjusted before starting the backup process. A reasonable level of parallelism can be determined by looking at the number of (physical) disks in the environment, because each channel can fully saturate a single disk. Keep in mind that solid-state disks (SSDs) provide a higher number of physical IOPS and support increasing parallelism further. In deployments with SSDs, you should consider the number of CPU cores for the source system, because each channel needs CPU capacity. A reasonable approximation is about one to two channels per core.
    • Encryption: If the backup is to be transferred to the destination system over an untrusted or public connection, encrypting the backup (using Oracle RMAN encryption) is recommended.

     

    After Oracle RMAN has completed the backup process, the files must be made available or transferred to the destination system.

     

    If the migration is creating a system clone, the source system can now be set online again by opening the database in read/write mode and by restarting the SAP application (not shown in Listing 5).

     

    SQL> ALTER DATABASE OPEN READ WRITE;

    Database altered.

    Listing 5: Opening the database in read-write mode.

     

    Step 2. Transporting the backup files to the destination platform.

     

    From an Oracle RMAN perspective, the method used to transport the backup files to the destination does not matter, as long as all the backup files generated in the first step are available from the destination system.

     

    As mentioned previously, during the testing, an NFS share was used that was accessible from both the source and destination systems. In such a case, the share must be set with the correct mount options for Oracle RMAN file systems. For more details, see "NFS Mounts for RMAN" in Oracle Support Document 1567137.1. (Access to Oracle Support Documents requires logon and authentication to My Oracle Support.)

     

    Step 3. Restoring the database on the destination platform.

     

    Before restoring the database, an empty database must first be created as the restore destination. Perform the steps in the article "Part 2: SAP Environment Migration—Pre-Database-Migration Tasks" of this series to create the database destination. Once the empty database is created, enter the Oracle RMAN RESTORE command:

     

    RMAN> RESTORE

          FROM PLATFORM 'AIX-Based Systems (64-bit)'

          FOREIGN DATABASE TO NEW

          FROM BACKUPSET '/nfs_share/CROSS/ALL/sap_DB_COMPRESSED_7hre3v4g_1_1.bck',

          '/nfs_share/CROSS/ALL/sap_DB_COMPRESSED_7ire3v4g_1_1.bck',

          '/nfs_share/CROSS/ALL/sap_DB_COMPRESSED_7jre3v4g_1_1.bck',

          '/nfs_share/CROSS/ALL/sap_DB_COMPRESSED_7kre3v4g_1_1.bck';

    Listing 6: Restoring the database on the destination.

     

    Once the restore process is completed, the source and destination databases contain identical content.

     

    The Oracle Database migration is now complete and the destination database instance is now usable. There are, however, a few additional tasks necessary to finalize the migration of the SAP system. Part 6 of this series, "SAP Environment Migration—Post-Database-Migration Tasks," describes these requirements.

     

    Cross-Platform Backup/Restore Migrations: Different Endian Format

     

    As mentioned previously, if the migration is performed between platforms that have different endian formats, a complete Oracle RMAN backup/restore is not possible. It is, however, possible to back up and restore the relevant tablespaces.

     

    The method described below is very similar to the TTS method. Before using it, it is strongly recommended that you read the article "Part 4: SAP Database Migration Method 2—Transportable Tablespaces" to gain background and a better understanding of the steps that follow.

     

    Step 1. Set the relevant tablespaces on the source platform to read-only mode.

     

    Identify the relevant tablespaces on the source system and set them to read-only mode, as shown in Listing 7.

     

    SQL> select tablespace_name, status from dba_tablespaces;

     

    TABLESPACE_NAME                STATUS

    ------------------------------ ---------

    SYSTEM                        ONLINE

    SYSAUX                        ONLINE

    PSAPUNDO001                    ONLINE

    PSAPTEMP                      ONLINE

    PSAPSR3                        ONLINE

    PSAPSR3740                    ONLINE

    PSAPSR3USR                    ONLINE

    PSAPUNDO002                    ONLINE

     

    8 rows selected.

    SQL> alter tablespace PSAPSR3 read only;

     

    Tablespace altered.

     

    SQL> alter tablespace PSAPSR3740 read only;

     

    Tablespace altered.

     

    SQL> alter tablespace PSAPSR3USR read only;

     

    Tablespace altered.

     

    SQL> select tablespace_name, status from dba_tablespaces;

     

    TABLESPACE_NAME                STATUS

    ------------------------------ ---------

    SYSTEM                        ONLINE

    SYSAUX                        ONLINE

    PSAPUNDO001                    ONLINE

    PSAPTEMP                      ONLINE

    PSAPSR3                        READ ONLY

    PSAPSR3740                    READ ONLY

    PSAPSR3USR                    READ ONLY

    PSAPUNDO002                    ONLINE

     

    8 rows selected.

    Listing 7: Setting the relevant tablespaces to read-only mode.

     

    Step 2. Export the tablespace-related metadata and table data using Oracle RMAN BACKUP FOR TRANSPORT.

     

    Oracle RMAN is used to export the tablespace-related metadata and table data:

     

    RMAN> BACKUP FOR TRANSPORT

            TABLESPACE PSAPSR3,PSAPSR3740,PSAPSR3USR

            FORMAT '/nfs_share/CROSS/sap_tablespaces_%U.bck'

            DATAPUMP FORMAT '/nfs_share/CROSS/sap_tablespaces.dmp';

    Listing 8: Exporting the relevant metadata and table data.

     

    The Oracle RMAN command in Listing 8 first validates that the provided tablespaces are self-contained. It then exports the relevant metadata to the specified dump file and creates a backup of the relevant data files. Note that the same optimizations listed in the previous section (compression, parallelism, and encryption) apply here as well.

     

    Once the Oracle RMAN backup is performed, it is necessary to export the SAP-related metadata that is not stored in the tablespaces. This includes, for example, views and authorizations. To do this, export the dictionary data for the tables owned by SAPSR3, as shown in "Part 4: SAP Database Migration Method 2—Transportable Tablespaces" and in Listing 9.

     

    $ cat tts_export_dict.par

    full=y

    exclude=table:"in( select table_name from dba_tables where owner='SAPSR3')"

    exclude=tablespace

    exclude=statistics

    compression=none

    directory=migrate_pr1

    dumpfile=dict.dmp

    logfile=ttsexpdict.log

    status=60

    $ expdp par=tts_export_dict.par

    Listing 9: Exporting the metadata not stored in the tablespaces.

     

    Once again, optimizations for metadata export (compression, parallelism, and encryption) apply here as well.

     

    If the goal of the migration is to create a system clone, the source system can be set online by restarting the database in read-write mode (and then restarting the SAP application, which is not shown in Listing 10):

     

    SQL> alter tablespace PSAPSR3 read write;

    Tablespace altered.

    SQL> alter tablespace PSAPSR3740 read write;

    Tablespace altered.

    SQL> alter tablespace PSAPSR3USR read write;

    Tablespace altered.

    Listing 10: Setting the relevant tablespaces back to read-write mode.

     

    Step 3. Transporting the backup files to the destination platform.

     

    From an Oracle RMAN perspective, the method used to transport backup files to the destination does not matter as long as all backup files generated are available to the destination system.

     

    As mentioned previously, during the testing, an NFS share was used that was accessible from both the source and destination systems. In such a case, the share must be set with the correct mount options for Oracle RMAN file systems. For more details, see "NFS Mounts for RMAN" in Oracle Support Document 1567137.1. (Access to Oracle Support Documents requires logon and authentication to My Oracle Support.)

     

    Step 4. Restoring the database on the destination platform.

     

    Before restoring the database on the destination, it's necessary to set up the database software on the destination system. Follow the steps in the article "Part 2: SAP Environment Migration—Pre-Database-Migration Tasks" to prepare the destination. Then, to create the destination database, follow the steps in the article "Part 4: SAP Database Migration Method 2—Transportable Tablespaces." Make sure to create the roles SAPCONN and SAPDB, as well as the SAPSR user.

     

    At this point, use Oracle RMAN to convert and copy the data files into the Oracle ASM file system specified during the database creation, and import the tablespace-related metadata, as shown in Listing 11:

     

    RMAN> RESTORE

            FOREIGN TABLESPACE PSAPSR3,PSAPSR3740,PSAPSR3USR TO NEW

            FROM BACKUPSET

            '/nfs_share/CROSS/sap_tablespaces_4jre10eb.bck',

            '/nfs_share/CROSS/sap_tablespaces_4kre10eb.bck',

            '/nfs_share/CROSS/sap_tablespaces_4lre10eb.bck',

            '/nfs_share/CROSS/sap_tablespaces_4mre10eb.bck'

            DUMP FILE FROM BACKUPSET '/nfs_share/CROSS/sap_tablespaces.dmp';

    ...

    Listing 11: Using Oracle RMAN to convert and copy the data files into an Oracle ASM file system.

     

    The runtime of the restore operation depends on both the number of objects in the tablespaces and the size of the tablespaces. There are two stages in a cross-platform restore for migrations with different endian format databases: converting the data files and importing the metadata. While the duration of the first phase (data file conversion) depends largely on the destination system's I/O capacity, the second part (importing the metadata) is dependent on the same factors as with the TTS migration method. Therefore, all the recommendations provided in "Part 4: SAP Database Migration Method 2—Transportable Tablespaces," particularly SAP recommendations for PFILE/SPFILE settings, are also relevant for this method.

     

    The last import step is the import of the dictionary metadata. It is done with a very simple and short parameter file:

     

    $ cat ttsimpdict.par

    directory=pr1migration

    dumpfile=dict_nocompress.dmp

    logfile=ttsimpdict.log

    $ impdp PARFILE=ttsimpdict.par

    Listing 12: Metadata import parameter file and dictionary data import.

     

    Once the import is complete, perform the final steps provided in "Part 4: SAP Database Migration Method 2—Transportable Tablespaces" to check the integrity of the database after the import process. These steps consist of running validate database from Oracle RMAN, and switching the tablespaces into read-write mode on the destination (Listing 13).

     

    SQL> alter tablespace PSAPSR3 read write;

    Tablespace altered.

    SQL> alter tablespace PSAPSR3740 read write;

    Tablespace altered.

    SQL> alter tablespace PSAPSR3USR read write;

    Tablespace altered.

    SQL> select tablespace_name,status from dba_tablespaces;

    TABLESPACE_NAME    STATUS

    ---------------------------------------

    SYSTEM            ONLINE

    SYSAUX            ONLINE

    PSAPUNDO          ONLINE

    PSAPTEMP          ONLINE

    PSAPSR3            ONLINE

    PSAPSR3740        ONLINE

    PSAPSR3USR        ONLINE

    Listing 13: Setting the tablespaces to read-write mode on the destination system.

     

    The default and temporary tablespaces must be set for user SAPSR3:

     

    SQL> alter user sapsr3 default tablespace psapsr3usr temporary tablespace psaptemp;

    User altered.

    Listing 14: Setting default and temporary tablespaces for user SAPSR3.

     

    Some SAP systems use PSAPSR3 as the default tablespace for user SAPSR3. In that case, set it to PSAPSR3 instead of the PSAPSR3USR value shown in Listing 14.

     

    The Oracle Database migration is now complete and the database instance is usable. There are, however, additional tasks that are necessary to finalize the migration of the SAP system itself. These additional steps are listed in the article "Part 6: SAP Environment Migration—Post-Database-Migration Tasks."

     

    See Also

     

    For more information about the Oracle RMAN cross-platform BACKUP and RESTORE operations for data transport, refer to the Oracle Database Backup and Recovery User's Guide (for Oracle Database 12c). Also see the Oracle Recovery Manager page on Oracle Technology Network.

     

    About the Authors

     

    Jan Brosowski is a principal sales consultant for Oracle Systems in Europe North. Located in Walldorf, Germany, he is responsible for developing customer-specific architectures and operating models for both SAP and Hyperion systems, accompanying the projects from the requirements specification process to going live. Brosowski holds a Master of Business and Engineering degree and has been working for over 15 years with SAP systems in different roles.

     

    Andris Perkons is a principal sales consultant for Oracle Systems in Europe North. Located in Dusseldorf, Germany, he supports and develops systems architectures with a focus on achieving smooth migrations and highly available solutions. Perkons has 20 years' experience with SAP systems and Oracle Database in pre- and post-sales roles.

     

    Pierre Reynes is a solution manager for Oracle Optimized Solution for SAP and Oracle Optimized Solution for PeopleSoft. He is responsible for driving the strategy and efforts to help raise customer and market awareness for Oracle Optimized Solutions in these areas. Reynes has over 25 years of experience in the computer and networking industries.