Let us examine how Oracle can speed queries using bitmapped indexes.
Bitmap indexes are a powerful feature in Oracle databases that significantly enhance the speed of SQL queries, especially when dealing with low-cardinality columns, those that have few unique values relative to the number of rows that contain them. They are highly efficient in scenarios where the cardinality of a column is less than 1% of the number of rows in the table. Bitmap indexes are used in Data Warehousing environments where ad hoc queries, often complex, are common and the data is primarily read-only.
Here is an in-depth explanation of how bitmap indexes boost query performance:
- Storage Efficiency: Bitmap indexes store rowids associated with each distinct column value as a set of bits (1s and 0s), not as physical or logical rowids as in the case of B-tree indexes. This makes bitmap indexes much smaller and more space-efficient than their B-tree counterparts. The reduced size helps decrease I/O operations and increase buffer cache hit ratios, leading to faster query responses.
- Bitwise Operations: Bitmap indexes take advantage of bitwise operations (AND, OR, XOR) for query processing. For instance, when a SQL query includes conditions on multiple bitmap indexed columns combined with logical operators (like AND or OR), Oracle can rapidly perform these operations on the corresponding bitmaps to get the result set. Bitwise operations are extremely fast, even on large bitmaps, accelerating query performance.
- Star Schema Queries: Bitmap indexes are especially efficient for star schema queries, a common structure in data warehousing environments. When joining a large fact table to one or more smaller dimension tables, bitmap indexes can leverage a technique called bitmap star transformation. This process converts the join into a set of bitmap operations, yielding a considerable speedup compared to traditional join operations.
- Bitmap Join Indexes: Bitmap join indexes, a specific type of bitmap index, pre-join a large table to a smaller one, storing the result as a bitmap index on the larger table. When a query includes a join between these tables, Oracle can use the bitmap join index instead of performing the join operation, significantly speeding up the query.
- Bitmap Conversion to Rowids: In certain scenarios, Oracle uses a feature called Bitmap Conversion to Rowids (BCR). BCR transforms the bitmap index into actual rowids during the execution of the query. It's beneficial for mixed workloads where you have both OLTP and decision support within the same application, adding to the flexibility of query optimization.
- Parallel Execution: Bitmap indexes are inherently suitable for parallel query execution. The bitmaps for different values are independent and can be operated on in parallel, thus further increasing the performance on multi-core, multi-CPU systems.
In conclusion, bitmap indexes provide a range of benefits in the context of Oracle SQL tuning, particularly for data warehousing and reporting applications. However, they are not a one-size-fits-all solution. They can significantly slow down transactional workloads with frequent updates due to the need to lock the entire bitmap for a particular value during updates, which can lead to concurrency issues. Therefore, understanding the workload type and data characteristics is essential to leverage bitmap indexes effectively.
In spite of the advantages they offer, bitmapped indexes are not applicable to every query. They are most useful when the following conditions are true:
- Index columns have few distinct values (less than 20)
- The SQL has several predicates involving bitmap indexes in the WHERE clause
- The SQL select statement is INDEX ONLY, meaning that reading the index without reading the table will satisfy the query.
In summary, bitmap indexes provide excellent performance, while using less storage. Because of their different performance characteristics, you should create bitmap indexes on low cardinality data, and keep B*tree indexes on high-cardinality data.
The next lesson discusses STAR index queries.