HANA

SAP HANA 2 Dynamic tiering
Best Practices Guide
© 2018 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP
products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany
and other countries.
Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are
registered trademarks of Crossgate AG in Germany and other
countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials

are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.
www.sap.com
TABLE OF CONTENTS
SCOPE .............................................................................................................................................................. 3
SYSTEM LANDSCAPE..................................................................................................................................... 3
HARDWARE SIZING ........................................................................................................................................ 4
Sizing space for transaction logs .................................................................................................................. 5
Helpful tool to measure I/O throughput ......................................................................................................... 6
Network requirements ..................................................................................................................................... 6
INSTALLATION AND CONFIGURATION ........................................................................................................ 6
Startup Properties ........................................................................................................................................... 7
Balancing CPU and memory resources for a same host deployment ....................................................... 9
Trace and Zrlog Section Properties ............................................................................................................... 9
CREATING EXTENDED STORAGE .............................................................................................................. 10
DATA MODELING .......................................................................................................................................... 10
Key aspects of multistore tables ................................................................................................................. 11
Heterogeneous multistore tables ................................................................................................................. 12
THE DATA LIFECYCLE MANAGER TOOL ................................................................................................... 12
PERFORMANCE ............................................................................................................................................. 13
Load performance ......................................................................................................................................... 13
IMPORT FROM statement .............................................................................................................................. 13
IMPORT FROM statement: delta-enabled extended tables ............................................................................ 14
INSERT...SELECT statement .......................................................................................................................... 14
ALTER TABLE USING EXTENDED STORAGE statement ............................................................................ 14
Parameterized array inserts ............................................................................................................................ 14
Loading data from SAP Landscape Transformation Replication Server (SLT) ............................................... 14
Update ............................................................................................................................................................. 15
Query performance ........................................................................................................................................ 15
Indexes ............................................................................................................................................................ 17
Statistics........................................................................................................................................................... 18
Partition pruning ............................................................................................................................................... 18
Intermediate results caching ............................................................................................................................ 18
Zone maps ....................................................................................................................................................... 19
HIGH AVAILABILITY AND DISASTER RECOVERY .................................................................................... 21
Failover ........................................................................................................................................................... 21
System replication ......................................................................................................................................... 21
Backup and recovery .................................................................................................................................... 21
SECURITY ....................................................................................................................................................... 22
TROUBLESHOOTING .................................................................................................................................... 23
System views ................................................................................................................................................. 23
Tracing ............................................................................................................................................................ 24
Validating the version of the dynamic tiering delivery unit ...................................................................... 25
Setting Alerts in SAP HANA Cockpit ........................................................................................................... 25
Emergency mode dynamic tiering troubleshooting .................................................................................. 25
SUMMARY ...................................................................................................................................................... 27
RESOURCES AND REFERENCES ............................................................................................................... 27
INTRODUCTION
This document describes best practices for setting up and operating SAP HANA 2.0 dynamic
tiering - an add-on option to the SAP HANA database that augments the HANA memory store with
a disk-backed columnar store. SAP HANA dynamic tiering is a cost effective option to scale the
total volume of SAP HANA database systems. The proper use case for dynamic tiering is to offload
the storage and processing of data that has aged, or is otherwise no longer frequently accessed
from SAP HANA memory. Keep any data required for typical business processes in memory for
best performance. You can migrate older data to the cheaper dynamic tiering disk store, with
slower, but still acceptable performance. Dynamic tiering extended storage is an integral part of
the SAP HANA database. Warm/cool data on disk can be queried, updated, and combined with
hot data in HANA memory, all with transactional consistency.
Although dynamic tiering uses columnar database technology similar to SAP HANA, it maintains
data on disk, and has its own sizing and configuration aspects different from a pure SAP HANA in-
memory system. While dynamic tiering is tightly integrated with the SAP HANA database – making
use of the same tooling, backing up its data along with the SAP HANA database, and accessed
only through an SAP HANA client connection – it brings additional system administration
responsibilities. This guide supplements the SAP HANA dynamic tiering user documentation with
advice for proper use and optimization of your dynamic tiering system.
SCOPE
This best practices guide covers sizing, configuration, performance, and troubleshooting aspects of
an SAP HANA system with dynamic tiering. This guide is a living document that will be updated
with successive releases of dynamic tiering. This version is up to date as of SAP HANA dynamic
tiering 2.0 SPS 03, released in April 2018.
SYSTEM LANDSCAPE
The SAP HANA dynamic tiering server is installed in production environments on its own machine:
3
The HANA host and the dynamic tiering hosts must share certain directories on a shared file
system such as NFS (Network File System) or GPFS (General Parallel File System). The
directories include that which contains executable programs and other shared data (default is
/hana/shared) and the data backup area. SAP HANA dynamic tiering uses the same directories for
data and log backups as SAP HANA. HANA and dynamic tiering manage their own data and logs
independently of each other.
You can add dynamic tiering to an existing single-node or a scale out multi-node SAP HANA
system. Currently, dynamic tiering itself does not scale out. However, dynamic tiering is a disk-
backed column store with a memory cache, and a single node on properly sized hardware can
scale up to effectively manage up to about 100TB of compressed data on disk. In a multitenant
database environment, you need a separate dynamic tiering server for each tenant database using
dynamic tiering.
A dynamic tiering server must run on the same operating system as the other SAP HANA servers
within the SAP HANA system. However, the dynamic tiering server does not need to run on SAP
HANA certified hardware. It can run on commodity hardware.
With HANA 2.0, you can now install SAP HANA and dynamic tiering on the same physical machine
for an SAP HANA scale up (single server) system managing a single tenant database. However,
most users install dynamic tiering on its own machine.
Adding dynamic tiering to a HANA appliance (either for dedicated or same host deployments)
immediately changes the appliance into a Tailored Data Center Integration (TDI) setup. This
implies that the hardware remains certified and supported by SAP. You must make some
changes for a dedicated host deployment, such as creating a shared file system and adding a
network interface card for inter-node communication. For a same host deployment, you will need
to add memory for the esserver process, add storage, and perhaps add additional CPU cores.
Adding memory for dynamic tiering does not require additional SAP HANA memory licensing.
Dynamic tiering is supported on virtual machines, if the virtual environment is sized properly
according to the sizing guidelines in this best practices guide. Specifically, the virtual environment
needs to provide the dynamic tiering server with good I/O throughput to the underlying storage.
We have begun to validate the operation of dynamic tiering in public cloud environments. See this
SAP Note for more information about which cloud environments are supported:
https://launchpad.support.sap.com/#/notes/0002555629
HARDWARE SIZING
Dynamic tiering is designed for larger SAP HANA systems – 512GB or larger. For multitenant
database systems, each tenant database should have a corresponding 512GB of SAP HANA
memory allocated for it. You can add dynamic tiering to a smaller SAP HANA system, but all
interaction with dynamic tiering occurs through an SAP HANA connection, and you will need
sufficient SAP HANA memory to accommodate query result sets returned from dynamic tiering.
Many query operations are handled by the dynamic tiering server, which returns reduced result
sets to SAP HANA. When there are functional gaps between SAP HANA and dynamic tiering,
data is pulled from dynamic tiering into SAP HANA memory to perform the processing. An
example of this is predictive analytics (PAL). The predictive analytics engine runs in SAP HANA,
not in the dynamic tiering server. If you execute a PAL function on dynamic tiering data, the data is
4
copied to SAP HANA first. It is critical to test your system with dynamic tiering, and make sure you
have adequate SAP HANA working memory for your particular use case.
With a pure SAP HANA in-memory system, the compute node size is derived from the database
size. With a disk-backed columnar database server such as SAP HANA dynamic tiering, the
compute node size is established based on the workload on the system – primarily data loading
and query tasks. Since the dynamic tiering server manages cool/warm data, activity in it should be
significantly less than that in the SAP HANA server.
For query workload, dynamic tiering needs at minimum 1 – 2 cores per concurrent query. Dynamic
tiering will normally assign 10s-100s of threads per query and can take advantage of all cores on
the machine. As a result, the more cores available to the dynamic tiering server, the better the
query performance. For bulk data loading (the fastest data ingestion method for dynamic tiering),
one CPU core can load approximately 10 - 20MB of data per second. After estimating your data
loading needs and the number of concurrent users querying the system, calculate the required
number of CPU cores for the dynamic tiering server. Estimate you need 16GB of RAM per core.
Now you can determine the storage size required by the dynamic tiering store. The dynamic
tiering store is composed of 4 dbspaces. A dbspace is a logical container of physical files to store
specific kinds of data. You add space by creating a physical file assigned to the dbspace:
• ES_USER: contains user data, composed of SAP HANA extended and multistore table
data and indexes. Dynamic tiering has similar data compression characteristics to SAP
HANA.
• ES_DELTA (optional): contains the write ahead transaction log for the dynamic tiering row
level versioned (RLV) delta store. This dbspace is required to use delta enabled extended
or multistore tables (tables that can accept concurrent writes). Size this dbspace at 16GB
* the number of CPU cores on the dynamic tiering machine.
• ES_TEMP: contains data and indexes for temporary tables. It also contains generated
temporary data from sort operations, and intermediate result sets. Size this dbspace at
10% of the size of ( ES_USER + ES_DELTA ).
• ES_SYSTEM: contains data used by dynamic tiering to manage extended storage:
database catalogue, metadata for managing database space, versioning metadata, and
transaction control information. Size this dbspace at 10% of the size of ES_USER.
For dynamic tiering to perform at capacity without blocking on I/O to the disk subsystem, ensure
that the storage can provide at least 50MB / sec / core of throughput. For faster cores, you can
increase this to 100MB / sec / core. If possible, partition the storage drives (SSD drives are the
best and least expensive choice for disk storage) among the dynamic tiering dbspaces, so that
storage for the dbspaces do not overlap each other. For example, ES_USER and ES_TEMP
should use different storage devices. Dynamic tiering stripes data across all files in a dbspace for
better I/O performance. If possible, create at least 8 files for ES_USER, and the same for
ES_TEMP, and spread them across the SSD drives assigned to the dbspace.
Sizing space for transaction logs
The dynamic tiering store requires space for transaction logs. Log space is related to incoming
data and updates. The logs are compressed like the dynamic tiering store. The transaction log is
truncated only on log backup, when a new log file is opened and the older one is moved to backup
storage. Log backups accrue until a new full or delta backup is created.
5
If you plan to use HANA system replication, note that the primary site retains logs until they are
completely replicated on the secondary site. Log buildup can occur on the primary site if there is a
slow network connection between the primary and secondary sites, or if the secondary site is
unreachable for a period of time. Provide extra space for logs to address this type of situation.
As a starting point, allocate 10x the volume of maximum daily changes to the dynamic tiering store
for log space.
With SP03, dynamic tiering now supports SAP HANA’s “log_mode = overwrite”. Here, transaction
logs are not maintained after data is committed, and are not backed up. This mode is useful for
development or test systems that don’t require point-in-time-recovery of a database backup. If you
set this mode (recommended only for development and test systems), then you do not need to
maintain a large space for log files as described above.
Helpful tool to measure I/O throughput
Use this tool to help you measure I/O throughput to disk storage. It is free, and supports many OS
platforms:
http://freecode.com/projects/fio
You can find documentation for this tool here:

http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark
Network requirements
For a dedicated host deployment, SAP recommends that you set up a minimum of a 10GBit / sec
dedicated network between SAP HANA and the dynamic tiering server. If you plan to use system
replication to a secondary site for high availability, you also need a high-speed network connection
between the primary and secondary sites.
Note that as machines get larger with more memory and CPU cores, and can support heavier
workloads and more concurrent users, you will want to consider enlarging the network capacity
between HANA servers and the dynamic tiering server. HANA and dynamic tiering converse with
each other over the network as queries are being executed on the dynamic tiering server, and
operations such as INSERT…SELECT to insert data into dynamic tiering from a HANA column
table in memory will pass data over the network.
INSTALLATION AND CONFIGURATION
After you complete installation and verify that the dynamic tiering server is running, you should
configure the dynamic tiering server with adequate cache sizes, and other settings. The settings
are stored in a configuration file called esserver.ini, which you can edit using either HANA Studio or
HANA Cockpit.
The configuration file in HANA Studio appears like the following:
6
Use the following table as guidance for configuring parameters that might require adjustment.
Some parameters, such as num_partition_buffer_cache and num_threads, have reasonable
default settings that you should only change when advised by SAP support:
Startup Properties
Name Description Recommended setting
catalog_cache Amount of memory In most environments, the catalog cache
initially reserved for should be sized at 2 to 8 times the size of the
caching the dynamic catalog file. The catalog file contains
tiering catalog. metadata for extended tables. The file has the
name <SID>ESDB.db, and can be found in a
subdirectory rooted at /hana/data_es/<SID>.
7
checkpoint_interval Maximum interval The recommendation is to start with 60

between checkpoints. minutes (default). Larger checkpoint intervals
reduce the frequency of checkpoints at the
expense of a longer database recovery time if
the database is shut down and restarted.
delta_memory_mb Amount of memory Size this cache large enough to keep data in
available to store memory that is being loaded and changed
delta-enabled prior to being merged with the main store data
extended and on disk. This amount will vary depending on
multistore tables. the number of tables, load frequency, and
merge frequency with the main store on disk.
A good starting point for most systems is 250
– 500MB for each delta-enabled extended or
multistore table. This allows an adequate
safety margin if load frequencies spike on all
objects simultaneously.
heap_memory_mb Amount of heap Calculate 85% of the total memory on the
memory that dynamic dynamic tiering server machine, subtract the
tiering can use. 0 amount of memory you need for RLV memory
means no limit on (delta_memory_mb) and catalog cache
heap memory. (catalog_cache), and then divide the
remaining memory as follows:
• load_memory_mb: 25%
• heap_memory_mb: 25%
• main_cache_mb: 25%
• temporary_cache_mb: 25%
load_memory_mb Maximum amount of (See heap_memory_mb above.)
memory extended
storage can request
from the operating
system for temporary
use.
main_cache_mb Amount of memory for (See heap_memory_mb above.)
caching dynamic
tiering database
objects.
temporary_cache_mb Amount of memory for (See heap_memory_mb above.)
temporary objects
during dynamic tiering
operations.
8
max_concurrent_conn Maximum number of Set this to a realistic value based on your use
ections concurrent case.
connections that the
dynamic tiering
service accepts.
max_concurrent_queri Maximum number of Set this to 1.5 * the value of
es concurrent queries max_concurrent_connections
allowed by the
dynamic tiering
server.
Balancing CPU and memory resources for a same host deployment

If you deploy SAP HANA and dynamic tiering on the same physical machine, divide up memory
and CPU resources between the two. Set the following configuration parameters in esserver.ini to
limit memory usage by dynamic tiering:
• delta_memory_mb
• load_memory_mb
• main_cache_mb
• temporary_cache_mb
• catalog_cache
• heap_memory_mb
To limit usage of CPU cores by dynamic tiering, set the following esserver.ini parameters:
• max_concurrent_connections
• max_concurrent_queries
• num_threads
The above parameter settings limits CPU usage by the esserver process, but do not confine the
process to a particular set of cores. To do that, use the Linux numactl command to bind cores to
the esserver process. Refer to the Linux man pages about numactl. Run the following command
from a Linux command window to display information about the machine’s CPU cores:
numactl --hardware
Edit the executable and arguments values of the esserver portion of the daemon.ini configuration
file to look similar to the following. Try to choose cores that are physically near each other:
[esserver]
executable=numactl
arguments=--cpunodebind=6,7 --membind=6,7 hdbesserver -n
es$(SAPSYSTEMNAME)$(SAPSYSTEM) -x tcpip{port=3$(SAPSYSTEM)12} -hes -
iqnumbercpus 40
Trace and Zrlog Section Properties

For these properties, see the Tracing section in this document.
9
CREATING EXTENDED STORAGE

Once installation and configuration of dynamic tiering settings is complete, the final step before
beginning to use SAP HANA dynamic tiering is to create extended storage.
By default, only one process at a time can write to an extended table or the dynamic tiering portion
of a multistore table. If you anticipate that your dynamic tiering tables will require multiple
concurrent writers, create your extended storage with the ENABLE DELTA parameter.
The delta store is optimized for concurrent writes, and provides row level locking instead of the
standard table level locking for plain extended tables. It is important to understand the use case of
the dynamic tiering delta store. It is not intended to give dynamic tiering the same performance as
SAP HANA with respect to OLTP style loading. The delta store is intended for row level
commands such as INSERT VALUES. These commands are faster when delta is enabled.
However, if your intent is to optimize load speed, better performance is achieved with the IMPORT
command and a non-delta enabled extended or multistore table.
When you create extended storage with a delta store, an additional dbspace (ES_DELTA) is
created. This dbspace contains the write-ahead transaction log for the delta store. Ensure you
create the file(s) for this dbspace on fast storage.
DATA MODELING
It is the responsibility of any application using dynamic tiering to decide how to separate data
between SAP HANA memory and the dynamic tiering store. The data separation should match the
application workload: anything that is required for typical business processes should be maintained
in memory. When data reaches a certain level of inactivity, it becomes a candidate for migration to
dynamic tiering, where performance of data access does not match SAP HANA, but is still
acceptable for applications’ SLAs. A useful system view is the
M_TABLE_PARTITION_STATISTICS view, which shows you how often a HANA column table
partition has been selected. Partitions that are accessed infrequently are candidates for migrating
to dynamic tiering.
You can create two types of tables that host part or all of their data in the dynamic tiering store:
1. Extended table: an extended table is an SAP HANA column table, where the table
definition resides in the HANA catalog, but all of the data in the table is stored in dynamic
tiering.
2. Multistore table: a multi-partitioned SAP HANA column table, where at least one partition
resides in default storage (SAP HANA memory), and one partition resides in extended
storage (dynamic tiering).
Extended and multistore tables are first class database objects – part of the SAP HANA catalog,
and able to be used in SQL and calculation views.
Unlike multistore tables, extended tables are not partitioned. This does not necessarily affect
query performance. The dynamic tiering query engine automatically partitions tables into row
ranges when executing queries, in order to parallelize processing and scale up on machines with
many CPU cores. Users will often prefer multistore tables over extended tables for their modelling
simplicity, but if you have a situation where all data in a table always resides in dynamic tiering,
extended tables may be useful to you.
10
SAP HANA advanced capabilities like text search and analytics, series data, and graph are not
supported with extended tables, or on the dynamic tiering partitions of multistore tables. If you use
an Application Function Library (AFL) function on data residing in dynamic tiering, the data is
pulled into SAP HANA for processing in memory.
There are a number of SQL language and data type differences between extended and multistore
tables and pure HANA column tables. These differences are being resolved over time, and are
described in the Administration Guide of the SAP HANA Dynamic tiering user documentation.
Key aspects of multistore tables
A multistore table is a multi-partitioned SAP HANA column table with at least one partition in SAP
HANA memory, and one partition in dynamic tiering extended storage. Multistore tables support
range, hash-range, and range-range partitioning. With two-level partitioning (hash-range and
range-range), the first level partitions reside in SAP HANA memory, and the second level of
partitions reside in HANA memory and dynamic tiering. When data is written into a multistore
table, it is automatically inserted into the proper store based on the partitioning scheme. You can
add partitions, move partitions between stores, merge, split, and drop partitions.
Multistore tables also support time selection partitioning, where you specify a partitioning column in
the table of type NVARCHAR(8). The NVARCHAR(8) column is meant to hold a date value in the
format ‘YYYYMMDD’. The time selection partitioning column does not need to be a prefix of the
primary key.
With a two-level partitioned table, the partitioning column of the top partition (hash of hash/range,
or first range of range/range) must be a prefix of the primary key, and those partitions reside in
memory. The second level of partitions reside in either HANA memory or dynamic tiering. Here is
an example of a hash-range multistore table:
You may not specify a foreign key on a multistore table. Also, uniqueness is not enforced on the
extended store side of the multistore table, or across stores. For example, it is possible to create a
row in the extended store with the same primary key as a row in the column store. Lack of
uniqueness checking for multistore tables might seem like a shortcoming. However, if you
consider the use of multistore tables for older data, data will normally be inserted into a HANA
11
memory partition first, where uniqueness checks are always done. Then data is aged out later,
when it should not be necessary to perform an additional uniqueness check in extended storage.
Because dynamic tiering is positioned as a “warm store”, you can update rows of an extended or
multistore table, and those rows will be updated, regardless of whether the rows reside in the
memory store or the dynamic tiering store. However, for good performance, it is recommended to
perform DML (INSERT and UPDATE) operations on data in the HANA memory partitions, and then
occasionally migrate the data to extended storage by using the ALTER TABLE…ALTER
PARTITION SQL command to move an entire partition from memory to disk. Dynamic tiering
operates best with bulk operations that operate on many rows at the same time.
Heterogeneous multistore tables
With SP03, HANA dynamic tiering supports an additional, flexible partitioning scheme for multistore
tables. This is called a heterogeneous multistore table. This partitioning scheme is designed for
tables with an unbalanced distribution of data, where you may end up with empty data partitions
with the traditional range, range-range, or hash-range partitioning approach. (SAP HANA allows
only 16000 partitions in a table, so you don’t want to waste partitions on empty contents, if you
have a large table with many partitions.) Heterogeneous multistore tables allow you to partition
data by range on one column value, and partition by subrange on another column value. Each
partition can have a different set of sub-partitions. The following picture shows you an example of
the benefits of heterogeneous partitioning:
THE DATA LIFECYCLE MANAGER TOOL

Once you have settled on how you want to split data between memory and disk, you can either
build your own SQL commands to move the data from SAP HANA memory to dynamic tiering, or
you can use SAP’s DLM (Data Lifecycle Manager) tool to automate this work for you.
12
DLM is part of the SAP Data Warehousing Foundation. It is a graphical interface that lets you
model migration rules on tables to move less frequently accessed data to alternate storage tiers,
such as dynamic tiering:
The DLM tool creates stored procedures to perform mass data movement between the memory
and dynamic tiering stores, and lets you schedule those procedures for automatic execution.
You can find the user documentation for the DLM tool here:
http://help.sap.com/hana_options_dwf
PERFORMANCE
This chapter offers advice on optimizing the performance of data loading and data queries.
Load performance
SAP HANA dynamic tiering supports multiple methods of loading data into an extended or
multistore table. As a general rule, dynamic tiering performs best with bulk writes. Although
supported, singleton writes are not optimized for dynamic tiering. This section explores the various
mechanisms for inserting data into extended tables.
IMPORT FROM statement
This is the fastest method for loading external data. The IMPORT command loads data from a
comma separated values (CSV) file into an extended table or a multistore table. The IMPORT
command also supports binary formatted files. The SAP HANA engine delegates the IMPORT
13
statement directly to the dynamic tiering node for execution, and is converted into an internal
dynamic tiering LOAD TABLE statement. If loading a large number of rows, best performance by
breaking the input into multiple files. Make sure you place the data files in a shared directory
accessible by both the SAP HANA and dynamic tiering servers. For good performance, the shared
directory should be local to the dynamic tiering server, to allow a server side LOAD TABLE
statement.
IMPORT FROM statement: delta-enabled extended tables
If importing data into a delta-enabled extended table, you can run multiple import statements in
parallel. This puts heavy demand on the DELTA store. Make sure you have allocated enough
DELTA memory to hold a transaction’s worth of data for each concurrent IMPORT. Merging the
imported data from the DELTA store to the full table also has performance overhead.
INSERT...SELECT statement
If the data being inserted into an extended table exists in another SAP HANA table, then
INSERT…SELECT might be a better option than IMPORT, which requires the input data to be
present in a file on disk. The optimizer relocates the INSERT…SELECT statement to the dynamic
tiering node. To speed up the operation, the dynamic tiering node then does a parallel fetch from
SAP HANA.
ALTER TABLE USING EXTENDED STORAGE statement
ALTER TABLE USING EXTENDED STORAGE is a SQL command that converts an SAP HANA
in-memory table to an extended table, and moves all the data over to the extended store. ALTER
TABLE NOT USING EXTENDED STORAGE does the reverse – converts an extended table to an
SAP HANA in-memory column table, and moves the data back to SAP HANA memory. In the
past, moving data from dynamic tiering to SAP HANA was much slower than the reverse. With
SP03, performance has been improved by using a more efficient format, called a compressed
ITAB, to transfer the data.
With a multistore table, the ALTER TABLE command is used with the ALTER PARTITION clause
to move a partition of data between the default store and the extended store.
Parameterized array inserts
A parameterized array insert is another optimized method for inserting data into an extended or
multistore table. Parameterized array inserts are performed at the API level. For example, if the
application is using ODBC or JDBC to insert large amounts of data into an extended or multistore
table, then the application likely uses the “wide insert” or “array insert” support that these APIs
provide. In this case, the application prepares an insert statement with parameter placeholders,
and then builds arrays of values to insert a large number of rows in a single execution. With
dynamic tiering, SAP HANA creates a compressed ITAB, and the data is pulled in parallel from
HANA to dynamic tiering to perform the insert.
Loading data from SAP Landscape Transformation Replication Server (SLT)
You may use SLT to load data into an extended or multistore table. It is recommended that SLT
primarily write to an in-memory partition of a multistore table, since write operations to dynamic
tiering partitions are slower than write operations to in-memory partitions. Aging of data within a
multistore table is best accomplished by altering the table to move an entire partition from default
store to extended store.
Dynamic tiering does not currently support triggers. Therefore, a dynamic tiering table or partition
can only be the target of an SLT operation, not a source.
14
Update
An UPDATE statement against the extended store is a slow operation. If updating a lot of rows,
execute a DELETE statement on the pertinent set of rows, then EXPORT the SAP HANA data to
be loaded into dynamic tiering, and finally use the IMPORT statement to load the data.
In SP03, there is an optimization of the UPDATE statement, when you are using UPDATE on a
partitioning column of a multistore table to move a set of rows from HANA memory to dynamic
tiering. In this case, HANA creates an ITAB (internal table) with the data to be moved from HANA
to dynamic tiering. Dynamic tiering then pulls the data in parallel from HANA to dynamic tiering
and inserts the data into the extended store.
Query performance
Queries involving both SAP HANA tables and multistore or extended tables are decomposed into
fragments, and the fragments are either executed in SAP HANA memory by pulling over data from
dynamic tiering, or are relocated to dynamic tiering, where dynamic tiering pulls the data from the
SAP HANA in-memory store. Generally, since dynamic tiering usually manages tables with large
amounts of data, the query optimizer often chooses the latter strategy. The query optimizer is not
going to be able to make good decisions, however, unless you create statistics on extended and
multistore tables. See the statistics section below for a discussion on this topic.
If you have a query accessing both SAP HANA in-memory and dynamic tiering data, and it is
exhibiting poor performance, then the first diagnostic step is to review the query plan. The visual
query plan displays timings for the various subtrees of the query – both those that run in the SAP
HANA in-memory engine and those that run in dynamic tiering. The SAP HANA Dynamic Tiering
Administration Guide describes query plans for troubleshooting queries.
As shown in this HANA Studio screenshot, “Explain Plan” displays the general processing steps for
the query, but it is not accurate, because the query optimizer will not know the complete query plan
pre-execution. You need to choose “Visualize Plan…Execute” to display the actual query plan:
15
The query plan shows the various operators involved in the query execution. The Remote Row
Scan operator is associated with the query fragment that is executed by the dynamic tiering node:
You can also run a SELECT statement against the SAP HANA system view
M_REMOTE_STATEMENTS to view results for the timing of query fragments that were executed
in dynamic tiering.
With SP03, there are some new and improved system views that will help you diagnose poor query
performance:
• M_ES_EXPENSIVE_STATEMENTS: provides information about time spent during
statement executions in dynamic tiering. This view is a union of the
M_EXPENSIVE_STATEMENTS and M_REMOTE_STATEMENTS views.
16
o You will need to configure expensive statement tracing in the [expensive_statement]

section of the global.ini configuration file to get this view to populate
• M_TABLE_PRUNING_STATISTICS: provides insight into how well partition pruning is
working for queries on multistore tables. This information is also collected only when
expensive statement tracing is turned on.
If you want additional insight into how data is split between memory and disk in a multistore table,
check out the M_TABLE_PARTITIONS view which will tell you for each partition, whether it is in
memory or disk, and how many bytes it consumes.
When HANA is executing a query that includes dynamic tiering data, the default query execution
strategy is auto, meaning that the optimizer chooses the strategy for executing the query – whether
to relocate the query to dynamic tiering, or to execute parts of the query in SAP HANA, and parts in
dynamic tiering. In most cases, the auto strategy results in the best query performance.
However, there are cases where relocating the query to dynamic tiering yields better performance.
If the auto mode doesn’t yield the best plan, you can execute the following SQL to set the
configuration parameter to force the query to execute completely on the dynamic tiering server:
-- make sure that you clean up the query plan cache

alter system clear sql plan cache;
-- alter the execution strategy to remote - this will try to relocate the query but it
is still subject to dynamic tiering's capabilities
-- the default is 'auto' and should in most cases be quite performant
alter system alter configuration ('esserver.ini', 'SYSTEM') SET ('row_engine',
'execution_strategies') = 'remote' with reconfigure;
Be careful with this setting, however, because it will affect all dynamic tiering queries.
If poor query performance continues, there may be a capability issue. The query optimizer decides
what to ship to dynamic tiering, based on the capabilities supported by dynamic tiering. Although
the gap is being closed over successive releases of dynamic tiering, there are still some
differences. If the query includes an operator that dynamic tiering does not understand, it lets SAP
HANA’s execution engine compensate for it.
With SP03, there is a new feature that adds information about missing capabilities into the
EXPLAIN plan. Here is a SQL example (with the key parts of the syntax), that shows that the
SINH function is not supported in dynamic tiering, and will be executed in HANA:
EXPLAIN PLAN … FOR SELECT * from DT_TABLE where SINH(customer_id) > 0;
SELECT OPERATOR_DETAILS from EXPLAIN_PLAN_TABLE…
Result:
SELECT...FROM DT_TABLE WHERE SINH(customer_id) [Local Compensation] SINH
Indexes
Extended and multistore tables require indexes to achieve good query performance. Make sure
you create primary keys on your tables, and create a b-tree index on each column within a
multicolumn primary key. Sometimes helpful, but not always needed is a b-tree index on a
commonly used predicated column or grouping columns.
17
However, don’t overdo creating indexes until you evaluate query behavior. Indexes on large fact
tables may actually degrade performance.
Statistics
Statistics help the query optimizer select the right query plan. When no statistics for an extended
or multistore table are present, the query optimizer does not know the distribution and count of
rows in extended storage, and the chosen query plan may not be optimal. It is recommended you
create statistics on extended tables and the extended partitions of multistore tables. At the very
least, it is recommended that you create statistics on the key columns and commonly used
columns of multistore and extended tables.
With SAP HANA 2.0, the CREATE STATISTICS command has a new clause that specifies the
refresh strategy – AUTO or MANUAL. AUTO means that the data statistics object is refreshed
automatically when underlying data changes. MANUAL indicates that the database statistics
object is not refreshed until explicitly requested by a REFRESH STATISTICS command. If you are
using a MANUAL refresh strategy, you should update the statistics after data loads or significant
migrations of data between SAP HANA in-memory and dynamic tiering.
There is also a new feature in SP03, which will cause statistics that you created with the CREATE
STATISTICS command to be automatically updated, whenever an ALTER TABLE statement is
used to move data from HANA to dynamic tiering, or the reverse. Use the following options to
configure this:
“indexserver.ini”, “datastatistics”, “dev_autocreate_es_datastatistics” =
true/false
“indexserver.ini”, “datastatistics”, “dstat_autocreate_es_topk_on_alter”
= true/false
“esserver.ini”, “database”, “stats_refresh” = true/false.
Partition pruning
A multistore table is partitioned based on a partitioning key - a column in the table. When a SQL
query is executed against the table, and the WHERE clause of the SELECT statement contains the
partitioning key of the table, the HANA query engine will automatically prune out partitions that do
not satisfy the WHERE clause. For example, if you query data in hot partitions only, as specified in
the WHERE clause, then HANA will not access dynamic tiering at all.
With time-selection multistore tables, HANA can also perform dynamic partition pruning on non-
partition-key columns. You need to CREATE STATISTICS with the VALID FOR DATA
DEPENDENCY clause on any column you might include in a SELECT statement WHERE clause
that does not also include the partitioning key. For example, you might have a sales order table
with time selection partitioning on a date field, and older partitions residing in dynamic tiering. You
might also have a geographic region field in the table, and want to execute a query on all sales
orders for a specific region. By creating statistics on the region column, the query optimizer will be
able to prune out partitions that don’t include data for the region you are interested in.
Intermediate results caching
Intermediate results caching is a feature that improves dynamic tiering query performance for
cross-store join operations. It allows the dynamic tiering server to cache portions of SAP HANA in-
memory tables on the dynamic tiering side. This results in less traffic over the network for queries
that join the same SAP HANA and dynamic tiering data multiple times.
18
With intermediate results caching, dynamic tiering can now cache HANA column table data on the
dynamic tiering side of the SAP HANA database. This improves performance of repetitive queries
that join SAP HANA memory and dynamic tiering data. You will be able to see whether the
intermediate results cache was used for a query in the graphical executed query plan.
The intermediate results caching feature maintains cache coherence, and invalidates the cache on
the dynamic tiering side if the corresponding data is changed on the SAP HANA memory side.
There are two quota settings that must be adjusted to tune cache size and use:
• result_cache_temp_pct (default 20): sets the max size of cached results as a percent of the
temp cache size (temporary_cache_mb). Generally should be less than 100% so that
results are not paged out to dynamic tiering’s temp store (ES_TEMP). 0 deactivates this
feature.
• result_cache_max_result_pct (default 10): prevents large tables that won’t fit in the result
cache from displacing smaller ones.
Edit the esserver.ini file to add these new parameters to the dynamic tiering server configuration. If
the parameters are not visible in SAP HANA Studio, use the Configure Dynamic Tiering link within
the Dynamic Tiering Links category in SAP HANA Cockpit:
Zone maps
Zone maps are a new feature in SP03. Zone maps can improve range type queries (=, <, >, !=,
BETWEEN, NOT BETWEEN) on data in dynamic tiering. They are most effective if the values in a
column are arranged in sequential order (you inserted them into dynamic tiering in DATE order, for
example). But zone maps can be useful for certain queries, even if the data is not ordered in the
database pages. Each database page in a columnar store like dynamic tiering contains the values
for a specific column of a database table. The dynamic tiering query engine creates maps of the
minimum and maximum values of every database page:
19
Zone maps are automatically created when you add a new column to an extended or multistore
table. Tables already existing before you begin using SP03 will not have zone maps, but you can
create then with the ES_REBUILD_INDEX SQL command. There is a stored procedure called
sp_iqzonemapenable which will tell you which columns are missing zone maps.
The detailed query plans for dynamic tiering contain information about whether a zone map was
used to optimize a query. In the example below, 8808 zones out of 8811 were eliminated during
query processing, and the corresponding data pages were not accessed:
20
HIGH AVAILABILITY AND DISASTER RECOVERY

There are several high availability (HA) and disaster recovery (DR) capabilities provided by SAP
HANA dynamic tiering.
Failover
For high availability of the dynamic tiering server, set up a failover server. If the active dynamic
tiering server becomes unresponsive, the SAP HANA server automatically executes a failover
operation to the dynamic tiering standby server.
System replication
An additional high availability capability is system replication to an alternate site. Dynamic tiering
supports two-tier synchronous and asynchronous, as well as three-tier SAP HANA system
replication. When dynamic tiering is configured with a delta store, however, only two-tier
synchronous replication is supported.
For high availability, you can configure a secondary SAP HANA with dynamic tiering system at a
remote location, and data is replicated to it from both the SAP HANA in-memory and dynamic
tiering stores. The secondary system is passive until a takeover occurs. Active/active is supported
with a HANA dynamic tiering system. However, dynamic tiering data is excluded from queries on
the secondary system. Essentially, dynamic tiering does not interfere with active-active, but does
not fully participate.
See this SAP Note for details of system replication support in HANA dynamic tiering: 2447994 -
SAP HANA Dynamic Tiering Support for SAP HANA System Replication.
Backup and recovery
For data safeguarding, dynamic tiering offers both data and log backups. When you execute a
backup command, both the SAP HANA in-memory store and the dynamic tiering store are backed
up as a single unit. You cannot back up the dynamic tiering store independent of the SAP HANA
memory store. The two stores are integral components of the same database. Full data and delta
21
backups are supported. Dynamic tiering also supports the BACKINT interface to interface with
third party backup tools. There are two improvements to BACKINT with the SP03 release:
• Dynamic tiering can now use multiple backup and restore channels for BACKINT (global.ini
configuration parameter: parallel_data_backup_backint_channels)
• Dynamic tiering now processes streamed logs directly from the third-party backup agent,
and does not materialize the data to disk first. This saves storage space, and time as well,
when performing a BACKINT based database restore.
A full data backup of the extended store has the same size as the compressed data in the
extended store. There is no direct mechanism for determining this size, but there is a heuristic that
provides a reasonable estimate. Run the following SQL command (the 1.1 factor accounts for the
catalog and some other data structures):
1.1 * ( SELECT SUM ( USAGE * TOTAL_SIZE /100 ) FROM M_ES_DBSPACES
WHERE DBSPACE_NAME <> 'ES_TEMP' )
With point in time recovery (PITR), there are additional storage requirements for the log backups.
The PITR log is compressed just like the dynamic tiering store, and the compression ratio depends
on the data types, cardinality, etc. of the changed data in the dynamic tiering store. For example, if
data is compressed to 50% of its raw size, 100GB of incoming data requires 50GB of log backup
space. If the data is being ingested through delta enabled extended tables, then the space
requirement for the logs is doubled to 100GB.
Logs will build up in dynamic tiering’s log directory until a log backup occurs. Then the logs are
removed, and logging continues with additional available space. For dynamic tiering, there is a
parameter es_log_backup_interval, which governs how frequently dynamic tiering log backups
occur. Setting a value of 0 means that backups won’t happen at all. However, logging still occurs
and continues to fill the log space for dynamic tiering. You should set es_log_backup_interval to a
reasonable value to ensure that log backups occur regularly and log space does not fill up. If you
are generally running out of disk space, and don’t require point-in-time-recovery, you can set
log_mode = overwrite to prevent logs from building up on disk.
At this time, SAP HANA dynamic tiering does not support storage snapshots.
For additional information about SAP HANA dynamic tiering backup, see this SAP Note: 2375865 -
SAP HANA Dynamic Tiering 2.0: Backup and Restore Functional Restrictions.
SECURITY
SAP HANA dynamic tiering supports encryption of the dynamic tiering store. Dynamic tiering uses
the same data volume encryption root key as SAP HANA. The SAP HANA and dynamic tiering
stores each have their own database page encryption keys. PITR is not possible when doing a
recovery to a dynamic tiering system with a different encryption state from the source system.
If you add dynamic tiering to an encrypted SAP HANA database, the dynamic tiering store is
automatically created in encrypted format. To change the encryption state of a HANA dynamic
tiering system, perform the following steps:
1. Perform a FULL DATA BACKUP
2. Drop extended storage
22
3. Change the encryption state of SAP HANA with the SQL command: ALTER SYSTEM
PERSISTENCE ENCRYPTION ON
4. (Optional) Create a new root encryption key with the SQL command: ALTER SYSTEM
PERSISTENCE ENCRYPTION CREATE NEW ROOT KEY
5. Recover the full data backup
With SP03, dynamic tiering can now create encrypted full data backups, just like HANA. However,
delta and log backups have the encryption state of the dynamic tiering data volumes. For
example, you cannot encrypt dynamic tiering’s delta and log backups for an unencrypted HANA
database.
If you are not encrypting your HANA database, and don’t expect to soon, there is a new BACKUP
command setting that will speed up dynamic tiering backups.
BACKUP DATA…DISABLE ES ENCRYPTION CHANGE
With the DISABLE ES ENCRYPTION CHANGE clause, dynamic tiering data backs up data in a
streamlined manner that will not allow the backup to be used to later change the encryption state of
the HANA database. If you change your mind, and decide to encrypt your database, you can take
another backup without the clause, and then restore that backup. The M_BACKUP_CATALOG
system view has a new column to tell you whether a dynamic tiering backup was performed with
the DISABLE ES ENCRYPTION CHANGE option.
TROUBLESHOOTING
This section describes a number of techniques to help you troubleshoot problems.
System views
There are many system views that give you visibility into HANA dynamic tiering configuration and
activity:
• M_ES_CONNECTIONS: processes running in dynamic tiering
• M_ES_DBSPACE_FILES: information about all dbspace files in extended storage
• M_ES_DBSPACES: shows dbspaces configured in extended storage
• M_ES_DELTA_MEMORY: delta memory utilization in dynamic tiering
• M_ES_DELTA_MERGE_STATISTICS: merge operations for delta enabled extended and
multistore tables
• M_ES_EXPENSIVE_STATEMENTS: duration time and number of records returned for a
SQL statement executed against dynamic tiering
• M_ES_LOCKS: table locks held in dynamic tiering
• M_ES_OVERVIEW: information about configuration of dynamic tiering server
• M_ES_TABLES: information about all extended and multistore tables, such as table size,
record count, and last modified time
• M_ES_TRANSACTIONS: active dynamic tiering transactions
• M_TABLE_PRUNING_STATISTICS: Shows pruning effectiveness of queries against
multistore tables
23
• M_REMOTE_STATEMENTS: gives details on SQL statements executed by dynamic

tiering, such as number of fetched statements, and start and end time. With SP03,
M_REMOTE_STATEMENTS introduces a new column: STATEMENT_ID.
M_REMOTE_STATEMENTS can be joined on STATEMENT_ID with other monitoring
views such as M_PREPARED_STATEMENTS.
Tracing
SAP HANA and dynamic tiering each log information to various trace files. You can locate the
trace files in HANA Studio under Administration / Diagnosis Files. The trace file for dynamic tiering
is the esserver trace file. The format of the name of the file is esserver_<hostname>.3xx12.*.trc,
where xx is the SAP HANA instance number. The indexserver and nameserver trace files may
also provide information related to dynamic tiering. You can set the maximum size of the files, and
also record SQL being executed by dynamic tiering in the esserver.ini file. Change statement_type
= SQL in esserver.ini:
Another good diagnostic approach is to turn on federation trace. Federation trace generates
tracing information in the indexserver trace file and gives you visibility into most issues with
dynamic tiering. The following SQL commands enable federation tracing:
alter system alter configuration ('indexserver.ini', 'SYSTEM') SET ('trace',
'fedtrace') = 'debug' with reconfigure;
alter system alter configuration ('indexserver.ini', 'SYSTEM') SET ('trace',
'federationexecution') = 'debug' with reconfigure;
Setting fedtrace to debug generates a very detailed dynamic tiering query plan, along with html
query plans with significant internal detail of the dynamic tiering portions of the query.
To turn on .html query plans, execute the following SQL:
ALTER SYSTEM ALTER CONFIGURATION ('esserver.ini', 'SYSTEM') SET ('database',
‘query_plan_after_run') = ‘on' WITH RECONFIGURE;
‘query_plan_as_html') = ‘on' WITH RECONFIGURE;
‘query_detail') = ‘on' WITH RECONFIGURE;
‘query_timing') = ‘on' WITH RECONFIGURE;
24
Validating the version of the dynamic tiering delivery unit

If you suspect that the dynamic tiering delivery unit did not install or update correctly, you can
execute a SQL statement to display the installed version of dynamic tiering:
select * from "_SYS_REPO"."DELIVERY_UNITS" where DELIVERY_UNIT='HANA_TIERING'
Setting Alerts in SAP HANA Cockpit

Alerts notify you of critical situations before trouble occurs. Set alerts using the SAP HANA cockpit
to notify you of disk space availability or capacity issues. It is recommended that you set up proper
alert notifications to keep your dynamic tiering system running smoothly:
Emergency mode dynamic tiering troubleshooting

This section describes an exceptional troubleshooting mode when documented practices are
insufficient. In extreme situations, you may connect directly to the dynamic tiering server and run
some internal dynamic tiering diagnostics by performing the following steps:
• Create a special ES Admin user
• Perform the troubleshooting
• Drop the ES Admin user
The ES Admin user has direct but restricted access to the dynamic tiering server. This user cannot
access extended tables, create new database objects, or perform user management. The SAP
HANA Dynamic Tiering Administration Guide explains how to create and drop the ES Admin user.
After you create this user, you can invoke a utility to execute various SQL troubleshooting stored
procedures. The utility is called ‘dbisql’ and is a simple GUI for directly running SQL commands
against the dynamic tiering server.
From an operating system command prompt, type this command:
dbisql -c
“UID=ES_ADMIN;PWD=admin123;HOST=EXTENDED_STORAGE_HOSTNAME:3xx12”
where xx = HANA Instance Number
25
You will see the following display:
The allowed operations are (type the command into the “SQL Statements” window above):
System Procedure Description
sp_iqcheckdb Checks validity of the current database. Optionally corrects
allocation problems for dbspaces or databases
sp_iqrebuildindex Rebuilds column indexes
sp_iqindexmetadata Displays index metadata for a given index
sp_iqindexinfo Displays the number of blocks used per index per main dbspace
for a given object
sp_iqindexsize Gives the size of the specified index
sp_iqtablesize Returns the size of the specified table
sp_iqstatistics Returns serial number, name, description, value, and unit
specifier for each available statistic, or a specified statistic
sp_iqconnection Shows various information about connections
sp_iqcontext Tracks and displays, by connection, information about statements
that are currently executing
sp_iqspaceused Shows information about space available and space used in the
IQ store, IQ temporary store, RLV store, and IQ global and local
shared temporary stores
sp_iqstatus Displays a variety of SAP Sybase IQ status information about the
current database
sp_iqtransaction Shows information about transactions and versions
26
sp_iqversionuse Displays version usage for the IQ main store

sp_iqzonemapenable Identifies columns that do not have a zone map
sa_report_deadlocks Retrieves information about deadlocks from an internal buffer
created by the database server
sp_iqlocks Shows information about locks in the database, for both the IQ
main store and the IQ catalogue store
sa_locks Displays all locks in the database
sa_table_page_usage Reports information about the page usage of database tables
SUMMARY
This document has provided some best practices for setting up and operating SAP HANA dynamic
tiering – sizing, configuration, performance, administration, and troubleshooting. This guide
supplements the SAP HANA dynamic tiering user documentation with advice for proper use and
optimization of your dynamic tiering system. This guide is a living document that will be updated
and improved with successive releases of HANA dynamic tiering.
RESOURCES AND REFERENCES
SAP corporate website: http://www.sap.com/
SAP HANA resources: http://www.saphana.com/
SAP HANA help portal: http://help.sap.com/hana/
SAP HANA dynamic tiering help portal: http://help.sap.com/hana_options_dynamic tiering/
SAP HANA Data Warehousing Foundation help portal: http://help.sap.com/hana_options_dwf
SAP Note with general information about SAP HANA dynamic tiering:
http://service.sap.com/sap/support/notes/2394124
SAP HANA Academy dynamic tiering videos:

https://www.youtube.com/watch?v=ae1qIViv5sk&list=PLkzo92owKnVxDWNSB_4CdC1W5SD7yZRfR
SAP HANA Dynamic Tiering Developer site: https://www.sap.com/developer/topics/hana-dynamic-

tiering.html
27

HANA

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

HANA

Hochgeladen von

Copyright:

Verfügbare Formate

SAP HANA 2 Dynamic tiering

Best Practices Guide

© 2018 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

Business Objects and the Business Objects logo, BusinessObjects,

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

These materials are subject to change without notice. These materials

You can find documentation for this tool here:

checkpoint_interval Maximum interval The recommendation is to start with 60

Balancing CPU and memory resources for a same host deployment

Trace and Zrlog Section Properties

CREATING EXTENDED STORAGE

THE DATA LIFECYCLE MANAGER TOOL

o You will need to configure expensive statement tracing in the [expensive_statement]

-- make sure that you clean up the query plan cache

HIGH AVAILABILITY AND DISASTER RECOVERY

• M_REMOTE_STATEMENTS: gives details on SQL statements executed by dynamic

Validating the version of the dynamic tiering delivery unit

Setting Alerts in SAP HANA Cockpit

Emergency mode dynamic tiering troubleshooting

You will see the following display:

sp_iqversionuse Displays version usage for the IQ main store

SAP corporate website: http://www.sap.com/

SAP HANA resources: http://www.saphana.com/

SAP HANA help portal: http://help.sap.com/hana/

SAP HANA dynamic tiering help portal: http://help.sap.com/hana_options_dynamic tiering/

SAP HANA Data Warehousing Foundation help portal: http://help.sap.com/hana_options_dwf

SAP HANA Academy dynamic tiering videos:

SAP HANA Dynamic Tiering Developer site: https://www.sap.com/developer/topics/hana-dynamic-

Das könnte Ihnen auch gefallen