Performance Tuning in SAP HANA:

An Independent Expert’s Guide

Kurt Hollis
Deloitte

Produced by Wellesley Information Services,

LLC, publisher of SAPinsider. © 2015 Wellesley
Information Services. All rights reserved.
In This Session

• Quick overview of HANA

• Architecture, sizing, scale-out key areas
• Review performance of HANA
• Common performance issues
• Tools for monitoring HANA performance
• Troubleshooting and resolving performance issues
• Performance checklists
• DEMO of performance monitoring and issues

1
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

2
Quick Overview of SAP HANA

• HANA is a solution for in-memory computing

• Acronym HANA means “High-Performance Analytic Appliance”
(source: SAP training course HA200)
• SAP HANA is a flexible, data source-agnostic appliance that
enables customers to analyze large volumes of data in real time
• HANA DB takes advantage of the low cost of main memory (RAM),
data processing abilities of multi-core processors, and the fast
data access of solid-state drives relative to traditional hard drives
to deliver better performance of analytical and transactional
applications
• It offers a multi-engine query processing environment which
allows it to support both relational data (with both row- and
column-oriented physical representations in a hybrid engine) as
well as graph and text processing for semi and unstructured data
management within the same system
Source: http://en.wikipedia.org/wiki/SAP_HANA 3
Quick Overview of SAP HANA (cont.)
• HANA DB is comprised of services.
Index server is the main service,
containing actual data and engines
for processing the data:
 Index Server
 Name Server
 Preprocessor
 Compile Server
 XS Server
 Built-in Web Server
• Memory is managed by the Index
Server
• System includes Storage for
Persistent Store (Data and Logs)
4
HANA In-Memory Database

• The database runs completely in-memory. This makes the

memory a very important performance consideration.
• It is critical for the HANA system to carefully manage and track
the consumption of memory. The HANA system pre-allocates and
manages its own memory pool.
• Memory sizing is key to
avoiding peak used memory
limit
• Keep track of the peak value
as your high water mark
• More important to understand
the behavior of used memory
over time and under peak loads
5
In-Memory Data and Persistent Storage

• The SAP HANA database holds the bulk of its data in-memory for
maximum performance, but still uses persistent storage to
provide a fallback in case of failure
• During normal database operation, data is automatically saved
from memory to disk at regular save points
• Additionally, all data changes are captured in the redo log. With
each committed database transaction, the redo log is saved from
memory to disk.
• If a failure occurs (e.g., a power outage),
the database can be restarted in the same
way as any disk-based database, and
returned to its last consistent state by
replaying the redo log since the last
save point

Source: SAP 6
Column Tables

• Column tables are loaded into memory column by column upon

use; this is called lazy loading
• Columns that are never used will not be loaded into memory,
saving waste of memory
• As HANA approaches limits of allocatable memory, it will try to
unload least recent table columns and cache to free up memory
• To load a table using SQL: LOAD table_name ALL

7
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

8
Architecture Discussion
• Key points of the HANA architecture:
 In-Memory Database  The entire database is running in memory
 Combines OLTP, OLAP, and HW Acceleration, eliminating
unnecessary complexity and latency
 Strict hardware specifications for performance design reasons 
16GB of memory per CPU core, fixed ratio of disk data storage to 4
times RAM, log storage = 1 times RAM
 Two types of Relational Stores in HANA  Row Store (common in
previous traditional databases) and Column Store (is what HANA
uses primarily)
 Persistency Layer  In-memory is volatile, so persistency layer
makes sure all data in memory is also stored on hard drive storage
 Not only is data stored in HANA memory, but what makes it faster
is that the calculations are made in the database, and only the
results transfer to the application layer
9
Architecture

Source: SAP

10
HANA Scenarios
• HANA started as a standalone data mart, then added apps
• Content was added using Reporting and Analytics with SAP BusinessObjects
• HANA on Cloud
• BW on HANA
• Business Suite on HANA

Source: SAP 11
HANA Deployment Options

• Four scenarios exist

• Virtualization is okay for Production

SAP Note 1666670 – Multiple SAP HANA DBs on one appliance Source: SAP
SAP Note 1661202 – Support for multiple applications on SAP HANA
SAP Note 1826100 – Multiple applications SAP Business Suite powered by SAP HANA
SAP Note 1681092 – BW on SAP HANA – landscape deployment planning
SAP Note 1788665 – SAP HANA running on VMware vSphere VMs 12
Sizing HANA
• Important SAP Notes about sizing HANA:
 1514966 – Sizing HANA
 1704499 – System Measurement for License Audit
 1637145 – Sizing BW on HANA
• Static + Dynamic RAM requirements determine sizing. To do this, determine
uncompressed data volume to be loaded, then apply compression factor, then
multiply result by two.
• Only 50% of the total RAM should be used for the in-memory database. The
other 50% is needed for temporary objects (for example, intermediate results),
the operating system, and application code.
• Disk size for the persistence layer is equal to 4 times RAM
• Disk size for the log files equals 1 times RAM
• CPU equals 300 SAPS per active user. Never to exceed 65% of CPU server load.
• BW on HANA has a quick sizing tool available at:
https://service.sap.com/quicksizing *
• HANA is available in incremental sizes: XS, S, M, L
* Requires login credentials to the SAP Service Marketplace 13
HANA on VMware
• SAP and VMware announced support for deploying SAP HANA (SPS05 or
greater) virtualized using VMware vSphere 5.1 and recently vSphere 5.5
• Single-node deployments only running virtualized with VMware vSphere on
certified hardware or tailored DC and within the current limits of VMware
vSphere of 64 virtual CPUs and 1 TB of memory for use within non-
production scenarios (Up to 1TB memory, 768GB usable)
• Multiple virtual machines can be deployed on a single SAP HANA appliance
• Each SAP HANA instance deployed on a virtual machine is recommended to
be sized the same as SAP HANA deployed on “bare metal” SAP HANA
appliances
• For single node (non-clustered) SAP HANA deployments
• Alternative with SAP HANA tailored data center integration approach:
 SAP HANA installation was done by an SAP-certified engineer
 SAP HANA tailored data center integration configuration has been verified
with SAP HANA hardware verification tool; respective hardware
requirements do apply
 No over-provisioning of RAM or CPU is allowed for SAP HANA
14
Improvements to HANA SPS Releases

• SAP is now providing two SP stack revisions per year for SAP
HANA systems
• Introduction of the Verified Revision, which is tested in a
Productive system

Source: SAP
15
Scale-Out Architecture

• HANA Scale out uses multiple

servers, with CPU and memory
sharing same disks
• Scale out works very well with BW
systems to distribute large tables
across multiple HANA nodes
• Table landscape distribution is set
up to pre-determine which table
types are on master node and
slave/worker nodes
• It is possible to move tables
between nodes
• Load rebalancing is possible Source: SAP

16
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

17
Performance Overview

• STEP 1: Monitor for Performance Issues – To analyze data at

incredible speeds on HANA with scans of 1 billion rows per
second per core and join performance of 10 million rows per
second is only possible if the system is monitored and
performance issues are kept to a minimum
• STEP 2: Observing the General Symptoms – Such as system poor
performance, high memory usage, and paging or column store
unloads. Narrow down the possible causes as a first step in
analyzing the issue.
• STEP 3: Keep HANA System Updated – The performance analysis
capabilities significantly improve with newer SAP HANA patch
levels

18
Performance Consideration Areas

• Host resources (CPU, memory, disk)

• Size and growth of data structures
• Transactional problems
• SQL statement performance
• Security, authorization, and licensing
• Configuration
• Out-of-Memory (OOM) Situations
 Check trace files and error messages indicating an Out-of-
Memory situation
 OOM – Analyzing the root cause

• Paging on Operating System Level

 Check if paging is reported on operating system level
19
Performance Consideration Areas (cont.)

• Memory Problems – analyzing the root cause

• Column Store Unloads
 Many unloads in the column store

 Alerts indicate issues with high memory usage: Column store

unloads (Alert 55)
• Memory Problems for information on analyzing the root cause
• Permanently Slow System Issues

20
Areas of HANA Performance Problems and Analysis
• Memory Problems
• CPU-Related Root Causes and Solutions
• Disk-Related Root Causes and Solutions
• Delta Merge
• Security-Related Issues
• Transactional Problems
• Statement Performance Analysis
• Application Performance Analysis
• Tools and Tracing
• System Performance Analysis
• SQL Statement Analysis
• Query Plan Analysis
• Advanced Analysis
• Additional Analysis Tools for Support
21
Host Resources
• Typical reasons for a slow system are resource shortages of CPU,
memory, disk I/O, and, for distributed systems, network performance
 Common HANA Performance Issues
 Disk I/O
 Network I/O
• SQL statements dispatched by other users, which can block a lot of
resources. In the case of memory, this can lead to unloads of tables
when a table has to be reloaded into memory, which affects future
SQL statements
• Another reason for poor performance, which in many cases cannot
be detected by the SAP HANA instance itself, are other processes
running on the same host that are not related to SAP HANA. You can
use the operating system tools to check for such processes. Note
that SAP only supports production systems running on dedicated
hardware.
22
Non-HANA Performance Issues

• Network Latency between HANA and Application Servers

 Place on same subnet and use 10GB networks only
• Kernel versions of SAP systems too low; mandatory patch level
requirements and actions needed to make sure that SAP kernel
7.4x is running optimally and that performance issues are linked
to the 7.4x enqueue work process (See SAP Note 2031037 and
SAP Note 2013043)
• To determine if a detailed investigation on SAP HANA side is
useful:
 First, identify the portion of time spent on SAP HANA server
side
 Then, the application side (e.g., within ABAP)
 Finally, the network between SAP HANA and the application
 To determine if the SAP HANA server side is responsible
23
Memory Performance

• Watch for Out-of-Memory (OOM) errors in trace files

• Too many column unloads occurring indicate high memory
consumption issues
• SQL checks for (1) Historic top memory consuming areas and (2)
Overview of current memory allocation by tables
• Memory leak is a memory area (typically, a heap allocator) that
grows over time without any apparent reason
• Some heap areas can be larger than necessary without being a
memory leak
• Expensive SQL statements processing a high amount of data or
using inefficient processing strategies can be responsible for
increased memory requirements
• Memory requirements – it is possible that the available memory is
not sufficient for the current utilization of the system
24
Memory Performance (cont.)
• High memory consumption can be caused by problems with
transactions caused by wait situations
 Long-running or unclosed cursors
 Blocked transactions
 Hanging threads
• If the fragmentation of row store tables in the shared memory segments
of index server processes reaches 30% and the allocated memory size is
greater than 10GB, a table redistribution operation is needed
• LOB (Large Object) columns can be responsible for significant memory
allocation in the row store and column store if they are defined as
memory LOBs
• Delta store can allocate a significant portion of the column store
memory
• Perform memory trace and leak analysis using SQL command 
hdbcons 'mm flag / -rs as'
25
Memory Performance (cont.)

• Things you can do to help memory consumption:

 Keep system clean of too much memory consumption

 Ensure regular Basis table house-keeping is set up for

technical, administration, and communication tables so that
they don’t consume unnecessary memory
 Perform archiving or use near line storage solutions

 Check for indexes with high memory requirements. May be able

to drop some indexes.
 Secondary indexes that were created in order to optimize the
performance of non-HANA databases
 BW: If DSOs are changed from “standard” to “write-
optimized,” a primary index is no longer required
26
CPU-Related Performance

• A constantly high CPU consumption will lead to a considerably

slower system, as no more requests can be processed
• From an end-user perspective, the application behaves slowly, is
unresponsive, or can even seem to hang
• SAP HANA is optimized to consume all memory and CPU
available. HANA system will parallelize queries as much as
possible in order to provide optimal performance.
• If CPU usage is near 100% for a query execution, it does not
always mean there is an issue. It also does not automatically
indicate a performance issue.
• Thread Monitor shows the CPU time of each thread running in
microseconds. A high CPU time of related threads is an indicator
that an operation is causing the increased CPU consumption.
27
Disk Performance

• Low Disk Space issue is usually reported whenever one of the

disk volumes used for data, log, backup, or trace files reaches a
critical size. Alerts are sent out.
• Not possible to write to one of the disk volumes used for data, log,
backup, or trace files:
 File system full

 File system quota is exceeded (GPFS file systems)

 File system runs out of inodes

• When analyzing I/O, the focus is on throughput and latency

• During save point write operations, a global database lock occurs;
this is usually for a short period of time, however, poor I/O
performance can extend it to a length that causes a considerable
performance impact
28
About Delta Merge

• The Column Store uses efficient compression algorithms to keep

relevant application data in-memory
• Write operations on the compressed data are costly, as they
require reorganizing the storage structure and recalculating the
compression
• Therefore, write operations in Column Store do not directly modify
the compressed data structure in the so called main storage
• Instead, all changes are, at first, written into a separate data
structure called the delta storage, and at a later point in time,
synchronized with the main storage. This synchronization
operation is called delta merge.

29
Delta Storage and Merge Operations

• Write operations write to

Delta Storage
• Later the Delta Storage is
Merged to the Main Storage
• See below the steps for
Before, During, and After
Merge

Source: SAP 30
Delta Merge Issues

• Performance issues may occur if the amount of data in the delta

storage is large, because read times from delta storage are
considerably slower than reads from main storage
• Merge operations on a large data volume may cause bottleneck
situations. The data to be merged is held twice in-memory during
the merge operation.
• The following alerts indicate an issue with delta merges:
 Delta merge (mergedog) configuration

 Record count of delta storage of Column Store tables

 Size of delta storage of Column Store tables

31
SQL Statements Performance Issues
• Slow Individual SQL Statements
 Blocked transactions (Threads)
 Delta Merge operation (based on long runtimes and thresholds)
• Increasingly Long Runtime
• Slow individual SQL Statements or increasingly long runtimes Issues
with the performance of a particular statement can be caused by a
number of very different root causes
• In principle, a statement can trigger all the resource problems that
also lead to an overall slowdown of the system, so most of the
previous information also applies to statement performance. In
addition, statement performance can suffer from transactional
problems, that is, blocked transactions.
• Blocked transactions can be checked in the Threads tab
• A transactionally blocked thread is indicated by a warning icon ( ) in
the Status column
32
Transaction Performance Issues

• If the runtime of a statement increases steadily over time, there

could be an issue with the delta merge operation
• Alerts should be issued for most problems occurring with the
delta merge, but since they depend on configurable thresholds,
this is not always the case
• For troubleshooting, proceed with Delta Merge
• If you have none of the above problems, but the statement is still
too slow, a detailed Statement Performance Analysis might reveal
ways to optimize the statement
• However, some queries are inherently complex and require a lot
of computational resources and time
• Transactional lock waits – entire execution time is caused by lock
wait time, so transactional locks (i.e., record or object locks) are
responsible for the long runtime
33
Security Issues with Performance
• Security issues cause major issues which become quickly evident
• License – after 90 days the temporary license expires leading to system
lockdown
• If memory exceeds the licensed amount, use “select * from m_license”
to see the details
• The system view EFFECTIVE_PRIVILEGES is useful for checking the
privileges of a specific user. It includes information about all privileges
granted to a specific user (both directly and indirectly through roles), as
well as how the privileges were obtained (GRANTOR and
GRANTOR_TYPE column).
 Select * from effective_privileges where user_name = “KHOLLIS1”
• If the error “Insufficient privilege: Not authorized” occurs during
statement execution, you need to find out which privileges the user is
missing and then grant them to the user
• A user receives the error “User is locked” after too many failed log-on
attempts
34
Recommendations

• Advantage to have most recent SAP HANA patch level in place.

Regular implementation on a 3 to 12 month basis (SAP Note
2115815).
• Recommended to activate the expensive statement trace
permanently (refer to SAP Note 1982207)
 Set trace to reasonably high threshold of at least 1,000,000
microseconds
 Provides a lot of useful information (CPU and memory
consumption, exact timing of individual executions) and results
in limited overhead

35
Recommendations (cont.)

• As of revision 74, it is recommended to switch to the embedded

statistics server (SAP Notes 1917938 and 2092033)
• This change allows you to store important thread sample
information for longer times in
HOST_SERVICE_THREAD_SAMPLES and includes historic
information (set retention to 42 days)
• Be aware that this change increases the memory requirements of
the statistics server

36
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

37
HANA Studio — Administration Console
• Daily checks always include the Overview Screen in the Administration
Console Perspective
• Check All Services Started, Alerts and Messages, the Memory, CPU, and the
Disk Usage
Choose Overview to view the overall status, memory

Alerts

Memory Usage

Choose the system

38
Using the Administration Console for Memory

• Memory is the main resource of the HANA database (memory

pool) and is managed by its own memory manager
• Monitoring views and memory indicators are used to understand
HANA memory usage
• Indicators include “used memory” and “peak used memory”
• External indicators can be misleading, such as the size of memory
at the host level

Source: SAP 39
Using the Administration Console for Memory (cont.)

Source: SAP 40
HANA Monitoring Dashboard

• This runs outside of the HANA Studio

41
New Memory Overview (Since SP07)

• Launched from the HANA Studio

• One of two new monitoring views
• Requires new security role added
“sap.hana.admin.roles::Monitoring”

42
New Resource Utilization Views

• Second of the two new views from the HANA Studio (SP07
onwards)
• Select from the column’s CPU, Memory, Disk to see the graph
values over time

43
HANA Studio — Administration Console —
Performance
• Performance tab is important to see the activities on the database
and perform system analysis
• Check the active threads, sessions, blocked transactions, SQL
plan cache, expensive statements, job progress, and the load in
graphical views

44
HANA Studio — Administration Console — System
Information and Diagnosis
• System Information and Diagnosis Files tabs provide quick and easy access to
common queries about the system and to the logs and traces. Traces are set up
in the Trace Configuration tab.

45
DBA Cockpit
• In the ABAP system  transaction DBACOCKPIT, very similar to the HANA
Studio
• Used for Administration Tasks  Scheduling backups, some configuration
changes
• Performing Monitoring Tasks  Detailed views of Services, Volumes,
Performance
• Alerting  Critical monitoring allows for alert generation automatically (uses
CCMS)
• Tracing – Setting trace levels and displaying trace files

46
Performance Load

• The Blocked Transactions graph shows how many blocked

transactions currently exist and existed in the past
• Also used extensively for overall performance load

47
Session Monitor

• Monitor all sessions in the landscape

• Active/inactive sessions and their relation to applications
• Whether a session is blocked and, if so, which session is
blocking it
• The number of transactions that are blocked by a blocking
session
• Statistics, like average query runtime and the number of DML and
DDL statements in a session

48
Blocked Transactions

• Blocked transactions, or transactionally blocked threads, can

impact application responsiveness
• Transactions that are unable to be processed further because
they need to acquire transactional locks (record or table locks)
that are currently held by another transaction
• Transactions can also be blocked waiting for other resources,
such as network or disk (database or metadata locks)

49
Threads

• Monitor all running threads in the system

• See how long a thread is running or if a thread is blocked for an
inexplicable length of time

50
SQL Plan Cache

• The SQL plan cache is a valuable tool for understanding and

analyzing SQL processing
• Every SQL statement is compiled to a plan before execution
• Plans can be reused the next time the same statement is
executed, instead of compiling a new plan every time
• This view shows the statistics information for the SQL Plan Cache

51
Expensive Statements Trace

• In order to identify expensive statements causing high resource

consumption, turn on the Expensive Statement trace and specify
a reasonable runtime
• The expensive statements trace allows you to identify which SQL
statements require a significant amount of time and resources

52
Live Demonstration of HANA Performance
Monitoring
• Next is a Live Demonstration of some common performance
analysis functions:
 HANA version 8.0 or higher is used for this demo

 Using HANA Studio

53
Other Administration Tasks

• Take time to become familiar with the configuration parameter

settings and validate that the settings are optimal for your
environment
• Monitoring the memory usage is important. Memory is a
fundamental resource of the database and understanding how the
database requests, uses, and manages this resource is crucial.
• Monitor the replication and extractors from other systems
• SLT monitoring using transaction LTR in the SLT ABAP system
• Verify the connections are working for the SAP Data Services and
SAP BusinessObjects tools. Verify the services are running on
these tools.
• Create a good detailed landscape diagram to assist in
troubleshooting connectivity issues
54
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

55
Performance Checks To-Do
Check Item Description, Impacts to Performance
HANA Patch Level Patches include additional performance optimizations and bug fixes, latest HANA
revision is recommended
Parameter Settings Use HANA Configuration Parameters with setting
ONLY_RECOMMENDATION_DEVIATIONS = “X” to check recommended settings (See
SAP Note 1969700)
Network Check Verify Network Bandwidth and Latency is correct (See SAP Note 1100926)

HANA HW configuration Perform all recommendations for checking the HANA system configuration (See SAP
Note 2000003)
ABAP Parameter Verify HANA-related profile parameters are set to defaults, such as rsdb/max blocking
Settings factor (See SAP Note 1987132)
I/O Analysis Slow I/O can impact startup times, save points, commits, or reloads (See SAP Note
1999930)
SQL Statement Check for expensive SQL statements and optimize them from SAP HANA or application
Optimization perspective (See SAP Note 2000002)
Lock Analysis Check Check for lock waits and optimize them from SAP HANA or application perspective (See
SAP Note 1999998)
Activated Traces Activated traces can have an impact on performance, so you should only activate as few
traces as possible. The activation and modification state of some (but not of all) traces
can be checked using SQL (See SAP Note 1969700).
56
HANA Performance Checks
• Check how many threads are running, what are they working on, and is
any of the threads are blocked
• Check if sessions are blocking current transactions
• Check if any operations are running for a significantly long time and
consuming a lot of resources
• Compare different hosts in terms of performance
• Check for blocked transactions or transaction blocked threads, since
these can impact application responsiveness
• Check active/inactive sessions and their relation to applications
• Check statistics, like average query runtime
• Check for long running jobs that are running for an excessively long
time and consuming a considerable amount of resources
• Check load monitoring graphical display
• Analyze SQL traces, expensive statements, and SQL plan cache
• Run the HANA Mini Checks (see SAP Note 1969700)
57
Troubleshooting — Log Full Situations
• Avoiding LOG FULL (file system full) situations
 When the log is backed up, the backed up log segments remain on disk until they
have been released automatically after a save point
 After the log has released, the oldest unused log segment can be overwritten with
new log entries
 If there are no unused log segments, new log segments are created
 If the disk becomes full and no more log segments can be created, a log full
situation arises
 When the log is full, no more logging is possible until the log backup has
completed
 Solution  Automatic log backup prevents log full situations from arising
• Avoid log backup area becoming full
 Regularly archive old log backups to a different location using operating system
commands
 Monitor disk space that is used for diagnosis files (Diagnosis Files tab)
 Use SAP HANA Studio to delete diagnosis files that are no longer needed
• Caution: Do not delete log segments on the operating system level, as the log area
will become unusable and the database may stop working
58
Alerts

• Actively monitor the status of the system, the services, and the
consumption of the resources it uses with alerts. Alert tab in the
Admin perspective in the HANA Studio tool.
• Alerts for critical situations:
 Disk is becoming full
 CPU usage is reaching a critical level
 Memory usage
 Services inactive or restarted
• The statistics server is the main component of the monitoring
infrastructure and collects information about status, performance,
and resource usage from all components of the database
• The statistics server issues an alert based on the priority level of
the alert (example – low priority alert for 90% disk space used and
critical alert for 98% used)
59
Troubleshooting — HANA Database Issues

• Using the HANA Studio:

 Check log and trace files for errors (Diagnosis Files tab)

 Turn on and configure several traces (Trace Configuration tab)

 May need to open SAP OSS connection for assistance and send
logs to SAP using download files (uses zip format)
 Crash dumps may be collected and analyzed
Note: Monitor disk space that is used for diagnosis files and delete files that are no longer needed located in 
/usr/sap/<SID>/HDB<instance>/<host>/trace

60
Analyze Logs, Traces, and Performance Using
HANA Studio
1. Check the System Information – double-click each task to execute
the SQL command and display the result
2. Check the Diagnosis files – double-click each log file to see the
content
3. Activation and Deactivation of traces is done from the Trace tab
on the Admin Perspective. Click the Edit button next to each trace
to see the details. Turn on traces when encountering problems
with the HANA system.
4. Monitor disk space that is used for diagnosis files
5. Monitor performance using the HANA Studio and DBA Cockpit

61
Commit Operations Optimization
• During COMMITs, the changes of the transaction are persisted to
disk and made visible for other transactions. Certain factors can
influence the time of COMMIT operations, such as Disk I/O and
Synchronous system replication mode.
• Disk I/O writes performance to logs  During COMMITs, the
change information is written to the log files. If writing data is slow,
the COMMIT times can increase (See SAP Note 1999930).
• Synchronous system replication mode for DR (Disaster Recovery)
systems  If a synchronous system replication mode is activated,
changes are propagated to the replication side during a COMMIT,
and the local session has to wait for an acknowledgement. Check is
switching to a less critical system replication mode (e.g., SYNC 
SYNCMEM or SYNCMEM  ASYNC) to improve the performance.
• Analyze if there are unnecessary replication delays due to limited
network bandwidth or high latency times
62
What We’ll Cover

• Quick Overview of HANA

• HANA Architecture, Sizing, Scale-Out
• HANA Performance
• HANA Performance Tools, Monitoring, Logs
• Performance Checks and Troubleshooting
• Wrap-up

63
Where to Find More Information

• Guides and Resources

 Most Important Guides all located at the link:
http://help.sap.com/hana
 Technical Operations Manual (TOM)

 HANA Administration Guide

 HANA Security Guide

 Other Important Guides:

 HANA Master Guide

 HANA Lifecycle Management

 HANA Studio Installation

 HANA Installation Guide

64
SAP HANA Troubleshooting and Performance
Analysis Guide

From help.sap.com/hana 65
Where to Find More Information

• Important SAP Notes for HANA

SAP NOTE HANA NOTE TITLE

NUMBER
1514967 SAP HANA Central Note
1523337 SAP HANA Database Central Note
1681092 Support for multiple SAP HANA Databases on a single SAP
HANA appliance
1661202 Support for multiple applications on HANA
1577128 Supported clients for HANA
1514966 HANA Sizing for Database
1637145 BW on HANA Sizing for Database
1597355 Swap space recommendations for Linux

66
HANA FAQ NOTES
2044468 FAQ: SAP HANA Partitioning
2057046 FAQ: SAP HANA Delta Merges
2073112 FAQ: SAP HANA Studio
2081591 FAQ: SAP HANA Table Distribution
2100040 FAQ: SAP HANA CPU
2100009 FAQ: SAP HANA Savepoints
2101244 FAQ: SAP HANA Multitenant Database Containers
2112604 FAQ: SAP HANA Compression
2114710 FAQ: SAP HANA Threads and Thread Samples
2115815 FAQ: SAP HANA Database Patches and Upgrades
2116157 FAQ: SAP HANA Consistency Checks and Corruptions
2124112 FAQ: SAP HANA Parsing
2127458 FAQ: SAP HANA Loads and Unloads
1640741 FAQ: "DB users for the DBA Cockpit for SAP HANA“
2103477 Too many compressed alert trace files

67
HANA FAQ NOTES (cont.)
2057595 FAQ: SAP HANA High Availability
2082286 FAQ: SAP HANA Graph
2000003 FAQ: SAP HANA
1642148 FAQ: SAP HANA Database Backup & Recovery
2039883 FAQ: SAP HANA Database and storage snapshots
2104291 FAQ - SAP HANA Multitenant database containers
2053330 FAQ: Operations Recommendation on SAP HANA Alerts
2000000 FAQ: SAP HANA Performance Optimization
2000002 FAQ: SAP HANA SQL Optimization
1999998 FAQ: SAP HANA Lock Analysis
1999930 FAQ: SAP HANA I/O Analysis
1999997 FAQ: SAP HANA Memory
1999880 FAQ: SAP HANA System Replication
1969700 SQL statement collection for SAP HANA
2122650 Hana Server Crashes (OUT OF MEMORY) occurred

68
HANA FAQ NOTES (cont.)
81065 Troubleshooting SAP HANA Network
2031037 Upgrade to SAP_BASIS 740 or NetWeaver® Kernel 74x
2013043 Performance Problems with Enqueue Work Process
1999020 SAP HANA: Troubleshooting database is no longer reachab
1987132 SAP HANA: Parameter setting for SELECT FOR ALL ENTRIES
1917938 Migration of the statistics server for Revision 74 or higher
1835075 Analyze backup and recovery performance issues
1694864 Very long Commit Times
1601951 Self Service 'SQL Statement Tuning' - Prerequisites and FAQ
1100926 FAQ: Network performance
805934 FAQ: Database time
1840954 Alerts related to HANA memory consumption (OOM) dump files.
706478 Preventing Basis tables from increasing considerably

69
SAP Services for Performance Analysis

• Business Process Performance Optimization Service (BPPO)

• Volume Test Optimization Service (VTO)
• Customer Program Optimization Service (CPO)
• SAP GoingLive Support Service (GLS)
• SAP EarlyWatch Check
• SAP HANA System Administration Service
• Solution Manager Self-Service “SQL Statement Tuning” (SAP Note
1601951)

70
7 Key Points to Take Home

• Understanding the HANA key performance areas builds the

foundation for improving the performance of the system
• Performance recommendations will immediately be beneficial
• How to detect and resolve performance issues before they
become a real problem
• Knowledge of the performance tools and how to use them will
save much time
• Performance analysis helps to uncover the cause of the issues
• Monitoring the system for key indicators on performance is
paramount to a successful running HANA system
• Troubleshooting using the Logs, Diagnostics, and Traces takes
practice, but once mastered, will make for a better running HANA
system
71
Your Turn!

How to contact me:

Kurt Hollis
kuhollis@deloitte.com

Please remember to complete your session evaluation 72

Disclaimer

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or
an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective
companies. Wellesley Information Services is neither owned nor controlled by SAP SE.

About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each
of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte
Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP
and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.

This presentation should not be interpreted as a representation about or endorsement of any third party products, including SAP software.

This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial,
investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it
be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your
business, you should consult a qualified professional advisor.

Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.

Copyright © 2015 Deloitte Development LLC. All rights reserved.

Member of Deloitte Touche Tohmatsu Limited.

73
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2015 Wellesley Information Services. All rights reserved.