SAP HANA Installation
SAP HANA Update Revision: Steps for a Safe SPS Upgrade
Learn how to plan and execute an SAP HANA update revision, including revision selection, readiness checks, backup validation, hdblcm execution, post-update verification, and rollback planning.
SAP HANA updates keep an on-premise system aligned with supported fixes, security improvements, and operational requirements. A reliable update revision process combines a clear target, validated backups, host and database checks, controlled downtime, and post-update verification.
This guide explains the main SAP HANA upgrade steps for a revision update. It focuses on planning and execution with SAP HANA lifecycle tools, especially hdblcm, while keeping the system database and tenant databases in view.
Plan the SAP HANA revision update
An update revision changes the SAP HANA software revision while preserving the system’s databases and configuration. Start by documenting the current revision, operating system, installed components, database topology, interfaces, and maintenance requirements.
Use the SAP HANA installation guide to confirm the installation layout and prerequisite approach before preparing the update. The target revision should be selected from the supported maintenance path for the installed SAP HANA 2.0 system, operating system, and connected applications.
A practical revision plan includes:
- The current SAP HANA revision and target revision
- The planned maintenance window and business owners
- The system database and tenant databases affected by the operation
- Required SAP HANA components and additional packages
- Application, interface, and monitoring dependencies
- Backup validation and recovery responsibilities
- The person responsible for technical verification after startup
SAP HANA 2.0 operates as a multitenant system with a system database and tenant databases. The update plan therefore covers the complete system and includes checks for each tenant that supports business workloads.
Check prerequisites before the update
Before launching the update, verify that the target media is complete and accessible on the installation host. Confirm the operating system prerequisites, file-system capacity, user permissions, communication paths, and required maintenance credentials.
Check the following areas in sequence:
- Confirm the target revision and download package integrity.
- Review the SAP HANA installation and update documentation for the target package.
- Check free space in the locations used for installation media, temporary files, data, and logs.
- Confirm that the system can be stopped and started during the maintenance window.
- Identify active application connections, scheduled jobs, replication dependencies, and external monitoring.
- Confirm that the operating system and SAP HANA administration users can perform the required tasks.
- Record the current configuration so that post-update comparisons are meaningful.
Use SAP HANA cockpit and SAP HANA database explorer to inspect system health, database status, alerts, services, and tenant connectivity before maintenance. A clean starting state makes post-update troubleshooting more precise.
Memory and capacity checks should include host and service utilization. Host memory is available in SYS.M_HOST_RESOURCE_UTILIZATION, including HOST, USED_PHYSICAL_MEMORY, FREE_PHYSICAL_MEMORY, ALLOCATION_LIMIT, INSTANCE_TOTAL_MEMORY_USED_SIZE, and INSTANCE_TOTAL_MEMORY_ALLOCATED_SIZE. Service memory is available in SYS.M_SERVICE_MEMORY, where the used-memory column is TOTAL_MEMORY_USED_SIZE.
For a broader capacity review, see the SAP HANA memory usage guide. This is especially useful when the target revision introduces additional components or when the current system already operates close to its allocation limits.
Validate backups and recovery readiness
A successful update depends on a recovery plan that has been tested and understood. Complete a current data backup, verify recent log backups, and confirm that the backup catalog and destination are available to the recovery team.
Before maintenance, document:
- The latest successful data backup
- The latest available log backup
- Backup destinations and retention details
- The recovery owner and escalation path
- The expected recovery point and recovery time
- The procedure for restoring the system if the update cannot be completed
Test that the required backup files can be read from the backup infrastructure. A backup that exists but cannot be accessed during an incident does not provide dependable recovery protection.
If encryption is configured, back up the root keys before the update and back them up again after any change. Data volume encryption, log volume encryption, and backup encryption are configured separately. A backup encryption root key that changes without a new root-key backup makes the backup unrecoverable.
The SAP HANA backup and recovery guide provides additional operational context for backup validation and recovery planning.
Choose the SAP HANA update method
The command-line lifecycle manager is hdblcm. It supports SAP HANA installation, update, and component lifecycle operations from the command line. The separate graphical front end is hdblcmgui.
Review the SAP HANA hdblcm guide before the maintenance window so that the administrator knows which executable, media location, and parameters apply to the planned operation. Run the lifecycle manager with the operating system permissions required by the SAP HANA installation and follow its prompts for the selected update.
For component updates that provide a graphical workflow, SAP HANA cockpit can support administration and monitoring. The graphical interface does not replace the need to validate prerequisites, backups, database status, and recovery procedures.
The update method should be consistent across the system. Record the selected options, package locations, component versions, and any configuration changes made during the operation. This record supports verification and future maintenance.
Execute the SAP HANA revision update
Begin the maintenance window by notifying application owners and stopping workload-generating processes according to the agreed procedure. Confirm that the system is ready for maintenance, then run the selected lifecycle operation from the designated installation host.
A controlled execution sequence is:
- Confirm the maintenance approval and backup status.
- Stop application traffic and dependent jobs.
- Review the current system and tenant database state in SAP HANA cockpit or SAP HANA database explorer.
- Start
hdblcmor the approved graphical workflow from the SAP HANA installation media. - Select the update operation and verify the target revision and components.
- Review the displayed summary carefully before confirming.
- Monitor the lifecycle operation, operating-system messages, and SAP HANA service status.
- Capture the completion result and any warnings for the change record.
Do not treat completion of the installer as the only success criterion. The system must also start correctly, expose the expected services, allow database connections, and pass application-level validation.
The local start and stop script is HDB, located at /usr/sap/<SID>/HDB<instance number>/HDB. The commands are HDB start and HDB stop, and they operate on the local host. For distributed systems, use sapcontrol -nr <instance number> -function StartSystem or sapcontrol -nr <instance number> -function StopSystem with the <sid>adm user. The -nr option selects the instance number.
Verify the updated system
After the lifecycle operation finishes, verify the complete SAP HANA system before releasing it to users. Confirm the software revision, service status, system database status, tenant database status, connectivity, alerts, and application behavior.
Use SAP HANA cockpit and SAP HANA database explorer for administration checks such as:
- System and tenant database availability
- Service startup and service health
- Recent alerts and failed operations
- Administrative user connectivity
- Application schema access
- Backup and log-backup status
- Replication or interface status where applicable
The system database controls the multitenant environment, while each tenant database supports its own application workload. Verify each tenant separately and confirm that expected services and connections are available.
For system-wide start and stop procedures, consult the SAP HANA start and stop guide. Starting or stopping a single tenant uses ALTER SYSTEM START DATABASE <name> or ALTER SYSTEM STOP DATABASE <name> in the system database. The M_DATABASES view lists the tenants.
Compare the post-update state with the baseline captured before maintenance. Review configuration values, users, roles, interfaces, scheduled jobs, backup settings, and monitoring integrations. Resolve warnings before declaring the update complete.
Document rollback and follow-up actions
A revision update should have a defined decision point for continuing, pausing, or recovering. If the lifecycle operation fails, preserve installer logs and system information, then use the approved SAP support and recovery procedure.
Do not improvise a downgrade during the maintenance window. A rollback plan normally relies on the documented recovery method, available backups, compatible software media, and a decision by the responsible technical and business owners.
After successful verification, complete the change record with:
- Previous and target revisions
- Start and completion times
- Executed lifecycle commands or graphical workflow details
- Backup and recovery evidence
- Warnings and their resolutions
- Database and application validation results
- Updated operational documentation
- Root-key backup evidence when encryption keys changed
Schedule a short follow-up review to confirm that monitoring remains healthy, backups continue successfully, and application workloads behave normally after the revision update.