Вы находитесь на странице: 1из 7

2160391 FAQ: SAP HANA Indexes

SEPTEMBER 17, 2015 BY SAP HANA WIKI0 COMMENTS


1. What are SAP HANA indexes in the context of this SAP Note?
SAP HANA indexes in the context of this SAP Note are data structures on
tables, that can provide efficient table data access and / or guarantee
uniqueness. This index concept is very common for relational databases.
In general the term index in SAP HANA can also mean table or data.
For example, the main SAP HANA process indexserver obviously works on
data in the first place and not on indexes.

2. What is the purpose of indexes in SAP HANA environments?


The main reasons for creating indexes in SAP HANA environments are:

Efficient table data access (see SAP Note 2000002)

Efficient support of unique and primary key constraints

3. Which special aspects and limitations have to be considered with


indexes?
For an efficient index design it is good to know the following aspects and
limitations of indexes:
Scenario

Details

Although the index (and the underlying dictionary) provides


sorted data, it is not possible to retrieve the minimum or the
maximum value directly. Instead the whole data has to be
No support of MIN
scanned to find the minimum / maximum. Main reason for this
and MAX
technical restriction is the fact that two separate data areas
exist (main and delta storage) and so no globally sorted data
set is available.

No support of
ORDER BY

Although the index (and the underlying dictionary) provides


sorted data, it is not possible to support an ORDER BY with an
index. Instead always an explicit sorting needs to be done. Main
reason for this technical restriction is the fact that two separate
data areas exist (main and delta storage) and so no globally
sorted data set is available.

Risk of
performance
regressions with
INVERTED HASH
indexes

Hash collisions or range conditions on index columns can result


in performance regressions when using INVERTED HASH
indexes. See SAP Note 2109355 for more details.

Increased
Due to the fuzzy content of FULLTEXT indexes the memory
memory
requirements can be significantly higher than for normal
requirements of
indexes.
FULLTEXT indexes
Indexes on
For technical reasons indexes on columns with PREFIXED or
PREFIXED and
SPARSE compression may not be used for efficient data access.
SPARSE columns
See SAP Note 2000002 for more information.
may not be used

Implicit indexes
when creating
primary key

When a unique or primary index is created on multiple columns


of a column store table, an (unnamed) implicit single column
index is created on all individual columns. If for example a
primary key is created on columns MANDT, BELNR and POSNR,
implicit single column indexes are created on column MANDT,
on column BELNR and on column POSNR.

4. Where can I find information about existing indexes?


Information about indexes is available in the following SAP HANA tables and
monitoring views:
Table name

Details

FULLTEXT_INDEXES

Fulltext indexes

GEOCODE_INDEXES

Geocode indexes

INDEXES

All existing indexes

INDEX_COLUMNS

Columns of all existing indexes

M_CS_INDEXES

Column store indexes

M_FUZZY_SEARCH_INDEXES

Fuzzy search indexes

M_RS_INDEXES

Row store indexes

The following index related SQL statements are available via SAP
Note 1969700:
SQL statement

Details

SQL: HANA_Indexes_Columns

Index columns

Shows single column indexes


on columns with SPARSE or
SQL:
PREFIXED compression type
HANA_Indexes_ColumnStore_IndexesOnSparseAndPref (which may not provide
xedColumns
performance benefit, see SAP
Note 2000002 for more
information)
Shows redundant single
column indexes (which are
SQL: HANA_Indexes_ColumnStore_RedundantIndexes already implicitly created on
columns of primary key or
unique indexes)

SQL: HANA_Indexes_HashCollisions

Hash collisions of INVERTED


HASH indexes (SAP
Note2109355)

SQL: HANA_Indexes_LargestIndexes

Overview of largest indexes

SQL: HANA_RowStore_TotalIndexSize

Calculation of total row store


index size and comparison
with Pool/RowEngine/CpbTree
heap allocator in order to
detect memory leak

5. What kind of indexes exist in SAP HANA environments?


The following indexes are available in SAP HANA environments:
Store Index type
Row
store

BTREE
[UNIQUE]

Row
store

CPBTREE
[UNIQUE]

Column
FULLTEXT
store
Column INVERTED
store HASH
[UNIQUE]

SAP
Note

Details

Creation command

B*tree index on row store table

CREATE [UNIQUE]
BTREE INDEX ...

21126 B*tree index with compressed prefix CREATE [UNIQUE]


04
on row store table
CPBTREE INDEX ...
Fulltext index

CREATE FULLTEXT
INDEX ...

21093 INVERTED HASH index, more


CREATE [UNIQUE]
55
memory efficient alternative
INVERTED HASH
to INVERTED VALUE indexes
INDEX...
Maps column dictionary value IDs to

row IDs, no B*tree structure

INVERTED VALUE index, standard


column store index that maps value
CREATE [UNIQUE]
IDs of dictionary to row IDs of
INVERTED VALUE
column
INDEX ...
Maps column dictionary value IDs to
row IDs, no B*tree structure

INVERTED
Column
VALUE
store
[UNIQUE]

6. Which general recommendations exist for individually created indexes?


The following general recommendations should be considered when creating
indexes individually:
Recommendation Details

As few indexes as
possible

Every index imposes overhead in terms of space and


performance, so you should create as few indexes as possible.

As small indexes as Specify as few columns as possible in an index, so that the space
possible
overhead is minimized.

Single column indexes in column store have much less space


overhead, because they are implemented as rather small
additional column data structure. Therefore you should use
Prefer single column
single column indexes whenever possible.
indexes in column
Due to the in-memory approach it is typically fine to define an
store
index only on the most selective column in SAP HANA
environments, while on other relational databases often only a
multi-column index provides optimal performance.

7. Are there tools available which automatically suggest useful indexes?


While the individual design of secondary indexes is typically an outcome of
SQL optimization there are already the following general approaches
available to determine useful secondary indexes:
Area

Details

SAP Suite on See SAP Note 1794297 that provides some reports for identifying useful

HANA

indexes.

SAP Bank
Analyzer

See SAP Note 2015986 for general suggestions on index design in Bank
Analyzer environments.

General

$DIR_INSTANCE/exe/python_support/indexAdvisor.py is a Python script


that identifies useful indexes.

8. Which DDL operations can be performed on indexes?


Important DDL operations on indexes are:
Operati
Command
on
Create CREATE ... INDEX "<index_name>" ON "<table_name>" ...
Drop

DROP INDEX "<index_name>"


ALTER INDEX "<index_name>" REBUILD

Rebuild Only relevant for row store, as column store indexes are automatically rebuilt
during delta merge operations.
Rename RENAME INDEX "<index_name>" TO "<new_index_name>"
9. How are indexes stored in column store?
Single-column indexes in column store are rather light-weight data
structures on top of the column structure, so called inverted indexes.
Multi-column indexes in column store are stored as internal columns, so
called CONCAT attributes. See SAP Note 1986747 for more information how
multi-column indexes are stored as internal columns. On a CONCAT attribute
columns also an inverted index is created, just like for columns being used
by a single-column index.
10. Are indexes persisted to disk?
The following overview shows which kind of indexes are persisted to disk:
Store

Index
type

Multi
Column
column
store
indexes

SP
Detail
S
<=
Only maintained in memory, recreated during column load
06

Column specific inverted index structures recreated during load


The following parameter controls if CONCAT attributes are
persisted to disk:
Parameter

Defa
Details
ult

>=
07
attributes.ini -> [global] ->
runtime_structure_persiste true
nce

If set to true CONCAT


attributes are persisted to disk
(increased disk space
requirements, but quicker load
times).
If set to false CONCAT
attributes are not persisted to
disk and recreated during
column load (less disk space
requirements, but slower load
times).
SAP Note1976994 describes a
wrong result set bug with Rev.
70 caused by persisted
indexes.

Single
Column
column
store
indexes

Only maintained in memory, recreated during column load

Row
store

Only maintained in memory, recreated during startup

11. Why do I need single column indexes on column store tables although
the column dictionary is already sorted?
The column dictionary contains the existing column values in a sorted way,
but it doesnt contain the information, in which rows of the table a certain
value exists. This mapping from the dictionary value ID to the related table
row IDs is only available via an index (inverted index). Without index, the
whole column has to be scanned for a specific value.
The following picture illustrates the direct mapping of dictionary value IDs to
table row IDs via an inverted index (right hand side):

12. Where can I see if an indexes is used by a certain SQL statement?


This information is available via PlanViz (see SAP Note 2073964).
Example: (inverted index on column X used for access)

13. Are indexes dedicated storage objects?


On other databases administrators are used to consider indexes as
dedicated storage objects like segments (e.g. DBA_SEGMENTS entries with
SEGMENT_TYPE = INDEX on Oracle). This doesnt apply for SAP HANA. As
already seen above, indexes are extensions to column structures (inverted
indexes) or internal columns (e.g. CONCAT attributes, TREX external key,
see SAP Note1986747), and the allocated space is in the first place purely
linked to the underlying table. Only with specific analysis tools like SQL:
HANA_Tables_LargestTables or SQL: HANA_Indexes_LargestIndexes (SAP
Note1969700) it is possible to understand better how much space is
allocated by index structure.