This is the third part of the blog series of HANA memory usage details and changes in SPS12
Here are the technical changes with SPS12 in an overview:
Number Note Description Details
1) 2116157 HANA Consistency Checks and Corruptions new checks SET_ALERT_SCHEDULE SET_COLLECTOR_SCHEDULE
2) 2014148 query result allocator “Pool/malloc/”
3) 1999997 metadata cache own allocator
4) 2336344 view cache own allocator Pool/ResultCache
5) 2220627 monitoring view new view M_TABLE_LOB_STATISTICS
6) 2101244 MDC parameter new parameter systemdb_reserved_memory
7) 2298750 JVM6 Kerberos krb5 configuration
8) 1999880 replicate parameters automatically replicate parameters in SR scenarios
9) 1999880 alert 94 reports increased log replay backlogs
10) 2169283 Garbage Collection GARBAGE_LOB_FILES_ table-wise garbage collection
11) 2127458 Merge load/unload reason
12) 2057046 Merge critical merges
13) 2057046 auto merge decision
merge and optimize compression decision functions
14) 2340450 sync table replication Optimistic synchronous table replication
15) 2339401 Commit in autonomous transaction Commit in autonomous transaction no longer impacts temporary tables in main transaction
16) 2124112 sampling overhead High sampling overhead
17) 2124112 plan sharing type ‘SESSION LOCAL’ more efficient ‘GLOBAL’ sharing type
18) 2200772 statement routing decisions partitioning information in statement routing decisions
19) 1999880 initialize SR with binary copy
initialize a replicated system based on backup / restore

1) HANA Consistency Checks and Corruptions


Specify a specific time of day (local server time) for the alert check (SAP HANA >= SPS 12)


Specify a specific time of day (local server time) for the collector (SAP HANA >= SPS 12). This setting is applied only if the INTERVAL 1,2,3,4,6,8, 12 or 24 hours is used.

This means:


Definition of check interval in seconds (e.g. 86400 for daily execution)

2) Query result cache

Allocator: “Pool/ResultCache”
The result cache was introdruced with SPS06 and also caches view results.
Up to SPS 12 the allocator “Pool/malloc/” is also used when the query result cache is configured (indexserver.ini -> [cache] -> query_result_cache = enabled; SAP Note 2014148). With newer patch levels dedicated result cache allocators (Pool/ResultCache) are used instead.

3) Metadata cache

Allocator: “Pool/Metadata/MetadataCache/MetadataGlobalCacheSlot”
The metadata cache allocator was introduced with SPS 12 and is used to store metadata locally that otherwise has to be retrieved from a remote SAP HANA node. It can grow significantly if many DDL operations are executed, because DDL operations invalidate existing cache entries.
Before SPS 12 the metadata information was stored in temporary row tables and so the allocator Pool/RowEngine/RSTempPage was used.

Known issues in 120 – 122.03 => fixed with 122.04+

4) View cache

Allocator: “Pool/ResultCache”
This allocator stores view cache information with SPS 12 and higher. The view cache is available as of SPS 11. It is also known as result cache extension and allows to cache results on SQL views, calculation views and CDS views. This allows to get the result without repeated overhead.

The view cache can provide the following advantages:

  • Reduction of CPU consumption
  • Reduction of SAP HANA thread utilization
  • Performance improvements

5) Monitoring view for LOBs

New monitoring view: M_TABLE_LOB_STATISTICS
LOBs (large objects) are columns that are used to store a large amount of unstructured data such as text documents and images.

Starting with SPS 12 you can consider using M_TABLE_LOB_STATISTICS as a light-weight variant for M_TABLE_LOB_FILES that doesn’t show the high memory requirements.

6) MDC parameter

Parameter: global.ini -> [multidb] -> systemdb_reserved_memory
This parameter allows you to configure a minimal amount of memory (in MB) to be exclusively used by the multitenant database container system database.

7) JVM6 Kerberos

The default JVM 6 encryption configuration for Kerberos is deprecated and cannot be used with the new KRB5 version in SPS 12. For JVM 6 therefore, you need to configure a krb5.ini file (default file for Windows) or krb5.conf file (default file for Linux).

For more details for each topic just follow the corresponging note.

8) replicate parameters

Starting with SPS 12 it is possible to automatically replicate parameters from the primary to the secondary site by activating the following parameter:

global.ini -> [inifile_checker] -> replicate = ‘true’

Before SPS12 you have to configure every side for itself. If you have done a mistake you will get an alert for a parameter mismatch. With this feature this is not necessary any more.

9) alert 94

Starting with SAP HANA SPS 12 alert 94 (“Log replay backlog for system replication secondary”) reports increased log replay backlogs.
SQL: “HANA_Replication_SystemReplication_KeyFigures” displays among others the log replay backlog (REPLAY_BACKLOG_MB).

As a fallback option you can use the contents of M_SERVICE_REPLICATION to determine the log replay delay on the secondary site:


Now you can calculate the difference and multiply it with the log position size of 64 byte:


10) Garbage Collection

Up to SPS 11 the table GARBAGE_LOB_FILES_ is defined as meta data, so that table-wise garbage collection isn’t possible.
Starting with SPS 12 adjustments were done and the problem no longer exists.
Now SYS tables with the naming convention RS_LOB_GARBAGE__ are used for that purpose.

11) Merge I

If a column is loaded and unloaded purely for merge reasons, you will find the unload reason in column REASON of monitoring view M_CS_UNLOADS MERGE as of SPS 12.
See SAP Note 2057046 for more information related to SAP HANA delta merges. In former times you couldn’t find out the root cause for the unload/load of the table.

12) Merge II

Up to SAP HANA Rev. 121 critical merges are registered with MOTIVATION = ‘AUTO’ in views like M_DELTA_MERGE_STATISTICS and HOST_DELTA_MERGE_STATISTICS. Therefore you can see a merge categorized as ‘AUTO’ when a critical merge was executed (e.g. because no successful merge happened within the last 7 days).

Starting with SAP HANA Rev. 122 critical merges are recorded with MOTIVATION = ‘CRITICAL’ in M_DELTA_MERGE_STATISTICS.

13) auto merge decision

A bug with SAP HANA Rev. 120 to 122.04 can result in permanent merges of specific tables because UDIV gaps (that can only be eliminated with optimize compression) are erroneously considered as deleted main rows and so the decision function may indicate the need for a merge on a permanent basis.
As a workaround the merge and optimize compression decision functions are suggested for Rev. 120 to 122.04 => you will find it in the corresponding note.

14) Optimistic synchronous table replication

The synchronous table replication allows to replicate a table to one or several replicas synchronously. This means that the replicas are always in sync with the master table. Up to SPS 11 only the asynchronous table replication was able to use. This means the usual replication delay is significantly smaller than 1 s, but in case of overload or resource bottlenecks it can be much higher.

There have also been earlier implementations of synchronous table replication. They are deprecated as of SAP HANA SPS 12.
See SAP Note 2385974 for more details.

There is also a new monitoring view: M_TABLE_REPLICAS

15) Commit in autonomous transaction

Previously the content of temporary tables related to the main transaction was accessible by autonomous transactions. This has been corrected and so you have to materialize the content of a temporary table in a variable if you want to access it from an autonomous transaction.

16) High sampling overhead

SAP HANA calculates certain statistics ad-hoc during parsing. By optimizing any of the known issues prior SPS12 (see note 2124112), also this overhead should reduce, because less parses are required. In special situations, you can consider adjusting the statistics sampling behavior.

Starting with SPS 12 you can adjust the amount of samples for a particular SQL statement using the ESTIMATION_SAMPLES hint (SAP Note 2142945).

For example, the following hint will completely disable sampling for the query:


17) More efficient ‘GLOBAL’ sharing type

SQL plans with sharing type ‘SESSION LOCAL’ can exclusively be used by the connection that has created the SQL plan. As a consequence various plans for the same SQL statement may exist in the SQL cache at the same time and additionally parsing of the same plan is done various times for different connections. In case of complex SQL statements parsing can take significant time and so the performance can be impacted.

As of SAP HANA SPS 12 statements using global temporary tables with a defined location will use the more efficient ‘GLOBAL’ sharing type.

18) partitioning information in statement routing decisions

Partitioning information can be included in the statement routing decisions. With SAP HANA SPS 12 the following options exist:


Hash partitioning Yes Yes
Hash partitioning during split batch insert Split batch not supported Yes
Range partitioning No Yes
Range partitioning during split batch insert Split batch not supported Yes

19) initialize a replicated system based on backup / restore

Up to SPS 11 it is only possible to initialize the replication side based on an snapshot that is created via full data shipping from primary side. An initialization via backup and restore is not possible.

Starting with SPS 12 you can initialize the secondary with a binary copy (via storage snapshot or while primary site is stopped) from the primary site.

…) to be continued


2222219 – SAP HANA Errors and different Results due to Design Changes

Main blog
Shared memory
Heap memory

Update 1.1
14) – 19)

New NetWeaver Information at

Very Helpfull



User Rating: Be the first one !