1. 1 juliandyke.com Bitmap Index Internals Julian Dyke Independent Consultant Web Version © 2005 Julian Dyke

2. juliandyke.com 2 Agenda  Introduction  Bitmap Row Sources  Internal Structures  Bitmap Index DML  Conclusion

3. © 2005 Julian Dyke juliandyke.com 3 Introduction

4. © 2005 Julian Dyke juliandyke.com 4 Bitmap Indexes  Introduced in Oracle 7.3  Originally intended for columns with  Low cardinality (few distinct values)  Little or no DML activity  Often used in DSS environments  Useful for ad-hoc queries where predicates are not known in advance

5. © 2005 Julian Dyke juliandyke.com 5 Bitmap Index Properties  Bitmap indexes  Must be non-unique  Include NULL values (B*Tree indexes do not)  Maximum 30 columns (B*Tree indexes max 32 columns)  Can be locally partitioned (8.1.5 and above)  Cannot be globally partitioned  Can be function-based indexes (built-in or user-defined)  Can be IOT secondary indexes (9.2 and above)  Can be created on global temporary tables  Cannot be compressed  Cannot be reversed

6. © 2005 Julian Dyke juliandyke.com 6 Bitmap Indexes CREATE TABLE property ( property_code NUMBER, bedrooms NUMBER, receptions NUMBER, garages NUMBER ); CREATE BITMAP INDEX index1 ON property (bedrooms); CREATE BITMAP INDEX index2 ON property (receptions); CREATE BITMAP INDEX index3 ON property (garages); SELECT property_code FROM property WHERE bedrooms = 4 AND receptions = 3 AND garages = 2  For example

7. © 2005 Julian Dyke juliandyke.com 7 Logical Operations  Bitmaps can be combined using the logical operations AND, OR, NOT. ABA AND BA OR BNOT A 00001 01011 10010 11110  Oracle also implements a MINUS operation internally  A MINUS B is equivalent to A AND NOT B

8. © 2005 Julian Dyke juliandyke.com 8 Multicolumn Bitmap Indexes  Bitmap indexes can be defined for more than one column CREATE BITMAP INDEX i1 ON t1 (c1,c2);  Can be used for queries such as SELECT * FROM t1 WHERE c1 = 0; SELECT * FROM t1 WHERE c1 = 0 AND c2 = 0;  However for queries such as SELECT * FROM t1 WHERE c2 = 0;  there is apparently no equivalent to INDEX (SKIP SCAN)  Consider creating two indexes and allowing Oracle to perform join dynamically CREATE BITMAP INDEX i1 ON t1 (c1); CREATE BITMAP INDEX i2 ON t1 (c2);

9. © 2005 Julian Dyke juliandyke.com 9 Bitmap Row Sources

10. © 2005 Julian Dyke juliandyke.com 10 Bitmap Row Sources OperationVersion BITMAP INDEX (SINGLE VALUE)7.3.2 BITMAP INDEX (RANGE SCAN)7.3.2 BITMAP INDEX (FULL SCAN)7.3.2 BITMAP INDEX (FAST FULL SCAN)9.0.1 BITMAP AND7.3.2 BITMAP OR7.3.2 BITMAP MINUS7.3.2 BITMAP MERGE7.3.2 BITMAP KEY ITERATION7.3.2 BITMAP CONVERSION TO ROWIDS7.3.2 BITMAP CONVERSION COUNT7.3.2 BITMAP CONVERSION FROM ROWIDS7.3.2 BITMAP CONSTRUCTION7.3.2 BITMAP COMPACTION7.3.2

11. © 2005 Julian Dyke juliandyke.com 11 Bitmap Index Operation  Introduced in 7.3  Options are  BITMAP INDEX (SINGLE VALUE)  Builds a single bitmap for a given value  BITMAP INDEX (RANGE SCAN)  Builds a bitmap containing each value in the range  BITMAP INDEX (FULL SCAN)  Builds a bitmap containing each value in the index  BITMAP INDEX (FAST FULL SCAN)  Oracle 9.0.1 and above  Equivalent to INDEX (FAST FULL SCAN)

12. © 2005 Julian Dyke juliandyke.com 12 Bitmap Conversion Operation  Introduced in Oracle 7.3  Options are  BITMAP CONVERSION (TO ROWIDS)  Converts a bitmap into a set of ROWIDs  BITMAP CONVERSION (COUNT)  Returns the number of set bits in a bitmap  Used to implement COUNT() aggregates  BITMAP CONVERSION (FROM ROWIDS)  Converts a set of ROWIDs into a bitmap

13. © 2005 Julian Dyke juliandyke.com 13 Bitmap And Operation  Introduced in Oracle 7.3  Performs logical AND operation between two bitmaps CREATE TABLE t1 (c1 NUMBER, c2 NUMBER); CREATE BITMAP INDEX i1 ON t1 (c1); CREATE BITMAP INDEX i2 ON t1 (c2); 0SELECT STATEMENT Optimizer=CHOOSE 10BITMAP CONVERSION (TO ROWIDS) 21BITMAP AND 32BITMAP INDEX (SINGLE VALUE) OF 'I1‘ 42BITMAP INDEX (SINGLE VALUE) OF 'I2‘ SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2 FROM t1 WHERE c1 = 0 AND c2 = 0;

14. © 2005 Julian Dyke juliandyke.com 14 Bitmap Or Operation  Introduced in Oracle 7.3  Performs logical OR operation between two bitmaps CREATE TABLE t1 (c1 NUMBER, c2 NUMBER); CREATE BITMAP INDEX i1 ON t1 (c1); CREATE BITMAP INDEX i2 ON t1 (c2); 0SELECT STATEMENT Optimizer=CHOOSE 10TABLE ACCESS (BY INDEX ROWID) OF 'T1‘ 21BITMAP CONVERSION (TO ROWIDS) 32BITMAP OR 43BITMAP INDEX (SINGLE VALUE) OF 'I1‘ 53BITMAP INDEX (SINGLE VALUE) OF 'I2' SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2 FROM t1 WHERE c1 = 0 OR c2 = 0;

15. © 2005 Julian Dyke juliandyke.com 15 Bitmap Minus Operation  Introduced in Oracle 7.3  Performs logical MINUS operation between two bitmaps CREATE TABLE t1 (c1 NUMBER, c2 NUMBER); CREATE BITMAP INDEX i1 ON t1 (c1); CREATE BITMAP INDEX i2 ON t1 (c2); 0SELECT STATEMENT Optimizer=CHOOSE 10TABLE ACCESS (BY INDEX ROWID) OF 'T1‘ 21BITMAP CONVERSION (TO ROWIDS) 32BITMAP MINUS 43BITMAP MINUS 54BITMAP INDEX (SINGLE VALUE) OF 'I1‘ 64BITMAP INDEX (SINGLE VALUE) OF 'I2‘ 73BITMAP INDEX (SINGLE VALUE) OF 'I2' SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2 FROM t1 WHERE c1 = 0 AND NOT c2 = 0;

16. © 2005 Julian Dyke juliandyke.com 16 Bitmap Merge Operation  Introduced in Oracle 7.3  Merges two or more bitmaps together CREATE TABLE t1 (c1 NUMBER, c2 NUMBER); CREATE BITMAP INDEX i1 ON t1 (c1); CREATE BITMAP INDEX i2 ON t1 (c2); 0SELECT STATEMENT Optimizer=CHOOSE 10TABLE ACCESS (BY INDEX ROWID) OF 'T1' 21BITMAP CONVERSION (TO ROWIDS) 32BITMAP AND 43BITMAP INDEX (SINGLE VALUE) OF 'I2‘ 53BITMAP MERGE 65BITMAP INDEX (RANGE SCAN) OF 'I1' SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2 FROM t1 WHERE c1 > 0 AND c2 = 0;

17. © 2005 Julian Dyke juliandyke.com 17 Bitmap Construction / Compaction  Introduced in Oracle 7.3  Used by index creation/rebuild operations  Appear in EXPLAIN PLAN  Do not appear in AUTOTRACE or V$SQL_PLAN CREATE TABLE t1 (c1 NUMBER); 0CREATE INDEX STATEMENT Optimizer=CHOOSE 10INDEX BUILD (NON UNIQUE) OF 'I1‘ 21BITMAP COMPACTION 32SORT (CREATE INDEX) 43BITMAP CONSTRUCTION 54TABLE ACCESS (FULL) OF 'T1' EXPLAIN PLAN FOR CREATE BITMAP INDEX i1 ON t1 (c01)

18. © 2005 Julian Dyke juliandyke.com 18 Bitmap Key Iteration  Introduced in Oracle 7.3  Used to implement star transformations  Star transformations join three or more tables together -- Create fact table CREATE TABLE fact (factkey NUMBER,dim1key NUMBER,dim2key NUMBER); -- Create bitmap indexes on fact columns CREATE BITMAP INDEX index1 ON fact (dim1key); CREATE BITMAP INDEX index2 ON fact (dim2key); -- Set the number of rows BEGIN DBMS_STATS.SET_TABLE_STATS(USER,’FACT’,numrows=>100000); END; -- Create dimension tables CREATE TABLE dim1 (dim1key NUMBER,dim1desc NUMBER); CREATE TABLE dim2 (dim2key NUMBER,dim2desc NUMBER);

19. © 2005 Julian Dyke juliandyke.com 19 Bitmap Key Iteration  Star transformations require the following parameter SELECT /*+ STAR_TRANSFORMATION */ fact.factkey, dim1.dim1key, dim2.dim2key FROM fact, dim1, dim2 WHERE dim1.dim1key = fact.dim1key AND dim2.dim2key = fact.dim2key AND dim1.dim1desc = 100 AND dim2.dim2desc = 200; ALTER SESSION SET star_transformation_enabled = TRUE;  The statement

20. © 2005 Julian Dyke juliandyke.com 20 Bitmap Key Iteration  In Oracle 9.0.1 and above, the following plan is generated 0SELECT STATEMENT Optimizer=CHOOSE 10HASH JOIN 21MERGE JOIN (CARTESIAN) 32TABLE ACCESS (FULL) OF ‘DIM1' 42BUFFER (SORT) 54TABLE ACCESS (FULL) OF ‘DIM2' 61TABLE ACCESS (BY INDEX ROWID) OF ‘FACT‘ 76 BITMAP CONVERSION (TO ROWIDS) 87BITMAP AND 98BITMAP MERGE 109BITMAP KEY ITERATION 1110TABLE ACCESS (FULL) OF ‘DIM1‘ 1210BITMAP INDEX (RANGE SCAN) OF 'INDEX1‘ 138BITMAP MERGE 1413BITMAP KEY ITERATION 1514TABLE ACCESS (FULL) OF ‘DIM2‘ 1614BITMAP INDEX (RANGE SCAN) OF 'INDEX2'

21. © 2005 Julian Dyke juliandyke.com 21 B*Tree Bitmap Plans  In Oracle 7.3 and above it is possible to convert B*tree indexes into bitmaps  Enabled using _B_TREE_BITMAP_PLANS parameter  Default value FALSE (8.1.7 and below), TRUE (9.0.1 and above) CREATE TABLE t1 (c1 NUMBER, c2 NUMBER); BEGIN FOR f IN 0..9999 LOOP INSERT INTO t1 VALUES (MOD (f,100), MOD (f,200)); END LOOP; END; COMMIT; CREATE INDEX i1 ON t1 (c1); -- Not bitmap index CREATE INDEX i2 ON t1 (c2); -- Not bitmap index ANALYZE TABLE t1 COMPUTE STATISTICS;  For example (8192 byte block size)

22. © 2005 Julian Dyke juliandyke.com 22 B*Tree Bitmap Plans  In Oracle 9.2 the statement SELECT c1, c2 FROM t1 WHERE c1 = 0 AND c2 = 0;  generates the plan 0SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5) 10BITMAP CONVERSION (TO ROWIDS) 21BITMAP AND 32BITMAP CONVERSION (FROM ROWIDS) 43INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) (Cost=1) 52BITMAP CONVERSION (FROM ROWIDS) 65 INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) (Cost=1)

23. © 2005 Julian Dyke juliandyke.com 23 Internal Structure

24. © 2005 Julian Dyke juliandyke.com 24 Leaf Block Format  Each value in the index is represented by one or more bitmaps  Each bitmap represents a range of ROWIDs  Each leaf row entry typically contains four columns ColumnDescription 1Column Value 2Start ROWID 3End ROWID 4Bitmap  A multi-column index will have additional key columns  Branch block format and characteristics are identical to B*Tree indexes

25. © 2005 Julian Dyke juliandyke.com 25 Key Start ROWID End ROWID Bitmap Bitmaps and Leaf Blocks  For example, consider a bitmap index on column BEDROOMS Block 212Block 211 PROPERTY_CODE BEDROOMS RECEPTIONS GARAGES 2433123413220211 2 211/0 212/3 10000010 3 211/0 212/3 00110101 4 211/0 212/3 01001000 43235678321221121234 1322 0211 5678 3212 2112

26. © 2005 Julian Dyke juliandyke.com 26 Bitmap Block Dump  Partial block dump for the previous slide row#0[8013] flag: -----, lock: 0 col 0; len 2; (2): c1 03 col 1; len 6; (6): 01 00 01 82 00 00 col 2; len 6; (6): 01 00 01 83 00 07 col 3; len 3; (3): 00 c2 44 row#1[7988] flag: -----, lock: 0 col 0; len 2; (2): c1 04 col 1; len 6; (6): 01 00 01 82 00 00 col 2; len 6; (6): 01 00 01 83 00 07 col 3; len 5; (5): c8 0c f8 56 0a row#2[7965] flag: -----, lock: 0 col 0; len 2; (2): c1 05 col 1; len 6; (6): 01 00 01 82 00 00 col 2; len 6; (6): 01 00 01 83 00 07 col 3; len 3; (3): 01 c0 44 Key Start ROWID End ROWID Bitmap

27. © 2005 Julian Dyke juliandyke.com 27 B*Tree Block Dump row#0[8024] flag: -----, lock: 0 col 0; len 2; (2): c1 03 col 1; len 6; (6): 01 00 01 82 00 00 row#1[8012] flag: -----, lock: 0 col 0; len 2; (2): c1 03 col 1; len 6; (6): 01 00 01 83 00 02 row#2[8000] flag: -----, lock: 0 col 0; len 2; (2): c1 04 col 1; len 6; (6): 01 00 01 82 00 02 row#3[7988] flag: -----, lock: 0 col 0; len 2; (2): c1 04 col 1; len 6; (6): 01 00 01 82 00 03 Key ROWID row#4[7976] flag: -----, lock: 0 col 0; len 2; (2): c1 04 col 1; len 6; (6): 01 00 01 83 00 01 row#5[7964] flag: -----, lock: 0 col 0; len 2; (2): c1 04 col 1; len 6; (6): 01 00 01 83 00 03 row#6[7952] flag: -----, lock: 0 col 0; len 2; (2): c1 05 col 1; len 6; (6): 01 00 01 82 00 01 row#7[7940] flag: -----, lock: 0 col 0; len 2; (2): c1 05 col 1; len 6; (6): 01 00 01 83 00 00

28. © 2005 Julian Dyke juliandyke.com 28 Bitmap Pieces  Every bitmap piece has a start ROWID and an end ROWID  Start ROWID is rounded to the nearest byte boundary below  End ROWID is rounded to the nearest byte boundary above  Each indexed column value may have one or more bitmap pieces  A bitmap piece  covers a contiguous set of rows in one or more extents  may cross extent boundaries  may split within a block

29. © 2005 Julian Dyke juliandyke.com 29 Bitmap Pieces  For example the following are all valid bitmap pieces Start 211/0 End 533/15Start 532/0End 533/15End 533/7Start 211/8 Block 211Block 532Block 533 Start 532/8 End 532/15 Start 211/0End 533/15Start 533/0 End 532/15 Start 211/0End 533/15Start 532/8End 532/7 Extent 1Extent 2 Start 211/0End 211/15

30. © 2005 Julian Dyke juliandyke.com 30 Compression Algorithm  Bitmaps consists of zeros and ones  Zeros are compressed; ones are not compressed  Bitmaps can be subdivided into groups of bytes  First byte in each group determines length of group First ByteDescription < 192Single-byte group >= 192Multi-byte group

31. © 2005 Julian Dyke juliandyke.com 31 Single-Byte Groups  Byte represents the number of zero bits followed by a one bit  Maximum of 191 zero bits ByteBitmap 0010000000 0101000000 0200100000 0300010000 0800000000 10000000 0F00000000 00000001 1000000000 00000000 10000000 1100000000 00000000 01000000 1700000000 00000000 00000001 1800000000 00000000 00000000 10000000 1900000000 00000000 00000000 01000000  Range of byte values is 0x00 to 0xBF

32. © 2005 Julian Dyke juliandyke.com 32 Multi-Byte Groups  Multi-byte groups allow more than 192 bits to be skipped  First byte is a control byte  Next three bits indicate number of zero bytes to skip  If all three bits are set then number overflows to second byte  If top bit of second byte is set then number of zero bytes overflows to third byte  First two bits indicate this is a control byte (always 11)  Last three bits indicate number of bytes following control block (minimum 1, maximum 8) 11

33. © 2005 Julian Dyke juliandyke.com 33 Multi-Byte Groups  Examples CodeNumber of Zero Bytes Number of Zero Bits HexBinary C81100100000 D01101000018 D811011000216 E011100000324 E811101000432 F011110000540 F8 0011111000 00000000648 F8 0111111000 00000001756 F8 0211111000 00000010864 F8 7F11111000 011111111331064 F8 80 0111111000 10000000 000000011341072 F8 81 0111111000 10000001 000000011351080

34. © 2005 Julian Dyke juliandyke.com 34 Multi-Byte Groups  Last three bits indicate number of bytes following control block (minimum 1, maximum 8) CodeNumber of bytes Example HexBinary C8110010001C8 FF C9110010012C9 FF FF CA110010103CA FF FF FF CB110010114CB FF FF FF FF CC110011005CC FF FF FF FF FF CD110011016CD FF FF FF FF FF FF CE110011107CE FF FF FF FF FF FF FF CF110011118CF FF FF FF FF FF FF FF FF

35. © 2005 Julian Dyke juliandyke.com 35 Håkan Factor  For each table describes maximum number of rows that each block can theoretically hold  Derived from column definition  Affected by  Number of columns  Column datatypes and lengths  NOT NULL constraints  Stored in lower 11 (at least) bits of SYS.TAB$.SPARE1  Minimum value is 11 bytes per row to allow row to be migrated Block SizeMaximum Rows per Block 2048178 4096364 8192736 163841481

36. © 2005 Julian Dyke juliandyke.com 36 Håkan Factor  Håkan Factor can be adjusted using ALTER TABLE table_name MINIMIZE RECORDS_PER_BLOCK;  This command  Scans entire table  Counts number of rows in each block  Sets Håkan Factor in SPARE1 to maximum row count  Sets bit 0x8000 in SPARE1 to indicate value has been set  Subsequently modified blocks will be limited to the new Håkan Factor  Command is reversed using ALTER TABLE table_name NOMINIMIZE RECORDS_PER_BLOCK;

37. © 2005 Julian Dyke juliandyke.com 37 Håkan Factor  Hakan Factor is used when compressing bitmaps  Each bitmap represents an array Blocks Maximum rows per block  Minimising records per block reduces size of this array Blocks Maximum rows per block  Reduces memory required to access/manipulate bitmap  May reduce disk space required to hold bitmap

38. © 2005 Julian Dyke juliandyke.com 38 Nulls  B*Tree indexes do not include NULL values  Bitmap indexes do include a leaf row for NULL values  For example, if I1 is a bitmap index, the statement SELECT COUNT(*) FROM t1 WHERE c1 IS NULL;  generates the plan 0SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5) 10SORT (AGGREGATE) 21BITMAP CONVERSION (COUNT) 32BITMAP INDEX (SINGLE VALUE) OF ‘I1'  If I1 is a B*Tree index the same statement generates the plan 0SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5) 10SORT (AGGREGATE) 21TABLE ACCESS (FULL) OF ‘T1’

39. © 2005 Julian Dyke juliandyke.com 39 Distinct Keys  This example shows how the number of distinct keys affects number of leaf blocks for 100000 row table  8192 byte block size Distinct KeysB*TreeBitmap 12373 2 5 5 13 1023725 10023750 100023748 1000023787 50000237210 100000237363

40. © 2005 Julian Dyke juliandyke.com 40 Clustering  Size of bitmap indexes is affected by the clustering of the data  For example 100000 row table  Column1 and Column2 contain 100 distinct values Column1 (Distributed) Column2 (Clustered) Column1 (Distributed) Column2 (Clustered) Height22 Blocks248 Leaf Rows100 Leaf Blocks203 Branch Rows192 Branch Blocks11

41. © 2005 Julian Dyke juliandyke.com 41 Bitmap Index DML

42. © 2005 Julian Dyke juliandyke.com 42 Inserts  In Oracle 9.2 and below, insertion is very inefficient  When a row is inserted  if leaf row already exists for ROWID then bitmap is updated  otherwise a new leaf row is inserted for the eight bits around the new row  In Oracle 10g, insertion is more efficient  rows are inserted into existing leaf rows where possible  if necessary start ROWID or end ROWID is adjusted

43. © 2005 Julian Dyke juliandyke.com 43 Inserts  Insertion behaviour in Oracle 9.2 and below Bitmap Index Leaf Rows Block 573Block 574 Table Rows 2 573/0 574/7 Key Start End Block 575 2 574/8 574/15 Key Start End 2 575/0 575/7 Key Start End 2 575/8 575/15 Key Start End Key = 2 Key <> 2

44. © 2005 Julian Dyke juliandyke.com 44 Inserts  Insertion behaviour in Oracle 10g Bitmap Index Leaf Rows Block 573Block 574 Table Rows 2 573/0 574/7 Key Start End Block 575 574/15575/7575/15 Key = 2 Key <> 2

45. © 2005 Julian Dyke juliandyke.com 45 Updates  As with B*Tree indexes updates consist of a delete followed by an insert  delete old value from bitmap piece  add new value from bitmap piece  At least two bitmap pieces are affected by every update  Also applies to bitmap indexes containing NULL values  When bitmaps are updated on a block  Must have sufficient space on block for old and new rows  Otherwise block is split  Can lead to long branch block rows

46. © 2005 Julian Dyke juliandyke.com 46 Locking  When a bitmap index is updated, a row lock is taken for the index leaf entry  The index leaf entry contains a bitmap which may cover many rows across a number of blocks  No other transaction can update an indexed column in any row covered by that bitmap piece until the original transaction commits or rolls back

47. © 2005 Julian Dyke juliandyke.com 47 Locking Bitmap Index Leaf Rows 2 10499100107 4332 5152010 97929498 3423 15251020 89868890 4332 1510205 80777883 4332 102555 Block 211Block 212Block 213Block 214 UPDATE t1 SET c2 = 4 WHERE c1 = 88; c1 c2 c3 3334444 Table Rows 2 211/0 214/3 Key Start End Lock0 3 211/0 212/3 Key Start End Lock0 3 211/0 212/3 Key Start End Lock1 3 213/0 214/3 Key Start End Lock0 4 211/0 214/3 Key Start End Lock0 4 211/0 214/3 Key Start End Lock1 4 20 88 CREATE BITMAP INDEX i1 ON t1 (c2); Updated UPDATE t1 SET c2 = 4 WHERE c1 = 88; Locked

48. © 2005 Julian Dyke juliandyke.com 48 Leaf Block Splits  When bitmaps indexes are updated  Old row is retained until transaction is committed  New row is written to free space in block  If no free space in existing block, new block is used  Leaf rows stored in ascending order  Key, start and end ROWIDs are unchanged therefore leaf row ordered by bitmap  If last bitmap in block is updated then block is split  Branch blocks contain unique leading edge for columns  If change is at end of bitmap, entire bitmap may be copied up into branch block

49. © 2005 Julian Dyke juliandyke.com 49 Leaf Block Splits  Example of leaf block split  Oracle 9.2 – 8192 byte block size  8 distinct values – approximately 3000 rows each 1 2 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 3 4 START END 001000 000100 000010 000001 100000 000010 000001 100000 010000 001000 START END 5 6 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 7 8 START END 001000 000100 000010 000001 100000 000100 000010 000001 100000 010000 START END 3 5 17 Branch Block Leaf Blocks Initial state. Branch rows initial contain index key values only

50. © 2005 Julian Dyke juliandyke.com 50 Leaf Block Splits 1 2 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 2 START END 100000 010000 001000 000100 000010 3 4 START END 001000 000100 000010 000001 100000 000010 000001 100000 010000 001000 START END 4 START END 100000 010000 001000 000100 000010 5 6 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 7 8 START END 001000 000100 000010 000001 100000 000100 000010 000001 100000 010000 START END UPDATE t1 SET c2 = 2 /* was 4 */ WHERE c1 = 23988; 2 3 START END 100000 010000 001000 000100 000010 4 1 START END 010000 001000 000100 000010 000001 7 5 Updated Deleted Branch Block Leaf Blocks Deleted row is retained until end of transaction. Leaf block splits between updated and deleted rows. Branch row must contain bitmap

51. © 2005 Julian Dyke juliandyke.com 51 Leaf Block Splits 1 2 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 2 START END 100000 010000 001000 000100 000010 3 4 START END 001000 000100 000010 000001 100000 000010 000001 100000 010000 001000 START END 4 START END 100000 010000 001000 000100 000010 5 6 START END 100000 010000 001000 000100 000010 010000 001000 000100 000010 000001 START END 6 START END 100000 010000 001000 000100 000010 7 8 START END 001000 000100 000010 000001 100000 000100 000010 000001 100000 010000 START END 8 START END 000010 000001 100000 010000 001000 5 1 2 3 START END 100000 010000 001000 000100 000010 4 1 START END 010000 001000 000100 000010 000001 6 7 START END 100000 010000 001000 000100 000010 8 5 START END 010000 001000 000100 000010 000001 UPDATE t1 SET c2 = 6 /* was 8 */ WHERE c1 = 23992; Updated Deleted Insufficient space for new branch rows in branch block Branch block splits. New root block created. Index height increases

52. © 2005 Julian Dyke juliandyke.com 52 Conclusions  Columns with relatively high cardinality may be suitable for bitmap indexes  Clustering of data significantly affects bitmap index size  DML is very inefficient in Oracle 9i and below; in Oracle 10g it is much more efficient  Be aware of implications of locking when indexes are updated by multiple sessions  In Oracle 10g bitmap indexes are viable for volatile tables if all updates are made by one session

53. © 2005 Julian Dyke juliandyke.com 53 References  Jonathan Lewis  Understanding Bitmap Indexes (http://www.dbazine.com)http://www.dbazine.com  Optimising Oracle – Performance by Design 2001-2003  Steve Adams  Miracle Master Class 2003  Julian Dyke (http://www.juliandyke.com)http://www.juliandyke.com

54. © 2005 Julian Dyke juliandyke.com 54 Thank you for your interest For more information and to provide feedback please contact me My e-mail address is: info@juliandyke.com My website address is: www.juliandyke.com