For your convenience Apress has placed some of the front matter material after the index Please use the Bookmarks and Contents at a Glance links to access them Contents at a Glance Contents v About the Authors xiii About the Technical Reviewer xiv Acknowledgments xv Chapter 1: Oracle Indexes .1 Chapter 2: B-tree Indexes .19 Chapter 3: Bitmap Indexes .49 Chapter 4: Index-Organized Tables 69 Chapter 5: Specialized Indexes 85 Chapter 6: Partitioned Indexes .115 Chapter 7: Tuning Index Usage .141 Chapter 8: Maintaining Indexes 171 Chapter 9: SQL Tuning Advisor .205 Chapter 10: SQL Access Advisor 233 Index .249 iv CHAPTER ■■■ Oracle Indexes An index is an optionally created database object used primarily to increase query performance The purpose of a database index is similar to an index in the back of a book A book index associates a topic with a page number When you’re locating information in a book, it’s usually much faster to examine the index first, find the topic of interest, and identify associated page numbers With this information, you can navigate directly to specific page numbers in the book If the topic only appears on a few pages within the book, then the number of pages to read is minimal In this manner, the usefulness of the index decreases with an increase in the number of times a topic appears in a book Similar to a book index, a database index stores the column value of interest along with its row identifier (ROWID) The ROWID contains the physical location of the table row on disk that stores the column value With the ROWID in hand, Oracle can efficiently retrieve table data with a minimum of disk reads In this way, indexes function like a shortcut to the table data If there is no available index, then Oracle reads each row in the table to determine if the row contains the desired information Note In addition to improving performance, Oracle uses indexes to help enforce enabled primary key and unique key constraints Additionally, Oracle can better manage table locking scenarios when indexes are placed on foreign key columns While it’s possible to build a database application devoid of indexes, without them you’re almost guaranteeing poor performance Indexes allow for excellent scalability even with very large data sets So if indexes are so important to database performance, why not place them on all tables and column combinations? The answer is short: indexes are not free They consume disk space and system resources As column values are modified, any corresponding indexes must also be updated In this way, indexes use storage, I/O, CPU, and memory resources A poor choice of indexes leads to wasted disk usage and excessive consumption of system resources This results in a decrease in database performance For these reasons, when you design and build an Oracle database application, expert consideration must be given to your indexing strategy As an application architect, you must understand the physical properties of an index, what types of indexes are available, and strategies for choosing which table and column combinations to index A correct indexing methodology is central to achieving maximum performance for your database This chapter introduces you to Oracle indexing concepts We begin with a to-the-point example of how an index improves query performance We then explain index types available within Oracle and CHAPTER ■ ORACLE INDEXES provide guidelines and recommendations for choosing which columns to index If you’re new to indexes or require a refreshing, start here Improving Performance with Indexes How exactly does an index improve query performance? To understand how an index works, consider the following simple example Suppose you create a table to hold customer information, like so: create table cust (cust_id number ,last_name varchar2(30) ,first_name varchar2(30)); Your business grows quickly; after a short time, millions of customers are created You run daily reports against this table and notice that performance has progressively decreased when issuing queries like this: select cust_id, last_name, first_name from cust where last_name = 'STARK'; When there was hardly any data in the table, this query returned in sub-seconds Now, with over a million rows and growing, this query is taking longer and longer What’s going on here? When a SQL select statement executes, the Oracle query optimizer quickly calculates a step-by-step execution plan detailing how it will retrieve column values specified in the query In calculating the plan, the optimizer determines which tables and indexes will be used to retrieve data When no index exists, the table itself is the only access path available to satisfy the results of the query In this scenario, Oracle has no choice but to inspect every row within every used block in the table (this is known as a full table scan) to see if there are rows with the last name of STARK As more data is inserted into this table, the query takes longer The cost of this query (as a measure of CPU, memory, and I/O resources consumed) is proportional to the number of table blocks The only way to make this query run faster is to buy better hardware or use a performance enhancing feature such as an index You can peak ahead in this chapter and determine that an index on columns that appear in the WHERE clause of a SQL query might improve performance and decide to create an index on the CUST table’s LAST_NAME column, like so: create index cust_idx1 on cust(last_name); This statement creates a B-tree index (more on this later) This is the default index type in Oracle After creating the index, the performance of queries selecting by last name returns to sub-second timing Life is good To understand how the index improves performance, recall that an index stores two types of information: the value of the table column(s) and the corresponding ROWID The ROWID uniquely identifies a row (for heap-organized tables) within a database and contains its physical location (datafile, block, and row position within block) Once the index is created and subsequent queries execute, the query optimizer considers whether the index will reduce the amount of resources required to return the results of the query Acknowledgments Special thanks go to lead editor Jonathan Gennick for providing vision and numerous recommendations on both the content and organization of this book A huge thanks goes to Karen Morton for countless suggestions that greatly improved the quality and technical content It really is an honor for the authors to have a person of such consummate skill and wisdom (and fame) as Karen help out with the technical vetting of the book Any remaining errors are, of course, the authors' alone Thanks also to the tremendous extra effort from coordinating editor Anita Castro to get this book completed on schedule, which, in addition to her “normal” tasks, entailed juggling multiple versions of the chapters among the three authors—a demanding task in itself Thanks as well to the excellent copy editing performed by the copy editor Mary Behr It takes a dedicated and talented team to produce a book like this Personal Acknowledgments Thanks to hard working fellow co-authors, Sam R Alapati and Bill Padfield, and also thanks to the numerous DBAs and developers who I’ve learned from over the years: Scott Schulze, Dave Jennings, Bob Suehrstedt, Ken Toney, Pete Mullineaux, Janet Bacon, Sue Wagner, Mohan Koneru, Arup Nanda, Charles Kim, Bernard Lopuz, Barb Sannwald, Tim Gorman, Shawn Heisdorffer, Sujit Pattanaik, Ken Roberts, Roger Murphy, Mehran Sowdaey, Kevin Bayer, Guido Handley, Dan Fink, Nehru Kaja, Tim Colbert, Glenn Balanoff, Bob Mason, Mike Nims, Brad Blake, Ravi Narayanaswamy, Abdul Ebadi, Kevin Hoyt, Trent Sherman, Sandra Montijo, Jim Secor, Maureen Frazzini, Sean Best, Patrick Gates, Krish Hariharan, Buzzy Cheadle, Lori Beer, Liz Brill, Ennio Murroni, Gary Smith, Dan Truman, Joey Canlas, Eric Wendelin, Mark Lutze, Kevin Quinlivan, Dave Bourque, John Lilly, Dave Wood, Laurie Bourgeois, Steve Buckmelter, Casey Costley, John DiVirgilio, Valerie Eipper, John Goggin, Brett Guy, Kevin O'Grady, Peter Schow, Jeff Shoup, Mike Tanaka, Todd Wichers, Doug Cushing, Kye Bae, Will Thornburg, Ambereen Pasha, Steve Roughton, Sudha Verma, Dinesh Neelay, Ann Togasaki, Thom Chumley, Lea Wang, Steve Odendahl, Ken Kadonaga, Vasa Dasan, Erik Jasiak, Tae Kim, Jeff Sherard, Aaron Isom, Kristi Jackson, Karolyn Vowles, Terry Roam, Darin Christensen, Max Rose, Doug Drake, Jim Johnson, Marilyn Wenzel, Doc Heppler, Mert Lovell, Ken Sardoni, Kimball Moore, Brian Beasly, Clair Larsen, Odean Bowler, Jim Stark, Robbie Robertson, Gary Plessinger, Donna Zwiller, Brighton Bigler, Kit Ashworth, Lasse Jansen, Debra Rimmer, and Harmon Faleono Darl Kuhn xv ■ ACKNOWLEDGMENTS This is the second book that I wrote with Bill and Darl, and I’m truly fortunate to have had the opportunity of working with such great professionals on this project Both of them are superb Oracle database administrators and they’re also personally great Constant cheer and good humor on behalf of my two co-authors, not to speak of their extreme generosity and willingness when I requested their assistance, has made writing this book a very cheerful task I’d like to (quite belatedly) acknowledge the great help provided in my career by Ram Janardhanan and Anil Sinha of Citicorp, New York As is usual when I write a book, my family has made quite a few sacrifices to enable me to put my best possible effort into the planning and writing of the book I gratefully acknowledge the wonderful support and help from my wife, Valerie, and my children Shannon, Nicholas, and Nina Finally, I’d like to thank my other family: my mother, Swarna Kumari; my father, Appa Rao; my brothers, Hari Hara Prasad and Siva Sankara Prasad; as well as Aruna, Vanaja, Ashwin, Teja, Aparna, and Soumya for their constant support, encouragement, affection, and love Sam R Alapati I’d like to thank my gracious co-authors, Sam R Alapati and Darl Kuhn, for all of their help and support and for taking on a rookie for this project I couldn’t have made it without their help There are so many people I can thank that have helped me over the years in my career, so please know that I appreciate every single individual who has encouraged and helped me along First of all, I’d like to thank Bob Ranney for giving me the opportunity to be a DBA I also would like to thank some of my key managers over the years that have helped me, including Beth Bowen, Larry Wyzgala, John Zlamal, Linda Scheldrup, Amy Neff, and Maureen Frazzini Of course, there are many DBAs, developers, system administrators, and architects that have helped me greatly in my career First, I need to thank the DBAs on my current team who make the everyday grind a blast These folks have helped me so much professionally and have become great friends over the many years we have worked together This includes Dave Carter, Debbie Fitzgerald, Pankaj Guleria, Pete Sardaczuk, Brad Strom, and Rebecca Western Over the years, I’ve learned an awful lot from the following folks, who have always been generous with their time and help, and patient with my questions: Mark Nold, Mick McMahon, Sandra Montijo, Jerry Sanderson, Glen Sanderson, Jose Fernandez, Mike Hammontre, Pat Cain, Dave Steep, Gary Whiting, Ron Fullmer, Becky Enter, John Weber, Avanish Gupta, Scott Bunker, Paul Mayes, Bill Read, Rod Ermish, Rick Barry, Sun Yang, Sue Wagner, Glenn Balanoff, Linda Lee Burau, Deborah LieouMcCall, Bob Zumpf, Kristi Sargent, Sandy Hass, George Huner, Pad Kail, Curtis Gay, Ross Bartholomay, Carol Rosenow, Scott Richards, Sheryl Gross, Lachelle Shambe, John Piel, Rob Grote, Rex Ellis, Zane Warton, Steve Pearson, Jim Barclay, Jason Hermstad, Shari Plantz-Masters, Denise Duncan, Bob Mason, Brad Blake, Mike Nims, Cathie Wilson, Rob Coates, Shirley Amend, Rob Bushlack, Cindy Patterson, Debbie Chartier, Blair Christensen, Meera Ganesan, Kedar Panda, Srivatsan Muralidaran, Kevin Tomimatsu, John Townley, and Brent Wagner Bill Padfield xvi ... database This chapter introduces you to Oracle indexing concepts We begin with a to-the-point example of how an index improves query performance We then explain index types available within Oracle. .. similar to an index in the back of a book A book index associates a topic with a page number When you’re locating information in a book, it’s usually much faster to examine the index first, find the... pages to read is minimal In this manner, the usefulness of the index decreases with an increase in the number of times a topic appears in a book Similar to a book index, a database index stores the