on 11-01-2012 2:36 PM
Hi guys,
I hope some experieced users can help me out with this Hardware migration
Currently there is a R/3 4.7 system running under a IBM DB6 8.0 and SUSE Linux 32-bit
The goal is to copy that same R/3 4.7 system into a Red Hat Enterprise 5 64-bit and with DB6 9.7, since we need to upgrade that system to ERP 6.05
Any comments, suggestions, recommendations to follow regarding how to accomplish this?
Thanks!
Hi Martin, a quick question aside from the main point of your post: why are you looking at moving to RHEL 5.x? 6.x is the current stable release of RHEL that's supported by SAP, so given you're doing a big upgrade anyway why not move to the current stable branch? This will mean you're supported on that version of RHEL through to 2020 (for RHEL 6.x) as opposed to 2017 (for RHEL 5.x) according to the PAM.
Note also that to move to the EXT version of the SAP kernel will require you to be on RHEL 6.x anyway, and that version of the kernel is sometimes required as you move to later versions of other parts of your software stack.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John,
Many thanks for your valuable info regarding RHEL 5.x since as you mentioned is not compatible for
DB2 9.7 and Kernel 720_EXT 64-bit UC.
We are now planning to migrate first RHEL 5.x to 6.x.
Regarding Kernel 720_EXT 64-bit UC, is this release the new standard for SAP system and Kernel 7.20 64-bit UC is no longer supported
Since for ERP 6.0 EHP 5, Kernel 7.20 64-bit UC is listed as compatible, but for ERP 6.0 EHP6 is no longer listed.
Is there any SAP Note regarding this?
That's essentially correct Martin, yes. This is because installing EHP6 usually requires moving to NetWeaver 7.03 (7.0 EHP3)/7.31 (7.3 EHP1), which are actually effectively the same thing on the ABAP stack. These versions of NetWeaver require moving to the 720_EXT kernel, which as you say requires RHEL 6.x.
This is an example of what I was saying when I talked about this version of the kernel being required for some combinations of software, hence why I would recommend making the jump to RHEL 6 if undertaking such a large upgrade anyway.
Sources:
Check page 11 of the Upgrade and Update Guide for EHP6 as an example to see that it's based on NW7.03.
1591607: 7.20_EXT kernel required on NW 7 EHP3 or NW 730
1678024: RHEL 6.x min Linux version to use 720_EXT kernel variant
1563102: Linux Requirements for 7.20 EXT kernel (again RHEL 6.x required)
HTH,
John
Thanks Again John with you valuable input.
Regarding this migration, you may help me out sheding some light.
Since we are now installing RHEL 6.x and DB2 v9.7 we may need a take a different roadmap with extra mid-steps from our actual OS/DB/SAP to our target system.
Our Initial plan is to install actual version of SAP into a new OS/DB RHEL6/DB2 v9.7, and from this point start with Application upgrade
A SAP consultant replied on a message its not possible to install SAP R/3 Enterprise 47x200 with a 720_EXT Kernel, therefore DB2 9.7 would not be compatible
A suggestion would be installing SAP with a previous DB2 Version, then updating latest 720_EXT kernel, and finally DB2 Upgrade to v9.7.
According to PAM, this is the only alternative for SAP R/3 47x200 on DB2 v9.7/RHEL6
DB2 FOR LUW 9.7 64-BIT maintained until see : | LINUX REDHAT EL6/X86_64 64BIT maintained until 11/30/2020 : | SAP KERNEL 6.40_EX2 64-BIT maintained until 03/31/2013 |
Note 1496410 - Red Hat Enterprise Linux 6.x: Installation and Upgrade mentions minimun Patchlevels are the following.
SAP kernel 4.6D_EXT: patchlevel >= 1811
SAP kernel 6.40: patchlevel >= 12
Actual Source system is Kernel 620 Patch 1602,
Is compatible to run actual SAP Version 47x200 with a Kernel 6.40_EX2 64-BIT?
I understand if listed on PAM it is supported, but my question if i can convert a 620 system into a 640_EX2 system
Thanks!
How many downtime business is allowing you to perform this activity.
You can do -
- All in one long downtime (migrate and then SAP upgrade). Risk is if you hit performance issues then you will not be able pinpoint whether caused by migration or upgrade.
- Two downtime - One for migration and another for upgrade. This will help you to test the new hardware and performance testing before upgrade. The upgrade will be fast once you moved your system to new hardware. And this approach will help you to pinpoint the issue whether caused by migration or upgrade.
The migration has to be done by certified SAP migration consultant.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sunil, thanks for the input
We are trying to implement the one-long-downtime scenario.
The major steps we are trying to overcome would be the following
First: Install a R/3 4.7 on Red Hat Enterprise 5.0 with DB2 9.7. Is this possible? I know on PAM this scenario is not listed, therefore we would nee to find out how.
Second: Perform a DB copy from a DB 8.0 (old system) to DB2 9.7 (new system). Any restrictions on this?
Third: Once we have the ERP 4.7running on the new hardware, start the Upgrade from 4.7 to 6.0.
Thanks!
Hi Martin,
If PAM support DB+OS with specific SAP release, osdb migration is possible from any DB+OS combination to other OS+DB combination.Please check in PAM.
Now question is that which tool or copy procedure you will use. This mostly depends on your DB size + planned downtime.
In this caes you have following options :
Option 1 : Use SAPINST to perform export and import ( if you have small database 200 GB)
Option 2: Use Migration monitor if you DB size is 300 GB to 1 TB
Option 3 : Use Distribution Monitor if your DB is more than 1 TB
First try with simple SAPINST and familiar with all processes and logs after gradually explore MigMon or DistMon option.
Keep in mind ( for production system) you need to wait 6-8 weeks time after OSDB migration, since SAP need to perform GOLIVE check. Once SAP completed the GOLIVE check you can do upgrade, untill that no changes.
Regards,
Dipam Phukan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.