SAP HANA Performance Analysis Guide en[1]

PUBLICSAP HANA Platform SPS 07Document Version: 1.1 - 13-03-2014

SAP HANA Performance Analysis Guide

Table of Contents1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 SAP HANA Guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Related Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.3 Important SAP Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2 Identifying and Resolving Performance Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 System Performance Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Thread Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.1.2 Blocked Transaction Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Session Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 Job Progress Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122.1.5 Load Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2.2 SQL Statement Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Analyzing SQL Traces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132.2.2 Analyzing Expensive Statements Traces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Analyzing SQL Execution with the SQL Plan Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Query Plan Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1 Analyzing SQL Execution with the Plan Explanation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.2 Analyzing SQL Execution with the Plan Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Advanced Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272.4.1 Analyzing Column Searches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Analyzing Table Joins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

2.5 Additional Analysis Tools for Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.1 Performance Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.2 Kernel Profiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Recommendations for Enhancing Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323.1 Recommendations for Improving Performance of SQL Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 Creation of Indexes on Non-Primary Key Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3 Creating Analytic Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4 Developing Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Application Function Library (AFL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6 About Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7 Further Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

4 Important Disclaimers on Legal Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2P U B L I C 2014 SAP AG or an SAP affiliate company. All rights reserved.

SAP HANA Performance Analysis GuideTable of Contents

1 IntroductionWith SAP HANA, you can analyze data at incredible speeds, for example, with scans of 1 billion rows per second per core and join performance of 10 million rows per second. However, such results are only possible if the system is monitored and performance issues are kept to a minimum.This guide describes what steps you can take to identify and resolve specific performance issues and what you can do to enhance the performance of your SAP HANA database in general.

1.1 SAP HANA Guides

Links are provided here to documentation for the current Support Package Stack of the SAP HANA Platform Edition, on the SAP Help Portal, and for previous Support Package Stacks, on the SAP HANA Knowledge Center on SAP Service Marketplace.For information about SAP HANA landscape, security, installation, and administration, see the resources listed below:Topic Location Quick Link

SAP HANA landscape, deployment, and installation

SAP HANA Knowledge Center on the SAP Help Portal

http://help.sap.com/hana_platform: SAP HANA Master Guide SAP HANA Server Installation Guide SAP HANA Master Update Guide SAP HANA Update and Configura

tion Guide

SAP HANA administration and security

SAP HANA Knowledge Center on the SAP Help Portal

http://help.sap.com/hana_platform: SAP HANA Technical Operations

Manual SAP HANA Administration Guide SAP HANA Security Guide

SAP HANA documentation for previous Support Package Stacks

SAP HANA Knowledge Center on SAP Service Marketplace

https://service.sap.com/hana

1.2 Related Information

For more information about identifying and resolving performance issues, see the following:

SAP HANA Performance Analysis GuideIntroduction

P U B L I C 2014 SAP AG or an SAP affiliate company. All rights reserved. 3

Content LocationSAP Data Services Performance Optimization Guide http://help.sap.com/businessobject/product_guides/

sboDS42/en/ds_42_perf_opt_en.pdfPerformance of SAP Software Solutions http://service.sap.com/performance

1.3 Important SAP NotesRead the following SAP Notes before you start analyzing performance issues. These SAP Notes contain the latest information about performance issues.Make sure that you have the most up-to-date version of each SAP Note, which you can find on SAP Service Marketplace at https://service.sap.com/notes .

SAP Note Number Title

1890444 Slow HANA system due to CPU power save mode

1824819 Optimal settings for SLES 11 SP2 and SLES 11 for SAP SP2

For additional performance-related SAP Notes, you can search for the term HANA and the category Performance on SAP Service Marketplace at https://service.sap.com/notes .

Customer Messages

If you encounter any problems with the software, create a customer message on the SAP Service Marketplace athttp://service.sap.com/message .In addition, the Customer Interaction Center (CIC) is available 24 x 7 in every region to help you resolve any issues you may run into (https://service.sap.com/supportcenters ).The CIC requires a valid S-user number. To create an S-user ID, follow the steps in this guide (https://service.sap.com/~sapidp/011000358700000905192010E.pdf ).When creating a customer message, you can choose from the above list of components for the relevant software part.


SAP HANA Performance Analysis GuideIntroduction

2 Identifying and Resolving Performance IssuesAlthough SAP HANA is a high performance system, issues may occur that limit its performance. If this happens, you can identify and resolve any issues affecting performance by analyzing what happens in detail when you query the SAP HANA database.

Context

Identifying the source of poor performance in SAP HANA can, however, be challenging. Not only does SAP HANA process large volumes of data, but the SAP HANA database server is also composed of many different engines that work together to execute specific parts of a query. To simplify matters and enable effective performance analysis, the Administration Console of the SAP HANA studio provides several key features for analyzing system performance, SQL statements, and query plans.

NoteIf your application uses not only SAP HANA but ABAP developments as well, then the source of the performance issue may be on the ABAP side. ABAP trace tools, such as the transactions STAD, ST05, and SAT, can help identify the source of performance issues; however, such tools are not within the scope of this documentation. For more information about available ABAP analysis tools, see Test and Analysis Tools in ABAP on the SAP Help Portal at http://help.sap.com/.

To identify and resolve SAP HANA performance issues, we suggest the following approach.

Procedure

1. Ensure the SAP HANA system is configured properly and operating correctly.a) In the Administration editor, use the information on the Overview tab to ensure the SAP HANA system is

operational and the overall status is acceptable.b) Ensure that CPUs in SAP HANA appliances are configured for maximum performance both on the

hardware level and on the operating system level.2. In the Administration editor, use the information on the Performance tab to analyze system performance.

a) Investigate and resolve any blocked threads, transactions, or sessions.b) Analyze job progress and system load to identify any long-running operations that may be responsible for

the poor performance.3. Analyze SQL statements to identify which statements are costing the most time.4. Analyze query plans to identify whether SAP HANA is handling queries efficiently.5. If appropriate, perform advanced analysis of how SAP HANA joins tables and performs column searches.6. If you cannot identify the source of the performance issue, contact SAP Support.

SAP Support can use additional analysis tools to try to identify the issue.

SAP HANA Performance Analysis GuideIdentifying and Resolving Performance Issues


2.1 System Performance AnalysisAs a first step to resolving SAP HANA performance issues, you can analyze detailed aspects of system performance in the SAP HANA studio on the Performance tab of the Administration editor.When analyzing system performance issues, the information provided on the Performance tab enables you to focus your analysis on the following questions: What and how many threads are running, what are they working on, and are any of these threads blocked? Are any sessions blocking current transactions? Are any operations running for a significantly long time and consuming a lot of resources? If so, when will they

be finished? How do different hosts compare in terms of performance?On the Performance tab, you can take certain actions to improve performance, including canceling the operations that cause blocking situations.

2.1.1 Thread MonitoringYou can monitor all running threads in your system in the Administration editor on the PerformanceThreads sub-tab. It may be useful to see, for example, how long a thread is running, or if a thread is blocked for an inexplicable length of time.

Thread Display

By default, the Threads sub-tab shows you a list of all currently active threads with the Group and sort filter applied. This arranges the information as follows: Threads with the same connection ID are grouped. Within each group, the call hierarchy is depicted (first the caller, then the callee). Groups are displayed in order of descending duration.On big systems with a large number of threads, this arrangement provides you with a more meaningful and clear structure for analysis. To revert to an unstructured view, deselect the Group and sort checkbox or change the layout in some other way (for example, sort by a column).

Thread Information

Detailed information available on the Threads sub-tab includes the following: The context in which a thread is used

This is indicated by the thread type. Important thread types are SqlExecutor and PlanExecutor. SqlExecutor threads handle session requests such as statement compilation, statement execution, or



result fetching issued by applications on top of SAP HANA. PlanExecutor threads are used to process column-store statements and have an SqlExecutor thread as their parent.

NoteWith revision 56, PlanExecutor threads were replaced by JobWorker threads.

NoteThe information in the Thread Type column is only useful to SAP Support for detailed analysis.

What a thread is currently working onThe information in Thread Detail, Thread Method, and Thread Status columns is helpful for analyzing what a thread is currently working on. In the case of SqlExecutor threads, for example, the SQL statement currently being processed is displayed. In the case of PlanExecutor threads (or JobWorker threads as of revision 56), details about the execution plan currently being processed are displayed.

NoteThe information in the Thread Detail, Thread Method, and Thread Status columns is only useful to SAP Support for detailed analysis.

Information about transactionally blocked threadsA transactionally blocked thread is indicated by a warning icon ( ) in the Status column. You can see detailed information about the blocking situation by hovering the cursor over this icon.A transactionally blocked thread cannot be processed because it needs to acquire a transactional lock that is currently held by another transaction. Transactional locks may be held on records or tables. Transactions can also be blocked waiting for other resources such as network or disk (database or metadata locks).The type of lock held by the blocking thread (record, table, or metadata) is indicated in the Transactional Lock Type column.The lock mode determines the level of access other transactions have to the locked record, table, or database. The lock mode is indicated in the Transactional Lock Type column.Exclusive row-level locks prevent concurrent write operations on the same record. They are acquired implicitly by update and delete operations or explicitly with the SELECT FOR UPDATE statement.Table-level locks prevent operations on the content of a table from interfering with changes to the table definition (such as drop table, alter table). DML operations on the table content require an intentional exclusive lock, while changes to the table definition (DDL operations) require an exclusive table lock. There is also a LOCK TABLE statement for explicitly locking a table. Intentional exclusive locks can be acquired if no other transaction holds an exclusive lock for the same object. Exclusive locks require that no other transaction holds a lock for the same object (neither intentional exclusive nor exclusive).For more detailed analysis of blocked threads, information about low-level locks is available in the columns Lock Wait Name, Lock Wait Component and Thread ID of Low-Level Lock Owner. Low-level locks are locks acquired at the thread level. They manage code-level access to a range of resources (for example, internal data structures, network, disk). Lock wait components group low-level locks by engine component or resource.The Blocked Transactions sub-tab provides you with a filtered view of transactionally blocked threads.



Monitoring and Analysis Features

To support monitoring and analysis, you can perform the following actions on the Threads sub-tab: See the full details of a thread by right-clicking the thread and choosing Show Details. End the operations associated with a thread by right-clicking the thread and choosing Cancel Operations.

NoteThis option is not available for threads of external transactions, that is those with a connection ID of -1.

Jump to the following related objects by right-clicking the thread and choosing Navigate To : Threads called by and calling the selected thread Sessions with the same connection ID as the selected thread Blocked transactions with the same connection ID as the selected thread

View the call stack for a specific thread by selecting the Create call stacks checkbox, refreshing the page, and then selecting the thread in question.

NoteThe information contained in call stacks is only useful to SAP Support for detailed analysis.

Activate the expensive statements trace, SQL trace, or performance trace by choosing Configure Trace .The Trace Configuration dialog opens with information from the selected thread automatically entered (application and user).

NoteIf the SQL trace or expensive statements trace is already running, the new settings overwrite the existing ones. If the performance trace is already running, you must stop it before you can start a new one.

Related Information

M_SERVICE_THREADSM_SERVICE_THREAD_SAMPLESSQL Trace [page 13]

The SQL trace collects information about all executed SQL statements and saves it in a trace file for further analysis.

Performance Trace [page 29]The performance trace is a performance tracing tool built into the SAP HANA database. It records performance indicators for individual query processing steps in the database kernel.

Expensive Statements Trace [page 15]Expensive statements are individual SQL statements whose execution time exceeded a configured threshold. The expensive statements trace records information about these statements for further analysis.



2.1.2 Blocked Transaction MonitoringBlocked transactions, or transactionally blocked threads, can impact application responsiveness. They are indicated in the Administration editor on the Performance Threads tab. You can see another representation of the information about blocked and blocking transactions on the Blocked Transactions sub-tab.

Information About Blocked Transactions

Blocked transactions are transactions that are unable to be processed further because they need to acquire transactional locks (record or table locks) that are currently held by another transaction. Transactions can also be blocked waiting for other resources such as network or disk (database or metadata locks).The type of lock held by the blocking transaction (record, table, or metadata) is indicated in the Transactional Lock Type column.The lock mode determines the level of access other transactions have to the locked record, table, or database. The lock mode is indicated in the Transactional Lock Type column.Exclusive row-level locks prevent concurrent write operations on the same record. They are acquired implicitly by update and delete operations or explicitly with the SELECT FOR UPDATE statement.Table-level locks prevent operations on the content of a table from interfering with changes to the table definition (such as drop table, alter table). DML operations on the table content require an intentional exclusive lock, while changes to the table definition (DDL operations) require an exclusive table lock. There is also a LOCK TABLE statement for explicitly locking a table. Intentional exclusive locks can be acquired if no other transaction holds an exclusive lock for the same object. Exclusive locks require that no other transaction holds a lock for the same object (neither intentional exclusive nor exclusive).For more detailed analysis of blocked transactions, information about low-level locks is available in the columns Lock Wait Name, Lock Wait Component and Thread ID of Low-Level Lock Owner. Low-level locks are locks acquired at the thread level. They manage code-level access to a range of resources (for example, internal data structures, network, disk). Lock wait components group low-level locks by engine component or resource.


To support monitoring and analysis, you can perform the following actions on the Blocked Transactions sub-tab: Jump to threads and sessions with the same connection ID as a blocked/blocking transaction by right-

clicking the transaction and choosing Navigate To . Activate the performance trace, SQL trace, or expensive statements trace for the blocking transaction (that is

the lock holder) by choosing Configure Trace .The Trace Configuration dialog opens with information from the selected thread automatically entered (application and user).




Related Information

M_BLOCKED_TRANSACTIONSM_OBJECT_LOCKSM_RECORD_LOCKSM_OBJECT_LOCK_STATISTICSSQL Trace [page 13]




2.1.3 Session MonitoringYou can monitor all sessions in your landscape in the Administration editor on the Performance Sessionssub-tab.

Session Information

The Sessions sub-tab allows you to monitor all sessions in the current landscape. You can see the following information: Active/inactive sessions and their relation to applications Whether a session is blocked and if so which session is blocking The number of transactions that are blocked by a blocking session Statistics like average query runtime and the number of DML and DDL statements in a session The operator currently being processed by an active session (Current Operator column).

NoteIn earlier revisions, you can get this information from the SYS.M_CONNECTIONS monitoring view with the following statement:SELECT CURRENT_OPERATOR_NAME FROM M_CONNECTIONS WHERE CONNECTION_STATUS = 'RUNNING'

TipTo investigate sessions with the connection status RUNNING, you can analyze the SQL statements being processed in the session. To see the statements, ensure that the Last Executed Statement and Current



Statement columns are visible. You can then copy the statement into the SQL console and analyze it using the Explain Plan and Visualize Plan features. It is also possible to use the SQL plan cache to understand and analyze SQL processing.


To support monitoring and analysis, you can perform the following actions on the Sessions sub-tab: Cancel a session by right-clicking the session and choosing Cancel Session... Jump to the following related objects by right-clicking the session and choosing Navigate To : Threads with the same connection ID as the selected session Blocked transactions with the same connection ID as the selected session

Activate the performance trace, SQL trace, or expensive statements trace by choosing Configure Trace .The Trace Configuration dialog opens with information from the selected session automatically entered (application and user).


Related Information

M_CONNECTIONSM_TRANSACTIONSSQL Trace [page 13]






2.1.4 Job Progress MonitoringCertain operations in SAP HANA typically run for a long time and may consume a considerable amount of resources. You can monitor long-running jobs in the Administration editor on the Performance Job Progress sub-tab.By monitoring the progress of long-running operations, for example, delta merge operations and data compression, you can determine whether or not they are responsible for current high load, see how far along they are, and when they will finish.The following information is available, for example: Connection that triggered the operation (CONNECTION_ID) Start time of the operation (START_TIME) Steps of the operation that have already finished (CURRENT_PROGRESS) Maximum number of steps in the operation (MAX_PROGRESS)For more information about the operations that appear on the Job Progress sub-tab, see system view M_JOB_PROGRESS.

Related Information

M_JOB_PROGRESS

2.1.5 Load MonitoringA graphical display of a range of system performance indicators is available in the Administration editor on the

Performance Load sub-tab.You can use the load graph for performance monitoring and analysis. For example, you can use it to get a general idea about how many blocked transactions exist now and in the past, or troubleshoot the root cause of slow statement performance.

2.2 SQL Statement AnalysisA key step in identifying the source of poor performance is understanding how much time is spent in the SAP HANA engine for query execution. By analyzing SQL statements and calculating their response times, you can better understand how the statements affect application and system performance.You can analyze the response time of SQL statements with the following traces: SQL trace

From the trace file, you can analyze the response time of SQL statements.



Expensive statements traceOn the Performance Expensive Statements Trace tab, you can view a list of all SQL statements that exceed a specified response time.

In addition to these traces, you can analyze the SQL plan cache, which provides a statistical overview of what statements are executed in the system.

2.2.1 Analyzing SQL TracesThe SQL trace allows you to analyze the response time of SQL statements within an object.

Procedure

1. In the Administration editor, choose the Trace Configuration trace and edit the SQL trace.2. In the Trace Configuration dialog box, specify a name for the trace file, set the trace status to Active, and

specify the required trace and user filters.3. Choose Finish.4. Run the application or SQL statements you want to trace.5. Re-open the SQL trace configuration and set the trace status to Inactive.6. Choose Finish.7. Choose the Diagnosis Files tab and open the trace file you created.8. Choose Show Entire File.9. Analyze the response time of the relevant SQL statements to identify which statements negatively affect

performance.The SQL statements in the trace file are listed in order of execution time. To calculate the response time of a specific SQL statement, calculate the difference between the times given for # tracing PrepareStatement_execute call and # tracing finished PrepareStatement_execute.

2.2.1.1 SQL TraceThe SQL trace collects information about all executed SQL statements and saves it in a trace file for further analysis.Information collected includes overall execution time of each statement, the number of records affected, potential errors (for example, unique constraint violations) that were reported, the database connection being used, and so on. Therefore, the SQL trace is a good starting point for understanding executed statements and their potential effect on the overall application and system performance, as well as for identifying potential performance bottlenecks at statement level.SQL trace information is saved as an executable python program that you can access on the Diagnosis Files tab of the Administration editor.



NoteWriting SQL trace files can impact database performance significantly. They also consume storage space on the disk. Therefore, it is not recommended that you leave the SQL trace enabled all the time.

Configuration Options

You activate the SQL trace in the Administration editor on the Trace Configuration tab.You can choose from the following trace levels:Trace Level DescriptionNORMAL All statements that have finished successfully are traced with detailed information

such as executed timestamp, thread ID, connection ID, and statement ID.ERROR All statements that returned errors are traced with detailed information such as

executed timestamp, thread ID, connection ID, and statement ID.ERROR_ROLLBACK All statements that are rolled back are traced with detailed information such as exe

cuted timestamp, thread ID, connection ID and statement ID.ALL All statements including status of normal, error, and rollback are traced with de

tailed information such as executed timestamp, thread ID, connection ID and statement ID.

ALL_WITH_RESULTS In addition to the trace generated with trace level ALL, the result returned by select statements is also included in the trace file.

NoteAn SQL trace that includes results can quickly become very large.

CautionAn SQL trace that includes results may expose security-relevant data, for example, query result sets.

The following additional configuration options are available: You can specify filters to restrict traced statements to those of particular database or application users and

applications, as well as to certain statement types and tables. All statements matching the filter criteria are recorded and saved to the specified trace file.

You can specify a user-specific name for the trace file.If you do not enter a user-specific file name, the file name is generated according to the following default pattern:sqltrace_$HOST_${PORT}_${COUNT:3}.py, where: $HOST is the host name of the service (for example, indexserver) $PORT is the port number of the service



$COUNT:3 is an automatically generated 3-digit number starting with 000 that increments by 1 and serves as a file counter when several files are created.

You can adapt the flush interval if required.During tracing, the messages of a connection are buffered. As soon as the flush interval number of messages is buffered (or if the connection is closed), those messages are written to the trace file.

2.2.2 Analyzing Expensive Statements Traces

The expensive statements trace allows you to identify which SQL statements require a significant amount of time and resources.

Procedure

1. In the Administration editor, choose the Trace Configuration trace and edit the expensive statements trace.2. In the Trace Configuration dialog box, set the trace status to Active and specify a threshold execution time in

microseconds.The system will identify any statements that exceed this threshold as expensive statements.

3. Choose Finish.4. Run the application or SQL statements you want to trace.5. Choose the Performance Expensive Statements Trace tab.6. Analyze the displayed information to identify which statements negatively affected performance.

For each SQL statement, the following columns are especially useful for determining the statement's impact on performance: START_TIME DURATION_MICROSEC OBJECT_NAME (names of the objects accessed) STATEMENT_STRING CPU_TIME

2.2.2.1 Expensive Statements Trace

Expensive statements are individual SQL statements whose execution time exceeded a configured threshold. The expensive statements trace records information about these statements for further analysis.Information about recorded expensive statements is displayed on the Performance tab.




You activate the expensive statements trace in the Administration editor on either the Trace Configuration tab or the Performance tab. The following configuration options are available: You can configure the threshold execution time in microseconds (default 1,000,000). You can specify filters to restrict traced statements to those of particular database or application users, as

well as to certain applications and tables. If you are activating the performance trace as part of an end-to-end trace scenario with the Process

Monitoring Infrastructure (PMI), you can specify the passport trace level as an additional filter. This means that only requests that are marked with a passport of the specified level are traced.For more information see, SAP Library for NetWeaver on SAP Help Portal.

NoteProcess tracing is possible only for components in the ABAP and Business Objects stacks.

You can deactivate the tracing of parameter values.In SQL statements, field values may be specified as parameters (using a "?" in the syntax). If these parameter values are not required, you can deselect the Trace parameter values checkbox to reduce the amount of data traced.

Related Information

Process Monitoring with PMI (Process Monitoring Infrastructure)

2.2.3 Analyzing SQL Execution with the SQL Plan CacheThe SQL plan cache is a valuable tool for understanding and analyzing SQL processing.Before it is executed, every SQL statement is compiled to a plan. Once a plan has been compiled, it is better to reuse it the next time the same statement is executed, instead of compiling a new plan every time. The SAP HANA database provides an object, the SQL plan cache, that stores plans generated from previous executions. Whenever the execution of a statement is requested, a SQL procedure checks the SQL plan cache to see if there is a plan already compiled. If a match is found, the cached plan is reused. If not, the statement is compiled and the generated plan is cached.As the SQL plan cache collects statistics on the preparation and execution of SQL statements, it is an important tool for understanding and analyzing SQL processing. For example, it can help you to find slow queries, as well as measure the overall performance of your system.You can access the SQL plan cache in the Administration editor on the Performance tab. The two system views associated with the SQL plan cache are M_SQL_PLAN_CACHE_OVERVIEW and M_SQL_PLAN_CACHE.The SQL plan cache contains a lot of information. Filtering according to the following columns can help you identify statements that are more likely to be causing problems and/or could be optimized:



Column DescriptionTOTAL_EXECUTION_TIME The total time spent for all executions of a plan

This helps to identify which statements are dominant in terms of time.AVG_EXECUTION_TIME The average time it takes to execute a plan execution

This can help you identify long-running SQL statements.EXECUTION_COUNT The number of times a plan has been executed

This can help you identify SQL statements that are executed more frequently than expected.

TOTAL_LOCK_WAIT_COUNT

The total number of waiting locksThis can help you identify SQL statements with high lock contention.

USER_NAME The name of the user who prepared the plan and therefore where the SQL originated (ABAP/index server/statistics server)

For a full list of all SQL cache columns including descriptions, see the documentation for the system views M_SQL_PLAN_CACHE_OVERVIEW and M_SQL_PLAN_CACHE in the SAP HANA SQL and System Views Reference.

Related Information

SAP HANA SQL and System Views Reference

2.2.3.1 Example: Reading the SQL Plan CacheThese examples aim to show you how to gain useful insights by analyzing the SQL plan cache.

Execution in a Single-Host System

This example aims to show you how to interpret information about execution time. The following table is sorted by TOTAL_EXECUTION_TIME.USER_ NAME

STATMENT_ STRING TOTAL_ EXECUTION_ TIME

AVG_ EXECUTION_ TIME

EXECUTION_ COUNT

SYSTEM SELECT "REQUEST" , "DA-TAPAKID" , "PARTNO" , "RECORD" , "CAL-DAY" , ...

774,367,833 181,266 4,272



USER_ NAME

STATMENT_ STRING TOTAL_ EXECUTION_ TIME

AVG_ EXECUTION_ TIME

EXECUTION_ COUNT

SYSTEM SELECT * FROM "/BIC/AZDSTGODO40" WHERE "SID" = ?

726,672,877 60,556,073 12

SYSTEM SELECT "JOBNAME" , "JOB-COUNT" , "JOBGROUP" , "INTREPORT" , "STEP-COUNT" ...

473,620,452 22,987 20,604

You could read these top 3 results as follows: Statement 1 takes the longest time overall but it is also executed frequently. Statement 2 is not executed very frequently but has the second highest total execution time. Why is this

simple SQL taking so long? Does it have problems processing? The execution times for statement 3 are fine for one-off execution, but it runs too frequently, over 20,000

times. Why? Is there a problem in application code?Sorting by AVG_EXECUTION_TIME or EXECUTION_COUNT provides a different angle on your analysis.The following example aims to show you how to interpret information about locking situations. The information in columns TOTAL_LOCK_WAIT_COUNT and TOTAL_LOCK_WAIT_DURATION lets us know which statement is waiting for others and how much time it takes.USER STATEMENT_STRING TOTAL_LOCK_

WAIT_COUNTTOTAL_LOCK_ WAIT_DURATION

TOTAL_ EXECUTION_TIME

SYSTEM SELECT "FROMNUMBER","TO-NUMBER","NRLEVEL" FROM "NRIV" ... FOR UPDATE

11,549,961 210,142,307,207 676,473

SYSTEM UPDATE "NRIV" SET "NRLE-VEL" = ? WHERE "CLIENT" = '000' ... AND "TOYEAR" = '0000'

0 0 3,706,184

SYSTEM SELECT "DIMID" FROM "/BIC/DZDSTGCUBE4" WHERE "/B49/S_VERSION" = ?

0 0 460,991

Here, it is clear that the first statement is waiting almost all the time. Known as pessimistic/optimistic locking, the SELECT...FOR UPDATE code locks the resulting columns and may be replaced by a non-locking variant, which can result in poor performance. If the application is critical, it may be necessary to revise the SELECT...FOR UPDATE code for better resource utilization and performance.

Execution in a Distributed System

In distributed SAP HANA systems, tables and table partitions are located on multiple hosts. The execution of requests received from database clients may potentially have to be executed on multiple hosts, depending on



where the requested data is located. The following example illustrates statement routing and how, if it is not enabled, requests from the database client are executed on the contacted index server (in this case the master index server) and the required data is fetched from the index server on the relevant host(s). However, if statement routing is enabled, after initial query compilation, request execution is routed directly to the host on which the required data is located.

Figure 1: Distributed Execution with Statement Routing Off and On

Execution times should be better with statement routing enabled. You can use the SQL plan cache to compare the execution statistics of statements with statement routing enabled and disabled and thus confirm the effect.Statement routing is controlled by the client_distribution_mode parameter in the indexserver.ini file. It is enabled by default (value=statement).The following SQL plan cache examples show the execution times of sample statements based on the scenario illustrated above.

NoteThe column IS_DISTRIBUTED_EXECUTION indicates whether or not statement execution takes place on more than one host.



The TOTAL_EXECUTION_TIME for a statement is the sum of execution times on all hosts, therefore:Statement Request Path Total Execution TimeUPSERT "RSBMONMESS_DTP" ( "MSGNO", "MSGTY", "MSGID", ...

seltera12 = execution time on seltera12

SELECT * FROM "/BI0/SIOBJNM" WHERE "IOBJNM" = ?

seltera12 > selbld13 = execution time on seltera12 + execution time on selbld13

SELECT * FROM "/B49/SCUSTOMER" WHERE "/B49/S_CUSTOMER" = ?

seltera12 > seltera13 > selbld16 = execution time on seltera12 + execution time on selbld16

Statement Request Path Total Execution TimeUPSERT "RSBMONMESS_DTP" ( "MSGNO", "MSGTY", "MSGID", ...

seltera12 = execution time on seltera12

SELECT * FROM "/BI0/SIOBJNM" WHERE "IOBJNM" = ?

selbld13 = execution time on selbld13

SELECT * FROM "/B49/SCUSTOMER" WHERE "/B49/S_CUSTOMER" = ?

selbld16 = execution time on selbld16



2.3 Query Plan AnalysisIn SAP HANA, to identify queries that are inefficiently processed, you can both technically and logically analyze the steps SAP HANA took to process those queries.From a technical perspective, analyzing query plans allows you to identify long running steps, understand how much data is processed by the operators, and see whether data is processed in parallel. However, if you understand the idea and purpose behind the query, you can also analyze query plans from a logical perspective and consider questions such as: Does SAP HANA read data from multiple tables when only one is required? Does SAP HANA read all records when only one is required? Does SAP HANA start with one table even though another table has a much smaller result set?To gain the insight you need to answer such questions, the SAP HANA studio provides the following features for query plan analysis: Plan explanation Plan visualization

2.3.1 Analyzing SQL Execution with the Plan ExplanationYou can generate a plan explanation for any SQL statement in the SQL console. You can use this to evaluate the execution plan that the SAP HANA database follows to execute an SQL statement.

Procedure

1. Enter a query into the SQL console and choose Explain Plan in the context menu.

NoteYou can enter multiple statements, separated by the configured separator character (usually a semicolon), to generate several plan explanations at once.

The plan explanation is displayed on the Result tab.2. Optional: Run the same statement on different systems/users by changing the SQL connection.

That is, assuming that the tables and views exist in the other systems and you have authorization to access them.The plan explanation is displayed on the Result tab.

Results

Plan explanations are also stored in the EXPLAIN_PLAN_TABLE view of the SYS schema for later examination.



2.3.2 Analyzing SQL Execution with the Plan VisualizerTo help you understand and analyze the execution plan of an SQL statement, you can generate a graphical view of the plan.

Procedure

1. Visualize the plan of the SQL statement in one of the following ways:a) Enter the statement in the SQL console and choose Visualize Plan in the context menu.b) On the SQL Plan Cache tab or the Expensive Statements Trace tab of the Performance tab, right-click the

statement and choose Visualize Plan.



A graphical representation of the query, with estimated performance, is displayed.Figure 2: Visualized Plan

2. Validate the estimated performance by choosing Execute in the context menu.



Another similar high-level graphic is generated with execution time information for each of the parts.Figure 3: Executed Plan

NoteExecution time is given as a pair of values: "self" (the execution time of the node), and "Inclusive" (the execution time including the descendent nodes.

3. To see a temporal breakdown of the individual operations processed in the execution of the query, open the Timeline view.



From the main menu choose Window Show View Timeline .Figure 4: Timeline View

4. If the query used the SAP HANA Column Engine, you can view the details of the various database operations by choosing Visualize Column Plan from the context menu.



A detailed graphic is displayed.Figure 5: Column Plan Visualization

Results

This graphic is a very powerful tool for studying performance of queries on SAP HANA databases. You can explore the graphic further, for example, you can expand, collapse, or rearrange nodes on the screen. You can also save the graphic as an image or XML file, for example, so you can submit it as part of a support query.



2.4 Advanced AnalysisIf have you an advanced knowledge of SAP HANA and SQL databases and you suspect that automated processes are making poor decisions that have negative impacts on query performance, you can perform advanced analyses to better understand how those decisions were made.In SAP HANA, you can use specific SQL commands to produce trace information to help analyze the following processes: Table joins Column searches

RecommendationPerform these types of analysis only if analyses of query plans and SQL statements were not enough to find the root cause of slow query performance.

2.4.1 Analyzing Column SearchesIn SAP HANA, if a column search takes a long time, you can analyze how the query-optimizer performed the column search. A query-optimizer (qo) trace of a single SAP HANA table search provides the details you need for such an analysis.

Context

The qo trace provides a lot of information that is hard to consume if you are not an SAP HANA query-optimizer expert; however, it does provide some useful information for performance analysis. From the information within the trace files, you can see which column the query-optimizer decided to use as the first column in the column search and you can determine whether that decision negatively impacted the performance of the column search.To start a user-specific qo trace and analyze the relevant trace information, proceed as follows.

Procedure

1. In the Administration editor, choose Trace Configuration and create a new user-specific trace.The Trace Configuration dialog box opens.

2. Specify a context name.The context name appears as part of the trace file name and should be easy for you to recognize and later find.

3. Specify your database user or application user.4. Select the Show All Components checkbox.



5. Enter qo as filter text and search for the trex_qo component.6. For the trex_qo component, select DEBUG as the system trace level.7. Choose Finish.8. Run the query you want to trace.9. Switch off the trace by deleting the user-specific trace configuration.10. On the Diagnosis Files tab, search for the trace file, open the file, and select Show Entire File.11. In the trace section, analyze the trace information for each term (WHERE condition).

a) Find the sections detailing the estimated results for the terms.These sections are marked with GetEstimation.cpp.

b) Find the sections detailing the actual search results for the terms.These sections are marked with Evaluate.cpp.

c) Compare the estimated results with the actual search results.The query-optimizer selects which column to use as the first column of the search based on the term with the lowest estimated number of results.

Results

If the actual results indicate that a different term should have been used to start the column search, then this may represent the source of poor performance. For more detailed analysis, you can send the trace file to SAP Support.

2.4.2 Analyzing Table Joins

In SAP HANA, if a query on joined tables takes a long time, you can analyze how the tables are joined and in what order. A join evaluation (je) trace of joined SAP HANA tables provides the details you need for such an analysis.

Context

The je trace provides a lot of information that is hard to consume if you are not an SAP HANA join engine expert; however, it does provide some useful information for performance analysis. From the information within the trace files, you can see which table is used as the first table when processing a join and how the order of tables in the join is defined. You can use this information to determine whether query performance is negatively impacted by the table join.To start a je trace and analyze the relevant trace information, proceed as follows:



Procedure

1. In the Administration editor, choose Trace Configuration and create a new user-specific trace.The Trace Configuration dialog box opens.

2. Specify a context name.The context name appears as part of the trace file name and should be easy for you to recognize and later find.

3. Specify your database user or application user.4. Select the Show All Components checkbox.5. Enter join as filter text and search for the join_eval component.6. For the join_eval component, select DEBUG as the system trace level.7. Choose Finish.8. Run the query you want to trace.9. Switch off the trace by deleting the user-specific trace configuration.10. On the Diagnosis Files tab, search for the indexserver trace file, open the file, and select Show Entire File.11. From the end of the file, search backwards for the beginning of the trace section.

The trace section starts with i TraceContext TraceContext.cpp.12. In the trace section, analyze the following trace information:

Estimations for the WHERE conditions Table size and join conditions Join decision

2.5 Additional Analysis Tools for SupportTo complement the standard tools for performance analysis, SAP HANA provides additional analysis tools that SAP Support can use to help determine the cause of performance issues.The following analysis tools are available in SAP HANA; however, these tools are intended only for use when requested by SAP Support: Performance trace

This tool records performance indicators for individual query processing steps in database kernel. Kernel profiler

This tool provides information about hotspots and expensive execution paths during query processing.

2.5.1 Performance TraceThe performance trace is a performance tracing tool built into the SAP HANA database. It records performance indicators for individual query processing steps in the database kernel.



Information collected includes the processing time required in a particular step, the data size read and written, network communication, and information specific to the operator or processing-step-specific (for example, number of records used as input and output).

CautionThe performance trace is a tool intended for SAP HANA development support only. To interpret the information collected, you require a deep understanding of the system component being analyzed.

It is recommended that you start performance tracing immediately before running the command(s) that you want to analyze and stop it immediately after they have finished. When you stop tracing, the results are saved to trace files that you can access on the Diagnosis Files tab of the Administration editor. You cannot analyze these files meaningfully in the SAP HANA studio, but instead must use a tool capable of reading the output format (*.tpt). SAP Support has tools for evaluating performance traces.


You activate the performance trace in the Administration editor on the Trace Configuration tab.The following configuration options are available: You can configure the trace for a single specific database user, a single specific application user, and a single

specific application. If you are activating the performance trace as part of an end-to-end trace scenario with the Process

Monitoring Infrastructure (PMI), you can specify the passport trace level as an additional filter. This means that only requests that are marked with a passport of the specified level are traced.For more information see, SAP Library for NetWeaver on SAP Help Portal.

NoteProcess tracing is possible only for components in the ABAP and Business Objects stacks.

You can trace execution plans in addition to the default trace data. You can activate the function profiler.

The function profiler is a very fine-grained performance tracing tool based on source code instrumentation. It complements the performance trace by providing even more detailed information about the individual processing steps that are done in the database kernel.

You can specify the file name to which the trace data is automatically saved after the performance trace is stopped.

You can specify how long you want tracing to run.If a certain scenario is to be traced, ensure that you enter a value greater than the time it takes the scenario to run. If there is no specific scenario to trace but instead general system performance, then enter a reasonable value. After the specified duration, the trace stops automatically.

Related Information

Process Monitoring with PMI (Process Monitoring Infrastructure)



2.5.2 Kernel ProfilerThe kernel profiler is a sampling profiler built into the SAP HANA database. It can be used to analyze performance issues with systems on which third-party software cannot be installed, or parts of the database that are not accessible by the performance trace.

CautionThe kernel profiler is a performance analysis tool for experts. To interpret the information collected, you require a deep understanding of the source code of the SAP HANA database kernel. For this reason, to be able to use the kernel profile, you must have the SAP_INTERNAL_HANA_SUPPORT role. This role is intended only for SAP HANA development support.

The kernel profile collects, for example, information about frequent and/or expensive execution paths during query processing.It is recommended that you start kernel profiler tracing immediately before you execute the statements you want to analyze and stop it immediately after they have finished. This avoids the unnecessary recording of irrelevant statements. It is also advisable as this kind of tracing can negatively impact performance. When you stop tracing, the results are saved to trace files that you can access on the Diagnosis Files tab of the Administration editor. You cannot analyze these files meaningfully in the SAP HANA studio, but instead must use a tool capable of reading the configured output format, that is KCacheGrind or DOT (default format).


You activate the kernel profile in the Administration editor on the Trace Configuration tab.When you start tracing, you can specify the following configuration options: The service(s) that you want to profile The amount of time the kernel profiler is to wait between call stack retrievals

When you activate the kernel profiler, it retrieves the call stacks of relevant threads several times. If a wait time is specified, it must wait the specified time minus the time the previous retrieval took.

Memory limit that will stop tracingThe kernel profiler can potentially use a lot a memory. To prevent the SAP HANA database from running out of memory due to profiling, you can specify a memory limit that cannot be exceeded.

The database user and/or application user you want to profileWhen you stop tracing, you can configure the output format.



3 Recommendations for Enhancing PerformanceYou can improve the general performance of the SAP HANA database by implementing various best practices, design principles, available features, and add-ons.To enhance the performance of the SAP HANA database, we recommend you do the following: Improve SQL queries by using the recommendations provided.

You can significantly improve the performance of your SQL queries by knowing how the SAP HANA database and SAP HANA engines process queries and adapting your queries accordingly.

Create indexes for any non-primary key columns that are often queried.SAP HANA automatically creates indexes for primary key columns; however, if you need indexes for non-primary key columns, you must create them manually.

Create virtual star schemas on SAP HANA data by joining attribute views to tables that contain measures within the definition of an analytic view.By using analytic views, SAP HANA can automatically recognize star queries and enable the performance benefits of using star schemas, such as reducing dependencies for query processing.

Develop procedures to embed data-intensive application logic into the database.With procedures, no large data transfers to the application are required and you can use performance-enhancing features such as parallel execution. Procedures are used when other modeling objects, such as analytic or attribute views, are not sufficient. If you use SQLscript to create procedures, follow the best practices for using SQLscript. For statistical computing, create procedures using the open source language R.

Download and install the available application function libraries, such as Predictive Analysis Library (PAL) and Business Function Library (BFL).Application functions are like database procedures written in C++ and called from outside to perform data intensive and complex operations.

Scale SAP HANA to improve performance.SAP HANA's performance is derived from its efficient, parallelized approach. The more computation cores your SAP HANA server has, the better overall system performance is.

NoteWith SAP HANA, you do not need to perform any tuning to achieve high performance. In general, the SAP HANA default settings should be sufficient in almost any application scenario. Any modifications to the predefined system parameters should only be done after receiving explicit instruction from SAP Support.

3.1 Recommendations for Improving Performance of SQL QueriesYou can significantly improve the performance of your SQL queries by knowing how the SAP HANA database and SAP HANA engines process queries and adapting your queries accordingly.As a general guideline for improving SQL query performance, we recommend you avoid operations that are not natively supported by the various SAP HANA engines. Such operations can significantly increase the time


SAP HANA Performance Analysis GuideRecommendations for Enhancing Performance

required to process queries. In addition, the following specific recommendations may help improve the performance of your SQL queries: Avoid calculations in queries.

If you cannot avoid calculations, you can consider adding a generated column. A generated column improves query performance at the expense of increased insertion and update costs.Slow query SELECT * FROM T WHERE b * c = 10;Fast query SELECT * FROM T WHERE bc = 10;DDL for faster query ALTER TABLE T ADD (bc INTEGER GENERATED

ALWAYS AS b * c); If two columns are frequently compared by queries, ensure the two columns have the same data type.

For columns of different types, SAP HANA uses implicit type casting to enable comparison. However, implicit type casting has a negative affect on performance. If you cannot ensure the two columns have the same type from the beginning, one of the following steps can improve performance: If possible, change the type of value as this has less cost than changing the type of column.

Slow query SELECT * FROM T WHERE date_string < CURRENT_DATE;

Fast query SELECT * FROM T WHERE date_string < TO_CHAR(CURRENT_DATE, 'YYYYMMDD');

Consider adding a generated column. A generated column improves query performance at the expense of increased insertion and update costs.Slow query SELECT * FROM T WHERE s = 1;Fast query SELECT * FROM T WHERE n = 1;DDL for faster query ALTER TABLE T ADD (n DECIMAL GENERATED

ALWAYS AS s); Avoid join predicates that do not have the equal condition. Join predicates connected by OR, Cartesian

product, and join without join predicates are not natively supported.

Slow query SELECT M.year, M.month, SUM(T.ship_amount)FROM T JOIN M ON T.ship_date BETWEEN M.first_date AND M.last_dateGROUP BY M.year, M.month;

Fast query SELECT M.year, M.month, SUM(T.ship_amount)FROM T JOIN M ON EXTRACT(YEAR FROM T.ship_date) = M.year AND EXTRACT(MONTH FROM T.ship_date) = M.monthGROUP BY M.year, M.month;

Avoid using filter predicates inside outer join predicates because they are not natively supported.You can rewrite such filter predicates into equijoin predicates using a generated column.Slow query SELECT * FROM T JOIN S ON T.a = S.a AND

T.b = 1;



Fast query SELECT * FROM T JOIN S ON T.a = S.a AND T.b = S.one;

DDL for faster query ALTER TABLE S ADD (one INTEGER GENERATED ALWAYS AS 1);

Avoid cyclic joins because cyclic outer joins are not natively supported and the performance of cyclic inner joins is inferior to acyclic inner joins.In the following example, the cyclic join is rewritten as an acyclic join by moving the nation column of the supplier table to the lineitem table.

Cyclic join SELECT * FROM supplier S, customer C, lineitem LWHERE L.supp_key = S.key AND L.cust_key = C.key AND S.nation = C.nation;

Acyclic join SELECT * FROM supplier S, customer C, lineitem LWHERE L.supp_key = S.key AND L.cust_key = C.key AND L.supp_nation = C.nation;

Avoid using OR to connect EXISTS or NOT EXISTS predicates with other predicates. If possible, use the NOT EXISTS predicate instead of NOT IN. The NOT IN predicate is more expensive. Avoid using the UNION ALL, UNION, INTERSECT and EXCEPT predicates because they are not natively

supported. For multiple columns involved in a join, create the required indexes in advance.

SAP HANA automatically creates indexes to process joins; however, if the queries are issued by an update transaction or a lock conflict occurs, the indexes cannot be created, which may cause performance issues.

3.2 Creation of Indexes on Non-Primary Key Columns

Create indexes on non-primary key columns to enhance the performance of some queries using the index adviser.SAP HANA automatically creates indexes for all primary key columns.Indexing the primary key columns is usually sufficient because queries typically put filter conditions on primary key columns. When filter conditions are on non-key fields and tables have many records, creating an index on the non-primary key columns may improve the performance.

TipTo check whether there is an index for a column, in the Plan Visualizer, in the properties of a column, see the Inverted Index entry. Alternatively, you can also see the system view M_INDEXES.

You can create indexes on non-primary key columns to enhance the performance of some queries, particularly highly selective queries on non-primary key columns.



Use the index adviser to find out for which tables and columns indexing would be most valuable. The indexAdvisor.py script is part of a SAP HANA system installation and runs from the command line. It is located in the $DIR_INSTANCE/exe/python_support directory.There is a trade-off between indexing and memory consumption: While indexing non-primary key columns can make query execution faster, the downside is that memory consumption increases. The index adviser takes this trade-off into account: In dynamic mode, the index adviser looks for the tables and columns that are used most often. The higher the selectivity is, that is, the more different values are in the column, the higher are the performance gains from indexing the columns.To create indexes on non-primary columns, use the following SQL statement:CREATE INDEX ON ()

Related Information

SAP HANA SQL and System Views Reference

3.3 Creating Analytic ViewsProcedure

1. Define Output Structurea) Add the tables that you want to use in any of the following ways:

Drag the required tables present in the Catalog to the Data Foundation node. Select the Data Foundation node in the Scenario panel, and in the context menu of the Details panel,

choose Add ... and search for the required object.

Note You can add the same table in the Data Foundation by using table aliases in the editor; for

example, consider a table containing supplier and buyer information with postal code, and another table containing the link from postal code to region and country. Now, you want to join this geography table two time to the buyer and the supplier.

If your analytic view has more than one table, you need to specify which table is the central table (fact table) from which the measures will be derived. You can specify the central table by selecting a value in the Central Entity property of the Data Foundation node.

RestrictionYou cannot add column views to the Data Foundation of an analytic view. However, you can add column views to a calculation view.

b) To query data from more than one table, go to the Details panel context menu, choose Create Join, and enter the required details.In the New Joinwindow, choose a left and a right table. To create a join, choose



appropriate columns from each table and set relevant properties. At a time, you can create only a single join.You can also join two tables by dragging and dropping the join from the column of one table to a column in another table . After creating the join, you can edit its properties, such as join type and cardinality, in the Properties view. You can choose to create Text Join between table fields in order to get language-specific dataYou 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.

TipYou can set the cardinality of the join as required. By default, the cardinality of the join is empty. The empty cardinality can be specified if you are not sure about the right cardinality. If you specify the empty cardinality, the system will determine the the cardinality during the join evaluation phase.

CautionSelecting the incorrect cardinality can lead to erroneous data and memory issues.

c) Perform one of the following steps to add the table columns to the output structure (Semantics node) that you want to use to define the facts. Select the toggle button on the left of the table field. Right-click the table field, and choose Add to Output.

d) To specify a filter condition based on which system must display data for a table field in the output,:Only display revenue for companies that fulfill the filter conditions you have specified.1. Right-click the table field, and choose Apply Filter.2. Select the required operator, and enter the filter values.You can use the following operators for

filtering.Filter Operator DescriptionEqual To filter and show data corresponding to the fil

ter valueNot Equal To filter and show data other than the filter valueBetween To filter and show data for a particular range

specified in the From Value and To ValueList of Values To filter and show data for a specific list of values

separated by commaNot in list To filter data and show data for the values other

than the ones specified. You can provide a list of values to be excluded using comma.

Is NULL To filter and show row data having NULL valuesIs not NULL To filter and show data of all the rows that have

non NULL values



Filter Operator DescriptionLess than To filter and show data with values less than the

one specified as filter valueLess than or Equal to To filter and show data with values less than or

equal to the one specified as filter valueGreater than To filter and show data with values greater than

the one specified as filter valueGreater than or Equal to To filter and show data with values greater than

or equal to the one specified as filter valueContains Pattern To filter and show data that matches the pattern

specified in the filter value. You can use '?' question mark to substitute a single character, and '*' asterik to substitute many. For example, to filter data for continents that start with letter A, use Contains Pattern filter with value A*. This would show the data for all the continents that start with A like Asia and Africa.

NoteYou can either specify a fixed value for the filter, or use an input parameter of the current analytic view to provide the filter value at runtime during data preview. You can specify the filter value as fixed or dynamic in the Value Help dialog by specifying the Type as Fixed or Input Parameter.

The table fields selected above form the fact table.e) To create a star schema, that is linking the fact table with the descriptive data (attribute views:

1. Perform one of following steps to add the required attribute views in the Logical Join node: Drag the required attribute views present in the Content node to the Logical Join node. Select the Logical Join node in the Scenario panel, and choose Add to add the attribute views.

2. Create joins between the views and the fact table.

NoteIn the Logical Join, you can create a temporal join between the date field of the fact table to an interval (to and from) field of the attribute view. The temporal join has to start from the fact table such that the single column must be in the fact table and the to and from columns must be in the table that is directly joined to the fact table. The join type must be a referential join. The supported data types are timestamp, date, and integer.

RestrictionWhile creating joins, you must ensure that a table does not appear twice in any join path, that is r a self join is not supported. A join path is the set of joins that links the fact table to other tables.While creating joins between analytic view and attribute view: The same table cannot be used in the join path of analytic view and attribute view



The table of the attribute view which is linked to the fact table should not have an alias table

2. Create Calculated Column (Optional)a) In the Output of Logical Join panel, right-click on Calculated Columns and in the context menu, choose

New.b) Enter a name and description (label) for the calculated column.Select a data type, and enter the length

and scale for the calculated column.c) Select the Column Type to determine whether it is a calculated attribute or a calculated measure.d) If you select Calculate Before Aggregation, select the aggregation type.

NoteIf you select Calculate Before Aggregation, the calculation happens as per the expression specified and then the results are aggregated as SUM, MIN, MAX or COUNT. If Calculate Before Aggregation is not selected, the data is not aggregated but it gets calculated as per calculation expression (formula), and the aggregation is shown as FORMULA. If the aggregation is not set, then it will be considered as an attribute. You should selecting Calculate Before Aggregation only when required as it may decrease the performance.

e) In the Expression Editor enter the expression.if("PRODUCT" = 'ABC, "DISCOUNT" * 0.10, "DISCOUNT") which is equivalent to, if attribute PRODUCT equals the string ABC then DISCOUNT equals to DISCOUNT multiplied by 0.10 should be returned. Otherwise the original value of attribute DISCOUNT should be used.

NoteThe expression can also be assembled by dragging and dropping the expression elements from the menus below the editor window.

f) To associate the calculated column with the currency and unit of measuring quantity, select the Advanced view and select the required Type. Choose OK.

RememberCalculated Columns can be created only at the Logical Join level and not at the Data Foundation level.

TipYou can also create a calculated column based on the existing one by copying it and making the required changes. The copy paste option is available from the context menu of the calculated column. You can also use the CTRL + C and CTRL + V keyboard shortcuts. The copy paste functionality works only in the same editor, that is, if you copy a calculated column in one view editor you cannot paste it in another view editor. Also, if you copy a calculated column in one editor and go to another view editor and again copy another object, the paste option in the previous editor is not available. The copy paste functionality for calculated columns only works in the Output panel.

3. Optional step: Create counters to obtain the number of distinct values of an attributea) Choose the Logical Join node.b) In the Output panel, choose Calculated Columns.c) In the context menu of the Calculated Columns, choose New Counter.d) In the Counter window, enter a counter name and a description.



e) To hide the counter during data preview, select the Hidden checkbox.f) To add attributes in the Counters panel, choose Add.g) Choose OK.

4. Optional Step: Create Restricted ColumnsYou can create restricted columns if you want to filter the value for an output field based on the user-defined rules. For example, you can choose to restrict the value for the Revenue column only for Region = APJ, and Year = 2012.a) In the Output panel of the Logical Join, right-click Restricted Columns, and choose New.b) Enter a name and description for the restricted column.c) From the Column dropdown list, select the column for which you want to apply a restriction.

CautionThe column for which you apply a restriction must be defined as measure in the semantics node otherwise the validation will fail.

d) Choose Add Restriction.e) In the Parameter field, select the column that you want to create a restriction for, then select the operator

and value.f) Choose OK.

NoteFor a restricted column the aggregation type of the base column is applied.

TipYou can also create a restricted column based on the existing one by copying it and making the required changes. The copy paste option is available from the context menu of the calculated column. You can also use the CTRL + C and CTRL + V keyboard shortcuts. The copy paste functionality works only in the same editor, that is, if you copy a restricted column in one view editor you cannot paste it in another view editor. Also, if you copy a restricted column in one editor and go to another view editor and again copy another object, the paste option in the previous editor is not available. The copy paste functionality for restricted columns only works in the Output panel

5. Define Attributes and Measuresa) Select the Semantics node.b) In the Column panel, select the Local tab page, and change the type as attributes and measures.

NoteThe Shared tab page shows the attributes of the used attribute views. While generating the column views, the joined local attribute name is ignored and the shared attribute name is considered, therefore the joined local attribute is not shown on the Semantics node.

NoteYou can change the type of a measure and perform currency conversion by selecting it in the Local tab page and changing the Measure Type property in the properties panel.



6. Optional Step: Assign Semantics to Attributes, Measures, and Calculated Columnsa) To indicate what an attribute or a calculated attribute of an analytic view represent, in the Columns panel

toolbar of the Semantics node, choose Assign Semantics.b) In the Semantics dialog, select the required Semantics Type.

1. If you select Amount with Currency Code as Semantic Type, select an attribute or calculated column that represents the currency code in the Currency dropdown.

NoteAttributes and calculated columns having semantic type as Currency Code are highlighted for Currency selection.

2. If you select Quantity with Unit of Measure as Semantic Type, select an attribute or calculated column that represents the currency code in the Unit dropdown.

NoteAttributes and calculated columns having semantic type as Unit of Measure are highlighted for Unit selection.

3. Choose OK.The supported semantic types for attributes and calculated attributes are: Amount with Currency Code Quantity with Unit of Measure Currency Code Unit of Measure Date Date - Business Date From Date - Business Date To Geo Location - Longitude Geo Location - Latitude Geo Location - Carto Id Geo Location - Normalized Name

a) To indicate what a measure or a calculated measure of an analytic view represent, in the Columns panel toolbar of the Semantics node, choose Assign Semantics.1. If you select Amount with Currency Code as Semantic Type, in the Currency field, select a currency

code.

NoteYou can choose the currency from the system table TCURC or from an attribute of the view based on the currency type as Fixed or Column respectively.

2. If you select Quantity with Unit of Measure as Semantic Type, select a unit of measure in the Unit field.

NoteYou can choose the currency from the system table T006 and T006A or from an attribute of the view based on the unit type as Fixed or Column respectively.



3. Choose OK.7. Optional Step: You can filter and view the table data in the modeled view for a specific client as specified in the

table fields, such as MANDT or CLIENT, by doing the following:1. Select the Semantics node, in the Properties panel, edit the Default Client property.

NoteThe default value for the property is the one that is specified as a preference. If the property is set to Dynamic, at run-time the value set for the Session Client property is considered to filter table data. The Session Client property is set while creating a user. At run time, if the property is set to Cross Client, the table data is not filtered for any of the client systems.

8. Optional Step: Assign VariableYou assign variables to an attribute of the view at design time to filter data based on the values you provide for the variable. The variable values are interpreted as WHERE clause of the SQL statement by the clients/consumers like Data Preview, MDX, Advanced Analysis for Office or BO Explorer. At runtime, you can provide different values to the variable to view the corresponding set of attribute data.

9. If you want to parametrize currency conversion, calculated columns and Data Foundation filters, create input parameters.

10. Activate the view using one of the following options: If you are in the SAP HANA Modeler perspective, do the following as required:

Save and Activate - to activate the current view and redeploy the affected objects if an active version of the affected object exists. Otherwise only current view gets activated.

Save and Activate All - to activate the current view along with the required and affected objects.

NoteYou can also activate the current view by selecting the view in the SAP HANA Systems view and choosing Activate in the context menu. The activation triggers validation check for both the client side and the server side rules. If the object does not meet any validation check, the object activation fails.

If you are in the SAP HANA Development perspective, do the following:1. In the Project Explorer view, select the required object.2. In the context menu, select Team Activate .

NoteThe activation triggers the validation check only for the server side rules. Hence, if there are any errors on the client side, they are skipped and the object activation goes through if no error found at the server side.

NoteIf an active version of the affected objects exist, activating the current view redeploys the affected objects. In the SAP HANA Modeler perspective, even if the affected object redeployment fails, the current view activation might go through. However, in the SAP HANA Development perspective, if any of the affected objects redeployment fails, the current view activation also fails.



Note

RestrictionThe behavior of analytic views with the information model editor is as follows:When an object (a table of an attribute view) is removed and added again in an attribute view in order to reflect the recently modified columns with its data type, it reflects the previous state of the columns. To overcome this issue, you can close and open the editor, and then add the modified object. For more information, see SAP Note 1783668 .

11. In the Change Tracking dialog, either create a new ID or select the existing change ID. For more information about Change Tracking, see the section SAP HANA Change Management in the chapter Implementing Lifecycle Management of the SAP HANA Developer Guide.

12. Choose Finish .

Related Information

SAP HANA Developer Guide

3.4 Developing ProceduresSQL in SAP HANA includes extensions for creating procedures, which enables you to embed data-intensive application logic into the database, where it can be optimized for performance (since there are no large data transfers to the application and features such as parallel execution is possible). Procedures are used when other modeling objects, such as analytic or attribute views, are not sufficient.Some of the reasons to use procedures instead of standard SQL: SQL is not designed for complex calculations, such as for financials. SQL does not provide for imperative logic. Complex SQL statements can be hard to understand and maintain. SQL queries return one result set. Procedures can return multiple result sets. Procedures can have local variables, eliminating the need to explicitly create temporary tables for

intermediate results.Procedures can be written in the following languages: SQLScript: The language that SAP HANA provides for writing procedures. R: An open-source programming language for statistical computing and graphics, which can be installed and

integrated with SAP HANA.There are additional libraries of procedures, called Business Function Library and Predictive Analysis Library, that can be called via SQL or from within another procedure.



SQL Extensions for Procedures

SQL includes the following statements for enabling procedures: CREATE TYPE: Creates a table types, which are used to define parameters for a procedure that represent

tabular results. For example:

CREATE TYPE tt_publishers AS TABLE ( publisher INTEGER, name VARCHAR(50), price DECIMAL, cnt INTEGER);

SAP HANA Performance Analysis Guide en[1]

Documents

sap hana database

sap hana guideslinks

sap ag

sap hana platform edition

sap help portalhttp

sap affiliate company

sap service marketplacehttps

important sap notes