Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

452
CHAPTER 11 ■ INDEXES
This example shows the power of the bitmap indexes. Oracle is able to see the location
in (1,10,30) and knows to read the index on location for these three values and logically OR
together the “bits” in the bitmap. It then takes that resulting bitmap and logically ANDs that
with the bitmaps for AGE_GROUP='41 AND OVER' and GENDER='M'. Then a simple count of 1s
and the answer is ready.
ops$tkyte@ORA10G> select *
2 from t
3 where ( ( gender = 'M' and location = 20 )
4 or ( gender = 'F' and location = 22 ))
5 and age_group = '18 and under';
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=77 Card=507 Bytes=16731)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (TABLE) (Cost=77 Card=507 ...
2 1 BITMAP CONVERSION (TO ROWIDS)
3 2 BITMAP AND
4 3 BITMAP INDEX (SINGLE VALUE) OF 'AGE_GROUP_IDX' (INDEX (BITMAP))
5 3 BITMAP OR
6 5 BITMAP AND
7 6 BITMAP INDEX (SINGLE VALUE) OF 'LOCATION_IDX' (INDEX (BITMAP))
8 6 BITMAP INDEX (SINGLE VALUE) OF 'GENDER_IDX' (INDEX (BITMAP))
9 5 BITMAP AND
10 9 BITMAP INDEX (SINGLE VALUE) OF 'GENDER_IDX' (INDEX (BITMAP))
11 9 BITMAP INDEX (SINGLE VALUE) OF 'LOCATION_IDX' (INDEX (BITMAP))
This shows similar logic: the plan shows the OR’d conditions are each evaluated by AND-ing
together the appropriate bitmaps and then OR-ing together those results. Throw in another AND
to satisfy the AGE_GROUP='18 AND UNDER' and we have it all. Since we asked for the actual rows
this time, Oracle will convert each bitmap 1 and 0 into rowids to retrieve the source data.
In a data warehouse or a large reporting system supporting many ad hoc SQL queries, this
ability to use as many indexes as make sense simultaneously comes in very handy indeed.
Using conventional B*Tree indexes here would not be nearly as usual or usable, and as the
number of columns that are to be searched by the ad hoc queries increases, the number of
combinations of B*Tree indexes you would need increases as well.
However, there are times when bitmaps are not appropriate. They work well in a readintensive
environment, but they are extremely ill suited for a write-intensive environment.
The reason is that a single bitmap index key entry points to many rows. If a session modifies
the indexed data, then all of the rows that index entry points to are effectively locked in most
cases. Oracle cannot lock an individual bit in a bitmap index entry; it locks the entire bitmap
index entry. Any other modifications that need to update that same bitmap index entry will be
locked out. This will seriously inhibit concurrency, as each update will appear to lock potentially
hundreds of rows preventing their bitmap columns from being concurrently updated. It
will not lock every row as you might think—just many of them. Bitmaps are stored in chunks,
so using the earlier EMP example we might find that the index key ANALYST appears in the index
many times, each time pointing to hundreds of rows. An update to a row that modifies the JOB