SQL tuning sets

Abstract

A method of storing one or more database query language statements and performance information for each statement as a persistent database object is disclosed.

Description

FIELD OF THE INVENTION

This invention is related to the field of electronic database management.

BACKGROUND

In a database management system, SQL statements are used to manipulate data and to retrieve data that matches certain selection criteria. A SQL statement is compiled in memory before being executed by a database engine. Though the compiled form of the SQL statement may be cached in memory for some amount of time for repeated executions, it is eventually discarded. Therefore SQL statements can be considered transient objects in a database system.

In practice, the set of SQL statements used by an application are repeatedly executed, and the same SQL statements can be frequently compiled into memory and executed. Also, some statements, when executed, place a high load on the system by consuming a large amount of system resources, which causes the system's performance to suffer. If knowledge about the frequency or load demands of certain SQL statements is available, then this knowledge can be used to tune these statements by adding controls to improve the performance of these SQL statements.

However, obtaining knowledge about the frequency or load demands for these statements is complex and sometimes impossible. For example, the number of SQL statements that are executed by a database system can be very large and thus very difficult to manage. Conventional database systems typically do not persistently store executed statements and performance information about each statement. The conventional systems are therefore unable to provide a sufficient amount of performance information about the executed statements to identify which statements are consuming a substantial amount of resources. Also, conventional database systems are unable to allow a database administrator (DBA) to filter or rank the executed statements based on their performance characteristics.

A need exists for a method to persistently store SQL statements and their performance information into a database as an object that can be used in a performance analysis such as a comparison of system performance between different time periods. Also, a need exists to identify high load SQL statements.

SUMMARY

A method of storing one or more database query language statements and performance information for each statement as a persistent database object is disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of a device that can collect a STS, persistently store the STS, and provide a portion of the STS as an input to an auto-tuning optimizer.

FIG. 2 shows an example of creating and using SQL tuning sets.

FIG. 3 is a block diagram of a computer system suitable for implementing an embodiment of SQL Tuning Sets.

DETAILED DESCRIPTION

Overview

The embodiments of the invention are described using the term “SQL”, however, the invention is not limited to just this exact database query language, and indeed may be used in conjunction with other database query languages and constructs.

A SQL tuning set (STS) is used to persistently store a set of SQL statements, along with their related performance information, as a database object which can be used to manage and tune the set of statements. The performance information for the statements that are stored in the STS includes execution measurements and execution context of each statement. The contents of the STS can be customized and processed as first class objects. For example, they can be filtered, ranked, loaded, updated, and deleted. The contents of the STS can be used to identify high load SQL statements that consume a significant amount of system resources. The identified statements can then be automatically tuned using their related performance information.

With the STS, a workload of SQL statements, including their performance environment and statistics, can be collected from multiple sources. The STS can then be analyzed to identify a relevant subset of SQL statements, such as high load statements, by filtering and ranking the statements in the workload using criteria such as performance statistics. The STS therefore provides a mechanism for capturing and managing SQL workloads. With this information about the high load statements, a tuning process can be performed to improve the execution of each statement in the STS.

In addition to targeting high load SQL statements, the SQL tuning set can also be used to, for example, capture all or a representative set of statements (high load or not) for a given application, along with their performance information, and use it to compare performance degradation after a potential change in the application environment. For example, if a user wants to upgrade the application, the database itself or change a database parameter that can affect the workload and the corresponding performance of the application, the user can capture such non high-load statements, because they might become high load after the change. The STS can therefore allow the SQL workload comparison to include their execution statistics and plans from before the change. Another example of a SQL tuning set feature is an incremental capture from these data sources, which allows DBAs to capture statements multiple times within a user-specified interval, thus reducing the probability of losing statements due to cursor aging.

FIG. 1 shows an example of a device that can collect a STS, persistently store the STS, and provide a portion of the STS as an input to an auto-tuning optimizer. An execution plan for a statement is received from compiler 110 and executed by engine 120. The statement, and information related to the statement, are automatically stored in a automatic workload repository (AWR) 130. The contents of the AWR can be filtered by an automatic database diagnostic monitor (ADDM) 140, to automatically select high-load statements from the AWR, or can be filtered by a user 150, to manually select statements for tuning. A set of the selected statements and their related information are used to create SQL Tuning Set 160. Each statement in the STS 160, and its related information, can be input to auto-tuning optimizer 170. The optimizer 170 generates tuning hints for the statement based on the information from the STS, and places the hints in a profile 180 that can be stored in tuning base 190. The profile can be retrieved by compiler 110 to generate a well-tuned execution plan.

Creating the STS

The problematic statements and their related information can come from several sources, including an Automatic Workload Repository (AWR), a cursor cache, another SQL tuning set, or from a customized workload created by a user. The SQL statements can also be captured or extracted from other sources like PL/SQL packages, stored procedures and also SQL trace. The AWR stores performance and system data for statements executed during a specified time period, or snapshot. Each snapshot is a persistent store of information that provides a consistent view of the database system for the time period.

The statements stored in a snapshot of the AWR can be automatically identified by the database system via an Automatic Database Diagnostic Monitor (ADDM), based on a contribution of the statements to an overall workload of the system. The ADDM can automatically identify root causes of top performance bottlenecks and excessive resource consumption, along with the impact on the processing time of the workload. The ADDM can also provide recommendations for alleviating these burdens on the system. For example, the ADDM can identify high load statements, create a STS for the statements, and recommend that the statements in the STS are each automatically tuned. This is one example of using the SQL tuning set for automatic capture and tuning. The DBA can also decide to manually capture, process filter and rank his set of representative SQL statements, either from AWR or directly from the cursor cache, and than invoke SQL tuning advisor or compare the workload performance information with information captured during a different period.

The STS objects can also be created and managed using manual directives issued by a database administrator (DBA). This manual process can be used by the DBA to tune the response time of a subset of SQL statements for a specific function of a database application, even if that function accounts for a small percentage of the overall workload. For instance, the DBA can create a STS to store performance information for each SQL statement executed between 8 am and 5 pm on a given day having a number of fetches above a certain threshold.

Multiple SQL tuning sets can be created, where each tuning set corresponds to a different SQL workload processed by the database server. For example, after creating the STS for statements executed between 8 am and 5 pm, another STS can be created for batch queries issued between midnight and 2 am. These different SQL tuning sets can then be independently accessed by an auto-tuning optimizer to tune the SQL statements using an auto-tune process.

Contents of the STS

The information stored for each statement in the STS can include metadata for the STS and the SQL statements stored in the STS, such as a STS name, owner. The STS name uniquely identifies the STS for a particular user (STS owner). The information stored in the STS also includes performance information for each statement, such as execution context and execution statistics. This allows the optimizer to consider the runtime environment of each statement during the tuning process. This information can also be used during SQL workload comparison.

The execution context can include a user schema, a name and action of the application program issuing the statement, a list of bind values, and system environment information. The name and an action attribute of the application for the statement can be used by a consumer of the STS as a filter. The system environment information can include a set of optimizer related initialization parameters for the executed statement.

The execution statistics can include averages for statistics such as the number of buffer gets, disk reads, rows processed, and executions performed, can be built from the source and stored in the STS. An optimizer cost field in the STS stores the cost of the execution plan for the statement. An object list includes a list of objects accessed by the statement. Time information related to the statement can include a last execution time, which is the last time the statement was executed during the population period. Also, the time information can include the time period during which the execution statistics were created. The content of the SQL tuning set can also include multiple execution plans for the statements. For example, the SQL tuning set can capture and store multiple plans for a given statement. The STS can also include the list of objects referenced within a SQL statement.

Manipulating the Content of the STS

The content of the STS can be processed by functions such as insert new or additional information, updating existing information, computing missing information, delete information, rank the information, or perform queries on the information. Thus, the STS can be treated as a table having rows of SQL statements and columns of attributes. For example, a filter can be applied to a STS to select a desired subset of SQL statements, such as high load statements. The filter may be a relational expression used as a where clause on one or more execution statistics or context fields of the STS or any combination of them. The ranking measurement can be an order-by clause on the SQL statements. The statements can be filtered with multiple ranking measurements, which reduce or prevent ties between statements.

An arithmetic expression on execution statistics, such as cpu time, buffer gets, disk reads, elapsed time, executions, rows processed, optimizer cost, last execution date for example, can be used as the ranking filter. The ranking filter can rank the statements based on the ranking measurement, then can select the “top N” statements for this measurement. A “top N” predicate which is a constant number is provided to specify a result limit L of top statements. A percentage P filter is also provided to represent a percentage on the sum of a ranking measurement and can be used to select the top SQL statements that contribute to P percent of the overall sum. The limit L is used to select the top L SQL statements from the filtered source, as ranked by the ranking measurement. If both a limit L and a percentage P of top statements are specified, then the top SQL statements that contribute to P percent of the sum on the ranking measure, up to a maximum of L statements, are returned.

For instance, a set of SQL statements can be ordered using cpu time as the ranking measurement. The subset of these statements which contribute to 90 percent of the total cpu time in the set of statements can be selected. A result limit of 5 statements can be used to return no more than 5 statements of the subset.

FIG. 2 shows an example of creating and using SQL tuning sets. One or more SQL statements, and performance information for each SQL statement, is gathered from a source and stored in a STS as a persistent database object, 210. The SQL statements in the STS are filtered based on the performance information, 220. A portion of the filtered statements are identified as resource intensive statements, 230. The identified resource intensive statements and the performance information for each resource intensive statement is stored in a second STS as a second persistent database object, 240. Then, an auto-tuning process can be used for automatically tuning each statement in the second persistent database object 250, as discussed in the following example.

Using the STS to Automatically Tune High Load Statements

An example of a method of using the STS to perform automatic tuning can include creating the STS, populating the STS, filtering high load statements in the STS, tuning the high load statements in the STS, then dropping the STS. For example, if a DBA wants to reduce an I/O bottleneck on the system during peak hours, SQL statements that are I/O intensive can be tuned. First, a STS is created for the I/O intensive workload by specifying a name, such as ‘I/O peak’ and description, such as ‘I/O intensive workload on April 10 from 8 am to 11 am.’

After creating the STS, it is populated with the desired SQL statements and their performance statistics from one of the sources. The STS can be populated with I/O intensive statements from the workload repository or directly from the cursor cache during the peak period. One or more filters can be used to identify the I/O intensive statements in the workload repository and place them in the STS. SQL statements that have been executed for example, at least ten times and have a disk-read/buffer-get ratio greater than 50 percent for the peak period are chosen. These statements can then be ordered by (disk-read/buffer-get). The top 30 statements can be selected to populate the STS.

Once the STS is created and populated, the DBA can browse through the STS and select some of the statements for further review. For example, each statement with a (disk-reads/buffer-gets) ratio >75 percent can be marked to have a high priority comparing to the rest of statements in the SQL tuning set.

The unmarked statements can be deleted from the STS. Then, for each statement in the STS, an auto-tuning optimizer can be for example used to read the statement from the STS, analyze the statement, and automatically generate tuning actions for the statement. The tuning actions can be placed in a SQL profile and stored in a tuning base. Then, when the statement is compiled, the profile for the statement can be retrieved from the tuning base and used to generate an execution plan. In this example, the tuning information in the profile allows the compiler to generate an execution plan that reduces the 1/O bottleneck of the system. After each statement in the STS is tuned, the STS can be dropped.

FIG. 3 is a block diagram of a computer system 300 suitable for implementing an embodiment of SQL Tuning Sets. Computer system 300 includes a bus 302 or other communication mechanism for communicating information, which interconnects subsystems and devices, such as processor 304, system memory 306 (e.g., RAM), static storage device 308 (e.g., ROM), disk drive 310 (e.g., magnetic or optical), communication interface 312 (e.g., modem or ethernet card), display 314 (e.g., CRT or LCD), input device 316 (e.g., keyboard), and cursor control 318 (e.g., mouse or trackball).

According to one embodiment of the invention, computer system 300 performs specific operations by processor 304 executing one or more sequences of one or more instructions contained in system memory 306. Such instructions may be read into system memory 306 from another computer readable medium, such as static storage device 308 or disk drive 310. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.

The term “computer readable medium” as used herein refers to any medium that participates in providing instructions to processor 304 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 310. Volatile media includes dynamic memory, such as system memory 306. Transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 302. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave, or any other medium from which a computer can read.

In an embodiment of the invention, execution of the sequences of instructions to practice the invention is performed by a single computer system 300. According to other embodiments of the invention, two or more computer systems 300 coupled by communication link 320 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions to practice the invention in coordination with one another. Computer system 300 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 320 and communication interface 312. Received program code may be executed by processor 304 as it is received, and/or stored in disk drive 310, or other non-volatile storage for later execution.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.

Claims

1. A method comprising: storing one or more database query language statements and performance information for each statement as a persistent database object.

2. The method of claim 1, further comprising: filtering the statements based on the performance information

3. The method of claim 2, further comprising: identifying a portion of the filtered statements as resource intensive statements.

4. The method of claim 3, further comprising: storing the resource intensive statements and the performance information for each resource intensive statement as a second persistent database object.

5. The method of claim 4, further comprising: automatically tuning each statement in the second persistent database object.

6. The method of claim 1, wherein the database query language statements are SQL statements.

7. An apparatus comprising: means for storing one or more database query language statements; and means for storing performance information for each statement as a persistent database object.

8. The apparatus of claim 7, further comprising: means for filtering the statements based on the performance information

9. The apparatus of claim 8, further comprising: means for identifying a portion of the filtered statements as resource intensive statements.

10. The apparatus of claim 9, further comprising: means for storing the resource intensive statements and the performance information for each resource intensive statement as a second persistent database object.

11. The apparatus of claim 10, further comprising: means for automatically tuning each statement in the second persistent database object.

12. The apparatus of claim 7, wherein the database query language statements are SQL statements.

13. A computer readable medium storing a computer program of instructions which, when executed by a processing system, cause the system to perform a method comprising: storing one or more query language statements and performance information for each statement as a persistent database object.

14. The medium of claim 13, wherein the computer program, when executed, further performs the method comprising: filtering the statements based on the performance information.

15. The medium of claim 14, wherein the computer program, when executed, further performs the method comprising: identifying a portion of the filtered statements as resource intensive statements.

16. The medium of claim 15, wherein the computer program, when executed, further performs the method comprising: storing the resource intensive statements and the performance information for each resource intensive statement as a second persistent database object.

17. The medium of claim 16, wherein the computer program, when executed, further performs the method comprising: automatically tuning each statement in the second persistent database object.

18. The medium of claim 13, wherein the query language statements are SQL statements.