Introduction:

This is the third article in the series of Analysing Stats in HANA.  In this article we'll explore the statistics related to query execution time.

Here is the link to first and second part of the series Analysing Stats in HANA for Audit or ROI perspective. Analysing Stats in HANA for Audit or ROI perspective - Part 2

3. HANA Model: Query Runtime Stats

This is actually quite straight forward and we'll use the "SYS"."M_SQL_PLAN_CACHE" view as the source for our model.  You can execute a simple SQL query on the table or can browse it using   [Adminstration Perspective] -> [Performance] -> [SQL Plan Cache] .

Please refer to the SAP HANA Reference guide more details on M_SQL_PLAN_CACHE view.

The collection of SQL plan cache statistics is enabled by default. You can disable it on the SQL Plan Cache tab by selecting Configure.

The plan_cache_size value is in bytes. 2147483648 means 2GB.  Since there is a size time (in my case it is 2GB), HANA by default will keep only the last 2GB of sql cache, the older data will be deleted.

Building the Models:

Step 1:  Understanding the dataset:  The "SYS"."M_SQL_PLAN_CACHE" provides statistics on compiled queries. Here, you can view frequently executed queries and slow queries, which allows you to find potential candidates for optimization.

We're interested in the following scenarios and fields.

• Dominant statements: (TOTAL_EXECUTION_TIME)
• Long-running statements: (AVG_EXECUTION_TIME)
• Frequently-executed plans: (EXECUTION_COUNT)
• Statements with high lock contention: (TOTAL_LOCK_WAIT_COUNT)
• Last execution of a Query (LAST_EXECUTION_TIMESTAMP)
• List of users (USER_NAME)
• Memory Usage of the Query (PLAN_MEMORY_USE)

Step 2:Enhancing the dataset:  Since there is a size time (in my case it is 2GB), HANA by default will keep only the last 2GB of sql cache, the older data will be deleted.

So to meet our long term reporting requirement, we need to persist the data.

• Create a column table "_SYS_BI"."Z_SQL_PLAN_CACHE" (you may create the table in any other schema). This must have the same structure as that of "SYS"."M_SQL_PLAN_CACHE".
• Create two additional "auto generated column"  (Package Name & Cube Name as below) in "_SYS_BI"."Z_SQL_PLAN_CACHE". As you see below, we are deriving the package name and cube name from the SQL query (STATEMENT_STRING).

alter table "_SYS_BI"."Z_SQL_PLAN_CACHE" ADD(

CATALOG_NAME NVARCHAR(256) generated always as SUBSTR_AFTER(SUBSTR_BEFORE(SUBSTR_BEFORE(RPAD(SUBSTR_AFTER(STATEMENT_STRING,'_SYS_BIC'),LENGTH(SUBSTR_AFTER(STATEMENT_STRING,'_SYS_BIC'))+1,' '),' '),'/'),'."'),

CUBE_NAME NVARCHAR(256) generated always as SUBSTR_BEFORE(SUBSTR_AFTER(SUBSTR_BEFORE(RPAD(SUBSTR_AFTER(STATEMENT_STRING,'_SYS_BIC'),LENGTH(SUBSTR_AFTER(STATEMENT_STRING,'_SYS_BIC'))+1,' '),' '),'/'),'"')

);

• Create comment on the new columns in "_SYS_BI"."Z_SQL_PLAN_CACHE"

COMMENT ON COLUMN "_SYS_BI"."Z_SQL_PLAN_CACHE"."CATALOG_NAME" is 'Package Name';

COMMENT ON COLUMN "_SYS_BI"."Z_SQL_PLAN_CACHE"."CUBE_NAME" is 'Cube Name';

• Copy the records from "SYS"."M_SQL_PLAN_CACHE" to "_SYS_BI"."Z_SQL_PLAN_CACHE".  Please note you have to copy the records periodically. You can  use LAST_EXECUTION_TIMESTAMP to establish the delta mechanism for copying the records.

insert into "_SYS_BI"."Z_SQL_PLAN_CACHE"

select * from "SYS"."M_SQL_PLAN_CACHE"

where IS_INTERNAL = 'FALSE';

Step 3: Building the data model: This is rather straight forward with a simple projection node. I'm using the following filters to select queries only on HANA views (you can change it to fit your acquirement)

• IS_INTERNAL = FALSE
• CATALOG_NAME <> '' (blank)
• CUBE_NAME <> '' (blank)

Results:

1. Query Performance:

2. Last use (of Models):