Bit Map Index Internals

Bitmap Index
Internals
Julian Dyke
Independent Consultant
Web Version
1
2005 Julian Dyke
Agenda
Introduction
Bitmap
Row Sources
Internal Structures
Bitmap Index DML
Conclusion
2005 Julian Dyke
Introduction
2005 Julian Dyke
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
2005 Julian Dyke
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
2005 Julian Dyke
Bitmap Indexes
For example
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
2005 Julian Dyke
Logical Operations
Bitmaps can be combined using the logical operations AND,

OR , NOT.
A
A AND B
A OR B
NOT A
Oracle also implements a MINUS operation internally

A MINUS B is equivalent to A AND NOT B
2005 Julian Dyke
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);

2005 Julian Dyke
Bitmap Row
Sources
2005 Julian Dyke
Bitmap Row Sources
Operation
Version
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 AND
7.3.2
BITMAP OR
7.3.2
BITMAP MINUS
7.3.2
BITMAP MERGE
7.3.2
BITMAP KEY ITERATION
7.3.2
BITMAP CONVERSION TO ROWIDS
7.3.2
BITMAP CONVERSION COUNT
7.3.2
BITMAP CONVERSION FROM ROWIDS
7.3.2
BITMAP CONSTRUCTION
7.3.2
BITMAP COMPACTION
7.3.2
2005 Julian Dyke
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)
2005 Julian Dyke
Bitmap Conversion Operation

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
2005 Julian Dyke
Bitmap And Operation

Performs logical AND operation between two bitmaps
CREATE TABLE t1 (c1 NUMBER, c2 NUMBER);
SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2
FROM t1
WHERE c1 = 0 AND c2 = 0;
0
1
2
3
4
0
1
2
2
2005 Julian Dyke
SELECT STATEMENT Optimizer=CHOOSE

BITMAP AND
BITMAP INDEX (SINGLE VALUE) OF 'I1
Bitmap Or Operation

Performs logical OR operation between two bitmaps
FROM t1
WHERE c1 = 0 OR c2 = 0;
0
1
2
3
4
5
0
1
2
3
3
2005 Julian Dyke

TABLE ACCESS (BY INDEX ROWID) OF 'T1
BITMAP OR
BITMAP INDEX (SINGLE VALUE) OF 'I2'
Bitmap Minus Operation

Performs logical MINUS operation between two bitmaps
FROM t1
WHERE c1 = 0 AND NOT c2 = 0;
0
1
2
3
4
5
6
7
0
1
2
3
4
4
3
2005 Julian Dyke

TABLE ACCESS (BY INDEX ROWID) OF 'T1
BITMAP MINUS
BITMAP MINUS
BITMAP INDEX (SINGLE VALUE) OF 'I2'
Bitmap Merge Operation

Merges two or more bitmaps together
FROM t1
WHERE c1 > 0 AND c2 = 0;
0
1
2
3
4
5
6
0
1
2
3
3
5
2005 Julian Dyke

TABLE ACCESS (BY INDEX ROWID) OF 'T1'
BITMAP AND
BITMAP MERGE
BITMAP INDEX (RANGE SCAN) OF 'I1'
Bitmap Construction / Compaction

Used by index creation/rebuild operations
Appear in EXPLAIN PLAN
Do not appear in AUTOTRACE or V$SQL_PLAN
CREATE TABLE t1 (c1 NUMBER);
EXPLAIN PLAN FOR
CREATE BITMAP INDEX i1 ON t1 (c01)
0
1
2
3
4
5
0
1
2
3
4
2005 Julian Dyke
CREATE INDEX STATEMENT Optimizer=CHOOSE

INDEX BUILD (NON UNIQUE) OF 'I1
BITMAP COMPACTION
SORT (CREATE INDEX)
BITMAP CONSTRUCTION
TABLE ACCESS (FULL) OF 'T1'
Bitmap Key Iteration

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);
2005 Julian Dyke
Star transformations require the following parameter

ALTER SESSION SET star_transformation_enabled = TRUE;
The statement
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;
2005 Julian Dyke
In Oracle 9.0.1 and above, the following plan is generated

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

0 HASH JOIN
1
MERGE JOIN (CARTESIAN)
2
TABLE ACCESS (FULL) OF DIM1'
2
BUFFER (SORT)
4
TABLE ACCESS (FULL) OF DIM2'
1
TABLE ACCESS (BY INDEX ROWID) OF FACT
6
7
BITMAP AND
8
BITMAP MERGE
9
10
TABLE ACCESS (FULL) OF DIM1
10
BITMAP INDEX (RANGE SCAN) OF 'INDEX1
8
BITMAP MERGE
13
14
TABLE ACCESS (FULL) OF DIM2
14
BITMAP INDEX (RANGE SCAN) OF 'INDEX2'
2005 Julian Dyke
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)
For example (8192 byte block size)

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;
2005 Julian Dyke
B*Tree Bitmap Plans
In Oracle 9.2 the statement

SELECT c1, c2
FROM t1
WHERE c1 = 0 AND c2 = 0;
0
1
2
3
4
5
6
generates the plan

0
1
2
3
2
5
SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5)

BITMAP AND
INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) (Cost=1)
INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) (Cost=1)
2005 Julian Dyke
Internal
Structure
2005 Julian Dyke
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
Column
Description
Column Value
Start ROWID
End ROWID
Bitmap
A multi-column index will have additional key columns

Branch block format and characteristics are identical to B*Tree
indexes
2005 Julian Dyke
Bitmaps and Leaf Blocks
For example, consider a bitmap index on column BEDROOMS
Key
Start ROWID
211/0
211/0
211/0
End ROWID
212/3
212/3
212/3
Bitmap
10000010
00110101
01001000
PROPERTY_CODE
1
2
1
0
BEDROOMS
RECEPTIONS
GARAGES
2
4
3
2
Block 211
2005 Julian Dyke
3
3
2
1
4
3
2
1
5
4
3
2
6
3
2
1
Block 212
7
2
1
1
8
3
2
2
Bitmap Block Dump
Partial block dump for the previous slide

Key
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
2005 Julian Dyke
Start ROWID
End ROWID
Bitmap
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
2005 Julian Dyke
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
2005 Julian Dyke
Bitmap Pieces
For example the following are all valid bitmap pieces

Start 211/0
End 533/15
Start 211/0 End 211/15
Start 532/0
Start 211/0
End 532/15 Start 533/0 End 533/15
Start 211/0
End 532/7
Start 211/8
Block 211
Extent 1
2005 Julian Dyke
End 533/15
Start 532/8
End 533/15
End 533/7
Start 532/8
End 532/15
Block 532
Block 533
Extent 2
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
2005 Julian Dyke
First Byte
Description
< 192
Single-byte group
>= 192
Multi-byte group
Single-Byte Groups
Byte represents the number of zero bits followed by a one bit

Maximum of 191 zero bits
Byte
Bitmap
00
10000000
01
01000000
02
00100000
03
00010000
08
00000000 10000000
0F
00000000 00000001
10
00000000 00000000 10000000
11
00000000 00000000 01000000
17
00000000 00000000 00000001
18
00000000 00000000 00000000 10000000
19
00000000 00000000 00000000 01000000
Range of byte values is 0x00 to 0xBF
2005 Julian Dyke
Multi-Byte Groups
Multi-byte groups allow more than 192 bits to be skipped

First byte is a control byte
1 1
First two bits indicate this is a control byte (always 11)
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
Last three bits indicate number of bytes following control

block (minimum 1, maximum 8)
2005 Julian Dyke
Multi-Byte Groups
Examples
Code
Hex
Binary
Number of
Zero Bytes
Number of
Zero Bits
C8
11001000
D0
11010000
D8
11011000
16
E0
11100000
24
E8
11101000
32
F0
11110000
40
F8 00
11111000 00000000
48
F8 01
11111000 00000001
56
F8 02
11111000 00000010
64
F8 7F
11111000 01111111
133
1064
F8 80 01
11111000 10000000 00000001
134
1072
F8 81 01
11111000 10000001 00000001
135
1080
2005 Julian Dyke
Multi-Byte Groups
Last three bits indicate number of bytes following control

block (minimum 1, maximum 8)
Code
Binary
Number of
bytes
C8
11001000
C8 FF
C9
11001001
C9 FF FF
CA
11001010
CA FF FF FF
CB
11001011
CB FF FF FF FF
CC
11001100
CC FF FF FF FF FF
CD
11001101
CD FF FF FF FF FF FF
CE
11001110
CE FF FF FF FF FF FF FF
CF
11001111
CF FF FF FF FF FF FF FF FF
Hex
2005 Julian Dyke
Example
Hkan 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 Size
2005 Julian Dyke
Maximum
Rows per Block
2048
178
4096
364
8192
736
16384
1481
Hkan Factor
Hkan 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 Hkan 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 Hkan
Factor
Command is reversed using
ALTER TABLE table_name

NOMINIMIZE RECORDS_PER_BLOCK;
2005 Julian Dyke
Hkan 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
2005 Julian Dyke
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

0
1 0
SORT (AGGREGATE)
2 1
BITMAP CONVERSION (COUNT)
3 2
BITMAP INDEX (SINGLE VALUE) OF I1'
If I1 is a B*Tree index the same statement generates the plan

0
1 0
SORT (AGGREGATE)
2 1
TABLE ACCESS (FULL) OF T1
2005 Julian Dyke
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 Keys
B*Tree
Bitmap
237
237
237
13
10
237
25
100
237
50
1000
237
48
10000
237
87
50000
237
210
100000
237
363
2005 Julian Dyke
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)
Height
Blocks
24
Leaf Rows
100
100
Leaf Blocks
20
Branch Rows
19
Branch Blocks
2005 Julian Dyke
Bitmap Index
DML
2005 Julian Dyke
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
2005 Julian Dyke
Inserts
Insertion behaviour in Oracle 9.2 and below
Bitmap Index Leaf Rows
Key
Key
Key
Start 573/0
Start 574/8
Start
575/0
Start
575/8
End 574/7
End 574/15
End
575/7
End
575/15
Block 573
Table Rows
Key
2005 Julian Dyke
Block 574
Block 575
Key = 2
Key <> 2
Inserts
Insertion behaviour in Oracle 10g
Key
Start 573/0
End 574/7
575/15
575/7
574/15
Block 573
Table Rows
2005 Julian Dyke
Block 574
Block 575
Key = 2
Key <> 2
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
2005 Julian Dyke
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
2005 Julian Dyke
Locking

Lock
2Key
Lock
0
1
Lock
Lock
0
1
Key
Key
Key
Start
211/0
Start
211/0
Start
213/0
Start
211/0
End
214/3
End
212/3
End
214/3
End
214/3
c1
77
78
80
83
86
88
89
90
92
94
97
98
99
c2
4
3
c3
25
10
10
20
15
25
10
15
20
15
20
10
Block 211
Table Rows
2005 Julian Dyke
Block 212
Block 213
UPDATE t1
SET c2 = 4
WHERE c1 = 88;
100 104 107
Block 214
Updated
Locked
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
2005 Julian Dyke
Leaf Block Splits
Example of leaf block split

Oracle 9.2 8192 byte block size
8 distinct values approximately 3000 rows each
1
START
END
100000
010000
001000
000100
000010
START
END
010000
001000
000100
000010
000001
START
END
001000
000100
000010
000001
100000
START
END
000010
000001
100000
010000
001000
START
END
100000
010000
001000
000100
000010
START
END
010000
001000
000100
000010
000001
START
END
001000
000100
000010
000001
100000
START
END
000100
000010
000001
100000
010000
Initial state. Branch rows initial contain index key values only
Branch
Block
2005 Julian Dyke
Leaf
Blocks
Leaf Block Splits

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

UPDATE t1
SET c2 = 6 /* was 8 */
WHERE c1 = 23992;
1
START
END
100000
010000
001000
000100
000010
Updated
Deleted
START
END
100000
010000
001000
000100
000010
START
END
010000
001000
000100
000010
000001
START
END
010000
001000
000100
000010
000001
START
END
100000
010000
001000
000100
000010
START
END
010000
001000
000100
000010
000001
START
END
100000
010000
001000
000100
000010
START
END
001000
000100
000010
000001
100000
START
END
000010
000001
100000
010000
001000
START
END
100000
010000
001000
000100
000010
START
END
100000
010000
001000
000100
000010
START
END
010000
001000
000100
000010
000001
START
END
100000
010000
001000
000100
000010
START
END
001000
000100
000010
000001
100000
START
END
000100
000010
000001
100000
010000
START
END
000010
000001
100000
010000
001000
Insufficient space for new branch rows in branch block

Branch block splits. New root block created. Index height increases
2005 Julian Dyke
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
2005 Julian Dyke
References
Jonathan Lewis
Understanding Bitmap Indexes (http://www.dbazine.com)
Optimising Oracle Performance by Design 2001-2003
Steve Adams
Miracle Master Class 2003
Julian Dyke (http://www.juliandyke.com)
2005 Julian Dyke
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
2005 Julian Dyke

Bit Map Index Internals

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bit Map Index Internals

Transféré par

Droits d'auteur :

Formats disponibles

Bitmap Index

2005 Julian Dyke

2005 Julian Dyke

2005 Julian Dyke

Introduced in Oracle 7.3

Originally intended for columns with

Often used in DSS environments

2005 Julian Dyke

Bitmap Index Properties

2005 Julian Dyke

2005 Julian Dyke

Bitmaps can be combined using the logical operations AND,

Oracle also implements a MINUS operation internally

2005 Julian Dyke

Multicolumn Bitmap Indexes

Bitmap indexes can be defined for more than one column

Can be used for queries such as

However for queries such as

there is apparently no equivalent to INDEX (SKIP SCAN)

CREATE BITMAP INDEX i1 ON t1 (c1);

2005 Julian Dyke

2005 Julian Dyke

Bitmap Row Sources

BITMAP INDEX (SINGLE VALUE)

BITMAP INDEX (RANGE SCAN)

BITMAP INDEX (FULL SCAN)

BITMAP INDEX (FAST FULL SCAN)

BITMAP KEY ITERATION

BITMAP CONVERSION TO ROWIDS

BITMAP CONVERSION COUNT

BITMAP CONVERSION FROM ROWIDS

2005 Julian Dyke

Bitmap Index Operation

BITMAP INDEX (RANGE SCAN)

BITMAP INDEX (FULL SCAN)

BITMAP INDEX (FAST FULL SCAN)

2005 Julian Dyke

Bitmap Conversion Operation

Introduced in Oracle 7.3

BITMAP CONVERSION (COUNT)

BITMAP CONVERSION (FROM ROWIDS)

2005 Julian Dyke

Bitmap And Operation

Introduced in Oracle 7.3

2005 Julian Dyke

SELECT STATEMENT Optimizer=CHOOSE

Introduced in Oracle 7.3

2005 Julian Dyke

SELECT STATEMENT Optimizer=CHOOSE

Bitmap Minus Operation

Introduced in Oracle 7.3

2005 Julian Dyke

SELECT STATEMENT Optimizer=CHOOSE

Bitmap Merge Operation

Introduced in Oracle 7.3

2005 Julian Dyke

SELECT STATEMENT Optimizer=CHOOSE

Bitmap Construction / Compaction

Introduced in Oracle 7.3

2005 Julian Dyke

CREATE INDEX STATEMENT Optimizer=CHOOSE

Bitmap Key Iteration

Introduced in Oracle 7.3

-- Create fact table