Chapter16

784 views

Published on

Navate Database Management system

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
784
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Chapter16

  1. 2. <ul><li>Practical </li></ul><ul><li>Database Design </li></ul><ul><li>And </li></ul><ul><li>Tuning </li></ul>Chapter 16
  2. 3. <ul><li>Physical Database Design in Relational Databases </li></ul><ul><li>An Overview of Database Tuning in Relational Systems </li></ul>Chapter Outline
  3. 4. <ul><li>Meaningful design decisions can be made if we know the queries, transactions, and applications that are expected to run on the database. </li></ul><ul><li>The physical database design decision mainly considers the storage structure and access paths for database files. It requires analyzing: </li></ul><ul><ul><li>The database queries and transactions </li></ul></ul><ul><ul><li>The expected frequency of invocation of queries and transactions </li></ul></ul><ul><ul><li>The time constraints of queries and transactions </li></ul></ul><ul><ul><li>The expected frequencies of update operations </li></ul></ul><ul><ul><li>The uniqueness constraints on attributes </li></ul></ul>Physical Database Design
  4. 5. <ul><li>Design decision about indexing a relation falls into the following categories: </li></ul><ul><ul><li>Whether to index an attribute </li></ul></ul><ul><ul><li>What attribute or attributes to index on </li></ul></ul><ul><ul><li>Whether to set up a clustered index </li></ul></ul><ul><ul><li>Whether to use a hash index over a tree index </li></ul></ul><ul><ul><li>Whether to use dynamic hashing for the file </li></ul></ul>Physical Database Design
  5. 6. <ul><li>The goals of Database tuning: </li></ul><ul><ul><li>To make applications run faster </li></ul></ul><ul><ul><li>To lower the response time of queries/transactions </li></ul></ul><ul><ul><li>To improve the overall throughput of transactions </li></ul></ul><ul><li>Tuning indexes for the following reasons: </li></ul><ul><ul><li>Certain queries may take too long to run for lack of index </li></ul></ul><ul><ul><li>Certain indexes may not get utilized at all </li></ul></ul><ul><ul><li>Certain indexes may be causing excessive overhead </li></ul></ul>An Overview of Database Tuning
  6. 7. <ul><li>Changes to the conceptual schema for tuning the database may be of the following nature: </li></ul><ul><ul><li>Existing tables may be joined (denormalization) But the resulting redundancy causes problems during updates and redesigns </li></ul></ul><ul><ul><li>An alternative design for a given set of tables </li></ul></ul><ul><ul><li>Vertical partitioning a table. For example the table </li></ul></ul><ul><ul><ul><li>EMPLOYEE ( SSN , Name, Phone, Grade, Salary) </li></ul></ul></ul><ul><ul><ul><li>May be split into two tables </li></ul></ul></ul><ul><ul><ul><li>EMPLOYEE1 ( SSN , Name, Phone) , </li></ul></ul></ul><ul><ul><ul><li>EMPLOYEE2 ( SSN , Grade, Salary) </li></ul></ul></ul><ul><ul><li>Makes some sense if some attributes tend to be accessed often or together, and others rarely </li></ul></ul><ul><ul><li>Attribute(s) from one table may be repeated in another e.g. Partname might be spelt out instead of using PartNumber </li></ul></ul><ul><ul><li>Horizontal partitioning e.g. one table per product number But this makes queries that need all of the data more complex </li></ul></ul>An Overview of Database Tuning
  7. 8. <ul><li>Query tuning may be needed in the following situations: </li></ul><ul><ul><li>When query optimizer do not use indexes because of the presence of particular operators (e.g., >, <, etc.) </li></ul></ul><ul><ul><li>Indexes are often not uses for nested queries using IN, e.g., SELECT SSN </li></ul></ul><ul><ul><ul><li>FROM EMPLOYEE </li></ul></ul></ul><ul><ul><ul><li>WHERE DNO IN (SELECT DNUMBER </li></ul></ul></ul><ul><ul><ul><li> FROM EPARTMENT </li></ul></ul></ul><ul><ul><ul><li> WHERE MGRSSN=‘333445555’); </li></ul></ul></ul><ul><ul><ul><li>May not use the index on DNO, whereas using </li></ul></ul></ul><ul><ul><ul><li>DNO = DNUMBER in the WHERE of query block may cause the </li></ul></ul></ul><ul><ul><ul><li>index to be used. </li></ul></ul></ul>An Overview of Database Tuning
  8. 9. <ul><ul><li>Avoid using DISTINCT, since it causes a sort operation But relying on duplicates is not part of the relational model </li></ul></ul><ul><ul><li>Avoid unnecessary use of temporary result tables </li></ul></ul><ul><ul><li>If multiple options for join condition are possible, choose one that uses a clustering index and avoid those that contain string comparisons </li></ul></ul><ul><ul><li>In the FROM clause, reorder the tables such that the JOIN processing implies to scan the smaller tables and uses the indexes from large tables </li></ul></ul><ul><ul><li>Avoid using view tables that are defined by a join, as long as the base tables can be used </li></ul></ul>An Overview of Database Tuning
  9. 10. <ul><ul><li>Sometimes temporary results are useful, e.g. the query </li></ul></ul><ul><ul><li>SELECT SSN </li></ul></ul><ul><ul><li>FROM EMPLOYEE E </li></ul></ul><ul><ul><li>WHERE SALARY = SELECT MAX (SALARY) </li></ul></ul><ul><ul><li> FROM EMPLOYEE M </li></ul></ul><ul><ul><li> WHERE M.DNO = E.DNO; </li></ul></ul><ul><ul><li>can be broken into </li></ul></ul><ul><ul><li>SELECT MAX (SALARY) AS HSAL, DNO INTO TEMP </li></ul></ul><ul><ul><li>FROM EMPLOYEE </li></ul></ul><ul><ul><li>GROUP BY DNO; and </li></ul></ul><ul><ul><li>SELECT SSN </li></ul></ul><ul><ul><li>FROM EMPLOYEE, TEMP </li></ul></ul><ul><ul><li>WHERE SALARY=HSAL AND EMPLOYEE.DNO = TEMP.DNO; </li></ul></ul>An Overview of Database Tuning
  10. 11. Warnings <ul><li>Optimisation doesn’t always destroy clarity, and maintainability, but it certainly can </li></ul><ul><li>Today’s clever optimisation hack could become tomorrow’s unmaintainable bottleneck </li></ul><ul><ul><li>Optimisation capabilities and biases of database systems vary, and are subject to change </li></ul></ul><ul><li>The normalised forms eliminate redundancy for a reason </li></ul><ul><ul><li>Strive for a structure that is fast without redundancy </li></ul></ul><ul><li>Find out what the database is really doing (e.g. “explain” command in PostgreSQL) </li></ul>
  11. 12. More Warnings <ul><li>Using hint commands is better than writing mangled SQL </li></ul><ul><li>“ Premature optimization is the root of all evil” ― C. A. R. Hoare </li></ul><ul><li>“ More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.” ― W.A. Wulf </li></ul><ul><li>&quot;Performance anxiety leads to premature optimization.&quot; ― Anonymous ( http://c2.com/ cgi / wiki ? PrematureOptimization ) </li></ul>

×