DB2 SAP执行计划
You can use this function to explain all SELECT, INSERT, UPDATE or DELETE statements.The statements may contain optional comments such as --OPTLEVEL( <optlevel> ) --QUERY_DEGREE(< query_degree> --LOCATION( <report> , <position> ). If no comments are specified, the statements are explained using the default <optlevel> and default <query degree> for the work process.
You can call the EXPLAIN function in the following ways:
[*]
Call transaction DB6COCKPIT and choose Diagnostics EXPLAIN in the navigation frame of the DBA Cockpit. On the Diagnostics: EXPLAIN screen, enter an SQL statement manually and choose
Explain.
[*]Call transaction ST04 and choose Performance Applications in the navigation frame of the DBA Cockpit. For more information, see Applications: Statements.
[*]Call transaction ST04 and choose Performance SQL Cache Snapshot in the navigation frame of the DBA Cockpit. For more information, see Performance: SQL Cache Snapshot.
[*]Call transaction DB6COCKPIT and choose Diagnostics Cumulative SQL Trace in the navigation frame of the DBA Cockpit. For more information, see Diagnostics: Cumulative SQL Trace.
[*]Call transaction ST05 and choose Explain one SQL request. Enter an SQL statement manually and choose Explain.
If a statement cannot be explained, the ERROR: Check SQL Statement screen appears providing a detailed error message and the possibility to modify the statement. To continue, choose
Explain Again.
[*]Call transaction ST05 and choose Trace List. Select one statement and choose Explain .
ST05中查看Statement
Access Plan of a Statement
If a statement was explained successfully, the Display Execution Plan for SQL Statement screen appears, providing information on the SQL statement text, the OPTLEVEL andQUERY_DEGREE that was used to explain this statement, and the access plan.
The access plan generated by the DB2 optimizer is displayed as a tree structure. It consists of all database operations that will be performed when the statement is executed.
The estimated execution time is displayed in timerons (arbitrary IBM time unit). All operators are numbered, starting with zero. Operators can have the following extensions:
Extension
Description
/
Shows whether the operator acts as an outer/inner input branch for a subsequent join operation.
(<Partition>)
Shows on which partition this operation was performed. This is only displayed if you are using a multi-partition database.
Non-volatile tables and indexes of non-volatile tables are displayed in blue. Volatile tables and indexes of volatile tables are displayed in orange.
For each index used in the access plan, the number of key columns, that means index fields that were really used within the access plan, are displayed.
For further analysis of the displayed information, you can choose from various options in the application tool bar. For more information, see EXPLAIN Options.
On the Display Execution Plan for SQL Statement screen, the following options are available:
Option
Description
Details
If no operator in the access plan is highlighted when choosing this option, a dialog box is displayed providing detailed information on the statement and each operator. This output is similar to the one of the DB2 command line tool db2exfmt. For more information, see the IBM documentation Administration Guide, Appendix I.
If operator no. 0 is highlighted, only the original statement and optimized statement are displayed in a separate dialog box.
If any other operator is highlighted, the system displays detailed information on the selected operator only.
Optimizer
The access plan may vary depending on the optimizer parameters specified. When you choose this button, the Change Query Optimization dialog box appears where you can change the parameters OPTIMIZER LEVEL, QUERY DEGREE and the flagVOLATILE for the tables used in the access plan. To explain the statement with new parameters, choose
Explain Again.
DB Catalog
With this option, you can display system catalog information on tables and indexes that are shown in the access plan. The following information is displayed:
For a table:
Selected information from table SYSCAT.TABLES is displayed. Additionally, all indexes of the table are displayed with their index columns.
For an index:
Selected information from table SYSCAT.INDEXES for this index is displayed. Additionally, selected information from table SYSCAT.COLUMNS is displayed for all index columns.
Depending on whether you have selected a table or an index, the following buttons are available:
Table
Displays selected information from table SYSCAT.TABLES. Additionally, all indexes of the table are displayed with their index columns.
Columns
Displays selected information from table SYSCAT.COLUMNS for all table columns
Indexes
Displays information from table SYSCAT.INDEXES for all indexes of the table as well as information from table SYSCAT.COLUMNS for all index columns
Update Statistics
Updates the catalog statistics for the table. If the catalog statistics were updated successfully, the field <stats-time>is displayed in green.
Table
Displays selected information from table SYSCAT.TABLES. Additionally, all indexes of the table are displayed with their index columns.
Dictionary
With this option, you can display the ABAP Dictionary structure (definition) of a table by selecting the table in the access plan.
If you do not select a table in the access plan, the ABAP Dictionary structure (definition) of the first dictionary object of the SQL statement is displayed.
With this option, you can display the structure of views, even though views never appear in the access plan.
This function is only available for RFC-monitored systems.
Test Execution
This option is only available, if a:
SELECT statement is explained using transaction ST05 Trace list, the parameter values for all parameter markers of the statement are provided and the operation is other than PREPARE.
SELECT statement without parameter markers is explained.
When you use the EXPLAIN function, the entered SQL statement isonly prepared and the access plan of the optimizer is chosen because of the system catalog statistics. On the basis of this information the optimizer estimates the costs for the execution of this statement.
However, the estimated costs may not correspond to the real execution time. Reasons for this might be bad statistics, a bad database layout or problems of the optimizer itself.
The Test Execution option measures the real execution time and provides other snapshot data, such as the number of buffer pool accesses and sorts for the selected statement. When the statement is executed, the parameter markers are replaced by the actual parameter values. A dialog box appears where you can change these values to investigate the dependence of the execution time from these values.
The result of several test executions of the same statement can vary because, for example, the buffer pool may already contain data that is necessary for the execution.
This function is only available for RFC-monitored systems.
Tree Info
The following additional information is displayed or hidden:
num_rows
Estimated number of rows (result set)
tot_cost
Estimated total cost for this statement
i/o_cost
Estimated I/O cost of the statement
This information is also included in the output information when you choose Details.
Edit
When choosing this option, the system switches to an editor window in which you can modify the selected SQL statement and re-explain it.
Source
This option is only available when the statement contains a LOCATION comment, for example, when you call EXPLAIN using transaction ST05 Trace list.
The location of the statement in the ABAP source code is displayed in a separate window.
This function is only available for RFC-monitored systems.
Collect
For systems that are monitored using remote database connections, this function cannot collect all necessary information. Therefore, a couple of error screens will appear when you execute this function. However, you should ignore these error screens and the function continues to gather as much information as possible.
For a detailed analysis of a statement you might need to download important information. You can use this option to download data to your local machine (the presentation server) and to execute the DB2 export on the database server.
When you choose Collect EXPLAIN Information, a dialog box appears where you can select data to download:
DB2 Level
Registry Variables
DBM Configuration
Database manager configuration
DB Configuration
Database configuration
Table Structure
Structures of the tables involved in the statement and all views defined in the database
Tablespace Configuration
Statistics
Statistics of the tables involved in the statement
Explain
EXPLAIN information of executable db2exfmt including the access plan
Under Path and Filename on Local Machine, you specify the path and file name where the selected information should be stored. The output is stored on your local computer. You can change the path by choosing Browse for folder. The default path is /tmp on UNIX and the value of the environment variable TEMP on Windows. The default file name is <SAPSID>_<current timestamp>. The files are stored in ASCII format.
If you want to analyze the download directly on the screen, Display Download on Screen must be activated. By default, this flag is activated.
For a more detailed analysis, DB2 support might need the output of the DB2 export. To display this option, choose
Display More/Less. By default, this option is deactivated. To activate it, selectDB2 Export on DB Server and choose Continue.
The files are stored on the database server in the path and file name you specified under DB2 Export on Database Server. The default file name is sysibm and the default path is /tmp on UNIX and the value of the environment variable TEMP on Windows. The files are stored in IXF format (integrated exchange format), which allows the tables to be recreated for test purposes.
You can ignore warnings on truncated data.
==========================================================================
A volatile table is defined as a table whose contents can vary from empty to very large at run time. The volatility or extreme changeability of this type of table makes reliance on the statistics collected by RUNSTATS inaccurate. Statistics are gathered at, and only reflect, a point in time. To generate an access plan that uses a volatile table can result in an incorrect or poorly performing plan. For example, if statistics are gathered when the volatile table is empty, the optimizer tends to favor accessing the volatile table using a table scan rather than an index scan.
To prevent this, you should consider declaring the table as volatile using the ALTER TABLE statement. By declaring the table volatile, the optimizer will consider using index scan rather than table scan. The access plans that use declared volatile tables will not depend on the existing statistics for that table.
这玩意应该是db2特有的
通常执行计划根据统计信息来的
但是由于volatile table的变化非常大
统计信息对它来说是不准确的
有的时候会错误的选择了全表扫描而不是索引扫描
而声明以volatile的方式访问
就是指定使用索引的方式来执行计划
From <http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/t0005308.htm>
页:
[1]