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:
- 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
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
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
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
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/22.214.171.124/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:
- Cloning an existing
ORACLE_HOMEto create a new
- Applying the SAP bundle patch to the newly created
- Migrating databases from the original
ORACLE_HOMEto the newly patched
- 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@sapm7zdbadm1c1:~$ ln -s /u01/app/oracle/product/126.96.36.199/dbhome_SXD12102P_1511 /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.
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@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.
$ 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/188.8.131.52/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
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
/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
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@sapm7zdbadm1c1:/oracle/PR2/121/dbs$ . oraenv
ORACLE_SID = [dbm011] ? PR2
oracle@sapm7zdbadm1c1:/oracle/PR2/121/dbs$ env |grep ORACLE
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.