Database Systems - Lec 11: Practical Database Design and Tuning - Nguyen Thanh Tung

Nội dung text: Database Systems - Lec 11: Practical Database Design and Tuning - Nguyen Thanh Tung

1. Outline ▪ Practical Database Design and Tuning • Physical Database Design in Relational Databases • An Overview of Database Tuning in Relational Systems ▪ Reading: • Physical Design: Chapter 16 [1] 2
2. Physical Database Design in Relational Databases ▪ Factors that Influence Physical Database Design (contd.): A. Analyzing the database queries and transactions (contd.) • For each update transaction or operation, the following information is needed. 1. The files that will be updated; 2. The type of operation on each file (insert, update or delete); 3. The attributes on which selection conditions for a delete or update operation are specified; 4. The attributes whose values will be changed by an update operation. • Note: the attributes listed in items 3 above are candidates for definition of access structures. However, the attributes listed in item 4 are candidates for avoiding an access structure. 4
3. Physical Database Design in Relational Databases ▪ Factors that Influence Physical Database Design (contd.) C. Analyzing the time constraints of queries and transactions • Performance constraints place further priorities on the attributes that are candidates for access paths. • The selection attributes used by queries and transactions with time constraints become higher-priority candidates for primary access structure. 6
4. Physical Database Design in Relational Databases ▪ Factors that Influence Physical Database Design (contd.) E. Analyzing the uniqueness constraints on attributes • Access paths should be specified on all candidate key attributes — or set of attributes — that are either the primary key or constrained to be unique. 8
5. Physical Database Design in Relational Databases ▪ Physical Database Design Decisions (contd.) ▪ Denormalization as a design decision for speeding up queries • The goal of normalization is to separate the logically related attributes into tables to minimize redundancy and thereby avoid the update anomalies that cause an extra processing overheard to maintain consistency of the database. • The goal of denormalization is to improve the performance of frequently occurring queries and transactions. (Typically the designer adds to a table attributes that are needed for answering queries or producing reports so that a join with another table is avoided.) • Trade off between update and query performance 10
6. An Overview of Database Tuning in Relational Systems ▪ Statistics internally collected in DBMSs: • Size of individual tables • Number of distinct values in a column • The number of times a particular query or transaction is submitted/executed in an interval of time • The times required for different phases of query and transaction processing ▪ Statistics obtained from monitoring: • Storage statistics • I/O and device performance statistics • Query/transaction processing statistics • Locking/logging related statistics • Index statistic 12
7. An Overview of Database Tuning in Relational Systems ▪ Tuning Indexes • Reasons to tuning indexes →Certain queries may take too long to run for lack of an index; →Certain indexes may not get utilized at all; →Certain indexes may be causing excessive overhead because the index is on an attribute that undergoes frequent changes • Options to tuning indexes →Drop or/and build new indexes →Change a non-clustered index to a clustered index (and vice versa) →Rebuilding the index 14
8. An Overview of Database Tuning in Relational Systems ▪ Tuning the Database Design (contd.) • Possible changes to the database design →Existing tables may be joined (denormalized) because certain attributes from two or more tables are frequently needed together. →For the given set of tables, there may be alternative design choices, all of which achieve 3NF or BCNF. One may be replaced by the other. →A relation of the form R(K, A, B, C, D, ) that is in BCNF can be stored into multiple tables that are also in BCNF by replicating the key K in each table. →Attribute(s) from one table may be repeated in another even though this creates redundancy and potential anomalies. →Apply horizontal partitioning as well as vertical partitioning if necessary. 16
9. An Overview of Database Tuning in Relational Systems ▪ Tuning Queries (contd.): Typical instances for query tuning • In some situations involving using of correlated queries, temporaries are useful. Example: SELECT SSN FROM EMPLOYEE E WHERE SALARY = SELECT MAX (SALARY) FROM EMPLOYEE AS M WHERE M.DNO = E.DNO; SELECT MAX (SALARY) AS HIGHSALARY, DNO INTO TEMP FROM EMPLOYEE GROUP BY DNO; SELECT SSN FROM EMPLOYEE, TEMP WHERE SALARY = HIGHSALARY AND EMPLOYEE.DNO = TEMP.DNO; 18
10. An Overview of Database Tuning in Relational Systems ▪ Additional Query Tuning Guidelines • A query with multiple selection conditions that are connected via OR may not be prompting the query optimizer to use any index. Such a query may be split up and expressed as a union of queries, each with a condition on an attribute that causes an index to be used. Example: SELECT FNAME, LNAME, SALARY, AGE FROM EMPLOYEE WHERE AGE > 45 OR SALARY 45 UNION SELECT FNAME, LNAME, SALARY, AGE FROM EMPLOYEE WHERE SALARY < 50000; 20
11. An Overview of Database Tuning in Relational Systems ▪ Additional Query Tuning Guidelines • WHERE conditions may be rewritten to utilize the indexes on multiple columns. Example: SELECT REGION#, PROD_TYPE, MONTH, SALES FROM SALES_STATISTICS WHERE REGION# = 3 AND ((PRODUCT_TYPE BETWEEN 1 AND 3) OR (PRODUCT_TYPE BETWEEN 8 AND 10)); may use an index only on REGION# and search through all leaf pages of the index for a match on PRODUCT_TYPE. Instead, using SELECT REGION#, PROD_TYPE, MONTH, SALES FROM SALES_STATISTICS WHERE (REGION# = 3 AND (PRODUCT_TYPE BETWEEN 1 AND 3)) OR (REGION# = 3 AND (PRODUCT_TYPE BETWEEN 8 AND 10)); 22
12. Q&A 24