Professional Documents
Culture Documents
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:
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
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.
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 ************/
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.