At the SAP Inside Track in Newtown Square on 10th August 2012, I performed the first ever SAP NetWeaver BW 7.3 migration to SAP HANA, running on a Mac Mini.
I’m going to re-run this session online at https://sap.na.pgiconnect.com/miniappleby on Wednesday 5th September at 9am PST, midday EST, 5pm BST or 6pm CET, for those that missed it – and hopefully make it run perfectly!!!
Correction – it will now be at 8am PST, 11am EST, 4pm BST or 5pm CET, to avoid a conflict with the Steve Lucas webinar on BW on HANA!
The recording is now available: https://sap.na.pgiconnect.com/p25952529/
The project had started off a month or so earlier when I had proclaimed to Rich Heilman, rather enthusiastically, that I would do a live BW on HANA migration during his community conference. One late night later after dinner with a BI leader colleague, I ended up in the Apple Store in Covent Garden, London. Some hours later I had a Mac Mini all over the sofa, in pieces, as I upgraded it to 2 SSDs and 16GB RAM.
From there, I had rather assumed that life would be easy. So I got my IT department to setup a SAP NetWeaver BW 7.3 EhP1 system and created a migration copy – called an “installation export”, and copied it over the internet (about 2 hours each time).
It turns out that installing SAP HANA on a Mac Mini is easy. It readily runs SuSe Enterprise Linux for SAP Applications and SAP HANA installs with minimal hassle, apart from disabling the hardware check (Google this if you need to know how). HANA starts up just great.
The fun comes when you go to migrate BW onto a Mac Mini. Linux needs 2GB RAM, HANA uses 6GB RAM, the BW installer uses 2GB RAM and so you have 6GB RAM available for the database. Trust me, it’s not big enough and you get memory errors when loading BW. Here’s what I went through!
1) 2nd Mac Mini: BW Central Instance
I stole a Mac Mini from my office and upgraded it to 4GB RAM, and used it as the SAP BW central instance. This saves 2GB RAM from the Mac Mini and it’s not enough!
2) Killing Services
You can kill services like the XS engine and the Statistics Server when BW is installing and this gives a few GB free RAM back.
3) Unloading Column Tables
You can write a script to unload Column Tables, but not Row Tables. It turns out that it’s the uncompressed Row tables that cause the pain and they fill up the HANA system. You can’t unload Row tables from SAP HANA and things like the ABAP repository alone take up several GB. Sucks!
4) 3rd Mac Mini: Distributed Database
Well if 2 Mac Minis aren’t good enough then let’s have 3! I bought another Mac Mini from the Apple Store in Ardmore and upgraded it to 16GB RAM thanks to MicroCenter. Then I created a NFS Server on the first Mac Mini, created mount points and installed a distributed instance of SAP HANA, spanning 2 nodes of 16GB. Total of 32GB!
5) Table Distribution
It turns out that BW on SAP HANA behaves in an interesting way, when installed into a distributed instance – for performance purposes. The master node (first system) holds the row tables, and then the column tables are shared amongst the slave nodes. So the master node filled up again! I found there was a setting which causes this which is set when BW is installed. You have to pause the installer, unset this option and restart SAP HANA before continuing.
It turns out that the installer for SAP HANA performs optimally when you create the database export with a ton of parallel files. This makes sense because SAP HANA does work best when there is massive parallelism. On a Mac Mini this equates to needing 100-200 export files so you can max out the CPU.
It also turns out that I think there’s a good reason why the Row Store is configured to run on the master node: row tables running on slave nodes seem to be much slower of room reason. I’ve no clue why that is, but the Row Store is rarely used so I think this would be a moot point in practice.
I like how it looks like only 7 steps here but it took at least 50 attempts to get SAP HANA running on a Mac Mini. What’s really interesting is that all my problems related to either the RAM available on the Mac Mini, regular migration issues like tables splitting or hardware problems like bad RAM. SAP HANA was 100% stable throughout – she never crashed for any other reason. I think this is really impressive on unsupported hardware, an unsupported configuration, using 1/8th of the minimum RAM normally required.
This sort of stuff takes ages. It was an attempt at the impossible and I had a lot of fun. And SAP HANA runs great on a Mac Mini, provided you don’t need to use a lot of RAM, which is what caused all my problems. If you have a Test & Demo license for SAP HANA then go ahead and install it!