Oracle.

com Downloads Cloud Trials Other Languages Go Directly To Quick Links

Best Practices for Migrating SAP Systems to Oracle Infrastructure-  Version 15

-Part 1: Introduction to Methods for Migrating SAP to an Oracle

Stack
Created by steph-choyer-Oracle on May 27, 2016 9:21 AM. Last modified by steph-choyer-Oracle on Mar 16, 2017 4:15 PM.

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.

Introduction

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 in collaboration with
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:
Oracle Optimized Solutions provide
tested and proven best practices for
how to run software products on
Oracle systems. Learn more .

Part 1: Introduction to Methods for Migrating SAP to an Oracle Stack

Part 2: SAP Environment Migration—Pre-Database-Migration Tasks
Part 3: SAP Database Migration Method 1—Oracle RMAN DUPLICATE
Part 4: SAP Database Migration Method 2—Transportable Tablespaces
Part 5: SAP Database Migration Method 3—Oracle RMAN Cross-Platform BACKUP and RESTORE
Part 6: SAP Environment Migration—Post-Database-Migration Tasks

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 12c) 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
Downtime Downtime: Shorter.
and
migration Migration: Faster, especially
time for small and medium
compared databases.
to R3LOAD
Cost Free; no additional licenses or Free; no additional
consultants needed.
Technical Source and destination
restrictions platforms must be similar
(same endianness, similar
operating system) and on the
same database release.
Transportable Oracle RMAN Cross-Platform Oracle Migration Service: Oracle Migration Service:
Tablespaces (TTS) BACKUP and RESTORE Oracle-to-Oracle Oracle-to-Oracle Online
Downtime: Similar on Downtime: Similar on source Downtime: Minimal, depends on Downtime: Typically 30–60
source database. database. database size. minutes even for extremely
large databases.
Migration: Faster Migration: Faster particularly Migration: Faster, particularly for
particularly for large for large databases. standard SAP databases. Migration: Dependent on
databases. size, number of changes,
and network bandwidth
between source and
destination.
Free; no additional licenses Paid service from Oracle Paid service from Oracle
licenses or consultants or consultants needed. Advanced Customer Support Advanced Customer Support
needed. Services; no additional licenses Services; Oracle GoldenGate
needed. required during migration.
Source must be Oracle Source must be Oracle Source release must be Oracle Source and destination need
Database 10g or Database 12c or higher. Database 8.1 or later. Oracle GoldenGate for data
higher. transfer.
Destination has to be on the Oracle Migration Manager
Destination has to be same or a higher release software has to be installed on Source and destination can
on the same or a than source. both the source and destination be any database supported
higher release than side. by Oracle GoldenGate.
source.
 Oracle RMAN DUPLICATE
Special Primary database can stay
features online if used for system
copies.
Knowledge Oracle RMAN knowledge; no
level SAP-specific knowledge
needed.
Summary Migration with downtime
between similar platforms and
similar releases without
additional cost.
Transportable Oracle RMAN Cross-Platform Oracle Migration Service: Oracle Migration Service:
Tablespaces (TTS) BACKUP and RESTORE Oracle-to-Oracle Oracle-to-Oracle Online
Can be performed in Can be performed in Can introduce additional Oracle Can introduce additional
iterative steps for very iterative steps for very large Database features such as Oracle Database features;
large databases. databases. compression or partitioning; includes a reorganization of
always includes a reorganization the database.
of the database.
Includes fallback scenario to
old hardware that has similar
downtime.
Oracle Database Oracle Database and Oracle Consultant needed who has Consultant needed who has
administration and RMAN knowledge for latest expert knowledge about SAP expert knowledge about
Oracle RMAN release; no SAP-specific database administration. database replication with
knowledge; no SAP- knowledge needed. Oracle GoldenGate.
specific knowledge
needed.
Migration with Migration with longer Migration with downtime between Migration with nearly no
downtime between all downtime between all all platforms; requires consulting downtime between all
platforms and releases platforms without additional service. platforms; requires
without additional cost. cost; available for Oracle consulting service; requires
Database 12c and higher. Oracle GoldenGate licenses.

Oracle RMAN DUPLICATE

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 10g. 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 12c 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 12c. In the future, when most SAP environments are running Oracle Database 12c, 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 12c 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 10g running on the HP-UX operating system to the latest Oracle
Database 12c 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

Oracle Optimized Solution for SAP

Oracle Database and IT Infrastructure for SAP
Oracle Services for SAP
SAP on Oracle

Papers

"Best Practices for Migrating SAP Environments "

"Oracle SuperCluster M7: The Ideal Platform for SAP "
"How to Improve the Efficiency and Performance of an SAP Environment with Oracle Optimized Solution for SAP "
"Oracle ACS Lifecycle Migration Service for SAP Environments "
"Migrating Oracle Databases "
"Using SAP NetWeaver with Oracle Database 12c on Oracle Exadata "
"SAP Note 1508271 " - Oracle Lifecycle Migration Service (formerly O2O/Triple-O)

Documentation

Oracle Database documentation site

Oracle Database Backup and Recovery User's Guide

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.

4803 Views Categories:

Tags: database, migration, sap, solaris, sparc, supercluster, oracle supercluster, otntecharticle, oracle solaris, database migration, oracle optimized solutions, optimized
solutions, oos, oracle sparc, optimized solution, oracle optimized solution, sap migration, oracle migration services

Average User Rating

(5 ratings )

0 Comments

Oracle Community

   
About Oracle Developer Community FAQ Communities Other Languages Oracle.com

Site Map Legal Notices Terms of Use Privacy Cookie Preferences Ad Choices