Details

Preface. <p><b>1. Introduction.</b></p> <p>Another Book About SQL Performance!</p> <p>Inadequate Indexing.</p> <p>Myths and Misconceptions.</p> <p><b>2. Table and Index Organization.</b></p> <p>Introduction.</p> <p>Index Rows.</p> <p>Index Structure.</p> <p>Table Row.</p> <p>Buffer Pools and Disk I/Os.</p> <p>Hardware Specifics.</p> <p>DBMS Specifics.</p> <p><b>3. SQL Processing.</b></p> <p>Introduction.</p> <p>Predicates.</p> <p>Optimizers and Access Paths.</p> <p>Filter Factors.</p> <p>Materializing the Result Rows.</p> <p>Exercises.</p> <p><b>4. Deriving the Ideal Index for a SELECT.</b></p> <p>Introduction.</p> <p>Basic Assumptions for Disk and CPU Times.</p> <p>Inadequate Index.</p> <p>Three-Star Index—The Ideal Index for a SELECT.</p> <p>Algorithm to Derive the Best Index for a SELECT.</p> <p>Ideal Index for Every SELECT?</p> <p>Cost of an Additional Index.</p> <p>Recommendation.</p> <p>Exercises.</p> <p><b>5. Proactive Index Design.</b></p> <p>Detection of Inadequate Indexing.</p> <p>Basic Question (BQ).</p> <p>Quick Upper-Bound Estimate (QUBD).</p> <p>Cheapest Adequate Index or Best Possible Index: Example 1.</p> <p>Cheapest Adequate Index or Best Possible Index: Example 2.</p> <p>When to Use the QUBE.</p> <p><b>6. Factors Affecting the Index Design Process.</b></p> <p>I/O Time Estimate Verification.</p> <p>Multiple Thin Index Slices.</p> <p>Difficult Predicates.</p> <p>Filter Factor Pitfall.</p> <p>Filter Factor Pitfall Example.</p> <p>Exercises.</p> <p><b>7. Reactive Index Design.</b></p> <p>Introduction.</p> <p>EXPLAIN Describes the Selected Access Paths.</p> <p>Monitoring Reveals the Reality.</p> <p>LRT-Level Exception Monitoring.</p> <p>Call-Level Exception Monitoring.</p> <p>DBMS-Specific Monitoring Issues.</p> <p>Exercises.</p> <p><b>8. Indexing for Table Joins.</b></p> <p>Introduction.</p> <p>Two Simple Joins.</p> <p>Impact of Table Access Order on Index Design.</p> <p>Basic Joint Question (BJQ).</p> <p>Predicting the Table Access Order.</p> <p>Merge Scan Joins and Hash Joins.</p> <p>Nested-Loop Joins Versus MS/HJ and Ideal Indexes.</p> <p>Joining More Than Two Tables.</p> <p>Why Joins Often Perform Poorly.</p> <p>Designing Indexes for Subqueries.</p> <p>Designing Indexes for Unions.</p> <p>Table Design Considerations.</p> <p>Exercises.</p> <p><b>9. Star Join Considerations.</b></p> <p>Introduction.</p> <p>Indexes on Dimension tables.</p> <p>Huge Impact of the Table Access Order.</p> <p>Indexes on Fact Tables.</p> <p>Summary Tables.</p> <p><b>10. Multiple Index Access.</b></p> <p>Introduction.</p> <p>Index ANDing.</p> <p>Index ORing.</p> <p>Index Join.</p> <p>Exercises.</p> <p><b>11. Indexes and Reorganization.</b></p> <p>Physical Structure of a B-Tree Index.</p> <p>How the DBMS Finds an Index Row.</p> <p>What Happens When a Row IS Inserted?</p> <p>Are Leaf Page Splits Serious?</p> <p>When Should an Index Be reorganized?</p> <p>Volatile Index Columns.</p> <p>Long Index Rows.</p> <p>Example: Order-Sensitive Batch Job.</p> <p>Table Rows Stored in Leaf Pages.</p> <p>Cost of Index Reorganization.</p> <p>Split Monitoring.</p> <p>Summary.</p> <p><b>12. DBMS-Specific Indexing Restrictions.</b></p> <p>Introduction.</p> <p>Number of Index Columns,</p> <p>Total Length of the Index Columns.</p> <p>Variable-Length Columns.</p> <p>Number of Indexes per Table.</p> <p>Maximum Index Size.</p> <p>Index Locking.</p> <p>Index Row Suppression.</p> <p>DBMS Index Creation Examples.</p> <p><b>13. DBMS-Specific Indexing Options.</b></p> <p>Introduction.</p> <p>Index Row Suppression.</p> <p>Additional Index Columns After the Index Key.</p> <p>Constraints to Enforce Uniqueness.</p> <p>DBMS Able to Read an Index in Both Directions.</p> <p>Index Key Truncation.</p> <p>Function-Based Indexes.</p> <p>Index Skip Scan.</p> <p>Block Indexes.</p> <p>Data-Partitioned Secondary Indexes.</p> <p>Exercises.</p> <p><b>14. Optimizers Are Not Perfect.</b></p> <p>Introduction.</p> <p>Optimizers Do Not Always See the Best Alternative.</p> <p>Optimizers’ Cost Estimates May Be Very Wrong.</p> <p>Cost Estimate Formulas.</p> <p>Do Optimizer Problems Affect Index Design?</p> <p>Exercises.</p> <p><b>15. Additional Estimation Considerations.</b></p> <p>Assumptions Behind the QUBE Formula.</p> <p>Nonleaf Index Pages in Memory.</p> <p>When the Actual Response Time Can Be Much Shorter Than the QUBE.</p> <p>Estimating CPU Time (CQUBE).</p> <p>CPU Estimation Examples.</p> <p><b>16. Organizing the Index Design Process.</b></p> <p>Introduction.</p> <p>Computer-Assisted Index Design.</p> <p>Nine Steps Toward Excellent Indexes.</p> <p>References.</p> <p>Glossary.</p> <p>Index.</p>

"I recommend this book to all those who have anything to do with database performance. It is a must-read for all database administrations, database designers, performance-tuning specialists, and application programmers…" (<i>Computing Reviews.com</i>, November 20, 2005)

<p><strong>Tapio Lahdenmaki</strong> received his M.Sc. from the Helsinki Institute of Technology. He worked at IBM for over thirty years, as a Database Specialist since 1975 (first IMS, then DB2 and other relational DBMSs). He has taught hundreds of database performance courses in 20 different countries, and was the main author of IBM's current global courses for DB2 (for z/OS) performance. He is the author and co-author of several books and articles on database performance. Since 2003 he has been an independent consultant on database performance, and teaches a product-independent index design course. <p><strong>Mike Leach</strong> recently retired from a position at IBM, with 20 years experience teaching database classes at IBM locations in the UK and other countries. In 1990, he and Mr. Leach developed?a?DB2 Application Performance course, which is still taught in IBM Education Centers around the world.

<p><b>Improve the performance of relational databases with indexes designed for today's hardware</b></p> <p>Over the last few years, hardware and software have advanced beyond all recognition, so it's hardly surprising that relational database performance now receives much less attention. Unfortunately, the reality is that the improved hardware hasn't kept pace with the ever-increasing quantity of data processed today. Although disk packing densities have increased enormously, making storage costs extremely low and sequential read very fast, random reads are still painfully slow. Many of the old design recommendations are therefore no longer valid—the optimal point of indexing has come a long way. Consequently many of the old problems haven't actually gone away—they have simply changed their appearance.</p> <p>This book provides an easy but effective approach to the design of indexes and tables. Using lots of examples and case studies, the authors describe how the DB2, Oracle, and SQL Server optimizers determine how to access data, and how CPU and response times for the resulting access paths can be quickly estimated. This enables comparisons to be made of the various designs, and helps you choose available choices for the most appropriate design.</p> <p>This book is intended for anyone who wants to understand the issues of SQL performance or how to design tables and indexes effectively. With this title, readers with many years of experience of relational systems will be able to better grasp the implications that have been brought into play by the introduction of new hardware.</p>

US