Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Thursday, March 27, 2014

HowTo: Check HANA LM Is Running

Scenario: You want to check if the SAP HANA Lifecycle Manager is running/installed.

The SAP HANA Lifecycle Manager is installed separately the HANA DB and runs in its own Java VM.
It's installed by default into the "/usr/sap/hlm_bootstraps" directory and occupies ~700MB of disk space.

By default the HLM is not usually started with the instance.  It gets started when you call it from the HANA Studio, or if you manually start it from the Linux command line using the script located in "/usr/sap/hlm_bootstraps/<SID>/HLM".

From HANA Studio, right click the HANA instance as SYSTEM, then select "Lifecycle Management":


From the command line on the Linux server, as the <sid>adm Linux user:

> cd /usr/sap/hlm_bootstraps/H10/HLM
> ./

You will be dropped into the OSGI (Open Service Gateway Interface, see here: command line.

Monday, March 24, 2014

Why SAP Learning Hub Is Great Value

I run my own company and I am primarily a BASIS guy, secondarily a DBA.
With the launch of SAP HANA, the new In-Memory DB platform from SAP, I decided that I needed to prove my skills with this popular new technology before it takes off mainstream.

Being in control of my own training plan means that I can see the issues large companies have.
Training is not cheap when you factor in the cost of the training, the overnight hotel stays, breakfasts, evening meals and car fuel, plus you have to pay the employee for the day.
Advances in technology mean you can now complete some training online.  This is obviously sacrificing the usual face-to-face interaction and dynamism you get in a classroom, but if you are a capable learner (you need a specific technique), then you can benefit from the flexibility of online learning.

SAP launched the Learning Hub primarily to provide a method of easily selecting and following a training plan or certification path.
Secondly, the Learning Hub provides the perfect place to manage and distribute online training content.

Let's get to the point:
How does it compare cost-wise with classroom based training?  Well here's how I worked it out:
(Certification C_HANATEC131 proposes that courses HA100 and HA200 should be completed.)

- SAP HANA HA100 classroom cost:  £1040.
- SAP HANA HA200 classroom cost:  £2600.
- Travel & overnight stay costs (for me): £120 per night = ~ £840
- C_HANATEC131 certificate exam: £350

TOTAL for classroom training & certification exam: £4830.

Compare the above total to the Learning Hub method that I used:

- 12 months subscription to SAP Learning Hub:  £2400.
(Courses HA100E and HA200R are in the catalogue)
- Travel & overnight stay costs (for me) one night: £120
- C_HANATEC131 certificate exam: £350

TOTAL for SAP Learning Hub online training & certification exam:  £2870.

As you can see, the Learning Hub route gave me much better value.

And the best is still to come...
With the 12 months subscription, I get access to ALL of SAP eLearning courses.
Not only can I now choose another set of courses, but should I decide to certify on another topic, I just need to pay for the exam and I've saved money yet again.

There must be a downside?
Not necessarily.  It does mean that you have to be a certain type of learner.  You need a learning technique that suits you and a method of time control that stops learning overload.
Being my own boss means I can take time to train in-between contracts, but you could also perform your training online in the evenings.

My method:
- Find the certification exam you want to complete, on

HANA Training - Find the certification exam on

- Expand the "Topic Areas" section on the page and you will see the topic course recommendations on the right.

HANA Training - Expand the topic areas

- Print the page with the areas expanded, so you can see the "%" of relevance to the certification exam.

- Use the Learning Hub to access the online version of the required/recommended training courses.
These usually also include a PDF document with the course content.
Don't forget to include the install and upgrade guides if relevant.

- Upload the PDF(s) to your tablet for a little easy reading when lounging (or when you have some dead time).

- Write key concepts on Post-It Notes and stick them somewhere you look at regularly (a wall maybe).

Don't move them once stuck, because this helps you visualise them in your mind whilst learning.
You'll come to know exactly on the wall where certain notes are.  That's because you've remembered them with the associated place on the wall.

- Write notes in a book or notepad as you go through the learning material.
Don't write long paragraphs and definitely copy down diagrams, it helps reinforce the picture contents.

- Review and revise often.
You don't need long, maybe 20 minutes.
Sometimes, just staring and going through the Post-It Notes will help them stick.

- Look up any acronyms you don't know.

- Don't be too concerned with the test exams, they are not very accurate or good quality.
When you think you're ready, book your exam.  You can always re-take it if you have been unsuccessful.

Good luck.

Thursday, March 20, 2014

HowTo: Disable HANA Web Dispatcher

Scenario: The SAP HANA Web Dispatcher seems to be automatically running in HANA 1.0 SPS70.  I am supposing that this is mainly for the XS-Engine.

If you have already removed the XS-Engine (see my post here), then you can also disable the Web Dispatcher as follows (this will save around 300MB of memory).

From HANA Studio, change the daemon.ini configuration parameter "sapwebdisp -> instances" to "0" for your host(s):

HANA sapwebdisp instances

Restart the HANA instance.
The Web Dispatcher process will be no longer present:

HANA processes no sapwebdisp

No more Web Dispatcher.

Thursday, March 13, 2014

HowTo: Install HANA Lifecycle Manager

Scenario:  You've followed my previous post on how to install a basic HANA DB and now you would like to install HANA LM into the same instance so that you can patch HANA and perform other LM tasks.

What you will need:
- A working HANA DB instance.
- The HANA installation media (usually an ISO file).

This will take less than 10 minutes if you already have the install media.
I have already converted the HANA install media DVD into an ISO file so that I can easily mount it as a virtual cdrom in a VM.
If you haven't converted the install media to an ISO, you can always upload the media directly, or if you're working in a VM, you can use the Shared Folders functionality to share a folder directly from the host O/S to the guest SUSE Linux VM.

Mount the ISO as a cdrom (I'm using a Virtual Machine as my SUSE HANA server).

On the cdrom you will have a directory containing the installation media for the HANA LM tool:


As the root Linux user, run the installation tool (note: your HANA system can be shutdown during this process, especially if you have a low amount of memory):

# ./hdbinst

SAP HANA Lifecycle Manager installation kit detected.

SAP HANA Database Installation Manager - SAP HANA HLM Installation
  SAP HANA system ID | Description
  H10                | SAP HANA Database H10

Enter SAP HANA system ID [H10]:

Root user password. Mandatory for Distributed system with not configured Trusted SSH Connectivity, or                    else not applicable. [""]:

Root user SSH passphrase. Optional for Distributed system with configured Trusted SSH Connectivity, or                    else not applicable. [""]:

Checking installation...
Preparing package "SAP HANA lifecycle manager"...
Installing SAP HANA Lifecycle Manager to /hana/shared/H10/HLM...
Installing package 'SAP HANA lifecycle manager' ...

Installation takes approximately 10 minutes.

From HANA Studio, you can now open the Lifecycle Manager:

SAP HANA Lifecycle Manager install

Monday, March 10, 2014

Analysing High SAP Roll Wait Time - NW702

One of my clients identified an increase in the Response Time measurements they monitor.  They use the EarlyWatch Report to monitor the SAP system SLAs against response time performance.
I initially thought this was going to a be a nice easy assignment, identify the database performance issues and propose some reorganisation work.  After all, this does seem to be the case in ~75% of the cases I've seen.

Basic info: SAP NW 702 on Oracle 11gR2 on Unix.
SLAs are monitored against DIALOG response time from 9am to 6pm weekdays only.

I brought up the ST03 screen and checked the "Ranking Lists -> Top Response Time of Dialog Steps" (also known as the Hit List) for the past 3 month's data, one month at a time.
All three months showed a similar pattern.  The worst performing reports were customer developed reports.  The database time looked reasonable (< 40% of Response Time - Wait Time), processing time was long-ish and load/gen time was tiny.
What didn't look good was the "Roll Wait Time".

I backtracked a step and looked again at the "Workload Overview", and specifically tab "Parts of response time":

MWSnap101 2014-01-02, 09_55_04

That's right, 26% of the response time for Dialog, is Roll Wait time.
Time to dig out the definition of SAP Roll Wait Time...
I've blogged about the basic performance tuning steps before, but I've yet to deep dive into the Roll Wait Time metric.

What is "Roll Wait Time".
SAP note 8963 says:
"The roll wait time is time that elapses on the client while the user context is in the roll area. Therefore, no resources are used on the client and there is no bottleneck here if the roll wait time is long. "
So we may not be looking at a problem with the SAP server, but a problem between the SAP application and the front-end.
The note goes on to state that for DIALOG processing, the roll out of the context can be caused by calls to other external applications from the R/3 system, or from a call to an external RFC.
More importantly, it says:
"As of Release 4.6, roll wait times also occur when the R/3 system communicates with the controls in the front end. While the data in the front end is processed, the R/3 context is rolled out, and the work process is released as a result. This may occur several times during a transaction step. If front-end office applications (such as Microsoft Word) are started and only closed after a long time (more than several minutes), a very long roll wait time also occurs."
This means that the communication to the front-end (SAP GUI, Microsoft Excel, Word etc), can cause the DIALOG work process to roll out, subsequently increasing the "Roll Wait Time".
Even further clarification is provided in SAP notes 364625 and 376148 which mention the "new" GUI controls introduced in R/3 4.7.
SAP note 606610 explains how an ABAP "WAIT" command causes a task to roll-out of the work process.

SAP note 203924 provides some more detailed information on high Roll Wait Time:
"As of Release 4.6 the roll wait time (and therefore the total response time) contains the time for installing "Enjoy Elements" (=controls) and therefore the essential part of the communication between the GUI and the R/3 instance. In this case, the response time displayed in Transaction ST03 is closer to (almost identical to) the time experienced by the user."
Plus it also confirms what we're thinking:
"As of Release 4.6, therefore, a high roll wait time is a first indication of a slow network between the GUI and the R/3 instance."
Section 2a of the note provides some good pointers in diagnosing network performance issues and checking the size of the SAP user menus.

As per the note, I opened up transaction ST06 and via the "Detailed Analysis" button, I went to the "LAN Check by PING" screen, then clicked "Presentation Server":

 MWSnap104 2014-01-02, 10_57_13

MWSnap105 2014-01-02, 10_57_22

MWSnap106 2014-01-02, 11_02_32

Once here, I selected a random selection of "Presentation Server" clients and initiated a 10x PING.
What I found was that specific "Presentation Servers" (client PCs) were not responding within the expected 20ms:


I knew that we were operating in a WAN environment (multiple offices across different cities) so I should be expecting a WAN connection time of between 50ms and 250ms (according to SAP note 203924).
I was seeing ~60ms in some cases.  So I can conclude that we have a moderately quick WAN setup.
The main point is that I was not seeing any packet loss.  Which is a good sign.

Whilst the immediate data is always good to see, it's worth mentioning that the speed could be circumstantial.  It's best to check the times in our ST03 statistics.  Opening up ST03 again and navigating to the "Workload Overview" analysis view, I can see on the "Times" tab, an "Average GUI Time per Dialog Step" of 90.4ms:


round trip

  GUI Time

GUI Time:  Measured at the Application Server, this is the average time taken for all requests (of a Dialog step) to go from the Application Server to the front-end SAP GUI (it does not include the time taken for the SAP GUI to send data to the Application Server).
The time I see is not too bad and will vary depending on the amount of data sent.

We can verify the value by checking the "Average Front-end Network Time" (per Dialog step):


  Front End Network Time

Front-end Network Time:  Measured at the SAP GUI, we see that the Front-end has recorded an average of 91.4ms time taken for the first request (of a Dialog step) to go from the Application Server to the front-end SAP GUI, plus the time taken for the last request (of a Dialog step) to go from the Application Server to the SAP GUI plus the processing required on the front-end for screen formatting.  This roughly agrees with our network finding of 60ms ping time (with no GUI processing at all), which means that on average, we're probably seeing ~30ms of time for the SAP GUI to perform it's rendering.

Based on the above findings I can rule out networking as being a probable cause to the high Roll Wait Time as it seems to be (on average) pretty normal.  Although I could recommend to my client that they use the "Low Speed Connection" setting in the SAP GUI as this is recommended by SAP in WAN setups (see SAP note 203924 section 4).  It's also possible I could recommend reverting to the Classic Theme in the GUI.  Also recommended in the mentioned note.

SAP note 62418 discusses the typical amount of data sent per Dialog step in SAP ECC 6.0.  Around 4.6KB is to be expected (per Dialog step).  It doesn't state if that is a normal connection setup or using the "Low Speed Connection" setup.
We can also look at the relationship of GUI Time to Roll Wait Time.  There's something there that doesn't look quite right.

If I go back to the Workload Overview, I can see that for DIALOG tasks, the "Average GUI Time" is 90.4ms, which should be almost equal to the "Roll-out" + "Roll Wait" + "Roll In" (these happen whilst the GUI is doing it's stuff - during RFC).

Except, in my case, I can see that the GUI (plus the time to talk to it) is doing it's stuff much quicker than the Application Server is rolling out and waiting (NOTE: We've had to drag the columns around in ST03 and we're on the "All Data" tab):


0.4 + 147.7 + 15.8 = 163.9ms.

This is 163.9 - 90.4 = 73.5ms slower (on average, per Dialog step) than I would have expected!
This is ~12% of the response time (the Roll Wait Time is ~26% of the response time).

These are the possible reasons I considered to explain this:
  • Bad network performance.  We've looked at this and we can see that GUI Time is actually pretty normal.  Why would waiting around take longer than the time to do something.  Network performance seems good.
  • Lack of dialog work processes.  No it can't be this, because this would not be attributable to Roll Wait Time, but instead would be measured as Dispatcher Queue Time (also known as "Wait Time" without the word "Roll").
  • Longer time to  Roll In and Roll Out.  It's possible that Roll In and Roll Out time could affect the calculations.  I'm seeing average Roll In time (per dialog step) of 15.8ms and Roll Out time of 0.4ms.  But this still doesn't add up to 73.5ms.
  • Time taken to initialise and open the RFC connection to the SAP GUI.  It's possible that the network lookup/hostname buffer is slow to get going before we manage to open the connection to the SAP GUI, but 75ms is pretty slow.
I needed to get out of the aggregated data and into the real nitty gritty.
I needed transaction STAD and some real live data.

Opening STAD, I left the default options with a read time of 10 minutes ago.
Once the records were displayed, I changed the layout of the screen to remove fields I wasn't interested in, I then added fields I was interested in:
- Started
- Server
- Transaction
- Program
- Type
- Screen
- Work Process
- User
- Response Time
- Roll Wait
- GUI Time

Once I had the screen setup, it was a simple case of scanning through the records looking for any that had "Roll Wait" > "GUI Time" with 0 "RFC+CPIC".

I found some!
One of the records (shown below) has a huge "Roll Wait" time of around 5 seconds, yet "GUI Time" is zero:


It just so happens that at the same time as this STAD record was created, I was also running an Enqueue Trace, SQL Trace and Buffer Trace from transaction ST05 (yeah, it was a quiet day so I felt confident that dipping in and out of tracing wouldn't hurt performance too bad).

So I had an opportunity to display these traces for the same period of time (and the same Work Process number).
I found that there were no long durations in the entire trace.  In fact, the total duration of the trace period didn't add up to even 1 second.  What!

Sorting the trace by the "Time" column and manually scrolling through looking for the 5 seconds between one row and the next and sure enough, I found it.  The missing 5 seconds:



I single clicked the first record after the time gap, and because it was an ABAP program, I was able to click the "Display Call Positions in ABAP Programs" button:



The source code position that I arrived at didn't seem to be doing anything other than an OPENSQL statement, so I scrolled back up the program a little.
Then I saw it.  The program was moving UNIX files around.  Not only that, but there was an ABAP command "WAIT UP TO 5 SECONDS.":



Here's what the ABAP syntax help says:
"This statement interrupts the execution of the program by the number of seconds specified... ... after the specified time has passed, the program continues with the statement following WAIT."
It also states:
"Each time the statement WAIT is used, a database commit is performed.  For this reason, WAIT must not be used between Open SQL statements that open or close a database cursor."


We've seen how "GUI Time" is measured and checked the network performance stats to see how accurate it is.
We've also learned how "GUI Time" is actually related in some ways to the value of the "Roll Wait Time".

It's been a long hard slog to get to the bottom of why I have a high average "Roll Wait Time" shown in ST03, when the average "GUI Time" is much lower.  A hardcoded ABAP statement was causing my work processes to WAIT for a fixed period of time, increasing the overall Response Time reported in ST03.  We referenced SAP note 606610 at the beginning of our article, but it seems very difficult to actually find out (without going through ABAP source) if a WAIT statement is has been the cause of Roll Wait Time.

We have subsequently learned that the ST03 Dialog Response Time measurements should be taken lightly, and that you should always try to exclude "GUI Time" by using the "Response Time Distribution" analysis view and clicking the "Dialog Without GUI Time" button.  This will exclude the "Roll Wait Time" as described in SAP note

During my investigation, I also found a few other things.

We were actually suffering from the program error described in SAP note 1789729, so there is some potential to get better performance from the system by eliminating the additional database & buffer calls.

Some of the records in STAD contained HTTP records.
When I analysed these, I could see that certain document related transactions were calling out to the SAP HTTP Content Server to access documents.
I managed to calculate that the "Call Time" for the HTTP access, was recorded as "Processing Time" in the overall Response Time.
So, if you use a Content Server, be sure to check the response times, as this could also be a factor in slower response times, and this wasted time *is* recorded in the overall Response Time.
Obviously, using SSL will make this process slightly slower, so maybe some form of front-end cache would be better.

Thanks for reading.

Thursday, March 06, 2014

HowTo: SAP NW731 Java Full HTTP Trace With Headers Content & Timings

Scenario: You have a SAP Java stack which is hosting either some SAP components/modules, or it's hosting your own custom Java code.
You would like to perform a full HTTP trace so that you can see the HTTP headers and returned content during a HTTP session between your browser and the SAP HTTP Server.  You also wish to see timings for the processing time of the response.
Following SAP note "724719 - How to enable HTTP tracing in the SAP J2EE Engine 6.40/7.0"  connect into the SAP Netweaver Administrator main web page as J2EE_ADMIN:
On the left-hand side, select "System Properties":
SAP NWA System Properties
Select the dispatcher item under "<SID> -> Instance -> Dispatcher":
SAP NWA System Properties despatcher
On the Services tab, select "http":
SAP NWA System Properties despatcher http service
In the "Properties" tab at the bottom, select "HttpTrace" and click the "Modify" button:
SAP NWA System Properties dispatcher http service httptrace
Now change the trace setting to the following:
SAP NWA System Properties dispatcher http service httptrace enable
The possible values are described in the SAP note as:
         Using this option will cause the whole requests/responses to be written
        Using this option will cause only the headers of each request/response to be written
        Using this option will cause the whole requests/responses to be written in a 16-column hexadecimal format. This option is valid for J2EE Engine SP10 or higher
        Using this option will cause only the headers of each request/response to be written in a 16-column hexadecimal format. This option is valid for J2EE Engine SP10 or higher
The SAP note also recommends to set the property HttpTraceTime, to "true".
This is described further in SAP note "972540 - Tracing dispatcher and server response times".
Since you would only get the dispatcher processing time, you should also set the server trace property as described in the above note, to allow you to see the server processing time:
"1) dispatcher + server processing time trace in http access log
- On the dispatcher enable Http Provider#s property #HttpTraceTime#
- On the servers enable Http Provider#s property #LogResponseTime#
Then messages in the httpaccess response file will contain additional fields  d[...] and c[...] where d is dispatcher and server processing time and c is client id.
2) additional traces - if the request is processed for more than XX seconds
- there is a new Http Provider#s property on the server # #TraceResponseTimeAbove#
- if its value is -1 then there will be no additional traces
- if its value is >-1 (the value represents the response time in ms)
    then additional traces will be written in the default trace file only for these requests which response time is >= property#s value
- on the servers put the log severity for HttpProvider service to DEBUG
Once you have enabled the tracing, no restart of the Java stack is required.  It is activate immediately.
Simply check the trace output file /usr/sap/<SID>/<instance>/j2ee/cluster/dispatcher/log/services/http/req_resp.trc  (for NW731+) using operating system level file viewers (or AL11 in an ABAP stack).
For information, you should be aware of the HTTP 1.1 status codes, so you know what to look for if you are tracing an authorisation error (HTTP authorisation) or some other HTTP related issue .

Monday, March 03, 2014

HowTo: Install SAP HANA into a VM in less than 30minutes

Scenario: You want to prototype something and you don't have the hardware available for a new prototype HANA database.  Instead, you can use the power of a virtual machine to get a HANA SPS07 database up and running in less than 30 minutes.
Well, it was supposed to be 30 minutes, and it sure can be 30 minutes, providing you have the right equipment to hand.
As I found out, working on a slow disk, limited CPU system, extended this to 2 hours from start to finish.
Here's how...

Update: 09/2014, if you're using SPS08 (rev 80+) then this will also work, but people have had issues trying to perform the install with the media converted to an ISO.  Instead, just use the VMWare "Shared Folders" feature to share the install files from your PC into the SUSE VM.

What you'll need:
- SAP HANA In Memory DB 1.0 SPS07 install media from SAP Software Download Centre.  This is media ID 51047423.
- The SUSE Linux for SAP v11 sp02 or sp03 install media (ISO).
- A valid license for the HANA database (platform edition or enterprise edition).
- SAP HANA Studio rev 70 installed on a PC which can access the virtual HANA server you're going to create (the Studio install media is contained within the HANA install media DVD, or you can download it separately).
- A host machine to host the virtual machine.  You need at least 20GB of RAM, although if you configure your pagefile (in Windows) on SSD or flash, you could get away with 16GB (I did !!!).

What we're going to do:
- We'll create a basic SUSE Linux for SAP virtual machine.  You can use any host OS, I'm using Windows 7 64bit.
- Because most people are using VMs to maximise infrastructure, we'll go through a couple of steps to really reduce the O/S memory footprint (we disable X11 as one of these steps).  We get this whole thing running in less than 16GB of RAM in the end.
- We'll install a basic HANA database.
- We disable the XS-Engine (saving a lot of memory) which you don't have to do if you absolutely need it.  The XS-Engine is a lightweight application server for hosting the next generation HANA based APPS.


Create your basic VM for SUSE Enterprise Linux (I'm using SUSE Linux for SAP SP2).
It will need the following resources:
- More than 16GB of RAM (preferably 24GB) on the physical host machine .
- 8GB of disk for the O/S.
- 50GB of disk for the basic HANA DB with nothing in it, plus the installed software.
- 20GB of disk on the physical host  for swapping (if you don't have 20GB of RAM).
- 2 CPUs if you can spare the cores.
- A hostname and fully qualified domain name.
- Some form of networking (use "Bridged" if you need to access this across the network).

Let's create the VM and set the CDROM to point to the SUSE Linux SP2 install DVD ISO file:

Create HANA VM with SUSE ISO

Confirm the VM full name, your username and your preferred password (for the username and for root):

HANA VM gets a full name

Set the location to store your VM files:

HANA VM files location

Set the initial hard disk to have 8GB and store it in one big file (it's up to you really):

HANA VM needs 8GB for SUSE

Now customise the hardware:

HANA VM needs more hardware

Set the RAM to 20GB or more (you really need 24GB of RAM, but I have only 16GB and will be ready for some serious swapping).  At a minimum the VM should have 18GB of RAM for day-to-day running:

  HANA VM needs 20GB RAM

Give the VM at least 2 cores:

HANA VM needs more than 2 cores

Use bridged networking if you need to access over the network, but only if you have DHCP enabled or you're a network guru:

HANA VM needs networking

Start the VM.

We're off.
The SUSE install took 12.5 minutes in my testing on a core i5 (unfortunately only 3rd gen :-(  ):

SUSE install progresses

Oh look, it reckons that we have 12mins 19 seconds left until completed:

SUSE packages installed 12mins remain.

Boom, SUSE is up!


Shutdown the VM again so that we can add the second hard disk:

HANA VM second hard disk is added

SUSE HANA VM second hard disk
SUSE HANA VM new virtual disk

It's SCSI as recommended:

SUSE HANA VM scsi disk

We set it to max out at 50GB (set yours however large you think you will need it, but we will create this in a volume group so you can always add more hard disks and just expand the volume group in SUSE):


NOTE: If you're going to be moving this VM around using USB sticks, you may want to choose the "Split..." option so that the files might fit.

Give the VMDK a file name (I've added "HANADB" so I can potentially plug and play this disk to other VMs):

SUSE HANA VM vmdk name

Also re-add the CDROM drive (mine went missing after the install, probably due to VMWare player's Easy Install process):


Configure the CDROM to point to the ISO for the SUSE install DVD again.
Start the VM again:


Notice the Kernel version we have is 3.0.13-0.27:


From the bottom bar in SUSE, start YAST and select the "Network Settings" item:

SUSE HANA VM network settings

Disable IPv6 on the "Global Options" tab:

disable IPV6

On the hostname tab set the hostname and FQDN:

SUSE HANA VM set hostname and fqdn

Apply those changes and quit from YAST.
Right click the desktop and open a Terminal:

SUSE HANA VM terminal

Add your specific IP address and hostname (fqdn) plus the short hostname to the /etc/hosts file using vi:

SUSE HANA VM hostname and fqdn setup

Save the changes to the file and quit vi.

Reboot the HANA VM from the terminal using "shutdown -r now".
Once it comes back up, you need to check the hostname resolution:

SUSE HANA VM check hostname

According to the HANA installation guide I'm following, we need to apply some recommended settings following SAP note 1824819:

SAP note 1824819

So we run the command to disable the transparent huge pages:

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

I checked the C-state and it was fine on my Intel CPU.

We're not using XFS so I don't need to bother with the rest, I don't want to patch my GlibC, but feel free to if you wish.


A quick recap, we should have working SUSE VM, it should be booted and you should have the SUSE DVD loaded in the virtual CDROM.

Open a new Terminal window:

SUSE HANA VM terminal

Now install the following Java 1.6 packages from the source distribution (these are part of the HANA install guide for sp07, page 15):

# cd /media/SLE-11-SP2-SAP-DVD-x86_640025/suse/x86_64

# rpm -i --nodeps java-1_6_0-ibm-*

The rest of the requirements are already installed in SUSE EL 11 sp2 for SAP.

Now we create the volume group for the HANA database and software.
First check which disk you're using for the O/S:

chekc disk for HANA OS

So, I'm using "sda" as my primary disk.
This means that "sdb" will be my HANA disk
WARNING: Adjust the commands below to the finding above, so you use the correct unused disk and don't overwrite your root disk.

Create the new partition on the disk:

# fdisk /dev/<your disk device e.g. sdb>

Then enter:

n <return>
p <return>
1 <return>
t <return>
1 <return>
8e <return>
w <return>

At the end, the fdisk command exits.

Re-run fdisk to check your new partition:


Create the volume group and logical volume:

# pvcreate /dev/sdb1
# vgcreate /dev/volHANA /dev/sdb1
# lvcreate -L 51072M -n lvHANA1 volHANA

Format the new logical volume:

# mkfs.ext3 /dev/volHANA/lvHANA1

Mount the new partition:

# mkdir /hana

# echo "/dev/volHANA/lvHANA1 /hana ext3 defaults 0 0"   >> /etc/fstab

# mount -a

Check the new partition:

# df -h /hana

Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/volHANA-lvHANA1   50G  180M   47G   1% /hana

Create the required directory locations (H10 is out instance name):

# mkdir -p /hana/data/H10  /hana/log/H10  /hana/shared

Now set the LVM to start at boot:

# chkconfig --level 235 boot.lvm on

Now we've got somewhere to create our HANA database and put the software.
To perform the HANA install, I've converted my downloaded HANA install media into an ISO file that I can simply mount as a CD/DVD into the VMware tool.
Instead of this method, you could alternatively use the Shared Folders capability and simply extract the file to your local PC, sharing the directory location through VMware to the guest O/S.  The outcome will be the same.

Mount the ISO file (HANA install media, from which I've created an ISO for ease of use).
You can do this by presenting the ISO file as the virtual CDROM from within VMWare.

Open the properties for the virtual machine and ensure that you select the CDROM device:


On the right-hand side, enable the device to be connected and powered on, then browse for the location of the ISO file on your PC:


Apply the settings to the VM.

Prior to starting the install, we can reduce our memory footprint of the O/S by over 1GB.
Use vi to change the file /etc/inittab so that the default runlevel is 3 (no X-windows):


Also, disable 4 services that are more than likely not needed and just consume memory:

Disable VMware thin printing:
# chkconfig vmware-tools-thinprint off

Disable Linux printing:
# chkconfig cups off

Disable Linux auditing:
# chkconfig auditd off

Disable Linux eMail SMTP daemon:
# chkconfig postfix off

Disable sound:
# chkconfig alsasound off

Disable SMBFS / CIFS:
# chkconfig smbfs off

Disable NFS ( you might need it...):
# chkconfig nfs off

Disable splash screen:
# chkconfig splash off

Disable the Machine Check Events Logging capture:
# chkconfig mcelog off

Double check the IP address of your VM:
# ifconfig | grep inet


Your IP address should be listed (you can see mine is
If you don't have one, then your VM is not quite setup correctly in the VMWare properties or your networking configuration is not correct, or you don't have a DHCP server on your local network, or your network security is preventing your VM from registering it's MAC address.  It's complex.

Assuming that you have an IP address, check that you can connect to the SSH server in your VM using PUTTY :


Enter the IP address of your VM server:


Log into the server as root:


From this point onwards, it is advisable to use the PUTTY client tool to connect, as this provides a more feature rich access to your server environment, than the basic VMWare console connection.
You now need to restart the virtual server:

# shutdown -r now

Once the server is back, re-connect with PUTTY.
We will not use the GUI for installing the HANA system (hdblcmgui), because this takes more time and more memory away from our basic requirement of a HANA DB.
Mount the cdrom inside the SUSE O/S:

# mount /dev/cdrom /media

Change to the install location inside the VM and then run the hdbinst tool (this is the lowest common denominator regarding HDB installation):


# ./hdbinst --ignore=check_diskspace,check_min_mem

You will be prompted for certain pieces of information.  Below is what was entered:
Installation Path:   /hana/shared
System ID:             H10
Instance Number: 10
System Administrator Password:  hanahana
System Administrator Home Dir:  /usr/sap/H10/home
System Administrator ID:  10001
System Administrator Shell:  /bin/sh
Data Volumes:  /hana/data/H10
Log Volumes:   /hana/log/H10
Database SYSTEM user password:   Hanahana1
Restart instance after reboot:  N

Installation will begin:


My HANA DB install took approximately 1 hour 20 minutes on a Core i5 with 16GB RAM, 5400rpm HDD (encrypted) plus a large pagefile (not encrypted):

Snap653 2014-02-27, 12_47_56

******  OPTIONAL ********
After the install completed, I then followed SAP note 1697613 to remove the XS-Engine from the landscape to reduce the memory footprint even further:
From HANA Studio, right click the system and launch the SQL Console:


Run the following SQL statements (changing the host name accordingly):

select host from m_services where service_name = 'xsengine'
select VOLUME_ID from m_volumes where service_name = 'xsengine'
ALTER SYSTEM ALTER CONFIGURATION ('daemon.ini', 'host', 'hana01') UNSET ('xsengine','instances') WITH RECONFIGURE
ALTER SYSTEM ALTER CONFIGURATION ('topology.ini', 'system') UNSET ('/host/hana01', 'xsengine')  WITH RECONFIGURE

NOTE: Change the value "<NUM>" below to be what is reported as the volume number in the second SQL statement above.

ALTER SYSTEM ALTER CONFIGURATION ('topology.ini', 'system') UNSET ('/volumes', '<NUM>')  WITH RECONFIGURE

The XS-Engine process will disappear.
You can now restart the HANA instance using HANA Studio.


This completes the HANA DB install.
At the end of this process you should have a running HANA database in which you can execute queries.
It's possible you can reduce the VM memory allocation to 16GB and the HANA instance will still start (if you remove the XS-Engine).
You should note that we don't have the HANA Lifecycle Manager installed.  You'll need to complete this if you want to patch this instance.  However, for 15mins work, you can re-install!

NOTE: Consider SAP note 1801227 "Change Time Zone if SID is not changed via Config. Tool" v4.   The default timezone for the HANA database doesn't appear to be set correctly.
You can also check/change the Linux O/S timezone in file "/etc/sysconfig/clock".