Chapter 11

1. Chapter 11 Database Performance Tuning and Query Optimization Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel

2. In this chapter, you will learn: • Basic database performance-tuning concepts • How a DBMS processes SQL queries • About the importance of indexes in query processing • About the types of decisions the query optimizer has to make

3. In this chapter, you will learn (continued): • Some common practices used to write efficient SQL code • How to formulate queries and tune the DBMS for optimal performance

4. 11.1 Database Performance-Tuning Concepts • Goal of database performance is to execute queries as fast as possible • Database performance tuning • Set of activities and procedures designed to reduce response time of database system

5. Database Performance-Tuning Concepts (continued)

6. Database Performance-Tuning Concepts (continued) • All factors must be checked to ensure that each one operates at its optimum level and has sufficient resources to minimize occurrence of bottlenecks • Good database performance starts with good database design

7. Performance Tuning: Client and Server • Database performance-tuning activities can be divided into: • Client side • Objective is to generate SQL query that returns correct answer in least amount of time, using minimum amount of resources at server end • SQL performance tuning • Server side • DBMS environment must be properly configured to respond to clients’ requests in fastest way possible, while making optimum use of existing resources • DBMS performance tuning

8. DBMS Architecture • All data in database are stored in data files • Data files • Automatically expand in predefined increments known as extends • Generally grouped in file groups of table spaces • Table space or file group is logical grouping of several data files that store data with similar characteristics

9. DBMS Architecture (continued)

10. DBMS Architecture (continued) • DBMS retrieve data from permanent storage and place it in RAM • Data cache or buffer cache is shared, reserved memory area that stores most recently accessed data blocks in RAM • SQL cache or procedure cache is shared, reserved memory area that stores most recently executed SQL statements or PL/SQL procedures, including triggers and functions

11. DBMS Architecture (continued) • An input/output request is low-level (read or write) data access operation to/from computer devices • Working with data in data cache is many times faster than working with data in data files because DBMS doesn’t have to wait for hard disk to retrieve data • Majority of performance-tuning activities focus on minimizing number of I/O operations

12. Database Statistics • Refers to number of measurements about database objects and available resources • Tables • Indexes • Number of processors used • Processor speed • Temporary space available • Make critical decisions about improving query processing efficiency • Can be gathered manually by DBA or automatically by DBMS

13. Database Statistics (continued)

14. 11.2 Query Processing • DBMS processes queries in three phases • Parsing (剖析): The DBMS parses the SQL query and chooses the most efficient access/execution plan • Execution: The DBMS executes the SQL query, using the chosen execution plan • Fetching: The DBMS fetches the data and sends the result set back to the client

15. SQL Parsing Phase • Breaking down (parsing) query into smaller units and transforming original SQL query into slightly different version of original SQL code • Fully equivalent • Optimized query results are always the same as original query • More efficient • Optimized query will almost always execute faster than original query

16. SQL Parsing Phase (continued)

17. SQL Parsing Phase (continued) • Query optimizer analyzes SQL query and finds most efficient way to access data • Access plans are DBMS-specific and translate client’s SQL query into series of complex I/O operations required to read the data from the physical data files and generate result set

18. SQL Parsing Phase (continued)

19. SQL Execution Phase • All I/O operations indicated in access plan are executed SQL Fetching Phase • Rows of resulting query result set are returned to client • DBMS may use temporary table space to store temporary data

20. 11.3 Indexes and Query Optimization • Indexes • Crucial in speeding up data access • Facilitate searching, sorting, and using aggregate functions as well as join operations • Ordered set of values that contains index key and pointers • More efficient to use index to access table than to scan all rows in table sequentially • Data sparsity determines whether index is needed

21. Indexes and Query Optimization (continued)

22. 11.4 Optimizer Choices • Rule-based optimizer • Uses set of preset rules and points to determine best approach to execute query • Cost-based optimizer • Uses sophisticated algorithms based on statistics about objects being accessed to determine best approach to execute query

23. Example SELECT P_CODE, P_DESCRIPT, P_PRICE, V_NAME, V_STATE FROM PRODUCT P, VENDOR V WHERE P.V_CODE=V.V_CODE AND V.V_STATE=‘FL’; • With the following database statistics: • The PRODUCT table has 7000 rows • The VENDOR table has 300 rows • 10 vendors come from Florida • 1000 products come from vendors in Florida

24. Optimizer Choices (continued)

25. Example • Assume the PRODUCT table has the index PQOH_NDX in the P_QOH attribute SELECT MIN(P_QOH) FROM PRODUCT could be resolved by reading only the first entry in the PQOH_NDX index

26. Using Hints to Affect Optimizer Choices Oracle 版本 SQL Server 2005 的語法請參考： http://geeks.netindonesia.net/blogs/kasim.wirama/archive/2007/12/31/sql-server-2005-query-hints.aspx http://download.microsoft.com/download/1/3/4/134644FD-05AD-4EE8-8B5A-0AED1C18A31E/Forcing_Query_Plans.doc

27. 11.5 SQL Performance Tuning • Evaluated from client perspective • Most current-generation relational DBMSs perform automatic query optimization at the server end • Most SQL performance optimization techniques are DBMS-specific and are rarely portable

28. Index Selectivity • Indexes are likely used when: • Indexed column appears by itself in search criteria of WHERE or HAVING clause • Indexed column appears by itself in GROUP BY or ORDER BY clause • MAX or MIN function is applied to indexed column • Data sparsity on indexed column is high • Index Selectivity • Measure of how likely an index will be used

29. Index Selectivity (continued) • General guidelines for creating and using indexes: • Create indexes for each attribute in WHERE, HAVING, ORDER BY, or GROUP BY clause • Do not use in small tables or tables with low sparsity • Declare primary and foreign keys so optimizer can use indexes in join operations • Declare indexes in join columns other than PK/FK

30. Conditional Expressions • Normally expressed within WHERE or HAVING clauses of SQL statement • Restricts output of query to only rows matching conditional criteria

31. Common Practices to write efficient Conditional Expressions • Use simple columns or literals as operands in a conditional expression – avoid functions • Numeric field comparisons are faster than character, date, and NULL comparisons • Equality comparisons are faster than inequality comparisons—the slowest is “LIKE” comparison • Transform conditional expressions to use literals • Write equality conditions first • For multiple AND (OR) conditions, write the condition most likely to be false (true) first • Avoid the use of NOT logical operator

32. 11.6 Query Formulation • Identify what columns and computations are required • Check simple expressions, aggregate functions, granularity of the raw data • Identify source tables • Determine how to join tables • Determine what selection criteria is needed • Check simple comparisons, single value to multiple values, nested comparisons, grouped data selection • Determine in what order to display output

33. 11.7 DBMS Performance Tuning • Includes global tasks such as managing DBMS processes in primary memory and structures in physical storage • Includes applying several practices examined in previous section • DBMS performance tuning at server end focuses on setting parameters used for: • Data cache: large enough • SQL cache: same query may be submitted by many users • Sort cache • Optimizer mode

34. DBMS Performance Tuning (continued) • Some general recommendations for creation of databases: • Use RAID (Redundant Array of Independent Disks) to provide balance between performance and faulttolerance • Minimize disk contention • At least the following table spaces: system table space, user data table space, index table space, temporary table space, rollback segment table space • Put high-usage tables in their own table spaces

35. DBMS Performance Tuning (continued) • Assign separate data files in separate storage volumes for indexes, system, and high-usage tables • Partition tables based on usage • Use denormalized tables where appropriate • Store computed and aggregate attributes in tables

36. DBMS Performance Tuning (continued)

37. 11.8 Query Optimization Example (跳過) 請參考 SQL Server 版本

38. Query Optimization Example 請參考 SQL Server 版本

39. Query Optimization Example 請參考 SQL Server 版本

40. Query Optimization Example 請參考 SQL Server 版本

41. Query Optimization Example 請參考 SQL Server 版本

42. Query Optimization Example 請參考 SQL Server 版本

43. Query Optimization Example 請參考 SQL Server 版本

44. Query Optimization Example 請參考 SQL Server 版本

45. Query Optimization Example 請參考 SQL Server 版本

46. Summary • Database performance tuning • Refers to set of activities and procedures designed to ensure that end-user query is processed by DBMS in minimum amount of time • SQL performance tuning • Refers to activities on client side designed to generate SQL code that returns correct answer in least amount of time, using minimum amount of resources at server end

47. Summary (continued) • DBMS performance tuning refers to activities on server side oriented to ensure that DBMS is properly configured to respond to clients’ requests in fastest way possible while making optimum use of existing resources • DBMS architecture is represented by many processes and structures (in memory and in permanent storage) used to manage a database

48. Summary (continued) • Database statistics refers to a number of measurements gathered by the DBMS that describe snapshot of database objects’ characteristics • DBMS processes queries in three phases: Parsing, Execution and Fetching • Indexes are crucial in process that speeds up data access

49. Summary (continued) • During query optimization, DBMS must choose what indexes to use, how to perform join operations, what table to use first, and so on • Hints are used to change optimizer mode for current SQL statement • SQL performance tuning deals with writing queries that make good use of statistics

50. Summary (continued) • Query formulation deals with how to translate business questions into specific SQL code to generate required results • DBMS performance tuning includes tasks such as managing DBMS processes in primary memory and structures in physical storage