Inspiricon-Persistence-Layers-in-SAP-HANA

The 5 W’s of the Persistence Layer in SAP HANA

Imagine this scenario: you sit down with a fresh cup of coffee in front of your nice shiny new HANA database, which has been delivering results at record-breaking speed, much to the satisfaction and dismay of all your business users…  

Then suddenly, between sips, the unspeakable happens! Disaster strikes! Lights out! Power off! A crash! HANA’s in-memory data fades out in the middle of processing… How could this have happened?!  

More importantly, how to recover all that data and restore it to its last committed state?! 

To be prepared for this eventuality, and to prevent in-memory data loss and avoid major efforts in data recovery/restoration afterwards, SAP HANA employs a so-called “Persistence Layer”.  

Wait a minute, you may be saying to yourself, what’s all this about “persistence”? Isn’t SAP HANA supposed to be so much faster exactly because it is NOT persistent, and instead relies on in-memory technology?  

Well, in fact SAP HANA does also depend on data persistence. Here’s a brief overview of the built-in SAP HANA Persistence Layer. 

The 5 W’s: Who-What-Where-When-Why? 

Who? 

SAP HANA developers and consultants are the target audience for this basic overview of the Persistence Layer in the SAP HANA database architecture. 

What? 

The fact is, the Persistence Layer is built into the HANA database. It’s important not to confuse this “Persistence Layer” with the option you have as a developer to create “Persistent HANA Views” – but that’s a topic for another day and another blog!  

The storage of data on disk is called “persistence”. This is in contrast to the data temporarily residing in RAM, the so-called “in-memory” data, which can be accessed with dramatically faster response times – which is the basis of SAP HANA’s in-memory technology!  

The Persistence Layer is used to physically store data in the form of so-called “savepoints” at regular intervals of every X seconds (default configuration = 300 seconds, which is 5 minutes). These savepoints contain the last transactions written to the persistent storage on data volumes in the HANA database. In addition, SAP HANA stores logs of ongoing data transactions. In the event of in-memory data loss, the latest savepoint is used together with the logged transactions that occurred since that savepoint to “reconstruct” or restore the database to the last committed state of the data.  

Where? 

The Persistence Layer is located inside the Index Server in the SAP HANA database. It’s best viewed in the context of the In-Memory Computing Engine (IMCE): 

Inspiricon_In-Memory-Computing-Engine

 

 

 

 

 

 

 

 

 

 

 

 

When? 

The Persistence Layer is configured by the SAP Basis Team during the original installation and setup of the SAP HANA database. The necessary parameters are stored in the global.ini file. These can be accessed directly or via the SAP HANA Cockpit under the Persistence section. It is possible to adjust these parameters at any time to optimize data recovery or system performance. For example, the frequency of the savepoint is determined by the configuration parameter savepoint_interval_s, which can be easily changed from the default value of 300 seconds (5 minutes). Since the savepoint involves writing data to disk, there is a performance cost/benefit to consider. 

Why? 

Why do we need a Persistence Layer in SAP HANA? For exactly the reasons implied in our original scenario above: To secure – or “persist” – your in-memory data in the event of a power outage or other system crash scenario. 

In addition, the SAP HANA Persistence Layer helps to fulfill the “A-C-I-D” properties for a database: Atomicity – Consistency – Isolation – Durability. The Persistence Layer ensures that the database transactions remain ACID by making sure that each transaction is either completely executed or completely rolled back (atomicity and consistency), and restoring the data to the most recent committed state after a restart (durability).  

Oh yes, there’s also the “H” question… 

How? 

This is the critical question: How does it work? 

The deeper technical details are documented in many Internet sources, but the basic steps can be outlined as follows: 

Inspiricon_SAP-HANA-Persistence-Layer

 

 

 

 

  • The SAP in-memory database holds the bulk of its data in memory for maximum performance, and writing data to disk is minimized. 
  • SAP HANA still depends on persistent storage to provide a fallback in case of power failure or other unplanned system shutdowns. 
  • The HANA system uses a combination of “write-ahead” or redo transaction logs and the last savepoint to recreate the last committed state of the HANA database after such a sudden shutdown.   
  • When a database transaction occurs “in memory”, the changed memory pages are captured by the redo logs before those changes are actually applied to the physical database volume at the next write to disk. These “write-ahead” logs can be used for both redo and undo operations, thus ensuring a complete rollforward or rollback of individual transactions. 
  • The in-memory data and the transactional log information are automatically saved to disk at regular savepoint intervals. 
  • The in-memory pages containing data are written to the data volume to persist them.  
  •  The redo log entries are written to the transactional log volumes for all changes to persistent data that occurred in memory and since the last savepoint.  
  • The data belonging to a savepoint is the last consistent state of the data stored on disk, and it remains there until the next savepoint operation has completed.  
  • In the event of a database restart, data from the last completed savepoint can be read from the data volumes, and the redo log entries are then applied or replayed, so that the last logged changes to the data are “rolled forward” and written to the log volumes to reconstruct the data to its last consistent state following a HANA database restart. 

To Sum It All Up: 

The Persistence Layer in the SAP HANA database can save you the agony of in-memory data loss after an unexpected power interruption or other type of system crash, and it plays a major role in ensuring the successful long-term fail-safe operation of your SAP HANA database!  

For any questions or help needed in implementing your SAP BW on HANA or BW/4HANA system in your organization, please feel free to contact us at Inspiricon AG!  

SAVE THE DATE: You can find out more about this and other related SAP HANA topics in our upcoming webinar on “Migration to BW/4HANA”. Please secure your space under this link today! 

Source of images: sapstudent.com, tutorialspoint.com

Author
Andrea Taylor Senior Consultant SAP BI
Phone: +49 (0) 7031 714 660 0
Email: info@inspiricon.de