Está en la página 1de 116

An insight into SAP HANA Architecture

SAP HANA Architecture Overview:

The SAP HANA database is developed in C++ and runs on SUSE Linux Enterprise
Server. SAP HANA database consists of multiple servers and the most important
component is the Index Server. SAP HANA database consists of Index Server, Name
Server, Statistics Server, Preprocessor Server and XS Engine.

Index Server:

Index server is the main SAP HANA database component

It 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.
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.
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.
Statistic Server:
The statistics server collects information about status, performance and resource
consumption from the other servers in the system.. The statistics server also provides a
history of measurement data for further analysis.
Session and Transaction Manager:
The Transaction manager coordinates database transactions, and keeps track of
running and closed transactions. When a transaction is committed or rolled back, the
transaction manager informs the involved storage engines about this event so they can
execute necessary actions.
XS Engine:
XS Engine is an optional component. Using XS Engine clients can connect to SAP
HANA database to fetch data via HTTP.

The heart of SAP HANA Index Server

The SAP HANA Index Server contains the majority of the magic behind SAP HANA.

Connection and Session Management

This component is responsible for creating and managing sessions and


connections for the database clients.

Once a session is established, clients can communicate with the SAP HANA
database using SQL statements.

For each session a set of parameters are maintained like, auto-commit, current
transaction isolation level etc.

Users are Authenticated either by the SAP HANA database itself (login with user
and password) or authentication can be delegated to an external authentication
providers such as an LDAP directory.
The Authorization Manager
This component is invoked by other SAP HANA database components to check whether
the user has the required privileges to execute the requested operations.

SAP HANA allows granting of privileges to users or roles. A privilege grants the
right to perform a specified operation (such as create, update, select, execute, and so
on) on a specified object (for example a table, view, SQLScript function, and so on).

The SAP HANA database supports Analytic Privileges that represent filters or
hierarchy drilldown limitations for analytic queries. Analytic privileges grant access to
values with a certain combination of dimension attributes. This is used to restrict access
to a cube with some values of the dimensional attributes.
Request Processing and Execution Control:
The client requests are analyzed and executed by the set of components summarized
as Request Processing and Execution Control. The Request Parser analyses the client
request and dispatches it to the responsible component. The Execution Layer acts as
the controller that invokes the different engines and routes intermediate results to the
next execution step.

SQL Processor:
Incoming SQL requests are received by the SQL Processor. Data manipulation
statements are executed by the SQL Processor itself.

Other types of requests are delegated to other components. Data


definition statements are dispatched to the Metadata Manager, transaction control
statements are forwarded to the Transaction Manager, planning commands are routed
to the Planning Engine and procedure calls are forwarded to the stored procedure
processor.

SQLScript:

The SAP HANA database has its own scripting language named
SQLScript that is designed to enable optimizations and parallelization. SQLScript is a
collection of extensions to SQL.

SQLScript is based on side effect free functions that operate on tables


using SQL queries for set processing. The motivation for SQLScript is to offload dataintensive application logic into the database.
Multidimensional Expressions (MDX):

MDX is a language for querying and manipulating the multidimensional


data stored in OLAP cubes.

Incoming MDX requests are processed by the MDX engine and also
forwarded to the Calc Engine.
Planning Engine:

Planning Engine allows financial planning applications to execute basic


planning operations in the database layer. One such basic operation is to create a new
version of a data set as a copy of an existing one while applying filters and
transformations. For example: planning data for a new year is created as a copy of the
data from the previous year.

Another example for a planning operation is the disaggregation operation


that distributes target values from higher to lower aggregation levels based on a
distribution function.
Calc engine:

The SAP HANA database features such as SQLScript and Planning


operations are implemented using a common infrastructure called the Calc engine.

The SQLScript, MDX, Planning Model and Domain-Specific models are


converted into Calculation Models. The Calc Engine creates Logical Execution Plan for
Calculation Models. The Calculation Engine will break up a model, for example some
SQL Script, into operations that can be processed in parallel.

Transaction Manager:
In HANA database, each SQL statement is processed in the context of a transaction.
New sessions are implicitly assigned to a new transaction. The Transaction Manager
coordinates database transactions, controls transactional isolation and keeps track of
running and closed transactions. When a transaction is committed or rolled back, the
transaction manager informs the involved engines about this event so they can execute
necessary actions.
The transaction manager also cooperates with the persistence layer to achieve atomic
and durable transactions.
Metadata Manager:

Metadata can be accessed via the Metadata Manager component. In the SAP
HANA database, metadata comprises a variety of objects, such as definitions of
relational tables, columns, views, indexes and procedures.

Metadata of all these types is stored in one common database catalog for all
stores. The database catalog is stored in tables in the Row Store. The features of the

SAP HANA database such as transaction support and multi-version concurrency


control, are also used for metadata management.

In the center of the figure you see the different data Stores of the SAP HANA database.
A store is a sub-system of the SAP HANA database which includes in-memory storage,
as well as the components that manages that storage.

The Row Store:


The Row Store is the SAP HANA database row-based in-memory relational data
engine.
The Column Store:
The Column Store stores tables column-wise. It originates from the TREX (SAP
NetWeaver Search and Classification) product.
Want to know more about Row Data and Column Data Storage?
Check Column Data Storage vs Row Data Storage: How Different are they Really?

Persistence Layer:
The Persistence Layer is responsible for durability and atomicity of transactions. This
layer ensures that the database is restored to the most recent committed state after a
restart and that transactions are either completely executed or completely undone. To
achieve this goal in an efficient way, the Persistence Layer uses a combination of writeahead logs, shadow paging and savepoints.

The Persistence Layer offers interfaces for writing and reading persisted data. It also
contains the Logger component that manages the transaction log. Transaction log
entries are written explicitly by using a log interface or implicitly when using the virtual
file abstraction.
Column Data Storage Vs Row Data Storage in HANA

Overview of Row Data Storage and Column Data Storage

Relational databases typically use row-based data storage. However Column-based


storage is more suitable for many business applications. SAP HANA supports both rowbased and column-based storage, and is particularly optimized for column-based
storage.

As shown in the figure below, a database table is conceptually a two-dimensional


structure composed of cells arranged in rows and columns.

Because computer memory is structured linearly, there are two options for the
sequences of cell values stored in contiguous memory locations:

Row Storage - It stores table records in a sequence of rows.


Column Storage - It stores table records in a sequence of columns i.e. the entries of a
column is stored in contiguous memory locations.

Traditional databases store data simply in rows. The HANA in-memory database stores
data in both rows and columns. It is this combination of both storage approaches that
produces the speed, flexibility and performance of the HANA database.
Advantages of column-based tables:

Faster Data Access:


Only affected columns have to be read during the selection process of a query. Any of
the columns can serve as an index.

Better Compression:
Columnar data storage allows highly efficient compression because the majority of the
columns contain only few distinct values (compared to number of rows).

Better parallel Processing:


In a column store, data is already vertically partitioned. This means that operations on
different columns can easily be processed in parallel. If multiple columns need to be
searched or aggregated, each of these operations can be assigned to a different
processor core

Advantages and disadvantages of row-based tables:

Row based tables have advantages in the following circumstances:

The application needs to only process a single record at one time (many
selects and/or updates of single records).

The application typically needs to access a complete record (or row).

Neither aggregations nor fast searching are required.

The table has a small number of rows (e. g. configuration tables, system
tables).

Row based tables have dis-advantages in the following circumstances:

In case of analytic applications where aggregation are used and fast


search and processing is required. In row based tables all data in a row has to be read
even though the requirement may be to access data from a few columns.

Which type of tables should be preferred - Row-based or Column-based?

In case of analytic applications where aggregations are used and fast search and
processing is required row-based storage are not good. In row based tables all data in a
row has to be read even though the requirement may be to access data from a few
columns. Hence these queries on huge amounts of data take a lot of time.

In columnar tables, this information is stored physically next to each other, significantly
increasing the speed of certain data queries.

The following example shows the different usage of column and row storage, and
positions them relative to row and column queries. Column storage is most useful for
OLAP queries (queries using any SQL aggregate functions) because these queries get
just a few attributes from every data entry. But for traditional OLTP queries (queries not
using any SQL aggregate functions), it is more advantageous to store all attributes sideby-side in row tables. HANA combines the benefits of both row- and column-storage
tables.

Conclusion:
To enable fast on-the-fly aggregations, ad-hoc reporting, and to benefit from
compression mechanisms it is recommended that transaction data is stored in a
column-based table.

The SAP HANA data-base allows joining row-based tables with column-based tables.

However, it is more efficient to join tables that are located in the same row or column
store. For example, master data that is frequently joined with transaction data should
also be stored in column-based tables.

SAP HANA Memory Usage Explained

Introduction:
SAP HANA is a leading in-memory database and data management platform, specifically
developed to take full advantage of the capabilities provided by modern hardware to increase
application performance. By keeping all relevant data in main memory (RAM), data processing
operations are significantly accelerated.

"SAP HANA has become the fastest growing product in SAP's history."

A fundamental SAP HANA resource is memory. Understanding how the SAP HANA system
requests, uses and manages this resource is crucial to the understanding of SAP HANA. SAP
HANA provides a variety of memory usage indicators, to allow monitoring, tracking and alerting.

This article explores the key concepts of SAP HANA memory utilization, and shows how to
understand the various memory indicators.

Memory Concepts:
As an in-memory database, it is critical for SAP HANA to handle and track its memory
consumption carefully and efficiently. For this purpose, the SAP HANA database pre-allocates

and manages its own memory pool and provides a variety of memory usage indicators to allow
monitoring.

SAP HANA tracks memory from the perspective of the host. The most important concepts are
as follows:

Physical memory:
The amount of (system) physical memory available on the host.

SAP HANA Allocated memory


The memory pool reserved by SAP HANA from the operating system.

SAP HANA Used memory


The amount of memory from this pool that is actually used by the SAP HANA database.

Determining Physical Memory Size:


Physical memory (DRAM) is the basis for all memory discussions. On most SAP HANA hosts, it
ranges from 256 gigabytes to 2 terabytes. It is used to run the Linux operating system, SAP
HANA, and all other programs that run on the host. The following table lists the various ways of
determining the amount of physical memory:

You can use the M_HOST_RESOURCE_UTILIZATION view to explore the amount of Physical
Memory as follows:

Determine Available Physical Memory:


Execute the SQL query:

select round((USED_PHYSICAL_MEMORY + FREE_PHYSICAL_MEMORY) /1024/1024/1024, 2)


as "Physical Memory GB"
from PUBLIC.M_HOST_RESOURCE_UTILIZATION;

Execute the Linux command:


cat /proc/meminfo | grep MemTotal

Determine Free Physical Memory:


Execute the SQL query:
select round(FREE_PHYSICAL_MEMORY/1024/1024/1024, 2)
as "Free Physical GB"
from PUBLIC.M_HOST_RESOURCE_UTILIZATION;

Execute the Linux command:


awk 'BEGIN {sum = 0};
/^(MemFree|Buffers|Cached):/ {sum = sum + $2}; END {print sum}' /proc/meminfo

SAP HANA Allocated Memory Pool:


The SAP HANA database (across its different processes) reserves a pool of memory before
actual use.

This pool of allocated memory is pre-allocated from the operating system over time, up to a

predefined global allocation limit, and is then efficiently used as needed by the SAP HANA
database code. More memory is allocated to the pool as used memory grows. If used memory
nears the global allocation limit, the SAP HANA database may run out of memory if it cannot
free memory. The default allocation limit is 90% of available physical memory, but this value is
configurable.

To find the global allocation limit of the database, run below SQL query:
select HOST, round(ALLOCATION_LIMIT/1024/1024/1024, 2) as "Allocation Limit GB"
from PUBLIC.M_HOST_RESOURCE_UTILIZATION

Effective Allocation Limit:


In addition to the global allocation limit, each process running on the host has an allocation limit,
the process allocation limit. Given that all processes cannot collectively consume more memory
than the global allocation limit, each process also has what is called an effective allocation limit.
The effective allocation limit of a process specifies how much physical memory a process can in
reality consume given the current memory consumption of other processes.

Example:
A single-host system has 100 GB physical memory. Both the global allocation limit and the
individual process allocation limits are 90% (default values). This means the following:

Collectively, all processes of the HANA database can use a maximum of 90 GB.

Individually, each process can use a maximum of 90 GB.


If 2 processes are running and the current memory pool of process 1 is 50 GB, then the
effective allocation limit of process 2 is 40 GB. This is because process 1 is already using 50 GB
and together they cannot exceed the global allocation limit of 90 GB.

SAP HANA Used Memory:


Used memory serves several purposes:

Program code and stack

Working space and data tables (heap and shared memory)


The program code area contains the SAP HANA database itself while it is running. Different
parts of SAP HANA can share the same program code.

The stack is needed to do actual computations.

The heap and shared memory are the most important part of used memory. It is used for
working space, temporary data and for storing all data tables.

You can use the M_SERVICE_MEMORY view to explore the amount of SAP HANA Used
Memory as follows:

Total Memory Used:


SELECT round(sum(TOTAL_MEMORY_USED_SIZE/1024/1024)) AS "Total Used MB"
FROM SYS.M_SERVICE_MEMORY;

Code and Stack Size:


SELECT round(sum(CODE_SIZE+STACK_SIZE)/1024/1024) AS "Code+stack MB"
FROM SYS.M_SERVICE_MEMORY;

Total Memory Consumption of All Columnar Tables:

SELECT round(sum(MEMORY_SIZE_IN_TOTAL)/1024/1024) AS "Column Tables MB"


FROM M_CS_TABLES;

Total Memory Consumption of All Row Tables


SELECT round(sum(USED_FIXED_PART_SIZE +
USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB"
FROM M_RS_TABLES;

Total Memory Consumption of All Columnar Tables by Schema:


SELECT SCHEMA_NAME AS "Schema",
round(sum(MEMORY_SIZE_IN_TOTAL) /1024/1024) AS "MB"
FROM M_CS_TABLES GROUP BY SCHEMA_NAME ORDER BY "MB" DESC;

Memory Consumption of Columnar Tables:


The SAP HANA database loads columnar tables into memory column by column only upon use.
This is sometimes called "lazy loading". This means that columns that are never used are not
loaded, which avoids memory waste.

When the SAP HANA database runs out of allocated memory, it may also unload rarely used
columns to free up some memory. Therefore, if it is important to precisely measure the total, or
"worst case", amount of memory used for a particular table, it is best to ensure that the table is
fully loaded first by executing the following SQL statement:
LOAD table_name ALL.

To examine the memory consumption of columnar tables, you can use the M_CS_TABLES and
M_CS_COLUMNS views.

The following examples show how you can use these views to examine the amount of memory
consumed by a specific table. You can also see which of its columns are loaded and the
compression ratio that was accomplished.

List All Columnar Tables of Schema 'SYSTEM':


SELECT TABLE_NAME AS "Table", round(MEMORY_SIZE_IN_TOTAL/1024/1024, 2) as "MB"
FROM M_CS_TABLES WHERE SCHEMA_NAME = 'SYSTEM' ORDER BY "MB" DESC;

Show Column Details of Table "TABLE1":


SELECT COLUMN_NAME AS "Column", LOADED AS "Is Loaded",
round(UNCOMPRESSED_SIZE/1024/1024) AS "Uncompressed MB",
round(MEMORY_SIZE_IN_MAIN/1024/1024) AS "Main MB",
round(MEMORY_SIZE_IN_DELTA/1024/1024) AS "Delta MB",
round(MEMORY_SIZE_IN_TOTAL/1024/1024) AS "Total Used MB",
round(COMPRESSION_RATIO_IN_PERCENTAGE/100, 2) AS "Compr. Ratio"
FROM M_CS_Columns WHERE TABLE_NAME = 'TABLE1;

Note: The M_CS_TABLES and M_CS_COLUMNS views contain a lot of additional information
(such as cardinality, main-storage versus delta storage and more). For example, use the
following query to obtain more information:
SELECT * FROM M_CS_COLUMNS WHERE TABLE_NAME = '"' and COLUMN_NAME = '"'

Memory Consumption of Row-Ordered Tables:


Several system tables are in fact row-ordered tables. You can use the M_RS_TABLES view to
examine the memory consumption of row-ordered tables.

For instance, you can execute the following SQL query, which lists all row tables of schema
"SYS" by descending size:
SELECT SCHEMA_NAME, TABLE_NAME, round((USED_FIXED_PART_SIZE +
USED_VARIABLE_PART_SIZE)/1024/1024, 2) AS "MB Used"
FROM M_RS_TABLES
WHERE schema_name = 'SYS' ORDER BY "MB Used" DESC, TABLE_NAME

Memory Consumption Configuration:


By default, SAP HANA can pre-allocate up to 90% of the available physical memory on the host.
There is normally no reason to change the value of this variable, except in the case where a
license was purchased for less than the total of the physical memory. In this case, you should
change the global allocation limit to remain in compliance with the license.

Example 1:
You have a server with 512GB, but purchased an SAP HANA license for only 384 GB. Set the
global_allocation_limit to 393216 (384 * 1024 MB).

Example 2:

You have a distributed HANA system on four hosts with 512GB each, but purchased an SAP
HANA license for only 768 GB. Set the global_allocation_limit to 196608 (192 * 1024 MB on
each host).

Resident memory:
Resident memory is the physical memory actually in operational use by a process.

Over time, the operating system may "swap out" some of a process' resident memory, according
to a least-recently-used algorithm, to make room for other code or data. Thus, a process'
resident memory size may fluctuate independently of its virtual memory size. In a properly sized
SAP HANA appliance there is enough physical memory, and thus swapping is disabled and
should not be observed.

To display the size of the Physical Memory and Resident part, you can use the following SQL
command:
select HOST, round((USED_PHYSICAL_MEMORY +
FREE_PHYSICAL_MEMORY)/1024/1024/1024, 2) as "Physical Memory GB",
round(USED_PHYSICAL_MEMORY/1024/1024/1024, 2) as "Resident GB"
from PUBLIC.M_HOST_RESOURCE_UTILIZATION

Memory Sizing:
Memory sizing is the process of estimating, in advance, the amount of memory that will be
required to run a certain workload on SAP HANA. To understand memory sizing, you will need
to answer the following questions:

1. What is the size of the data tables that will be stored in SAP HANA?
You may be able to estimate this based on the size of your existing data, but unless you
precisely know the compression ratio of the existing data and the anticipated growth factor, this
estimate may only be partially meaningful.

2. What is the expected compression ratio that SAP HANA will apply to these tables?
The SAP HANA Column Store automatically uses a combination of various advanced
compression algorithms (dictionary, LRE, sparse, and more) to best compress each table
column separately. The achieved compression ratio depends on many factors, such as the
nature of the data, its organization and data-types, the presence of repeated values, the number
of indexes (SAP HANA requires fewer indexes), and more.

3. How much extra working memory will be required for DB operations and temporary
computations?
The amount of extra memory will somewhat depend on the size of the tables (larger tables will
create larger intermediate result-tables in operations like joins), but even more on the expected
work load in terms of the number of users and the concurrency and complexity of the analytical
queries (each query needs its own workspace).

SAP Notes 1514966, 1637145 and 1736976 provide additional tools and information to help you
size the required amount of memory, but the most accurate method is ultimately to import
several representative tables into a SAP HANA system, measure the memory requirements,

and extrapolate from the results.

SAP HANA Studio:


You can view some of the most important memory indicators on the Overview tab of the SAP
HANA studio administrative perspective:

For even more details, check out the new Memory Overview feature of the SAP HANA studio.
To access it, right click on a system in the Systems View, and select "Open Memory Overview"
in the context menu, as follows:

This will open the Memory Overview, which looks as follows:

Note: To view the Memory Overview, you need Monitoring privileges. E.g. use the following
SQL statement (replace 'youruser' with the actual user name): call
GRANT_ACTIVATED_ROLE('sap.hana.admin.roles::Monitoring','youruser')

Summary:
SAP HANA maintains many system views and memory indicators, to provide a precise way to
monitor and understand the SAP HANA memory utilization. The most important of these
indicators is Used Memory and the corresponding historic snapshots. In turn, it is possible to
drill down into very detailed reports of memory utilization using additional system views, or by
using the convenient Memory Overview from the SAP HANA studio.

Since SAP HANA contains its own memory manager and memory pool, external indicators, like
the host-level Resident Memory size, or the process-level virtual and resident memory sizes,
can be misleading when estimating the real memory requirements of a SAP HANA deployment.

System Generated Schemas in SAP HANA


A database schema is a way to logically group objects such as tables, views, stored
procedures etc. Think of a schema as a container of objects.

Types of Schemas
There are 3 types of schemas.
1.

User Defined Schema

2.

System Defined Schema

3.

SLT Derived Schema


User Defined Schema:
These are created by user (DBA or System Administrator)

SLT Derived Schema:


When SLT is configured, it creates schema in HANA system. All the tables replicated
into HANA system are contained in this schema

System Defined Schema:


These schemas are delivered with the SAP HANA database and contains HANA system
information. There are system schemas like _SYS_BIC, _SYS_BI, _SYS_REPO,
_SYS_STATISTICS etc.

System Generated Schemas

_SYS_BIC:
This schema contains all the columns views of activated objects. When the user
activates the Attribute View/Analytic View/Calculation View/Analytic Privilege
/Procedure, the respective run-time objects are created under _SYS_BIC/ Column
Views.

_SYS_REPO:
Whatever the objects are there in the system is available in repository. This schema
contains the list of Activated objects, Inactive Objects, Package details and Runtime

Objects information etc.


Also _SYS_REPO user must have SELECT privilege with grant option on the data
schama.
Read more about "GRANT SELECT PRIVILEGE ON _SYS_REPO"

_SYS_BI:
This schema stores all the metadata of created column Views. It contains the tables for
created Variables, Time Data (Fiscal, Gregorian), Schema Mapping and Content
Mapping tables.

_SYS_STATISTICS:
This schema contains all the system configurations and parameters.

_SYS_XS:
This schema is used for SAP HANA Extended Application Services.

SAP HANA Backup and Recovery


SAP HANA is an in-memory database. This means all the data is in RAM. As we all
know that RAM is a volatile memory and all the data get lost when power goes down.
This leads to a very obvious question:
What happens when power goes down in SAP HANA? Do we loose all the
valuable data?

The answer is NO.


SAP HANA is an in-memory database which means all the data resides in RAM.
But there is also a disc memory just for backup purpose.

In-memory computing is safe: The SAP HANA database holds the bulk of its data in
memory for maximum performance, but still uses persistent storage (disk memory) to
provide a fallback in case of failure.

Why Backup is Required?


In database technology, atomicity, consistency, isolation, and durability (ACID) is a
set of requirements that guarantees that database transactions are processed reliably:
A transaction has to be atomic. That is, if part of a transaction fails, the entire
transaction has to fail and leave the database state unchanged.
The consistency of a database must be preserved by the transactions that it performs.
Isolation ensures that no transaction is able to interfere with another transaction.
Durability means that after a transaction has been committed it will remain committed.

While the first three requirements are not affected by the in-memory concept, durability
is a requirement that cannot be met by storing data in main memory alone.
Main memory is volatile storage. That is, it looses its content when it is out of electrical
power. To make data persistent, it has to reside on non-volatile storage, such as hard
drives, SSD, or Flash devices.

How Backup and Recovery Works in SAP HANA?

The main memory (RAM) in SAP HANA is divided into pages. When a transaction
changes data, the corresponding pages are marked and written to disk storage in
regular intervals.
In addition, a database log captures all changes made by transactions. Each committed
transaction generates a log entry that is written to disk storage. This ensures that all
transactions are permanent.

Figure below illustrates this. SAP HANA stores changed pages in savepoints, which are
asynchronously written to disk storage in regular intervals (by default every 5 minutes).
The log is written synchronously. That is, a transaction does not return before the
corresponding log entry has been written to persistent storage, in order to meet the

durability requirement, as described above.

After a power failure, the database can be restarted like a disk-based database.
The database pages are restored from the savepoints, and then the database logs are
applied (rolled forward) to restore the changes that were not captured in the savepoints.
This ensures that the database can be restored in memory to exactly the same state as
before the power failure.

Data backup can be taken manually or can be scheduled.

Few Important Concepts:


What is Database Backup and Recovery
Backup and Recovery is the process of copying/storing data for the specific purpose of
restoring. Backing up files can protect against accidental loss of user data, database
corruption, hardware failures, and even natural disasters.

Savepoint:
A savepoint is the point at which data is written to disk as backup. This is a point from
which the Database Engine can start applying changes contained in the backup disk
during recovery after an unexpected shutdown or crash.
The database administrator determines the frequency of savepoints.

Data and Log:


Data backups

Contain the current payload of the data volumes (data and undo
information)

Manual (SAP HANA studio, SQL commands), or scheduled (DBA Cockpit)

Log backups

Contain the content of closed log segments; the backup catalog is also
written as a log backup

Automatic (asynchronous) whenever a log segment is full or the timeout


for log backup has elapsed

SAP Notes:
Check below SAP notes to find out more about SAP HANA backup and recovery.
Scheduling the SAP HANA Backups: 1651055
SAP HANA database backup and recovery: 1642148

SAP HANA Modeling Introduction


SAP HANA Modeling at a glance:

SAP HANA Information Modeling which also known as SAP HANA Data
Modeling is the heart of HANA application development.

You can create modeling views on top of database tables and implement business logic
to create a meaningful report.

These modeling views can be consumed via Java or HTML based


applications or SAP HANA native applications. You can also use SAP tools like SAP
Lumira or Analysis Office to directly connect to HANA and report modeling views. It is
also possible to use 3rd party tools like MS-Excel to connect to HANA and create your
report.

Modeling SAP HANA Information Views are important for successfully


exploiting the power of SAP HANA. These views are classified as

Attribute Views

Analytic Views

Calculation Views

At run-time these views make implicit use of optimized SAP HANA InMemory calculation engines and thus enable for best performance.

HANA Data Modeling is only possible for Column Tables i.e. Information
Modeler only works with column storage tables.

Attribute View:

Attribute views are dimensions, BW characteristics or master data.

Attribute views are used to join to a dimension or attribute view.

In most cases used to model master data like entities (like Product,
Employee, Business Partner)

Highly re-used and shared in Analytic- and Calculation Views

Example : An attribute view "FLIGHT" can show together Airline Code, Airline
Connection Number and flight Date into one Object. This attribute view can be used in
analytic and calculation views where entities are relevant.

Generally attribute views represent master data. But, however technically there is no
restriction and it's possible to make attribute views on transaction data.

Analytic View:

Analytic views are star schemas or fact tables surrounded by dimensions,


calculations or restricted measures.

In the language on SAP BW analytical views can be roughly compared


with Info Cubes or Info Sets.

Analytic views are typically defined on at least one fact table that contains
transactional data along with number of tables or attribute views.

Analytic views leverage the computing power of SAP HANA to calculate


aggregate data, e. g., the number of bikes sold per country, or the maximum power
consumed per month.

It is specifically designed to execute star schema queries

Calculation View:

Calculation views are composite views used on top of analytical and


attribute views.

It can perform complex calculations not possible with other views.

It can be defined as either graphical views or scripted views depending on


how they are created. Graphical views can be modeled using the graphical modeling
features of the SAP HANA Modeler. Scripted views are created as sequences of SQL
statements.

Calculation views can be referred as combination of tables, attributes


views and analytical views to deliver a complex business requirement. They offer to
combine different analytical views into one source of data for reporting.

Want to do some hands-on? Please read


Build Your First SAP HANA Model in 10 Minutes

SAP HANA Modeling View Processing:


SAP HANA has mainly 3 types of engines that are used based on the views required by
the model.

Join Engine: Used for Attribute Views

OLAP Engine: Used for Analytic Views (without calculated columns)

Calculation Engine: Used for Analytic views with calculated attributes, Calculation
views

To know more about SAP HANA Engine, please read Understanding SAP HANA
Engine

Build Your First SAP HANA Model in 10 Minutes


This article describes how to build a simple model using data stored on SAP HANA.
By the end of this, you will have created tables, attribute views, and analytical views in
SAP HANA.

Prerequisite:

You have SAP HANA Studio installed on your machine.

You have added an SAP HANA system in HANA Studio

Create new tables in SAP HANA and fill them with data:

1.

Open HANA Studio and expand the SAP HANA system.

2.

Go to your schema. Right-click on your schema and select SQL editor.

Note: In this example schema name is "SAP_HANA_TUTORIAL". In case you want to


create a new schema use below query.
create schema <schema_name>;

3.

Copy and paste the below script in SQL editor and execute.

--REPLACE <YOUR SCHEMA> WITH YOUR SCHEMA NAME

-- Create Product table


create column table "<YOUR SCHEMA>"."PRODUCT"(
"PRODUCT_ID" INTEGER null,
"PRODUCT_NAME" VARCHAR (100) null default ''
);

insert into "<YOUR SCHEMA>"."PRODUCT" values(1,'Shirts');


insert into "<YOUR SCHEMA>"."PRODUCT" values(2,'Jackets');
insert into "<YOUR SCHEMA>"."PRODUCT" values(3,'Trousers');

insert into "<YOUR SCHEMA>"."PRODUCT" values(4,'Coats');


insert into "<YOUR SCHEMA>"."PRODUCT" values(5,'Purse');
-- Create Region table
create column table "<YOUR SCHEMA>"."REGION"(
"REGION_ID" INTEGER null,
"REGION_NAME" VARCHAR (100) null default '',
"SUB_REGION_NAME" VARCHAR (100) null default ''
);

insert into "<YOUR SCHEMA>"."REGION" values(1,'Americas','North-America');


insert into "<YOUR SCHEMA>"."REGION" values(2,'Americas','South-America');
insert into "<YOUR SCHEMA>"."REGION" values(3,'Asia','India');
insert into "<YOUR SCHEMA>"."REGION" values(4,'Asia','Japan');
insert into "<YOUR SCHEMA>"."REGION" values(5,'Europe','Germany');

-- Create Sales table


create column table "<YOUR SCHEMA>"."SALES"(
"REGION_ID" INTEGER null,
"PRODUCT_ID" INTEGER null,
"SALES_AMOUNT" DOUBLE null);

insert into "<YOUR SCHEMA>"."SALES" values(1,1,100);


insert into "<YOUR SCHEMA>"."SALES" values(1,2,90);
insert into "<YOUR SCHEMA>"."SALES" values(1,5,85);
insert into "<YOUR SCHEMA>"."SALES" values(2,2,80);
insert into "<YOUR SCHEMA>"."SALES" values(2,1,75);
insert into "<YOUR SCHEMA>"."SALES" values(3,3,85);
insert into "<YOUR SCHEMA>"."SALES" values(4,4,75);

insert into "<YOUR SCHEMA>"."SALES" values(5,1,65);


insert into "<YOUR SCHEMA>"."SALES" values(5,2,65);

4.

After executing the scripts you should have 3 tables created. If there are no
tables, try right-clicking on your schema and refreshing.

Grant schema SELECT rights to _SYS_REPO user:


Open the SQL editor of your schema and execute the following command line:
GRANT SELECT ON SCHEMA <YOUR SCHEMA> TO _SYS_REPO WITH GRANT OPTION;

If you miss this step, an error will occur when you activate your views later.
Click here to know more about this.

Create an attribute view:

1.

Open HANA Studio and make sure you are in Modeler perspective

2.

Create a new package under the content folder.


Right-click on the content folder and choose "New" -> "Package." Fill the fields "Name"
and "Description" and click "OK."
If you dont see the new package after this, try right-clicking on the content folder and
refreshing.

3.

Right click on the package and choose "New Attribute View." Enter a name and a
description and click "Finish"

4.

The attribute view will be opened in the HANA studio editor. Select "+" sign on
"Data Foundation"

5.

Search for table "REGION" and select it.

6.

Now add the columns from the REGION table to output. Simply right click on the
column and select "Add to Output". Add all 3 columns REGION_ID, REGION_NAME,

SUB_REGION_NAME to the output.


Once it is done, you will see the selected column in right side pane.

7.

Now select "Semantics". All 3 columns appears under Column pane as


attributes.

8.

Now you need to define attributes and key attributes. Every attribute view must
have at least one key attribute.

9.

Click on the "Type" to select key attribute for REGION_ID.

10.

Click on the "Save and Activate" button on top right corner to activate the view.

11.

In the "Job log" Pane you will see an activation completed message.

12.

Attribute view is created and activated.


To see the output of this view click on the "Data Preview" button on top right corner.

Then select "Raw Data" tab.

Congratulation!! You have successfully created your first modeling view.

Next step is to create an analytic view.

Create an Analytic View:

1.

Right click on the package and choose "New Analytic View." Enter a name and a
description and click "Finish"

2.

Click on "+" sign of "Data Foundation" and add table SALES.

3.

Right Click on the columns of table SALES and add REGION_ID and
SALES_AMOUNT to output.

4.

Click on "+" sign of "Logical Join" and add attribute view "AT_Region" which was
created earlier.

5.

Click on the REGION_ID from "Data Foundation" and connect it to the


REGION_ID of attribute view AT_Region. In the properties pane select join type as left
outer join and cardinality as n..1

6.

Select "Sementics". In the right side change the column type of


SALES_AMOUNT as measure.

7.

Activate the analytic view similar to attribute view.


Right-click on your analytic view and choose "Data Preview." After that, you can browse
through the tabs named raw data, distinct values, and analysis.

Congratulation!! You have successfully created your first Analytic View.

SAP HANA Calculation View


Calculation views are composite views and can be used to combine other views. It
canconsume other Analytical, Attribute, other Calculation Views & tables.
It can perform complex calculations not possible with other views.

Types of Calculation Views:


Calculation views can be created using a Graphical editor or the SQL Script editor.

Graphical calculation views are created using the graphical editor.

Scripted calculation views are created using SQL Editor. Complex


calculations which are not possible thru graphical approach, can be created using
SQLScript.

Capabilities of Calculation Views:


Graphical Calculation Views

Can consume other Analytical, Attribute, other Calculation Views & tables

Built-in Union, Join, Projection & Aggregation nodes

Provides additional features like Distinct, Count, Calculation, dynamic


joins

No SQL or SQL Script knowledge required


SQLScript-based Calculation Views

Can be regarded as a function, defined in the HANA-specific language


SQLScript, which is built upon SQL commands or special HANA pre-defined functions

Must be read-only

Create Graphical Calculation View in 10 minutes

Calculation view can be defined as either graphical views or scripted views. In this
article we will learn how we can create graphical calculation view.

Prerequisite:

You have SAP HANA Studio installed on your machine.

You have added an SAP HANA system in HANA Studio

Scenario:
Suppose there are 3 tables PRODUCTS, REGION and SALES.

We need to find out

What are the sales value for "Asia" region?

What are the total sales value for "Shirts"?

What are the total sales value for "Europe" for "Jackets"?
Let us create a graphical calculation view to get answer of the above mentioned
questions.

Create new tables in SAP HANA and fill them with data:
1.

Open HANA Studio and expand the SAP HANA system.

2.

Go to your schema. Right-click on your schema and select SQL editor.

Note: In this example schema name is "SAP_HANA_TUTORIAL". In case you want to


create a new schema use below query.
create schema <schema_name>;

3.

Copy and paste the below script in SQL editor and execute.

----REPLACE <YOUR SCHEMA> WITH YOUR SCHEMA NAME

---- Create Product table


create column table "<YOUR SCHEMA>"."PRODUCT"(
"PRODUCT_ID" INTEGER,

"PRODUCT_NAME" VARCHAR (100),


primary key ("PRODUCT_ID")
);

insert into "<YOUR SCHEMA>"."PRODUCT" values(1,'Shirts');


insert into "<YOUR SCHEMA>"."PRODUCT" values(2,'Jackets');
insert into "<YOUR SCHEMA>"."PRODUCT" values(3,'Trousers');
insert into "<YOUR SCHEMA>"."PRODUCT" values(4,'Coats');
insert into "<YOUR SCHEMA>"."PRODUCT" values(5,'Purse');
-- Create Region table
create column table "<YOUR SCHEMA>"."REGION"(
"REGION_ID" INTEGER,
"REGION_NAME" VARCHAR (100),
"SUB_REGION_NAME" VARCHAR (100),
PRIMARY KEY ("REGION_ID")
);

insert into "<YOUR SCHEMA>"."REGION" values(100,'Americas','North-America');


insert into "<YOUR SCHEMA>"."REGION" values(200,'Americas','South-America');
insert into "<YOUR SCHEMA>"."REGION" values(300,'Asia','India');
insert into "<YOUR SCHEMA>"."REGION" values(400,'Asia','Japan');
insert into "<YOUR SCHEMA>"."REGION" values(500,'Europe','Germany');

-- Create Sales table


create column table "<YOUR SCHEMA>"."SALES"(
"REGION_ID" INTEGER ,
"PRODUCT_ID" INTEGER ,
"SALES_AMOUNT" DOUBLE,

PRIMARY KEY ("REGION_ID", "PRODUCT_ID") );

insert into "<YOUR SCHEMA>"."SALES" values(100,1,100);


insert into "<YOUR SCHEMA>"."SALES" values(100,2,90);
insert into "<YOUR SCHEMA>"."SALES" values(100,5,85);
insert into "<YOUR SCHEMA>"."SALES" values(200,2,80);
insert into "<YOUR SCHEMA>"."SALES" values(200,1,75);
insert into "<YOUR SCHEMA>"."SALES" values(300,3,85);
insert into "<YOUR SCHEMA>"."SALES" values(400,4,75);
insert into "<YOUR SCHEMA>"."SALES" values(500,1,65);
insert into "<YOUR SCHEMA>"."SALES" values(500,2,65);

4.

After executing the scripts you should have 3 tables created. If there are no
tables, try right-clicking on your schema and refreshing.

Grant schema SELECT rights to _SYS_REPO user:


Open the SQL editor of your schema and execute the following command line:

GRANT SELECT ON SCHEMA <YOUR SCHEMA> TO _SYS_REPO WITH GRANT OPTION;

If you miss this step, an error will occur when you activate your views later.
Click here to know more about this.

Steps for creating calculation view:

1.

Open HANA Studio and make sure you are in Modeler perspective. Right click on
the package and choose "Calculation View"

2.

Enter a name and a description. Select Subtype as "Graphical" and Data


Category as "Cube". Then click on "Finish".

3.

You will see the graphical editor as shown in image below.

4.

Click on the "Join" symbol and drag it in the scenario area to create Join block.
Click on "+" sign of "Join" and add REGION tables.

5.

Similarly add SALES table.

6.

Select the REGION_ID from REGION table. Drag it and drop it on the
REGION_ID of SALES table. Join type can be changed in the Properties tab. Let it be

Inner Join as of now.

7.

Add REGION_NAME, SUB_REGION_NAME, PRODUCT_ID AND


SALES_AMOUNT to the Columns by right clicking and clicking on "Add To Output".
Alternatively you can also click on the grey color circle before the column name to add it
to output.

8.

Click on the "Join" symbol again and drag it in the scenario area to create
another Join block. Connect the previous Join block to new Join block with the arrow.

9.

Click on "+" sign of new Join block and add PRODUCT table.

10.

Select the PRODUCT_ID from Join_1. Drag it and drop it on the PRODUCT_ID
of PRODUCT table. Select the Join type as Inner Join.
Add REGION_NAME, SUB_REGION_NAME, PRODUCT_ID, SALES_AMOUNT and
PRODUCT_NAME to the Columns by right clicking and clicking on "Add To Output".

11.

Add the Join block "Join_2" to "Aggregation" block by arrow. Add all the columns
to output.

12.

Select Semantics. Now we need to specify which columns are attributes and
which columns are measures. Click on the "Auto Assign" button to do it automatically.
Alternatively you can also specify the Attribute/measure by clicking on Type down-arrow.
Select SALES_AMOUNT as measure and rest of the column as attribute.

13.

Activate the calculation view. Right-click on your calculation view and choose
"Data Preview". After that, you can browse through the tabs named Raw Data, Distinct
Values, and Analysis.
Analysis tab:

Raw Data tab:

Congratulation!! You have successfully created your first Graphical Calculation


View.

Understanding SAP HANA Engine


SAP HANA Engine:

SAP HANA has mainly 3 types of engines that are used based on the views required by
the model.

Join Engine:

Used when querying an Attribute View

The join engine is also used, when you run plain SQL.

OLAP Engine:

Used for Analytic view (without calculated columns).

Calculation Engine:

Used for Analytic views with calculated attributes and Calculation views

Note: To check what engine is used to process a query: simply run the Plan
Visualization on your query.

Q1: What If I execute a standard ANSI92 SQL statement from a BI tool or in SAP HANA
Studio. What engines will be used?
Ans: Depends on what objects you reference in your query. If you're just querying plain
base tables then the join engine will be used. As soon as you reference an analytic or
calculation view, the other engines will be employed as well.

Q2: If my Analytic View foundation is joined to attribute views, is both the OLAP and
JOIN Engine used?
Ans: Nope - during activation of the analytic views, the joins in the attribute views get
'flattened' and included in the analytic view run time object. Only the OLAP engine will
be used then.

SAP HANA Join Types - All You Ever Wanted to


Know

A Join clause combines records from two or more tables /view in a database.
SAP HANA supports following types of join.

Inner Join

Left Outer Join

Right Outer Join

Full Outer Join

Referential Join

Text Join
In this article you will learn the details of all these type of joins.

We are going to use 2 tables to explain the different types of Join. CUSTOMER and
SALES_ORDER.

SQL Script to create the above mentioned tables:


-- REPLACE <Schema_Name> WITH YOUR SCHEMA

CREATE COLUMN TABLE <Schema_Name>."CUSTOMER" (


"CustomerID" nvarchar(10) primary key,
"CustomerName" nvarchar(50)
);
INSERT INTO <Schema_Name>."CUSTOMER" VALUES ('C1', 'Alfred');
INSERT INTO <Schema_Name>."CUSTOMER" VALUES ('C2', 'John');

INSERT INTO <Schema_Name>."CUSTOMER" VALUES ('C3', 'Maria');


INSERT INTO <Schema_Name>."CUSTOMER" VALUES ('C4', 'Harry');

CREATE COLUMN TABLE <Schema_Name>."SALES_ORDER" (


"OrderID" integer primary key,
"CustomerID" nvarchar(10),
"Product" nvarchar(20),
"Total_Units" integer
);
INSERT INTO <Schema_Name>."SALES_ORDER" VALUES (101, 'C1','Camera',300);
INSERT INTO <Schema_Name>."SALES_ORDER" VALUES (102, 'C1','Mobile',200);
INSERT INTO <Schema_Name>."SALES_ORDER" VALUES (103, 'C2','iPod',500);
INSERT INTO <Schema_Name>."SALES_ORDER" VALUES (104, 'C3','Television',400);
INSERT INTO <Schema_Name>."SALES_ORDER" VALUES (105, 'C5','Laptop',800);

Inner Join:
The INNER JOIN selects the set of records that match in both the Tables.

Syntax

SELECT T2."OrderID", T1."CustomerID", T1."CustomerName", T2."Product", T2."Total_Units"


from "CUSTOMER" AS T1
INNER JOIN
"SALES_ORDER" AS T2
ON T1."CustomerID" = T2."CustomerID";

The result of Inner Join will be like this:

Where to Use?
Inner join should be used if referential integrity is ensured.
Inner Join is much faster that Outer Join thus is the preferred solution if possible from
semantical perspective
Attribute View: Inner Joins can be used to join different master data tables to a joint
dimension Analytical Views: Inner Joins can be used if referential integrity cannot be ensured

Left Outer Join:


The Left Outer Join selects the complete set of records from first table (CUSTOMER), with the
matching records (where available) in second table (SALES_ORDER). If there is no match, the
right side will contain null.

Syntax
SELECT T2."OrderID", T1."CustomerID", T1."CustomerName", T2."Product", T2."Total_Units"
from "CUSTOMER" AS T1
LEFT OUTER JOIN
"SALES_ORDER" AS T2
ON T1."CustomerID" = T2."CustomerID";

The result of Left Outer Join will be like this:

Right Outer Join:


The Right Outer Join selects the complete set of records from second table (SALES_ORDER),
with the matching records (where available) in first table (CUSTOMER). If there is no match, the
left side will contain null.

Syntax
SELECT T2."OrderID", T2."CustomerID", T1."CustomerName", T2."Product", T2."Total_Units"
from "CUSTOMER" AS T1
RIGHT OUTER JOIN
"SALES_ORDER" AS T2
ON T1."CustomerID" = T2."CustomerID";

The result of Right Outer Join will be like this:

Full Outer Join:


The INNER JOIN selects the set of records that match in both the Tables.

Syntax
SELECT T2."OrderID", T1."CustomerID", T1."CustomerName", T2."Product", T2."Total_Units"
from "CUSTOMER" AS T1
FULL OUTER JOIN
"SALES_ORDER" AS T2
ON T1."CustomerID" = T2."CustomerID";

The result of Full Outer Join will be like this:

All the 4 types of joins explained above are standard database join types.
SAP HANA also supports 2 new type of joins. Referential Join and Text Join. These 2 type of
joins can only be used in modeling views.
Let's take a look into these 2 new type of joins.

SAP HANA Referential Join:


Referential Join is semantically an inner join that assume that referential integrity is given.

Note: Referential integrity is the property of database which ensures that each foreign key value
in a table exists as a primary key in the referenced table.

Referential join is performance wise better than inner join, but only be used when you are sure
that referential integrity is maintained.

SAP HANA Text Join:


Text Join is used in order to get language-specific data.

You have a product table that contains product IDs without descriptions and you have a text
table for products that contains language-specific descriptions for each product. You can create
a text join between the two tables to get the language-specific details. In a text join, the right
table should be the text table and it is mandatory to specify the Language Column.

SAP HANA Text Join - Fetch Language Specific


Data

Text Join is used in order to get language-specific data.

Before understanding the text join, it is important that we understand Text Tables.

Text Tables:
Table A is a text table of table B if the key of A comprises the key of B and an additional
language key field (field of data type LANG). Table A may therefore contain explanatory text in
several languages for each key entry of B.

Text Join in SAP HANA:


Text Join is used to fetch the description based on user's session language. Once we implement
the text join in SAP HANA, it automatically find out user's language and give description in that
language.

Implementation of Text Join in SAP HANA:


Example:
Suppose there is a table called "PRODUCT" which contains Product ID and Product Name.

There is also a text table of "PRODUCT", which is called "PRODUCT_TEXT_TABLE". The text
table contains the description of products in different language. For example "Cotton Shirts" in
English and "Baumwoll-Shirts" in German.

Purpose:
Create a calculation view which will give Product Name and Product Description. The Product
Description should be only in user's session language.

Implementation:

1.

Open HANA Studio. Right click on your schema and open SQL Editor. Copy the
below SQL script to create 2 tables - "PRODUCT" and "PRODUCT_TEXT_TABLE".
-- REPLACE WITH YOUR ACTUAL SCHEMA NAME

-- PRODUCT table
CREATE COLUMN TABLE ""."PRODUCT"(
"PRODUCT_ID" INTEGER ,
"PRODUCT_NAME" VARCHAR(20) ,
primary key ("PRODUCT_ID"));

-- PRODUCT text table


CREATE COLUMN TABLE ""."PRODUCT_TEXT_TABLE"(
"PRODUCT_ID" INTEGER ,
"LANGUAGE" VARCHAR(1),
"PRODUCT_DESCRIPTION" VARCHAR(50) ,
primary key ("PRODUCT_ID", "LANGUAGE"));

insert into ""."PRODUCT" values(1,'Shirts');


insert into ""."PRODUCT" values(2,'Jackets');
insert into ""."PRODUCT" values(3,'Trousers');
insert into ""."PRODUCT" values(4,'Coats');
insert into ""."PRODUCT" values(5,'Purse');

insert into ""."PRODUCT_TEXT_TABLE" values(1,'E', 'Cotton Shirts');


insert into ""."PRODUCT_TEXT_TABLE" values(1,'D', 'Baumwoll-Shirts');
insert into ""."PRODUCT_TEXT_TABLE" values(2,'E', 'Leather jacket');
insert into ""."PRODUCT_TEXT_TABLE" values(2,'D', 'Lederjacke');
insert into ""."PRODUCT_TEXT_TABLE" values(3,'E', 'Trousers and Pants');
insert into ""."PRODUCT_TEXT_TABLE" values(3,'D', 'Hosen und Hosen');
insert into ""."PRODUCT_TEXT_TABLE" values(4,'E', 'Coats and Blazers');
insert into ""."PRODUCT_TEXT_TABLE" values(4,'D', 'Muntel und Jacken');
insert into ""."PRODUCT_TEXT_TABLE" values(5,'E', 'Purse and Handbags');
insert into ""."PRODUCT_TEXT_TABLE" values(5,'D', 'Geldburse und Handtaschen');

Note: The Language code for English is "E" and for German is "D"

2.

Right click on your schema and refresh to see the 2 tables created.

3.

Go to "Content" and right click on your package. Select Calculation view.

4.

Give Name and Description of the Calculation View. Select Data Category as
"Dimension".

5.

Add a "Join" block and add both the tables "PRODUCT" and
"PRODUCT_TEXT_TABLE".

6.

Make a join on the column "PRODUCT_ID". Specify the Join Type as "Text Join".
Click on the Language option and select "Language" column. Add "PRODUCT_ID",
"PRODUCT_NAME" and "PRODUCT_DESCRIPTION" to output.

7.

Connect the Join block to Projection Block. Add all the 3 column to output.

8.

Select the Semantics block. Select the Type of Columns as "Attribute". This might
be selected by default. Save and Activate the view.

9.

Click on the Data Preview to see output of the calculation view.


The output contains only the English Description.

Change User Session Language (Locale) and Check The


Output Again:

1.

Right click on the HANA system and select "Properties".

2.

Click on the tab "Additional Properties" and select the Locale as "German"

Click on "OK".
3.

Check the output of the calculation view. Now the output contains German
Description.

SAP HANA Analytic Privilege


In this article we will explain what is Analytic privilege in HANA and how does it work.

What is Analytic Privileges?


Analytic privileges control access to SAP HANA data models.
Analytic privileges are used to grant different users access to different portions of
data in the same view depending on their business role. It allows us to maintain rowlevel access.

Why do we need Analytic Privilege?


SQL privileges implement authorization at object level only. Users either have access to
an object, such as a table, view or procedure, or they do not.

While this is often sufficient, there are cases when access to data in an object depends
on certain values or combinations of values. Analytic privileges are used in the SAP

HANA database to provide such fine-grained control of which data individual users can
see within the same view.

Example:

Suppose there is a calculation view which contains the sales data of all the regions like
Asia, Europe and America.

The regional managers must have access to the calculation view to see the data.
However, managers should only see the data for their region. The manager of America
region should not be able to see data of other region.

In this case, an analytic privilege could be modeled so that they can all query the view,
but only the data that each user is authorized to see is returned.

Important Facts about Analytic Privileges:

Analytic privileges are intended to control read-only access to SAP HANA


information models, that is

Attribute views

Analytic views

Calculation views

Analytic privileges do not apply to database tables or views modeled on


row-store tables.

Create and Manage Analytic Privilege.


Here is the sequence of steps to achieve this
1.

Create Analytic Privilege and assign restriction for region Asia.

2.

Assign the Analytic Privilege to User to restrict the data on HANA Views.

SAP HANA System Privileges Required to Create/Manage Analytic


Privilege:
To create analytic privileges, the system privilege CREATE STRUCTURED PRIVILEGE
is required.
To drop analytic privileges, the system privilege STRUCTUREDPRIVILEGE ADMIN is
required.

In the SAP HANA modeler, repository objects are technically created by the technical
user _SYS_REPO, which by default has the system privileges for both creating and
dropping analytic privileges.
The database user requires the package privileges REPO.EDIT_NATIVE_OBJECTS
and REPO.ACTIVATE_NATIVE_OBJECTS to activate and redeploy analytic privileges
in the Modeler.

Steps to Create an Analytic Privilege:


Prerequisite:
We need to create the modeling view first which will be used in the Analytic Privilege.
Create a calculation view by following the article Create a calculation view in 10
minutes.
The output of the calculation view is

Let us see how we can restrict the output only for "Asia" region.

1.

Right click on the package and select Analytic Privilege

2.

Specify Name and label for the Analytic Privilege

3.

Select the calculation view and click on Add button. Then click on Finish.

4.

Click on Add button as shown below and select the column


REGION_NAME.

5.

Now we need to assign the restriction. Click on the add button as shown
below and select the value Asia.

6.

Save and activate the analytic privilege.


The analytic privilege is ready. Now we can assign this analytic privilege to any user.

Assign Analytic Privilege to a User:

Note: You must have authorization to create/assign privileges to a user.


1.

Go to Security -> Users. Right click and create a new user. Specify user
name and password.

2.

Click on the Analytic Privileges tab and add the analytic privilege created
in previous step.

3.

You also need to assign following privileges required to get access to


modeling views.

Execute & Select access on _SYS_BI

Execute & Select access on _SYS_BIC

Execute on REPOSITORY_REST
Done!! We have created an analytic privilege and assign that to a user.
Now add the same HANA system using new user. Open the data preview of the same
calculation view. It will show only the data for region Asia.

Variables and Input Parameters in HANA


In this article we learn what are Variables and Input Parameters in HANA and how do
they work.

Variables and Input Parameters in HANA:

Sometimes we need to filter the data based on user's input. This is where Input
Paramters and Variables come into the pictures.
Input parameters and variables are used to filter the result of modeling views.

Let us first see what is Variable and how does it work.

Introduction to variables:
Variables are bound to columns and are used for filtering using WHERE clauses. As
such, they can only contain the values available in the Columns they relate to.

Sounds confusing?? Let us take a simple example.


In the article Create Graphical Calculation View in 10 minutes, we created a calculation
view which has 4 columns PRODUCT_NAME, REGION_NAME, SUB_REGION_NAME
and SALES_AMOUNT.
REGION_NAME contains different regions like America, Asia and Europe. The
calculation view gives all the regions details in output.

Now suppose we want to filter the data on region basis. The calculation view will prompt
the user to specify Region Name and the output data will be filtered based on that.
For example if the user provides the value as Asia, the calculation view will show data
only for Asia region.

How to create and use variables in modeling view:


Now we will see how to implement this using variable.

Note: We will refer to the calculation created in the article Create Graphical Calculation
View in 10 minutes.
1.

Open the calculation view. On Right-Bottom side you will see a pane
called Variables/Input Parameters. Click on the down arrow of + icon and select
Variable

2.

Specify Name of the Variable. Click on the drop down arrow besides
Attribute and select REGION_NAME. Click on ok.

3.

Activate the calculation view. Now click on the data preview.

4.

A pop-up window will appear. Click on Open Value Help besides From
and select Asia region. Click on ok.

5.

Go to Raw Data tab to see complete output. It contains data only for Asia
region.

Important features of variables:

You use variables to filter data at runtime. You assign values to these
variables by entering the value manually, or by selecting it from the drop-down list.

You can also define whether the Variable is Mandatory or if it should have
aDefault Value.

You can apply variables only in analytic and calculation views.

Variable Types:
The following types of Variables are supported:

Single Value: Use this to apply a filter to a Single Value.

Interval: Use this where you want the user to specify a set start and end
to a selected Interval.

Range: Use this when you want the end user to be able to use operators
such as Greater Than or Less Than.

System Tables to see Variable Information:


There are 4 system tables under the schema _SYS_BI which contains information
about Variables.

BIMC_VARIABLE

BIMC_VARIABLE_ASSIGNMENT

BIMC_VARIABLE_VIEW

BIMC_VARIABLE_VALUE

Introduction to Input Parameters:


Sometimes you might not want a variable to just restrict the data of a view. But you also
want to take input from the user and process it, returning dynamic data based on the
user selection.
Input Parameters makes this possible.

How to create and use input parameters in modeling view:


Example Scenario:

Let us consider the same calculation view we created before which has following
attributes and measures.
Attributes: PRODUCT_NAME, REGION_ID, REGION_NAME, SUB_REGION_NAME
Measures: SALES_AMOUNT

Suppose we want the end user to decide whether SALES_AMOUNT or NET_AMOUNT


should be shown in the output.
We can create a input parameter of type Static List which will have 2 values
SalesAmount and NetAmount.

The calculation view will prompt for the input parameter. The user will choose either
SalesAmount or NetAmount. Based on this selection, the output will be shown.

Let us create the input parameter.


1.

Open the same calculation view. On Right-Bottom side you will see a pane
called Variables/Input Parameters. Click on the down arrow of + icon and select
Input Parameter.

2.

Provide Name, description and select the data type as INTEGER.

3.

Select the Aggregation block and right click on Calculated Columns to


create a new column.

4.

Specify the name as NET_AMOUNT, Data Type as double. In the


expression editor provide the expression as
"SALES_AMOUNT" - ( "SALES_AMOUNT" * $$DISCOUNT$$ /100)

Note that we are using Input parameter DISCOUNT by using syntax$$DISCOUNT$$

5.

Activate the calculation view.

6.

Click on data preview. A pop-up window will be opened. Provide the


Region Name as Asia and Discount value as 10.

7.

The NET_AMOUNT will be calculated as per the given DISCOUNT value.

Important Features of Input Parameters:

Input Parameters can contain any value the reporting user has to enter
to parameterize the result. Therefore, a data type must be specified for each Input
Parameter.

Input Parameters are passed by Placeholders and used in Formulas.

Input Parameter Types:


The following types of Input variables are supported.

Currency:
Use this during currency conversion where the end user should specify a source or
target currency.

Date:
Use this to retrieve a date from the end user using a calendar type input box.

Static List:
Use this when the end user should have a set list of values to choose from.

Attribute Value:
When an Input Variable has this type, it serves the same purpose as a normal Variable.

None:
If none of the above applies you do not have to specify an Input Variable type. The Type
can be left blank.

How to Pass Input Parameters and Variables in SQL Query:

Open the data preview of calculation view as mentioned in previous step.


Click on the Show Log and then double click on the message highlighted below. A new
window will be opened which contains the SQL query.

The generated query is:


SELECT TOP 200 "PRODUCT_NAME", "REGION_NAME", "SUB_REGION_NAME",
"NET_AMOUNT", sum("SALES_AMOUNT") AS "SALES_AMOUNT"
FROM "_SYS_BIC"."sap-hana-tutorial/SalesReport"
('PLACEHOLDER' = ('$$DISCOUNT$$', '10'))
WHERE ("REGION_NAME" IN ('Asia') )
GROUP BY "PRODUCT_NAME", "REGION_NAME", "SUB_REGION_NAME", "NET_AMOUNT"

Note that in your case package name might be different and query might be slightly
different.

Input Parameter is passed using PLACEHOLDER:

The value of Input Parameter is passed using PLACEHOLDER clause.


('PLACEHOLDER' = ('$$DISCOUNT$$', '10'))

WHERE:
The value of Variable is passed using WHERE clause.
WHERE ("REGION_NAME" IN ('Asia') )