SAP Administration

• Monitor system health, memory, CPU, disk, services (via the HANA cockpit).
• Manage users, roles and privileges (security).
• Configure and monitor backups and recovery, and system replication (HA/DR).
• Tune performance (memory management, expensive statements, table distribution).
• Manage tenants (in multitenant systems) and apply revisions/patches.

The division of labour is worth stating, because it varies by organisation. Where a Basis team runs both, HANA administration is part of the same role. Where a database team exists, they own HANA and Basis owns the application above it, and the boundary sits at the connection between them. Knowing which model you are in decides who you go to when the answer is "the database is slow".

The HANA cockpit is the primary web-based administration tool: it shows system status, alerts, memory and performance, and lets administrators manage backups, users, and configuration. It is the day-to-day home for HANA operations.

Alongside it, two other routes matter. HANA Studio is the older Eclipse-based client, still found in established landscapes. And hdbsql plus the command line tools are what you use when the cockpit is unavailable, which is precisely when you need them most, so knowing how to start, stop and check a system without a browser is worth practising before an incident.

One operational point about the cockpit itself: it runs separately from the databases it manages, so a cockpit that is down does not mean the database is. Knowing the command line route to check a system's status independently is what stops a monitoring outage being reported as a database outage.

Because HANA is in-memory, memory is the critical resource. Administrators watch memory usage, manage what is loaded/unloaded, and ensure the system stays within its licensed/physical memory, memory pressure is the characteristic HANA operational concern.

The numbers worth watching, and what each means. Used memory is what HANA actually holds, including data and working memory. Peak used memory is the high water mark since the last reset, which is what tells you whether a spike happened while nobody was looking. The allocation limit is the ceiling, set from the licence and the hardware.

The behaviour to understand is what happens as it fills: HANA unloads column tables from memory rather than failing, and reloads them on next access. So the symptom of memory pressure is not an error, it is a system that becomes unpredictably slow, and the unload statistics are where that is visible.

Ten minutes, and it catches most things before a user does.

Are all services up. Nameserver, indexserver, preprocessor, and the others. A service restarted overnight is worth knowing about.

Memory. Used against the allocation limit, and whether any tables have been unloaded recently.

Disk. The data volume, the log volume and the trace directory. The log volume filling stops the database, and trace files quietly consume more space than people expect.

Backups. That last night's data backup succeeded and that log backups are running continuously. A gap in the log backup chain is the thing that removes point in time recovery.

Alerts. The cockpit raises them for the above and more, and the useful discipline is resolving or suppressing each one rather than letting a permanent list of amber accumulate until nobody reads it.

Long running statements and blocked transactions. One statement holding a lock looks like general slowness to everyone behind it.

Two more that are quick and catch things the tiles do not. Check the trace directory size, because a component logging verbosely after a problem last week is still logging, and a full file system stops the database as effectively as any fault. And look at the connection count against what is expected: a climbing number usually means an application is opening connections and not closing them, which exhausts the limit hours before anybody reports an error.

HANA is updated through revisions/support package stacks; administrators plan and apply these (in non-production first), keeping the database supported and secure, coordinated with the SAP application layer.

Two practical points. The database revision must be compatible with the application release above it, so a HANA update is planned against the SAP system rather than independently. And updating a replicated pair has an order: the secondary first, then a takeover, then the old primary, which is how the update happens with minimal downtime. Doing it in the wrong order costs the availability the replication was bought for.

HANA has its own user and privilege model, separate from the ABAP one above it, and administrators are frequently surprised by that.

Database users exist in HANA independently of SAP users. The ABAP system connects through one technical database user, so every business user's activity reaches the database as that one account. Which is why ABAP authorisations, not HANA privileges, control what business users can see.

HANA privileges come in kinds. System privileges allow administrative actions. Object privileges allow access to a table or a view. Analytic privileges restrict which rows a modelled view returns, which is the row-level control for reporting. Package privileges cover design-time content.

Two accounts deserve particular care. SYSTEM is the superuser, and the standard advice is to create named administrator accounts and deactivate it rather than sharing it. Emergency access to the database bypasses the application entirely, so it needs the same treatment as any privileged route.

The practical point for anyone administering both layers: a user restricted in ABAP is not restricted in HANA if they also hold a database account, and those are granted by different people for different reasons.

Memory is the constraint, and the useful discipline is watching it move rather than reacting when it is full.

Table growth per month, by the largest tables. One growing faster than the others is either a business change or a housekeeping job that stopped running.

Used against the allocation limit, trended over months. A steady climb tells you when you will need more, which is a budget conversation with notice rather than an emergency.

Unload statistics. Tables being unloaded and reloaded is the first symptom of pressure, and it appears well before anything fails.

Delta merges. Tables with a large unmerged delta consume memory and perform badly, and a merge that is not happening is usually a configuration or a load pattern issue.

The two levers when it does become a problem are archiving, which removes data, and data tiering, which moves older data to cheaper storage while keeping it queryable. Both need lead time, which is the argument for watching the trend rather than the number.

• Ignoring memory pressure, the key HANA resource.
• Unmonitored backups/replication.
• Patching production first without testing.

• Trace files never cleared. They fill the file system, and a full disk stops the database as effectively as any fault.
• Alerts left permanently amber. The list stops being read, and the one that matters arrives unnoticed.
• Updating HANA without checking application compatibility. See the architecture, system performance, security and roles for the surrounding areas.

• The SYSTEM account shared among administrators. Named accounts are what make the audit log worth reading.
• Updating the database without checking what the application supports. Compatibility is a matrix, not an assumption.

Running the round is the daily work, and sizing, patching and keeping a replicated pair available is the part you do in the course.

The number to watch is not used memory, it is unloads. Tables being unloaded and reloaded is memory pressure announcing itself weeks before anything fails, and it is the earliest warning available.