PUBLIC

openSAP
Using the Optimizer for SQLScript Programming in SAP
HANA

Week 2 Unit 1

00:00:05 Hello, my name is Tae Suk Son, and I’m Product Manager for SAP HANA and SAP HANA
Cloud.
00:00:12 I’m very happy to present the units for week two. What we have learned in week one
00:00:19 was the high-level overview of the SQLScript optimizer and its execution engine from both
Helen and Minjeong.
00:00:27 I hope that all of you got to understand how the SQLScript optimizer and its execution
engine works internally.
00:00:41 For this week, we will focus on a more practical knowledge based on what we have learned
last week.
00:00:49 How to use the SQLScript supportability features to understand how it is executed
00:00:54 and also resolve any performance issues that you may face. We have set up six units to
learn five supportability features
00:01:03 that are used for SQLScript. I will provide a demo for each feature,
00:01:08 so please follow the demo scenarios in your own system and try to use them for your own
purposes.
00:01:15 Being familiar with each of these features is very important to find out what is exactly
happening during its execution.
00:01:27 HANA SQLScript has many supportability features. Let me introduce them briefly in the
slide.
00:01:35 First of all, SQL Trace, Explain Plan, and Plan Visualizer are general tools for SQL queries,
but they are also very beneficial and have specialized features for SQLScript as well.

00:01:51 M_ACTIVE_PROCEDURES is a monitoring view showing active SQLScript procedures that

are currently in execution.
00:01:59 SQLScript Plan Profiler is a performance profiling tool, as its name suggests. SQLScript
Code Analyzer is a static code scanner
00:02:09 to search for patterns indicating problems in code quality, security and performance.
SQLScript Debugger is a tool to check SQLScript procedure
00:02:21 from a functional point of view. Type and length check for table parameters
00:02:29 is a feature about checking the inconsistency of type and length of table parameters. The
SQLScript Code Coverage
00:02:39 is a code coverage tool for your own SQLScript procedures. SQLScript Pragmas is a
special comment to pass more information
00:02:49 to the SQLScript compiler and the SQLScript Code Analyzer. Lastly, Query Export is an
enhancement of the EXPORT statement.
00:03:00 It allows exporting queries, that is database objects used in a query together with the query
string and parameters.
00:03:11 This query can either be standalone, or executed as a part of a SQLScript procedure. Out of
these many features,
00:03:25 we will focus on learning supportability features that are most helpful for investigating
performance issues during this course.
00:03:34 They are SQL Trace, Explain Plan of a CALL statement, Plan Visualizer for SQLScript,
M_ACTIVE_PROCEDURES monitoring view, and SQLScript plan profiler.
00:03:47 The SQLScript Code Analyzer is also a very useful tool to enhance performance. But it is
just a code scanner.
00:03:55 So I would like to skip the details for this course. Each of these supportability features have
different scope,
00:04:04 and it is very essential to know when you should use which ones. Sometimes it might be
enough to use a single feature,
00:04:13 but other times you have to use several features in parallel, or one by one to get the right
information you want.
00:04:22 Here’s an overall flowchart of how the SQLScript procedure is processed. The left side
shows a definition of SQLScript stored as metadata
00:04:33 using CREATE PROCEDURE or CREATE FUNCTION. As we learned during the first week,

00:04:39 when we execute a SQLScript procedure, the SQLScript engine compiles and optimizes it
first,
00:04:46 and then the execution plan for the SQLScript is generated. This execution plan is executed
by the SQLScript engine.
00:04:56 As you know, imperative programming constructs are dealt by the SQLScript engine, and
SQL statements are passed to the SQL engine for processing.
00:05:10 To check an execution plan which is the output of SQLScript optimization process, you can
use multiple features, such as Explain Plan for the CALL statement,
00:05:21 SQLScript Plan Profiler, and the Plan Visualizer for SQLScript. To check execution of
imperative programming constructs,
00:05:35 you can use SQLScript Plan Profiler, and the Plan Visualizer for SQLScript. If you want to
check the execution of inner SQL statements of a procedure,
00:05:51 you can use SQL Trace, SQLScript Plan Profiler, M_ACTIVE_PROCEDURES, and Plan
Visualizer for SQLScript.
00:06:05 Here’s a summary table describing the scope of each feature. As you can see, some
features have the same scope,
00:06:15 but their usage would be different. So, once you’re familiar with each of these supportability
features,
00:06:26 you can easily decide which one of them is best suited for performance analysis under the
circumstances.
00:06:43 As I explained earlier, the SQLScript Debugger and SQLScript Code Analyzer are also very
powerful tools,
00:06:50 but will not be covered in detail during this course, so I will just explain them briefly here.
The SQLScript Debugger is a tool to investigate functional and programmatical issues.
00:07:04 When you use the SQLScript debugger, a non-optimal execution plan is generated for the
purpose of just debugging.
00:07:13 The executed statements will not be inlined and will be executed individually for step-by-
step debugging purposes.
00:07:23 So, a separate plan will be generated just for debugging, and this means the debugging
execution of a procedure
00:07:32 would be different from the existing execution plan. The execution plan for debugging is not
considered at all
00:07:42 from a performance perspective. So the purpose is to just validate the control flow and
correctness of the execution.
00:07:52 The SQLScript Code Analyzer is a static code scanner to search for patterns indicating
problems in code quality, security, and performance.

2 / 20
00:08:04 Since this tool shows the scanned results regardless of actual execution, you can simply run
and check the report after writing SQLScript procedure code
00:08:15 without any execution. So please be aware that the result can include some false alarms,
00:08:22 due to the nature of the static code scanner. Before introducing each the features in detail,
00:08:31 we had a bird's eye view of the overall features available. As I emphasized,
00:08:39 it is very important to know which features should be used based on your situation. Roughly,
to check an execution plan,
00:08:49 which is an output of the SQLScript optimization process, you can use SQLScript Plan
Profiler, Explain Plan For CALL statements,
00:08:59 and Plan Visualizer for SQLScript If you want to see how SQLScript is executed, then SQL
Trace, SQLScript Plan Profiler,
00:09:11 M_ACTIVE_PROCEDURES, and Plan Visualizer for SQLScript are used. So, that’s it for
this unit.
00:09:23 For the next unit, we’re going to learn how to use SQL Trace, SQLScript Plan Profiler,
M_ACTIVE_PROCEDURES monitoring view,
00:09:33 Explain Plan For CALL statements, and Plan Visualizer for SQLScript one by one for each
unit.
00:09:41 So I hope to see you again for the next unit. And thank you very much.

3 / 20
Week 2 Unit 2

00:00:05 Hello, welcome back to unit two of week two. For this unit,
00:00:10 we'll look into using the SQL Trace for SQLScript. SQL Trace is a widely-used feature
00:00:20 to collect SQL statement execution details. It can capture preparation and execution of
queries
00:00:27 based on the filtering condition, and it shows much useful detailed information
00:00:35 about the executed SQL statements, such as the overall execution time of each statement,

00:00:44 memory consumption, the number of records that were affected,

00:00:50 potential errors, and also including the query plan. But SQL Trace is also very useful for
SQLScript.
00:01:01 From a user perspective, a CALL statement is explicitly executed by a user.
00:01:09 What I mean is that a user doesn't execute SQL statements within the SQLScript procedure
body one by one explicitly.
00:01:18 Instead, these inner SQL statements are executed as a child of the call execution.
00:01:25 So we can say that these inner SQL statements are executed internally. If you configure the
parameter internal
00:01:35 under the SQL Trace section as true, then you can collect the inner SQL statements
00:01:43 within the SQLScript procedure, like a trace or any other SQL queries.
00:01:49 See the picture on the right side showing the scope of SQL Trace.
00:01:55 SQL Trace checks query execution in the SQL engine level.
00:02:00 So it looks a little bit far from SQLScript processing itself,
00:02:05 but since SQLScript engine reshapes the statement string of an inner SQL query within the
procedure definition,
00:02:14 monitoring these inner SQL statements and the information of its execution
00:02:19 is sometimes very useful. So you can use this trace
00:02:24 if you want to check the inner SQL statements, reshaped by SQLScript optimizer,
00:02:32 find out the target inner queries that consumes high memory or causes slow execution.
00:02:40 Also check each executed SQL plan of the inner SQL statements.
00:02:47 And last but not least, see the intermediate results for each inner queries.
00:02:55 Now, we'll dig a little bit deeper and check how we can use the SQL Trace
00:03:04 to collect the necessary information for SQLScript. So now, we'll see how to set up the SQL
Trace for SQLScript.
00:03:17 Here, I've set up an SAP HANA Cloud instance, and I've connected using the HANA
database explorer
00:03:24 using the SQL console. So what I'll do is I'll create a SCHEMA OPENSAP
00:03:31 for the demos of this week, and I'll set the default SCHEMA to OPENSAP.
00:03:41 I'll create a table called TAB1 with a MATERIAL and FABRIC_ID as two columns
00:03:49 and enter a record into that table. I'll also create a result table type
00:04:00 that is identical to the table I just created, and this would be one of the output
00:04:06 of the procedures that I'll be creating. The first procedure I will create is P2,
00:04:13 with one input variable called F2, and the output of the table results.
00:04:19 And based on if the input is TA, then assign the filtering BI,
00:04:27 then select the record from that table and return it back, then assign it to the T_RESULT
output variable.

4 / 20
00:04:39 And then I have another P1 procedure that calls the P2 procedure underneath,
00:04:46 so the previous procedure that we have defined. I just pass along the input parameter into
the P2
00:04:56 and then the output variable is assigned to COMPOSITION and select the values of the
COMPOSITION
00:05:05 for the output of this procedure. So let me create that procedure.
00:05:12 And then the final procedure is called MY_PROC_01. And the input parameter would be an
integer.
00:05:21 If the input parameter value is greater than one, then select the values from the table from
TAB1,
00:05:29 and then assign the value plus one from TAB1, and then select the output of each into this
system.
00:05:45 So let me create that. Okay, so based on that, now let me clear out the plan cache.
00:06:04 So we will not use an existing plan, a compiled plan that was already created
00:06:11 in the SQL plan cache. So we just flushed out the entire SQL plan cache.
00:06:18 Then we'll turn on the SQL Trace. The first thing is we'll try to call
00:06:28 the procedure MY_PROC_01 with the literal value of 2. And as you can see, the result is 2.

00:06:40 The second result is the record in the table. The third result is added plus one.
00:06:50 Another type of procedure we'll call is the same procedure but using a placement
00:07:00 or parameter value type. So I'll put a question mark
00:07:04 in the procedure parameter value and execute it. So this time, it will pre-compile.
00:07:11 Then I'll put 2 and execute. And again, the result is 2.
00:07:18 The second result is the record from the table. The third result is added one
00:07:27 to the first value that was passed in. Now, I'll just turn off the SQL Trace.
00:07:39 And let's go to the sqltrace folder of the left navigation pane,
00:07:48 and we see a new SQL Trace file has been created. And double-click to open,
00:07:55 and it's open to the last line of the file. And with that information, it stores the detail
00:08:05 that we have turned off the SQL Trace using the ALTER SYSTEM
00:08:10 and turning off the SQL Trace. So we'll go back to the PowerPoint,
00:08:16 and I'll use the PowerPoint to explain the details of the SQL Trace.
00:08:24 I copied the screenshot from the result of the previous demo.
00:08:29 When you turn on SQL Trace, trace file shows when it starts and with which options.
00:08:38 Then you can see the execution of the CALL statement. You can see the same statement
string two times.
00:08:51 This is because the first one is for the preparation, and the other one is for the actual
execution.
00:09:00 COMPILE: 96 next to duration means it took 96 microseconds to compile this query string.

00:09:09 And SELECT: 76 means it took 76 microseconds to execute it.

00:09:20 Also, you can see the query string, which you didn't write in the procedure definition.
00:09:27 This SQL statement string is generated by the SQLScript optimizer based on the inline rule.

00:09:35 You can easily identify them from others by the additional comment prefixed with procedure.

00:09:41 This shows the procedure name, the location of the statement,
00:09:45 and the associated table variables. The inline SQL statements can vary
00:09:53 based on the CALL statement. I'm showing two cases here

5 / 20
00:09:59 based on how the procedure is called and resulting in how the statements are inlined.
00:10:07 The first case was based on using the parameter with literal values,
00:10:13 and the second case is using a parameter where the values are assigned.
00:10:21 Also, please check the naming rule for the persisted table variables,
00:10:26 which is referenced by a later inner SQL statement. Now, here are the key takeaways for
unit two.
00:10:38 The SQL Trace shows information of all executed SQL statements within the SQLScript
00:10:47 that has the inner SQL statements based on the system configuration parameter called
internal
00:10:54 in the SQL Trace section. It is important to know the exact actual SQL statements
00:11:01 that are being executed, as the SQL Script optimizer reshapes the inner SQL statements.
00:11:09 I hope that everyone got to understand the usefulness of the SQL Trace, even for
SQLScript,
00:11:17 and hope to see you again for the next unit, which is the SQLScript Plan Profiler.
00:11:24 Thank you.

6 / 20
Week 2 Unit 3

00:00:05 Hello, and welcome back to unit three of week two. For this unit, we'll look into the details
00:00:13 of the SQLScript Plan Profiler. The SQLScript Plan Profiler
00:00:20 is a performance analysis tool designed mainly for the purpose
00:00:25 of profiling the execution plan for stored procedures. The SQLScript Plan Profiler is enabled

00:00:35 as a singular tabular result, where a call statement is generated.

00:00:41 The result table contains information such as start time, end time, CPU time, wait time,
00:00:49 and some additional detailed information for each predefined operation.
00:00:55 The predefined operations can be anything that is considered of importance
00:01:01 for analyzing the performance of the stored procedure. It covers both the compilation and
execution times.
00:01:15 The tabular results are displayed in the monitoring view called
M_SQLSCRIPT_PLAN_PROFILER_RESULTS.
00:01:24 One thing to remember is that if the query is canceled or failed due to any reason,
00:01:30 it cannot capture the profiler results. The SQLScript Plan Profiler is recommended to use
00:01:39 when you want to first understand the entire process of how SQLScript is executed.
00:01:46 For example, compilation, execution, and parallelization information is given.
00:01:55 Second, find out which inner query consumes high memory or executes slowly.
00:02:03 The SQLScript Plan Profiler is an effective tool to monitor SQLScript optimization and
execution details.
00:02:14 Now let's look into the details of the SQLScript Plan Profiler using a demo.
00:02:24 I've created a new SQL console for the unit three demo, and I'll set the default schema to be
OpenSAP.
00:02:32 So we'll use the existing procedure and table that we created in unit two.
00:02:38 First of all, let me just clear out the SQL plan cache so that we're not using a pre-compiled
plan and
00:02:47 so that it will compile and execute when we call the procedure.
00:02:53 And we'll clear out any of the existing profile results. So one option to enable the SQLScript
Plan Profiler
00:03:02 is using the ALTER SYSTEM START, SQLSCRIPT PLAN PROFILER.
00:03:09 So using this, once this is executed for any SQLScript procedure calls,
00:03:16 that it will profile it. So let me just call P1 and stop the profiling...
00:03:29 and check the results. Here it was, the procedure was based on OpenSAP,
00:03:39 as you can see here. It started with the top level call of the P1 procedure
00:03:44 using the literal value of TA. The operators are nested with the depth of the operator.
00:03:54 So within the first level is Compile and Execution. Within Compile, the SQLScript is pre-
processed,
00:04:02 optimized, and the execution code or plan is generated. And the plan is analyzed
00:04:09 if it can be executed in parallel. Once the plan is generated, it will execute.
00:04:17 So based on the internal logic, it will execute the inner SQL statement
00:04:26 or the inlined SQL statement, and based on the literal value
00:04:30 this is what was inline for this procedure. So what this has done is that between the
00:04:46 ALTER SYSTEM START SQLSCRIPT PLAN PROFILER and the STOP SQLSCRIPT PLAN
PROFILER,

7 / 20
00:04:54 any procedure call will be profiled. So it may be a lot of information by using this option.
00:05:03 So there are multiple ways to filter down to a specific logic or execution of a procedure.
00:05:13 And one option is using the connection ID. So to check how we can do that,
00:05:19 let me again clear out all the SQL plan cache, clear out the existing profile results,
00:05:29 and make sure that the profile results is empty. Let's check what is the current connection
ID
00:05:38 from the system? It is 201391.
00:05:44 And make sure that I'm using the ALTER SYSTEM START SQLSCRIPT PLAN PROFILER
00:05:50 for a specific session connection ID, which is 201391. So I will just enable the profiling for
this connection.
00:06:06 This time, instead of using a literal value, I will use a parameterized value
00:06:16 as the call for the procedure. When I execute this call P1,
00:06:23 it actually goes into the system and compiles it without executing.
00:06:29 So the compilation is already done. And now let me put the value TA and execute.
00:06:40 So here the results are the same as before. Let me stop the profiling,
00:06:48 and then let's check the results. So here the call to the P1 was using a parameterized value
of GA.
00:07:06 But as you can see, the compilation was not profiled. Because when we passed on the TA
value
00:07:13 and profiling the execution, the compilation was already compiled and cached
00:07:20 as part of the initial call using a question mark. So with such a parameterized queries,
00:07:30 only the execution of plan is profiled. And based on the literal value and the parameterized
value,
00:07:41 you can see that the control flow within the procedure itself is very different
00:07:49 from the example below. And also the inline SQL statement is very different.
00:07:58 So even though the values are the same and the logic may be somewhat identical,
00:08:05 but since the value has been passed later on and the compilation was done in a different
way.
00:08:12 Means that the optimization was a bit different and that the internal execution is different
00:08:19 between a literal value and a parameterized value. So that is one option.
00:08:28 Another option, using the session as a filtering condition for profiling a procedure.
00:08:38 Another option is to limit to a specified procedure. So we know which procedure we want to
profile.
00:08:47 So instead, we're using the ALTER SYSTEM START SQLSCRIPT PLAN PROFILER for
procedure P1.
00:08:56 So to test that again, let's clear out the SQLScript Plan Profiler
00:09:04 and check that it is empty again. We will not clear out the SQL plan cache
00:09:12 because we know what step operators are executed for the compilation.
00:09:19 So we'll just focus on the execution part. So we'll physically name it,
00:09:29 filter for a specified parameter and call with the literal value,
00:09:37 and stop the profiling once executed. And now let's check the values.
00:09:49 And as you can see, the compilation was done, the execution was done.
00:09:56 This is because when we first cleared it, the literal value TA plan was gone.
00:10:03 So this was compiled first, again, because there was no value with the literal value.
00:10:10 We had the parameterized call. But since the hash value is different,
00:10:16 this is a new plan or new statement hash and a new plan to be compiled and executed.
00:10:25 Another option is to use a call. And then instead of using an ALTER System,

8 / 20
00:10:36 we'll use a hint, a call for SQLScript Plan Profiler. So we'll just clear out the results again,
00:10:47 and make sure that it's empty. We'll call PAT1 with the hint...
00:10:57 and then check the results. So if we use this hint, as you can see,
00:11:06 there are three result tabs. The first result is for the call itself.
00:11:13 Which is returning one record. And since we use the hint,
00:11:17 it automatically returns the profile results with the compile and execution.
00:11:26 And since we've added WITH HINT at the end of the statement itself,
00:11:32 again the statement hash is different from the previous call.
00:11:36 So it actually compiled and executed. And the third result is using
00:11:49 Calling the Profiler Results. So the monitoring view itself is not populated,
00:11:58 but with the hint itself, then the values are executed with the result.
00:12:05 So, there are two results with the plan, with the call statement,
00:12:11 where the one result is the actual result of the call itself,
00:12:16 and the second result set is related to it the using the hint.
00:12:23 And this time, since I called this call statement again, the compile part was not executed
00:12:31 and only the execution part was actually being executed. And let me clear that again.
00:12:42 And then this time, we'll use the parameterized value with TA. So like I've mentioned, it
already compiled
00:12:53 in the background. Then I execute with this parameter value.
00:13:00 Again, it returns two results. The result of the actual call itself,
00:13:06 and the result for the parameterized value call. Okay, and then let's make sure
00:13:17 that we clear the results and the demo. Let's look into the details
00:13:27 of the SQLScript Plan Profiler results, copied from the demo.
00:13:32 If the SQLScript procedure was executed for the first time, the SQL Plan Profiler shows the
detailed compilation,
00:13:40 and any additional optimization steps are shown in the upper red box.
00:13:46 Finally, the execution steps are shown in the green box. If the call is already cached and
compiled
00:13:54 only the execution are shown, as in the lower example. When calling a SQLScript stored
procedure,
00:14:03 using different parameter values the execution steps may be different,
00:14:09 based on the imperative logic and optimization. As explained in week one,
00:14:18 the actual SQL statement executed will be reshaped, because several statements may be
inlined and combined
00:14:26 during the SQLScript optimization steps. As we have seen using the SQLTrace,
00:14:35 a comment is prefixed containing the name of the procedure, the name of each table
variable used,
00:14:42 with line and column positions accordingly. The table variables are listed first,
00:14:48 with the resultset being assigned as T_RESULT table variable.
00:14:52 And then followed by table variable called T_TABL, which is the inlined part of the executed
SQL statement.
00:15:01 During SQLScript optimization, the table variable will be converted to be unique.
00:15:08 If the result set needs to be persisted, it will be done as a local temp table,
00:15:14 and then referenced later in the inlined SQL statements that will be executed.
00:15:21 As we have also seen in the SQLTrace example. As part of each step,
00:15:28 detailed step information is collected. Such as START_TIME, END_TIME, DURATION,
ACTIVE_TIME_SELF,

9 / 20
00:15:37 ACTIVE_TIME_CUMULATIVE, CPU_TIME_SELF, CPU_TIME_CUMULATIVE,
USED_MEMORY_SIZE_SELF, and USED_MEMORY_SIZE_CUMULATIVE.
00:15:44 You can find the details in the table below. For further information,
00:15:50 please refer to our help documentation, help.sap.com for more detailed information.
00:16:00 Now let's look at the key takeaways from unit three. The SQLScript Plan Profiler
00:16:07 is a performance analysis tool showing how a procedure is actually running.
00:16:13 The results are shown in the M_SQLSCRIPT_PLAN_PROFILER_RESULTS monitoring
view.
00:16:20 And the SQLScript Plan Profiler can be triggered at system level
00:16:26 using the ALTER SYSTEM START SQLSCRIPT PLAN PROFILER for multiple procedures.
00:16:33 Or using a SQL HINT called SQLSCRIPT_PLAN_PROFILER for individual call statements.
00:16:44 As with other tools, it cannot collect the results
00:16:47 if the execution has been canceled or failed due to any reason.
00:16:53 To summarize, you can check the control flow logic, check the execution plan of the
SQLScript procedure,
00:17:00 and the actual executed SQL statements with statistics for each step.
00:17:08 I hope everyone got to understand the usefulness of the SQLScript Plan Profiler.
00:17:14 For the next unit, we will look into the details
00:17:17 of the M_ACTIVE_PROCEDUREs of Monitoring View. Thank you.

10 / 20
Week 2 Unit 4

00:00:05 Hello, welcome to unit four of week two. For this unit we'll look into the details
00:00:10 of M_ACTIVE_PROCEDURES monitoring view. The M_ACTIVE_PROCEDURES
Monitoring View
00:00:16 shows all executed SQL statements starting from a procedure call,
00:00:21 except for the SQLScript compilation step. It also includes any remotely executed SQL
statements.
00:00:29 M_ACTIVE_PROCEDURES monitoring view is very much like the
M_ACTIVE_STATEMENT view
00:00:35 but it keeps all the records completed until the top-level parent procedure has finished.
00:00:44 The information is shown in a hierarchical order of nested call stack.
00:00:50 You can see the content only during the time when the parent procedure is actually running
by default.
00:00:58 Once the parent procedure is finished, the content of the procedure call will be deleted.
00:01:07 For on-prem HANA, if you want to keep the content even after the execution, you can
configure
00:01:15 number of calls to retain after execution or retention period for SQLScript context
parameters
00:01:26 in the section of the SQLScript to keep them after the execution has applied. But for SAP
HANA Cloud,
00:01:34 keep in mind that these cannot be changed. Now let's look into the
M_ACTIVE_PROCEDURES
00:01:42 using a live demo. For unit four, we'll look into
00:01:49 using the M_ACTIVE_PROCEDURES monitoring view to check the current running
procedure.
00:01:59 And to do that we have to make sure that the procedure is running for a longer duration.
00:02:05 And what we have done is we've added a SLEEP_SECONDS with the value of 10. So the
procedure will sleep for 10 seconds before finishing the procedure itself.
00:02:19 So here we've set the default schema to be OPENSAP and then modify the procedure P1
00:02:28 with the added sleep at the end of the procedure. And now we'll call the procedure itself.
00:02:36 So it is now being executed for 10 seconds. And we'll use...sorry.
00:02:48 So let me execute that again. And then while it's running, we'll use the previous console
00:02:57 to check the procedure itself for P1. Here, as you can see, it shows the
M_ACTIVE_PROCEDURES
00:03:10 with the statement hash within the procedure itself. So it's only showing the call procedure,

00:03:20 the inner statement, which is the inline SQL statement.

00:03:28 As we have seen with the plan profiler, the SQL trace that the statement itself is identical.
00:03:40 And then the final result, key result table is sent back from the temporary table
00:03:52 as a result set by the procedure. So here, these two have been finished,
00:04:01 because we put the sleep at the end and the execution of the top-level call is still being
executed.
00:04:15 So what we can do is, again, before doing a P2 call,
00:04:23 maybe we can move the sleep at the top and again, modify it,
00:04:31 call it again. And while it's running,
00:04:41 again, execute the monitoring view. And this time it's still executing the initial call

11 / 20
00:04:51 because it has not executed the inner statements yet. And then once the execution is
finished,
00:05:06 the information is gone from this monitoring view. So HANA cloud,
00:05:14 there isn't an option to enable it before the on-prem that as you have the system-level
access,
00:05:24 then you can modify the system to retain the information, which we will explain during the
session.
00:05:33 I've copied the results of the demo, and let's look into the details.
00:05:38 It shows all SQL statements within the call stack, starting from the top-level call
00:05:43 with the statement status and depth. It also shows other useful statistics
00:05:48 such as statement, compile, execution, and materialization time. Also, it shows memory-
related statistics as well.
00:06:00 Now let's review the key takeaways. The M_ACTIVE_PROCEDURES Monitoring View
shows information
00:06:07 of all executed inner SQL statements that are actively running on the fly.
00:06:13 The monitoring can be done without any prerequisites. So it can be monitored if a
SQLScript procedure
00:06:20 is running for a long time and if it's unexpectedly running slower than usual.
00:06:27 So now let's recap. The M_ACTIVE_PROCEDURES is useful to check the execution
00:06:33 of the inner SQL statement on the fly. So I hope this unit will help you investigate
00:06:40 the SQLScript procedures that is executing abnormally. For the next unit,
00:06:46 we'll look into using the explain plan for SQLScript. Thank you.

12 / 20
Week 2 Unit 5

00:00:06 Hello, welcome to unit five of week two. For this unit, we'll look into the details
00:00:12 of using the EXPLAIN PLAN for the SQLScript. The EXPLAIN PLAN provides information
00:00:18 about the compile plan of a given SQLScript procedure without execution.
00:00:26 The information is stored in the EXPLAIN_CALL_PLANS table, and shows operators, inner
query strings,
00:00:34 and execution engines, and also displays whether the inner queries
00:00:40 will be executed in parallel or sequentially. It also recommended to use this when you want
to see
00:00:49 the compile plan of the SQLScript without actually executing it.
00:00:55 The compile plan of SQLScript will contain the inner final optimized statement string,
00:01:02 the sequential or parallel execution information, and SQLScript logics such as loops or
conditions.
00:01:11 But it doesn't show the EXPLAIN PLAN of the inner SQL statements.
00:01:17 You can check the query plan of these inner queries by collecting the SQL Trace
00:01:23 or using the EXPLAIN PLAN of the plan ID of the inner statements that are stored in the
SQL plan cache.
00:01:34 So now let's look into the details of the EXPLAIN PLAN via a demo.
00:01:43 For this unit, we'll look into the EXPLAIN PLAN for SQLScript CALL statements.
00:01:51 So again, I've created a new SQL console for unit five. I'll set the default schema to be
OPENSAP.
00:02:02 I'll make sure that I delete any existing EXPLAIN PLAN calls, just in case.
00:02:13 And I've named one type of Explain Plan as 'P1' and the other one with 'P?'.
00:02:20 So 'P1' is for the literal value and the 'P?' is for the parameterized argument. So, to use the
EXPLAIN PLAN,
00:02:32 we use the statement called EXPLAIN PLAN SET STATEMENT_NAME = then we assign a
statement name for it:
00:02:43 and then for the call procedure itself. So, we can call it for the 'P1'
00:02:50 using the literal value assigned to 'P1', STATEMENT_NAME. And for the parameterized
argument,
00:02:59 we'll call it and assign it to 'P?' But I'm not sure if you have noticed
00:03:08 that when we call EXPLAIN Plan for the parameterized argument, it did not ask me to enter
the parameter value.
00:03:21 Because the EXPLAIN PLAN is not a physical execution plan.
00:03:28 It is just looking at the logical plan without actually executing the plan itself.
00:03:37 So, it is only compiling the SQLScript and making sure what the logic will be if you execute
for that procedure.
00:03:54 So, let's get the results from that EXPLAIN PLAN. So, using the EXPLAIN_CALL_PLANS
monitoring view
00:04:06 for the SQLScript CALL statements, we can get the information from this monitoring view.
00:04:21 So, Result 1 table is for the literal value. So, as you can see, the operator
00:04:28 is the call with the literal value. The sequential op, initial op, expression.
00:04:38 As you can see, it has the sleep seconds that I've added in my previous example.
00:04:45 The inline inner SQL statement that is shown. So it shows the actual SQL statements that
would be run within.
00:04:56 And the table variable that it will be assigned to. So, it's going to assign it to T_RESULT_1.

13 / 20
00:05:09 And also finally, we'll save it into this local temp table and select the values from this local
temp table as a result set.
00:05:29 The Result 2 is for the parameterized value. So, there is some additional logic compared
00:05:41 to the literal ones. But the logic is very similar,
00:05:45 except that the inlined inner SQL statement is a bit different because it does not know the
prefixed value.
00:05:57 So, the logic is somewhat different. But still, the result is assigned
00:06:03 to the T_RESULT_1, table variable, and then saved inside a local temp variable as well.
00:06:18 Here I've cleared the SQL plan cache. And let me call this again twice.
00:06:27 So, it's been called twice for each type of the procedure calls. And if I do a SELECT again
00:06:38 from the EXPLAIN_CALL_PLANS monitoring view, I get two repeated values.
00:06:48 And as you can see, since this is just a logical compile, it does not really matter regarding
the SQL plan cache,
00:06:57 because it will always use the same compilation to make sure to get the EXPLAIN PLAN
results.
00:07:10 So, it's not actually using the SQL plan cache because it was never being executed,
00:07:16 but just compiling them and giving you back the results
00:07:21 from this monitoring view. Also same for the parameterized value ones
00:07:28 where it's showing the identical information, but repeated twice because I called them twice.

00:07:37 Okay, let me just delete and make sure that there's nothing existing in this monitoring view.

00:07:50 And for SAP HANA Cloud, there is a faster way. Instead of entering all the statement,
explain plans
00:07:58 that statement equals something, and for the procedure call, you can directly highlight the
CALL statement,
00:08:09 and under the Analyze section, select the Explain Plan or use the Ctrl + Shift + Z key or the
hotkey
00:08:21 to get the EXPLAIN PLAN information. And as you can see,
00:08:26 the information that was returned is identical. If we check the monitoring view,
00:08:39 it will not exist in the monitoring view. So, this Analyze itself is actually returning back as
with
00:08:49 the call statement itself and throwing back the results, but not storing them in the monitoring
view.
00:08:56 I've copied the results of the demo in this slide, and let's look into the details.
00:09:02 The SQLScript shows the logical execution plan. So it's not based on an actual execution.
00:09:10 But there is no information of the inner query plans of the SQL statement.
00:09:18 Now, let's recap for the EXPLAIN PLAN. The key takeaway for this unit is that the EXPLAIN
PLAN shows the execution plan
00:09:30 that is an output of the SQLScript optimization process without actual execution.
00:09:36 So, it does not show any actual query execution plan of the inner SQL statements. So, this
is just useful for quickly checking
00:09:46 the execution plan of the SQLScript procedure without any execution.
00:09:53 So that's it for this unit. And for the last unit of week two,
00:09:58 we will look into the Plan Visualizer for SQLScript. Thank you.

14 / 20
15 / 20
Week 2 Unit 6

00:00:05 Hello, and welcome to unit six of week two. This is the last unit for this week.
00:00:12 We'll look into the Plan Visualizer, especially in the context of using it with SQLScript
analysis.
00:00:20 The Plan Visualizer is a tool that shows the execution plan and any additional information
00:00:27 about its actual execution in a visual graph format. The tool is mostly used for single SQL
statement analysis,
00:00:37 but it also has useful features for analyzing the SQLScript procedures.
00:00:45 Currently, there are two options for doing the analysis. The first option is using the new SQL
analyzer tool,
00:00:55 which is the recommended tool going forward. This tool can be executed on-prem as a
standalone,
00:01:02 or by using the Visual Studio Code extension. Also, it can be executed from the cloud
00:01:10 as part of the SAP Business Application Studio. The two interfaces are identical.
00:01:18 So you can install the on-prem version on your own computer, or use the tool
00:01:24 from the cloud without having to relearn the tool. The second option is to use the SAP
HANA Studio
00:01:33 or PlanViz perspective, but we have officially deprecated it.
00:01:41 So the new features are only introduced with the new SQL analyzer tool.
00:01:48 Now let's briefly review the information that is available using SAP HANA Studio.
00:01:55 As you already know, the overview page shows several important KPIs required
00:02:01 for performance analysis. It should be your starting point to get the overview
00:02:08 of the executed statement before going into the complex details for analysis.
00:02:15 The statement statistics page is only available once a stored procedure is called
00:02:24 and it displays a set of statistics for each of the inner SQL statements involved
00:02:30 in a procedure. The Executed Plan page shows the actual execution
00:02:38 of both imperative programming constructs and SQL statements.
00:02:45 Another useful page is looking at the Timeline chart. It shows when the operator is
executed, and the duration,
00:02:54 and also if the operator is running in parallel. Now let's look over the new SQL analyzer tool.

00:03:07 As mentioned, it is provided for both on-prem and cloud to analyze the performance of SQL
and SQLScript.
00:03:17 It supports all features that are available with SAP HANA Studio,
00:03:22 such as loading multiple PLV files for analysis, visualizing the query plans in PLV as a plan
graph,
00:03:32 visualizing the critical path, to find the hotspot regarding performance.
00:03:39 In addition to that, we have added several features like bookmarking,
00:03:44 adding comments, and sharing them with your colleagues so that you can keep the history
of the analysis.
00:03:51 We also improve the usability by using advanced UI techniques and also connecting
00:03:57 to a live SAP HANA system for a real-time analysis. Now let's take a look at the new SQL
analyzer
00:04:06 and compare them with the existing SAP HANA Studio. Like SAP HANA Studio, we can
start with the overview page.
00:04:16 As you can see, it shows more detailed information compared to SAP HANA Studio.

16 / 20
00:04:23 We have the execution summary, and this card shows the total compilation
00:04:29 and execution times of the query. It also shows the start time, peak memory usage,
00:04:36 number of operators and edges. And also lets you see the compilation summary
00:04:42 or exception details when it's available. We also have dominant plan operators,
00:04:50 which is showing the top five most time-consuming operators based on their execution time.

00:04:59 Additional information is the data usage showing the statistics of data usage for the query
execution, this display.
00:05:08 Also, if the query involves a Virtual Table, it shows the number of remote sources
00:05:15 and Cross DB Access, if the access is against another tenant of the database.
00:05:23 Keep in mind that the Cross DB Access is only available for the on-prem,
00:05:29 as multi-tenancy is not available for SAP HANA Cloud. Additional information is the
distribution,
00:05:37 which is for a scale-out environment, also for on-prem, and shows the number of SAP
HANA indexer pairs.
00:05:45 And shows the node distribution and network transfers involved with the query execution.
00:05:53 The next information is the context, showing the entire SQL query and the number of
parameters.
00:06:00 Finally, we have the system information showing the host information and the SAP HANA
version.
00:06:09 One of the biggest differences compared to SAP HANA Studio is that we provide links that
can go down
00:06:17 into more detailed information, just from the overview page.
00:06:24 As with SAP HANA Studio, the new SQL analyzer also supports the STATEMENT
STATISTICS page.
00:06:31 It shows the statistics information for the inner SQL statements.
00:06:39 But the key difference here is supporting the analysis of just the inner SQL statement.
00:06:45 The PlanViz graph for the entire procedure would most likely be very big
00:06:50 and difficult to navigate and analyze. So you would like to just narrow down
00:06:58 into a single statement. So you click on the open link within the deep dive column,
00:07:04 which shows a copy of just that statement where it's open. We also have compilation
summary
00:07:14 and it shows the detailed information of the compilation, but it will be only available when
the execution was done
00:07:22 with the compile. Next is the plan graph,
00:07:26 and we'll look into the details during the demo. Another key difference is the SQL page
showing
00:07:33 the entire SQL statement. Whereas SAP HANA Studio, it only shows a portion
00:07:38 of the SQL statement up to a certain length. It also shows the session context
00:07:46 and parameter values whenever it's available. Also, the timeline information is available
00:07:54 in the new tool as well. Now let's look into the details via a demo of the tool.
00:08:06 Now let's check how we can use the Plan Visualizer for SQLScript.
00:08:12 I've created a new SQL console within the SAP HANA Database Explorer, and again,
00:08:18 we'll set the default schema to be 'OPENSAP' so that we will reuse the existing tables
00:08:25 and stored procedures. Also, we will clear up the SQL plan cache
00:08:31 so that when we call the stored procedure, we will actually be compiling it
00:08:37 and then executing the procedure. Now to generate a plan graph for the SQLScript
procedure,

17 / 20
00:08:49 we will generate it for the entire call procedure statement. And to do that, within the SAP
HANA database explorer,
00:09:01 we'll go to the analyze menu and we will select the generate SQL Analyzer Plan File menu.

00:09:11 Once we do that, it will ask me for a prefix, so I prefix it with OPENSAP
00:09:20 and then we'll append the statement execution ID with the PLV extension and save that.
00:09:28 So now it is actually executing the stored procedure and generating the plan graph.
00:09:36 Once it is generated, it will be saved in the server in this file path
00:09:44 and you can see that it is under the other folder. but we can directly download it from this
pop-up menu.
00:09:55 Now click download and it will automatically download to my download folder
00:10:01 as it is the default behavior for the web browser. So let me close that
00:10:08 and close this dialog box, and within the other folder,
00:10:15 let me refresh it by clicking it again, and you can see that OPENSAP and the new PLV file
have been generated.
00:10:26 Now let me go to the Visual Studio Code, and I'm running the Visual Studio Code,
00:10:34 and I've already installed the SAP HANA SQL analyzer. But just to let you know,
00:10:40 that the SQL analyzer tool for SAP HANA is available in the Visual Studio Code
marketplace, and you can search
00:10:53 for SQL analyzer tool for SAP HANA and install it. And once installed, the icon
00:11:00 for the SQL analyzer will be shown on the left pane. Also, there is the SAP HANA Database
Explorer extension,
00:11:11 which is very similar to the web version or cloud version that you have seen earlier,
00:11:18 which is also installed within the Visual Studio Code. But for this demo, let me concentrate
on the SQL analyzer,
00:11:30 and to open that PLV, within the left pane, there is the plan graphs
00:11:38 and clicking on the plus sign, I have the option to open. And let me open the one that I just
saved,
00:11:47 which is the top one with the latest timestamp, and open that one.
00:11:55 And it shows the execution summary, the dominant plan operators, the statement statistics,

00:12:02 as I've mentioned, the plan graph, and the SQL for the call statement.
00:12:11 Here within the plan graph, I can drill down into more details.
00:12:18 Going back to the overview in the execution summary, I have the compilation time
00:12:24 and the execution time for this statement. Also the start time and the peak memory,
00:12:32 number of operators, and number of edges are displayed. Also, the top plan operators, it's
all hyperlinked.
00:12:41 So I can click any one of them. And the majority of the time is the sleep that I've added
00:12:49 to the stored procedure. I can click that, and it will directly take me
00:12:55 to the operator where it is calling the sleep library. And also, as you can see, whenever I
click an operator,
00:13:06 the 'last 10 visited' is updated with the operator that I just selected being on the top.
00:13:14 And it is shown in reverse chronological order of the 'last 10 visited'.
00:13:24 And on the left of the operator selected, there are two small icons.
00:13:30 The first one is the bookmark, where I can create a new bookmark.
00:13:36 So testing bookmark and save it.
00:13:46 And this information will be saved within the PLV. Another option is to use the comments.

18 / 20
00:13:56 So whenever I click on the comment icon, it will take a screenshot of the operator that was
selected
00:14:03 as the center of the screenshot, and also the hyperlink to take me back to that operator.
00:14:10 And then here I can enter in comments and send it.
00:14:23 So basically, it's like a conversation. So, whenever I have this file saved in a central
location,
00:14:30 opened by multiple people and each person has entered their own email address,
00:14:37 then I would see my comments on the right side, while the other comments from other
people will be shown on the left side.
00:14:48 Now going back to the statement statistics, I have two inner SQL statements.
00:14:55 One is the inline one, where it is actually getting the data from the internal tables.
00:15:04 And the second one is reading the local temp table where the results
00:15:09 are temporarily stored and then sent back as results. Now, let me open the first inner
statement,
00:15:17 and what it did was it created a new PLV file saying that it is an inner plan of the existing
PLV file.
00:15:27 And it has the same information like the execution summary, the dominant plan operators,
it's showing the plan graph,
00:15:36 and the SQL that was used for this statement. And as you can see, the plan graph is just
limited
00:15:45 for that individual inner SQL statement. So, I can focus on just this SQL statement
00:15:54 and look at the timeline for this statement alone, and narrow down any of the hotspots
00:16:03 where I'm seeing majority of the time taken, which would be the Group By here.
00:16:13 Okay, so that's it for the demo and let's go back to the slide for the key takeaways for this
unit.
00:16:28 So now we'll look at the key takeaways for this unit. The Plan Visualizer visualizes an
execution plan
00:16:36 and its execution in a graph format. It also contains the imperative programing constructs
00:16:44 and query operation nodes of each SQL statement. Keep in mind that the SQL analyzer tool
is the successor
00:16:53 of the existing SAP HANA Studio. So it is recommended to use the latest SQL analyzer tool.

00:17:04 And that is it for week two. I hope that you got to understand all the various tools
00:17:11 for analyzing the SQLScript. And for next week,
00:17:15 my colleague Jin Yeon will guide you on how to tune for the SQLScript.
00:17:23 Thank you.

19 / 20
© 2023 SAP SE or an SAP affiliate company. All rights reserved.
See Legal Notice on www.sap.com/legal-notice for use terms,
disclaimers, disclosures, or restrictions related to SAP Materials
for general audiences.