Time taken for HANA System to become available after a System restart for continuing transaction (in ERP on HANA)

[Former Member]

Hi HANA Gurus,

Would like to know in a normal system replication based HA for SoH, without memory preload, after an automatic failover to the second node,in how much time HANA becomes available for the SoH(ERP) users to continue transaction.  Consider an ideal scenario with  512 GB appliance , with allocation limit of 490GB approx., considering normal 90% of first 64gb and 97% of every further 64GB memory on the single host.  Also consider a used memory of say 128 GB(indicating database size and considering no custom configuration for specific  tables preload  .Consider the save point is every five minutes as default and committed transactions are written to the log.  Host is replicated to second node using HANA System replication and with HANA automatic failover option. This means on first node failure the HANA system will be restarted on second node and data will be loaded to the memory based on the last state in the other node. As I understand the save points are loaded, logs are applied and database become available for users, the lazy load continues etc. Kindly answer me if anyone knows by experience how much time it takes from the failure detection  to next state of the system becoming available for user to start updating for example a Sales Order. Also like to know more about this start-up process to understand it better(for example the last save points are done by saving the changed pages, so time taken to load the last savepoint pages to memory, then applying transactions from last save point (last 4 minutes for example  before failing over etc).  The purpose is to understand whether the failover time from Primary to standby takes similar time like a traditional db  (for example db2) or more due to memory load time in HANA. At the same time I am aware of other options available to reduce the RTO by using memory preload, cluster solutions from vendors , OS like SUSE etc.

Thanks in advance.

Rajesh Vikraman

[Former Member]

With system replication, you commit transactions on both sides in real-time. For SoH you should use synchronous replication, which will provide a very low RPO approaching zero.

Memory size and usage is not relevant, as both sides are active and hold the data in memory. RTO is just the time to detect failure, initiate takeover, and update DNS. We are looking at around 60s in regular operations.

[Former Member]

Hi John

My question is specific to a system failover  which is not replication with memory preload, where you require cluster software to do the failover. My question is in case of a automatic failover configuration using a standby node . For example gpfs / hana automatic failover option, where standby note starts hana, and  loads last savepoint , applies logs and then start lazy loading.

Regards

[Former Member]

Don't use this for an OLTP system, the RTO will be too long. It will depend on the size of your row store, but is typically 5-10 minutes before the system is available. You will need to test it in order to know the exact RTO for your system.

For OLTP you should use system replication.