SAP OS/DB Migration from HP-UX Platform to Vblock Systems - VCE

VCE Word Template 

Table of Contents 

www.vce.com 

SAP OS/DB MIGRATION FROM HP-UX 

PLATFORM TO VBLOCK SYSTEMS 

Version 2.0 

February 2013 

© 2013 VCE Company, LLC. All Rights Reserved. 


1

Copyright 2013 VCE Company, LLC. All Rights Reserved. 

VCE believes the information in this publication is accurate as of its publication date. The information is subject to 

change without notice. 

THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." VCE MAKES NO 

REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN 

THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OR 

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


2

Contents 

Introduction ................................................................................................................................. 6 

Business case ............................................................................................................................ 6 

Key results ................................................................................................................................. 6 

Vblock Systems versus PO8 (quarter end) transaction response times ................................ 7 

Vblock Systems versus PO8 (active) transaction response times ......................................... 7 

Scope ......................................................................................................................................... 7 

Objectives .................................................................................................................................. 7 

Audience .................................................................................................................................... 8 

Feedback ................................................................................................................................... 8 

Technology overview .................................................................................................................. 9 

Vblock Systems ....................................................................................................................... 9 

Vblock System 720 ................................................................................................................. 9 

Vblock System 320 ................................................................................................................. 9 

SAP components ..................................................................................................................... 10 

Environment and configuration details .................................................................................. 11 

Customer HP platform and SAP configuration ......................................................................... 11 

Database configuration on the HP-UX platform ................................................................... 12 

Vblock System configuration .................................................................................................... 13 

SAP server configuration on Vblock System 700 ................................................................. 13 

SAP database storage configuration on Vblock System 700 ............................................... 14 

Summary comparison of Vblock Systems and customer’s HP configuration .......................... 15 

SAP systems sizing considerations ......................................................................................... 16 

Migration best practices ........................................................................................................... 18 

Preparing the source system ................................................................................................... 18 

Downloading SAP media ...................................................................................................... 19 

Executing pending updates and deleting canceled updates ................................................ 19 

Deleting the QCM tables ...................................................................................................... 19 

Deleting all entries from tables TATGPC and TATGPCA ..................................................... 19 

Updating R3load, R3ldctl, and R3czchk in the Kernel directory ........................................... 19 

Updating the database parameters for sessions and processes .......................................... 19 

Increasing the table space for PSAPTEMP .......................................................................... 20 

Performing the complete database backup .......................................................................... 20 

Running the program SMIGR_CREATE_DDL as a batch job .............................................. 20 

Turning off the archive logs and redo logs mirroring ............................................................ 20 

Mounting the NFS share with required size for the export dump ......................................... 20 

Checking the /tmp file system .............................................................................................. 20 

Obtaining root-level access in the source system ................................................................ 20 


3

Exporting the source system database .................................................................................... 21 

Starting the export preparation process in the source system ............................................. 21 

Preparing to split tables ........................................................................................................ 21 

Starting the database export (ABAP+JAVA) ........................................................................ 23 

Preparing the target system ..................................................................................................... 27 

Installing all the pre-requisites for SAP on Linux systems .................................................... 27 

Installing Java 1.4.2 IBM version .......................................................................................... 27 

Adopting OS-level parameters required for Linux systems as recommended by SAP ........ 27 

Validating the SAP and Oracle file systems ......................................................................... 27 

Enabling the third-party security software to create the system users ................................. 27 

Installing the Oracle binaries and performing the database patching ................................... 27 

Mounting the NFS file system, which contains the export dump .......................................... 28 

Creating the migration key .................................................................................................... 28 

Adopting the database parameters for the processes and sessions .................................... 28 

Importing the database into the target system ......................................................................... 28 

Installing SCS and ASCS on the virtual hosts ...................................................................... 28 

Importing the database on virtual hosts ................................................................................ 30 

Installing the central instance using Java dump ................................................................... 34 

Installing the application servers .......................................................................................... 36 

Performing post-migration activities ......................................................................................... 36 

Fine tuning the database parameters ................................................................................... 37 

Starting SAP ......................................................................................................................... 37 

Running the installation check .............................................................................................. 37 

Installing the license key ....................................................................................................... 37 

Reconfiguring Java, performing memory tune-up and testing .............................................. 37 

Importing the profiles ............................................................................................................ 37 

Start the application servers ................................................................................................. 37 

Reconfiguring the STMS and changing the hostnames ....................................................... 37 

Changing all the RFC destinations ....................................................................................... 37 

Executing the program RS_BW_POST_MIGRATION ......................................................... 38 

Performing TEMSE consistency check and cleanup ............................................................ 38 

Configuring the logon groups ............................................................................................... 38 

Performing a complete backup ............................................................................................. 38 

Solution validation .................................................................................................................... 39 

Test environment ..................................................................................................................... 39 

Test objectives ......................................................................................................................... 39 

SAP performance testing ...................................................................................................... 40 

Tests ........................................................................................................................................ 41 

Test 1: Migration ................................................................................................................... 41 


4

Test 2: Performance ............................................................................................................. 42 

Test 3: Availability ................................................................................................................. 45 

Test 4: Stateless computing ................................................................................................. 45 

Test results summary ............................................................................................................... 45 

Conclusion ................................................................................................................................. 47 

Next steps ................................................................................................................................ 47 

References ................................................................................................................................. 48 


5

Introduction 

This document describes best practices for the operating system and database migration of SAP from 

HP Integrity Superdome servers running PA-RISC/HP-UX to Vblock Systems running x86 Red Hat 

Enterprise Linux. This paper demonstrates how customers can lower the migration risk of moving 

from a physical environment running HP-UX to Vblock Systems running Red Hat Linux in a virtualized 

environment. 

Traditional infrastructure practices recommend sizing for the worst case, which is an inefficient 

approach that adds to business risk. With Vblock Systems, customers can plan for the optimum size 

and take advantage of the dynamic scalability for SAP to support the worst-case scenarios. 

This paper provides guidance and testing results from a proof of concept (POC) performed for a large 

semiconductor equipment manufacturing company. The company’s SAP landscape includes the 

following modules: Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Supplier 

Relationship Management (SRM), Business Intelligence (BI), Process Integration (PI), and Enterprise 

Portal (EP). The tests involved migration and performance of two core SAP modules, ERP SCM and 

liveCache. Vblock System 700 was used as the target environment for this migration. 

Business case 

Virtualization has rapidly gained momentum in enterprise IT environments, because organizations are 

looking for ways to control escalating hardware costs and to optimize their use of energy and 

resources while improving business continuity. Virtualization of complex SAP applications can reduce 

costs and increase speed and resilience. Virtualization also permits faster data analysis and expands 

data analysis capabilities. 

Key results 

Key results demonstrate that when deployed on the Vblock System 700, SAP showed performance 

improvement well over the incumbent hardware. The key findings are: 

§ Performance improvement of 50% or more when running SAP on the Vblock System 700 

compared with a semiconductor equipment manufacturer’s environment 

§ 50% less hardware used compared to the customer’s environment 

§ Low migration risk moving from an HP-UX based physical environment to a Vblock System 700 

virtualized environment 

§ Fast recovery of failed application and database server blades with EMC Ionix Unified 

Infrastructure Manager (UIM) and Cisco Unified Computing System (UCS) service profiles 

§ Increased scalability to dynamically add resources 

§ High availability and live migration achieved through VMware vMotion 


6

Vblock Systems versus PO8 (quarter end) transaction response times 

The test results showed an overall 55% performance improvement on Vblock Systems. 

Transactions Vblock Systems (seconds) PO8 (quarter end) (seconds) Percent gain 

VA01 0.465 1.251 63 

VA02 0.315 1.298 76 

FAGLB03 0.229 2.1 89 

MMBE 2.1 1.905 -10 

KE30 0.953 2.28 58 

Vblock Systems versus PO8 (active) transaction response times 


Transactions Vblock Systems (seconds) PO8 (active) (seconds) Percent gain 

VA01 0.465 1.281 64 

VA02 0.315 1.358 77 

FAGLB03 0.229 1.753 87 

MMBE 2.1 2.211 5 

KE30 0.953 4.417 78 

Scope 

This document provides best practices for the OS/DB migration of SAP from HP Integrity Superdome 

servers running PA-RISC/HP-UX to the Vblock System 700 running x86/Red Hat Enterprise Linux. 

Objectives 

The objectives of this best practices document are to: 

§ Show how best practices were used to successfully complete the SAP migration to Vblock 

System 700 and explain how customers can use the same best practices to perform their 

migrations. The approaches used for sizing, application layout, storage layout, and the SAP 

migration procedure were all based on these best practices. 

§ Provide the collected testing/monitoring results data associated with the migration. Demonstrate 

running the applications on the Vblock System 700. 

§ Compare performance of Vblock Systems to a customer environment. 


7

Audience 

This paper is intended for Vblock Systems customers, SAP administrators and architects, and 

technical engineering staff, managers, IT planners, administrators, and other IT professionals who are 

evaluating, acquiring, managing, operating, or deploying SAP in a virtualized data center environment. 

Feedback 

To suggest documentation changes and provide feedback on this paper, send email to 

docfeedback@vce.com. Include the name of this paper, the name of the topic to which your comment 

applies, and your feedback. 


8

Technology overview 

This solution uses the following hardware and software components and technologies: 

§ Vblock Systems 

§ SAP components 

Vblock Systems 

The Vblock System from VCE is the world's most advanced converged infrastructure—one that 

optimizes infrastructure, lowers costs, secures the environment, simplifies management, speeds 

deployment, and promotes innovation. The Vblock System is designed as one architecture that spans 

the entire portfolio, includes best-in-class components, offers a single point of contact from initiation 

through support, and provides the industry's most robust range of configurations. 

Vblock System 720 

The Vblock System 720 is an enterprise, service provider class mission-critical system in the Vblock 

System 700 family, for the most demanding IT environments—supporting enterprise workloads and 

SLAs that run thousands of virtual machines and virtual desktops. It is architecturally designed to be 

modular, providing flexibility and choice of configurations based on demanding workloads. These 

workloads include business-critical enterprise resource planning (ERP), customer relationship 

management (CRM), and database, messaging, and collaboration services. The Vblock System 720 

leverages the industry’s best director-class fabric switch, the most advanced fabric based blade 

server, and the most trusted storage platform. The Vblock System 720 delivers greater configuration 

choices, 2X performance and scale from prior generations, flexible storage options, denser compute, 

five 9s of availability, and converged network and support for a new virtualization platform that 

accelerates time to service and reduces operations costs. 

Vblock System 320 

The Vblock System 320 is an enterprise and service provider ready system in the Vblock System 300 

family, designed to address a wide spectrum of virtual machines, users, and applications. It is ideally 

suited to achieve the scale required in both private and public cloud environments. The Vblock 

System 320 has been engineered for greater scalability and performance to support large enterprise 

deployments of mission-critical applications, cloud services, VDI, mixed workloads and application 

development and testing. The Vblock System 320 delivers greater configuration choices, 2X 

performance and scale from prior generations, flexible storage options, denser compute, five 9s of 

availability, and converged network and support for a new virtualization platform that accelerates time 

to service and reduces operations costs. Every Vblock System 320 is available with the marketleading 

EMC VNX storage arrays. 

For more information, go to www.vce.com. 


9

SAP components 

SAP is one of the key applications in today’s data centers, with the largest ERP market share. This 

test involved migrating the following key SAP components of the customer’s landscape: ERP Central 

Component (ECC) 6.0, SCM 5.0, and SAP liveCache. 

The SAP ERP application is an integrated enterprise resource planning software that targets business 

software requirements of midsize and large organizations in all industries and sectors. It allows for 

open communication within and among all company functions. 

SAP SCM enables collaboration, planning, execution, and coordination of the entire supply chain – 

empowering companies to adapt their supply chain processes to an ever-changing competitive 

environment. The SAP SCM solution transforms traditional supply chains from linear, sequential steps 

into an adaptive supply chain network. 

The SAP liveCache technology significantly increases the speed of the algorithmically complex, dataand 

runtime-intensive functions of various SAP applications, especially within SAP Supply Chain 

Management. It combines the advantages of main memory-based data retention with a complete 

operating concept, including backup and recovery. 


10

Environment and configuration details 

This section contains the configuration and sizing details for: 

§ Customer HP platform and SAP configuration 

§ Vblock Systems configuration 

Customer HP platform and SAP configuration 

The following table shows the SAP modules that are in the customer’s production landscape on the 

HP-UX platform. 

SAP component 

Estimated SAP systems 

(based on the hardware configuration) 

ERP Central Component (ECC) 6.0 77,528 

Supply Chain Management (SCM) 5.0 17,620 

SAP liveCache 7.6 

N.A. 

Customer Relationship Management (CRM) 6.0 10,572 

Business Information Warehouse (BW) 7.0 52,860 

Process Integration (PI) 7.0 12,334 

Supplier Relationship Management (SRM) 5.0 15,858 

Enterprise Portal (EP) 7.0 26,430 

Global Trade Services (GTS) 7.1 8,810 

Governance, Risk, and Compliance (GRC) 5.3 3,524 

Supply Network Collaboration (SNC) 7.0 10,572 

Business Objects Enterprise 3.1 10,572 

Master Data Management (MDM) 7.0 10,572 

NetWeaver Search and Classification (TREX) 7.0 3,524 

NetWeaver Composition Environment (CE) 3,524 

For the OS/DB migration proof of concept, the customer’s business critical applications – SAP ECC, 

SCM, and liveCache were considered. No other components were migrated. 


11

The following table provides details of the servers in the ECC environment on HP-UX. 

Server Model Operating system 

No. of 

CPUs 

Memory 

(in MB) 

ECCPDBCI ia64 hp server rx8640 HP-UX 11i v2 (11.23) 24 147,258 

ECCPDI 

&ECCPDI1 

ia64 hp server rx8640 HP-UX 11i v2 (11.23) 24 163,641 

ECCPDI2 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,469 





The following table provides details of the servers in the SCM environment on HP-UX. 

Server Model Operating system 

No. of 

CPUs 

Memory in MB 

SCMPDBCI + 

liveCache 

ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 65,469 

SCMPDI ia64 hp server rx8640 HP-UX 11i v2 (11.23) 8 98,171 

SCMPDI2 ia64 hp server rx8640 HP-UX 11i v2 (11.23) 4 16,316 

Database configuration on the HP-UX platform 

The customer’s SAP applications were running on Oracle database version 10.2.0.4. 

HP Serviceguard Solutions provides high availability for the Oracle database. 


12

Vblock System configuration 

The following table describes the Vblock System 700 configuration used for this testing. 

Component 

Cisco UCS 

Storage 

Storage area network 

Configuration 

UCS B200-M2 blade servers – (4) 2 x Quad Core with 96 GB RAM 

UCS B250-M2 blade servers – (4) 2 x Quad Core with 192 GB RAM 

EMC Symmetrix VMAX 2 Engine base –112 number 15K FC drives and 

32 7.5K SATA drives 

1 FC switch - Cisco MDS 9506 64 ports 

1 Ethernet switch 

1 virtual switch - Nexus 1000V 

SAP server configuration on Vblock System 700 

This section provides the configurations of the SAP systems that are part of the migration effort. 

The following table describes the ECC environment on Vblock System 700. 

Server type Server Hardware OS vCPU 

Memory 

(in GB) 

Physical ECCPDBCI UCS B250 M2 RHEL 5.5 N/A 192 

Physical ECCPDBCI Failover node UCS B250 M2 RHEL 5.5 N/A 192 

Virtual ECCPDI1 UCS B250 M2 RHEL 5.5 4 48 







13

The following table describes the SCM environment on Vblock System 700. 

Server type Server Hardware OS vCPU 

Memory 

(in GB) 

Virtual SCMPDBCI and liveCache UCS B250 M2 RHEL 5.5 4 48 

Virtual SCMPDBCI failover node UCS B200 M2 RHEL 5.5 4 48 

Virtual SCMPDI1 UCS B200 M2 RHEL 5.5 4 48 

Virtual SCMPDI2 UCS B250 M2 RHEL 5.5 4 48 

SAP database storage configuration on Vblock System 700 

The following table details SAP database storage on Vblock System 700. 

System 

Total IOPS 

IOPS/sec (based on 

8x7 time frame) 

Database 

size (GB) FC (95%) SATA (5%) 

SCM 106692228.2 529 303.74 4.59 0.73 

ECC 1817228262 9014 2606.97 78.18 12.35 

The following table details the drive configuration. 

Drive type Size Drive speed RAID level 

FC Drive 450GB 15000 RAID-10 

SATA Drive 1TB 7200 RAID-6+2 


14

Summary comparison of Vblock Systems and customer’s HP 

configuration 

The following table provides an SAP ECC hardware layout comparison between HP and Vblock 

Systems. 

Server type Server HP platform Vblock Systems 

Database layer Server type HP Integrity Superdome UCS B250-M2 

RX8640 

Configuration 24 cores with 192 GB RAM 12 cores with 192 

GB RAM 

OS/DB HP-UX 11.23/Oracle 10.2 RHEL 5.5/Oracle 

10.2 

Number of DB servers 2 (physical) 2 (physical) 

SAPS on DB server 42288 52960 

Application layer Server type 

HP Integrity Superdome 

RX8640 

Virtual machine on 

B200-M2 

Configuration 8 cores with 65 GB RAM 4 vCPU with 48 GB 

RAM 

OS HP-UX 11.23 RHEL 5.5 

Total SAPS on app servers 42288 (physical) 47910 (virtual) 

Number of app server 

instances 

6 6 

Total SAPS on app server 

instances 

42288 (physical) 47910 (virtual) with 

35% of CPU usage 


15

The following table provides an SAP SCM hardware layout comparison between HP and Vblock 

Systems. 

Server type Server HP platform Vblock Systems 

Database layer Server type HP Integrity Superdome 

RX8640 


UCS B250-M2 


RAM 

OS/DB HPUX 11.23/Oracle 10.2 RHEL 5.5/Oracle 

10.2 

Number of DB servers 2 (physical) 2 (virtual) 

SAPS on DB server 14096 (physical) 15970 (virtual) 

Server type 

HP Integrity Superdome 

RX8640 


B200-M2 

Application 

layer 


RAM 

OS HPUX 11.23 RHEL 5.5 

Number of App server 2 (physical) 1 VMware ESXi 

Total SAPS on App servers 7048 (physical) 15970 (virtual) 

Number of App server 

instances 

Total SAPS on App server 

instances 

2 (physical) 2 (virtual) 

7048 (physical) 15970 (virtual) 

SAP systems sizing considerations 

For any SAP system, the basic metric for sizing is the SAPS. The SAPS provided by the HP platform 

was considered the basis of the sizing. The customer’s HP-UX platform was an HP Superdome 

RX8640. 

The following are the SAPS calculations based on the SAP certification: 

§ Total SAPS certified for RX8640 server with 32 CPU: 28,200 

§ SAPS/core: 881 

§ The UCS server platform has Cisco UCS B200-M2 and B250-M2 blade servers. 

§ Total SAPS certified for the Cisco UCS B200-M2 blade server with 24 CPU: 26,480 

§ SAPS/core: 1,103 

Based on the current capacity on the HP-UX platform, the same capacity was provided on the Vblock 

System 700 to provide the same number of SAPS. 


16

For the SAP DB or application servers that are running on the virtual platform, SAPS are calculated as 

follows: 

§ Total number of SAPS available on UCS B200-M2/B250-M2: 26,480 

§ Total number of SAPS available for better performance with 65% of CPU and considering 10% 

VMware overhead: 26,480 x 0.65 x 0.9 = 15,490 

Server 

No. of 

CPUs 

Memory 

(in MB) 

Total 

SAPS 

Blade 

# 

# Cisco 

UCS 

M2 

blade Type SAP server Hardware 

ECCPDBCI 24 147,258 21,144 1 1 Physical ECCPDBCI UCS B250 M2 

ECCPDI + 

ECCPDI1 

24 163,641 21,144 2 1 Physical ECCPDBCI 

Failover 

node 

UCS B250 M2 

ECCPDI2 8 65,469 7,048 3 0.45 Virtual ECCPDI1 UCS B250 M2 





8 65,468 7,048 5 0.45 Virtual ECCPDI6 UCS B200 M2 

SCMPDBCI 8 65,469 7,048 6 0.45 Virtual SCMPDBCI 

and 

liveCache 

SCMPDI 8 98,171 7,048 7 0.45 Virtual SCMPDBCI 

Failover 

node 

UCS B250 M2 

UCS B200 M2 

SCMPDI2 4 16,316 3,524 7 0.23 Virtual SCMPDI1 UCS B200 M2 

4 16,316 3,524 6 0.23 Virtual SCMPDI2 UCS B250 M2 

The following sizing was performed and represents best practices: 

§ To use the advantages of the virtualization that is provided on Vblock Systems, all SAP 

application servers were sized on virtual servers. 

§ The ECC database was sized on the physical blade servers based on the customer’s 

requirement. 

§ The SCM database was sized on the virtualized servers. 

§ The liveCache application and its MaxDB database were sized on the virtual servers. 

§ Storage sizing was performed using the two-tier sizing method from EMC. 


17

Migration best practices 

The POC migration was performed as a best practice to lower the migration risk of moving from a 

physical environment to a Vblock Systems virtualized environment. These migration steps 

demonstrate recommended best practices. 

SAP OS/DB migration is performed based on the SAP standard process known as heterogeneous 

system copy. SAP standard tools are used to perform the OS/DB migration. 

This section provides the step-by-step procedure. The migration involves five major phases. 

Phase 

Task 

1 Prepare the source system. 

2 Export the source system database. 

3 Prepare the target system. 

4 Import the database into the target system. 

5 Perform post-migration activities. 

For more details on the specific steps, refer to the SAP documentation for heterogeneous system 

copy, available at www.sdn.sap.com. 

Preparing the source system 

Perform the following steps to prepare the source system: 

Step 

Action 

1 Download SAP media. 

2 Execute pending updates. 

3 Delete QCM tables. 

4 Delete entries from tables. 

5 Upload tools. 

6 Update database parameters. 

7 Increase table space. 

8 Perform complete database backup. 

9 Run SMIGR_CREATE_DDL. 

10 Disable archive log mode and redo logs mirroring. 

11 Mount the NFS share. 

12 Verify /tmp file system. 

13 Obtain root level access. 


18

Downloading SAP media 

Verify that all required DVDs for the system copy are available: 

§ Installation master DVD 

§ Java DVD 

Executing pending updates and deleting canceled updates 

In transaction SM13, check for pending or cancelled requests in the system. If cancelled or pending 

updates exist, you must update them again, or delete them from all clients. You can find out whether 

canceled or pending updates exist by checking if the VBDATA table contains any entries. 

Deleting the QCM tables 

Before the export, delete the QCM tables from your system. Before deleting these tables, always 

check that the: 

§ Tables are consistent. No restart log or conversion procedure termination must be displayed. 

§ Data of the original table is readable. 

Note: If application programs that use the affected original table do not run correctly, do not delete the QCM 

table yet. 

Deleting all entries from tables TATGPC and TATGPCA 

Check to make sure that the TATGPC and TATGPCA tables are empty before exporting the source 

system. 

Updating R3load, R3ldctl, and R3czchk in the Kernel directory 

The SAP migration process uses the following tools. Update these tools to the latest available 

versions before starting the migration process: 

§ R3load—Unloads and loads ABAP table data from and into the database 

§ R3ldctl—Unloads ABAP dictionary structures from the database 

§ 

R3czchk—Computes the size of ABAP tables and indexes for the target database and 

computes the ABAP related size for the target database 

Updating the database parameters for sessions and processes 

Update the database parameters for sessions and processes on the source system, following SAP 

recommendations. These factors affect the data export from the source system. 


19

Increasing the table space for PSAPTEMP 

Increase the table space for PSAPTEMP to avoid any unload terminations during the export process. 

PSAPTEMP is the database storage unit that is used for the sorting. R3load exports data in the 

primary key order. More temporary databases disk space is required for sorting. 

Performing the complete database backup 

Perform a complete database backup to safeguard the changes made for the export preparation. 

Regular backup methods are followed. 

Running the program SMIGR_CREATE_DDL as a batch job 

Run the SMIGR_CREATE_DDL program as a batch job in the background. This step is mandatory 

before exporting the data from the source system. 

This program allows the copying of database objects that do not correspond with SAP standards. 

These objects include partitioned (fragmented) tables and bitmap indexes. Special .SQL 

files are generated for these objects. These files contain native DDL (create) statements and can be 

analyzed by R3load. 

Turning off the archive logs and redo logs mirroring 

Disable the archive log mode and redo logs mirroring to avoid any space issues during the export 

process. Use only one redo log member per redo group. 

Mounting the NFS share with required size for the export dump 

Separate storage is provided to store the export dump. This storage is mounted as an NFS share on 

the source system. 

Checking the /tmp file system 

Check that the /tmp file system exists. Verify that this system has adequate space as required for the 

SAPinst during the export process. 

Obtaining root-level access in the source system 

Root access is needed to perform the export process on the source system. 


20

Exporting the source system database 

Perform the following steps to export the source system database: 

Step 

Action 

1 Start the export preparation process in the source system. 

2 Prepare to split tables. 

3 Start the database export (ABAP+JAVA). 

Starting the export preparation process in the source system 

Run SAPinst to perform the Export Preparation service. 

1. Start the SAP INSTALLER. 

2. Select System Copy > Oracle > Source system export > Central system > system based on 

AS ABAP and AS JAVA > Export Preparation. 

As soon as the export preparations have completed successfully, the complete export directory with 

its structure and the generated files that are required for building the target system are transferred to 

the export dump directory. The dump directory and its subdirectories and files are accessible for 

adm of the target system. 

Preparing to split tables 

The processing unit for one unload/load process is a package. During the standard system copy 

process, all tables of the SAP system are grouped into packages, and all tables with the same data 

class belong to the same package. The packages differ in the number and size of contained tables, 

resulting in varying unload or load runtimes. Creating packages of the same size can reduce the 

overall runtime. To create packages of the same size and runtime, split the default packages into 

smaller segments. You must perform the table splitting preparation by splitting the large tables to 

parallelize more R3load processes. 

1. Set the home to /home/adm. 


3. Select System Copy > Oracle > Source system export > Central system > Based on AS 

ABAP and AS JAVA > Table splitting preparation. 


21

4. Set the following general parameters for table splitting: 

- SAPSID 

- File with Tables to be split 

- Export Directory 

- Number of parallel R3ta run 

- Database type (Oracle)_ 

5. Select the table splitter option. The option for this migration is R3ta table splitter. 

6. Type the number of WHR files for each table. 

The table splitting preparation is successfully completed. 


22

Starting the database export (ABAP+JAVA) 

To start the database export: 


2. Select System Copy > Oracle > Source system export > Central system > Based on AS 

ABAP and AS JAVA > Database and Central Instance Export. 


23

3. Provide the SAP profile directory of the source system. Typically, this directory is 

/sapmnt/SAPSID/profile. 

4. Select the method for copying the database content. The Use database specific tools option 

must be unchecked. 

5. Provide the export location for the database export. This location is typically a local directory or an 

NFS share. 

6. Confirm the execution of the report, SMIGR_CREATE_DDL: 

a. Provide the location for the SQL file directory. You can place the directory in any temporary 

directory. 

b. The option Yes, use the generated SQL files for the system copy must be checked. 

7. Set the system parameters for the source system database. 


24

8. Provide the Java splitting parameters. 

9. Provide the export parameters. For the Target Hardware Platform parameter, select Little- 

Endian. 

10. Provide the unload options for the database export. 

Unload Options: -loadprocedure fast. 

11. Select the option to run the database statistics updates. In this case, we have chosen to omit the 

statistics. 


25

12. Update before the export. 

13. After you have finished setting the parameters and options, a summary window opens. Confirm 

all of your options. Click Next. The export process begins. 

The source system database is now successfully exported. 


26

Preparing the target system 

Perform the following steps to prepare the target system: 

Step 

Action 

1 Install the prerequisites for SAP on Linux systems. 

2 Install Java 1.4.2 IBM version. 

3 Adopt OS-level parameters required for Linux systems as recommended by SAP. 

4 Validate the SAP and Oracle file systems. 

5 Enable the third-party security software to create the system users. 

6 Install the Oracle binaries and perform the database patching. 

7 Mount the NFS file system, which contains the export dump. 

8 Create the migration key. 

9 Adopt the database parameters for the processes and sessions, and increase SGA. 

Installing all the pre-requisites for SAP on Linux systems 

Install all the RPMs that are required by SAP according to SAP Note 171356. 

Installing Java 1.4.2 IBM version 

Install the Java 1.4.2 version as required by the SAP installation. 

Adopting OS-level parameters required for Linux systems as recommended by SAP 

Adopt the OS-level parameters that are recommended by SAP. 

Validating the SAP and Oracle file systems 

Validate the file systems that are required by the SAP installation. 

Enabling the third-party security software to create the system users 

Enable the BoKS software, which is required by the customer to create the system users. 

Installing the Oracle binaries and performing the database patching 

Install the Oracle software. Update the database and install any required patches. 


27

Mounting the NFS file system, which contains the export dump 

Mount the NFS file system, which is used in the export process as export dump. 

Creating the migration key 

Generate the migration key at http://service.sap.com/migrationkey. Type the installation number of the 

source system when prompted. 

Adopting the database parameters for the processes and sessions 

Change the database parameters on the target system as recommended by SAP. These parameters 

affect the data import into the target system. 

Importing the database into the target system 

Perform the following steps to import the database into the target system: 

Step 

Action 

1 Install SCS and ASCS on the virtual hosts. 

2 Import the database on the virtual hosts. 

3 Install the central instance using Java dump. 

4 Install the application servers. 

Installing SCS and ASCS on the virtual hosts 

1. To install SCS and ASCS on the virtual hosts, start the SAPinst. 

2. Select System Copy > Oracle > Target System Installation > Distributed System > Central 

Services Instance (SCS). 


28

3. Set the parameter mode to Custom. 

4. Provide SAP System parameters, such as: 

a. SAP SID of the target system. 

b. System mount directory location. Ensure that Unicode System is checked. 

5. Review the prerequisites checker. If there are any severe errors, take the necessary action to 

resolve them. 


29

6. Click Next. 

7. Provide the SCS instance parameter for SCS Instance Number. Typically, this parameter is set 

to 00. 

8. Provide the SCS instance parameter for Internal SCS Message Server Port. 

9. Accept the default setting of 3900. Accept the SCS instance number selected in step 7. 

10. Provide the software packages and the location. 

11. Provide the directory locations where you have stored your installation media. 

12. Select the archives that need to be unpacked for the installation. Check all of the checkboxes. 

13. After you set the parameters and options, a summary window opens. Confirm all of your options 

and click Next. The installation process begins. 

The installation of the SCS instance is successfully completed. 

Importing the database on virtual hosts 

1. Start the SAPinst and select System Copy > Oracle > Target System Installation > 

Distributed System > Database Instance. 

2. Provide the software packages and the location where you have stored your installation media. 

3. Provide the JDK directory. 

4. Provide the JCE policy files archive location. 

5. Provide the SAP system profile directory. This directory is typically /sapmnt/SAPSID/profile. 

6. Provide the master password for all users that SAPinst creates during the installation. 


30

7. For Installation Method, select Standard System Copy/Migration (load-based). 

8. Set the database parameters for the target system database. The database SID should be the 

same as the SAPSID you selected in earlier steps. 

9. Provide the location of the source system database export directory. This is the location where 

you stored the export from the source system database. 

10. Provide the database system parameters. 

a. Set the password for the database users. 

b. Provide the media location for the database installation. 

c. Provide the Oracle listener configuration parameter. Typically, this parameter is set to 

LISTENER_SAPSID;. 

d. Leave the other options at the default values. 


31

11. Select the Oracle advanced configuration parameters. 

12. Provide the database instance file systems: ORACLE_HOME, ORACLE_STAGE and sapdata 

home Directory. 

13. Provide the SAP data paths. Ensure that there are a minimum of four SAP data paths. 

14. Provide the database specific information shown in the following figure. 


32

15. Provide the table space parameters. The following table lists the sizes used in this case. 

Table space 

SAPDATA volume 

File size 

(GB) 

Number of DB 

files 

Total size (GB) 

PSAPSR3 SAPDATA1 20 46 1000 





PSAPSR3DB SAPDATA3 20 1 20 

PSAPSR3USR SAPDATA4 20 9 180 

PSAPUNDO SAPDATA3 20 4 80 

SYSAUX SAPDATA3 10 1 10 

SYSYEM SAPDATA3 10 1 10 

PSAPTEMP SAPDATA4 20 15 300 


16. Provide the database control file information. Oracle best practices recommend three separate 

control files. 

17. Provide the general load parameters for the database import. 

Important: The migration key is intentionally incorrect, in order to pause the import after the database 

creation. This procedure helps tune the target database and improve the import performance. 

18. Select the option to update the database statistics at the end of the import. 


33

19. Provide the location of the database media for the installation. 

After you set the parameters and other options, a summary window opens. Confirm all of your 

options and click Next. The installation process begins. 

20. When the system is ready for the database installation, the SAPinst stops and displays a prompt 

to start the database installation. 

Complete the database installation and return to SAPinst. 

21. When the database installation is complete, click OK on the SAPinst to resume and complete the 

installation. 

The installation is now complete. 

Installing the central instance using Java dump 

1. On the SAPInst, select Software Life-Cycle Options > System Copy > Oracle > Target 

System Installation > Distributed System > Central Instance. 


34

2. Provide the software package location you set up in previous steps. 

3. Provide the Profile Directory location. Typically, this location is /sapmnt/SAPSID/profile. 

4. Type and confirm the SAP Master Password. 

5. Set the Oracle Listener Configuration. 

6. Type the Central Instance Number. Typically, this number is 01. 

7. Accept the default Central Instance parameter values. 

8. Provide the location of the software packages. 

9. Type and confirm the J2EE Engine Administrator (j2ee_admin) password. 

10. Type the Secure Store user (administrator) and password. 

11. Select the Interrupt the installation before start of system checkbox. 

12. Type the DDIC, client 000 password. 

13. Provide the location of the Oracle kernel and Oracle client software packages. 

14. Select any desired archives. 

15. Provide the SAP Solution Manager Key. Refer the to SAP documentation for information about 

how to get a solution manager key. 

16. Install the Diagnostics Agent. 


35

The installation successfully completes. 

Installing the application servers 

Install the application servers for the target system using the SAPinst tool. The installation procedure 

is available in the SAP installation guides at the SAP site. Use the link located in the References 

section of this paper. 

Performing post-migration activities 

Perform the following post-migration activities: 

Step 

Action 

1 Fine tune the database parameters. 

2 Start SAP. 

3 Run the installation check. 

4 Install the license key. 

5 Reconfigure Java, memory tune-up, and test. 

6 Import the profiles. 

7 Start the application servers. 

8 Reconfigure the STMS and change the hostnames. 

9 Change all of the RFC destinations. 

10 Execute the program RS_BW_POST_MIGRATION. 

11 Perform TEMSE consistency check and cleanup. 

12 Configure the logon groups. 

13 Perform a complete backup. 


36

Fine tuning the database parameters 

Follow the SAP recommendations to tune the database parameters based on the target system 

database. In this scenario, the target system database is Oracle. 

Starting SAP 

1. Log on to the target SAP system host. 

2. Start the SAP Database and instance. 

Running the installation check 

Run the installation check on the target system using transaction SICK. 

Installing the license key 

After the installation of the target system is complete and the SAP system copy has been imported, 

you must install a new license key. 

Reconfiguring Java, performing memory tune-up and testing 

Reconfigure the Java parameters, using SAP Note 831812. 

Importing the profiles 

Import the profiles in transaction RZ10 by selecting Utilities > Import Profiles > of active servers. 

Start the application servers 

1. Start the application server instances. 

2. Check the server instances in transaction SM50. 

Reconfiguring the STMS and changing the hostnames 

Configure the Transport Management System (transaction STMS). If you did not change the SAPSID 

during the system copy, all of the open transport, repair, and customizing requests that have not been 

released in the source system will not be released automatically. 

Changing all the RFC destinations 

In transaction SM59, change the destinations to the new host. 


37

Executing the program RS_BW_POST_MIGRATION 

Execute the program RS_BW_POST_MIGRATION in the background by using variant 

SAP&POSTMGR. Program RS_BW_POST_MIGRATION performs necessary modifications on 

database-specific objects, mainly BI objects. 

Performing TEMSE consistency check and cleanup 

Using transaction SP12, check the consistency of the Temporary Sequential Objects (TemSe). 

Search for files of TemSe objects for which no TemSe objects exist. Then delete the objects as 

necessary. 

Configuring the logon groups 

Configure the logon groups using the transaction SMLG. 

Performing a complete backup 

Perform a complete backup of the system before allowing it to be used. 


38

Solution validation 

This section describes the solution validation and test results. 

Test environment 

The test environment was set up using HP LoadRunner 9.2. 

Test objectives 

The test objective is to compare the Vblock System 700 with the HP-UX environment. This test was 

performed in two major categories: 

§ SAP performance testing 

§ Operational efficiency of Vblock Systems 

Various tests were conducted on an SAP database, central instance, and application server 

configuration comparable to the large semiconductor company’s production configurations. 

Performance testing was compared to performance test results from the semiconductor company’s 

production P08 and P04 systems. P08 is the SAP Production Planning system. P04 is the SAP 

(Delta) Materials Management production building block. 

Testing included these categories: 

§ Virtualized SAP application server layer 

§ SAP workload balancing using DRS 

§ On demand scaling of SAP application servers 

§ Online response times tests and batch throughput 

§ Stress tests using HP LoadRunner to test Vblock Systems capacity limits 

§ Reliability and redundancy of server, storage, and network components 

§ Dynamic resource allocation using UIM 

§ Migration of various components 


39

The following table details the test sets that were performed. 

Test 

Objective 

Migrate and run SAP ECC, SCM, 

and liveCache on Vblock Systems 

Demonstrate that SAP 

performance on Vblock Systems 

meets or exceeds current 

benchmarked performance KPIs 

Demonstrate that the highly 

available system meets or exceeds 

the current SLA 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

Using standard SAP OS/DB migration tools, the VCE team 

migrates the SAP landscape from the source environment to 

the Vblock System 700, transporting the data using an 

external NAS device or network. 

Deploy SAP Applications ECC and SCM using Adaptive 

Installation Best Practices. Configure the systems to enable 

connectivity to a large semiconductor manufacturing 

company’s Adaptive Computing Controller. 

Apply SAP best practice recommendation for tuning for 

optimum performance. 

Demonstrate complete functionality of SAP ECC and SCM 

systems by logging into the systems and executing a few key 

basis and sample business transactions. 

Using standard SAP OS/DB migration tools, the VCE team 

migrates the SAP landscape from the source environment to 

the Vblock System 700, transporting the data using an 

external NAS device or network. 

The highly available solution for the SAP systems database: 

SAP CI and DB high availability with Red Hat Linux Cluster 

suite (Active, Active solution). 

The highly available solution for the application servers: 

Multiple DIA and BGD instances on virtual machines 

distributed on separate ESXi servers. 

Demonstrate stateless computing § Demonstrate that hardware failure and recovery matches or 

exceeds existing system. Demonstrate the provisioning of a 

UCS blade on the Vblock System 700, using the service 

profile in case of a blade failure. 

The above tests were performed using various tools and techniques. Only Vblock Systems and SAP 

standard procedures and methods are used to perform benchmarking. 

SAP performance testing 

SAP performance testing includes two major components: 

§ Interactive performance testing (Dialog Transactions) 

§ Batch processing 

Interactive performance testing 

For this testing, HP LoadRunner was used to simulate production load (1,200 ECC Dialog Users + 

Batch Runs + SCM Batch Jobs + Batch Runs) on the SAP Vblock System. The average transaction 

response times were compared to the service levels provided with the AMAT EWR. 


40

The following metrics were among those monitored during the test: 

§ Average CPU time 

§ Memory 

§ Average response time 

§ Throughput 

§ Average wait time 

§ Average load time 

§ Database calls 

§ Database request 

Batch processing 

To identify capacity limits, batch workload was simulated to significantly increase the workload on the 

system. In addition to the analysis of the LoadRunner results, usage statistics were gathered at all 

infrastructure levels (OS, Hypervisor, Storage, and Network) during the runs. 

Tests 

This section provides details about the tests that were conducted. 

Test 1: Migration 

Migrate and run SAP ECC, SCM, and liveCache successfully on Vblock Systems. 

Test 

Test 1a 

Test 1b 

Test 1c 

Test 1d 

Description 

Using standard SAP OS/DB migration tools, migrate the SAP landscape from the 

source environment to the Vblock System 700, transporting the data using an external 

NAS device or network. 

Deploy SAP Applications ECC and SCM using Adaptive Installation Best Practices. 

Configure the systems to enable connectivity to a large semiconductor equipment 

manufacturing company’s Adaptive Computing Controller. 

Apply SAP best practice recommendation for tuning for optimum performance. 

Demonstrate complete functionality of SAP ECC and SCM systems by logging onto the 

systems and executing a few key basis and sample business transactions. 


41

Using best practices, migrate SAP landscape and data to Vblock System 700. Demonstrate 

improvement running on Vblock Systems. 

SAP layer Customer’s SAP on HP SAP on Vblock System 700 

DB Oracle Oracle 

OS HP-UX 11.23 RHEL 5.5 

ECC DB server HP Integrity Superdome RX8640 – 

24 cores, 192 GB RAM 

UCS B250-M1 – 12 cores, 

192 GB RAM 

SAPS on DB server 21,144 26,480 

ECC application servers 

6 X HP Integrity Superdome RX8640 

– 8 cores, 65 GB RAM 

6 x 4 cXPU with 48 GB vRAM 

(hosted on 3 ESXi servers) 

Total SAPS on application 

servers 

42,288 SAPS (physical) 71,496 SAPS (virtual) 

LoadRunner N/A V9.1 

Test 2: Performance 

Demonstrate that performance of the SAP system on Vblock Systems meets or exceeds the current 

benchmarked performance (KPIs). Using standard SAP OS/DB migration tools, the VCE team 

migrates the SAP landscape from the source environment to the Vblock System 700, transporting the 

data using an external NAS device or network. 

Vblock Systems versus PO8 (quarter end) transaction response times 


Transactions Vblock Systems (seconds) PO8 (quarter end) (seconds) Percent gain 

VA01 0.465 1.251 63 

VA02 0.315 1.298 76 

FAGLB03 0.229 2.1 89 

MMBE 2.1 1.905 -10 

KE30 0.953 2.28 58 


42

Vblock Systems versus PO8 (active) transaction response times 


Transactions Vblock Systems (seconds) PO8 (active) (seconds) Percent gain 

VA01 0.465 1.281 64 

VA02 0.315 1.358 77 

FAGLB03 0.229 1.753 87 

MMBE 2.1 2.211 5 

KE30 0.953 4.417 78 

Average response time improvement on Vblock Systems versus P08 


43

KPI - CPU Performance 

KPI – Network performance 


44

Test 3: Availability 

Demonstrate that the highly available system meets or exceeds the current SLA and the availability of 

the current system. 

Test 

Test 3a 

Test 3b 

Description 

The high availability solution for the SAP systems database: SAP CI and DB 

high availability with Red Hat Linux Cluster suite (Active, Active solution) 

The high availability solution for the application servers: Multiple DIA and BGD 

instances on virtual machines distributed on separate ESXi servers 

Test 4: Stateless computing 

Demonstrate stateless computing, in which hardware failure and recovery matches or exceeds the 

existing system. Demonstrate the provisioning of a UCS blade on the Vblock System 700, using the 

service profile in case of a blade failure. 

Number of 

benchmark 

users 

Average 

dialog 

response 

time (sec) 

Dialog 

steps per 

hour 

SAPS 

Central server 

(*) additional 

specifications Processors Cores 

Fully 

processed 

line items 

per hour 

3,200 0.92 1,055,000 17,580 UCS B200 M1 2 8 351,670 

4,852 0.99 1,589,000 26,480 UCS B200 M2 2 12 529,670 

Test results summary 

This section summarizes the results of a proof-of-concept OS/DB migration of SAP from a physical 

environment running HP-UX to the Vblock System 700 running Red Hat Linux in a virtualized 

environment. Test results include performance, stress, and batch job processing test results. 

Performance testing results 

§ Vblock System 700 performed 50% better compared to HP-UX. 

§ Average CPU of HP-UX production was 42.2%. 

§ Average CPU on Vblock Systems was 17%, under the same load. 

Stress testing results 

§ At 42% CPU usage, HP-UX supported an active user count of 150 and logged-on user count of 

1,200. 


45

Highly available system - LR scenario: 1,200 total users, 150 active, production batch load 

§ At 43% CPU usage, the Vblock System 700 supported an active user count of 250 and loggedon 

user count of 1,800. 

§ At 100% CPU usage, the Vblock System 700 supported an active user count of 350 and loggedon 

user count of approximately 2,500. 

SCM–OM17 Batch job testing results 

§ 38% performance improvement on the Vblock System 700 compared to the HP-UX platform. 


46

Conclusion 

The traditional method of sizing for SAP landscapes on physical servers is to size for the worst-case 

demand scenario. This practice is known to have significantly higher initial capital acquisition costs 

and ongoing operational costs that are decreasing business agility and increasing business risks. 

This paper alleviates concerns of execution risks and provides guidance to customers who choose to 

re-platform their SAP landscapes to an x86-based architecture and take advantage of lower capital 

acquisition costs and virtualization to improve agility. 

The goals for this POC and the results outlined in this paper were to: 

§ Show that best practices were used to successfully complete the SAP migration to the Vblock 

System 700. Explain how customers can use the same best practices to perform their migration. 

§ Provide the collected testing and monitoring results data associated with the migration that also 

demonstrates running the applications on the Vblock System 700. 

§ Compare performance of a Vblock System 700 to a customer environment. 

Best practice techniques were used in sizing the application and database servers, storage and filesystem 

layout. These techniques help remove the guesswork that typically drives such efforts. These 

best practices involved right-sizing of the Vblock System 700 at compute, storage and network layers. 

In this POC, it was demonstrated that by using the Vblock System 700: 

§ Performance improved 50% or more when running SAP on the Vblock System 700, compared 

with a semiconductor equipment manufacturer’s environment. 

§ 50% less hardware was used compared to the customer’s environment. 

§ The migration risk was low when moving from an HP-UX based physical environment to a 

Vblock Systems virtualized environment. 

§ Fast recovery of failed application and database server blades was possible with UIM and UCS 

service profiles. 

§ The Vblock System 700 provided increased scalability to dynamically add resources. 

§ High availability and live migration were achieved through vMotion. 

Next steps 

To learn more about this and other solutions, contact a VCE representative or visit www.vce.com. 


47

References 

Refer to the following sources for supporting and additional information: 

Note: To access SAP documentation on the SAP Service Marketplace, SAP requires that you register and 

have a user ID and password. Contact SAP to set up your user ID. 

§ SAP documentation for heterogeneous system copy 

www.sdn.sap.com 

§ SAP installation guides 

www.Service.SAP.com 


48

ABOUT VCE 

VCE, formed by Cisco and EMC with investments from VMware and Intel, accelerates the adoption of converged infrastructure and 

cloud-based computing models that dramatically reduce the cost of IT while improving time to market for our customers. VCE, 

through the Vblock Systems, delivers the industry's only fully integrated and fully virtualized cloud infrastructure system. VCE 

solutions are available through an extensive partner network, and cover horizontal applications, vertical industry offerings, and 

application development environments, allowing customers to focus on business innovation instead of integrating, validating, and 

managing IT infrastructure. 

For more information, go to www.vce.com. 

Copyright 2013 VCE Company, LLC. All Rights Reserved. Vblock and the VCE logo are registered trademarks or trademarks of VCE Company, LLC and/or its 

affiliates in the United States or other countries. All other trademarks used herein are the property of their respective owners. 

© 2013 VCE Company, LLC. All Rights Reserved.

SAP OS/DB Migration from HP-UX Platform to Vblock Systems - VCE

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?