The Ultimate SAP HANA Architecture and Upgrade Analysis: From In-Memory Basics to the Cloud Era

Welcome back to the tech blog! As a Senior SAP Technology Consultant, today I am taking an extremely detailed and profound look at the heart of modern SAP landscapes: SAP HANA (High-performance ANalytic Appliance). Today we connect fundamental historical backup knowledge with the latest architectural data, update paths, and code or scripting concepts to draw a complete picture of this revolutionary in-memory database.

Historical Facts and Technological Evolution

The development of SAP HANA was a paradigm shift, significantly driven by SAP co-founder Hasso Plattner as well as teams from the Hasso Plattner Institute (HPI) and Stanford University. The goal was clear: Answer business queries in real-time, without the latencies of traditional, disk-based databases.

In its early stages, the architecture was based on research on HYRISE (a main-memory hybrid storage engine, published in November 2010 and advanced to HYRISE2 in 2017). SAP also integrated and acquired key technologies such as the TREX Search Engine (for column-based in-memory searches), P*TIME (an in-memory OLTP platform acquired in 2005), and MaxDB with its liveCache engine. The first official release, SAP HANA 1.0, took place in November 2010.

Groundbreaking milestones followed over the years:

• 2012: Introduction of the SAP HANA Cloud Platform (PaaS) and SAP HANA One.

• 2013: Launch of the HANA Enterprise Cloud (HEC) and SAP HANA XS (an integrated, lightweight app server layer).

• 2015: Release of SAP S/4HANA, the simplified Business Suite written specifically for HANA.

• Nov 2016: Announcement of SAP HANA 2.0, which henceforth served as the technological basis for innovations.

• 2020: Tenth anniversary and launch of the SAP HANA Cloud (DPaaS) based on hyperscaler platforms.

Core Architecture: OLTAP, Column-Store, and MVCC

The greatest innovation of SAP HANA is its establishment as an OLTAP system (Online Transaction and Analytical Processing), often also referred to as HTAP (Hybrid Transactional/Analytical Processing). This architecture eliminates the need to operate OLTP (transactions) and OLAP (analytics) in separate systems.

Row Store vs. Column Store

Data is stored in RAM, making data access up to 10,000 times faster than on hard drives. By default, modeling tools like the Information Modeler work exclusively with Column Tables. The column store saves data of one column in the same location, enabling enormous vertical compression and lightning-fast OLAP queries.

Nevertheless, the Row Store continues to exist for specific administrative tasks. Here is an exact architectural breakdown of the system schemas:

• Row Store: Schema SYS (contains caches and administrative tables of the engine) as well as tables of the Statistics Server.

• Column Store: Schema _SYS_BI (metadata of the views and master data for MDX), Schema _SYS_BIC (generated tables for MDX), and Schema _SYS_REPO (lists of active/modified versions of the models).

MVCC (Multiversion Concurrency Control) and Garbage Collection

SAP HANA manages concurrency via MVCC. Transactions receive snapshots of the database. During updates, old data is not overwritten but marked as obsolete, while the new version is added. Architecture Knowledge / Troubleshooting: In older HANA revisions (122.00 to 122.04 and 122.07 to 122.10), LOB garbage collection in the Row Store could cause problems that blocked the global MVCC Version Garbage Collection (see SAP Notes 2413261 and 2482053). This led to a steady growth of HANA persistence and backups.

Multi-Tier Storage (Data Tiering)

Since RAM is expensive, HANA uses mechanisms for dynamic tiering:

• Hot Data: In-memory.

• Warm Data / Cold Data: Offloaded to hard drives or Data Lakes via Native Storage Extension (NSE).

Data Modeling: The Evolution of Views

The preparation of operational data for the end user was traditionally done in the SAP In-Memory Computing Studio and later via modern Web IDEs. The old basic knowledge of HANA modeling comprises three main views:

1. Attribute Views: Act as dimensions or master data tables. For table joins, join types like leftOuter, rightOuter, fullOuter, and textTable can be defined here with cardinalities of 1:1, N:1, and 1:N.

2. Analytic Views: Represent cubes in a Star Schema. They do not store data themselves but access the Column Store. At least one attribute and one measure are required here; additionally, Restricted and Calculated Measures can be implemented.

3. Calculation Views: These correspond logically to Virtual Providers with a services concept in SAP BW. They can be created graphically (with Union, Join, Projection nodes) or script-based via SQLScript.

With SAP HANA 2.0, development shifted heavily towards the SAP Web IDE for SAP HANA and Core Data Services (CDS) to build extended data models including syntax checking.

Advanced Analytics

SAP HANA offers massive parallel processing for compute-intensive logic directly in the database:

• SQLScript: Avoids data copies to the Application Server by pushing down application logic. Version 2 supports Stored Procedures for improved control flows.

• BFL (Business Function Library): Written in C++ and executed in the HANA Calculation Engine. It offers financial and business algorithms like Asset Depreciation and Moving Averages.

• PAL (Predictive Analytics Library): Contains native algorithms for statistical calculations such as clustering, classification, and time-series analysis.

• R-Integration: Open programming language for statistical computing, usable within Stored Procedures (over 3000+ packages).

• Graph Engine: Processes the Cypher Query Language and utilizes the Graph Viewer. Structures lie directly in the Column Store. Integrated algorithms include Pattern Matching, Single Shortest Path, and Neighborhood Search.

• Spatial Processing: Native SQL extensions for spatial data types (OGC-certified, integratable with ESRI ArcGIS).

• Text Analytics: "Fuzzy" search with fault tolerance and entity extraction (Voice of the Customer, Public Sector).

Application Development: From XS Classic to XSA

Initially, SAP used the SAP HANA extended application services (XS Engine) to provide OData and REST services with HTML5/JavaScript. The modern successor is the XS Advanced Engine (XSA). XSA is based on a Cloud Foundry architecture and supports "Bring Your Own Language." Native runtime environments for Node.js and JavaEE are integrated, as well as SAP HANA XS Javascript (XSJS) for backward-compatible server-side code.

Detailed Release Strategy and Complex Upgrade Paths

One of the most critical areas for SAP Basis consultants is maintenance and upgrade paths.

• HANA 1.0 SPS12: The End of Maintenance for HANA 1.0 SPS12 was set for May 2021. No new SPS followed for HANA 1.0.

• HANA 2.0: Follows the strategy of 1 SPS per year. The maintenance duration for a new SPS (from SPS02) is 2 years, while the final SPS of HANA 2.0 has a support period of 5 years.

The Hard Facts: Architecture Limits During Upgrade

Upgrades require that fixes from the source revision are included in the target revision. However, exceptions and incompatibilities exist documented across SPS boundaries:

• HANA 1 Revisions 75-79, 86-89, 98-99, and 103-109 were completely skipped.

• MDC (Multitenant Database Containers): When upgrading a HANA 1 MDC system, the system server must have separate metadata areas, which is only the case from maintenance revision 122.04 onwards. A prior upgrade to the last HANA 1.0 SPS12 is strictly required here.

• Skipping OS Restrictions: Some HANA revisions (like 122.35) support RHEL 7 but no RHEL 8, while HANA 2.0 Rev 60 supports RHEL 8 but no RHEL 7. Here, migration must occur via "Intermediate Jumps," e.g., via Revision 54 (supports RHEL 7 & 8), to then update to RHEL 8 at the OS level and subsequently jump to Rev 60 (according to Note 2407244).

• Example from the Upgrade Matrix: You may not upgrade directly from HANA 1.0 Revision 102.05 to HANA 1.0 SPS11 (110, 111, 112) because the source revision at that time already contained more fixes than these old SPS11 revisions. The permissible path here would be at least Revision 112.02 or HANA 1.0 SPS12 (Revision ≥ 120).

Integration into the SAP Landscape: NetWeaver, Fiori, and S/4HANA

SAP HANA is the exclusive foundation for SAP S/4HANA.

• Naming Convention: S/4HANA versions were designated as YYMM until 2020 (e.g., 1909 for September 2019) and switched to the YYYY format for On-Premise starting October 2020 (e.g., S/4HANA 2020).

• NetWeaver AS ABAP: The latest stack layers include versions like AS ABAP 7.54 (SAP_BASIS Component). The predecessor system ECC ended with EHP 618 as the last major release (indicated by the "1", e.g., HANA-optimized), identifiable via the SAP_APPL component.

• SAP Fiori & UI5: The user interfaces have changed drastically – from BlueCrystal (2015) via Belize / Belize Deep (Fiori 2.0 in 2016) to Fiori 3 with the themes Quartz Light/Dark. For SAPUI5 (verifiable via sap.ui.version in Browser DevTools), delivery via the SAP Business Technology Platform (BTP) switched from a quarterly to a monthly rhythm, with every twelfth version becoming a Long-Term Maintenance Version.

Editions, High Availability & Security

For Cloud and On-Premise scenarios, SAP HANA exists in various licensing models (Runtime vs. Full Use) as well as editions:

• Base Edition: Core functions of the database.

• Platform Edition: Base + Spatial, Predictive, R, Text, Graph.

• Enterprise Edition: Platform + Rule Frameworks + Data Loading components.

• Express Edition: Free for productive purposes up to 32 GB RAM, expandable to 128 GB RAM.

In HANA 2.0, management was massively simplified by the SAP HANA Cockpit. In the area of High Availability (HA) / Disaster Recovery (DR), HANA 2.0 supports Active/Active-Read Enabled Mode to shift read-heavy queries (e.g., Analytics) from the primary system to the secondary system (Replication Node). In terms of security, HANA scores with comprehensive Data-at-Rest encryption for data and redo logs as well as automatic role assignment via existing LDAP groups.

Conclusion

SAP HANA has evolved from an initial in-memory research vision into a highly complex multi-model transaction and development platform. The combination of HTAP architecture, Column Store performance, and advanced in-database calculations (SQLScript, PAL, Graph, Spatial) has closed the traditional gap between OLTP and OLAP forever. For architects and administrators, this means unimagined performance on the one hand (3.5 billion scans per second per core), but also high responsibility in adhering to exact upgrade paths, system architecture rules, and OS dependencies on the other. The replacement of HANA 1.0 by HANA 2.0 and the current shift into the HANA Cloud prove: The in-memory revolution was just the beginning of a completely data-driven corporate reality.