INDEX

1 Index
2 Difference between Full Index Scans and Fast Full Index Scans
3 Oracle bitmap index maximum distinct values
4 Bitmap Index vs. B-tree Index: Which and When? by Vivek Sharma
http://www.oracle.com/technetwork/articles/sharma-indexes-093638.html
5
6
 Difference between Full Index Scans and Fast Full Index
Scans
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3193365100346233806
An index fast full scan reads the ENTIRE index, unsorted, as it exists on disk. It is basically using the index as a "skinny"
version of the table. The query in question would only be accessing attributes in the index (we are not using the index
as a way to get to the table, we are using the index INSTEAD of the table) We use multiblock IO and read all of the
leaf, branch and the root block. We ignore the branch and root blocks and just process the (unordered) data on the
leaf blocks.

An index full scan is when we read the index a block at a time - from start to finish. We'll read the root block, navigate
down the left hand side of the index (or right if we are doing a descending full scan) and then when we hit the leaf
block - we'll read across the entire bottom of the index - a block at a time - in sorted order. We use single block IO,
not multiblock IO for this operation.

I wanna performe an index full scan on the table instead of a full table scan although that a full table sacn is likely to be
faster than an index full scan.

So, i wrote down a following sql statement

SELECT /*+ INDEX(t XPKGROUP_CUSTOMER)*/t.* FROM group_customer t;

that is the beginning of that discussion. In that case - the index XPKGROUP_CUSTOMER must have at least one NOT
NULL attribute because every single row in T is going to be counted and if there is a row in T with all of the
indexed attributes "NULL" - it won't appear in the index. The index does not point to EVERY single row in the table.

My counter example demonstrated an index fast full scan - where by we used the smaller index instead of the table -
to find all of the rows in the table SUCH THAT "filter("OWNER"='SCOTT')". Now, if OWNER = 'SCOTT', then owner is
known to be NOT NULL for the set of rows of interest - therefore any index that contained OWNER would be good
enough to fast full scan to count those rows.

Understand the concepts here:

a b*tree index on a set of attributes that are all NULLABLE does not point to every row in the table (does not HAVE to
point to every row in the table is more accurate).

if you have to access EVERY ROW in the table, you cannot use that index.

if you have to access a subset of rows in the table, and the subset is defined as a predicate on at least one of the
indexed columns AND that predicate is not of the form "column is null", then we CAN use the index to find those
rows - since we know now that that attribute is NOT NULL and hence would appear in the index.
 Oracle Bitmap Index Techniques
http://www.dba-oracle.com/oracle_tips_bitmapped_indexes.htm

Oracle bitmap indexes are very different from standard b-tree indexes. In bitmap
structures, a two-dimensional array is created with one column for every row in the
table being indexed. Each column represents a distinct value within the bitmapped
index. This two-dimensional array represents each value within the index multiplied
by the number of rows in the table.

At row retrieval time, Oracle decompresses the bitmap into the RAM data buffers so it
can be rapidly scanned for matching values. These matching values are delivered to
Oracle in the form of a Row-ID list, and these Row-ID values may directly access the
required information.

The real benefit of bitmapped indexing occurs when one table includes multiple
bitmapped indexes. Each individual column may have low cardinality. The creation of
multiple bitmapped indexes provides a very powerful method for rapidly answering
difficult SQL queries.

Using this bitmap merge methodology, Oracle can provide sub-second response time when
working against multiple low-cardinality columns.

Also see these important notes on Oracle bitmap index maximum distinct values

For example, assume there is a motor vehicle database with numerous low-cardinality
columns such as car_color, car_make, car_model, and car_year. Each column
contains less than 100 distinct values by themselves, and a b-tree index would be
fairly useless in a database of 20 million vehicles.
However, combining these indexes together in a query can provide blistering response
times a lot faster than the traditional method of reading each one of the 20 million
rows in the base table. For example, assume we wanted to find old blue Toyota
Corollas manufactured in 1981:

select
license_plat_nbr
from
vehicle
where
color = "blue"
and
make = "toyota"
and
year = 2015;

Oracle uses a specialized optimizer method called a bitmapped index merge to service
this query. In a bitmapped index merge, each Row-ID, or RID, list is built
independently by using the bitmaps, and a special merge routine is used in order to
compare the RID lists and find the intersecting values.

As the number if distinct values increases, the size of the bitmap increases exponentially, such
that an index with 100 values may perform thousands of times faster than a bitmap index on
1,000 distinct column values.

Also, remember that bitmap indexes are only suitable for static tables and materialized views
which are updated at nigh and rebuilt after batch row loading. If your tables experience multiple
DML's per second, BE CAREFUL when implementing bitmap indexes!

 1 - 7 distinct key values - Queries against bitmap indexes with a low cardinality are very
fast.
 8-100 distinct key values - As the number if distinct values increases, performance
decreases proportionally.
 100 - 10,000 distinct key values - Over 100 distinct values, the bitmap indexes become
huge and SQL performance drops off rapidly.
 Over 10,000 distinct key values - At this point, performance is ten times slower than an
index with only 100 distinct values.
 Oracle bitmap index maximum distinct values
Oracle Tips by Burleson
http://www.dba-oracle.com/t_bitmap_index_maximum_distinct_values_cardinality.htm
Updated March 8, 2015

Question: I know that bitmap indexes are for columns with a small number of distinct
values, but what is the rule for cardinality. Is 500 distinct values too many for a bitmap
index? Does the length of the index key play a role in the maximum number of distinct
values? How do I tell when m y bitmap index has too many values?

Answer: You are correct that the maximum cardinality for bitmap indexes is a function of the
number of distinct values and the size of the key, but far and away it is the number of distinct
values that is the largest contributing factor to the maximum number of distinct values you can
have in a bitmap index.

As the number if distinct values increases, the size of the bitmap increases exponentially, such
that an index with 100 values may perform thousands of times faster than a bitmap index on
1,000 distinct column values. The answer, as with all Oracle tuning questions is "It depends".

Also, remember that bitmap indexes are only suitable for static tables and materialized views
which are updated at nigh and rebuilt after batch row loading. If your tables are not read-only
during query time, carefully test your DML speed before implementing bitmap indexes! Tables
with dozens of updates per second can see slowdowns because of the overhead of updating the
bitmap.

So, which is the right maximum values for your bitmap index? Who knows? You will need to
run performance benchmarks on your unique database to see!

Benchmarks have shown these trends in SQL performance and the number of distinct bitmap
index values (as a percentage of total table rows), and the clustering factor for the index column.
All else being equal, cardinality is one of the most important factors in deciding to use a bitmap
index, but there are rare cases where a bitmap on a column with 10,000 key values might be
appropriate.

So, what is the maximum threshold for unique values in a bitmap index? The answer (as
with all Oracle tuning questions) is "It depends". To understand how a bitmap works,
remember that a bitmap is a two dimensional matrix with two axis. The number of rows in
the table is one axis, and the number of distinct key values is the other axis.
Conceptualize a bitmap index as a two-dimensional array

Hence, a bitmap index on a million row table with ten distinct values in the index column will
have ten million cells in the bitmap. Conversely, a bitmap on a million rows table with an index
column with 1,000 distinct values will be much larger, with a billion cells.

At this point, let's note that Oracle performs bitmap index compression, and that is why the
clustering_factor is important. If a bitmap index column has a "good" clustering factor (e.g.
close to the number of blocks in the table) then the index values are adjacent, and Oracle will be
able to compress the index far better than a bitmap on an un-clustered column.

Bitmap compression, row clustering, and column cardinality

It should be clear that it's not exclusively the number of distinct values in the index that governs
our choice of using a bitmap, it's also a function of the percentage the distinct values as a
percentage of rows in the table and the clustering of the column values (as per the
clustering_factor column in the dba_indexes view). Hence, a decision for a bitmap is a function
of these criteria:

 The ratio of rows to distinct values: A more accurate estimate of the suitability of a
bitmap index is the ratio of distinct rows to the number of total rows in a table.
 Clustering factor: The clustering of the index keys to the physical data blocks has an
influence on bitmap indexes.

In a table where the bitmap columns appear in the same physical order as the rows, related
column values will be adjacent on each data block. The clustering_factor will be close to the
value of the blocks column indba_data_files, and Oracle will be able to compress the bitmap
index.

When a bitmap index sees repeating column values, the matching rows can be omitted from the
bitmap. As a bitmap is being created or updated, Oracle looks to the previous index entry. If it
is the same, Oracle replaces the bitmap entry with a "same as prior" flag, and continues until a
new key value is detected.

At an extreme case, consider a million rows table where the column has 100,000 distinct values
and clustering_factor ~= blocks.

Because all adjacent columns values are grouped together, the bitmap axis goes from 1,000,000
rows down to 100,000, making for a highly compressed bitmap.
In the compressed example below, all "East:" rows appear adjacent in rows 1-5, all "North"
values resides on rows 6-13, all "South values" are in rows 14-15, and all "West" rows reside on
rows 16-18:

Again, in most cases, there will not be a lot of adjacent index values, so it quite rare to see
extensive compression.

Exceptions to the rule! High cardinality bitmap indexes

Oracle is not a science and for every rule we see exceptions! At first blush, the Oracle 11g
documentation can appear contradictory. In some places we see excellent rules-of-thumb for
bitmap index cardinality.

"In a data warehouse, B-tree indexes should only be used for unique columns or other
columns with very high cardinalities (that is, columns that are almost unique)."

"You typically want to use bitmap indexes on low degree of cardinality columns and B-
tree indexes on high degree of cardinality columns.

As a general rule, a cardinality of under 1% makes a good candidate for a bitmap index."

However, there are rare cases where high cardinality columns can be used in bitmap indexes, and
Oracle suggests that these conditions are acceptable for a bitmap index:

 If the number of distinct values of a column is less than 1% of the number of rows in the
table.
 If the values in a column are repeated more than 100 times, then the column is a
candidate for a bitmap index.
Now that we understand bitmap index compression, it should be clear that there are rare cases
where high cardinality columns might be candidates for bitmap indexes.

So, which are the right maximum values for your bitmap index? Who knows? You will need to
run performance benchmarks on your unique database to see!

The only way to know for sure is to perform real-world benchmark testing your real SQL
workloads. You can use the dbms_workload_capture procedure to grab a representative SQL
workload from your production database and replay the workload in a test instance using your
new bitmap index.

Bitmap index usage

Remember how bitmap indexes are generally used. Because they are low cardinality, they
have very little value by themselves, and the power comes when Oracle combines multiple
bitmaps in a bitmap merge operation:

We also have to deal with the volatility of low cardinality columns. For example, some hippie
states have adopted a five gender system, male, female, male becoming female, female becoming
male, and eunuch, changes that cost billions of dollars to implement.
 The Secrets of Oracle Bitmap Indexes
http://www.akadia.com/services/ora_bitmapped_index.html

Advantage of Bitmap Indexes

The advantages of them are that they have a highly compressed structure, making them
fast to read and their structure makes it possible for the system to combine multiple
indexes together for fast access to the underlying table.

Compressed indexes, like bitmap indexes, represent a trade-off between CPU usage and
disk space usage. A compressed structure is faster to read from disk but takes additional
CPU cycles to decompress for access - an uncompressed structure imposes a lower CPU load
but requires more bandwidth to read in a short time.

One belief concerning bitmap indexes is that they are only suitable for indexing low-
cardinality data. This is not necessarily true, and bitmap indexes can be used very
successfully for indexing columns with many thousands of different values.

Disadvantage of Bitmap Indexes

The reason for confining bitmap indexes to data warehouses is that the overhead on
maintaining them is enormous. A modification to a bitmap index requires a great deal
more work on behalf of the system than a modification to a b-tree index. In addition, the
concurrency for modifications on bitmap indexes is dreadful.

Bitmap Indexes and Deadlocks

Bitmap indexes are not appropriate for tables that have lots of single row DML operations
(inserts) and especially concurrent single row DML operations. Deadlock situations are the
result of concurrent inserts as the following example shows: Open two windows, one for
Session 1 and one for Session 2

Session 1 Session 2
create table bitmap_index_demo (
value varchar2(20)
);

insert into bitmap_index_demo

select decode(mod(rownum,2),0,'M','F')
from all_objects;

create bitmap index

bitmap_index_demo_idx
on bitmap_index_demo(value);
insert into bitmap_index_demo
values ('M');
1 row created.
 insert into bitmap_index_demo
values ('F');
1 row created.
insert into bitmap_index_demo
values ('F');
...... waiting ......
ERROR at line 1: insert into bitmap_index_demo
ORA-00060: deadlock detected while waiting values ('M');
for resource ...... waiting ......