Forum Stats

  • 3,780,804 Users
  • 2,254,440 Discussions


Best Practices for Migrating SAP Systems to Oracle Infrastructure--Part 2: SAP Environment Migration

steph-choyer-Oracle Member Posts: 101 Red Ribbon
edited Mar 17, 2017 5:33AM in Optimized Solutions

by Jan Brosowski, Victor Galis, and Pierre Reynes

This article, Part 2 in the series, provides preliminary steps to prepare an SAP environment before using any of the Oracle Database migration methods given in other articles.


This article is Part 2 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.

Preparing for an Oracle Database Migration

There are a few simple steps to prepare the environment before starting an Oracle Database migration.

Step 1. Determine the appropriate destination database parameters.

The following parameters must be specified for the destination database:

  • Oracle Database instance name
  • Oracle Database type: Oracle Real Application Clusters (Oracle RAC) or single-instance database
  • Number of database instances (if the database type is Oracle RAC)
  • Node name(s) on which the instances are running
  • Naming convention for Oracle RAC instances: one or three characters

In the migration procedures, the source database is initially migrated as a single-instance database. Once that migration is completed, the database instance can be converted to an Oracle RAC implementation if required.

Step 2. Prepare the environment for the SAP databases.

In this series of migration articles, the destination database has the ORACLE_SID PR2, PR3, or PR4 (depending on the chosen migration method), while the source (target) database has the ORACLE_SID PR1. While SAP installations usually use the same SAP SID and ORACLE_SID, it is supported to have different values for the two. One use case for such a setup would be to have training systems that have the same SAP SID, but have Oracle Database instances with different ORACLE_SID values.

SAP uses the file system /oracle/<ORACLE_SID> as the default database location. Best practice is to have this file system NFS-mounted from an internal Oracle ZFS Storage Appliance in the Oracle SuperCluster or from an external Oracle ZFS Storage Appliance. Depending on the environment, /oracle can either be NFS-mounted or each individual /oracle/<ORACLE_SID> directory can be a separately mounted file system. This decision is greatly influenced by dependencies between SAP systems and by current organizational practices.

In the migration procedures, one share on the internal Oracle ZFS Storage Appliance is defined in a separate project named ORACLE. The share is mounted as /oracle by adding an /etc/vfstab entry such as the one in Listing 1.

sapm7-h2-storIB:/export/sapm7/ORACLE/oracle  -  /oracle  nfs  -  yes  rw,bg,hard,nointr,rsize=131072,wsize=131072,proto=tcp,vers=3

Listing 1: Adding a new entry to /etc/vfstab for /oracle.

To create the mount point for the database, define an instance-specific directory. Listing 2 creates the mount point /oracle/PR2 (PR2 is the destination database used as an example in this article and in the migration article describing the use of Oracle RMAN DUPLICATE).

[email protected]:~$ mkdir /oracle/PR2

Listing 2: Creating a mount point for the new database instance PR2.

Step 3. Create soft links for ORACLE_HOME.

The Oracle Database software is installed in a standard path location referenced in the environment variable ORACLE_HOME. By default, the Oracle Database installation directory on Oracle SuperCluster is /u01/app/oracle/product/ (note that the path name also reflects the Oracle Database version).

For an SAP installation on Oracle SuperCluster, the ORACLE_HOME variable is set to /oracle/<ORACLE_ SID>/121, and a soft link is created that maps this location to an Oracle Database installation directory.

On Oracle SuperCluster deployments, and on any other server used for hosting instances of Oracle Database for SAP, multiple Oracle Database software home directories are often present. This is generally the result of a commonly used patching methodology that reduces downtime (see SAP Note 1696869, "Patching of Oracle Homes with Minimal Downtime"). This patching approach includes four basic steps:

  1. Cloning an existing ORACLE_HOME to create a new ORACLE_HOME.
  2. Applying the SAP bundle patch to the newly created ORACLE_HOME.
  3. Migrating databases from the original ORACLE_HOME to the newly patched ORACLE_HOME.
  4. Performing the final database patching steps.

The step of moving a database to a newly patched ORACLE_HOME is then a simple change of the soft link from the original ORACLE_HOME to the newly patched software home. As this methodology is both commonly used and a well-proven approach to reduce planned downtime, we use it as the basis of this series of migration articles.

All of the procedures assume that the migration process begins with an already patched ORACLE_HOME software home, and that the ORACLE_HOME for a specific SAP database is a symbolic link to an ORACLE_HOME directory that is patched with a current SAP bundle patch. Best practice is to include the patch name in the software home directory name, reflecting the level of the installed patch bundle. In Listing 3, for example, the ORACLE_HOME directory name indicates the currently applied SAP bundle patch (dbhome_SXD12102P_1511). Later on, when another patch is applied to a clone of ORACLE_HOME, updating the soft link simplifies access to the new ORACLE_HOME.

[email protected]:~$ ln -s /u01/app/oracle/product/ /oracle/PR2/121

Listing 3: Creating a soft link for ORACLE_HOME to a directory named according to the patch level.

Step 4. Create a new directory for log files.

Next, it's necessary to create new log file directories for the destination database. If BR*Tools will be used, the directories sapprof (profile) and sapbackup (log) must also be created.

[email protected]:~$ mkdir -p /oracle/PR2/saptrace/audit /oracle/PR2/saptrace/diag

[email protected]:~$ mkdir /oracle/PR2/sapbackup /oracle/PR2/sapprof

Listing 4: Creating directories for log files and optionally for BR*Tools.

Step 5. Change ownership of /oracle/PR2 to the user oracle.

Files in the destination database directory must have the correct ownership (that of the user oracle).

[email protected]:~$ chown -R oracle:oinstall /oracle/PR2

Listing 5: Setting the ownership for the database directory and files.

At this point, the environment is ready to begin a database migration using one of the migration method articles in this series.

$ pwd


$ ls -lah

drwxr-xr-x   3 oracle   oinstall       4 Aug 11 12:49 .

drwxr-x---   9 oracle   oinstall      14 Jul 15 02:28 ..

lrwxrwxrwx   1 oracle   oinstall      54 Apr  7 00:45 121 -> /u01/app/oracle/product/

drwxr-xr-x   4 oracle   oinstall       4 Apr  7 00:49 saptrace

drwxr-xr-x   4 oracle   oinstall       4 Apr  7 00:52 sapprof

Listing 6: Content and ownership in the destination database directory /oracle/PR2.

Step 6. Create the destination database on one of the nodes.

The destination Oracle Database can be created either manually or by using the Oracle Database Configuration Assistant (Oracle DBCA). If Oracle DBCA is used, make sure that the default location of the SPFILE is in $ORACLE_HOME/dbs and not a file on an Oracle Automatic Storage Management (Oracle ASM) disk group. When Oracle Recovery Manager (Oracle RMAN) is used to duplicate a database, a new SPFILE is created and the database is restarted. This procedure will fail if the new SPFILE is created on an Oracle ASM destination.

Step 7. Associate the ORACLE_SID to its home directory in the oratab file.

The file /var/opt/oratab should contain one line for every database instance being configured, as shown in Listing 7.


Listing 7: Adding the ORACLE_SID PR2 and its home directory to the oratab file.

The syntax is <db_unique_name>:<oracle home directory>:startup on host boot (Y or N). The first and second fields are the ORACLE_SID and the home directory for the database, respectively. The third field instructs the dbstart utility whether the database should (Y) or should not (N) be started at system boot time.

Step 8. Set up and check environment variables for the destination database.

Prior to a migration, use the oraenv command to define environment variables and set the ORACLE_SID variable. The Oracle Database base directory (ORACLE_BASE) remains unchanged from the default value /u01/app/oracle. The Oracle Database home directory (ORACLE_HOME) is set to the value /oracle/PR2/121.

[email protected]:/oracle/PR2/121/dbs$ . oraenvORACLE_SID = [dbm011] ? PR2[email protected]:/oracle/PR2/121/dbs$ env |grep ORACLEORACLE_SID=PR2ORACLE_BASE=/u01/app/oracleORACLE_HOME=/oracle/PR2/121

Listing 8: Setting and checking environment variables.

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