XLC: SAP HANA News

FAQ: SUSE Hypervisor for SAP (KVM)

Tue, 14 Apr 2026 15:31:08 GMT

KVM as alternative with low TCO

KVM is besides VMware and PowerVM the only certified virtualization alternative for SAP HANA. Be aware that RHEL KVM is not supported anymore for productive usage. Only SUSE KVM can be used for productive SAP HANA workloads to be certified and supported.

Within this article we will clarify the most frequent ask questions we are facing within our customer projects. Currently a lot of questions are rising and not each customer scenario can be covered. This also means that the list will be updated in the future.

1.What KVM stands for?

KVM is an acronym for Kernel-based Virtual Machine. Like ESXi KVM is running as linux on top of the bare metal server as hypervisor to create the foundation to create multiple VMs. The official product name in the SAP context for KVM is SUSE Hypervisor for SAP. This is the reason we are using this wording in this article.

2. Is SUSE Hypervisor for SAP certified for SAP HANA?

Yes, it is. But there are as always some restrictions and dependencies with each release. Currently (04/2026) KVM with SLES 15 SP4 and SLES 15 SP5 are supported to use it as production environment for SAP HANA. Please always check which SLES versions can run on top of the used KVM version.

3. Which hardware can be used for SUSE Hypervisor for SAP?

Only specific processor generations of Intel are certified for productive usage connected with the certification of the specific KVM release (SLES as hypervisor). This is the current roadmap which is subject to change. You can verify the current status via SAP Note 3430656 :

KVM hypervisor as part of SUSE Linux Enterprise Version for SAP Applications 15 SP4 - See SAP Note 3366235 for specific information and constraints.
KVM hypervisor as part of SUSE Linux Enterprise Version for SAP Applications 15 SP5 - See SAP Note 3538596 for specific information and constraints.

This means in other words for the Intel Generations:

4. Which subscription is needed?

To use SUSE Hypervisor for SAP (KVM) as hypervisor for SAP HANA or SAP Application servers you need an "Unlimited Virtual Machines" subscription. You can only use it in connection with a SUSE Linux Enterprise Server for SAP applications 15 SPx "Unlimited Virtual Machines" subscription. This means SLES4SAP is mandatory!

5. Which sizing rules I have to consider?

It is nearly the same like for VMware. You can only scale with full sockets. You cannot use half sockets or NUMA node sharing. With VMware you could use half NUMA nodes or COD/SNC. This is currently not supported / certified.

It is recommended to reserve a minimum of about 8% of the hosts’s main memory for the hypervisor.

The hypervisor will consume CPU capacity, approximately 5% to 10% of the SAPS capacity, depending on the workload characteristics:

5% of the SAPS capacity for mainly analytical workloads
10% of the SAPS capacity for mainly transactional workloads

It is however not required to dedicate CPUs to the hypervisor.

Since SAP HANA runs inside the VM, it is the RAM size of the VM which needs to satisfy the memory requirements of the SAP HANA Memory sizing.

The memory used by the VM must be smaller than the physical memory of the machine. It is recommended to reserve at least 8% of the total memory reported by “/proc/meminfo” (in the “MemTotal” field) for the hypervisor. This leaves ~ 92% to the VM.

Please be aware that you only can use full sockets. If you have a 2 Socket Emerald Rapid host with 4 TiB. You can run max. productive 2 VMs. One VM per socket.

4 TiB / 2 = 2 TiB

2 TiB * 0.92 = 1.84 TiB

The max. memory you can assign to both VMs are 1.84 TiB of memory. If you just want to run 1 big VM: 4 TiB * 0.92 = 3.68 TiB.

If you SAP HANA sizing is above 1.84TiB you have two options:

use both sockets and waste resources
optimize the sizing with data tiering methods

SBP-SLES4SAP-HANAonKVM-SLES15SP5 - memory-to-core ratio examples

Another example with Skylake processor (keep in mind - only supported with SUSE KVM Virtualization with SLES 15 SP4):

6. Which are the most popular limitations for SUSE KVM (SUSE Hypervisor for SAP)?

Currently only SLES15 SP4 + 5 as hypervisor version supported
no NUMA node sharing
no live migration for SAP HANA (for application server you can use it)
no scale-out support
no Ice Lake support
Mostly 4 socket support of Intel generations
no support for > 8TB+
minimum size of an SAP HANA instance in a virtual machine on SUSE KVM is 8 vCPUs based on 8 physical cores and 128 GB
KVM HA is not supported. Solutions based on HA solutions for automated SAP HANA system replication in HANA scale-up are supported.

7. What are the main differences between VMware and SUSE Hypervisor for SAP?

SUSE is only offering a virtualization solution. It means that there a feature gaps if you compare the two products. VMware/Broadcom is covering a way more features as bundle within the new licensing model. For instance this includes for the SUSE KVM no UI for administration/monitoring and some features like Fault Tolerance (FT), vMotion or NSX are currently not part of the product, not certified or even planned. If you are already using such features and want to stick to them you cannot easily replace this products. If you are just using VMware as simple virtualization layer the SUSE option with KVM may be an alternative for you.

8. How you can migrate your workload?

Option 1: Simple Backup / restore

Option 2: HSR

Option 3: Storage move (not officially supported)

9. What migration scenarios exist?

Scenario 1 : wide VMs

 Scenario 2: half socket HANA VMs

 Scenario 3 : optimize sizings for big instances (8TB+)

First optimize you sizing before you migrate the workload. You can achieve a saving of up to 40% with data tiering methods like NSE, Inverted Individual Indexes, VARBINARY to LOB and other possibilities to reduce the instance sizing for HANA.

10. Which features besides pure virtualization are provided by SUSE Hypervisor for SAP?

migration capabilities
live migration
snapshots
monitoring
cloning

11. Which migration capabilities are offered?

Live migration

The source VM continues to run while its configuration and memory are transferred to the target host. When the transfer is complete, the source VM is suspended and the target VM is resumed.

Live migration is useful for VMs that need to be online without any downtime. It is not supported for productive SAP HANA systems. You can use it for non-productive systems or application server workload in the SAP context.

Non-live migration

The source VM is suspended and its configuration and memory are transferred to the target host. Then the target VM is resumed.

Non-live migration is more reliable than live migration, although it creates downtime for the VM. If downtime is tolerable, non-live migration can be an option for VMs that are difficult to live migrate.

Offline migration

The VM definition is transferred to the target host. The source VM is not stopped and the target VM is not resumed.

Offline migration can be used to migrate inactive VMs.

Xen to KVM migration

As the KVM virtualization solution is becoming more and more popular among server administrators, many of them need a path to migrate their existing Xen based environments to KVM. As of now, there are no mature tools to automatically convert Xen VMs to KVM. There is, however, a technical solution that helps convert Xen virtual machines to KVM.

The migration procedure via virt-v2v described by the SUSE documentation is not fully supported by SUSE.

12. How snapshots can be used with KVM?

VM Guest snapshots are snapshots of the complete virtual machine including the state of CPU, RAM, devices and the content of all writable disks. To use virtual machine snapshots, all the attached hard disks need to use the qcow2 disk image format, and at least one of them needs to be writable.

Snapshots let you restore the state of the machine at a particular point in time. This is useful when undoing a faulty configuration or the installation of a lot of packages. After starting a snapshot that was created while the VM Guest was shut off, you need to boot it. Any changes written to the disk afterward are lost when starting the snapshot.

Attention:

Snapshots are supported on KVM VM Host Servers only.

Internal snapshots

Snapshots that are saved into the qcow2 file of the original VM Guest. The file holds both the saved state of the snapshot and the changes made since the snapshot was taken. The main advantage of internal snapshots is that they are all stored in one file and therefore it is easy to copy or move them across multiple machines.

External snapshots

When creating an external snapshot, the original qcow2 file is saved and made read-only, while a new qcow2 file is created to hold the changes. The original file is sometimes called a backing or base file, while the new file with all the changes is called an overlay or derived file. External snapshots are useful when performing backups of VM Guests. However, external snapshots are not supported by Virtual Machine Manager, and cannot be deleted by virsh directly.

Live snapshots

Snapshots created when the original VM Guest is running. Internal live snapshots support saving the devices, and memory and disk states, while external live snapshots with virsh support saving either the memory state, or the disk state, or both.

Offline snapshots

Snapshots created from a VM Guest that is shut off. This ensures data integrity as all the guest's processes are stopped and no memory is in use.

13. Which tools are provided by SUSE for administration / monitoring?

Virtualization console tools

virsh (Package: libvirt-client)

A command-line tool to manage VM Guests with similar functionality as the Virtual Machine Manager. virsh allows you to change a VM Guest's status, set up new guests and devices, or edit existing configurations. virsh is also useful to script VM Guest management operations.

virt-install (Package: virt-install)

A command-line tool for creating new VM Guests using the libvirt library. It supports graphical installations via VNC or SPICE protocols. Given suitable command-line arguments, virt-install can run unattended. This allows for easy automation of guest installs. virt-install is the default installation tool used by the Virtual Machine Manager.

remote-viewer (Package: virt-viewer)

A simple viewer of a remote desktop. It supports SPICE and VNC protocols.

virt-clone (Package: virt-install)

A tool for cloning existing virtual machine images using the libvirt hypervisor management library.

virt-host-validate (Package: libvirt-client)

A tool that validates whether the host is configured in a suitable way to run libvirt hypervisor drivers.

virt-top

virt-top is a command-line tool similar to the well-known process monitoring tool top

Virtualization GUI tools

The following libvirt-based graphical tools are available on SUSE Linux Enterprise Server. All tools are provided by packages carrying the tool's name.

Virtual Machine Manager (package: virt-manager)

The Virtual Machine Manager is a desktop tool for managing VM Guests. It provides the ability to control the lifecycle of existing machines (start/shutdown, pause/resume, save/restore) and create new VM Guests. It allows managing multiple types of storage and virtual networks. It provides access to the graphical console of VM Guests with a built-in VNC viewer and can be used to view performance statistics. virt-manager supports connecting to a local libvirtd , managing a local VM Host Server, or a remote libvirtd managing a remote VM Host Server.

Monitoring with `virt-top`

virt-top is a command-line tool similar to the well-known process monitoring tool top . virt-top uses libvirt and therefore is capable of showing statistics for VM Guests running on different hypervisors. It is recommended to use virt-top instead of hypervisor-specific tools like xentop .

By default virt-top shows statistics for all running VM Guests. Among the data that is displayed is the percentage of memory used ( %MEM ) and CPU ( %CPU ) and the uptime of the guest ( TIME ). The data is updated regularly (every three seconds by default). The following shows the output on a VM Host Server with seven VM Guests, four of them inactive:

Sources

SUSE Best Practices for SAP HANA on KVM SLES4SAP 15 SP4

SUSE Best Practices for SAP HANA on KVM SLES4SAP 15 SP5

3366235 - SAP HANA on SUSE KVM Virtualization with SLES 15 SP4

3538596 - SAP HANA on SUSE KVM Virtualization with SLES 15 SP5

Data Tiering case study part II: Inverted Individual Indexes

Mon, 06 Apr 2026 07:49:17 GMT

Inv Idv Idx - Inverted Individual Indexes - warm data

An inverted individual index is a special type of SAP HANA index which can only cover unique indexes. This includes all primary key structures. Unlike traditional column store indexes on more than one column (inverted value, inverted hash) an inverted individual index (Inv Idv Idx) doesn't need a dedicated concat attribute.

Why Inv Idv Idx are relevant for data tiering purposes?

Significantly reduced memory footprint due to absence of concat attribute
Less I/O in terms of data and redo logs
Reduced table optimization efforts
DML change operations can be faster due to reduced concat attribute maintenance

What influence can such indexes have on the sizing?

40-50% of S/4HANA systems can consists of indexes. Mostly of the indexes are primary keys, but there are also some secondary indexes which are in the most cases not unique indexes. This means indexes have an overall impact of 30-40% on the sizing. It depends on the size of the unique indexes. This can vary for each system.

Why is it not sensible to convert every unique index?

It is possible to convert every unique index but as always it is a trade-off between savings and performance. It depends on the mixture of filter of the critical SQL workload. If the filters are part of the index and one of the columns is also very selective, it might makes no difference in terms of performance.

How much memory can be saved with Inv Idv Idx?

It depends on each system, the workload and the distinct values of the column of the unique indexes. But as average we observed 11% savings in the payload.

The smallest saving was 5% and the peak saving 15% of the CS payload.

In total we could save round about 1.2TB memory out of 8.9TB which is percentage 13.5%.

For which systems the Inverted Individual Indexes can be used?

They are supported in any HANA system. The definition is possible in SE11. For BW/4HANA systems they are available in BW designer via the name “Memory-optimized Primary Key Structure”.

The good aspect on this part of data tiering is that it can be analyzed and implemented quite fast. But it must be tested well as every implementation.

If you are interested in more details, you can have a look at the general SAP Note 2600076 or our book “HANA deep dive” which will be released in a few weeks (it is already available in German).

Summary

Both data tiering methods, NSE and Inv Idv Idx, can cut your sizing more than half. In our customer case we observed payload savings of 42% and 69%. This means it is depending on the performance. Within the current times the needed resources can be quite expensive. These two aspects of data tiering are the most weighted once. Comparing the costs of a data tiering projects and the savings it is fast ROI calculation. The point in time of such a project can be quite important. For instance, the procurement of new hardware or the migration to the cloud or beginning a RISE journey. It can save immense costs if such a project can cut the sizing before such contracts are signed.

Data Tiering case study part I: NSE

Sun, 05 Apr 2026 15:16:25 GMT

NSE - Native Storage extension - warm data

Data tiering has become increasingly important in the operation of SAP HANA databases in recent years. Why? Since then, more and more systems have required HANA as a prerequisite. Furthermore, data inflow has also increased significantly. There are more and more connected systems feeding data into the database. The result is unplanned growth, leading to increased resource consumption, resizing, and consequently, significantly higher operating costs.

This leads to some questions for every SAP customer running HANA systems:

1. Do you know your operating costs per GB of RAM?

2. Do you know your inflow and outflow of data per year?

3. How long will your sizes continue to meet the requirements?

4. Are you fully utilizing your data tiering capabilities?

These questions ultimately lead to an important question due to the recent changes in legislation: Do you know the CO2 emissions per system and is your measurement suitable for an audit under the CSRD (Sustainable Corporate Reporting Directive)?

But first things first: What exactly is meant by data tiering in the SAP universe? Looking at the SAP documentation ( *1 , *2 , *3 ) quickly leads to the topic of multi-temperature storage strategy.

SAP defines this as:

1. Hot Data: Column Store (HANA in-memory)

2. Warm Data: NSE (Native Storage Extension) or Extension Nodes (BW scale-out)

3. Cold Data: Data Tiering with external storage such as NLS (Near-Line Storage)

At XLC, we take data tiering a step further, focusing on the optimal utilization of available resources. Ultimately, this allows us to optimize current sizing without the need to purchase expensive new hardware.

What approaches or features do we use for this, in addition to the well-known NSE and NLS?

Use of Inverted Individual Indexes (optimized indexes without significant persistence overhead)
Use of Workload Management (restricting resources on unimportant processes and prioritizing important/critical processes), including HANA parameterization
Optimization of partitioning (avoiding suboptimal dictionaries through multi-column designs)
BW: Optimization of key fields and concat attributes
Deletion of unnecessary indexes from anyDB time
Correct sizing without peak sizing (=SAP sizing report)
VARBINARY to LOB conversion
and many more

We are dividing our data tiering projects into 2-3 phases:

NSE wave I: technical tables (discovery phase with health checks and implementation of uncritical tables)
NSE wave II: business tables (conservative variant)
review / change design (aggressive variant)

In one of our projects last year, we could achieve impressive savings on multiple systems. The following case study summary provides an overview of the challenge the client faced, how we achieved the savings, and the ultimate impact of all measures on costs.

Customer case

Environment:

5x SAP production systems (~15TB)
10x HSR (secondary and tertiary of production systems) (~30TB)
10x SAP non-production systems (~20TB)
Platform: AS Azure (Europe: Amsterdam)

Challenge:

rising costs
high data inflow rates
no data tiering strategy

Goals:

optimizing instance costs
create proper sizing forecast
no performance impact for business-critical workload
legal retention obligations
proper scaling of systems
Low-effort operating concept

This means a reduction of the sizing results in a factor x4 for this environment. 3x PRD (primary, secondary and tertiary) + 1 QAS

Phase 1

In the first phase we created a system health check, analysed the workload and created a sizing. As part of this phase the technical tables (=NSE wave I) which normally are not part of critical workload are activated for NSE. The workload will be divided into business-critical and uncritical. Peaks will be analysed and mapped to workload classes if needed or optimized. This data will be used for phase 2 and the business-critical workload. A mapping together with the customer is elementary to prioritize and question the workload in detail.

Duration until implementation in production for technical tables (=NSE wave I): 4 weeks

Phase 2

The SQLs of each object business-critical will be analysed with a heatmap. A design with different variants will be created based on the details like SQL where clauses, CPU / memory resources, usage of indexes, materialization of columns, read and write rates. Mostly a moderate design with low risk will be used as design in this phase.

Duration until implementation in production (=NSE wave II): 6 weeks

Phase 3

After implementing the designs, the review of the performance, calculate the sizing and a forecast are part of it. If a design has a massive negative impact to the performance, a fallback to the old design hast to be done. Over time the design can also be adapted from conservative, moderate to aggressive.

NSE wording definitions

To interpret all figures correct you have to differ some of them and define the meaning and how they are calculated.

CS payload = all CS data in the system

NSE BC = NSE buffer cache

Paged data = CS data (payload) paged out as NSE data

NSE payload savings = paged data – NSE BC

NSE savings in sizing = paged data * 2 – NSE BC

Results and savings

In average the CS payload could be reduced by 41%. For one system we could reduce the payload by 56%! This is called the amount of paged data, but in the end not the savings:

PRD1: 50%
PRD2: 30%
PRD3: 56%
PRD4: 46%
PRD5: 23%

Only considering the reduction in the productive systems we could achieve a total NSE paged data of about 4TB. Since all systems were replicated twice the savings could be tripled.

The NSE paged data of the payload represents not the saving within the sizing. Due to the fact that for the SAP sizing the CS payload will be doubled it would nearly double the savings. Why only nearly? You need a certain amount of NSE buffer cache which reduces the savings.

A total NSE saving of more than 7TB for the 5 productive systems could be achieved. This is a moving target because this was the snapshot at the time of measurement. Due to the inflow of data we already reached 8TB of savings after 6 months. This means it is not an one time saving. It will help you over time to reduce the HANA sizing as well.

In the end the NSE savings reached nearly 30TB considering the fact of HSR and QAS systems.

Summary

With NSE you can achieve between 30-60% of reduction of the payload. It is a quite easy method to save some memory if it is done in a structured way. There is risk to impact the performance which should always avoided – especially for the business-critical workload. In our cases the impact varied from 2 – 8%. You can also try the NSE advisor, which is free of charge, but it won’t rate your SQL workload and give you partition instructions.

Also, this means not that you can reduce the sizing by these values. This means also that you cannot easy change the instance size. You have to consider also other facts like LOB, SQL workload, inflow and outflow (archiving). If you are not considering this it will not lead to a successful project.

During our NSE phase one we are also creating a health check report for each system. In this phase we identified some SQL workload issues and some more potentials for inverted individual indexes.

The next part of the blog series will cover inverted individual indexes, HANA sizing and CO2 emission + cost calculation. Not every saving always results in an instance resizing. You have to consider the CPU load and the future growth of the system. Our sizing calculation will be covered by Arwel Owen .

Performance issues with THP on multi-NUMA node systems

Mon, 30 Mar 2026 09:29:18 GMT

THP issues with kernels before February 2026

We have multiple customers running systems on hardware with multiple sockets (4+) and with SLES as OS. With the latest change of SAP HANA 2.0 SPS08 to support THP this can cause some trouble with the usage of SLES 15 SP5 and higher.

The SUSE SUSE KBA 22286 describes this problem in detail.

Who is affected?

Customers running HANA 2.0 SPS08
Customer running hardware with more or equal than 4 sockets
SLES 15 SP5 / SLES for SAP 15 SP5 < kernel-default-5.14.21-150500.55.136.1 (Feb-12-2026: kernel-default-5.14.21-150500.55.136.default)
SLES 15 SP5 / SLES for SAP 15 SP6 < kernel-default-6.4.0-150600.23.87.1 (Feb-12-2026: kernel-default-6.4.0-150600.23.87.default)
SLES 15 SP5 / SLES for SAP 15 SP7 < kernel-default-6.4.0-150700.53.31.1 (Feb-11-2026: kernel-default-6.4.0-150700.53.31.default)
Customer running a lower version of saptune 3.2.2

Customers which are regularly patching there systems are fine. The new kernel versions released in February 2026 are including the fix. But please keep in mind even if you are patching you systems and still running saptune 3.2.2 you have to manually revert the workaround. This version of saptune is just implementing the workaround independent of the used kernel version. Beginning with saptune 3.2.3 (not yet released, status of 15-04-2026: Pre-release) it will include an automatic check.

After installing the fixed kernel and rebooting, defrag should remain ON (madvise) as per the SAP-recommended settings in SAP Note 2131662 :

/sys/kernel/mm/transparent_hugepage/defrag => madvise /sys/kernel/mm/transparent_hugepage/enabled => madvise /sys/kernel/mm/transparent_hugepage/khugepaged/defrag => 1

How you can check if you are affected? You observe performance issues, memory imbalance and with it memory pressure for selective nodes. As result THP allocations can trigger unexpected direct reclaim and compaction/memory defragmentation, even though other NUMA nodes may have plenty of free memory.

# cat /sys/devices/system/node/node*/meminfo | grep MemFree

This imbalance where one node is low on memory while others have plenty of free memory is what triggers the problematic direct reclaim behavior.

This issue became prominent starting with SLES 15 SP5 and HANA 2 SPS08, when SAP Note 2131662 changed the recommendation to enable THP with "madvise". Prior to SLES 15 SP5, SAP HANA systems had THP disabled entirely. If your system shows [never] for THP, no action is needed:

# cat /sys/kernel/mm/transparent_hugepage/enabled

always madvise [never]

Temporary workaround for systems not yet updated to the fixed kernel:

If the system cannot be updated to the fixed kernel yet and the symptoms described above are observed, disable THP defragmentation while preserving opportunistic THP usage. This can be done manually or via saptune.

Manual (applied live, no reboot, no HA cluster or HANA restart required):

# echo "never" > /sys/kernel/mm/transparent_hugepage/defrag

# echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

Saptune 3.2.2+ ships Note HotFix000022286 as part of the Solutions HANA, NETWEAVER+HANA, S4HANA-APP+DB and S4HANA-DBSERVER. To apply:

# saptune note apply HotFix000022286

# saptune verify applied

Why NUMA node 0 is often affected first:

NUMA node 0 often experiences a disproportionate impact because PCI devices, such as those for LAN or DISK, are frequently configured to point to it, and user-space applications often default their installation to this same node. Consequently, all requests for LAN or DISK from other NUMA nodes will be routed through NUMA node 0 if that's where the necessary drivers are configured.

To review your driver configuration:

Kernel versions

Sources:

SUSE KBA 22286 : SAP HANA swap and system hangs with THP on multi-NUMA node systems

saptune 3.2.2 : Github

SAP Note 2131662 - Transparent Huge Pages (THP) on SAP HANA Servers

SAP Note 2578899 - SUSE Linux Enterprise Server 15: Installation Note

SAP Note 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15

SAP HANA & Transparent Huge Pages (THP

Mon, 26 Jan 2026 14:24:56 GMT

Switched to madvise in 2025 - now this?

If you’re running SAP HANA on SLES 15 SP5-SP7, keep an eye on this new SUSE article 22286 :
�� Transparent Huge Pages (THP) with madvise can trigger high swap usage, performance issues, or even system hangs on multi-NUMA systems.

Why this matters:
- SAP recommended switching to THP = madvise (SAP Note 2131662 ) for SLES15 SP5 / RHEL 9.2 and higher
- On multi-NUMA nodes, this can backfire
- One NUMA node runs low on memory -> direct reclaim & compaction kick in
- Result: swap fills, reclaim spikes, HANA stalls or failover

You can find out if THP is active by command:

cat /sys/kernel/mm/transparent_hugepage/enabled

If you see the following result, the THP is active.

[always] madvise never

If the OS version is

SLES 15 SP5 and
RHEL 9.2

or higher, then THP is recommended to be active.

Typical red flags:
- Swap usage grows while other NUMA nodes still have free memory
- High direct reclaim activity: pgscand/s spikes in sar -B output.
- Counters like allocstall_movable, pgscan_direct, compact_stall increase (/proc/vmstat)
- System hangs under load or cluster failover

Status:

After installing the fixed kernel and rebooting, defrag should remain ON (madvise) as per the SAP-recommended settings in SAP Note 2131662 :

/sys/kernel/mm/transparent_hugepage/defrag => madvise /sys/kernel/mm/transparent_hugepage/enabled => madvise /sys/kernel/mm/transparent_hugepage/khugepaged/defrag => 1

On multi-NUMA node systems high swap usage, hangs or performance issues were reported when THP was enabled due to an OS kernel issue. An OS kernel is currently being developed. So far, it is recommended to deactivate THP defragmentation on OS level by executing:

echo "never" > /sys/kernel/mm/transparent_hugepage/defrag

echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

�� Not affected:
- Single-NUMA systems
- Older SLES versions with THP fully disabled

- RHEL (currently no feedback and proven)

Bottom line:
Check your NUMA balance before HANA does it the hard way.

Sources:

2131662 - Transparent Huge Pages (THP) on SAP HANA Servers
https://me.sap.com/notes/2131662/E
3523701 - Transparent Huge Pages (THP) alert occurs
https://me.sap.com/notes/3523701/E
2031375 - SAP HANA: Transparent HugePages (THP) setting on Linux
https://me.sap.com/notes/0002031375
2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15
https://me.sap.com/notes/2684254
2578899 - SUSE Linux Enterprise Server 15: Installation Note
https://me.sap.com/notes/2578899
SAP HANA swap and system hangs with THP on multi-NUMA node systems
https://support.scc.suse.com/s/kb/SAP-HANA-swap-and-system-hangs-with-THP-on-multi-NUMA-node-systems?language=en_US

Ongoing HANA HEX performance issues with SPS07+SPS08

Fri, 09 Jan 2026 06:30:14 GMT

The HEX engine strikes back - again

I personally love the current statement in the SAP HANA troubleshooting guide regarding HEX:

"In SAP HANA, the SQL query processor parses SQL statements and generates SQL query execution plans.

As the query processor and the query optimizer continue to be developed (in, for example, the new HANA

Execution Engine - HEX) the resultant execution plans for a given query may change from one HANA release to

another, or the plan may change because the data being queried has been reorganized ; it is therefore possible

that the performance of an SQL query statement may degrade ."

With SPS06 and even more so with SPS07, the HEX engine was used more frequently. This results on the one hand side in easy scenario to perfect results with lower memory and CPU consumption ending up in faster response times. But in scenarios with FAE (for all entries) together with FDA (fast data access), it can result in bad performance. We faced scenarios with 10x times more runtime and +30% CPU load. There are also other scenarios, please have a look at the table below. After some customers upgraded their first systems to SPS07 I recommended to wait for Rev. 73/74, but some started early with Rev. 71/72 and we had to troubleshoot many statements. If you have similar performance issues after the upgrade to SPS07 feel free to contact us!

Our current recommendation is to use min. Rev. 79.05 with some workarounds . The performance degradation is extreme in systems like EWM and BW with high analytical workload, but also a lot of S/4 systems are affected. Some issues can only be fixed with an update. This means no workaround!

There are also cases in SAP standard coding that can be solved using always the latest SAP's delivered statement hints ( 2700051 ) or by implementing SAP notes for adding an ABAP hint (e.g. 3359519 ). We are checking this performance aspects in our health check services . If you want to be on the safe side, contact us - it's better to be safe than sorry.

While reading the ABAP hint fixes which are delivered by SAP via SP or note you can read interesting reasons besides the normal "performance improvement:"

"Default optimizations do not work due to HANA engine complexity ."

"The HANA optimizer used a wrong plan . As of now DB Hint USE_HEX_PLAN is used for performance reasons."

"The optimal HANA HEX execution engine is not always used for these SQLs in HANA <= SPS07 as due to safety limits a fallback compile to the COLUMN,ESX engines is done."

### Update 05 / 2025 ###

Starting with Rev. 76, the problems became less. But in recent weeks, more and more customers have updated to SPS07 with special scenarios (e.g. fiori) and again raised many new problems. The new recommendation is to use at least Rev. 79.02 with workarounds.

### Update 01 / 2026 ###

The new recommendation is to use at least Rev. 79.05 or 89 with workarounds.

Here we collected some of the current notes which affecting the performance of the system in the context of HEX [status: 09-01-2026]:

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

Source: SAP HANA Performance Guide for Developers

latest HEX issues

HEX Issue not fixed

older HEX issues

Some statistics on the current support S/4HANA releases:

S/4 Release details

DB Hint issues*

number of fixes for HEX performance issues in S/4*

statistic of number of fixes and their related SPS*

You can see that the most fixes were applied in the latest SPS (e.g. S/4 HANA 2022 SPS04 - SAPK-10704INS4CORE which was released in 07/2024). This means a lot of customers are currently affected by the performance issues and can only apply the single notes!

*The statistics figures are without guarantee and subject to change

HANA NSE - technical details Q&A

Mon, 24 Nov 2025 14:52:39 GMT

HANA NSE - technical details

SAP NSE was introduced with HANA 2.0 SPS04 and based on a similar approach like data aging. Data aging based on a application level approach which has a side effect if you are using a lot of Z-coding. You have to use special BADI's to access the correct data. This means you have to adapt your coding if you are using it for Z-tables or using not SAP standard functions for accessing the data in your Z-coding. This was big hurdle to use this feature. But in this blog I don't want to talk about old stuff, because there are a lot of information already out there in form of blogs ( SAP HANA Native Storage Extension: A Native Warm Data Tiering Solution by Robert Waywell [April 16, 2019]; SAP HANA Native Storage Extension(NSE) – Increase HANA Data Capacity With Warm Storage by jeetkapase [July 22, 2019], NSE: Systematically Measure Memory Savings by danielsblog01 [September 7, 2021]), documentation , slides and technical guides . This means this blog series will not cover general stuff, but will focus on technical details and limitation which I have already encountered in my projects.

Currently recommended revisions to use NSE stable:
SPS07: 79.07+

SPS08: 88+
Please follow SAP note 3280077 / 3393307 / 3471848 / 3515060 if you are on a lower revision!

Check if the parameter async_prealloc_in_chunks_enabled is set to false, when you are on <=59.10! (issue 290394/312021) It improve the situation by avoiding unnecessary buffer allocations and deallocations in case of merge/optimize compression/CC.

We'll start with some common questions I get asked when the first workshop takes place:

Does NSE cost additional licenses?
Can I use NSE for BWoH?
Which tables are perfect candidates for NSE?
How does the NSE structure look like?
Is there any holistic advice which table should be used for NSE in every system?
When should you use the NSE advisor?
Is it difficult to activate NSE?
Are there any prerequisites on HANA level?
How can we see which data is loaded into the buffer cache?
Are there more views with useful details about NSE?
Should we use archiving or NSE?
Can we also use indexes for NSE?
How big is the benefit of NSE?
How can we estimate the savings?
Can be NSE and pmem used together for a better TCO?
Do I have to adjust my topology regarding system resources, HSR, backup etc.?
Is NSE slower every time?
How the delta merge is working with NSE?
Is the NSE setting visible in the backend (ABAP dictionary)?
Is the NSE attribute lost if we clean-up a table?
Do we can use it with scale-out?
We are already using data aging. Do we need to switch?
How about LOB fields? Can we also use NSE to reduce the memory footprint of them?
What is the difference between heterogeneous and non-heterogeneous (homogeneous) partitioning?
How should I partition my table to take advantage of NSE on partition level?
How can the performance impact be tested?
Which are the important notes I have to check before using NSE?
Can I switch between 'normal' hot store and page loadable (NSE / warm store)
Can I pin or preload the buffer cache?
Which partitioning schemes are supported?
How the syntax looks like to activate NSE?
How should I size my buffer cache?
Do I have to do anything after NSE is active for the candidates?
How to determine appropriate tables for NSE usage?
Can we activating NSE during the migration towards to HANA?
Is there a automatically way to add new partitions besides dyn. range partitioning by record thresho...
Is NSE working with the re-distribution feature of scale-out systems?
Can we change the page loadable attribute right with the creation of the object?
Are all type of column store tables supported?
How the NSE Buffer Cache is working?
Are there other SAP applications supported besides S/4, BSoH and BW/4?
Can I use NSE with HANA Cloud?
How NSE object are treated in the consistency check?
Is there a known issue list for NSE bugs?
Are there any default tables with NSE delivered by SAP?
Is it possible to page out the audit log table?
Where are NSE data stored and can I configure the location?
Is the HANA sizing report considering NSE tables?
Do I have to reimplement NSE after a system copy?
Is there a recommended partition size for tables fully or partially in NSE?

Q1: Does NSE cost additional licenses?

A: No, it is already included in your SAP HANA license (regardless if runtime or full use). It is covered by the phrase "data tiering option". But it still costs memory. The size of the buffer cache is also normal DRAM, which has to be licensed regarding the amount of memory. Please keep this in mind. The larger the buffer cache, the smaller the savings.

Q2: Can I use NSE for BWoH?

A: No, it is not supported by SAP, but you can use it on your own risk. With BW/4HANA it is integrated and fully supported by SAP. AFAIK it is not on the roadmap of BWoH regarding my last talk with the product manager. You can use it with BWoH but you have to consider some tasks if you drop tables and recreate them in full load scenarios. This means additional administration effort. Use it carefully with estimation of your savings vs. effort.

Q3: Which tables are perfect candidates for NSE?

A: Tables which have a high change rate and a low read rate. Changed data in the delta area will stay hot in DRAM. They have the same access speed compared to normal ColumnStore. Only the access speed of data stored in the main area is affected. But if the data is already loaded into the buffer cache, the speed is nearly the same as in the normal ColumnStore.

Q4: How does the NSE structure look like?

A: The data structure look pretty much the same like the normal column store. Only at the persistence layer there is a difference how the dictionary is stored. Here is a little overhead compared to the normal CS structure.

Q5: Is there any holistic advice which table should be used for NSE in every system?

A : It always depends on your scenario and your expectations. But to start using NSE you can use the ESS (embedded statistics server) tables. This tables are not part your business workload. They are used for the performance und workload data of the system. This means they are only used for read load when you have some issues and your DBA or SAP is analyzing the system.

Enable/Disable NSE (PAGE LOADABLE) for column tables of HANA statistics server

But there are several starting points like EDID4, ZARIX*, DBTABLOG or BALDAT.

Q6: When should you use the NSE advisor?

A: This is just my opinion and may be other HANA specialists using the advisor in another way and had different experiences, but I'm not a fan of it. The advisor only covers a small timeframe and some special cases and scenarios will not be included. The advisor also has a little performance overhead which can be significant up to 20-30%. It should run at least for 7 days. As starting point or for simple scenarios it is a wonderful tool. For complex business cases I prefer the manual analyses to cover the needs of the business and special time frames like quarter or year closing. It can also not prioritize the SQLs e.g. SE16N selects or archiving runs which may falsifies the result.

There are also some known issues regarding the NSE advisor. At the time writing this blog there were no known issues in HANA revision >= 57.00 . If you want to use it use one of the latest revisions.

Q7: Is it difficult to activate NSE?

A: No, the activation is not complex, but to determine the savings including the real benefit with consideration of the performance and the partitioning design in context of the growth / scaling is the supreme discipline. There is no simple methode - every system is used in another way. No setup is identically. No user behavior is exactly the same. Every NSE analyses starts nearly at zero.

Q8: Are there any prerequisites on HANA level?

A: Yes, enough space on /hana/data , because the NSE persistence will use a little bit more disk space due to the dictionary metadata overhead - just about 10%.

[SPS04 - SPS07] You need at least HANA 2.0 SPS04 and the new persistence format for the affected table.

SELECT * FROM M_CS_COLUMNS_PERSISTENCE WHERE PERSISTENCE_TYPE = 'VIRTUAL_FILE' or PERSISTENCE_TYPE = 'VIRTUAL_PAGED'

If there is an output please consult note 2927591 and follow the migration procedure.

[SPS08] Starting with SPS08 a new persistence format was introduced which makes the conversion unnecessary.

Q9: How can we see which data is loaded into the buffer cache?

A: This is a frequent changing snapshot, but if you want to see which data is currently inside the buffer cache use the view M_CS_ALL_COLUMNS and the COLUMN MEMORY_SIZE_IN_PAGE_LOADABLE_MAIN

SELECT * FROM M_CS_ALL_COLUMNS WHERE LOAD_UNIT = 'PAGE‘;

or use the SQL script HANA_NSE_BufferCache_Tables_2.00.040+

Q10: Are there more views with useful details about NSE?

A : Yes, here we go:

SELECT * FROM M_CS_TABLES WHERE LOAD_UNIT = 'PAGE';

SELECT * FROM M_CS_COLUMNS_PERSISTENCE;

SELECT * from M_BUFFER_CACHE_STATISTICS;

SELECT * from M_BUFFER_CACHE_POOL_STATISTICS;

Q11: Should we use archiving or NSE?

A : Both! NSE is for warm data which is still accessed and may be changed. Archiving is for cold data which shouldn't be changed any more. Use NSE for old data which still has to be accessed /changed and can not be archived or for tables which can not be archived (no archive objects).

Q12: Can we also use indexes for NSE?

A : Yes, you can page out single indexes which are note frequently used. If you choose a whole table as candidate for NSE all indexes are paged out by default! Also if you choose a special partition for NSE, the part of the index for this partition is also paged out!

If you can not delete an index because it is a SAP standard index, you can use NSE to page this unused index out of the memory.

Q13: How big is the benefit of NSE?

A : This depends on your system, the usage and the end user behavior. If the system includes more than the current year you can calculate with min. 15% savings but in average for OLTP systems (ERP) you can save 20-25% and more.

Q14: How can we estimate the savings?

A : There are a few methods:

Peak sizing (full loaded table incl. indexes + working space)

Payload calculation (full loaded table incl. indexes)

Used payload calculation (only average loaded data)

In the end, you have to ask yourself from which perspective you want to act. The sizing or the usage perspective? The worst case or the normal business case scenario? Just do a before and after estimation of the memory size in detail degree of column level. Then subtract the buffer cache and you will get your savings.

Example:

You put the table EDID4 which has a full loaded size of 300GB into NSE. This means all columns and indexes are paged out. Normally only 20% are used. 100GB buffer cache are used.

Summary:

Peak sizing: 300GB *2 (payload + working space) – 100GB (buffer cache) = 500GB savings

Payload calculation: 300GB (payload) - 100GB (buffer cache) = 200GB savings

Used payload calculation: 60GB - 100GB (buffer cache) = no savings?

If you only need 60GB and it is the only table which you activated NSE for, you won't save really memory with this perspective. If your buffer cache hit ratio is always at 100% and the buffer cache won't grow to its max. size you should downsize it to save more memory.

Q15: Can be NSE and pmem used together for a better TCO?

A : Yes, the main part, which normally placed in DRAM can be stored with pmem. The buffer cache heap allocator Pool/CS/BufferPage resides in the DRAM and can not be placed into the pmem. This means every data loaded into the buffer cache is placed into the DRAM. You can combine this two feature if you place one partition (hot) into pmem and one into NSE. The performance impact needs to be measured when your needs are impacted, but technically it works. However pmem for INTEL is in sunset mode - only vPMEM on IBM Power can be used.

Q16: Do I have to adjust my topology regarding system resources, HSR, backup etc.?

A : No, it is a seemless and smooth integration. All data is included in HSR and the backups. The needed memory for the buffer cache should be smaller than the sum of your paged out data. So, in the end you save twice the data in memory (payload) and the workings space for the sizing.

Q17: Is NSE slower every time?

A: When the data is loaded into the buffer cache the access is nearly 1:1 compared the default setting ('COLUMN'). But in some scenarios I have observed that the partitioning design has speed up the selects and especially the inserts/updates/deletes.

If the data is not loaded into the buffer cache and it is thus the first access, you can add in average about 10-20% of database time. But this has to be tested carefully for every scenario.

Q18: How the delta merge is working with NSE?

A: My tests resulting in a degradation of merge duration of factor 4 to 8. It depends on the status of the page attribute (loaded/unloaded into buffer cache) and the merge parameters. There was nearly no overhead regarding the memory. The buffer cache was not used for the delta merge procedure!

The delta part of the NSE objects are stays hot inside the DRAM. That is also the reason/criteria for the candidates: high write ratio - low read ratio.

All columns of the merged table must be loaded to merge it. If the buffer cache (=BC) is not big enough to hold the entire table, at least the biggest column must fit into the buffer cache.

Similar to the merge process also the CC (consistency check) and the optimize compression are acting. The biggest NSE column which was paged out (=NSE on) must fit into the buffer cache. This means if you have 10GB BC and the biggest column (per partition) is 15GB, you have to increase your BC.

Q19: Is the NSE setting visible in the backend (ABAP dictionary)?

A: It depends on your release. It is fully integrated as table setting since S/4HANA 2020. It is supported for table conversions in the following releases:

S/4HANA 2020

In SAP S/4HANA 2020, the load unit for ABAP-managed HANA column store tables (that is, load unit setting on table level) can be defined via the ABAP Data Dictionary, in the technical settings for the table (transaction SE13). Changing the SAP-delivered setting for a given table technically represents a modification.

S/4HANA 2021

Like in SAP S/4HANA 2020 the load unit setting defined in the ABAP Data Dictionary is applied on table level. The load unit for columns or partitions can be set via database means, e.g. using the SAP HANA cockpit.

Starting with SAP S/4HANA 2021, there are two flavors ( preferred or enforced ) for specifying the load unit for ABAP-managed HANA column tables in the ABAP Data Dictionary (in the technical settings for the table, transaction SE13):

Preferred

default setting
Changing from one preferred load unit to another does not change the load unit on the database
During a table conversion, the actual NSE settings of the runtime object in the HANA database will be preserved

Enforced

Changing the enforced load unit results in a corresponding change on the database
The ABAP DDIC consistency check takes the load unit into account. Different values for the load unit in the DDIC and on the database result in tables that are inconsistent from the DDIC point of view.

The 'Preferred' flavors for the load unit setting in the ABAP DDIC offer the possibility for a database administrator or a tool like the SAP HANA Cockpit to overwrite the DDIC settings without making the table inconsistent. Please see the following section for the ABAP tool to check and (if required push-down) a preferred load unit setting to the HANA database.

Note for developers: In general, most of the tables should use one of the 'Preferred' settings for the load unit. Only if you are sure that the table should keep a specific load unit in all relevant scenarios (on premise, cloud, ...), you should use the Enforced load unit settings. The load unit setting in the ABAP Data Dictionary is chosen by the owner / creator of a table. Changing the load unit setting of an SAP-delivered table technically represents a modification.

Source: SAP Note 2973243

Q20: Is the NSE attribute lost if we clean-up a table?

A: If you delete or truncate a table which was activated for NSE, the attribute remains afterwards. If you drop a table and recreate it without explicit page loadable attribute, NSE is not activated for this table by default.

Q21: Do we can use it with scale-out?

A : Yes, since SPS05 starting with Revision 50. My personal recommendation is to use Rev. 56 and higher due to some non critical known issues.

But we have to differ some products as this is not fully stated out in all notes:

Data Tiering Optimization (DTO) supports NSE as warm-data store (as alternative to SAP HANA Extension Node)
SAP BW/4HANA (as from BW/4HANA 2021 SP04) on SAP HANA 2 SPS06 in scale-up and scale-out
SAP Business Warehouse on SAP HANA (BWoH) doesn’t support NSE in scale-up or scale-out
S/4HANA scale-out is supported since SPS05
SAP BW/4HANA on SAP HANA 2 SPS04 and SAP HANA 2 SPS05 : only scale-up

Q22: We are already using data aging. Do we need to switch?

A : Data aging is a similar concept using the page attribute but it is managed by the application. You don't have to switch because it is still supported, but my recommendation is to use one feature to make it easier administrating them.

Q23: How about LOB fields? Can we also use NSE to reduce the memory footprint of them?

A : Yes, but there were some restrictions and issues in the past. Please use the LOB fields only if you are on rev. 56+. When you upgrade to SAP_BASIS >= 7.53 the previous VARBINARY columns remain in place until an ABAP table conversion happens. New tables are created with a LOB data type.

As a consequence, many potentially large tables with large LRAW columns (<= 5000 byte) are completely loaded into memory (e.g. BALDAT, PCL2, SOC3, SWNCMONI, SWWCNTP0). In order to reduce the memory consumption, you can consider taking advantage of paged attributes / Native Storage Extension (so that unused column pages are evicted from memory in an LRU manner. Please also see SAP Notes 2816823 and 2898319 to safeguard NSE usage in table conversion events.

If there are blocked savepoints during "ALTER TABLE ... LOG REORGANIZE" or changing memory thresholds for LOBs involving paged /NSE columns

Workaround : convert LOB columns to column loadable, then alter memory threshold, and then convert back to page loadable. For more details have a look at my blog: details about HANA LOBs .

Source: 2220627 - FAQ: SAP HANA LOBs

Q24 : What is the difference between heterogeneous and non-heterogeneous (homogeneous) partitioning?

A : Exactly two brackets in the syntax . Personally I think this was a bad step by SAP. Not regarding the design, more about the syntax. A meaningful signal word in the syntax would make it more easier than two brackets:

Standard / non-heterogeneous / homogeneous partitioning

ALTER TABLE T PARTITION BY RANGE (C1)

(PARTITION 0 <= VALUES < 1000, PARTITION 1000 <= VALUES < 2000, PARTITION OTHERS );

heterogeneous with two brackets more

ALTER TABLE T PARTITION BY RANGE (C1)

((PARTITION 0 <= VALUES < 1000 , PARTITION 1000 <= VALUES < 2000 , PARTITION OTHERS));

Source: SAP documentation

But there is more to say:

In SPS05 I have noticed a small performance impact of up to 10% if I used a heterogeneous partitioning design vs. non-heterogeneous.

Pro heterogeneousContra heterogeneous select any attribute for partitioning not only PKperformance (must be tested)supported for : Range, Range-range, Range-hashno Range partitioning on first level (incl. dyn. range partitioning)

Favorite issue when activating NSE for a non-heterogeneous partitioned table:

SAP DBTech JDBC: [7]: feature not supported: modifying partition property for non-HETEROGENEOUS partitioned tables

Could not execute 'ALTER TABLE "<schema_name>"."<table_name" ALTER PARTITION <number_of_partitions> PAGE LOADABLE'SAP DBTech JDBC: [7]:

feature not supported:

The table is partitioned with a time selection partitioning. For this kind of partitioning it is not allowed to change loading type.

Q25: How should I partition my table to take advantage of NSE on partition level?

A : This should be analyzed and tested carefully and depends highly on the usage of the table by your business. Mostly the current and the last year is interesting for most scenarios. This means anything older than 2 years can be paged out. Here you have to choose a partition attribute. Mostly there is a time range attribute like FYEAR or GJAHR. Here you can partition by year / quarter / month. This depends on the amount of data. The details will be covered in the next blog part.

Q26: How can the performance impact be tested?

A : You should test your most critical business transactions and jobs in a sandbox or a QAS system. In the ideal case you should make benefit our of the capture&replay feature. Therefor a second system with the same size of the prod system is used. The workload will be captured on the prod. system and replayed on another one. Here NSE can be tested and the performance impact is visible.

Tip: If you use HSR for the prod system, test NSE on the secondary system during a maintenance window.

Q27: Which are the important notes I have to check before using NSE?

A : There are some:

Q28: Can I switch between 'normal' hot store and page loadable (NSE / warm store)

A : Yes, but you should test the duration. SAP recommends to do this for whole tables in a maintenance phase (=downtime).

My recommendation: You can do it for small tables also online in a low load phase of the system. With SPS08 there is the unified persistence, which means you can switch fast for every size of table. This is a massive advantage and an aspect upgrading to SPS08.

Q29: Can I pin or preload the buffer cache?

A : No, not by default or special setting. It will be loaded after the first access of page loadable data into the cache. Pinning doesn't make any sense. If you want it pinned save it as column loadable.

Q30 : Which partitioning schemes are supported?

# heterogeneous RANGE partitioning

ALTER TABLE <table_name> partition by RANGE (<Column>) ((PARTITION 19700101 <= VALUES < 20100101, PARTITION 20100101 <= VALUES < 20160101, PARTITION 20160101 <= VALUES < 20200101, PARTITION 20200101 <= VALUES < 20210101, PARTITION 20210101 <= VALUES < 20220101, PARTITION 20220101 <= VALUES < 20230101, PARTITION OTHERS))

# heterogeneous RANGE-RANGE partitioning

ALTER TABLE <table_name> partition by range (<Column>) ((PARTITION 100 <= VALUES < 200, PARTITION 200 <= VALUES < 400, PARTITION OTHERS)

SUBPARTITION by RANGE (<Column>) (PARTITION 19700101 <= VALUES < 20100101, PARTITION 20100101 <= VALUES < 20160101, PARTITION 20160101 <= VALUES < 20200101, PARTITION 20200101 <= VALUES < 20210101, PARTITION 20210101 <= VALUES < 20220101, PARTITION 20220101 <= VALUES < 20230101, PARTITION OTHERS))

# heterogeneous RANGE-HASH partitioning

ALTER TABLE <table_name> partition by range (<Column>) ((PARTITION 100 <= VALUES < 200, PARTITION 200 <= VALUES < 400, PARTITION OTHERS)

SUBPARTITION by HASH (<Column>) PARTITIONS 6)

# non-heterogeneous / homogeneous HASH-RANGE partitioning

ALTER TABLE <table_name> partition by HASH (<Column>) PARTITIONS 6,

RANGE (<Column>) (PARTITION 19700101 <= VALUES < 20100101, PARTITION 20100101 <= VALUES < 20160101, PARTITION 20160101 <= VALUES < 20200101, PARTITION 20200101 <= VALUES < 20210101, PARTITION 20210101 <= VALUES < 20220101, PARTITION 20220101 <= VALUES < 20230101, PARTITION OTHERS)

Please verify that you are using the correct documentation for your release. The syntax differences (comma, brackets, subpartition etc.) are small but important!

Documentation:

Q31: How the syntax looks like to activate NSE?

A : check the documentation for details, but here are some samples:

--Activation on Table level (recommended offline):

ALTER TABLE "<table_name>" PAGE LOADABLE [CASCADE];

--Activation on Column level (recommended online):

ALTER TABLE <table_name> ALTER ("<column>" <data_type> PAGE LOADABLE); (blocking concurrent changes)

ALTER "<table_name>" ALTER ("<column>" ALTER PAGE LOADABLE); (non-blocking conversion)

--Activation on Partition level (recommended online):

ALTER TABLE <table_name> ALTER PARTITION <part_id> PAGE LOADABLE;

--Activation on Index level (recommended online):

ALTER "<schema_name>"."<index_name>" PAGE LOADABLE;

Attention: Starting >= 2.00.059.01 (60+) the in-memory processing is done prior acquiring the consistent change lock in the context of the table page cascade conversion process.

Q32: How should I size my buffer cache?

A : Start with a factor of 6 and size it down while monitoring the buffer cache hit ratio. If you have 600GB paged out data to NSE. Use a buffer cache of 100GB. It depends highly on which data and the enduser selections. Monitor it over 1 or 2 weeks and adjust the buffer. Keep in mind that this is a frequent action and not a one-time task.

Default CS buffer cache size is 10% of PAL

indexserver.ini -> [buffer_cache_cs] -> max_size (in MB)

indexserver.ini -> [buffer_cache_cs] -> max_size_rel (in %) [default: 0 which means 10]

indexserver.ini -> [buffer_cache_cs] -> unload_threshold [default: 80] (SPS07)

indexserver.ini -> [buffer_cache_cs] -> async_prealloc_in_chunks_enabled = false

If you use the relative parameter your cache will automatically adjusted if you resize your server memory. Due to this my recommendation is to set it to a fix size, because in all other cases it will be forgotten and the cache is too big or too small. Be aware that if the cache is fully used, it won't be decreased/unloaded even if the data is not accessed. You can decrease the parameter which will free the memory. With SPS07 this features is delivered and addresses this gap with the NSE elastic buffer cache:

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

There is also a new alert regarding out-of-buffer events:

Q33: Do I have to do anything after NSE is active for the candidates?

A : Yes, monitoring the buffer hit ratio, fill degree of partitions, performance of SQLs (may be new coding which was not analyzed) and creating new partitions for new months, quarter or years. It is an ongoing process and every new HANA revisions has its own new features ��

Q34: How to determine appropriate tables for NSE usage?

A : Tables with 'paged preferred' load unit in ABAP Data Dictionary (DDIC) ( available starting SAP S/4HANA 2021 ��

Run report DD_REPAIR_TABT_DBPROPERTIES for all tables ('check only' option) to determine tables having a ABAP DDIC load unit 'page preferred' but have actual load unit 'column' in the HANA database.

For a quick glance on the load unit settings in DDIC, you may check field LOAD_UNIT in table DD09L: 'P'= 'page preferred', 'Q' 'page enforced'

Source: SAP Note 2973243

Q35: Can we enable NSE during migration to HANA?

A: You can define the partitioning design before you import the data to HANA in a special SUM DMO phase. You shouldn't activate NSE because the import performance can be impacted. Design your partitions before importing and activate NSE afterwards.

Q36: Is there a automatically way to add new partitions besides dyn. range partitioning by record threshold?

A: Starting with SPS06 there is a new interval option for range partitions:

#quarterly new partition

ALTER TABLE T PARTITION OTHERS DYNAMIC INTERVAL 3 MONTH;

#half yearly new partition

ALTER TABLE T PARTITION OTHERS DYNAMIC INTERVAL 6 MONTH;

#after 2 years new partition

ALTER TABLE T PARTITION OTHERS DYNAMIC INTERVAL 2 YEAR;

Documentation

Q37: Is NSE working with the re-distribution feature of scale-out systems?

A: Yes, it is supported starting with HANA SPS06.

Q38: Can we change the page loadable attribute right with the creation of the object?

A: Yes, it is possible during the creation to specify the load unit on column, table and partition level. It is not possible to change the partitioning design AND change the load unit at once. You have to do it in a 2-step approach. Starting with SPS06 this is possible.

Q39: Are all type of column store tables supported?

A: No!

Q40: How the NSE Buffer Cache is working?

A: The first access of a page loadable table will transfer the data from disk to the cache. It will remain until the LRU will evict it due to no access activity. But it will fill up the cache till its limit until the eviction kicks in. So, please choose the size of the cache wisely. The size can be shrinked by modifying the cache size. If a table will be dropped and is has a page load able attribute, it will be kicked out of the cache and the size drops!

Q41: Are there other SAP applications supported besides S/4, BSoH and BW/4?

A: Yes:

There could be more, but that's my current known state . If you miss any product just drop me a message or comment. There have also been some tests with the SolMan, which were officially presented by SAP, but currently there is no official support statement for it.

Q42: Can I use NSE with HANA Cloud?

A: Yes, but there are some limitation due to the different codeline.

Q43: How NSE object are treated in the consistency check?

A: Objects will be loaded fully and then checked. This means the buffer cache must suffer the request of min. the size of the largest table / partition. For instance your buffer cache is 50GB and your largest table is 60GB you will receive an error "ERROR_CHECK_FAILED". The buffer cannot be overprovisioned.

checking column table <schema>.<table>. Caught exception: exception 3020054: CS cannot provide requested memory as it's limit of <mb> MByte is exceeded.

indexserver.ini -> [table_consistency_check] -> enable_automatic_unload = true

There is a parameter for a early unload , but this is not valid for NSE tables. The issue was fixed with Rev. 55 and was improved with 59.

This means min. recommendation SPS05: 59.00 and SPS06 Rev. 64

Q44: Is there a known issue list for NSE bugs?

A: No, there is no official list. But I try to list them here:

Q45: Are there any default tables with NSE delivered by SAP?

A: Yes, since S/4HANA 2021 there are over 150 objects delivered during the EU_IMPORT phase from SAP. The most common once are dictionary tables like DD03L, DOKTL, DYNPSOURCE, TADIR etc. This means every customer with S/4 2021+ will now use NSE. So, please take care of your configuration.

S/4 tables after update/conversion:

Structure file (*.STR) during import:

Q46: Is it possible to page out the audit log table?

A: It is not possible before HANA 2.0 SPS07. Starting with HANA 2.0 Rev. 70 it is possible to page out the table "CS_AUDIT_LOG_" with the following command:

ALTER SYSTEM ALTER AUDIT LOG PAGE LOADABLE;

Q47: Where are NSE data stored and can I configure the location?

A: By default, NSE data is stored in the configured HANA data location (normally: /hana/data/). Currently there is no possibility to configure a special location apart from the HANA data location. The data is handled like the normal column store data in context of I/O , HSR and backup&recovery.

Q48: Is the HANA sizing report considering NSE tables?

A: Yes, since version 91 of /SDF/HDB_SIZING it is considering the default tables in S/4HANA and the suggestions by SAP.

Since version 102 there are even more possibilities regarding NSE. Please use always the latest version to get all the benefits.

Q49: Do I have to reimplement NSE after a system copy?

A: No, NSE attributes will reside the same as in the source. This means all NSE settings which were applied to PRD will also be restored to the QAS system via B&R or HSR. You can set the buffer cache a little bit more aggressive (=smaller) to save more memory.

Q50: Is there a recommended partition size for tables fully or partially in NSE?

A: When NSE is used for a table (regardless of whether the full table is page loadable, or only selected columns or partitions), comparatively small partitions should be designed in order to optimize IO-intensive operations such as delta merges. Because of the focus on IO, the relevant measurable is not the number of records per partition, but rather the partition size in bytes. When using NSE with a table, partition sizes should be smaller than 10 GB. This also means that if the size of a table that is fully or partially (selected columns) in NSE reaches 10 GB, this table should be partitioned.

Golden Rules for HANA Partitioning

Mon, 24 Nov 2025 10:51:17 GMT

Partitioning is not only useful to get rid of the record limitation alerts ID 17 ("Record count of non-partitioned column-store tables"),

20 ("Table growth of non-partitioned column-store tables") or 27 ("Record count of column-store table partitions") it can improve performance of SQLs,

startup, HSR, data migration and recovery. It is also useful to have a proper design to make use of NSE with paging out range partitions which are not frequently used.

I have also seen quite many of wrong designs like using multiple columns as partition attribute, too big or too small partitions, partitions with too many empty partitions. It can also happen that a design which is currently totally correct is not scalable and has bad performance due to massive change rate (increase due to growth as well as decrease due to archiving). This means you have to monitor the SQLs and the change rate and rate your partition design after 8-12 months again. Also due too new features (dyn. range partitioning / dynamic aging: threshold, interval + distance) it can make sense to redesign the partitioning. It is a moving target and like building a house - it will never be 100% complete and fitting your requirements, because the requirements will change over time.

Overall it is a very complex topic which should only handled by experts. A repartitioning can be really painful due to long downtimes (offline / standard partitioning ) or impacting the business due to long runtimes and resource consumption (online partitioning).

Rule of thumbs

Rule of thumbs for the initial partitioning:

min. 100 mio entries per partition for initial partitioning
max. 500 mio entries per partition for initial partitioning
if you choose too many partitions you can achieve a bad performance, because one thread per partition have to be triggered (e.g. you have 20 threads as statement concurrency limit and 40 partition have to be scanned which results in waiting for resources)
if you choose too less partitions, it can be that you have to repartition pretty timely which means another maintenance window / downtime
recommendation: HASH partitioning on a selective column, typically part of primary key
making sure that a single partition doesn't exceed a size of about 25 to 30 GB due to delta merge performance (SAP note 2100010 )
not too many empty partitions

Some of this rules can be checked by using the mini checks of SAP note 1969700.

For every rule exists a exception. For example ACDOCA can have (due to its number of fields which change over time depending on the S/4HANA release ) a partition size up to 100GB (SAP note 2044468 ). You will be charged in case of a delta merge, but if pruning is not possible is does make sense not to split this partition. This depends on the filters with the parallel threads required, as well as the number of parallel executions and business criticality.

It always depends on the usage of your system. There is no general design which is valid for every customer. You always need a detailed analyses and also this has to be done frequently because the workload and also the SQL (incl. filters) can change over time.

More details in one of our presentations at HANA Tech Con 2025

HASH

Use HASH partitioning if you have not a number, id or interval which is constantly increasing and used by the SQLs where clauses. If you are not aware of

the change rate and distribution, you can use HASH partitioning as a safe harbor. But use the number of partitions wisely! You can not easily add

partitions like for RANGE partitioning. The scalability is limited. A repartitioning can be expensive! Create the number of partitions wisely not too many and not too less.

RANGE

Use RANGE partitioning if you have a time attribute or a change number. This means a integer value which is constantly increasing and used by the SQLs

where clauses.

Typical date/time fields (in ABAP dictionary the data type is another one compared to HANA DB):

GJAHR (4 chars, ABAP DDIC: NUMC, HANA : NVARCHAR)

UDATE (8 chars, ABAP DDIC: DATS, HANA : NVARCHAR)

TIMESTAMP (21 chars, ABAP DDIC: DEC, HANA : DECIMAL)

Typical other integer fields which can be used for RANGE partitioning (sure there are more):

KNUMV

CHANGENR

This means not that every table with such columns should be partitioned by this attributes. It depends on the distribution and selectivity. Every system is different and there is no silver bullet.

The advantage of RANGE partitioning is, that you can add new partitions within milliseconds without disturbing the business operations. It means RANGE partitioning is the smarter partitioning option. You can also rebalance the design by merging or splitting partitions. During the partitioning process only the defined and affected ranges will be touched. This allows you to redesign the partitioning without big downtimes. This applies to standard/offline partitioning. For online partitioning always the complete table has to be touched!

RANGE partitioning includes also in all normal cases a OTHERS partition which all data will be stored which has no valid range. There are some features regarding dynamic range options ( threshold and interval option) which will be handled in an own article.

Multilevel partitioning

If your system includes huge tables it might be wise to use more than one attribute. One on the first level and one on the second level. This depends on the affected table and columns if it makes sense or not. There are only rare scenarios where it makes sense to combine multiple attributes on one level.

Designing Partitions

Actually the online repartitioning is based on table replication. Tables with the naming convention _SYS_OMR_<source_table>#<id> are used as interim

tables during online repartitioning operations. For details please read the “Designing Partitions” section in the documentation.

Summary :

Use partitioning columns that are often used in WHERE clauses for partition pruning
If you don’t know which partition scheme to use, start with hash partitioning
Use as many columns in the hash partitioning as required for good load balancing, but try to use only those columns that are typically used in requests
Queries do not necessarily become faster when smaller partitions are searched. Often queries make use of indexes and the table or partition size is
not significant. If the search criterion is not selective though, partition size does matter.
Using time-based partitioning often involves the use of hash-range partitioning with range on a date column
If you split an index (SAP names the CS tables also as index), always use a multiple of the source parts (for example 2 to 4 partitions). This way the
split will be executed in parallel mode and also does not require parts to be moved to a single server first.
Do not split/merge a table unless necessary.
Ideally tables have a time criterion in the primary key. This can then be used for time-based partitioning.
Single level partitioning limitation: the limitation of only being able to use key columns as partitioning columns (homogeneous partitioning)
the client (MANDT/MANDANT) as single attribute for partitioning is not recommended - only useful in multi level partitioning scenarios with real multi clients environments

In the end if you want be on the safe site, just contact us. We will find a scalable design and may improve performance or also find a NSE design for your tables. It is a complex topic on for a proper design you need deep knowledge in SQL performance tuning, partitioning options and HANA is working in general. In the near future our new book will be released with all details regarding partitioning.

Do you need help to raise your knowledge or straight recommendations from an expert? Check out our workshops or the expert services .

Details:

Blog: HANA Partitioning – 2 billion rows limitation – Part II: BSoH / S/4HANA

3234063 - How to partition/re-partition a table
3111531 - SAP HANA - How to convert an existing hash partitioned table to range.

2044468 - FAQ: SAP HANA Partitioning
2418299 - SAP HANA: Partitioning Best Practices / Examples for SAP Tables
2289491 - Best Practices for Partitioning of Finance Tables

From Complexity to Clarity: Optimizing the R+R List for SAP Cloud ERP

Thu, 25 Sep 2025 08:04:46 GMT

Check out how to optimize the R+R List for SAP Cloud ERP

In transformation projects like SAP RISE / SAP Cloud ERP , the Roles & Responsibilities (R+R) list often serves as the backbone for collaboration between customer, partner, and SAP. Yet too often, this list is treated as a static document rather than a living framework. Sometimes nobody knows exactly what was defined by the time signing the contract. By continuously questioning, refining, and contextualizing R+R, organizations can reduce ambiguity, close expectation gaps, and create a solid foundation for accountability. But this has to be done before signing the contract and not after the going live.

Every single customer signed a PCE contract negotiated different parameters and bought different CAS packages - oh sorry since July “CAS (=Cloud application service)” are now called “Packaged Services”. Be aware that all needed Packaged Services are discussed and included in the contract. Otherwise there can be extra costs.

The current R+R list for the tailored option (v7 2025) consists of 1084 services (not counting empty lines or titles) with this distribution:

59 pages (-4 pages for cover and legends) => 55 pages content
Service Management: 17 services
Managed Infrastructure: 73 services
HANA : 114 services
SAP HANA: Accelerator for SAP ASE (AFA): 11 services
DB (Excluding SAP HANA and Sybase IQ ): 19 services
DB2: 15 services
Basic (Core Technical Operations): 122 services
NW (NetWeaver Operations ABAP and Java): 52 services
SPROV (Server Provisioning (aka IaaS)): 36 services
CAS (Cloud Application Services): 19 services
Move (Movement Services for System Conversion and Transition): 13 services
X1 - X64 (3rd party software) : 593 services

Regarding X1 - X64 : 3rd party software is a bit misleading. Because this includes SAP software like BTP, SF, CALM, Content Server, ADS, ETD and many more.

But first things first. If you made a deep dive into the R+R list and compare it to your current service catalog which you already have from your current MSP or you created your own internal one, you will notice that there are gaps. This means not only that some tasks costs extra. This means also a lot of services are not needed because there is no need for you to run Sybase or DB2 or you have no third party product which leads to the conclusion that 593 services are not valid for you.

But you not only have to check which services are valid in the R+R. You have also to check which services are not covered or even not listed. For this you have to work close together with all technical teams, if there is currently no service catalog or an outdated version.

Even if a service is covered means not that the amount of executions are also covered. For instance Service HANA_1_1.04 ("Partition tables (technical execution)") stated out "If required as a consequence of extensive table growth; One (1) execution in One (1) table per SID, per year included; any further requests will be charged separately" which means that you have to pay extra if there is more than one execution in one table per SID.

Over the last years the list changed continuously which means not only that services were added. Also some of them were removed - yes not only marked as excluded - just removed. The valid list is the list which were transferred to you with your contract. Only this is valid for you.

Not covered means then excluded , removed or not listed . But who is responsible for this tasks? The customer has full responsibility to all tasks which are not covered. You still need experts who e.g.:

Design table partitioning strategy/architecture
Identify, analyze and optimize expensive SQL-statements to improve application performance
Design NSE strategy
provide commands to frequently page out old data / partitions (NSE)
run proactive Health Checks
run proactive index checks for index recommendations

Nearly all covered tasks have to be triggered via SR within provided time slots with lead times. The initiator is still the customer with full responsibilities.

Conclusion / Summary

You still need your SAP Basis experts or external partners even if you are use an SAP Cloud ERP offering. Please consider this in your cost calculation! You need to check this list multiple times with multiple experts to get all perspectives for the complete picture. My recommendation is to involve multiple experts for licensing , evaluation of the R+R, sizing, migration QA and for the operations. Four weeks aren't enough to validate all contract components. Find your blind spots and take the time you need to review all contract components.

SAP HANA data statistics for the optimizer

Wed, 28 May 2025 09:03:02 GMT

Popular misconcept: HANA needs no statistics

In the world of modern database management systems, query performance is not just a matter of hardware—it’s about smart execution plans . At the core of generating these plans lies a critical component: optimizer statistics . Every DBA is aware of the optimizer data statistics. Without this details the optimizer can only generate wrong execution plans. There are multiple optimizer statistics depending on the database:

system statistics (CPU, I/O, memory)
workload statistics
noworkload statistics
table statistics
column statistics
index statistics

Besides the different objects also the collect method is important. There are dynamic or runtime statistics and histograms. As always up-to-date and accurate statistics will lead to better execution plans depending on the costs. If a table is changing too frequently accurate and up-to-date statistics are not possible and would generate too heavy overhead. It must be in balance and this is depending on the different workloads.

Accurate statistics help the optimizer decide on:

Join order
Join method (e.g., hash join vs. nested loop)
Index usage
Degree of parallelism

Poor decisions can lead to excessive memory usage and CPU spikes.

The note 2100010 - SAP HANA: Popular Misconceptions deserves an update regarding the optimizer stats. Many "experts" talk about HANA as magical database which tunes itself and needs no optimizer statistics. The truth is that also HANA relies on different statistic data to generate an optimal execution plan. For virtual/remote tables like for SDA scenarios the manual statistics are used since HANA 1.0 SPS 06. There are different types of data statistics:

runtime : Automatic ad-hoc calculation

explicit : Manual creation via Syntax CREATE STATISTICS

For SAMPLE statistics, explicit statistics take precedence over runtime statistics.

For other statistics types, runtime statistics take precedence over explicit statistics. If you want to change this behavior, you can force the use of explicit statistics instead of runtime statistics using the following parameter: indexserver.ini -> [datastatistics] -> dev_force_use_non_runtime_datastatistics = true

Although HANA is an in-memory database not always all data is loaded into the memory. In some cases only a partition or some columns are loaded. The runtime statistics can only be created if all data is loaded. This happens during the prepare and compile phase. In some cases e.g. in the context of NSE this can take significant longer.

If the needed column is not fully loaded the data statistics are estimated. This approach eliminates column load overhead, but the data statistics estimations may be imprecise, imposing the risk that a bad execution plan is picked. The distinct count of a column is in this case set to the row count, representing a unique column. This can be far away from the real distinct count and unfavorable join orders and execution engines can be the consequence. In this case it can make sense to use manual statistics which have also to be updated frequently.

If you create data statistics manually you can choose between different refresh types:

Examples:

CREATE STATISTICS ON TABLE_NAME.COLUMN TYPE SAMPLE SAMPLE SIZE 10000 REFRESH TYPE MANUAL;

CREATE STATISTICS ON TABLE_NAME.COLUMN TYPE TOPK BUCKETS 1500 REFRESH TYPE AUTO;

Details:

2800028 - FAQ: SAP HANA Optimizer Statistics

2000002 - FAQ: SAP HANA SQL Optimization

HANA OS maintenance

Tue, 27 May 2025 19:54:22 GMT

This is a subtitle for your new post

Please notice that when you want to run HANA 2.0 SPS07 , you need defined OS levels. As you can see RHEL7 and SLES12 are not certified for SPS07. The SPS07 release of HANA is the basis for the S/4HANA release 2023 which is my recommended go-to release for the next years. Keep in mind that you have to go to SPS07 when you are running currently SPS06, because it already run out of maintenance in end of 2023.

SLES12 SP5 for SAP already run out of maintenance at the end of October 2024. To be supported you have to pay for LTSS because it is the final SP of SLES12 there is no ESPOS - no overlap support for this one.

Please plan your updates if you are still on SLES15 SP2 due to end of maintenance by end of this year.

For HANA 2.0 SPS08 be aware that you use at least SLES15 SP3 or RHEL9.2!

Attention: There is currently an ongoing issue with SLES15 SP06 and ADS (Adobe Document Service) for on-prem usage. Please check note 3522913 - ADS on SLES 15 SP6: Texts are not displayed in PDF after upgrade.

SAP HANA Optimizer - the heart of the performance

Sun, 25 May 2025 19:02:03 GMT

The HANA Optimizer is one of the core components of the HANA database. It determines how SQL is executed.

A database optimizer behaves similarly to the navigation system in your car. You use various parameters to determine which route you want to take to reach a particular destination. Potential additional costs for tolls and ferries also play a role, as do other limitations such as the vehicle's height, length, and width. From these input parameters, the navigation system determines the optimal route based on current traffic information (traffic volume, construction sites, congestion, accidents, closures, etc.), weather conditions, and the length of the route. This means that with exactly identical input parameters, different routes, costs, and thus different travel times can arise depending on the given conditions.

The HANA optimizer behaves similarly. It receives its input variables from the user's selection criteria. The given conditions here are the available resources, the dimensions of the objects involved (number of entries, field lengths, column size, different column weights, etc.), index information, existing hints, existing execution plans, optimizer statistics, etc. Finally, potential costs are calculated. As with a navigation device, the goal is to determine the fastest route. This may often not be the shortest or the most resource-efficient.

If you purchase a more powerful car with modified driving characteristics, the same route can now be covered somewhat faster. If you discover a shortcut with your old car, an improvement is also possible, but without the cost of purchasing a completely new vehicle. In HANA, this corresponds to measures such as adapting the application logic or using DB hints with other engines. With this analogy, we want to demonstrate that more system resources or a new database revision are not necessarily the direct path to the actual goal. It is much more important to understand how and why the optimizer handles certain queries differently.

Sometimes there may be a traffic jam along the route, which can be quickly resolved or even prevented in the first place by a clever traffic control system (parameter and workload management). Therefore, it is important to know the system's workload and be able to react to significant deviations. We recommend defining KPIs for this purpose.

To understand exactly how the optimizer works, let's first look at the flow of an SQL processing operation. This will make it clear when it is used.

You have to know that SQL is declaritive language. This means it only describes "what" to be processed. The "how" is determined by the SQL processor. SQL Processor is smart, but needs to make decisions in very short time => the plan might be sub-optimal if too many tables are involved.

Important: It cannot fix data model or logical issue within the SQL.

Normally, the SAP HANA database consistently picks an optimal execution plan to process a database request. In some cases, though, the database can switch to a worse execution plan, resulting in higher runtimes and increased CPU or memory consumption.

Typical reasons for execution plan regressions are:

Bind values: The selectivity of the bind values / parameters used during preparation are considered to work out an optimal execution plan. Subsequent executions to a certain keep the same execution plan even if the selectivity are significantly different. This is particularly critical in context of HEX engine (SAP Note 2570371) and SAP HANA <= 2.0 SPS 07 because the generated HEX execution plan is highly static. See SAP Note 3513868 for more details.
Sampling : Working out a good execution plan to a certain extent depends on sampled data. For example, only a subset of partitions is sampled, so that many empty partitions should be avoided.
Complexity and design : The more complex the design of a database request and the underlying accessed objects is, the higher is the probability of misconceptions of the query optimizer. Thus, keep the design always as light-weight and simple as possible, also in context of concepts like CDS views and AMDP procedures. Also, make sure that modelling best practices are considered.
Data : The actual data in the underlying tables also impacts optimizer decisions. In rare cases, even small changes to the underlying table data can impact the optimizer decisions.

There are two ways to determine the statistics:

The columns are loaded into memory and data statistics are calculated as usual
The columns are not loaded and values are estimated

The data statistics are stored within monitoring view M_SYSTEM_DATA_STATISTICS. You can use HANA_SQL_Statistics_DataStatistics_2.00.040+ to read the most recent data. Which data you will get?

- TYPE: Data statistics type

- SCHEMA_NAME: Schema name

- TABLE_NAME: Table name

- COLUMNS: Columns (individual columns or column groups listed via comma-separated column list)

- SOURCE: SYSTEM in case of system generated, USER in case of user defined

- LAST_REFRESH: Last data statistics refresh time

- COUNT: Record count

- NUM_DISTINCT: Number of distinct values

- NUM_NULLS: Number of NULL values

- MIN_VALUE: Minimum column value

- MAX_VALUE: Maximum column value

- BUCKETS: Histogram buckets

- INDIV_COSTS: Cost factor for leading column of inverted individual indexes (SAP Note 2600076)

- TOP_1: Top 1 histogram bucket (e.g. frequency and value of most frequent column value in case of frequency histograms)

- TOP_2: Top 2 histogram bucket

- TOP_3: Top 3 histogram bucket

- DATA_STATISTICS_CONTENT: Raw data statistics details in JSON format for SYSTEM statistics, statistics name for USER statistics

This data statistics are fundamental for the decisions of the optimizers. Like our example with the navigation system, if you are using old or incorrect information about the route, the system will decide possible wrong based on this wrong input variables.

But there are also other statistics. The so called join statistics available through monitoring view M_JOIN_DATA_STATISTICS. Join statistics are required to optimally understand cardinalities when joining different tables. You can use HANA_SQL_Statistics_JoinStatistics_1.00.120+ to select the details.

- REFRESH_TIME: Last statistics refresh time

- HOST: Host

- PORT: Port

- SCHEMA_NAME_1: Schema name of table 1

- TABLE_NAME_1: Table name of table 1

- COLUMN_NAME_1: Column name of table 1

- SCHEMA_NAME_2: Schema name of table 2

- TABLE_NAME_2: Table name of table 2

- COLUMN_NAME_2: Column name of table 2

- NUM_ROWS_1: Number of rows in table 1

- DISTINCT_1: Distinct values in column of table 1

- MEMORY_KB: Used memory (KB)

- VALUE_COUNTS_1: Unique value counts (or a single average value)

- VALUE_COUNTS_FREQUENCIES_1: Frequency of different value counts (or a single average value)

- MATCHING_VALUES_COUNTS: Number of value counts in table 1 with corresponding entries in table 2

indexserver.ini -> [joins] -> statistics_method (default: cs_statistics).

Setting statistics_method to "traditional" can result in increased resource consumption and additional database trace messages.

What can take influence? Which parameter can be changed to influence the behaviour?

indexserver.ini -> [joins] -> cs_statistics_cache_invalidation_threshold_factor (default: 2.0)

Table content has significantly changed since the last execution.

Definition of significance: More than 25 rows , change happens more than 2 times.

indexserver.ini -> [joins] -> cs_statistics_cache_invalidation_by_shrinking_tables (default: false)

With SAP HANA 2.0 SPS 07 (>= 2.00.073) SAP recommends to set this parameter explicitly (SAP Note 2600030). With SAP HANA >= 2.00.080 the default for this parameter is changed to false.

indexserver.ini -> [sql] -> large_predicate_sampling_threshold = <elements> (default: 100)

Predicates like long OR concatenations are only sampled when the number of elements doesn't exceed 100.

Otherwise a potentially less accurate estimation will be used and the risk of slower execution plans increases. Using larger values can result in better optimizer decisions at the cost of some parsing overhead.

You can control the limit on statement level via hint LARGE_PREDICATE_SAMPLING_THRESHOLD(<elements>)

indexserver.ini -> [hex] -> min_table_increase_factor_to_recompile = <factor> (default: 4)

The default value of 4 triggers a recompilation as soon as the table size is factor 4 larger or smaller than during the last parsing.

indexserver.ini -> [sql] -> compile_time_sampling_size (default: 1000; HANA 2.0 SPS08)

The size of sample to estimate selectivity of a filter by sampling: compile_time_sampling_size specifies the number of sample records to be examined on SQL query compilation to get statistics of a table or a partition of a table in case of partitioned table. If the value is 0, records in tables will not be examined on SQL query compilation. If the value is larger than the number of records in a table or a partition, all rows in the table or the partition will be examined.

indexserver.ini -> [sql] -> compile_time_sampling_partitions (default: 8)

Maximum number of partitions to estimate selectivity of a filter by sampling: compile_time_sampling_partitions specifies the maximum number of partitions to be examined on SQL query compilation to get statistics of a partitioned table. If the value is 0 or larger than the number of partitions in a table, all partitions in the table will be examined.

When cost-based enumeration ends, the final query execution plan is generated (called "code generation"). This is the plan that will be executed by the execution engines. At this point, the role of the SQL optimizer also ends.

After code generation, the query plan can still be changed but only by the execution engines. This is called "engine-specific optimization" because the changes are determined and made by the execution engines.

Engine-specific decisions vary from engine to engine. An example of an engine-specific decision is the parallel thread decision made by the join engine. During the optimization process, the SQL optimizer does not consider aspects related to memory management and CPU. Its primary task is to make the plan run faster and to do so it uses all available resources to a maximum. Whether the query should run on multiple threads is not part of its decision-making. The join engine is responsible for making this decision. That is why you need to use an engine-specific hint and not an SQL optimizer hint to enforce parallel execution for the query. SAP recommends to implement statement hints in order to avoid performance issues or high resource consumption due to wrong optimizer decisions for some defined standard SQLs ( 2700051 - Delivery of SAP HANA Statement Hints). This hints will be updated from time to time. Our recommendation is to add this note to your favorite notes and track changes (recent change of the note: 05/25/2025).

Is the effort for NSE worth it?

Fri, 18 Apr 2025 15:52:20 GMT

Is NSE worth the effort or is the better question: Do you know your cost per GB of RAM?

Most of our presentations on data tiering projects end with these typical questions:

How much we will save?
How fast can it be implemented?
Is the effort worth it over time?

My counter question:

"Do you know how much 1 GB of memory costs your company per month or year?"

=> how much memory we have to save to be beneficial?

Most of the customers cannot instantly answering this questions due mixed costs (hardware, software, maintenance, extra services, etc.). Do you know yours memory costs? Over the years we collected such data specific only for the infrastructure for on-prem and cloud systems.

For on-prem systems we are in the range of 1.30€ to 2.00€ per GB per month. This means in average 1.80€ (over the number of customers).

For IaaS systems (3 years reserved instances) we are in the range of $0.77 to $4.80 per GB per month for MS Azure (customer average: $2.56) and $1.64 to $5.67 per GB per month for GCP (customer average: $3.47). Please note this not a rating pro or con one of the hyperscalers due to the lag of comparison. You cannot compare the instances 1:1 due to the difference in CPU processor, number of CPUs, interfaces, costs per OS, different contract discounts etc. Please be aware of the concurrency conversion issues from $ to €.

In the end it is an easy calculation. If you save more memory compared to the costs of a data tiering project, you have your benefit and the answer if the effort worth it.

The cost of a NSE project? It depends as always. Mostly we do more than just NSE. We are optimizing partitioning designs, index memory usage and tuning some SQLs. This means not only NSE alone will save the memory but a big part belongs to the NSE benefit.

A NSE project is normally in the range of 15,000 to 30,000€. This means if we assume the max. costs, the benefit of NSE have to be bigger than 30,000€ over time.

How much memory saving you can expect?

Typically, depending on the archiving strategy, the aggressiveness of the NSE design, and system growth, we achieve savings of 27% to 35% per system. This means for the most customers it includes the PRD, QAS, and even the secondary HANA system replication site. For most environments, you save three times as much memory per NSE project.

If we save 500GB in the HANA sizing which means round about 250-300GB of payload (our smallest project achieved a saving of 600GB in the sizing with costs of around about 13,000€). When we will reach the break even with costs of 30,000€? Do we need multiple years? No! For most of the system we will reach the break even point in less than 10months.

If we assume a saving of 800GB per system in the HANA sizing we would reach the break even point for all systems in 8 months.

As you can see even with "high" NSE project costs you will achieve ROI in about one year.

Rule: The more systems are affected and the more savings can be achieved per system, the faster the investment in an NSE project will pay off.

The best aspect is that not only save system resources and money, you will also improve your energy efficiency and reduce your business’ carbon footprint. With the EU’s CSRD now regulating that compute energy must be measured as an emission, the environmental cost of HANA can soon overshadow its monetary cost.

If you are planning a RISE project you should implement NSE before you migrate to RISE because currently there is no CAS for a NSE design.

Buchtipp: SAP HANA Deepdive: Optimierung und Stabilität im Betrieb

Sun, 30 Mar 2025 10:43:46 GMT

Unser erstes Buch ist nun verfügbar

Pünktlich zu den DSAG Technologietagen 2025 wurde unser erstes Buchprojekt finalisiert und gedruckt. Hierbei handelt es sich nicht um das x-te HANA Administrationsbuch mit dem nötigen Basiswissen rund um die HANA Datenbank, sondern um eines das auf diesen Büchern für einen echten Deepdive aufbaut. Aktuell ist das Buch lediglich in Deutsch verfügbar.
Was steckt alles im Buch?

- knapp 300 Seiten HANA Know-How
- ~49543 Wörter
- 324.960 Zeichen (ohne Leerzeichen) / 372.544 Zeichen (mit Leerzeichen)
- 3298 Absätze
- 8270 Zeilen
- 11 Kapitel geballte Erfahrung, welche man nicht in Guides oder Dokumentationen findet
- 158 Bilder - alle eigens angefertigt (besonderes Dankeschön an Dominik Fiedler!)
- viel Zeit (über 250h), akribische Arbeit, Schweiß, Researching und ein paar graue Haare mehr

Wer sollte das Buch lesen?

- erfahrene SAP Admins
- HANA DBAs mit dem Drang nach Expertise
- SAP Architekten für Themen wie Wartung und Sizing
- SAP / HANA Entwickler mit dem Interesse Abfragen performant zu gestalten

Inhaltsverzeichnis:

1. SQL-Skriptsammlung
2. HANA System Sizing
3. Maintenance
4. Parametrisierung
5. Workload Management
6. Optimizer
7. Partitionierung
8. Hints
9. Index
10. Troubleshooting
11 Tools zu Analysezwecken

Wo bekommt Ihr es?

- espresso-tutorials.com (via digitales Abo oder als gebundenes Buch)
- sprecht uns an
- ISBN: 9783960123675

Ein riesiges Dankeschön an die vielen Kollegen und Experten für die Unterstützung, Überprüfung und Feinjustierung.

SAP ERP Extended Maintenance until 2033 - but with conditions

Fri, 07 Feb 2025 16:31:59 GMT

More time to switch from BSoH to S/4HANA

Recently handelsblatt released an article with a new SAP RISE option called SAP ERP, private edition, transition option. This option includes a extended maintenance until the end 2033. This means 3 years more compared to the original on-prem extended maintenance. This statement was confirmed by SAP on request of handelsblatt, but customers receive more details, such as the price, in the first half of the year. This is a quite unusual move of SAP without any official statement on the news page. Just to raise more doubts? Strategy? However a good move against the critics and the ever shorter timeline. Perhaps it is also a consequence of the growing shortage of experts for operating and migrating the large number of systems.

A short summary of the article

introduction of a new RISE option: "SAP ERP, private edition, transition option"
old systems (e.g. ECC) can be used until the end of 2033 if the option is part of the RISE contract
details will be announced soon (in the first half of the year)
no other change for on-prem customers - end of maintenance is 2027 with extended maintenance to 2030
a tradeoff: time exchanged for RISE

This raises some questions

Which OS / DB combinations are supported? It will lead to new lifecycle discussions with other vendors
Why it is not offered for the on-prem customers due to nearly the same maintenance effort? (the reason is obvious but the answer maybe interesting)
Can customers who signed the RISE transition option contract directly jump to a possible successor of RISE and S/4HANA?

As SAP provided further details in its fourth quarter results release:

the new option is only for a very few large customers
it's not about the extension of on-premise maintenance
all cloud solutions will run on HANA Cloud?!

The statement regarding HANA Cloud is a little bit misleading and can also be a slip of the tongue. However, all cloud solutions would imply also RISE and GROW. The heart of HANA 2.0 still beats under the hood of RISE and GROW. HANA Cloud is a separate product with its own line of code and its own lifecycle that cannot (yet) be used for S/4HANA.

Here the original transcript from seekingalpha :

Some assumptions

Only ERP 6.0 EhP8 will be supported until 2033 to reduce maintenance effort (release and kernel)
Only HANA systems will be supported until 2033 to raise the HANA revenue

The single product versions with ERP 6.0 had longer runtimes compared to S/4HANA. In summary the complete product ERP has 19 - 27 years depending on the version and extension option.

Ten years before (2030) S/4HANA will go out of maintenance (2040) they have to release a successor or extend the EoM date of S/4 to 2042 or 2043 to give customer enough time to migrate. Is it like a football or chess game and we see the result only at the end and not in the first half of the game?

Smart SAP HANA Optimization: Applying NSE for Better Efficiency

Wed, 15 Jan 2025 06:38:32 GMT

Optimize your HANA with NSE

When it comes to optimizing SAP HANA, the balance between performance and cost efficiency is critical. I am happy to share a success story where we used the Native Storage Extension (NSE) to significantly optimize memory usage while being able to adjust the sizing at the end.

The Challenge: Our client was operating on a 4 TB memory SAP HANA system, where increasing data loads were driving up costs and memory usage. They needed a solution to right-size their system without compromising performance or scalability. The client wanted to use less hardware in the future.

The Solution: We implemented NSE to offload less frequently accessed data from memory. The activation was customized based on table usage patterns:

6 tables fully transitioned to NSE
1 table partially transitioned (single partition)
1 table transitioned by specific columns

The Results: Memory Savings 1135 GB

NSE: 945 GB saved
Changing one table to Inverted Individual Index: 90 GB saved
SBCMCONT1 cleanup: 230 GB saved
Offset: NSE Buffer Cache (130 GB)

As you can see, we have not only saved memory through NSE, but have also discovered other potential savings in the course of the project.

Including the NSE buffer cache, we were able to save around 48% of the memory compared to the initial situation. A really great result. On average, we achieve savings of around 25-35% for an ERP system.

After the GoLive of NSE, the client waited around 5 weeks until the database memory was reduced from 4 TB to 2.5 TB, despite prior and intensive tests in the test system.

As a result, we achieved optimal sizing according to SAP:

50 % payload data
50 % working memory

It would have been possible to reduce the memory to 2 TB, but then we would have been directly at an utilization of 62%. Depending on the growth and use of the database, this may already be too much and it would have to be increased again soon.

The customer has decided on a conservative approach and selected 2.5 TB.

Beyond NSE: Holistic Data Management Is Key

While NSE delivered exceptional results in this case, it is not the only solution for optimizing SAP HANA systems. Proactive data archiving and, importantly, data deletion can also lead to significant memory savings. For example, SAP note " 2388483 - How-To: Data Management for Technical Tables" provides excellent strategies for managing technical tables effectively.

These steps — NSE, archiving, and deletion — serve as excellent preparation for:

Purchasing new on-premise hardware
Migrating to cloud or other cloud environments
Transitioning to SAP RISE

The less data you store in memory, the lower your costs and environmental impact. These optimizations not only improve performance but also contribute to a greener IT landscape by reducing energy usage. It is better to clean up first and then migrate.

As you can see from this story, an NSE project helps you to get to know your data better and also reveals other areas where memory can be saved.

How Can We Help? If you’re considering memory optimization for your SAP HANA system we’re here to help. Feel free to reach out with any questions or to explore how we can assist you in unlocking the full potential of your SAP HANA environment.

Together, let’s make SAP HANA smarter, leaner, and more sustainable.

3 years of RISE with SAP: ECS realignment

Sun, 05 Jan 2025 13:01:44 GMT

Realignment if the organization

Starting with RISE with SAP in 2021 the customers had responsible persons at ECS for several different tasks depending on their contract:

TSM = Technical Service Manager
CDM = Client Delivery Manager
SAP Architect
Database Engineer
Infrastructure Engineer
and more

Depending on the contract, these can also be dedicated people for one or more customers.

For this reason SAP introduced SAP ECS PC3 (SAP Enterprise Cloud Services Private Cloud Customer Center) a new digital delivery engagement model already back in 2022 .

The SAP Enterprise Cloud Services Private Cloud Customer Center (PC3) - a new digital delivery engagement model dedicated to manage service delivery for RISE with SAP S/4HANA Cloud, private edition customers.

Why is this important now? SAP is transitioning all existing and new customers from the classic CDM/TSM model to the digital model in a phased manner.

What effect does the change have? Most of the roles like TSM or CDM will disappear. Successor of those roles: PC3 Digital Customer Engagement Manager (dCEM)

A new escalation framework will be introduced.

dCEM

Description: A team of dedicated Centers of Expertise, supporting diverse phases of the engagement lifecycle (Migration & Onboarding, Implementation, Go-Live and Operations).

The Digital Customer engagement Managers are available to support the customers during each stage of your engagement lifecycle.

Role Requirements (only a part of them)

Engineering graduate with minimum 8+ years of work experience as SAP technical consultant with 4+ years in customer facing role (consulting, IT support, IT services etc.)
Excellent customer focus / Networking / Relationship Building /Results-driven / Self-organized / Decision making
Hands on experience with SAP Basis activities, SAP release upgrades and infrastructure updates for cloud customers
Cloud architecture and IT technical infrastructure know-how
Technical and application expertise for different cloud solutions ( min. HEC & S/4HANA )

=> interesting that HEC is still such present that it is mentioned as minimum requirement or is it a copy&paste issue? :)

Summary of dCEM tasks

Primary point of contact for customer during the RISE PCE Onboarding journey.
Coordinates system provisioning and communicates with the customer to align project information,requirements, and timelines.
a combination of CDM and TSM responsibilities

Detailed dCEM tasks

Assigned & Responsible for the customer during onboarding phase

Acts as a customer ambassador for various technical teams
Drives service kick-off, collects and validates technical information from the customer
Accountable for system build, test, network connectivity, system handover to and acceptance by the customer
Escalation management & SAP Experts' orchestration during Provisioning and Onboarding activities
Manages the implementation of disaster recovery (if applicable)
Actively communicates with the customer through PC3 central mailbox.

Available as team of experts during the Implementation, Go-Live and Operations phases

Provides the customer with transparency about the progress and KPIs of the SAP Enterprise Cloud Services via automated regular service review reports
Initial point of technical contact for customers/partners
Ensures meeting the contractually agreed KPIs, resolution of incidents, escalations, change mgmt. through alignment

IMPORTANT : The PC3 Mailbox is the main channel of communication with Enterprise Cloud Service Private Cloud Customer Centre.

Other roles

IAE : Industry Account Executive

Owns the account relationship, governance across SAP line of businesses and Enterprise Cloud services and is contact for all contract related topics

CAA/PCA : Cloud Advisory Architect

The CAA works alongside SAP IAE to present solution to the customer and supports dCEM + build team during handover to deliver.

CSP : Customer Success Partner

This role is depending on your contract, so if applicable this person is responsible for orchestrate all SAP teams with a customer, conduct regular business reviews and proactively engage with the customer’s stakeholders to provide guidance and expertise.

Source of the information: digital service enablement page

Fun fact

SAP is still searching for CDM and TSM roles (status of the job posting: 12/2024) and parallel is searching for dCEM roles - I'm confused .

Summary

SAP remains true to the motto of change. As soon as the customer gets used to processes, they are "improved" and adapted. Also most of the ECS description will change like the ECS workspace was already renamed to "Private Cloud Workspace". Upcoming articles for further changes:

latest updates to PC3 escalation framework
proactive maintenance with monthly maintenance windows: spotlight on to CMP (Contractual Maintenance Period) and MRC (Maintenance Readiness Check)

SAP RISE: Proactive Maintenance

Sun, 05 Jan 2025 12:49:41 GMT

SAP RISE: Shared responsibility with proactive maintenance

Proactive maintenance for SAP RISE will start now in 2025 with minor tasks like updating SPAM/SAINT and ST-PI / ST-A/PI. For those companies which are familiar with frequent maintenance windows, they are good to have such time frames to hold the systems up-to-date and secure. However, for larger companies where such frequent maintenance windows are not common because every minute of downtime is costly and may only really be necessary once, the situation is quite different.

SAP plans to introduce proactive maintenance running a push update service for selected technology components. The supported components will be announced separately and SAP plans to increase the scope over time.

Proactive maintenance will touch only the blue colored figures which represents the technology components
Proactive maintenance will be scheduled during a pre-announced maintenance window (customer-specific CMP - c ontractual m aintenance p eriod , or SAP-defined maintenance window)
Proactive maintenance will happen only on SAP systems which passed an upfront automated “Maintenance Readiness Check“ (= MRC )
Customers and IT partners will be notified upfront via automated e-mail notifications
The overall responsibility for patching remains with the customer, specifically for components where SAP provides no pro-active patching

"We understand performing an upgrade/update on the technology components will first be uncritical to your business application, and second, will not lead to request you as a customer to perform any validation after an SAP initiated change"

- Thorsten Hepting SAP ECS -

If we take this quote serious SAP says if we change only some technology components it will not harm any business application. My 20+ years of tech experience has shown me more than once that changing the operating system, SAP kernel, database or even SAP host agent can affect system stability and business process performance (shout out to SAP HEX engine). The behavior of QAS to PRD can differ significantly due to different infrastructure (number of application servers, sizing, parameter set etc.), data volumes and workloads. The first customer with a special workload who encounters a known issue in the HANA optimizer will gratefully refer to this quote. May be the quote was only in the context of tasks like SPAM/SAINT or ST-PI / ST-A/PI.

Maintenance process

SAP will send out mails to the planned downtime contacts maintained in the SAP for me portal. the changed will be executed in the SAP defined maintenance windows. Those are dates and times defined already in the SAP Cloud Services and which are region specific, having an individual defined date and time for MENA, APJ, Europe and America. On the long side SAP will perform the changes inside the contractual maintenance period (=CMP).

Customers have also an opt-out option to skip a campaign of proactive maintenance due to business specific reasons.

Additionally the affected systems have to pass an upfront automated Maintenance Readiness Check (=MRC). Only if these checks are all green, the deployment will be started. After the maintenance has been successfully finished another mail will be send out. In the end you will find in the SAP for me portal an overview of all the changes pushed by SAP within a new section and that will come in Q1 2025.

All technology components which may affect customer business processes are out of scope for Proactive Maintenance and will stay in full customer control and responsibility . Specifically, this includes Feature Package Stack (FPS) / Support Package Stack (SPS) Updates and Release Upgrades. SAP will continue to support these with on-demand technical execution and consulting based on Customer Service Requests.

=> May be this list should be more transparent which components are meant. S/4HANA FPS and SPS are crystal clear, but what else? The mentioned help.sap.com scope is not accessible for all customers.

CMP - contractual maintenance period

In future SAP will deploy changes in a customer defined CMP windows per system. This time windows will be used by SAP exclusively. This is a formal agreement between SAP and the customer as stipulated in the contract.

Prior to any maintenance, SAP will inform (usually at least 7 business days - source: RISE with SAP S/4HANA Cloud, private edition Supplement enGLOBAL.v.10-2024 ) the customer regarding the planned activities. The customer can request to reschedule the activities but this must be done within 5 days of the notification and must be rescheduled. The activities cannot be rejected permanently.

SAP-defined maintenance windows

For proactive maintenance events where CMPs cannot be used, as a fallback solution, SAP will define maintenance windows. This is possible mainly because this events will all be done as online changes and happening in system uptime.

MRC - Maintenance Readiness Check

MRC is a framework used by SAP to check if systems are ready to receive pro-active software changes. This framework is a new SAP development based on TCI and contains only ABAP repository objects. It's required to collect system data to better prepare upgrade/update procedures. The MRC will be used by ECS only. The MRC repository objects depend only on the underlying SAP NetWeaver functionality and have no dependencies to other components. MRC collects only relevant system informations (Installed Software Components, Database, Used Kernel, Application Servers, ...). MRC does not change anything in the system and uses only its own database tables to store the result of the MRC run.

The framework includes checks on the overall technical situation of the system and on specific qualities of planned software changes. Depending on the results of the checks, MRC categorizes each system as either Red or Green. Only for Green systems (meaning all checks) SAP will perform pro-active changes.

SAP Notes MRC:

3213339 - Maintenance Readiness Checks (MRC) - Central SAP Note
3386693 - Maintenance Readiness Checks - Content Delivery: Version 4 (Q1/2024)
3319026 - Delivery of Maintenance Readiness Checks (MRC)

My questions to this procedure:

If a customer always have QCM tables displayed in SE14 no maintenance can be performed means they don't have to opt-out just let one check not pass, right? This sounds like a permanently rejection option. What if customers are not fixing such red system tasks?
how and who will get an info for red systems?
For project or business frozen zones - how often such a maintenance can be skipped without getting a risk letter and take the full responsibility?
Is there a fallback for every maintenance task?
What happens if the maintenance window is exceeded? Fallback or early notification for increasing the downtime?

You have also questions to this new pro-active maintenance procedure by SAP?

Feel free to comment or contact me.

Range Partitioning - Dynamic Aging for NSE

Sat, 28 Dec 2024 17:38:09 GMT

Dynamic Aging for NSE - combined with Threshold and Interval option

Dynamic Aging

Currently you have to page out your NSE partition from time to time manually. This is an important task to save frequently memory and not wasting your costly resources. But sometimes it was forgotten or there is a project freeze phase and you cannot touch your systems. Today, such tasks can be carried out completely automatically and autonomously using the feature Dynamic Aging .

Dynamic Aging makes it possible to automatically manage at which point in time older partitions can be moved to the 'warm' data store => NSE. As an extension of the Dynamic Range Partitioning feature Dynamic Aging makes it possible to automatically manage when older partitions can be moved to the 'warm' data store (Native Storage Extension) with the load-unit attribute for the partition set to PAGE LOADABLE. Warm data is then stored on disk and only loaded to memory when required.

Dynamic Aging can be used with both THRESHOLD mode (defining a maximum row count number in partition OTHERS) and INTERVAL mode (defining a maximum time or other numeric interval between each new partition). For example, for a partitioned table which is managed by dynamic partitioning and containing date/time information, you can specify an age limit (for example six months) so that when data in an old partition reaches this age it is moved to NSE storage. The interval is referred to as a 'distance threshold' value.

Prerequisites

Dynamic Aging supports INTEGER columns and DATE columns using the following data types (the NVARCHAR data type is not supported ):

INTEGER data types: INT / SMALLINT / TINYINT / BIGINT
DATE data types: DATE / LONGDATE / SECONDDATE / TIMESTAMP

Syntax

... PARTITION OTHERS DYNAMIC [THRESHOLD <int> [DISTANCE <int> PAGE LOADABLE]]

... PARTITION OTHERS DYNAMIC INTERVAL <int + type> [DISTANCE <int + type> PAGE LOADABLE];

Interval option

CREATE COLUMN TABLE EXAMPLE (A SECONDDATE NOT NULL) PARTITION BY RANGE(YEAR(A)) (

PARTITION 0000 <= VALUES < 2021,

PARTITION 2021 <= VALUES < 2022,

PARTITION 2022 <= VALUES < 2023,

PARTITION 2023 <= VALUES < 2024,

PARTITION 2024 <= VALUES < 2025,

PARTITION 2025 <= VALUES < 2026,

PARTITION OTHERS DYNAMIC INTERVAL 1 YEAR DISTANCE 2 YEAR PAGE LOADABLE);

=> In this example, table EXAMPLE has a column for time values; it has an interval value of 1 year and a distance value of two years. This means new partitions generated by Dynamic Range will have range interval set as 1 year, and the partitions containing data older than 2 years (comparing with the latest data) will be moved to warm storage.

ALTER TABLE EXAMPLE ALTER PARTITION OTHERS DYNAMIC DISTANCE 3 YEAR PAGE LOADABLE;

Threshold option

[...] PARTITION OTHERS DYNAMIC THRESHOLD 3000000 DISTANCE 50000 PAGE LOADABLE

Deactivation

ALTER TABLE EXAMPLE ALTER PARTITION OTHERS NO DYNAMIC DISTANCE;

Manual Refresh

ALTER TABLE T1 REFRESH DYNAMIC DISTANCE

=> The background job to apply Dynamic Aging is timed to run automatically every 20 minutes but an update can be triggered manually for a single table with a REFRESH instruction

Pitfalls interval option

If a partition has been explicitly set to COLUMN LOADABLE, or if the column loadable attribute is inherited from its parent, then the partition's load unit will not be changed by Dynamic Aging. By default, the load unit setting of a partition is DEFAULT LOADABLE, which means there is no explicit preference. In practice, this means that you must not explicitly apply the COLUMN LOADABLE load unit property to an OTHERS partition where dynamic aging is active as this would prevent any automatic conversion of data.

How you can check if interval option is active?

SELECT TABLE_NAME, DYNAMIC_DISTANCE_INTERVAL, DYNAMIC_DISTANCE_LOAD_UNIT from TABLE_PARTITIONS

Summary

The Dynamic Aging feature is genius if you are using NSE, but cannot be used for SAP applications like S/4 or BW/4, because there are no table with datetime data type. NVARCHAR is not supported by now. You can only use it in HANA cloud or in HANA 2.0 native scenarios. Sadly but it is a first step.

Dynamic Range Partitioning - Interval Option

Sat, 28 Dec 2024 16:55:10 GMT

Dynamic range partitioning - option 2

Interval option

The interval option was introduced with SPS06 and can be used if you exactly know how the data will be distributed. Mostly it is used for time range partitioning. It operates like the threshold option on top of the OTHERS partition. It can currently only add partitions on base of the last range. It can not add a range before a already existing range. You can define a time interval based on month, year and hour. Currently an interval based on day or week is no possible by using this syntax. The target field for partitioning must be a real datetime type otherwise you have to use the integer option. The integer option will be used by default if no signal word like MONTH, YEAR or HOUR is used. It can be perfectly used for number ranges if you know how many distinct values represents a certain partition size. This means if you know that 50,000 values (not records!) of an attribute representing 250,000,000 - 500,000,000 records or a partitions size of 25 - 50GB than you may can use it as an integer interval to create automatically a right sized new partition. But use it with the needed care, there are a lot of pitfalls.

Prerequisites

partition schema: RANGE

type of partitioning: heterogenous

supported data types: DATE, TIMESTAMP, SECONDDATE, NVARCHAR,VARCHAR, TINYINT, SMALLINT, INTEGER, BIGINT, SHORTTEXT

partitioning and definition based on complete lengths of the fields

no type definition using INTERVAL means: INT

With the INTERVAL option there are two ways of measuring time: either as a time value (using data types such as DATE, TIMESTAMP, SECONDDATE - see the second example below) or, because time intervals are not always equidistant (for example, a month may have between 28 and 31 days), the option of using a numerical counter is supported (using data types such as INT, BIGINT, NVARCHAR).

Example for a datetime field

Alter table example PARTITION by RANGE (YEAR (GJAHR) ) ((

PARTITION 0000 <= VALUES < 2021,

PARTITION 2021 <= VALUES < 2022,

PARTITION 2022 <= VALUES < 2023,

PARTITION 2023 <= VALUES < 2024,

PARTITION 2024 <= VALUES < 2025,

PARTITION 2025 <= VALUES < 2026,

PARTITION OTHERS DYNAMIC INTERVAL 1 YEAR ));

=> In this example the field GJAHR is of type date

=> If one row will be entered with GJAHR "2026" or more, a new partition will be created with range 1 year as soon as the background job successfully finished

Example for a SAP table

Alter table FAGLFLEXA PARTITION by RANGE (BUDAT) ((

PARTITION 00000000 <= VALUES < 20230101,

PARTITION 20230101 <= VALUES < 20240101,

PARTITION 20240101 <= VALUES < 20250101,

PARTITION OTHERS));

Alter table FAGLFLEXA ALTER PARTITION OTHERS DYNAMIC INTERVAL 10000 ;

It can be defined also in one step:

Alter table FAGLFLEXA PARTITION by RANGE (BUDAT) ((

PARTITION 00000000 <= VALUES < 20230101,

PARTITION 20230101 <= VALUES < 20240101,

PARTITION 20240101 <= VALUES < 20250101,

PARTITION OTHERS DYNAMIC INTERVAL 10000 ));

=> In this example the field BUDAT is of type NVARCHAR and the default type will be INT

=> If one row will be entered with BUDAT "2025mmdd" or more, a new partition will be created with range 10,000 as soon as the background job successfully finished

Deactivation

ALTER TABLE FAGLFLEXA ALTER PARTITION OTHERS NO DYNAMIC;

Usage for NVARCHAR SAP time fields

In the SAP universe there are no real datetime fields. This means we have to use what we have:

4 chars like GJAHR
6 chars like BUDAT
14 chars like KDATU
21 chars like TIMESTAMP

Known Issues

[7]:feature not supported: Dynamic interval is not supported for non-HETEROGENEOUS partitioning type

=> only usable with heterogenous partitioning type

[2048]: columns store error: alter others partition: [2051] Function should be set and consistent with dynamic interval type when dynamic interval property is used

=> If the syntax MONTH | YEAR | HOUR was used, the column must be of type datetime.

[2048]: columns store error: fail to alter partition: [2051] partition specification not valid; invalud integer-like range: Length of bound 'xxxx' is not equal to the length 14 of the partitioning column. Make sure to fill up the bound with '0' from the left until the required size is reached.

=> be careful by using the hint of this error. If you specified only 4 chars while needing 8 chars you should not fill up with '0' from the left:

'2024' => NOT '00002024' !!!

'2024' => correct '20240101'

column store error: add dynamic range: [2594] SAPSID::SCHEMA:TABLE: Attempting to generate too many partitions, exceeding the configured maximum partitions count 1000. Please check the configuration partitioning::max_partitions_generated_by_dynamic_range (default: 1000). The interval granularity is probably not suitable, or consider modifying the configuration if necessary.

=> the background job was triggered and would have add >1000 new partition which indicated an error, because this is not a normal behavior to add such a high number of partitions. I think even 1000 is quite a high default the parameter max_partitions_generated_by_dynamic_range. This can be the case if your data includes rows with the year 9999. This is often the case for price conditions in table PRCD_ELEMENTS.

[7]:feature not supported: HETEROGENEOUS Dynamic Range others partition cannot have subpartitions

=> with multilevel partitioning the OTHERS partitioning can also have subpartitions - this is not suitable using dynamic partitioning. Remove the subpartitions of OTHERS or you cannot use the interval option

Dynamic interval partitioning does not allow gaps between ranges. Found lower bound 19700101 but the upper bound of the previous range is 00000000 : Partition specification is invalid

=> please always check your MIN and MAX values - there must be no gaps if the feature is to be used

column store error: add dynamic range: [2594] Encounter non-integer value in partition OTHERS

=> check your master data - there is something wrong with your data or you have selected the wrong field

Pitfalls interval option

Be aware that if you are running a SAP system on top of HANA you have no real date data types. This means you have to work with integer values and cannot use the interval type value YEAR, MONTH or HOUR!

In a multi level partitioning it can only used at the first level if the others partitioning has no sub partitions.

If you have a yearly partitions and the process allow to enter the year 9999 your design will not work because a lot of empty partition would be created. For this reason check always the minimum and maximum values before you activate it!

The feature currently (SPS08) does not allow gaps between ranges (see the error section above) and new partitions can only be created at the end of a range.

How you can check if interval option is active?

SELECT TABLE_NAME, DYNAMIC_RANGE_INTERVAL from TABLE_PARTITIONS

Summary

The interval option is must have for big systems with RANGE partitioning and multiple partitions. There are a lot of limitations but may be SAP will improve this feature more and more.

Are you still adding your partitions manually? Automate it if possible to avoid unnecessary hassle. If you want to play it safe and not try it on your own, please contact us. It is better to be safe than sorry!

Dynamic Range Partitioning - Threshold Option

Mon, 23 Dec 2024 15:14:36 GMT

Dynamic range partitioning

With RANGE partitioning (like mentioned in the blog series ), the data is divided into individual sections based on one or more characteristics. This allows you to determine exactly which data should be written to a partition. The most common use cases here are partitioning based on time or number values. In order to be able to determine the optimal size and, above all, the characteristics, in-depth application knowledge is required. Collaboration with the relevant specialist department is usually essential.

If partitioning is set up according to RANGE, regular maintenance must take place (e.g. definition of new partitions for the coming year for time-based areas, deletion of old partitions after archiving).

The big advantage is the flexibility and scalability with RANGE. Even if one range is not fitting your requirement any more you can just repartition the affected partitions. There is no need to repartition all data of the table. Only the required data / partitions will be touched. But this applies only for the standard (offline) option. The online option will always redistribute all the data.

Design

Range partitionings should always include an additional partition called OTHERS . This partition has no range definition and is the landing zone for records which cannot be assigned to a defined range partition. If a lot of records are saved into an OTHERS partition you should create a range for this data records or check what is going wrong. This means also proper monitoring is an important task when using partitioning.

When you create an OTHERS partition there is a risk that over time it could overflow and require further maintenance. Using the dynamic range feature the others partition is monitored by a background job and will be automatically split into an additional range partition when it reaches a predefined size threshold.

There are automatisms in place which called dynamic range partitioning.

Pitfalls RANGE partitioning

Since RANGE partitioning can be significantly more complex than HASH partitioning, there are also more pitfalls to consider. It may not be distributed evenly like for HASH designs. You are responsible to design it along the rules of partitioning.

You have to analyze the data quality of your partition attribute. If you just use a time attribute because it is the only one means not that it is the only way. If the attribute is not used in your queries you may will end up in a bad performance for this table, because no pruning can be used.

All additional options regarding dyn. range partitioning have certain limitations and besides benefits also some negativ impacts if you have not analyzed and monitored them well.

Threshold option

Tables with a dynamic others partition are monitored by a configurable background job which checks the current size of the partition in comparison to the defined limit and makes adjustments as required. If the OTHERS partition has exceeded the defined limit then all records in the OTHERS partition at the time the job runs are added to the new partition, the corresponding SQL statement is ADD PARTITION FROM OTHERS.

If you define a dyn. threshold of 50 Mio, a new range will be created with the min. value and the max. of the OTHERS partition.

You have defined ranges from 0 to 400,000. If you insert rows above the value 400,000 for CHANGENR they will be saved to the others partition. If the record count of the OTHERS partition (NOT the value of CHANGENR) will reach 50,000,000 a range will be created with the min value 400,000 and may be an odd number like 500,042 but again to illustrate it simple 500,000. A new empty OTHERS partition will be created for new entries without valid range as safe harbor.

It still can happen that a range can run full due to heavy usage of a certain number. This means multiple records of a CHANGENR. In this case, you still need to repartition your table and can adjust the threshold to a lower value.

Usage

This means this option can be useful if you are not aware of the min. / max. values of a partition and the only indicator is the records length and thus the partition size which leads to a certain number of records per partition.

Syntax

ALTER TABLE T ALTER PARTITION OTHERS DYNAMIC THRESHOLD 300000000;

SAP Documentation

Parameters

Partition parameters [partitioning] section of indexserver.ini :

dynamic_range_default_threshold (Default = 10000000)

dynamic_range_check_time_interval_sec (Default = 900s)

How you can check if threshold option is active?

SELECT TABLE_NAME, DYNAMIC_RANGE_THRESHOLD from TABLE_PARTITIONS

Pitfalls Threshold Option

Using the THRESHOLD property empty partitions are also removed during this process.

The creation of a new partition automatically stops the growing of existing partitions. You have to find out the right number of records for the threshold. This can be 300,000,000 records but this can also only 50,000,000 it depends on the scenario and usage of the table. It can also change over time due to higher workload. A proper monitoring is essentially for using RANGE partitioning. Do you have such a monitoring in place which monitors empty partitions, size of partitions, number of records per partition etc.? No? Let's get in touch to avoid unwanted situations (bad performance, error due to 2 billion records, right partition design, right threshold values etc.).

BW data tiering - a success story

Fri, 20 Dec 2024 16:35:52 GMT

Efficiently managing data for better performance and lower total costs

A few years ago, you often heard the phrase “data is the new oil”. Well this may be one of the reasons the BW systems are growing so fast. Since years there a possibilities with BW on anyDB and BWoH to save ressources with NLS. But for some scenarios this is not suitable in terms of performance or design. The challenge: Stop the growing and needed resizing of a already out of sizing BW/4HANA system of already 24TB (Scale-up). For additional optimization besides NLS, we analyzed the system and found more than just one product or feature could solve.

We found aspects which we see mostly in systems: a grown data model over several years. But we found ways to optimize:

Removed overhead in key attributes which reduced the PK size (often more than 50% of the overall table size)
optimized the partitioning design
used NSE for write optimized ADSOs
introduced NSE for several ADSOs
optimized usage of inverted individual indexes

We saved over 800GB just with removing unnecessary key attributes.

With an optimized partitioning strategy and the new possibilities of BW/4HANA we could reduce the meta data overhead in the dictionary which also saved over 500GB in total.

The introduction of NSE was the real game changer which saved more as we estimated. The estimation was round about to page out 4TB. In the end we paged out 5,4TB which results in terms of sizing in round about 10TB savings (some memory for the buffer cache must be counted in).

The journey is not over yet, we still have some ADSOs not covered and calculate with additional 1TB to be paged out. On top we are working on another possibility to convert the current inverted hash indexes to inverted value and save another 1,5 - 2TB of memory.

A great team effort which could only be achieved when BW team and DBAs working close together. The target of saving 8TB was exceeded.

ACDOCA - central element in S/4 HANA

Tue, 10 Dec 2024 13:05:31 GMT

ACDOCA table growth - how to handle it

Anyone dealing with S/4HANA heard about universal journal and the table ACDOCA. It is one central element of the S/4HANA simplification and also one of the largest and fastest growing tables.

Due to this fact I had to deal with it 2 years ago in the context of data tiering (NSE). The tables had 448 columns with the release S/4HANA 1909 . SAP warned to use NSE for central complex tables, but the customer was brave enough to test it with Capture&Replay before going live with it. We achieved with our NSE design an average saving rate of 23% (max. 38%) of the table size.

2 years later we are reviewing this design again and I wondered about the size and the low saving rate. The customer updated to S/4HANA 2022 and has now 494 fields ! This means 46 additional fields . Over the years the releases received several new default fields and sometimes also customer extensibilities (SAP Note 2453614 ).

There are some kind of "What's New in SAP S/4HANA xxxx" documents, but they are not covering all changes regarding all new fields. The new fields are also responsible for a 5% higher growth and of course the lower NSE saving rate.

I started to figure out which field was introduced with which release but the documentation is about such details is a mess:

S/4HANA 1909 ACRVALDAT

S/4HANA 2020 FIPEX

S/4HANA 2021 CBTTYPE RFCCUR FCSL

S/4HANA 2022 AUFNR_ORG VORNR_ORG

We analyzed the new SQLs running against ACDOCA and the new fields. We adapted our strategy and could eleminate 93% of the new not considered growth. This means not 5% growth rather 0,35%. This small number might not impress but if the table has a size of over 400GB and you save 80 or 100GB it matters. If you also consider other big tables for NSE like PRCD_ELEMENTS or CDPOS you can save multiple 100GBs which will save hardware costs, license / maintenance costs. In our case our first ACDOCA NSE design was very conservative to hold the performance impact as low as possible. With our new design we are more aggressive but always with a trade-off in mind. We increased out savings from 21% to 30%. This means for this system about 280GB savings.

In the end nothing speaks against NSE with ACDOCA.

Keep in mind: You should always combine NSE with archiving, but this is not possible in all scenarios.

SAP HANA 2.0 SPS08 Roadmap

Fri, 06 Dec 2024 11:38:17 GMT

The latest features of HANA 2.0 updated

The roadmap via Road Map Explorer was recently updated and some interesting features jumped into the spotlight. Some of them are already known because they are already implemented in HANA 4.0 (HANA Cloud). SAP HANA 2.0 SPS08 was released at the end of November 2024.

The interesting topics with important changes are: partitioning, data tiering (NSE), security, optimizer, backup and XSA. No, you won't hear any machine learning or AI features from me. If you really want and need them, because there are some, please go to Road Map Explorer :)

Partitioning

Support for a generated column as a partitioning key
Support for heterogeneous HASH-RANGE partitioning

=> currently HASH-RANGE was only possible for non-heterogeneous / homogeneous partitioning, so it was not possible to use the dynamic range interval option - a great one!

Support heterogeneous partitioning into three levels for the following partitioning types:
RANGE-RANGE-HASH
RANGE-RANGE-RANGE

=> some of you may noticed that some monitoring views in SPS07 already containing some level 3 partition details

=> I'm curious to find a business case for this partition designs

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

Data Tiering - NSE

Automatic setting of the minimum-required buffer cache size of the native storage extension, as per persistence size
Calculate and set the UNLOAD_THRESHOLD parameter size of the buffer cache automatically based on the persistence size for data in SAP HANA native storage extension

=> SAP mean the parameter buffer_cache_cs - unload_threshold which is set by default to 80 (%)

=> Currently I don't know if this feature helps customers to size the buffer cache properly

Dynamic aging for range partitions to native storage extension
Enable for dynamic creation of a new range partition, assignment of the load unit "page-loadable" to all range partitions with a certain distance to the new partition

=> I'm really excited to test this feature, because it will make the life of a DBA easier, if you are using NSE on partition level

Provide a transparent switch between column-loadable and page-loadable data without converting the persistency format
Significantly reduce conversion time between page-loadable and column-loadable data and, thereby, reduce business downtime and greatly simplify administration for native storage extension

=> this will make the implementation of NSE faster and easier due to lower downtimes - great feature!

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

Optimizer

Cache different SQL execution plans based on parameter values that cause variant SQL execution plans for HEX

=> this one of my most anticipated feature, because the HEX or more precise the optimizer made a lot of trouble in the past due to switching engines and the eviction of HEX plans

=> to be able to use multiple plans at a time depending on the bind variables can be a game changer in terms of performance using the HEX

=> this feature is already available since Q2 of 2024 for HANA Cloud named as SQL Plan Advisor

Source: Youtube: What’s New in SAP HANA Cloud | June 2024 | Susen Poppe and Product Experts

Security

Extend support for persistence, log, and backup encryption algorithms to AES 256 CTR
Activate TLS version 1.3 protocol by default for SQL connections for SAP HANA version 2.0 SPS 08
IP-based connect restriction for user groups: Ability to limit access for all users or parts of the user base, for instance, to enable only administrators to log in from the company’s IP range

=> Activating TLS 1.3 by default can create some trouble for some customers, but the implementation was more than necessary after this long time

=> the IP-based connect restriction allows to implement a SoD (Segregation of duties) concepts or helps to isolate instances

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

XSA

Improve setup of SAP HANA, extended application services, advanced model behind a reverse proxy
Make the solution more robust, especially during system replication takeover, as functionality of the internal system is not dependent on the external route and internal requests are “short-circuited”
Enable users to log in from external and internal software
Separate networks and DNS zones of external and internal domains
Hide internal back-end ports from public access by exposing the external app end points only (for example, to the public Internet) using reverse proxies

=> I'm waiting for such a feature for the "normal" HANA not only for XSA

Backup

Setting local secure store (LSS) as the default secure store
If LSS is used, inclusion of all necessary secure store backups in SAP HANA backups, eliminating the need to maintain secure store backups explicitly

=> to set LSS as default can also create some trouble and should be implemented carefully

At the end really useful features. I hope that they implement some new monitoring views for NSE and partitioning - otherwise we (XLC) can implement our own solution to get the needed information collected in own history views for our customers. Due to the lack of events around the topic HANA it was not possible to provide the needed feedback for so many customers. The consequence? A lot of missing features which SAP is not aware of. Yes, there is an idea/influence page but without enough votes you can not reach your goal even if the idea is brilliant, because SAP is not aware of the need.

End of maintenance for HANA 2.0 SPS05 in 2025

Thu, 21 Nov 2024 09:48:49 GMT

End of maintenance HANA SPS05 updated

Planen Sie zum Ende 2025 den Upgrade auf HANA 2.0 SPS07 oder SPS08 (Release 11/2024), sollten Sie sich aktuell auf SPS05 befinden. Bitte beachten Sie die unterstützten Betriebssysteme und planen Sie den OS Update/Upgrade mit ein!

Sie können von SPS05 direkt auf SPS08 wechseln. Beachten Sie hier bitte den Update-Pfad.

Sowohl die Parameter, als auch die Änderungen in Features / Engines haben Einfluss auf die Stabilität und Performance.

Wir unterstützen Sie bei der Validierung für ein optimales Ergebnis.

If you plan to upgrade to HANA 2.0 SPS07 or SPS08 (Release 11/2024) at the end of 2025, you should currently be on SPS05. Please note the supported operating systems and plan the OS update/upgrade!

You can switch directly from SPS05 to SPS08. Please note the update path here.

Both the parameters and the changes in features / engines have an impact on stability and performance.

We support you with the validation for an optimal result.

Release HANA 2.0 SPS08

Thu, 21 Nov 2024 03:48:52 GMT

SAP HANA 2.0 SPS08 wurde Ende November 2024 für Kunden freigegeben. Das Release besitzt 4 Jahre Wartung. Parallel bleibt SPS05 bis Dezember 2025 und SPS07 bis April 2028 in der Wartung. Bitte beachten Sie beim Update mögliche Performancebeeinträchtigungen der HANA HEX Engine .

Für folgende Bereiche sind Verbesserungen zu erwarten:

NSE
Security
Data Integration (SDA)
Supportability enhancements
SQL/SQL-Script Enhancements
Additional Partition options

SAP HANA 2.0 SPS08 was released to customers at the end of November 2024. The release has 4 years of maintenance. In parallel, SPS05 will remain under maintenance until December 2025 and SPS07 until April 2028. Please take attention to possible performance impact due to the HANA HEX engine .

Improvements can be expected in the following areas:

NSE
Security
Data Integration (SDA)
Supportability enhancements
SQL/SQL-Script Enhancements
Additional Partition options

Details:

2378962 - SAP HANA 2.0 Revision and Maintenance Strategy

3411133 - SAP HANA Platform 2.0 SPS 08 Release Note
SAP HANA 2.0 Revision Strategy

RISE with S/4HANA: Myth and Truth with feedback of customer projects

Mon, 18 Nov 2024 13:34:53 GMT

Feedback of customer projects and the labyrinth of the roles & responsibilities list

"RISE with SAP is a care package the software vendor is taking care of all the operational tasks. Everything from a single source. You don't need internal staff to manage the systems. In any case, it is currently difficult to find SAP experts to keep operations running and meet all the security specifications."

"The central task of many customers is to produce products or deliver services, but not to run SAP systems. You don't need an own data center in the modern digital world. If you want to be flexible, innovative and scalable, you have to use the cloud. We get fixed prices and know what we will get. We will never get cheaper prices for RISE than we do now.

This and similar sentences I heard the last months a lot from customer exchanges. But are all this arguments true and valid? I will collect some of them and try to find the correct answers with facts inside the contract chaos.

"The RISE with SAP offering includes AI-powered cloud ERP managed and optimized by SAP . It provides services and tools based on SAP's clean core approach to help you migrate on-premise systems, transform business processes, continuously innovate, and embrace cloud agility."

Source: https://www.sap.com/germany/products/erp/rise.html

"With RISE, we only handle the basic operation of the SAP system . We’re experts in this stack around HANA cloud. We also keep up with all the infrastructure innovations, and we excel at the lifecycle management level.

After all, we built all of this ourselves. Beyond this basic operation, customers have the freedom to customize. "

- Christian Klein CEO SAP SE

What are the basic operations? I think everyone will understand different meanings of it.

First rule: The customer remains fully responsible for maintenance and security! The customer must create service requests with the correct details and categories. If you want a database patch or an OS security fix applied the customer must act! Some current RISE clients told me that proactive advice on known issues was less or non-existent.

A rgument: "You don't need internal staff to manage the systems!"

T ruth: You will still need internal staff to create tickets and be responsible to head the ECS (Enterprise Cloud Services) teams. The only people who know which systems are dependent and knowing the internal process behind are the internal guys. The tasks will change from the OS console to orchestrate ECS. But you need people with the know-how and background information. They cannot be easily replaced with any external! The customer has to coordinate maintenance with which (SAP predefined) version and security fix. The customer is responsible to raise the requests! Without the needed know-how this will be a nightmare.

A: "You don't need an own data center in the modern digital world. If you want to be flexible, innovative and scalable, you have to use the cloud"

T : Some services cannot be replaced with RISE. There are some non-SAP services which cannot be handed over. There are still good reasons for an own data centre, hosted services or IaaS. SAP has standardized the SAP operations, but for non-SAP services some standard are missing. The raising costs in the past also show that you cannot calculate all costs of the next 5 years. Be aware : Also SAP has raising cloud costs in their RISE contracts. ( Sample Order Form 5.4: "The Cloud Services shall be subject to an annual fee increase of 3.3% effective on each anniversary of 27.04.2024")

A: "RISE with SAP is a care package the software vendor is taking care of all the operational tasks. Everything from a single source."

T: Which tasks are really covered is written in the service contract which every responsible person of the internal SAP should know. Only if you know what is covered and what costs extra, you can act accordingly. Most of the SAP teams I talked to never saw the contract. Root cause analysis (RCA) are only valid for productive environments. If your tests system is on heavily load or after a maintenance the system crashed, you won't get a RCA. This means it can appear in any point in the future in the productive environment. The roles & responsibilities ( R&R ) list/matrix should be read and compared with care. Not every task is 100% what you think. Please ask very properly if your understatement is correct.

An example: Table partitioning

Starting with RISE in 2021 partitioning was not part of the R&R . The list is valid with the version you have signed the contract. Any subsequent changes will not apply to you.

If you need a partitioning or repartitioning of a table you have to raise a ticket to find a suitable design (HANA_1.1.25). This is a CAS available at additional charge. You can also define the design by your own or via a third party consultancy.

If you found a design, you have to create a new ticket for the technical execution (HANA_1.1.04) which is a standard service and already covered. But only for one table per SID per year. If you want more tables partitioned (HANA_1.1.35), you have to pay for an additional services . Some MSPs act like this others have monthly budget for several service requests regardless which time effort the request has. Others have a ticket system with categories for each service request duration and a defined number of each category is included in the monthly fee. You have to compare apple and apple - this is in the end what makes it difficult to compare each service.

A: "The SLAs are equal or better than the current once"

T: It depends. They may sound better like they are (99,7% for PRD or 99,9 for PRD with HA), but please read the small parts of the contract. This may differ from your expections or what your are currently have defined in your own DC.

Excluded Downtime

... means the Total Minutes in the Month attributable to a Maintenance Window; or any Major Upgrade

Window for which the Customer has been notified at least 5 business days in advance; or unavailability caused by factors outside

of SAP’s reasonable control, such as unpredictable and unforeseeable events that could not have been avoided even if

reasonable care had been exercised.

Source: SAP

“ Emergency Downtime ” means downtime during emergency patch deployment and emergency operating

system upgrades as described in the Supplement.

“ Excluded Downtime ” means the Total Minutes in the Month attributable to: Scheduled Downtime; Agreed

Downtime; Emergency Downtime; downtime caused by factors outside of SAP’s reasonable control such as

unpredictable and unforeseeable events that could not have been avoided even if reasonable care had been

exercised (see examples in Section 2); or downtime of a NON-PRD system caused by using the NON-PRD

for failover/to repair to a PRD system.

2.2.4 . Interruptions or shutdowns of the Computing Environment, or portions thereof (or Servers for Server

Provisioning) resulting from the quality of the Customer-provided software and/or Customer’s customizations

or modifications of the Customer-provided software , Subscription Software or Computing Environment (or

Servers for Server Provisioning), unless this is the responsibility of SAP under this Agreement.
Source: SAP - " SERVICE LEVEL AGREEMENT FOR PRIVATE CLOUD EDITION SERVICES AND TAILORED OPTION"

3.3.2 . Notwithstanding the foregoing, SAP reserves the right to perform Emergency Maintenance activities at any time

without Customer’s prior consent. SAP will use reasonable efforts to provide Customer with forty-eight (48) hours

advance notice regarding performance of Emergency Maintenance. In case of Cloud Service downtime during

such Emergency Maintenance, such downtime will be considered “Emergency Downtime” as defined in the SLA

(defined in Section 3.4 below). “Emergency Maintenance” are maintenance activities reasonably necessary to

prevent or mitigate circumstances that may otherwise pose a significant impact to the Cloud Service.

Source: RISE with SAP S/4HANA Cloud, private edition Supplemental Terms and Conditions

A: "SAP is delivering innovation only in the cloud and the roadmaps are clearly defined."

T: Innovations will be released first in cloud releases and sometime first in public cloud ! Not each SAP cloud (public/private) is handled similar. Some of them may also be downported to on-prem software. SAP reserves the right to withdraw any cloud software after short notice. This already happened for smaller products like LAMA cloud (SAP Landscape Management Cloud).

In the end RISE is not equal RISE. Every single customer scenario will be different. You cannot compare them such easily.

this list will be extended - stay tuned

SAP HANA Hyperscaler news 09/2024

Fri, 20 Sep 2024 09:28:44 GMT

News for AWS, GCP and MS Azure

�� GCP has certified the first Emerald Rapids SP instances - c4-highmem (2024-08-14)
�� MS Azure has certified Msv3 + Mdsv3-series with max. 1792 vCPUs and 30TB RAM (2024-09-02)
�� AWS is the leader in the virtualized instance type category
�� GCP is the leader in the bare metal instance type category

total by RAM statistic:
1. GCP : x4-megamem-1920-metal: 32.768 GiB
2. MS Azure: M896ixds_32_v3 / M1792ixds_32_v3: 30.400GiB
3. AWS: u7in-24tb.224xlarge: 24.576GiB

�� As MS Azure's S-Series (HANA Large Instance service) is in sunset mode, there are no bare metal instances left which you can order.

Beware of cloud costs

Fri, 13 Sep 2024 11:55:27 GMT

Unforeseen cloud cost increases

The TCO calculation of cloud costs is a moving target. In the past, all hyperscalers have increased their prices or, like other cloud service providers such as SAP, have directly included an annual increase in the contract. The focus is usually directly on the services consumed, but associated costs, which are still small today and have never been on the radar, can explode. This is the case if the providers have changed their licensing/subscription model. Most recent case to name is Broadcom/VMware but now also another vendor announced a change: RedHat.

Most SAP systems are still running on SUSE and as far as I know also all RISE (+GROW) with SAP systems (public+private). In the past more and more customers changed the OS strategy due to lower/equal costs and RHEL features. They migrated their systems to RHEL.

RedHat announced back in January this year that the costs for cloud partners will be changed effective April 1, 2024. They called it scalable pricing. The previous pricing structure featured a two-tiered system that categorized VMs as either "small" or "large" based on the number of cores, or vCPUs, with fixed prices assigned to each category regardless of the VM's actual size. The duration of VM allocation determined subscription fees, as the number of cores or vCPUs did not influence the pricing, resulting in a capped cost for RHEL subscriptions.

Old RHEL Subscription model categories

Red Hat Enterprise Linux Server Small Virtual Node (1-4 vCPUs or Cores)
Red Hat Enterprise Linux Server Large Virtual Node (5 or more vCPUs or Cores)

This means the new price is depending on the number of vCPUs. Unlike before, the cost of a subscription will no longer be capped. Now some of you remember the chaos of the socket subscription or the oracle licensing model incl. the analogy of the parking spots. This means a physical core costs as much as the virtual core. Ok, fair enough if I use more cores I have to pay more. But this means the costs can also be lower for systems with less vCPUs, right? It can be a good thing, this new fancy "scalable pricing". So, when the costs are dropping and rising and who is affected?

Redhat:

"In general, we anticipate that the new RHEL pricing to cloud partners will be lower than the current pricing for small VM/instance sizes; at parity for some small and medium VM/instance sizes; and potentially higher than the current pricing for large and very large VM/instance sizes."

New RHEL Subscription model categories:

Red Hat Enterprise Linux Server Small Virtual Node (1-8 vCPUs or Cores)
Red Hat Enterprise Linux Server Medium Virtual Node (9 - 128 vCPUs or Cores)
Red Hat Enterprise Linux Server Large Virtual Node (129 or more vCPUs or Cores)

Amazon's statement :

"Any new product (such as a new instance type, new instance size, new region, etc.) launched after July 1, 2024, will use the new RHEL pricing. Therefore, any new rates (such as new regions or new instance types) launched after July 1, 2024, will be on the new RHEL pricing, even if the Savings Plans were purchased prior to July 1, 2024."

Microsoft Azure statement :

"In response to Red Hat’s price changes, Azure will also be rolling out price changes for all Red Hat Enterprise Linux instances. These changes will start occurring on April 1, 2024, with price decreases for Red Hat Enterprise Linux and RHEL for SAP Business Applications licenses for vCPU sizes less than 12. All other price updates will be effective July 1, 2024."

GCP statement :

"On January 26, 2024, Red Hat announced a price model update on RHEL and RHEL for SAP for all Cloud providers that scales image subscription costs according to vCPU count. As a result, starting July 1, 2024, any active commitments for RHEL and RHEL for SAP licenses will be canceled and will not be charged for the remainder of the commitment's term duration."

This means with the receiving of the July invoice in August the first customer took notice of the change. The smart cloud architects who considered the usage of cloud Finops noticed it earlier ;)

Let's have a look at the MS Azure pricing calculator , because they still have the most market share. With 12 or less vCPUs you will save money. But what does it mean for customers running SAP HANA instances, due to the fact that the smallest MS Azure instance is 20vCPUs? The cost of RHEL for SAP was previously $94.90 (constant line at the bottom of the graph) per month for all certified HANA instances.

MS Azure: RHEL price per certified HANA SKU [source: MS price calc: europe west / germany west central]

If you are running large instances with 128 and more vCPUs you will see that the costs are differ with more than $10,000 per month! If you are using large sandboxes or features like HANA system replication (HSR), you can multiple this additional costs.

MS Azure: Difference of 3 years reserved instances (3YRI) RHEL for SAP total instance costs [source: MS price calc: europe west / germany west central]

If we drill it down to the RHEL only costs per month, we can also the see the price per vCPU and the switch from 64vCPU to 128vCPU price.

MS Azure: Difference of 3 years reserved instances (3YRI) RHEL for SAP costs per month (before vs. now) [source: MS price calc: europe west / germany west central]

MS Azure: total RHEL pricing per SKU with costs per vCPU [source: MS price calc: europe west / germany west central]

Summary

For those using RHEL for small instances < 12 vCPUs the new RHEL pricing model is a saving. For SAP customers with larger instances it is a nightmare with unplanned additional costs which take directly effect by July 1, 2024.

Paying the same price for a physical core as for a virtual core is a simple calculation, but it does not have the same value. Anyone using multithreading will be penalized more heavily, and once again the customer will question whether Intel is worth the effort when comparing the cost and the performance gained.

Are customer now stop migrating to RHEL in cloud projects due to this heavy price difference?

Is it possible to get some RHEL volume discount?

The previous TCO calculation can be thrown in the trash.

Strange findings:

price calculators of Google and MS Azure are not up-to-date with the new RHEL pricing model
if you choose RHEL for SAP with HA option you get the old price of $87,60 for <= 8vCPUs and $204,40 for larger instances in the price calculator of MS Azure
MS Azure is calculating the large virtual node price ($7.01 per vCPU) for the 128vCPU SKUs which should have the medium virtual node price ($7.88 per vCPU) by definition

Options:

AWS and may be some others can provide RHEL volume discounts in exchange for an annual spend commitment. Please work with your Technical Account Manager to assess if you qualify.
Resize your instances which do currently not need the number of vCPUs
migrate to SUSE (but sure SUSE will also adapt their costs in the near future - just a matter of time)

SUSE - Lifecycle

Fri, 16 Aug 2024 14:20:10 GMT

How to interpret the SUSE Lifecycle

SLES4SAP 15 SP6 is now officially certified for SAP HANA 2.0 (SAP note 2235581).
If you are still running SLES12, you can use that as your target SLES SP, as support for SLES12 will end at the end of October this year (2024) unless you pay for LTSS.

This means regardless if you have SLES12 SP5 plain/vanilla or SLES4SAP12 SP5. The final SP of a major release will be handled special.

But first things first. One big advantage of SLES4SAP is that it is including 1.5 years of General Support plus 3 years of Extended Service Pack Overlap Support (ESPOS) for each service pack. This eliminates the need for customers to purchase LTSS (Long Term Service Pack Support) until the final service pack of a release. The key word here is "until". As already mentioned, the final SP won't get ESPOS because there will be no overlap with a further SP. This is the reason why the final service pack receives a longer general maintenance. If this still is not satisfying your need, you have the option to receive an extended 3 years of support for this final service pack through Long Term Service Pack Support (LTSS), which is available at an additional cost.

The Long Term Service Pack Support Core (LTSS Core) subscription offers support, patches, and maintenance for a core set of components of the product over the Extended Core lifecycle phase, which covers another 3 extra years after the Extended Lifecycle phase covered by the Long Term Service Pack Support (LTSS).

Sources:

https://www.suse.com/products/long-term-service-pack-support/

https://www.suse.com/support/policy-products/#sap

https://www.suse.com/lifecycle/#suse-linux-enterprise-server-for-sap-applications-12

https://www.suse.com/lifecycle/#suse-linux-enterprise-server-for-sap-applications-15

RISE with SAP: Roles & Responsibilities

Fri, 24 May 2024 18:34:14 GMT

Essential comparison

For every possible RISE with SAP customer it is essential to know the difference of the status quo system construct (on-prem self managed / hosted or managed by a MSP) and the RISE offering with a lot of excluded tasks or tasks with additional costs. If you don't need this tasks, it might be a perfect solution, but our experience is that most customers need some of the services with extra costs.

There is a list called roles and responsibilities (public information) which is listing all the services which are defined as :

Standard services
SAP Cloud Application Services ("CAS") (can be performed by customer)
Optional Services (can only be performed by SAP; no CAS; additional costs)
Additional Services (can only be performed by SAP; no CAS; additional costs)
Excluded Tasks (can only be performed by the customer)
not offered

Some of this tasks are defined as "Excluded Tasks" which you may think they are unimportant and not business critical. But if you ask any of your architects, security officers or SAP basis colleagues they will tell you that the sizing, monitoring and patching of the server infrastructure (VM) / OS is more than important for a stable operating system. The customer is responsible for this tasks !

Now the question is why SAP is not offering such services as standard when this tasks are so important? At first they only apply to additional server instances to run non-SAP applications. This may only apply to a very small group of customers who need this.

But why the mentioned tasks are so important?

Sizing

If the sizing of your instance does not fit to your workload needs, you will end up in a resource bottleneck which can lead to wait times or in the worst case to a failure due to OOM (Out of memory).

2. OS patches and security updates / antivirus pattern updates

Since NIS2 is a omnipresent topic, these aspects fall under it. It is important that the systems are kept up to date and regularly maintained to close known security gaps. For essential establishments, fines of up to 10 million euros or 2% of annual worldwide turnover (whichever is greater) may be imposed. You'd think that should be important, right? In comparison to the systems running SAP applications, SAP is not offering an OS or AV pattern patching.

3. OS Monitoring

The as for the patching is valid for the OS monitoring of non-SAP applications. It is an excluded task which is in the responsibilities of the customer! But how the customer with a cloud only strategy can monitor this? A lot of effort on customer side or another MSP which takes this as his responsibility.

Summary

For all customers consuming the standard service of running ERP or S/4HANA with RISE some standard monitoring is included. But please take into account that every special metric or KPI might be a special request for SAP and everyone understand a different depth when talking about monitoring. It can mean a 5s or a 60s sampling. What does it mean to monitor the disk or network utilization? IOPS? service time? throughput? package size? number of packages? Please be specific and compare apples to apples. Don't be surprised if you get not what you expected because you will get what you signed and paid for if you not ask for details.

HANA systems: Linux swappiness

Sun, 24 Mar 2024 15:34:08 GMT

Page Priority

################################

German version (scroll down for English)

################################

Seit SLES15 SP4 und RHEL8 (auch bei anderen Linux Distributionen) hat sich das Verhalten beim Reclaim geändert ( Details )

Vorher: vm.swappiness Default 60 [Range: 0 - 100]

Nachher: vm.swappiness Default 60 [Range: 0 - 200]

2 Arten von Pages:

anonymous page: dynamische Laufzeitdaten wie stack und heap
FS (Filesystem) page: Payload wie Applikationsdaten, shared libs etc.

Mit einem Wert von 100 wären damit anonymous pages und FS pages gleichgewichtet. Mit 0 - wie bisher auch - wird das swap Verhalten deaktiviert. Je höher also der Wert gesetzt wird, desto höher gewichtet man die anonymous pages. Es wird immer "kalte" Pages geben, welche einmalig in den Speicher geladen wurden und bei denen es Sinn macht sie früher auszulagern bevor der Speicher tatsächlich mal knapp wird.

Details

Früher (vor SLES11 SP3) wurden die anonymous pages nicht in das Verhalten miteinbezogen. Seit dem hatten man eine 1:1 Gewichtung der Kosten (file-cached pages : anonymous pages) eingeführt. Es wurde immer davon ausgegangen die file pages häufiger zu scannen und auszulagern als die anonymous pages, da es als recht teuer und damit als störend empfunden wurde. Es wurde also über Zeit erkannt, dass es in manchen Situationen doch Sinn macht dieses Verhalten zu ändern, daher hat man den Mechanismus granularer gestaltet.

Summary

Am Ende des Tages, wer hätte das gedacht, ist der neue Algorithmus effektiver und sinnvoller, sorgt aber dafür dass es zu höherem Paging Verhalten führt. Das macht aber nichts, da die Pages die ausgelagert werden tatsächlich mehr als "kalt" sind. Es muss sich also keiner Sorgen machen der bei gleichem Workload und Sizing nun erhöhtes Swapaufkommen bemerkt. Dazu gibt es auch neue metriken in vmstat mit denen sich das Verhalten monitoren lässt.

Empfehlung

Wenn es also viel I/O im System anliegt und der Anteil von FS pages gering ist, kann eine Erhöhung des vm.swappiness Parameters die Performance positiv beeinflussen. Daher empfehle ich den Parameter bei SLES15 SP4+ _nicht_ auf 0 oder 1 zu setzen. Tests haben gezeigt, dass sich mit dem Wert von 10 am besten mit HANA und dem damit verbunden Workload arbeiten lässt, allerdings kann auch ein höherer Wert dienlich sein (10 - 45 aus meinen Tests), da es darauf ankommt welche Third-Party Tools auf dem System zusätzlich laufen (AV, backup, monitoring etc.). Dies kann nur mit Tests und längeren Analysen beantwortet werden.

Fazit

Bleibt aber die Frage nach dem richtigen Monitoring offen. Früher hat man alarmiert sobald swap space genutzt wurde, da man davon aus ging, dass ein Speicherengpass vorliegt. Diese Frage muss sich nun jeder selbst stellen und für sich beantworten. Welche Metriken wurden dafür benutzt? Ab welchen Schwellwert alarmiere ich anhand der neuen Metriken? Kann mein Monitoring Tool diese neuen Metriken auslesen? Muss ich mir eine custom Lösung bauen? All das ist abhängig von der aktuellen Monitoringlösung.

################################

English version

################################

Since SLES15 SP4 and RHEL8 (also in other Linux distributions) the behavior of reclaim has changed ( details )

Before: vm.swappiness Default 60 [Range: 0 - 100]

After: vm.swappiness Default 60 [Range: 0 - 200]

2 types of pages:

anonymous page: dynamic runtime data such as stack and heap
FS (Filesystem) page: Payload such as application data, shared libs etc.

With a value of 100, anonymous pages and FS pages would be weighted equally. With 0 - as before - the swap behavior is deactivated. The higher the value is set, the higher the anonymous pages are weighted. There will always be "cold" pages that have been loaded into memory once and for which it makes sense to swap them out earlier before the memory actually runs out.

Details

Previously (before SLES11 SP3) anonymous pages were not included in the behavior. Since then, a 1:1 cost weighting (file-cached pages: anonymous pages) has been introduced. It was always assumed that the file pages would be scanned and outsourced more frequently than the anonymous pages, as it was perceived as quite expensive and therefore annoying. Over time it was recognized that in some situations it makes sense to change this behavior, so the mechanism was made more granular.

Summary

At the end of the day, who would have thought, the new algorithm is more effective and sensible, but ensures that it leads to higher paging behavior. But that doesn't matter because the pages that are being swapped out are actually more than "cold". So no one has to worry about noticing increased swap volumes with the same workload and sizing. There are also new metrics in vmstat that can be used to monitor behavior.

Recommendation

So if there is a lot of I/O in the system and the proportion of FS pages is low, increasing the vm.swappiness parameter can have a positive effect on performance. I therefore recommend not setting the parameter to 0 or 1 for SLES15 SP4+. Tests have shown that a value of 10 is best for working with HANA and the associated workload, although a higher value can also be useful (10 - 45 from my tests), as it depends on which third-party tools are used also run on the system (AV, backup, monitoring, etc.). This can only be answered with tests and longer analyses.

Conclusion

However, the question of the correct monitoring remains open. In the past, an alarm was raised as soon as swap space was used because it was assumed that there was a memory bottleneck. Everyone has to ask themselves this question and answer it for themselves. What metrics were used for this? At what threshold do I alert based on the new metrics? Can my monitoring tool read these new metrics? Do I have to build a custom solution? All of this depends on the current monitoring solution.

SUM tooling with target HANA

Mon, 18 Mar 2024 08:39:03 GMT

SUM tooling: what is currently not covered for big tables

"The SUM tool will do all the work and guide us, when something is missing"

- true or false ?

Numerous IT projects such as S/4HANA projects or HANA migrations will go live over the Easter weekend. Mostly this tasks will be controlled by the SAP provided SUM tool. The SUM is responsible for the techn. migration/conversion part of the data. Over the past years it become very stable and as long as you face no new issues nearly every technical oriented employee at SAP basis team can successfully migrate also bigger systems. In former times you needed a migrateur with certification which is no longer required. As long as all data could be migrated and the system is up and running the project was successful. But what does the result look like? Is it configured according to the best recommendation and experience? Is it running optimized and tuned?No, this is where the problem begins for most companies. The definition of the project milestone is not orienting on KPIs. It is simply based on the last dialog of the SUM tool, which states that the downtime has ended and all tasks have been executed successfully.

Neuer Text

1. HANA DB - the final table structures after SUM handling

If you look at your final HANA database, you will also see some partitioned tables. The most customers think 'perfect SUM has taken care also of my partition design'. Since years I see worse partition design due to the handling of SWPM and SUM. The target of this tools is just a fitting structure bypassing the 2 bln records limitation. This means only a few tables like CDPOS or EDID4 will get a proper HASH design on a single column. This means the selection of partition design is appropriate but may be not the number of partitions. The growth is not considered.

2. Wrong partition design

The rule for most of the other tables is if the table has more records than 1 bln per table/partition partition it by the primary key (PK). The partitioning by PK will always achieve a working structure, but is it recommended to use it as partitioning attribute? No! Especially in the context of performance it is horrible to use the PK. Partition pruning and NSE can not or only partly be used on this tables depending on the query (regarding pruning).

3. Missing partitionings?

Are all tables partitioned by SUM which should be partitioned? Also here the answer is no! There are some golden rules on the HANA database how big partitions should be created at the beginning. The partition size should be min. 100 million and max. 500million records. The SUM splits as soon as you reach 1 bln records. This means also that in the worst case if you have 1.99 bln records, you have nearly 1 bln per partition and if SAP is not delivering a partition design you will end up with PK and 1 bln records per partition. Even worse if the number of records are low but the size of the table is high due to VARBINARY or huge NVARCHAR columns or also a high number of columns/fields. Best examples are CDPOS [huge NVARCHAR columns], BSEG (404 columns), VBRP (282) [high number of fields], BALDAT and SWWCNTP0 [VARBINARY]. Very large tables also result in long delta merge and optimization compression run times, which should be avoided. Additionally, there is limited ability to parallelize filtering in queries. Inserts can be accelerated by multiple partitions as they are performed by column and per partition. An ideal size is 15-30GB. If a delta merge takes several times longer than 300s it can be an indication that is table should be partitioned.

In the end SUM is a perfect tool which should be used, but you still have to check notes and guides. Even if the result is a running HANA including all data, you still have to ask questions about scalability and performance. SUM is the tool for migrating/converting the data and not for operating it optimally. Please take care of this aspects and create milestones / define KPIs in your project to check also this aspects. You should consider a techn. QA instance or health checks for your systems. Ideally before go-live, this saves time for re-partitioning. But even if you encounter problems after going live, you can adjust the design. We already guided several projects and discovered wrong partition design, parameters, missing indexes and many more. We can write a book about all this discoveries - wait we already writing one ;)

How you can do a fast check if your system should be checked (tables > 800.000.000 records and 30GB):

select TABLE_NAME, PART_ID, TO_DECIMAL(MEMORY_SIZE_IN_TOTAL/1024/1024/1024 , 10, 2) MEMORY_SIZE_IN_TOTAL_IN_GB, RECORD_COUNT from M_CS_tables where RECORD_COUNT > '800000000' OR MEMORY_SIZE_IN_TOTAL > '30000000000' order by MEMORY_SIZE_IN_TOTAL desc;

HANA Plan Stability

Wed, 13 Dec 2023 10:30:00 GMT

Abstract SQL plan capturing

The feature plan stability is not a new one, but can help you in case of an revision update/upgrade, if you recognize big performance degradations. But you have to activate this feature at least 1-2 weeks before the maintenance to capture the SQLs and the execution plan. You can compare the plan performance and apply the execution plan with the best performance. You can also use it as always on feature in daily operations. This may be required due to changes in data over time which may cause the query optimizer to propose different execution plans which may have a negative impact on performance and memory consumption of a query. An additional preparation step can be used to apply filters so that only specific queries are captured. In the background execution statistics are recorded so that the performance of the query can be measured and the best execution plan can be selected.

Please don't forget to migrate the abstract SQL plan (ASP) after an upgrade:

ALTER SYSTEM MIGRATE ABSTRACT SQL PLAN;

For some scenarios it is currently not possible to use the abstract plan feature e.g. FDA queries, SqlScript Optimizer, MDX, CDS (partially supported from CE2022/QRC01) or even HEX (SAP is planning HEX as the next generation execution replacing existing legacy engines and only plan to capture HEX based execution plans). For the on prem variant it is only possible to capture complex statements. For HANA Cloud it is also possible to capture simple statement characteristics starting with 2022.QRC02 :

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'system' ) SET ('abstract_sql_plan', 'capture_simple_queries') = 'true' WITH RECONFIGURE;

Keep also in mind that any change on the metadata version information of related object will invalidate the Abstract SQL Plan . This means it cannot be applied if e.g. an alter table command was executed like a repartitioning.

You can easily activate the feature via HANA Cockpit:

Neuer TextHere some parameters which can influence the resources:

S/4HANA Compatibility Packs

Sat, 18 Nov 2023 19:07:11 GMT

This is a subtitle for your new post

The release S/4HANA 2023 will be the last one with CP. This means the coding based on all the help views has to be adjusted after this release. My recommendation is to use this as target release for the next years! But also keep an eye on the other components (more in this blog ).

The announcement about the extension of maintenance for Business Suite solutions has no influence on the end of compatibility pack use rights - they will be terminated after 2025. In the exceptional cases of CS, LE-TRA and PP-PI, the usage right to their respective compatibility pack items (cf. matrix) terminates at the end of 2030.

Details:

Compatibility Scope: What Happens after 2025/2030

https://blogs.sap.com/2022/08/09/compatibility-scope-what-happens-after-2025-2030/

SAP Extends Its Innovation Commitment for SAP S/4HANA, Provides Clarity and Choice on SAP Business Suite 7

https://news.sap.com/2020/02/sap-s4hana-maintenance-2040-clarity-choice-sap-business-suite-7/

The Future of Compatibility Packs in SAP S/4HANA

https://blogs.sap.com/2020/04/15/the-future-of-compatibility-packs-in-sap-s-4hana/

2269324 - Compatibility Scope Matrix for SAP S/4HANA

https://me.sap.com/notes/2269324

Video: https://www.youtube.com/watch?v=muPrV5J7ffM

S/4HANA maintenance

Sat, 18 Nov 2023 18:29:32 GMT

Have an eye on the lifecycles of your landscape

When you are running a S/4HANA system you have to check frequently if all components are still in support. This starts at the hardware level, continues on hypervisor level (more details here ) over OS till the SAP Kernel and the SAP S/4HANA version. The lifecycle of each component is different. So, this means that once a year you have to check this support dilemma. With this little diagram we want to help you to keep your components in sync.

NSE - wrong buffer cache sizing

Tue, 14 Nov 2023 08:58:56 GMT

Urgent recommendation: monitor your buffer cache

If you are not monitoring your buffer cache (=BC) over your landscape when you are using NSE, you can get serious problems. If the BC is too big, you waste memory and the saving rate drops. This is no big deal but should be avoided. The other way around - the BC is too small - will create some trouble. With every merge, optimize compression or CC (=consistency check) all components of the table will be loaded into memory. This means the BC must be big enough. Not big enough for the entire table, but big enough for the biggest column of a table/partition. In all other cases the CCL (ConsistentChangeLock) will be locked for a long time. This can cause issues for savepoints. There are already a lot of issues regarding NSE and such situations (see picture below).

With SAP HANA 2.00.059.05 - 2.00.059.10 the following parameter can be set to improve the situation by avoiding unnecessary buffer allocations and deallocations (issue number 290394):

indexserver.ini -> [buffer_cache_cs] -> async_prealloc_in_chunks_enabled = false

With SAP HANA >= 2.00.059.11 and >= 2.00.064 this parameter is set to false per default (issue numbers 290394, 312021).

Together with our partner solid cloud we are developing monitoring custom check with Avantra to fill the gap of other monitoring solutions.

We try to keep track on them in this blog :

DMOVE2S4 and Homogeneous option for SUM DMO

Wed, 25 Oct 2023 09:01:53 GMT

Spotlight on for Homogeneous option for DMO and DMOVE2S4 aka “DMO move to SAP S/4HANA (on hyperscaler)”

Homogeneous option for DMO (with system move)

DMO used to be heterogeneous (change of DB). Now you can use DMO with system move (also on-prem to target on-prem) to migrate and convert ECC on HANA to S/4 or just update/upgrade S/4 and move it to another location like other DC or other instance in one step.

SAP BW or SAP BW/4HANA systems are not supported
target “SAP ERP on SAP HANA” is not supported
only *HANA to S/4: Only target product SAP S/4HANA is supported
can also be used on prem (e.g. ERP 6.0 on HANA to S/4)
doDMO and doC are supported for homogeneous DMO since SUM 2.0 SP18
no rename of SID in the procedure possible (separate step afterwards needed)
possibility to retain the source after SUM procedure
R3load file mode is used

DMOVE2S4 aka “DMO move to SAP S/4HANA (on hyperscaler)”

The DMOVE2S4 is just to move and convert to the "cloud" in one step. This includes also anyDB source systems and downtime-optimization techniques (doDMO and doC). SAP illustrates it as cloud but, you can also use another DC or another hoster.

Approach is not a SUM option => more a combination of SUM features and options
alternative to “DMO with system move”
plain-DMO
Only target product SAP S/4HANA is supported
Approach works for source systems on anyDB as well as on SAP HANA DB
R3load pipe mode is used, not file mode
prerequiste: Latency < 20 ms between source and target
prerequiste: Bandwidth > 400 MBit/s
SUM runs a latency check
doDMO and doC are supported for homogeneous DMO since SUM 2.0 SP18
no rename of SID in the procedure possible (separate step afterwards needed)
no official possibility to retain the source after SUM procedure
ASCS which is not running with a AAS (=standalone) cannot be moved as standalone within the procedure => it will run within one AAS

=> Due to the fact that the R3load pipeline mode is used this option is faster compared to the "normal" DMO system move approach.

Intel COD / SNC NUMA feature

Thu, 28 Sep 2023 12:19:34 GMT

Possible performance degradation or inconsistencies

--Scroll down for English version

Es gibt ein Intel Feature mit dem Namen SNC bzw. COD. Dabei steht SNC nicht für Secure Network Connection, sondern für Sub-NUMA Clustering . COD steht hier nicht für ein Videospiel, sondern für Cluster-On-Die .

Diese Features werden bei neuerer Hardware eingesetzt und wird ca. seit zwei Jahren teilweise standardmäßig aktiviert (beispielsweise bei HPE ).

Die Features dürfen unter keinen Umständen mit HANA verwendet werden. Neben Performanceproblemen können ebenso Inkonsistenzen auftreten!

Es wird ein phys. NUMA Node in zwei NUMA Nodes aufgeteilt. Bei einem unserer HANA Health Checks wird neben der Datenbank auch von Storage über Hypervisor und OS einiges überprüft. Bei einem Kunden, für den wir einen solchen Health Check durchgeführt haben, ist uns aufgefallen, dass der ESXi bei einem phys. 2 Sockelserver plötzlich 4 NUMA Nodes anzeigt.

Auf ESX Ebene kann dies mit dem folgenden Kommando überprüft werden:

echo "CPU Packages";vsish -e dir /hardware/cpu/packageList;echo "NUMA nodes"; vsish -e dir /hardware/cpuTopology/numa/nodes

Das Feature kann im BIOS deaktiviert werden ( Beispiel HPE ).

#################################################### English #########################################################

There is an Intel feature called SNC or COD. SNC does not stand for Secure Network Connection, but for Sub-NUMA Clustering. COD does not stand for a video game, but for Cluster-On-Die.

These features are used in newer hardware and have been partially activated by default for around two years (for example at HPE).

The features may not be used with HANA under any circumstances. In addition to performance problems, inconsistencies can also occur!

A physical NUMA node is divided into two NUMA nodes. During one of our HANA health checks , not only the database but also the storage, hypervisor and OS are checked. We noticed at one customer that the ESXi suddenly shows 4 NUMA nodes on a physical 2 socket server.

At ESX level, this can be checked with the following command:

echo "CPU Packages";vsish -e dir /hardware/cpu/packageList;echo "NUMA nodes"; vsish -e dir /hardware/cpuTopology/numa/nodes

The feature can be deactivated in the BIOS ( example HPE ).

Source

2470289 - FAQ: SAP HANA Non-Uniform Memory Access (NUMA):

Is it possible to use sub-NUMA clustering for SAP HANA?

On BIOS/UEFI level it is possible to define more than one NUMA node per CPU socket (Intel Cluster-On-Die (COD) / sub-NUMA clustering technology). This scenario isn’t supported and can result in SAP HANA persistence corruptions (SAP Note 2116157).

2116157 - FAQ: SAP HANA Consistency Checks and Corruptions

" Unsupported activation of Intel Cluster-On-Die (COD) / sub-NUMA clustering technology "

Details :

Sub-NUMA Clustering by Frank Denneman

End of maintenance for HANA 2.0 SPS06 in 2023

Mon, 04 Sep 2023 06:56:29 GMT

End of maintenance HANA SPS06

Planen Sie zum Ende 2023 den Upgrade auf HANA 2.0 SPS07, sollten Sie sich aktuell auf SPS06 befinden. Bitte beachten Sie die unterstützten Betriebssysteme und planen Sie den OS Update/Upgrade mit ein!

Sowohl die Parameter, als auch die Änderungen in Features / Engines haben Einfluss auf die Stabilität und Performance.

Wir unterstützen Sie bei der Validierung für ein optimales Ergebnis.

If you plan to upgrade to HANA 2.0 SPS07 at the end of 2023, you should currently be on SPS06. Please note the supported operating systems and plan the OS update/upgrade!

Both the parameters and the changes in features / engines have an impact on stability and performance.

We support you with the validation for an optimal result.

HANA Sequences - the hidden handbrake in the system

Thu, 31 Aug 2023 08:26:28 GMT

Usage of Sequences

Do you use sequences in your SAP HANA systems? This should definitely be checked. If not set up correctly, these can have a major impact on the performance of individual SQL statements. A HANA sequence can be compared with a consecutive number range in ABAP. The sequence generates unique, preceding numbers, which e.g. B. can be used by a HANA trigger or when INSERT into a table. Similar to ABAP, numbers can be buffered. By default, however, the cache is set to 1.

If many operations access the sequence at the same time, there is a waiting situation until the next number is assigned. This problem can be solved by increasing the sequence cache. Note: There may be gaps in the assignment due to the use of the cache, but the numbers are always consecutive.

How do I check whether developers or even third-party vendors are using HANA sequences?

Recognize sequences in statements:

The sequence can be recognized in the statement by the “ .NEXTVAL ” function.

Example with triggers:

The trigger, which in turn uses a sequence, accounts for about 90% of the statement's runtime. Seen here in the context of the child processes.

Kernel Profiler

Statement Collector of the trigger statement

CallStack Not Initialized : This is a generic, unspecific semaphore name used for various semaphores in IBM on Power environments. On Intel they follow the naming convention "<module>.cpp: <function>" instead, e.g. "DeltaIndexManager.cpp: TRexAPI::DeltaIndexManager::MergeAttributeThread::MergeAttributeThread".

The Kernel Profiler can be used to determine exactly what the DB is doing in this status. This also applies to other cases.

3,88s waiting

The HANA sequence accounts for over 90% of this

In the specific customer case, this had the following effect:

Peak times before caching: 160ms per execution

Peak times after caching: 1ms per execution

The daily average is as follows:

HANA Sequences - die verborgene Handbremse im System

Thu, 31 Aug 2023 08:14:57 GMT

Nutzung von Sequences

Verwenden sie in ihren SAP HANA Systemen Sequences? Das sollte unbedingt geprüft werden. Diese können bei nicht korrekter Einrichtung die Performance einzelner SQL-Statements stark beeinflussen. Eine HANA Sequence kann mit einem fortlaufenden Nummernkreis im ABAP verglichen werden. Die Sequence generiert eindeutige, vorlaufende Nummern, die z. B. von einem HANA Trigger oder beim INSERT in eine Tabelle verwendet werden können. Ähnlich wie im ABAP können Nummern gepuffert werden. Im Standard ist der Cache jedoch auf 1 eingestellt.

Greifen gleichzeitig viele Operationen auf die Sequence zu, kommt es zu Wartesituation, bis die nächste Nummer vergeben wird. Durch Erhöhung des Sequence Cache kann dieses Problem gelöst werden. Hinweis: Durch den Einsatz des Caches kann es Lücken in der Vergabe geben, jedoch sind die Nummern immer fortlaufend.

Wie prüfe ich, ob Entwickler oder gar Third-Party Hersteller HANA Sequences benutzen?

Sequence im Statement erkennen:

Im Statement ist die Sequence durch die Funktion “ .NEXTVAL ” zu erkennen.

Beispiel mit Trigger:

Der Trigger, welcher wiederum eine Sequence verwendet, macht circa 90 % der Laufzeit des Statements aus. Hier zu sehen im Kontext der Child Prozesse.

Kernel Profiler

Statement Collector des Trigger Statements

Mittels Kernel Profiler kann ermittelt werden, was genau die DB in diesem Status macht. Das gilt auch für andere Fälle.

3,88s Wartezeit

Davon entfallen über 90% auf die HANA Sequence

Beim konkreten Kundenfall hatte das folgenden Effekt:

Peakzeiten vor Caching: 160ms pro Ausführung

Peakzeiten nach Caching: 1ms pro Ausführung

Im täglichen Durchschnitt sieht der Ergebnis folgendermaßen aus:

HANA performance degradation with SPS5 + SPS6

Tue, 25 Jul 2023 09:07:02 GMT

Follow the flow diagram if you have any HANA FDA performance issues

Please contact us if you face any kind of HANA performance issues.

If your are running HANA SPS5 or SPS06 (>Rev65) with an ABAP stack with one of the affected kernels you have to follow the instructions provided by SAP or contact XLC.

It is important if you use the new kernel wit the fix, you have to regenerate the ABAP loads via SGEN of the impacted code.

If you use the SPS06 workaround, you have to clear the SQL plan cache after implementing the parameter:

ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM' ) SET ('sql', 'prefer_cs_itab_in_subquery_for_param_itab') = 'true' WITH RECONFIGURE COMMENT 'SAP Note 3149562. <ADDITIONAL ACTION: Revert after upgrade to a revision containing the fix>';

ALTER SYSTEM CLEAR SQL PLAN CACHE; A

HANA Workload Management deep dive part III

Tue, 11 Apr 2023 16:16:18 GMT

Insides for SAP HANA Workload Management

Ok, you already read part I and II of the deep dive series of HANA workload management. You are waiting for more insides after you identified some HANA resource bottlenecks to solve them via Workload Classes? Then you are on the right track. In this part III will describe how you can map the workload and prioritize your workloads to unleash the performance for the important tasks.

https://blogs.sap.com/2023/04/11/hana-workload-management-deep-dive-part-iii/

Release HANA 2.0 SPS07

Fri, 31 Mar 2023 16:30:37 GMT

Das geplante Release von SAP HANA 2.0 SPS07 ist geplant für April 2023. Das Release besitzt Long Term Support. Dies bedeutet 5 Jahre Support. Parallel bleibt SPS05 bis Dezember 2025 im Support. Bitte beachten Sie beim Update mögliche Performancebeeinträchtigungen der HANA HEX Engine .

Für folgende Bereiche sind Verbesserungen zu erwarten:

Backup
NSE
Capture&Replay
Workload Management
VS Code based SQL Analyzer
Machine Learning

The planned release of SAP HANA 2.0 SPS07 is planned for April 2023. The release has long-term support. This means 5 years of support. At the same time, SPS05 will remain in support until December 2025. Please take attention to possible performance impact due to the HANA HEX engine .

Improvements can be expected in the following areas:

Backup
NSE
Capture&Replay
Workload Management
VS Code based SQL Analyzer
Machine Learning

Details:

2378962 - SAP HANA 2.0 Revision and Maintenance Strategy

SAP HANA 2.0 Revision Strategy

HANA Workload Management deep dive part II

Tue, 10 Jan 2023 09:03:52 GMT

Insides for SAP HANA Workload Management

Ok, you already read part I of the deep dive series of HANA workload management. You are waiting for more insides after you identified some HANA resource bottlenecks? Then you are on the right track. In this part I will describe how you can get an overview of your systems workload and how to handle it with different methods.

It is important to know the behavior and the load if the system. Every system is used in another way. Means you have to analyze, interpret and understand the workload. You have to know if it was just a one-time occurrence or a frequent behavior.

Most common scenarios:

The system is overloaded and cannot fulfill the request – means the DB can no longer respond
Performance issues for certain queries
System is not using the defined thresholds

https://blogs.sap.com/2023/01/09/hana-workload-management-deep-dive-part-ii/

HANA Workload Management deep dive part I

Mon, 14 Nov 2022 18:15:21 GMT

Insides for SAP HANA Workload Management

We all know that HANA needs a lot of system resources due its in-memory design. When we are not monitoring the prod. systems well the system can get overloaded by too highly parallelized applications, a memory leak or a SQL which was not restrictive enough ending up in a OOM (out of memory) dump. This behavior is nothing special and can + will happen to any system. This is not only the case for user workload. Also system workload like the merge, partitioning process and consistency check can be controlled.

>>There are several automatisms that are triggered by threshold events. Other actions are managed by dynamic workload management or parameters.

How can you manage it?

>> To handle the workload of system correctly you have to understand how HANA manages its resources, how you can identify bottlenecks and how to configure the right parameters. <<

https://blogs.sap.com/2022/09/08/hana-workload-management-deep-dive-part-i/

Details about HANA LOBs

Fri, 24 Jun 2022 14:38:17 GMT

Some insides about the HANA large objects

Ok, large objects aka LOBs (no not Line of Business) are nothing special and well known from other database systems.
LOBs are unstructured data like a picture, a PDF or a message XML content. The shared properties of this kind of data is that they can be quite large.

https://blogs.sap.com/2022/06/22/details-about-hana-lobs/

HANA XSA log4j CVE-2021-44228

Tue, 14 Dec 2021 10:41:07 GMT

Currently the security topic log4j is omnipresent. I want to show in this blog how you can check your HANA XSA systems and implement the mitigation. As well as to check if the settings are correct.

Release HANA 2.0 SPS06

Sun, 28 Nov 2021 17:17:27 GMT

Das geplante Release von SAP HANA 2.0 SPS06 ist geplant für Dezember 2021. Das Release besitzt keinen Long Term Support. Dies bedeutet lediglich 2 Jahre Support. Parallel bleibt SPS05 bis Dezember 2025 im Support. Für folgende Bereiche sind Verbesserungen zu erwarten:

Backup
NSE
HSR
Capture&Replay
Workload Management
Security

The planned release of SAP HANA 2.0 SPS06 is planned for December 2021. The release does not have long term support. This only means 2 years of support. At the same time, SPS05 will remain in support until December 2025.

Improvements can be expected in the following areas:

Backup
NSE
HSR
Capture & Replay
Workload management
Security

Details:

2378962 - SAP HANA 2.0 Revision and Maintenance Strategy

SAP HANA 2.0 Revision Strategy

[HANA] NSE part I – tech. details Q&A

Thu, 04 Nov 2021 07:27:25 GMT

Neuer Titel

SAP NSE was introduced with HANA 2.0 SPS04 and based on a similar approach like data aging. Data aging based on a application level approach which has a side effect if you are using a lot of Z-coding. You have to use special BADI’s to access the correct data. This means you have to adapt your coding if you are using it for Z-tables or using not SAP standard functions for accessing the data in your Z-coding. This was big hurdle to use this feature. But in this blog I don’t want to talk about old stuff, because there are a lot of information already out there in form of blogs (SAP HANA Native Storage Extension: A Native Warm Data Tiering Solution by Robert Waywell [April 16, 2019]; SAP HANA Native Storage Extension(NSE) – Increase HANA Data Capacity With Warm Storage by Jeetendra Kapase [July 22, 2019], NSE: Systematically Measure Memory Savings by Daniel Utvich [September 7, 2021]), documentation, slides and technical guides. This means this blog series will not cover general stuff, but will focus on technical details and limitation which I have already encountered in my projects.

We’ll start with some common questions I get asked when the first workshop takes place:

Does NSE cost additional licenses?

Can I use NSE for BWoH?

Which tables are perfect candidates for NSE?

HANA on VMware - Maintenance

Tue, 06 Apr 2021 18:30:03 GMT

HANA on VMware - Maintenance

https://blogs.sap.com/2021/04/04/hana-on-vmware-maintenance/

HANA – hdbcons first aid hacks

Mon, 01 Feb 2021 15:15:38 GMT

This is a subtitle for your new post

A tool which got more and more power since HANA 2.0 was released is hdbcons. It should only be used by experienced admins and should be tested in non-prod systems, because it can produce system crashes. There are several known issues documented in notes which describe scenarios you should avoid the usage of hdbcons in prod systems.

This blog won’t describe the full functional scope (see the central hdbcons note 2222218). I will show some general use cases which are not well known, but should be kept in mind for scenarios I call ‘HANA first aid’. At the end of the blog you will also get an example script for such a troubleshooting situation.

General stuff about hdbcons
HANA 2.0 SPS04 vs. SPS05 features
Disk / Container / Log Management
Memory / NUMA
HSR
Troubleshooting

https://blogs.sap.com/2021/01/09/hana-hdbcons-first-aid-hacks/

Technical details – HANA licensing

Mon, 01 Feb 2021 15:06:55 GMT

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?

https://blogs.sap.com/2021/01/18/technical-details-hana-licensing

End of support for HANA 1.0 SPS 12 and HANA 2.0 SPS04 in 2021

Sun, 27 Sep 2020 12:32:46 GMT

HANA 1.0 SPS12 + HANA 2.0 SPS4

Planen Sie Anfang 2021 den Upgrade auf HANA 2.0 SPS05. Sowohl die Parameter, als auch die Änderungen in Features / Engines haben Einfluss auf die Stabilität und Performance. Wir unterstützen Sie bei der Validierung für ein optimales Ergebnis.

Plan to upgrade to HANA 2.0 SPS05 in early 2021. Both the parameters and the changes in features / engines have an impact on stability and performance. We support you with the validation for an optimal result.

End of support in 2020 for HANA 2.0 SPS03

Sat, 06 Jun 2020 08:49:09 GMT

Bitte beachten Sie das Supportende von SPS03 im Juli 2020

Im Juli 2020 endet der Support für HANA 2 SPS03 . Dies bedeutet, dass nach diesem Zeitpunkt keine neuen Maintenance Revisions mehr für SPS03 (aktuell letzte Revision 37.06) von SAP freigegeben werden. Daher sollten alle Kunden sofort auf die neueste HANA 2.0 SPS04 Revision upgraden.
SPS05 wird zwar ebenso in diesem Zeitraum freigegeben, sollte aber erst nach etwas "Reifezeit" konsumiert werden. Dieses Release wird anders als bisherige nicht 2 Jahre Support, sondern 5 Jahre "long Term" Support erhalten. SPS06 wird dann wieder voraussichtlich 2 Jahre Support erhalten.
Jeder Upgrade birgt Gefahren hinsichtlich Stabilität und Performance, daher sollte dies mit der nötigen Sorgfalt getestet werden. Wir unterstützen Sie gerne mit unserer Erfahrung bei Upgrades oder anstehenden Herausforderungen hinsichtlich Performance oder Stabilität.

Support for HANA 2 SPS03 will end in July 2020 . This means that after this point in time, no new maintenance revisions for SPS03 (currently last revision 37.06) will be released by SAP. Therefore, all customers should immediately upgrade to the latest HANA 2.0 SPS04 revision.
SPS05 will also be released during this period, but should only be consumed after a bit of "maturing time" . Unlike previous releases, this release will not receive 2 years of support, but 5 years of "long term" support . SPS06 will then probably receive 2 years of support again.
Every upgrade is dangerous in terms of stability and performance, so this should be tested with the necessary care. We would be happy to support you with our experience with upgrades or upcoming challenges in terms of performance or stability.

Details:

2378962 - SAP HANA 2.0 Revision and Maintenance Strategy

SAP HANA 2.0 Revision Strategy

End of Support HANA 2.0 SPS06

HANA secure network communication

Tue, 31 Mar 2020 18:17:29 GMT

part I

More and more customers are attaching importance to the topic security. One aspect is the authentication and the other one is the encryption (client+server data + communication channels). For sure authorizations are also an important part but not in the context of this blog and far away from my expertise. As you may read between the lines – I’m not a fan of authorization concepts. These are all pretty broad topic and for now we will focus on the x.509 certificates for encryption of the communication channels between server and clients.

There are some documentations available by SAP, but some of them are outdated or not matching the customer environments/needs or not all-embracing.

Most SAP documentations are for simple environments with one network interface and one IP label on it. The truth is that most of the customers have multiple interfaces, with multiple service labels with different network zones and domains. Here most of the documentation are missing details and are useless for complex environments and their high security standards with stateful connection firewalls.

https://blogs.sap.com/2020/03/29/hana-secure-network-communication-part-i/

Best Experience: Creation of HANA Indexes part II

Wed, 04 Mar 2020 20:57:34 GMT

Part II

https://blogs.sap.com/2020/03/01/best-experience-creation-of-hana-indexes-part-ii/

Best Experience: Creation of HANA Indexes part I

Wed, 04 Mar 2020 20:16:39 GMT

How and when we should create indexes on HANA

https://blogs.sap.com/2020/02/29/best-experience-creation-of-hana-indexes-part-i/

SAP - Linux Staging

Fri, 10 Jan 2020 11:37:58 GMT

Linux Staging SAP / HANA

https://blogs.sap.com/2020/01/05/hana-linux-staging/

HANA Savepoint Details

Sat, 28 Dec 2019 19:12:00 GMT

Savepoint Details

https://blogs.sap.com/2019/12/26/hana-savepoint-details/

Linux - Memory Management

Sat, 28 Dec 2019 19:05:49 GMT

Memory Management Details

https://blogs.sap.com/2019/12/28/linux-memory-management-insights/

Unleash the performance of your VM

Mon, 11 Mar 2019 19:34:23 GMT

How to unleash the real performance of your VM with attention to NUMA

https://blogs.sap.com/2019/03/10/hana-unleash-the-performance-of-your-vm/

HANA 1.0 upgrade scenarios

Sun, 20 Jan 2019 18:47:20 GMT

HANA 1.0 ==> HANA 2.0

Sie planen einen Upgrade Ihres SAP HANA 1.0 Systems auf HANA 2.0 und würden gerne den Aufwand, sowie die möglichen Szenarien inkl. System Replication und die damit verbunden Fallstricke erfahren?

You plan to upgrade your SAP HANA from 1.0 to 2.0 and want to know the supported scenarios incl. System Replication? There are some pitfalls which you have to take care of. Check out this blog (8min read)

https://blogs.sap.com/2019/01/20/hana-1.0-upgrade-scenarios/

New lifecycle: SLES12 + SLES15

Fri, 11 Jan 2019 17:51:58 GMT

Support Extension

Seit Anfang diesen Jahres gibt SUSE 2 Jahre länger Support pro SP. Dies gilt auch für bestehende Subscriptions sowohl SLES12 als auch SLES15!
Damit belaufen sich die Lebenszyklen bei dem normalen SLES (Vanilla) auf 3 Jahre und bei SLES4SAP auf ingesamt 4,5 Jahre!

Since the beginning of this year, SUSE has been giving 2 years more support per SP. This also applies to existing subscriptions of both SLES12 and SLES15! Thus, the life cycles for the normal SLES (vanilla) are 3 years and for SLES4SAP a total of 4.5 years!

Supportende HANA 2.0 SPS02

Tue, 08 Jan 2019 13:14:14 GMT

Bitte beachten Sie das Supportende von SPS02

Ende März / Anfang April 2019 endet der Support für HANA 2 SPS02. Dies bedeutet, dass nach diesem Zeitpunkt keine neuen Maintenance Revisions mehr für SPS02 (aktuell letzte Revision 24.07) von SAP freigegeben werden. Daher sollten alle Kunden sofort auf die neueste HANA 2.0 SPS03 Revision upgraden.

End of March / beginning of April 2019 the maintenance for HANA 2 SPS02 ends. This means that after this time no new maintenance revisions for SPS02 (currently latest revision 24.07) will be released by SAP. Therefore, all customers should immediately upgrade to the latest HANA 2.0 SPS03 revision.

Details:

2378962 - SAP HANA 2.0 Revision and Maintenance Strategy

SAP HANA 2.0 Revision Strategy

SAP HANA Memory Deepdive

Sat, 06 Oct 2018 10:34:47 GMT

Details zur HANA Memory Nutzung

https://blogs.sap.com/2017/01/03/hana-memory-usage-details-part-1-shared-memory/

https://blogs.sap.com/2017/01/03/hana-memory-usage-details-part-2-heap-memory/

XLC: SAP HANA News

FAQ: SUSE Hypervisor for SAP (KVM)

KVM as alternative with low TCO

1.What KVM stands for?

2. Is SUSE Hypervisor for SAP certified for SAP HANA?

3. Which hardware can be used for SUSE Hypervisor for SAP?

4. Which subscription is needed?

5. Which sizing rules I have to consider?

6. Which are the most popular limitations for SUSE KVM (SUSE Hypervisor for SAP)?

7. What are the main differences between VMware and SUSE Hypervisor for SAP?

8. How you can migrate your workload?

9. What migration scenarios exist?

10. Which features besides pure virtualization are provided by SUSE Hypervisor for SAP?

11. Which migration capabilities are offered?

12. How snapshots can be used with KVM?

13. Which tools are provided by SUSE for administration / monitoring?

Virtualization console tools

Virtualization GUI tools

Monitoring with virt-top

Sources

Data Tiering case study part II: Inverted Individual Indexes

Inv Idv Idx - Inverted Individual Indexes - warm data

Why Inv Idv Idx are relevant for data tiering purposes?

What influence can such indexes have on the sizing?

Why is it not sensible to convert every unique index?

How much memory can be saved with Inv Idv Idx?

For which systems the Inverted Individual Indexes can be used?

Summary

Data Tiering case study part I: NSE

NSE - Native Storage extension - warm data

Customer case

Phase 1

Phase 2

Phase 3

NSE wording definitions

Results and savings

Summary

Performance issues with THP on multi-NUMA node systems

THP issues with kernels before February 2026

Temporary workaround for systems not yet updated to the fixed kernel:

Manual (applied live, no reboot, no HA cluster or HANA restart required):

Why NUMA node 0 is often affected first:

Kernel versions

Sources:

SAP HANA & Transparent Huge Pages (THP

Switched to madvise in 2025 - now this?

Ongoing HANA HEX performance issues with SPS07+SPS08

The HEX engine strikes back - again

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

Source: SAP HANA Performance Guide for Developers

HANA NSE - technical details Q&A

HANA NSE - technical details

Source: SAP Note 2973243

Source: 2220627 - FAQ: SAP HANA LOBs

Source: SAP documentation

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

Golden Rules for HANA Partitioning

Rule of thumbs

HASH

RANGE

Multilevel partitioning

Designing Partitions

From Complexity to Clarity: Optimizing the R+R List for SAP Cloud ERP

Check out how to optimize the R+R List for SAP Cloud ERP

Conclusion / Summary

SAP HANA data statistics for the optimizer

Popular misconcept: HANA needs no statistics

HANA OS maintenance

This is a subtitle for your new post

SAP HANA Optimizer - the heart of the performance

The HANA Optimizer is one of the core components of the HANA database. It determines how SQL is executed.

Is the effort for NSE worth it?

Is NSE worth the effort or is the better question: Do you know your cost per GB of RAM?

How much memory saving you can expect?

Buchtipp: SAP HANA Deepdive: Optimierung und Stabilität im Betrieb

Unser erstes Buch ist nun verfügbar

SAP ERP Extended Maintenance until 2033 - but with conditions

More time to switch from BSoH to S/4HANA

Smart SAP HANA Optimization: Applying NSE for Better Efficiency

Optimize your HANA with NSE

Monitoring with `virt-top`

The latest features of HANA 2.0 updated

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

End of maintenance HANA SPS05 updated

Unforeseen cloud cost increases

SUM tooling: what is currently not covered for big tables

© 2023 SAP SE or an SAP affiliate company. All rights reserved.