Skip to Main Content



For appeals, questions and feedback about Oracle Forums, please email Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Best Practices for Migrating SAP Systems to Oracle Infrastructure--Part 1: Introduction to Methods f

steph-choyer-OracleMay 27 2016 — edited Mar 16 2017

by Jan Brosowski, Victor Galis, and Pierre Reynes

This article, the first in a series, introduces three methods for migrating Oracle Database instances as a part of an SAP migration to an Oracle infrastructure: Oracle Recovery Manager (Oracle RMAN) DUPLICATE, transportable tablespaces (TTS), and Oracle RMAN Cross-Platform BACKUP and RESTORE.



This article is Part 1 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:

| |


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



Understanding SAP Migrations

Moving an SAP system between platforms is a well-documented and understood process. Every SAP Basis consultant clearly understands what the term heterogeneous system copy means—this is the official SAP wording for a migration that includes a change in the underlying hardware architecture, operating system, or relational database.

SAP has developed its own migration methods for SAP systems known as "R3LOAD"-based migrations, although the official name has changed over time. The idea behind the R3LOAD methodology is to first convert the whole SAP system to a platform- and database-agnostic format, and then to import it into a fresh new SAP installation on the destination platform. This well-known migration approach has its strength: mainly, it is universally applicable, allowing for migrations from any source to any destination. But it also has a significant weakness: it is an especially time- and resource-intensive effort, because it transfers the entire database content into a platform-independent format on the source side first, and then converts it into a platform-specific format again on the destination side.

Because an SAP system stores critical data in an underlying relational database, a fundamental part of the migration process is the database migration itself. A large majority of SAP systems use Oracle Database as the relational database. There are a number of different methods to migrate Oracle Database instances for SAP systems, and this series of articles focuses on three frequently used and effective techniques.

This first article in the series provides an overview of the three methods, comparing their respective benefits. The second article (Part 2) describes what's necessary to move the SAP environment (its file systems, SAP binaries, configurations, and so on). Parts 3, 4, and 5 give specific procedures for each of the three database migration methods: Oracle Recovery Manager (Oracle RMAN) DUPLICATE, transportable tablespaces (TTS), and Oracle RMAN Cross-Platform BACKUP and RESTORE, respectively. The final article in the series describes steps that must be performed after the Oracle Database migration is complete.

All the migration methods detailed in the articles have been tested on Oracle SuperCluster M7, an Oracle engineered system that offers many advantages for SAP environments, including infrastructure simplification, performance acceleration, high availability, and robust security. A number of papers have been published describing the benefits of deploying and running SAP on Oracle SuperCluster, including "Oracle SuperCluster M7: The Ideal Platform for SAP" and "How to Improve the Efficiency and Performance of an SAP Environment with Oracle Optimized Solution for SAP."

Note that the methods described in these articles could easily be adapted to a different destination platform such as other Oracle engineered systems or Oracle's SPARC servers with storage solutions from Oracle (Oracle ZFS Storage Appliances, Oracle All Flash FS1 Flash Storage Systems, and Oracle FS1-2 storage systems).

Overview of SAP Database Migration Methods

Today, many methods can be used to migrate Oracle Database instances in an SAP environment to a different platform. Figure 1 shows eight of the most commonly implemented approaches, charting them by the amount of downtime typically required and by the migration characteristic of heterogeneity versus homogeneity.


Figure 1. A comparison of SAP migration methods

Although they are shown in Figure 1, this article series does not cover the following methods:

  • R3LOAD, the universally applicable method provided by SAP and documented in the paper "Best Practices for Migrating SAP Environments"
  • Standard backup/restore methods, which allow very little heterogeneity between the source and destination platforms
  • Oracle Active Data Guard methods, which are more appropriate for disaster recovery (DR) than for migration purposes and also permit very little heterogeneity between the source and destination platforms

Instead, this article series focuses on these three methods of migrating Oracle Database instances as a part of an SAP systems migration:

  • Oracle RMAN DUPLICATE: A method that creates a complete clone of the source Oracle Database instance in the destination environment
  • Transportable tablespaces (TTS): A method capable of moving tablespaces between different platforms and Oracle Database releases
  • Oracle RMAN cross-platform BACKUP and RESTORE: A method similar to TTS (but introduced with Oracle Database 12_c_) that simplifies overall database migration procedures

Another approach is to use Oracle Migration Service offline and online variants previously known as Oracle-to-Oracle and Oracle-to-Oracle Online services, respectively. (These are sometimes called O2O and Triple-O, respectively, by field consultants.) Available from Oracle Advanced Customer Support Services, these services supply tools and consultants who have extensive field expertise to help to minimize risk and lower downtime, making them well-suited for certain Oracle Database and SAP migrations.

All of these migration methodologies, including the Oracle Migration Service options, have respective strengths and use cases in which they are most appropriate. The following table compares and contrasts the different approaches, and can help SAP system architects select the most suitable method for a migration.

| | Oracle RMAN DUPLICATE | Transportable Tablespaces (TTS) | Oracle RMAN Cross-Platform BACKUP and RESTORE | Oracle Migration Service: Oracle-to-Oracle | Oracle Migration Service: Oracle-to-Oracle Online |
| Downtime and migration time compared to R3LOAD | Downtime: Shorter.

Migration: Faster, especially for small and medium databases. | Downtime: Similar on source database.

Migration: Faster particularly for large databases. | Downtime: Similar on source database.

Migration: Faster particularly for large databases. | Downtime: Minimal, depends on database size.

Migration: Faster, particularly for standard SAP databases. | Downtime: Typically 30–60 minutes even for extremely large databases.

Migration: Dependent on size, number of changes, and network bandwidth between source and destination. |
| Cost | Free; no additional licenses or consultants needed. | Free; no additional licenses or consultants needed. | Free; no additional licenses or consultants needed. | Paid service from Oracle Advanced Customer Support Services; no additional licenses needed. | Paid service from Oracle Advanced Customer Support Services; Oracle GoldenGate required during migration. |
| Technical restrictions | Source and destination platforms must be similar (same endianness, similar operating system) and on the same database release. | Source must be Oracle Database 10_g_ or higher.

Destination has to be on the same or a higher release than source. | Source must be Oracle Database 12_c_ or higher.

Destination has to be on the same or a higher release than source. | Source release must be Oracle Database 8.1 or later.

Oracle Migration Manager software has to be installed on both the source and destination side. | Source and destination need Oracle GoldenGate for data transfer.

Source and destination can be any database supported by Oracle GoldenGate. |
| Special features | Primary database can stay online if used for system copies. | Can be performed in iterative steps for very large databases. | Can be performed in iterative steps for very large databases. | Can introduce additional Oracle Database features such as compression or partitioning; always includes a reorganization of the database. | Can introduce additional Oracle Database features; includes a reorganization of the database.

Includes fallback scenario to old hardware that has similar downtime. |
| Knowledge level | Oracle RMAN knowledge; no SAP-specific knowledge needed. | Oracle Database administration and Oracle RMAN knowledge; no SAP-specific knowledge needed. | Oracle Database and Oracle RMAN knowledge for latest release; no SAP-specific knowledge needed. | Consultant needed who has expert knowledge about SAP database administration. | Consultant needed who has expert knowledge about database replication with Oracle GoldenGate. |
| Summary | Migration with downtime between similar platforms and similar releases without additional cost. | Migration with downtime between all platforms and releases without additional cost. | Migration with longer downtime between all platforms without additional cost; available for Oracle Database 12_c_ and higher. | Migration with downtime between all platforms; requires consulting service. | Migration with nearly no downtime between all platforms; requires consulting service; requires Oracle GoldenGate licenses. |


The Oracle RMAN "DUPLICATE FROM ACTIVE DATABASE" approach is the easiest and simplest method to create a full copy of a complete Oracle Database instance. It can be used offline or online with the source database in an open state and operating during the copy process.

The offline process makes sure that both databases are exactly the same, while the online process restores the database to the status it had at the beginning of the duplication process and all subsequent changes are lost. This makes the offline process the best choice for migrations, while the online process is best for copying a busy system with high availability requirements.

However, the Oracle RMAN DUPLICATE approach is limited to specific platforms that share the same underlying hardware architecture with the same byte-endian format and the same version and patch level of Oracle Database. Generally, the Oracle RMAN DUPLICATE DATABASE command is used to create the database copy. Oracle Database parameter settings influence the copy that is created and can define a new storage structure, such as an Oracle Automatic Storage Management (Oracle ASM) destination. Thus this approach can be used to migrate from file system–based database storage into Oracle ASM.

Transportable Tablespaces

The transportable tablespaces (TTS) method uses an Oracle Database feature that became available for SAP migrations starting with Oracle Database 10_g_. It can be used to transport an Oracle Database instance or specific tablespaces from any source environment to any destination environment. Potential changes in the destination environment can include a different operating system, a change in the endianness of the underlying hardware, and changes in the storage architecture. TTS uses only standard Oracle Database functionality, making it an economical migration choice.

As an example, TTS can be used to migrate from an older x86 server running a Linux operating system and using local storage disks with EXT2 file systems to a current SPARC architecture platform running Oracle Solaris 11 and using Oracle ASM data storage on Oracle Exadata Storage Servers.

TTS functionality is based on the principle that an Oracle Database instance on any platform is able to read files created by another Oracle Database instance on any other platform, as long as it has the correct metadata describing the files, and as long the bit ordering is the same. If the bit ordering or the underlying storage architecture changes, Oracle RMAN offers the option to convert files between platforms. Running the query V$TRANSPORTABLE_PLATFORM displays the platforms that TTS supports.

By not changing database files, the transfer of the metadata constitutes the critical path in a TTS-based migration. This means that the duration of a TTS migration is not generally affected by the size of the database, but rather by the number of database objects (such as tables, indices, and so forth). In other words, TTS is faster than a standard migration, particularly when transferring large databases that contain a comparably small number of objects.

Oracle RMAN Cross-Platform BACKUP and RESTORE

Oracle Database 12_c_ introduced a new method called Oracle RMAN Cross-Platform BACKUP and RESTORE. Simply put, it combines the abilities of TTS with the ease of using Oracle RMAN DUPLICATE.

Oracle RMAN Cross-Platform BACKUP and RESTORE can be used both for system clones and migrations. It is comparably fast like TTS, but because it offers less flexibility in tuning, this method can be slower in certain cases.

Oracle RMAN Cross-Platform BACKUP and RESTORE handles data files differently than TTS, however. While TTS leaves data files untouched, Oracle RMAN Cross-Platform BACKUP and RESTORE always transports them using its own data format. Both creating and restoring data files from this file format is fast, but it is an additional step compared to TTS, which allows the original data files to be simply mounted on shared storage from the destination database.

On the other hand, when a copy of the data file must be created to transfer the data to the target platform—for example, when doing a system copy on separate storage—the Oracle RMAN Cross-Platform BACKUP and RESTORE method does not lead to slower performance.

Oracle RMAN Cross-Platform BACKUP and RESTORE can be used for heterogeneous and homogeneous migrations between any platforms that support Oracle Database 12_c_. In the future, when most SAP environments are running Oracle Database 12_c_, it will likely be an adequate replacement for TTS in most cases and provide a simplified migration process.

Oracle Migration Service for SAP

Oracle Migration Service can help migrate Oracle Database instances and SAP systems quickly and efficiently, allowing businesses to benefit from the latest database technologies, including Oracle Database 12_c_ and Oracle Database In-Memory.

Oracle Migration Service brings the benefits of automated technology, interactive tools, and experienced consultants to help plan, validate, and migrate all database content quickly and effectively. The service is a fixed-scope, fixed-price offering for migrating Oracle Database instances and non-Oracle databases to Oracle Database running on Oracle infrastructure such as Oracle SuperCluster. Key migration activities include

  • Premigration analysis of what's essential to a successful migration
  • High degrees of automation and tuning, to minimize the chance of human error and allow migrations to occur in parallel
  • Migration validation processes
  • Comprehensive reporting during each step of the process
  • Production execution

Not only does Oracle Migration Service include the ability to migrate the database, but it also can perform a database upgrade and introduce new database features at the same time. As an example, Oracle Migration Service can migrate between Oracle Database 10_g_ running on the HP-UX operating system to the latest Oracle Database 12_c_ release on Oracle SuperCluster while introducing index compression and encryption at the same time.

Depending on the specific availability requirements for a migration, Oracle Migration Service uses one of two different variants: either the option known formerly as Oracle-to-Oracle or the option formerly known as Oracle-to-Oracle Online.

  • Oracle-to-Oracle. The offline variant requires source database downtime during the migration. The downtime needed to migrate a database depends on the database size, the included database objects (SAP cluster tables, partitioned tables, and so on), and the available hardware resources (CPU, memory, storage, and network). This method offers a migration speed of more than 1 TB per hour and requires minimal configuration and migration testing, so it is generally faster than other traditional approaches.
  • Oracle-to-Oracle Online. If downtime requirements cannot be met with the offline method, this online method is an alternative. It was developed to minimize database migration time. Typically, the required downtime for a database migration is between 30 minutes to 1 hour depending on the database size. Technically, this migration service uses a continuous synchronization method to perform the actual data transfer while the source Oracle Database and SAP systems are online serving end users. Any changes to the source database are transferred to the destination side, and after a while, the source and destination databases are identical. A short downtime is then needed to switch the application servers to the new database. The actual time for the data transfer is, therefore, higher than the needed downtime for the switch-over.

Final Thoughts

Migrating Oracle Database instances for SAP systems to a different infrastructure can be a challenging undertaking without the proper guidance. This series of articles provides best practices, concrete procedures, and guidance to help ease the process of migrating to an Oracle infrastructure. The first step, of course, is to determine an optimal migration strategy based on migration project requirements: the source platform, operating system, Oracle Database release, and patch levels; the targeted Oracle Database destination environment and options; cost considerations; downtime concerns; staffing levels; and other environment specifics.

Subsequent articles in this series describe the steps used to move an Oracle Database instance and SAP environment to Oracle SuperCluster M7 using the Oracle RMAN DUPLICATE, transportable tablespaces (TTS), and Oracle RMAN Cross-Platform BACKUP and RESTORE methods. For specifics, see each associated article and its validated migration procedures.

See Also

Refer to these resources for more information:

Online Resources



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.

Victor Galis is a master sales consultant, part of the global Oracle Solution Center organization. He supports customers and sales teams architecting SAP environments based on Oracle hardware and technology. He works with SAP Basis and DBA teams, systems and storage administrators, as well as business owners and executives. His role is to understand current environments, business requirements, and pain points as well as future growth and map them to SAP landscapes that meet both performance and high availability expectations. He has been involved with many SAP on Oracle SuperCluster customer environments as an architect and has provided deployment and go-live assistance. Galis is an SAP-certified consultant and Oracle Database administrator.

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 experience in the computer and networking industries.

Post Details
Added on May 27 2016