Licensing is a topic which I have some points of contact in my projects. Mostly the questions are similar:
- How the system measurement is working?
- What about memory leaks? Do we pay for this peak usage?
- Do new HANA technologies / techniques such as NSE or persistent storage (aka pmem) have to be licensed and what are the effects of the license costs?
- How we can reduce the license costs?
- Which license do we need?
- What about S/4 HANA – enterprise or standard edition?
- How will the costs increase in the future?
- Direct or indirect use?
- How are the license costs composed?
To avoid answering the same questions all weeks was the reason writing this blog. So, it is also my lazyness factor not to have to repeat myself over and over again 😉
As you may know I hate to repeat already published details. I just want to summarize them and go deeper into some of them.
At first licensing is not my favourite topic and I just want to shed some light into the technical part. For sales part I have my partners or direct contacts at SAP for the customer.
Sources to start with:
- 1704499 – System Measurement for License Audit
- Measurement Guide by SAP
- Engine & Self-Declaration Product Measurement
- “What type of SAP HANA (License) do you need?” by Owen Pettiford
- “Official SAP HANA licensing Guide”
- “SAP HANA licensing models explained” by Jorge Mendes, SAP Portugal / Maxime Simon, SAP Japan
- SAP S/4HANA Licensing Model & Conversions
At first we have to know that in the old MDC days the system measurement was performaed on the system database. Since SAP HANA 2.0 SPS01, a MDC system performs measurements in the System database as well as in the individual tenant databases.
The named statement in 1704499 will show you the current license memory utilization of particular tenant database:
SELECT ROUND((SUM(SM.HEAP_MEMORY_USED_SIZE) + SUM(SM.SHARED_MEMORY_USED_SIZE)) / 1024 / 1024 / 1024, 0) + ROUND(MAX(SM.CODE_SIZE) / 1024 / 1024 / 1024, 0) AS DATABASE_MEMORY_USED_IN_GIGABYTES FROM SYS.M_SERVICE_MEMORY SM JOIN SYS.M_SERVICES S ON SM.HOST = S.HOST AND SM.PORT = S.PORT WHERE S.COORDINATOR_TYPE != 'STANDBY'
But what is included there? We need to know what is heap and shared memory.
Because I don’t want to repeat myself
The short answer SAP counts the heap, shared memory + code and stack for the license measurement.
The measurement consists of the used memory not the maximal memory which CAN be loaded. It is the peak of this 3 components. The monthly peak of this sum will be written to M_LICENSE_USAGE_HISTORY. If you want to check all the measurements over time you can use view M_LICENSE_MEASUREMENTS. Every hour the current peak value will be written to it.
SELECT ROUND( ( SUM(SM.HEAP_MEMORY_USED_SIZE) + SUM(SM.SHARED_MEMORY_USED_SIZE) ) / 1024 / 1024 / 1024, 0 ) + ROUND( MAX(SM.CODE_SIZE) / 1024 / 1024 / 1024, 0 ) AS DATABASE_MEMORY_USED_IN_GIGABYTES, ROUND( SUM(SM.HEAP_MEMORY_USED_SIZE) / 1024 / 1024 / 1024, 0 ) AS heap, ROUND( SUM(SM.SHARED_MEMORY_USED_SIZE) / 1024 / 1024 / 1024, 0 ) AS shared, ROUND( MAX(SM.CODE_SIZE) / 1024 / 1024 / 1024, 0 ) AS code FROM SYS.M_SERVICE_MEMORY AS SM INNER JOIN SYS.M_SERVICES AS S ON SM.HOST = S.HOST AND SM.PORT = S.PORT WHERE S.COORDINATOR_TYPE != 'STANDBY';
This means to lower the costs you should lower this memory areas.
1) Code – there is nothing you can do regarding code an stack
2) Shared memory = row store
We can break down this by service:
SELECT s.service_name, ROUND(sm.total_memory_used_size / 1024 / 1024 / 1024,0) as total_memory_used_size, ROUND(SM.SHARED_MEMORY_USED_SIZE / 1024 / 1024 / 1024 ,0) AS Shared, ROUND(SM.HEAP_MEMORY_USED_SIZE / 1024 / 1024 / 1024 ,0) AS Heap, ROUND(SM.CODE_SIZE / 1024 / 1024 / 1024 , 0 ) AS code FROM SYS.M_SERVICE_MEMORY AS SM INNER JOIN SYS.M_SERVICES AS S ON SM.HOST = S.HOST AND SM.PORT = S.PORT WHERE S.COORDINATOR_TYPE != 'STANDBY';
Don’t be confused by the ‘total_memory_used_size’. This is not the size of the measurement. It is just an indicator for the current memory usage.
The shared value of the M_Service_memory consists of (Details: SQL:HANA_RowStore_Overview / Views: M_RS_MEMORY / M_RS_TABLES ):
=> 96GB (Shared Memory value)
Take care of your RS tables and check the reorg need from time to time. In the latest SPS there is a automatical reorg feature.
Shared_GB , INDEX_GB and Extfrag_GB is not counted into.
The Heap consists of the loaded CS tables, row store indexes, Intermediate results, temporary structures, caches.
Wait we talked about the row store and it is linked to shared memory segments which results in non swappable structures. Why is it listed as heap allocator?
Anwer: The Pool Allocator Pool/RowEngine/CpbTree is part of the heap which results in swappable structures. (Details: 2160391 – FAQ: SAP HANA Indexes 14. / 1999997 – FAQ: SAP HANA Memory : Pool/RowEngine/CpbTree) This means that the RS index structures are not organized as shared memory segments. They have another design as the source RS data.
HANA_Memory_TopConsumers => Aggregate_By ‘SubArea’
However, the best way is to archive/delete data from CS and RS, but what about Intermediate results, temporary structures and caches?
In this example we see about 800GB of System Heap, 270GB of Intermediate results, 185GB fragmentation.
1) Intermediate results
Ok, the results can only be limited if you use the workload management, but in the most scenarios (SAP application/product based) this value is not avoidable.
How heap fragmentation can be managed you can read in 1999997 – FAQ: SAP HANA Memory => What is memory garbage collection?
|hdbcons ‘mm gc -f’
use the parameters gc_unused_memory_threshold_abs / gc_unused_memory_threshold_rel if you want to intervene.
3) System Heap
The greatest lever can be achieved if you analyze the system heap.
HANA_Memory_TopConsumers => Aggregate_By SUBAREA => in this case ‘Heap (System)’
You can see that the Top 3 of the 800GB consists of default/LPA aka Page Cache. Nearly 600GB are working space which can be configured.
Ok, this was the long answer of ‘How the system measurement is working?‘, but it answers also the question ‘What about memory leaks? Do we pay for this peak usage?‘ 🙂
Yes, if you can’t give a reason for it and the peak is over a longer time, you have to pay for it.
There are several areas which can be configured to lower the memory usage. Use them to reduce your costs!
Do new HANA technologies / techniques such as NSE or persistent storage (also known as pmem) have to be licensed and what are the effects of the license costs?
pmem reduces the TCO of hardware (RAM) but has nothing to do with the license costs of HANA.
Another topic is NSE. You only pay for the buffer cache and not for the warm store on disk. So, yes, you can reduce your license costs with NSE. You can also save hardware costs for the future growth of the DB.
How we can reduce the license costs?
- Archiving / deletion
- configure your system correct
- frequent HANA health checks to discover bugs
- use NSE
Which license do we need?
This depends on how you use the HANA. Please check the licensing Guide.
First check if you use on prem / priv. cloud or public cloud.
Do you use sofware licensed from SAP (runtime database) or a non-SAP/native software (=Full-use database)?
The Full use is devided into Enterprise and Standard edition. This means it also depends on the engines you want to use.
Do you want to use HSR with active/active? Yes? This is also a functionality you have to pay on top.
Source: SAP licensing guide
What about S/4 HANA – enterprise or standard edition?
Source: SAP HANA, Enterprise Edition for SAP S/4HANA , SAP HANA 2.0 Certification Guide: Technology Associate Exam (C_HANATEC_17) (SAP PRESS)
You can not use the standard edition for S/4HANA. Only the enterprise edition can be used for S4.
How will the costs increase in the future?
I have no glass sphere for you, but if you create frequent heath checks of your DB you will receive a linear growth of your database which is a good cost indicator. But there are so many factors you have to consider. It depends on the used revision, functionality, configuration, fragmentation and some more.
Direct or indirect use?
Indirect or digital access is when people or things use the digital core without logging into the system directly. It occurs when humans or any device or system indirectly use the digital core through non-SAP intermediary software, such as a front end, a custom solution, or any other third-party application. It also occurs when nonhuman devices, bots, automated systems, and so on use the digital core in any way.
Historically, any use of our digital core – either direct or indirect – was licensed through SAP Named User licenses and/or software on a user metric. The new pricing approach differentiates between direct human access (pricing continues to be user based) and indirect digital access (pricing is based on the number of transactions, called documents, processed within the digital core).
Source SAP licensing guide / SAP News / Indirect Usage Guide
How are the license costs composed?
|In the first year you pay a one time license fee + annual recurring fee. In the following years you only pay the maintenance and support fee which is x% of the license fee.|
Source: SAP licensing guide
In the end we know that all caches (if we need them or not) are taken into account. Housekeeping is not only nice to have, it can save a lot of money. Not only the data loaded into memory is important, also the caches and the rest of the working space will be considered. So, tuning your systems results in lower license costs.
Do you have other questions which I should add? Just drop a comment with your question.