HANA FSD Vs SAP HANA NVRAM
Below is a simple question and answer format I have created to illuminate the uses of FSD and have also compared it against HANA persistent memory (NVRAM)
1.What is the concept of SAP HANA Fast restart option?
The SAP HANA Fast Restart option uses storage in the file system to preserve and reuse MAIN data fragments to speed up SAP HANA restarts. This is effective in cases where the operating system is not restarted.
It possible to reuse MAIN data fragments after an SAP HANA service restart without the need to re-load the MAIN data from the persistent storage. It leverages the SAP HANA Persistent Memory implementation with the key performance benefit of greatly accelerated start-up times so that data can be quickly reloaded into memory and system downtimes can be minimized
2.Do we need extra license to use SAP HANA Fast Restart option?
No. The fast restart option is a bridge technology which can be used independant from CPU and memory type. There are no additional costs to use it. This means also that there is no reason not to use it.
3.How SAP HANA Fast restart different from SAP HANA NVRAM ?
In contrast to Persistent Memory which works with a DAX enabled file system, the Fast Restart option stores MAIN data fragments in tmpfs file systems with content in DRAM. Tmpfs file systems can grow and shrink dynamically.
HANA persistent memory need DAX filesystem
SAP HANA Fast restart option uses =tmpfs filesystem
Also the Fast Restart option can be used with all supported SAP HANA hardware platforms and all supported operating system versions. The HANA online performance and sizing KPIs are not impacted.
4.What are the steps required to prepare a filesystem for SAP HANA Fast Restart option?
To use this feature we must create a mount on the tmpfs file system for each NUMA node and HANA instance and set the basepath parameter to identify these locations (see Configuration below).
- Firstly, use the following command to determine the number of CPU sockets available in the HANA server:
This returns the node details, for example, two nodes numbered zero and one:
- Make a directory and mount for each node equipped with memory making sure that all tmpfs mounts have preferred NUMA policy, for example
Allow access to the directories
If we want to limit the size of these mounts you may use the SIZE option of the mount command, for example
To ensure that the mount points are available after an operating system reboot we must also add entries into the file system table, for example: /etc/fstab
5.How to enable HANA DB to use HANA Fast Restart option after creating directories ?
Basepath(basepath_persistent_memory_volumes) :As with the other existing data and log persistent storage volumes, for MAIN data fragments the in memory storage location basepath must be defined as a configuration parameter in the [persistence] section of the global.ini file. Enter the basepath location in the basepath_persistent_memory_volumes parameter (this parameter can only be set at the level of HOST). All MAIN data fragments are stored at the location defined here. Multiple locations corresponding to NUMA nodes can be defined using a semi-colon as a separator (no spaces), for example:
Enablement for Partitions, Tables or Columns: We can determine storage preferences for Fast Restart in the same way as for Persistent Memory by using the SQL CREATE and ALTER table statements with the alter_persistent_memory_specclause.
Persistent memory Global allocation limit(persistent_memory_global_allocation_limit): As an alternative to setting a limit on the size of each mount as described above, overall tmpfs memory usage for all NUMA nodes for a given HANA instance and a given server node can be limited by setting the persistent_memory_global_allocation_limit parameter in the [memorymanager] section of the global.ini file. By default, no limit is specified: enter a value in MB to set a limit on the size of the used tmpfs space for each host. If we wish to limit the size of this main memory storage we can decrease the tmpfs file system size or use the parameter persistent_memory_global_allocation_limit to restrict the used tmpfs size.
6.Does this option changes the column unload behavior in HANA DB?What is the use of parameter table_unload_action(DELETE/RETAIN) in persistent memory section?
The standard UNLOAD statement and also table unloads executed implicitly by HANA services due to memory running low, do not by default free the memory but simply remove the mapping of relevant data structures from the HANA service process address space and the MAIN data fragment remains – either in persistent memory or in tmpfs.
The configuration parameter table_unload_action in the [persistent_memory] section of the indexserver.ini file can be used to control this unload behavior. The default value of the parameter for tmpfs is DELETE in which case MAIN data fragments are cleared from tmpfs, but this can be set to RETAIN if required.
7.Can we unload tables using SQL when Fast restart option is used ?
We can use UNLOAD with the additional DELETE PERSISTENT MEMORY clause to completely free memory, for example: UNLOAD MYTABLE01 DELETE PERSISTENT MEMORY;
8.How to monitor SAP HANA Fast Restart Options ?
The monitoring views used by persistent memory are also used by the Fast Restart feature (see Persistent Memory). For example, the PERSISTENT_MEMORY column in M_CS_TABLES, M_CS_COLUMNS and M_CS_ALL_COLUMNS shows TRUE if real persistent memory or tmpfs is enabled.
Thanks for reading!
Follow for more such posts by clicking on below link and FOLLOWhttps://people.sap.com/rajarajeswari_kaliyaperumal
Like and leave a comment or suggestion if any!