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

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 7
that they wanted to index that column. They had read somewhere that bitmap indexes are
for low-cardinality columns (columns that have only a few distinct values) so it seemed a natural
fit.
Nevertheless, that bitmap index was the cause of all of their problems. In a bitmap index,
a single key entry points to many rows—hundreds or more of them. If you update a bitmap
index key, the hundreds of records to which that key points are effectively locked as well as the
single row you are actually updating.
So, someone inserting a new N record would lock an N key in the bitmap index, effectively
locking hundreds of other N records as well. Meanwhile, the process trying to read this
table and process the records would be prevented from modifying some N record to be a
Y (processed) record, because in order for it to update this column from N to Y, it would need
to lock that same bitmap index key. In fact, other sessions just trying to insert a new record
into this table would be blocked as well, as they would be attempting to lock this same bitmap
key entry. In short, the developers had implemented a set of structures that at most one person
would be able to insert or update against at a time!
I can demonstrate this scenario easily with a simple example. Here, I use two sessions to
demonstrate the blocking that can easily happen:
ops$tkyte@ORA10G> create table t ( processed_flag varchar2(1) );
Table created.
ops$tkyte@ORA10G> create bitmap index t_idx on t(processed_flag);
Index created.
ops$tkyte@ORA10G> insert into t values ( 'N' );
1 row created.
Now, in another SQL*Plus session, if I execute
ops$tkyte@ORA10G> insert into t values ( 'N' );
that statement will “hang” until I issue a COMMIT in the first blocking session.
So here we had an issue whereby a lack of understanding of the database feature (bitmap
indexes), of what it did and how it worked, meant that the database was doomed to poor scalability
from the start. Once this issue was discovered, correcting it was easy. We needed an index
on the processed flag column, but not a bitmap index. We needed a conventional B*Tree
index here. This took a bit of convincing because no one wanted to believe that use of a conventional
index on a column with two distinct values was a “good idea.” But after setting up a
simulation (I am very much into simulations, testing, and experimenting), we were able to
prove that it was the correct approach. There were two ways to approach the indexing of this
particular column:
• Just create an index on the processed flag column.
• Create an index only on the processed flag column when the processed flag is N—that
is, only index the values of interest. Typically, we do not want to use an index where the
processed flag is Y, since the vast majority of the records in the table would have the
value Y. Notice that I did not say “We never want to use”—if you need to frequently
count the number of processed records for some reason, then an index on the
processed records may well prove useful.