SAP Migration from HP IA64 architecture to mixed environment PAS/ASCS on Red Hat and Oracle db on Exadata
it is my first blog, in which I would like to share my experience and my “meeting” with the world of Oracle Exadata. I completed many heterogeneous System Copies in the past, but never on this mixed environment that involves Oracle Exadata
I had to migrate a SAP ECC 6.0 system from an HP IA64 hardware architecture (standard ABAP System) to a new hardware architecture (distributed ABAP System) where:
- ASCS and PAS should run on Red Hat 7.3 server (virtualized)
- Oracle Database should run on Exadata server, composed by two nodes7instances
Some preliminary activities
First of all I read 2195019 and 1635808 notes, because a check should be done for the installation requirements.
I didn’t find the uuidd package on the Exadata machines, so I installed the uuidd-2.17.2-18.104.22.168.el6.x86_64.rpm package (usung yum).
Another important point of attention was the hostname. According to 1635808 note the hostname command must only return the host name and not the Fully Qualified Host name (FQDN).
According to 1996481 note I had to modify the network configuration file of the operating system /etc/sysconfig/network
Another preliminary activity is related to the shared file systems between Exadata machines and PAS+ASCS machines. I usually work with NFS exported file systems, so I used this way for the /sapmnt/ and /usr/sap/trans sharing.
Main tool used for the migration was SWPM 1.0 SP18.
Firts step was the database export from the source system.
I performed this db export during the night and I copied the files using ftp from the IA64 source machine to the Exadata database target machine.
For a 106 GB database the export size was 17 GB (good compression!)
Just a little note about the Endianness: the migration involves a Big-Endian hardware (HP-UX IA64) in the source architecture and a Little-Endian hardware (Intel processor) on the target architecture
SAP System Copy in a Distributed System
The main steps to complete the migration were the following three:
- ASCS Instance installation (on Red Hat virtual machine)
- Database Instance installation (on two nodes of Exadata machine)
- PAS Instance installation (on another Red Hat virtual machine)
ASCS and PAS Instances creation run smoothly, while the critical step was was the Database Instance creation.
Easy “classic” installation that run without any problem.
An important assumption is that SAP environment requires the ORACLE_HOME environment variable to be set to /oracle/<DBSID>/<release>, while the Oracle Exadata deployment install the RDBMS software under /u01/app/oracle/product/22.214.171.124/dbhome_1
So, firts of all, using oracle user I created the following link:
OS>ln -s /u01/app/oracle/product/126.96.36.199/sapdev01 /oracle/SV4/121
I should perform an Hetereogeneous System Copy, so I choose “Standard System Copy”
SWPM offered the option that fit my architecture:
ASM Disk Group Configuration as showed in the image below:
Two instances/nodes are available:
During this migration phase I encountered a critical problem :
Component OraDbBuild: Context parameter dbHome must be a valid ORACLE_HOME directory
SWPM didn’t find the Oracle database software already installed.
I supposed that during the installation of the Oracle database instance the SWPM installer stopped the installation and prompted me to install the Oracle database software, but it didn’t happen….
Using RDBMS Media 51047708 (Oracle 12.1 RDBMS Linux on x86_64 64bit) I completed the Oracle database software installation, following the configuration on Oracle Engineered Systems (188.8.131.52) explained in the note 1521371.
The setting were:
OHRDBMS (runtime Oracle Home) /oracle/SV4/121 (softlink)
IHRDBMS (installation oracle Home) /u01/app/oracle/product/184.108.40.206/sapdev01
Immediately afterwards I patched the Oracle software installing the following SBP:
SBP 220.127.116.11.161018 201611V2 for Exadata
Easy “classic” installation, only some problem with the firewall, because some ports were closed.
Many parameters to be set are the same as the previous screens proposed in the previous procedure steps.
As far as I’m concerned one point of attention in this phase is the database service creation.
Consideration about Database Services creation on Exadata nodes
Previously I chose “One Character” length for the instance number, so the following two db instances for the db called SV4 were available:
- Instance one: SV41
- Instance two: SV42
SWPM asks for Service Name and for the preferred RAC instance.
Setting parameters in this way generates a script called SV4_D00.sh, that must be executed on node 1 (where SV41 instance is running) using oracle user with the right environment.
The service creation command is the following:
$ORACLE_HOME/bin/srvctl add service -db SV4 -service SV4_D00 -preferred SV41 -available SV42 -tafpolicy BASIC -policy AUTOMATIC -notification TRUE -failovertype SELECT -failovermethod BASIC -failoverretry 3 -failoverdelay 5
Similar to node 1 the script must be executed on node 2 (where SV42 instance is running), with the necessary modifications:
$ORACLE_HOME/bin/srvctl add service -db SV4 -service SV4_D01 -preferred SV42 -available SV41 -tafpolicy BASIC -policy AUTOMATIC -notification TRUE -failovertype SELECT -failovermethod BASIC -failoverretry 3 -failoverdelay 5
A consideration about -preferred and -available parameters: the proposed script create the SV4_D00 service that in this way will normally run on the SV41 instance, but will failover to the SV42 instance if SV41 becomes unavailable.
We can consider this as an ACTIVE/PASSIVE failover management.
SAP permits an ACTIVE/ACTIVE failover management too, so considering that the list of preferred instances must be mutually exclusive with the list of available instances I could run the scripts in a slightly different way:
$ORACLE_HOME/bin/srvctl add service -db SV4 -service SV4_D00 -preferred SV41,SV42 -tafpolicy BASIC -policy AUTOMATIC -notification TRUE -failovertype SELECT -failovermethod BASIC -failoverretry 3 -failoverdelay 5
The created database services must be obviously present into the tnsnames.ora file on both PAS and ASCS server.
I performed the typical follow-up activities explained in the “System Copy for SAP Systems based on the Application Server ABAP of SAP netweaver 7.1 to 7.5 on UNIX” SAP Operations Guide.
I found some error in the DB13 transaction, because the SAPXPG_DBDEST_<SAPDBHOST> RFC was not working.
I read the following blog and I set the right communication type, opening the necessary ports: