You are on page 1of 14

An SAP HANA system consists of all the server components needed.

XS Server:
SAP HANA Extended Application Services (SAP HANA XS) provides applications and
application developers with access to the SAP HANA database using a consumption model
that is exposed via HTTP. In addition to providing application-specific consumption models,
SAP HANA XS also host system services that are part of the SAP HANA database,
Compile Server:
The compile server performs the compilation of stored procedures and programs, for
example, SQLScript procedures. It runs on every host and does not persist data.
Web Dispatcher:

The Web Dispatcher processes inbound HTTP and HTTPS connections to XS services.
PREPROCESSOR SERVER:
The index server uses the preprocessor server for analyzing text data and extracting the
information on which the text search capabilities are based.
NAME SERVER:
The name server owns the information about the topology of SAP HANA system. In a
distributed system, the name server knows where the components are running and which
data is located on which server.
The below figure gives us an overview of HANA database high level architecture.

INDEX SERVER:
The main SAP HANA database management component is known as the index server, which
contains the actual data stores and the engines for processing the data. The index server
processes incoming SQL or MDX statements in the context of authenticated sessions and
transactions.

The SAP HANA database has its own scripting language named SQLScript. SQLScript
embeds data-intensive application logic into the database, is based on side-effect free
functions that operate on tables using SQL queries for set processing, and is therefore
parallelizable over multiple processors.
SQL and SQLScript are implemented using a common infrastructure of built-in data engine
functions that have access to various meta definitions, such as definitions of relational
tables, columns, views, and indexes, and definitions of SQLScript procedures. This metadata
is stored in one common catalog.

Session Management:
Session Management creates and manages sessions and connections for the database
clients.
Transaction manager
Transaction manager coordinates database transactions, and keeps track of running and
closed transactions.

Column store:
Column store is one of the relational engine which stores the data in column-optimized
tables, which are aggregated and used in analytical operations.
Row store:
Row store is one of the relational engine which engine stores the data in rows, similar to
that of traditional database systems.
Metadata manager:
Metadata manager helps to access metadata of SAP HANA objects like tables, views etc.
Authorization manager:
The authorization manager is triggered by other SAP HANA database components to check if
required privileges are present for all those users using them (table creation/alter, data
requests etc).

PERSISTENCE LAYER:
The database persistence layer is responsible for durability and atomicity of transactions. It
ensures that the database can be restored to the most recent committed state after a
restart and that transactions are either completely executed or completely undone.

HANA Studio:
The SAP HANA studio is an Eclipse-based development and administration tool for working
with SAP HANA, for creating projects, development objects, and deploying them to SAP
HANA and also to perform administrative tasks, such as configuring and monitoring the
system. Please look at SAP HANA Studio Overview for complete details about SAP HANA
Studio.
There are several perspectives present in our studio:
Modeler: Used for creating various types of views and analytical privileges.
Development: Used for programming applications, like creating development objects that
access or update the data models, such as server-side JavaScript or HTML files
Debug: Used to debug code, such as server-side JavaScript or SQLScript.
Administration: Used to monitor the system and change settings.
Thus we had looked at brief overview of the consequences led for moving to SAP HANA and
what HANA is exactly.
Summarizing:

SAP HANA is a flexible, data-source-agnostic appliance that enables customers to


analyze large volumes of SAP ERP data in real-time, avoiding the need to materialize
transformations.

SAP HANA appliance software is a hardware and software combination that


integrates a number of SAP components.

The SAP HANA database is a hybrid in-memory database that combines row-based,
column-based, and object-based database technology. It is optimized to exploit the

parallel processing capabilities of modern multi-core CPU architectures. With this


architecture, SAP applications can benefit from current hardware technologies.
Thank you for reading and hope this information is helpful. Please do share with your friends
if you feel the information is useful.

Different Engines in SAP HANA


In this article I would like to explain about different types of engines we have in HANA and
how each engine will process the execution of modeling objects or native sql statements at
Database level.
The below image shows the different engines available in HANA Database to process models
execution. They are,

Join Engine

OLAP Engine

Calculation Engine

ROW Engine

SQL Engine

The engines used in the backend to process a native sql statement or select statement on
modeling objects can be identified using Visualize Plan option available with right click.
Write the sql statement in SQL console Select the statement Right Click Visualize
Plan

Join Engine:
1.

This engine is used when we execute any Attribute View in HANA or run native SQL
on more than one table with join condition.

2.

If there are any calculations involved either in Attribute View or in native SQL then
Join Engine will use Calculation Engine for calculations and fetches the result.

I would like to explain few scenarios on Attribute View and Native SQL to see how different
engines will be called upon execution.
i) Here is a simple select statement on single table executed, Visualize Plan shows that it
didnt use any Engine. This is probably because, it was executed by SQL Parser or we can
also call it as SQL Engine.

ii) Now lets check on an attribute view created on single table, Visualize plan onselect
statement shows us that, it uses join engine.(Prefix : JE implies Join Engine)

iii) Either Attribute View or native SQL


with Calculations uses Join Engine along with
Calculation Engine to perform the
calculations, which means there is data
transfer between both the engines.
OLAP Engine:
This engine will be called in the backend

1.

whenever we run any queries on Analytic


Views in SAP HANA.
2.

If there are no additional calculations performed like calculated columns, restricted


measures and counters, then everything will be processed in OLAP Engine.

3.

OLAP Engine acts as join engine for those Attribute Views used in Analytic Views,
without any calculated columns

4.

All the join engine work will be converted into BwPopJoin which is part of OLAP
Engine.

5.

If there are any calculations present, to be performed then Calculation engine will be
used along with OLAP Engine.

Examples:
i) We have created an analytic View with Attribute Views and performed visualize which uses
just OLAP Engines (Prefix: BwPop implies OLAP Engine)

ii) If we have any calculations present either in Analytic or Attribute Views in an Analytic
View then system calls both OLAP and Calculation Engine to execute the model in backend.
Below image is the example where we have created an Analytic View with few calculated
columns and did visualize plan which uses both OLAP and Calculation Engine.

Calculation Engine:

1.

This engine is used when we execute calculation view in SAP HANA.

2.

Also it is often called by other engines to perform calculations in any view present in
HANA.

3.

Vice versa a calculation view also uses other engines along with calculation engine.
This is highly dependent on the source objects which were used while building the
calculation view, whether it is GUI or Script based.

Scenarios:

Calculation View on Tables (GUI & Script):


In the first scenario, we have created a calculation view directly on tables and everything is
executed in calculation engine when we did visualize plan (Prefix: CE Implies Calculation
engine)

GUI & SQL Script Calculation View on Models (Analytic View):


In this case lets say we have created a Calculation View on two Analytic Views with GUI
option and system called just OLAP Engine. If the source is Attribute View then the engine
will be Join Engine or if the source is Attribute View with Calculations then both Join Engine
and Calculation Engine.

CE Function Calculation View on Models:


In this scenario irrespective of the source objects used, calculation engine will be used in
the backend to execute the Calculation View. Along with calculation Engine, OLAP engine will
be used if the source is Analytic View and Join Engine incase Attribute View serves as
source.

Note: With this we can easily say in case of CE Functions, system is going to use multiple
engines which has some impact on performance, as the data moves between engines to get
the final result.
SQL Engine:
SQL Engine which is also known as SQL Parser/interface is used for all sorts of SQL

1.

statements generated by frontend application via different different clients and also for
native sql run at database level.
From SAP HANA SP7, we have an option for Calculation Views in Properties section,

2.

where we have an option to choose calculation view to run in SQL Engine. Advantage of
this option is that, instead of moving data between multiple engines HANA executes the
entire script in SQL Engine to get the final result.
Note: We have to keep few things in mind before we use this option.
1. This option is only available for GUI based calculation Views (As of SAP HANA SP9 Rev
94).
2. Using this option actually makes difference in the result of calculated columns based on
the functions we used. Please go through the SAP Note 1857202 SQL Execution of
calculation views for more information on this.
ROW Engine:

1.

This is used to perform operations specifically on ROW tables, which are mostly
system statistics tables.

2.

We have executed a native SQL statement on both ROW and COLUMN store tables
and did a visualize plan which showed usage of ROW Engine.

Thus we had looked at different engines available in SAP HANA and how each engine was
being used based on the type of modeling objects or native SQL executed in SAP HANA.

You might also like