To implement a multi-temperature memory strategy in your SAP BW, you can use the extended table concept with SAP HANA Dynamic Tiering. Using this concept, you can store warm data - with specific usage profiles without functional restrictions - in extended tables, which are managed by SAP HANA. This enables you to optimize usage of the main memory in SAP HANA.
In a data warehouse, data can be classified using the following categories based on access frequency: hot, warm, cold. In a data warehouse there are also different data usage profiles, which relate to the classification by access frequency. The multi temperature memory strategy of a company determines which memory areas are used to store data by access frequency and use. For more information about multi-temperature data management and classification of data by access frequency or use, see Multi-Temperature Data Management.
The extended tables concept relates to warm data. Since warm data is not constantly accessed, this data does need to occupy space in the main memory of SAP HANA. The concept of active data and non-active data was therefore introduced a while ago in SAP BW on SAP HANA. This concept means that if memory bottlenecks occur, specific tables are pushed out of the main database memory and into the SAP HANA file system. Although this solution offers better main memory usage, you still need to schedule a specific main memory capacity when sizing, because the data must first be loaded into the memory before it can be pushed out. The data for main memory access must also be reloaded into the main memory.
SAP HANA Dynamic Tiering enables you to optimize the main memory resource management in SAP HANA by using extended tables for BW objects with warm data:
Extended tables are tables managed by SAP HANA. Logically they are located in the SAP HANA database catalog and can be used as if they were persistent SAP HANA tables. These tables are physically located in a disk-based data storage however, which has been integrated into the SAP HANA system. The user sees the entire system as one single database. The persistence of data written to the extended table is hard-disk-based and not main-memory-based. The data written to an extended table is written directly to the disk-based data storage. This data in the warm memory is accessed using algorithms, which are optimized for disk-based storage. Unlike the concept of active/non-active data, the main memory in SAP HANA is not required for data persistence (in extended tables).
In SAP BW, warm data, which is used in the acquisition area or input area and in the corporate memory area, is usually saved in DataStore objects (advanced) persistent staging area tables (PSA tables) and in write-optimized DataStore objects. If you use SAP HANA Dynamic Tiering, you can configure these objects to make SAP HANA create an extended table instead of a native SAP HANA table. The data written to this table is written directly to the disk-based data storage. Since the extended table is logically located in SAP HANA, the SAP HANA optimizer can access this table like as it would any other SAP HANA table.
In summary, the extended tables concept enables you to do the following:
The concept of extended tables can optimize the main memory resource management even further than the concept of active/non-active data. This has a positive effect on hardware sizing, especially when dealing with a large quantity of warm data in the PSAs and write-optimized DataStore objects, which need to be available for extended tables. The main memory can be reduced as required. For more information, see SAP Note 1736976 .
The following prerequisites must be met in order to use extended tables in SAP BW:
Data, which is initially frequently accessed and then only used occasionally once it reaches a certain age, is classified as cold. Therefore this data can be removed from the SAP HANA data persistence and stored in an accessible archive. The solution offered by SAP is near-line storage (NLS) with SAP IQ. The difference to extended tables is that the primary data persistence was initially SAP HANA, and the data is deleted from SAP HANA once the data has been stored on the near-line storage (separate server).
Extended tables and NLS offer different solutions (different storage types) for data in different access categories and usage profiles. The following table shows the main differences between the solutions:
|Extended Tables||Near-Line Storage with SAP IQ|
|Main memory use is optimized in SAP HANA.||Data persistence is optimized in the system landscape.|
|Extended tables are an integral part of the platform.||The near-line storage is located on a separate server.|
|Extended tables handle complete tables.||NLS handles selected semantic data slices.|
|All types of data manipulation are possible (Create, Read, Update, Delete).||The data of an InfoProvider is written once to the near-line storage and then read from there.|
|Storage of data with business-critical service level agreements.||Storage of data with low service level agreements, in order to reduce costs.|
More information: SAP IQ as a Near-Line Storage Solution