Mentioning Other Tools

Objective

After completing this lesson, you will be able to mention other tools.

SQLScript Code Analyzer

The SQLScript Code Analyzer is a tool that is used to scan the code of functions and procedures to search for patterns indicating potential problems in code quality, security, and performance.

In the Web IDE Database Explorer, choose Analyze SQLScript Code from the context menu of a database, container, schema, procedure, or function.

Screenshot showing the SQLScript Code Analysis Results.

The tool looks for issues in the code relating to the following:

  • Consistency

  • Style

  • Security

  • Performance

SQLScript Code Analyzer - 12 Checking Rules

RULE_NAMECATEGORY

COMMIT_OR_ROLLBACK_IN_DYNAMIC_SQL

STYLE

DML_STATEMENTS_IN_LOOPS

PERFORMANCE

ROW_COUNT_AFTER_DYNAMIC_SQL

BEHAVIOR

ROW_COUNT_AFTER_SELECT

BEHAVIOR

SINGLE_SPACE_LITERAL

CONSISTENCY

UNCHECKED_SQL_INJECTION_SAFETY

SECURITY

UNNECESSARY_VARIABLE

CONSISTENCY

UNUSED_VARIABLE_VALUE

CONSISTENCY

USE_OF_CE_FUNCTIONS

PERFORMANCE

USE_OF_DYNAMIC_SQL

PERFORMANCE

USE_OF_SELECT_IN_SCALAR_UDF

PERFORMANCE

USE_OF_UNASSIGNED_SCALAR_VARIABLE

CONSISTENCY

As of SAP HANA 2.0 SPS07, there are twelve rules which are defined in system view SQLSCRIPT_ANALYZER_RULES.

  • UNNECESSARY_VARIABLE: Each variable is tested to identify if it is used by any output parameter of the procedure or if it influences the outcome of the procedure. Relevant statements for the outcome could be DML statements, implicit result sets, or conditions of control statements.

  • UNUSED_VARIABLE_VALUE: If a value assigned to a variable is not used in any other statement, the assignment can be removed. In case of default assignments in DECLARE statements, the default is never used.

  • SINGLE_SPACE_LITERAL: This rule searches for string laterals consisting of only one space. If ABAP VARCHAR MODE is used, such string literals are treated as empty strings. In this case, CHAR(32) can be used instead of ' '.

  • USE_OF_UNASSIGNED_SCALAR_VARIABLE: Detects variables which are used but were never assigned explicitly. Those variables will still have their default value when used, which might be undefined. We recommend that you assign a default value (can be NULL) to be sure that you get the intended value when you read from the variable.

  • USE_OF_CE_FUNCTIONS : Checks whether Calculation Engine Plan Operators (CE functions) are used. Since they make optimization more difficult and lead to performance penalties, they should be avoided.

  • DML_STATEMENTS_IN_LOOPS: Detects the following DML statements inside of loops: INSERT, UPDATE, DELETE, UPSERT. Sometimes it is possible to rewrite the loop and use a single DML statement to improve performance instead.

  • USE_OF_SELECT_IN SCALAR_UDF: Detects if SELECT is used within a scalar UDF which can lower the performance. If table operations are really needed, procedures or Table UDFs should be used instead.

  • UNCHECKED_SQL_INJECTION_SAFETY: Parameters of string type should always be checked for SQL injection safety if they are used in dynamic SQL. This rule checks if, for any such parameter, the function is_sql_injection_safe was called. For a simple conditional statement like IF is_sql_injection_safe(:var) = 0 THEN..., the control flow in the true branch is checked. The procedure should either end (by returning or by throwing an error) or the unsafe parameter value should be escaped with the functions escape_single_quotes or escape_double_quotes, depending on where the value is used. If the condition is more complex (for example, more than one variable is checked in one condition), a warning will be displayed as it could only be checked if any execution of the dynamic SQL has passed the SQL injection check.

  • COMMIT_OR_ROLLBACK_IN_DYNAMIC_SQL: Detects dynamic SQL which uses the COMMIT or ROLLBACK statement. Since COMMIT and ROLLBACK can be used directly in SQLScript without the need of dynamic SQL, it is recommended to use them directly.

The SQLScript Code Analyzer is launched in the SAP Web IDE Database Explorer from the context menu of:

  • Database: To scan all procedures and function in the database (launched from the catalog DB connection type)

  • Schema: To scan all procedures and function in a specific schema (launched from the catalog DB connection type)

  • Container: To scan all procedures and function in a specific HDI container (launched from the HDI container connection type)

  • Procedure: To scan a specific procedure

  • Function: To scan a specific function

You can download the results of a code analysis to a .CSV file. Use the download button in the results screen.

SQL Analyzer

The SQL Analyzer is a tool that is used to check the runtime performance of your SQL statements. The tool can help you evaluate potential bottlenecks and optimizations for these queries.

First screenshot showing the Analyze SQL option. Second screenshot showing the Overview tab with multiple tiles and multiple views.

You launch the SQL Analyzer by using the drop-down menu from the Execute button.

Note

Be careful not to confuse SQL Analyzer with SQL Code Analyzer.

Once launched you can navigate the various views that contain the following information:

  • Overview: Displays tiles that expose a summary of the key information. Useful for a quick glance.

  • Plan Graph: This view provides graphical guidance to help you understand and analyze the execution plan of an SQL statement.

  • Timeline: This view provides a complete overview of the execution plan based on the visualization of sequential time stamps.

  • Tables Used: This view provides a list of tables used during query execution and includes further details on tables, which can be used for further analysis. It can be used to understand which tables are needed to fulfill a given SQL statement.

  • Operator List: This view provides a list of operators used during query execution and includes additional details about each operator, which can be used for analysis.

  • Statement Statistics: This view is only displayed in the case of an SQLScript. This view provides details on the statistics of the executed statements in the SQLScript.

  • Table Accesses: Number of records returned and filter values used, and so on.

Based on the analysis, if needed, the following changes can be performed for optimization:

  • Change the SQL statement.

  • Change the data model.

  • Change the physical design.

  • Add SQL hints to statements.

SQL Debugger

You can step through the code and examine the run time behavior of your procedures and functions using the SQLScript Debug tool.

First screenshot showing the SQLScript Debugger. Second screenshot showing the contents of the BEST_COLORS variable.

You call the debugger from the Database Explorer view of SAP Web IDE by right-clicking any procedure or function and choosing Open for Debugging. You must then attach a debug session to the procedure or function. This is where you choose a database connection on which to run the debug session.

Then you set the breakpoints in your code. Do so by double-clicking on the code line and you will then see a breakpoint marker. You can optionally set conditional breakpoints where an expression is entered that must be true to stop the code.

Finally, right-click anywhere in the code and use the option Call Function or Call Procedure. You will be presented with the SQL calling statement where you can insert any input variables if applicable. Launch the procedure or function using F8 and the code will stop at the first breakpoint where you can examine the contents of any variables or parameters.

Use the control buttons to step through the code.

Note

Don’t forget to check the debug session time-out value in the Web IDE Preferences.

SQL Hints

SAP HANA Hints Categories

Hints are instructions for the SAP HANA database server which influence and enforce a certain access path of the optimizer.

  • Hint syntax in SQL statements / hint validation
  • Hints for controlling request processing / cache behaviors
  • Hints for scale-out environment
  • Hints for OLAP Engine, ESX Engine and HEX Engine selection
  • Hints for HEX enumeration decisions
  • Hints for Join Engine optimization

The system view that lists and details hints is SYS.HINTS;

If there is the need to test the effectiveness of the cost-based Optimizer within SAP HANA, the usage of hints can be very helpful. As a default, the SQL Optimizer selects the best access path (for example, to choose or not to choose an index) on the basis of the costs. You can influence the SQL Optimizer selection by using hints in the affected queries by providing the appropriate hint.

After analyzing the SQL Optimizer execution plan, it could be the case that the chosen plan appears not ideal anymore and a new plan sounds more effective. In this particular case it is possible to select the hint IGNORE_PLAN_CACHE out of the category ‘Hints for Controlling Request Processing‘ to check if this assumption is correct without deleting the plan cache that has been used before.

Another situation that could occur is the problem of dominant operators prevent filtering before joining huge amounts of data. In this case, it is possible to select the hint CS_JOIN_REDUCTION out of the category ‘Hints for Controlling Request Processing‘ to test the start of the reduction with a different table.

At time of writing, the System View Hints of SAP HANA Cloud shows 371 hints.

SAP Note 2400006 comprises a FAQ for SAP HANA Statement Hints and numerous tips for their usage.

Caution

Using hints needs to be handled with absolute care. They can cause situations to become worse right away or over time. It is rare that human intervention in the optimization process will produce a better plan than the Optimizer would on its own.

Cascading of Hints

Starting with SPS07, the Call Statement for the execution of stored procedures supports the cascading of hints into internal SQL statements. This cascading takes place after parsing and checking the syntax phase and after the logically and physically optimization phase. When there are nested Call Statements, cascade hints are propagated into the nested procedures.

Code Snippet
123
CALL "get_results" IM_CATEGORY=>'Notebooks', IM_TYPECODE=>'PR',RESULTS=>?) WITH HINT(USE_HEX_PLAN) CASCADE;
  • Allows hint propagation into internal SQL statements
  • An internal procedure is a procedure that is called by another procedure
  • The hint is applied to outermost procedure as well
  • Allows hint propagation into nested SQL statements of the same procedure body
  • Takes place after optimization phase of optimizer

The hint is applied to both the Call Statement itself and any internal SQLs that will be called within the body (cascading).

The following, with regards to other logic SQL constructions, are currently valid:

  1. Cascade is only supported in Call Statements and cannot propagate hints into UDFs.
  2. If Cascade is used for Non-Call Statements, a feature not supported message appears.