4/25/2019 Best Practices for Migrating SAP Systems to Ora...

| Oracle Community

Best Practices for Migrating SAP Version 3

Systems to Oracle Infrastructure--Part 2:

SAP Environment Migration--Pre-
Database-Migration Tasks
Created by steph-choyer-Oracle on May 27, 2016 9:23 AM. Last modified by steph-choyer-Oracle on Mar 17, 2017
9:33 AM.

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.

Introduction
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:

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

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

https://community.oracle.com/docs/DOC-999528 1/4
4/25/2019 Best Practices for Migrating SAP Systems to Ora... | Oracle Community

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=

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).

oracle@sapm7zdbadm1c1:~$ 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/12.1.0.2/dbhome_1 (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
https://community.oracle.com/docs/DOC-999528 2/4
4/25/2019 Best Practices for Migrating SAP Systems to Ora... | Oracle Community

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.

oracle@sapm7zdbadm1c1:~$ ln -s /u01/app/oracle/product/12.1.0.2/dbhome_SXD12102P_1511 /oracle/

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.

oracle@sapm7zdbadm1c1:~$ mkdir -p /oracle/PR2/saptrace/audit /oracle/PR2/saptrace/diag

oracle@sapm7zdbadm1c1:~$ 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).

oracle@sapm7zdbadm1c1:~$ 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
/oracle/PR2
$ 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/12.1.0.2/dbhome_SXD12102P_1511
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.

PR2:/oracle/PR2/121:N
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.

https://community.oracle.com/docs/DOC-999528 3/4
4/25/2019 Best Practices for Migrating SAP Systems to Ora... | Oracle Community

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.

oracle@sapm7zdbadm1c1:/oracle/PR2/121/dbs$ . oraenv
ORACLE_SID = [dbm011] ? PR2
oracle@sapm7zdbadm1c1:/oracle/PR2/121/dbs$ env |grep ORACLE
ORACLE_SID=PR2
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/oracle/PR2/121
Listing 8: Setting and checking environment variables.

https://community.oracle.com/docs/DOC-999528 4/4