Performance Improvement in ECC - Leverage Power of HANA

System is slow is one of the common complaints from users of SAP ECC. Root cause analysis
of the scenario may lead to some reasons - Poor performance, huge data volumes, Speed of
Analysis and Reporting etc. In these Challenging times, access to trusted, timely, accurate and
detailed information in certain important Business areas could make the difference between
corporate success or failure.
SAP HANA gives businesses the ability to perform complex calculations faster than ever in real
time. Its capabilities like In-memory computing, Columnar Storage etc can be leveraged to
process large data volumes in a more efficient way, which in turn will help address ERP
performance issues to a great extent.
HANA Innovations
Among various HANA innovations from SAP that are currently available for use for Customers
(as of Nov 2012) , SAP HANA accelerators(CO-PA being the most famous one) and using
HANA as a Secondary database for existing ERP are the best fit to improve performance. With
most of the business logic in ECC being heavily done in ABAP layer, customers will not see any
huge benefit buying HANA as a database. SAP cannot rewrite everything in ECC to work on
HANA. This means that we can expect more accelerators to be built by SAP, and more specialty
applications for ECC that needs HANA. Some of the HANA scenarios that are currently available
are shown below:

1. SAP HANA Accelerators:

These are standard accelerators provided by SAP. Primary data storage stays in ERP and HANA
is used as a secondary database. How to use HANA as a secondary database connection is well
explained in Thomas Jungs blog HANA Connectivity via Secondary database connection.
Data is replicated from ERP to HANA through SAP LT replication server. These accelerators
further read data from SAP HANA database instead of classical database, help in enjoy ing
significant acceleration and hence can reap the benefits of HANA.

Some of the SAP accelerators that are currently available are :

CO-PA - Profitability Analysis Accelerator
FI - Financial Accounting Accelerator
CO - Controlling Accelerator
Material Ledger Accelerator
Each of these accelerators have a set of Technical Pre-requisites - like HANA box and ERP EHP
(ERP 6.0, EHP 6), Netweaver EHP, SP and for SAP Kernel etc. These accelerators are built using
non-disruptive model (Plug-and-play) and can be readily used (Deployment is possible with
very little customizing, within few weeks). Benchmarking figures gathered from Use cases of
standard reports powered by these accelerators have shown an acceleration factor of around 40 to
50 which is a very good indicator of performance improvement.

2. SAP HANA as Secondary Database to accelerate ECC Transactions/reports

Performance of Custom/standard reports/transactions can be improved by using the same
approach of accelerators. In this scenario, HANA is used as secondary database and data is
replicated to HANA d/b from ERP. Transaction/Report needs to be slightly modified to read data
from HANA d/b instead of the classical database. Technical Pre-requisite in this scenario would
be to have a HANA box and ERP EHP (ERP 6.0, EHP 6), Netweaver EHP, SP and for SAP
Kernel etc.
How can I detect Optimizing potential for HANA? , How can I optimize my existing code ,
How can I fully exploit the power of SAP HANA?, could be some of the questions lingering in
the minds of the Application developer to improve performance. Some of the optimization
techniques that can be used here are explained as follows:

Use power of Open SQL replace classic ABAP coding by advanced Open SQL features like
- Joins, Sub-selects, Sorting, Aggregations, etc can be used.
- Database round trips and transferring data too much data into application server needs to be
reduced.
- Parallelization on SAP HANA can be benefited implicitly.
- Avoid Native SQL and prefer Open SQL due to the reasons that we already know Open
SQL is integrated in ABAP language and development infrastructure and it works on all
databases.
Open SQL Guidelines general performance guidelines like the following stay valid:
- Keep the result set small SELECT <colname> from <tabname> instead of SELECT * from
<tabname>. This is very important with SAP HANA as not only the data transferred matters,
but also the number of columns to be accessed by the database
-

Minimize the amount of data transferred use aggregate functions together with group by,
having SELECT carrid connid fldate MAX( luggweight ) INTO (ls_sbook-carrid,
ls_sbook-connid...) FROM sbook GROUP BY carrid connid fldate HAVING MAX(
luggweight ) > 20. Observations have shown that SELECT COUNT(*) can be much faster on
SAP HANA (especially when using non-key fields) , aggregate functions can be performed
very efficiently by SAP HANA, transferring calculations (including sorting / grouping) to the
SAP HANA database can increase overall performance. This means Aggregations including
sorting and grouping is a big strength of SAP HANA.

Minimize the number of data transfers - e.g. avoid nested SELECT ENDSELECT loops.
Using array fetches (instead of record by record transfer) is also important for SAP HANA.

Minimize the search overhead - e.g. specify the WHERE clause to keep the number of
searches down and create suitable indices if necessary. Observations have shown that SAP
HANA is not faster than a traditional database when the WHERE specifies the full primary /
secondary key (when reading buffered data) and SELECTs based on non-key fields can be
much faster with SAP HANA. A selective WHERE-clause is still advisable, but SAP HANA
offers fast scans on all columns.

Reduce the database Load - e.g. check whether a table meets the criteria for table buffering
(on the application server). Observations have shown that basic rule (still) applies: internal
table << table buffer << traditional database (memory) / SAP HANA database << traditional
database (disk). Use table buffering (on the application server) also in conjunction with SAP
HANA where possible. It is required to keep in mind that certain Open SQL statements
bypass the table buffer.

Use ALV optimized for SAP HANA to display large tabular data
Basic Principle is to select from the database only data which is to be displayed on the screen and
push down the ALV features to the database. Usage Details include Option to describe data
declaratively instead of passing large internal tables , Optimized HANA database access based on
user interface needs , Usable in SAP GUI and Web Dynpro / Floorplan Manager.
To summarize, use Open SQL as much as possible with most generic guidelines already being
used still staying valid for HANA and change the design patters for reports to use Code to data
instead of data to code approach.

Application Server for HANA (AS ABAP for HANA) - Ramp-Up and general availability

planned for 2013

The well-known SAP NetWeaver Application Server ABAP has been optimized for
running on the SAP HANA in-memory database. This will enable ABAP developers to
build cutting-edge business applications leveraging the proven, reliable ABAP
technology as well as the powerful in-memory capabilities provided by SAP HANA. This
means that AS ABAP can be used for development of new types of SAP applications
(hybrid) based on SAP HANA and on ABAP - custom development that can benefit
from leveraging SAP HANA in the analytical and transactional world.

With the combination of ABAP and SAP HANA, one can optimize existing programs
and build new applications that were not even possible before. Some of the existing
ABAP programming guidelines stay the same, some new development patterns have
emerged and AS ABAP can be used to fully exploit the power of SAP HANA from
within ABAP. According to SAP, AS ABAP is made part of upcoming release SAP
NetWeaver 7.4 (Ramp-Up and general availability planned for 2013).
According to SAP, motivation for AS ABAP comes from different stake holders, especially the
developer, who asks for an Integrated development environment (IDE) comprising all design
time tools as well as an effective and efficient business programming model, which allows to reuse existing ABAP skill set.

Sample scenario for AS ABAP would look like this :

The SAP HANA platform combines in-memory software with hardware from leading SAP
partners. Adding SAP HANA technology to certified database hardware enables not only
significant acceleration of existing applications, but also the development of completely new
applications that were not previously possible.

Main Features:
AS ABAP Leverages in-memory computing of HANA by using Code Push down technique,
where in calculation logic is pushed down from the application server to the database server. The
SAP HANA database then performs the calculations and sends the resulting data set back for use
by an application.

Traditionally, application logic is executed in the ABAP application server and data is copied
between data and application server. This is an expensive process for data intensive processes.
Using HANA , one can develop optimized applications with data residing in main memory, and
take advantage of massive parallelization with multi-core CPUs

HANA application programming allows to implement Code Push down in the following ways.
SQL script : SQL script is the rich stored procedure language of the SAP HANA database. SQL
script procedures may contain SQL statements and call other procedures. It is used to write
procedural orchestration logic and to define complex data flows.

Example :
CREATE FUNCTION divide
( IN x INTEGER,
IN y INTEGER,
OUT result INTEGER,
OUT rest INTEGER
)
TYPE SCALAR
BEGIN
result = @x@/@y@;
rest =@x@-(@result@*@y@);
END;
SELECT divide(sales.totalcount, sales.parts,relcount, rest)
FROM sales;

SQL script function call in ABAP is similar to already existing ABAP, Call syntax. ABAP types
are mapped to native SQL script types according to DDIC type mapping. ABAP internal tables
are mapped to table types. For more details on SQL script, please refer to the SQL Script guide
available at SAP Service market place.
Database Procedures:
These are created using SQL script. These can be called from ABAP report/transaction but is
actually executed at the Database layer.

Example :
DATABASE procedure high_and_low
/********* Begin Procedure Script ************/
BEGIN
et_high = select top 5 buyer_guid as bupa_guid from epm.snwd_so order by net_amount;
et_low = select top 5 buyer_guid as bupa_guid from epm.snwd_so order by net_amount desc;
END;
/********* End Procedure Script ************/

Calling this procedure from an ABAP report

REPORT z_high_and_low.
TYPES: ty_guid TYPE x LENGTH 16.
TYPES: BEGIN OF ty,
guid TYPE ty_guid,
END OF ty.
DATA :
ls_high type ty,
ls_low type ty,
lt_high TYPE TABLE OF ty,
lt_low TYPE TABLE OF ty.
CALL DATABASE PROCEDURE /XBR/HIGH_AND_LOW( IMPORTING et_high = lt_high et_low =
lt_low ).
WRITE / 'High'.
LOOP AT lt_high INTO ls_high.
WRITE / ls_high-guid.
ENDLOOP.
WRITE / 'Low'.
LOOP AT lt_low INTO ls_low.
WRITE / ls_flop-low.
ENDLOOP.

HANA modeled views: These are used for defining application specific data models, for defining
data flows, and to structure and re-use queries. Modeled Analytical views and Attribute views
can be created with the SAP HANA studio without programming. ABAP-SQL script integration
can be explained as shown below .

To summarize, till we have ECC on HANA released from SAP for general availability, we could
use the above methods to improve performance of ECC transactions.