As of SAP HANA 2.0 SPS00, it is possible to configure so-called “extension nodes” as an alternative to SAP HANA dynamic tiering with regards to data temperature management. While SAP HANA dynamic tiering allows hot data to stay in memory and warm data to be kept on disk in a columnar format, SAP HANA extension nodes allow some of the nodes to be “overloaded” regarding the memory to data ratio. Traditionally, the memory to data footprint ratio must be 2:1, which assumes all data is kept in RAM and ensures sufficient space for intermediate result sets. However, SAP HANA extension nodes are designed for warm data that is accessed less frequently and with less CPU-intensive processes. Therefore, a strict memory to data ratio is not required. The SAP HANA extension node solution is option for SAP BW, because up to 50% of BW data can be classified as warm. For more details about SAP HANA extension nodes, see the blog More Details – HANA Extension Nodes for BW-on-HANA.
This blog is not meant to document the low-level details of the actual configuration of SAP HANA extension nodes – I will provide links to the official documentation, which is regularly updated. It’s meant to give an overview of the key topology concepts of the SAP HANA extension nodes, and how these changes to the topology are supported by SAP HANA backup and recovery.
SAP HANA extension nodes are usually configured as part of SAP HANA scale-out system installation using the SAP HANA installation tool HDBLCM in either the command-line or graphical user interface. An installation of SAP HANA extension nodes has been supported since the SAP HANA 2.0 SPS00 release. During installation, you can now not only specify which SAP HANA hosts are part of configurable host groups (as part of a host auto-failover solution), but now you can also assign the hosts to worker groups. In the SAP BW scenario, for all new objects classified as “warm”, the corresponding database tables are created on an SAP HANA extension node. For more information about the distribution of SAP BW content across the SAP HANA worker groups, see SAP Note 2453736: How-To: Configuring SAP HANA for SAP BW Extension Node in SAP HANA 2.0 .
-----SAP HANA Backup and Recovery in SAP HANA 2.0 SPS02-----
Since its conception, SAP HANA backup and recovery supported the single database (non-multitenancy/MDC) deployment type for SAP HANA extension nodes, but only if the worker group value was “worker_dt” as is required by the SAP BW scenario.
With SAP HANA 2.0 SPS02, released on July 26th, 2017, the backup and recovery support for SAP HANA extension nodes has been extended to allow for more deployment types and flexibility. Because the worker groups are configured on host-level, as described by the installation, any service on the host inherits the worker group. Since backups are taken per service, with SAP HANA 2.0 SPS02 any backups include the worker group value in the backup header. Including the worker group value in the backup header allows for more flexible handling of backups during the database restore process.
Arbitrary worker group values support
Now, because the worker group value is stored in the backup header, any worker group value is supported as part of the database restore process (not just the value “worker_dt”). However, as in previous SAP HANA revisions, the restore process will fail if the worker group value between the backup and the restore host do not match. This is to ensure the data in the backup are restored to a host that has the same memory to data ratio as the host where the backup was taken.
Overriding worker group matching during restore
In some cases, the recovery of data may take precedence to restoring data with the same overload properties as the backup host. In this case, it’s possible to ignore the worker group matching during database restore using SQL. For more information, see the RECOVER DATABASE statement documentation.
Checking the worker group value of a backup
You can check the worker group value of a data backup by dumping the backup header using:
-v -b <backupname>
Support for SAP HANA multitenancy
In SAP HANA 2.0 SPS01, all SAP HANA systems are installed as or updated to MDC systems consisting of one system database and one tenant database. For more information, see the blog Multi-container database mode is the new default. SAP HANA backup and recovery does not support SAP HANA extension nodes for MDC systems in SAP HANA 2.0 SPS01. If a customer wants to upgrade to SPS01 and they are using SAP HANA extension nodes, it is required to involve SAP support if there are conflicts between the auto-conversion to MDC and required functionality.
With the newly release SAP HANA 2.0 SPS02, this restriction is lifted, and there are no limitations with regards to SAP HANA extension nodes and multitenancy.