Steps from BW 7.4 to BW/4HANA – Part 1: BW7.4 to BW7.5 Upgrade

Audience

Although this blog is aimed primarily at Basis consultants interested in performing the BW migration, it is also intended to appeal to a range of SAP consultants and customers interested in getting a better understanding of the steps and effort involved in undertaking such a migration.
I do not explain the detailed steps for performing an upgrade as this can be found in the SAP documentation. Instead I highlight the unexpected issues and errors that came up during the migration of our system from BW 7.4 to BW/4HANA so that you might avoid some of these pitfalls or at least be prepared for them when you come to do your own migration.

Setting the Scene

Our BW system has undergone several significant changes prior to commencing the BW/4HANA journey, including…

• Migration from Sybase ASE to HANA.
• Migration from on premise IBM Power hardware into the cloud onto an AWS instance.
• Additional scale out nodes installed and configured.

This blog is the first of a three part series documenting the steps from BW 7.4 to BW/4HANA which includes

• Version upgrade from BW 7.4 to 7.5 (Blog Part 1)
• Installation of the BW/4HANA starter Add-on (Blog Part 2 https://blogs.sap.com/2016/12/14/steps-from-bw-7.4-to-bw4-hana-part-2-installation-of-the-bw4hana-starter-add-on/)
• Running the conversion process to deliver a BW/4HANA system (Blog Part 3 https://blogs.sap.com/2017/01/24/steps-from-bw-7.4-to-bw4-hana-part-3-running-the-conversion-process-to-deliver-a-bw4hana-system/)

Upgrade from BW 7.4 to 7.5 (Part 1)

I will cover the following areas in part 1 of this blog series…

• Methods of generating the XML file
• Getting the software
• Required resources
• Some of the unexpected issues
• Other tips

Methods of generating the XML file.

Due to an upgrade happening on our Solution Manager system, we had to use the online Maintenance Planner tool rather than our Solution Manager system to determine the upgrade software packages required and generate the XML file.

If you find yourself needing to follow this route, I would suggest firstly checking that your system data in OSS is up to date and that your transfers from Solution Manager have been happening.  Our BW system data was out of date in terms of the patch level being reported as we had to apply some pre-requisite patches to BW prior to the upgrade. So any XML file generated was out of sync with the actual system and rejected by the SUM tool.

You cannot update patch versions yourself in system data. Instead you need to do the following

1.   In transaction SPAM, select Utilities -> Generate system info XML.
2.   Save the downloaded XML to your local machine.
3.   Create an incident with SAP with the component BC-UPG-MP and attach the system info XML.

SAP will update your system data and you can then run the Maintenance Planner tool to generate a valid XML file.

Getting the Software

Once you have run the Maintenance Planner tool, something else to be aware of is that it does not add the Upgrade media to your download basket; you must go and add that manually. The generated XML file does mention this but it is easily overlooked.

I would also recommend patching the kernel to the latest level along with the hostagent and also apply the latest SPAM update before starting. We also had to patch HANA as well.

When you are using a cloud based hosting option you have to factor in the additional steps and time required to transfer the upgrade media, patches etc to your instance.

Required Resources

In every day running we operate the BW system as a 3 node cluster with 90GB of memory allocated across all 3 nodes (30GB on each).  This is to keep costs as low as possible and as this is essentially and internal demo system this works perfectly well for us.  However, under the extra stress of the upgrade, this memory allocation was not sufficient.

SAP suggest that you should have data less than 50% of the memory. So, with a 200GB database we should ideally have 400GB of memory.  In a scale out environment SAP also say your nodes should be the same size, even though generally the worker nodes process more of the workload than the central node.  

A big advantage of using cloud infrastructure is the ability to increase and decrease the size of the instances very quickly and easily as required.  

To facilitate the upgrade we temporarily increased the size of the AWS HANA instances from r3.xlarge to r3.2xlarge. This gave us an increase of 4 to 8 vCPU and 30.5 to 61GiB memory on each node. Once the upgrade was complete this was scaled this back down to r3.xlarge size instances again.

Some of the unexpected issues

We close our AWS instances down overnight when not in use to keep the costs as low as possible. During the upgrade, I would let it get to a point where it stopped for input or reached the end of a phase and then shut it down cleanly.  In doing this however, I discovered that the shadow instance was not always restarted by the upgrade process.  When I restarted the upgrade through the SUM tool I noticed errors in the logs suggesting the shadow instance was not available. So on these occasions I had to start the shadow instance manually following the SAP process for doing so.  

One error I came across was this one…

I found a couple of blogs suggesting repeating the step several times to resolve the error and sure enough after doing this all but one error remained.  The remaining error was related to a custom object which SAP confirmed we could skip.

Another strange error was this one…

The SYSTEM password had somehow become corrupted, this actually happened twice.  After resetting the password and updating SUM with the new password the process continued.

The procedure to reset the SYSTEM password is described in this sap help link…

http://help.sap.com/saphelp_hanaplatform/helpdata/en/df/025d7abb5710148ba8b0ed6476b597/content.htm

Other tips

Other things to be aware include long runtimes for some steps such as SGEN.  If you have available resources you can specify a higher number of processes during the configuration stage that can be used and speed this up a bit, but it can run for several hours.

Another tip is that often you will get long periods of time when the SUM logs don’t get updated and it’s hard to tell if the upgrade is doing anything at all.  Another place to look is under your SUM directory in tmp

/usr/sap/<SID>/SUM/abap/tmp

The logs are written to tmp before being copied to the logs directory so you can often see activity in tmp when it looks like nothing is happening, of course sometimes there isn’t even anything in tmp, so you just have to be patient!

Following the completion of the upgrade step, I handed the system over to our BW consultant Glen Spalding who then completed a series of tests and checks on the system.  Glen’s blog highlights some interesting issues he uncovered…

https://blogs.sap.com/2016/12/08/bw7.4-on-hana-to-bw4hana-migration/

I hope you have found the sharing of our experiences so far useful.

“Installation of the BW/4HANA starter Add-on (Blog Part 2)” is now available via the following link…

Steps from BW 7.4 to BW/4 HANA – Part 2: Installation of the BW/4HANA Starter Add-on