Indexes: Structure, Splits and Free Space Management Internals
Download as PPTX, PDF7 likes5,455 views
The document discusses the internal structure and management of Oracle database indexes. It describes how B-tree indexes are structured, including the use of branch blocks and leaf blocks. It also covers concepts like index keys, splits that occur as indexes grow, free space management, and techniques for reorganizing indexes like rebuilding and coalescing. Bitmap indexes are also discussed, noting they use a compressed bitmap in their internal keys. Finally, some common myths about indexing are debunked, such as the idea that indexes need regular rebuilds to remain balanced.
Indexes: Structure, Splits and Free Space Management Internals
- 1. Indexes: Structure, Splits and Free Space Management Internals OakTable World, 29 September 2014 Christian Antognini BASEL BERN BRUGG LAUSANNE ZUERICH DUESSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MUNICH STUTTGART VIENNA 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 1
- 2. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 2 @ChrisAntognini Senior principal consultant, trainer and partner at Trivadis in Zurich (CH) christian.antognini@trivadis.com http://antognini.ch Focus: get the most out of Oracle Database Logical and physical database design Query optimizer Application performance management Author of Troubleshooting Oracle Performance Apress, 2008/2014 OakTable Network, Oracle ACE Director
- 3. AGENDA 1. Concepts 2. Index Keys 3. Splits 4. Free Space 5. Reorganizations 6. Bitmap 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 3
- 4. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Concepts 4
- 5. Structure of a B-Tree 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 5 24 51 12 29 42 86 2 ROWID 8 ROWID 10 ROWID 11 ROWID 12 ROWID 18 ROWID 20 ROWID 24 ROWID 26 ROWID 29 ROWID 34 ROWID 38 ROWID 42 ROWID 51 ROWID 55 ROWID 73 ROWID branch blocks 86 ROWID 99 ROWID left<24 right≥24 leaf blocks root block
- 6. 2014 © Trivadis Nulls NULL values are stored in the index only when at least one of the indexed columns is not NULL Exception: bitmap indexes always store indexed data For unique indexes the uniqueness is guaranteed only if at least one of the indexed columns is not NULL NULL values are stored after not NULL values in the index Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 6
- 7. 2014 © Trivadis Myths Oracle B-tree indexes can become “unbalanced” over time and need to be rebuilt Deleted space in an index is “deadwood” and over time requires the index to be rebuilt If an index reaches “x” number of levels, it becomes inefficient and requires the index to be rebuilt If an index has a poor clustering factor, the index needs to be rebuilt To improve performance, indexes need to be regularly rebuilt Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 7 Source: Oracle B-Tree Index Internals: Rebuilding The Truth, Richard Foote
- 8. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Index Keys 8
- 9. Internal Key Internally a unique key is needed to sort the indexed columns For unique indexes the internal key is the same as the index key For non-unique indexes the ROWID of the indexed row is added to the index key to make it unique For global indexes an extended ROWID is used, otherwise a restricted ROWID is enough 2014 © Trivadis Therefore The index entries are sorted in a consistent way Even for non-unique indexed the order of the index entries changes only when the indexed table is reorganized (i.e. not if the index is rebuilt!) Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 9
- 10. Branch Block Key In branch blocks the internal key is truncated after the first byte that differs from the last key of the left leaf block All keys are preceded by a length field 1 byte for data up to 127 bytes Otherwise 2 bytes - The high bit of the first byte is set (0x80) - The remaining bits of the first byte and the second byte contain the length Partially stored keys are terminated by 0xFE Nulls have a column length of 0xFF, trailing nulls are stored 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 10 RDBA Len Key 1 Data Key 1 Len Key X Data Key X
- 11. Leaf Block Key All keys are preceded by a length field 1 byte for data up to 127 bytes Otherwise 2 bytes - The high bit of the first byte is set (0x80) - The remaining bits of the first byte and the second byte contain the length Nulls have a column length of 0xFF, trailing nulls are stored For global indexes an extended ROWID is used, otherwise a restricted ROWID is enough 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 11 Flag Lock Len Key 1 Data Key 1 Len ROWID ROWID (optional)
- 12. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Splits 12
- 13. 2014 © Trivadis Splits Two split methods are implemented 50:50 split The keys are evenly distributed over two blocks Based on size, not number of keys 99:1 split (a.k.a. 90:10) The new key is the right-most of the index A new leaf block containing only the new key is added Useful for increasing values like sequences and timestamps A change in the structure of an index (like a split) is not rollbacked if the transaction that caused it is rollbacked Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 13
- 14. 2014 © Trivadis Splits Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 14 #1
- 15. 2014 © Trivadis Splits Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 15 #1 #2 #3
- 16. 2014 © Trivadis Splits #2 #4 #3 Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 16 #1 #2 #3
- 17. 2014 © Trivadis Splits #1 Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 17 #1 #2 #4 #3 #5 #2 #4 #3
- 18. 2014 © Trivadis Splits Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 18
- 19. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Free Space 19
- 20. Reminder PCTFREE is only used when the index is created (or rebuilt) An update is implemented as a delete followed by an insert The free space in leaf blocks is strongly dependent on the type of split (50:50 2014 © Trivadis or 99:1) PCTUSED cannot be used for indexes Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 20
- 21. Free Space 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 21 #1 #2 #3 #4
- 22. Free Space 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 22 #1 #2 #4 #3
- 23. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Reorganizations 23
- 24. Reorganizations If the free space is not automatically reused, it should be manually reclaimed This is unusual, therefore such an operation should only be performed if it is really necessary To manually reclaim free space two possibilities exists Rebuild: the index is recreated Coalesce: free space in contiguous blocks is merged and, therefore, some blocks are unchained Unnecessary rebuild/coalesce may lead to sub-optimal data density in leaf blocks Too much free space, i.e. too low density Too much block splits, i.e. too high density 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 24
- 25. Rebuild vs. Coalesce 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 25 Pro Cons Rebuild Doesn’t lock table (online rebuilds only) Reclaim all the free space Locks table during rebuild (offline rebuilds only) Doubles space usage temporarily The index is completely recreated (to do so large sorts may be performed) Coalesce Doesn’t lock table Current index structure is reused Doesn’t reclaim all the free space Can generate lot of redo
- 26. 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 Bitmap 26
- 27. 2014 © Trivadis Bitmap A bitmap index is a regular B-tree, only the internal key differs from the non-bitmap index! The key is composed by Indexed column(s) Start/End ROWID Bitmap representing the rows that have the key - To save space it is “compressed” Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 27
- 28. Summary 2014 © Trivadis B-tree indexes cannot become “unbalanced” Deleted space in an index can be reused Indexes do not need to be regularly rebuilt Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 28
- 29. Questions and answers ... Christian Antognini Senior Principal Consultant christian.antognini@trivadis.com BASEL BERN BRUGG LAUSANNE ZUERICH DUESSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MUNICH STUTTGART VIENNA 2014 © Trivadis Indexes: Structure, Splits and Free Space Management Internals 29 September 2014 29