SAP HANA installation

• Certified hardware or certified cloud instances (strict CPU-to-memory ratios).
• A certified Linux distribution with HANA-specific OS tuning.
• Correctly sized memory, the dataset must fit in RAM.
• Properly laid-out data, log and shared file systems.

The one that catches people is memory. HANA holds working data in memory, so sizing is not a performance preference the way it is on a disk database. Undersize it and tables unload, reload on access, and the system behaves erratically rather than simply slowly. Size from the report SAP provides for your source system rather than from a guess.

The rest of the list is unglamorous and each item has stopped an install. Certified hardware or a certified cloud instance type, because HANA is not supported on arbitrary machines. A supported Linux distribution at a supported patch level. Separate file systems for data, log and shared, with the log on storage fast enough for synchronous writes. Kernel and memory parameters set to SAP's values. And the hostname resolvable and stable, because it is written into the configuration.

HANA is installed with its own lifecycle tool (hdblcm), which sets up the HANA instance, system database and (optionally) tenant databases. You define the SID, instance number, and administrative users, and configure memory and persistence. Because HANA is memory-resident, sizing and OS tuning done beforehand are what make or break it.

Naming decisions made here are effectively permanent. The SID and the instance number appear in the port numbers, the file paths, the OS users and every connection string. Changing them afterwards is a rename exercise across the whole landscape, so agree them before the installer runs rather than during it.

One choice on the way through is worth thinking about rather than accepting. The installer offers to create the tenant for you, and taking that option is right on a sandbox and often wrong in a landscape, because the tenant name is what applications connect to and it should follow whatever convention the rest of your systems use. Naming it after the sandbox you happened to build first is a small decision that travels a long way.

• System DB vs tenant DBs: HANA supports multitenant databases (MDC).
• In-memory + persistence: data lives in RAM but is persisted to disk (data + log volumes) for durability.
• Column store: the default for analytics-friendly performance.

The one to be clear on at install time is system versus tenant. The system database holds the landscape-level configuration and the tenants hold the actual data, and they have separate administrators, separate backups and separate connection ports. Connecting to the wrong one is the most common early confusion: you log in successfully, and the tables you expect are not there because they live in a tenant.

Two more terms come up on day one. Multitenant is the default arrangement, so even a single tenant system has both databases and both sets of credentials. Scale up versus scale out decides whether the system is one large host or several, and it changes the install: a scale out system installs a master and additional hosts, and table distribution across those hosts becomes a design question rather than a default.

A day on a sandbox, and it makes every later administration topic concrete.

1. Check the OS prerequisites first: kernel parameters, file systems for data, log and shared, and the memory available.
2. Run the installer, recording the SID, instance number and the master password location before you start.
3. Watch where the data, log and backup volumes are placed. Log on the same disk as data is the classic sandbox shortcut that becomes a production incident.
4. After completion, connect to the system database and list the tenants.
5. Connect to a tenant and create a schema and a table. This proves the tenant, not just the install.
6. Take a backup and check it completed. An install without a proven backup is not finished.

Step six is the one people postpone, and it is the one that separates a running system from a supported one.

The installer finishes and the system is not ready. What follows is short, and skipping it produces problems that appear weeks later with no obvious connection to the install.

Change the passwords the installer set, and record where they are kept. The system user of each tenant has full rights over that tenant's data.

Turn off the automatic use of the system user for daily work. Create named administrators with the privileges they need. An audit finding of shared administrative accounts is avoidable at this point and awkward later.

Configure the backup. Both the data backup and the log backup, because a data backup alone cannot recover to a point in time. Then restore it somewhere, once, to prove it.

Set the memory and thread parameters if the machine is shared, so a second instance cannot starve the first.

Enable the traces you will want later, and set their retention, so the first performance question has data behind it.

Version note: the tooling moved. Older material uses HANA Studio, which is still functional and no longer where SAP is investing. Current work is done in the HANA cockpit and in the database explorer, and the underlying views and parameters are the same, so instructions written for the studio usually translate directly once you know the equivalent screen.

After install, confirm HANA starts, you can connect (e.g. via HANA Studio/cockpit), and memory and persistence are configured as intended. HANA problems downstream almost always trace to sizing, OS tuning or file-system issues here.

Check the services are all green rather than only that the system starts: nameserver, indexserver, preprocessor, compileserver and, on a distributed system, one indexserver per host. A system with one service down starts and appears to work until the missing piece is needed.

Two more checks are worth running before handing the system over. Confirm that the system survives a restart, because a parameter set only in memory and never written to the configuration works perfectly until the first reboot. And confirm that a client on another machine can connect, because a system reachable only from its own host has a firewall or a hostname problem that is much easier to find now than during the first application install.

Record what you did while it is fresh: the SID, the instance number, the ports, the volume paths, the version installed and the date. This becomes the first entry in the system's documentation, and it is the information every later support call asks for.

• Insufficient memory for the dataset.
• Uncertified hardware/instances.
• Skipping the HANA-specific OS tuning.

• Log volume on the same disk as data. Fine on a sandbox, and the reason for a slow production system later.
• Sizing from a guess. Undersized HANA behaves unpredictably rather than slowly.
• Never restoring the backup. See HANA backup, administration and architecture and the NetWeaver install.

Two more worth naming. Installing on an uncertified instance type because it was available, which works until you need support. And connecting to the system database and concluding the data is missing, which is the single most common first day confusion and is answered by switching to the tenant.

Where this sits in a landscape: a HANA install is rarely the goal in itself. It is the database layer underneath an application server, so the next step after this is usually installing S/4HANA on top of it, and the two sets of prerequisites are checked together rather than in sequence.

Installing is a day, and running the system afterwards is what the course covers.