Bitmap Join Indexes

8/3/2019 Bitmap Join Indexes

http://slidepdf.com/reader/full/bitmap-join-indexes 1/10

Oracle 9i New features

Oracle 9i New Features

New Index Methods

Prepared by Author

Author: Srinivas Kasam

Creation Date: 16 June 2003

Last Updated: 24 June 2003

Version: 1.1

Status: Draft

Copyright (C) 2003 Oracle CorporationAll Rights Reserved

Change Record

Date Printed On: 11/22/2011




Date Author Version Change Details

16 June 03 Srinivas Kasam 1.0 Original Version

24 June 03 Srinivas Kasam 1.1 Added diff between Join Index & Materialized Views





Table Of Contents

TABLE OF CONTENTS ......................................................................................... 3

OVERVIEW ............................................................................................................. 4

BITMAP JOIN INDEXES .......................................................................................4

CREATING BITMAP JOIN INDEXES .................................................................... 5

BITMAP JOIN INDEXES IN ACTION .................................................................... 5

RESTRICTIONS ON USING BITMAP JOIN INDEXES ......................................... 9

USAGE OF BITMAP JOIN INDEXES IN E-MARKETING APPLICATIONS ......... 9

POINTERS AND USEFUL INFORMATION........................................................... 9

FEEDBACK AND SUGGESTIONS ......................................................................10





Overview

Oracle began making significant advances in indexing with the introduction of the function-based indOracle8i. Oracle9i helps us improve performance even more with the addition of two new indexes.

• Bitmap Join Indexes• Skip Scan Indexes

This document discusses the Bitmap Join Indexes.

The bitmap join index allows us to build a single index across the joined columns of two or more taThe rowids from one table are stored along with the indexed column(s) of the other table.

Bitmap Join Indexes

To understand where a bitmap join index is helpful, it is important to have an understanding of a bitmindex. Bitmap indexes are most helpful in data warehousing because they are generally fast when weonly selecting data.

A bitmap index is smaller than a b-tree index because it stores only the rowid and a series of bits. In bitmap index, if a bit is set, it means that a row in the corresponding rowid (also stored) contains a kevalue. For example, consider the Emp table with two new columns, GENDER and MARRIED:

Empno Gender (M/F) Married (Y/N)

1001 F Y1002 F Y1003 F N

1004 M N1005 M Y

The actual storage depends on the algorithm used internally, but the bitmaps stored may be:

Empno= Gender=F Married=Y

1001 1 11002 1 11003 1 01004 0 01005 0 1

We can see from the above example that it would be easy to find all of the females by returning the r

where the gender bit is set to a '1.' We can similarly find all of those married or even quickly find acombination of gender and marital status.

B-tree indexes are usually used when columns are unique or near unique; bitmap indexes should be uor at least considered, in all other cases. While we would not generally use a b-tree index when retri40 percent of the rows of a table, a bitmap index is often still faster than doing a full table scan. This seemingly in violation of the 80/20 rule, which is to generally use an index when retrieving 20 percenless of the rows and do a full table scan when retrieving more. Bitmap indexes are smaller and work differently from the 80/20 rule. You can effectively use bitmap indexes even when retrieving large





percentages (20 to 80 percent) of a table. Bitmaps can also be used to retrieve conditions based on nu(since nulls are also indexed) and for "not equal" conditions

Creating Bitmap Join Indexes

This new table access method requires that we create an index that performs the join at index creation

time and that creates a bitmap index of the keys used in the join. But unlike most relational databaseindexes, the indexed columns don't reside in the table. Oracle has revolutionized index creation byallowing a WHERE clause to be included in the index creation syntax. This feature revolutionizes threlational tables are accessed via SQL.

In addition to a bitmap index on a single table, you can create a bitmap join index, which is a bitmapindex for the join of two or more tables. A bitmap join index is a space-saving way to reduce the voluof data that must be joined, by performing restrictions in advance. For each value in a column of a ta bitmap join index stores the rowids of corresponding rows in another table. In a data warehousingenvironment, the join condition is an equi-inner join between the primary key column(s) of the dimentables and the foreign key column(s) in the fact table.

Syntax for creating bitmap join index is as follows:CREATE BITMAP INDEX <Index Name> ON <Junction Table> ( <Key1>, <Key2>)FROM <Table1>, <Table2> …..WHERE <Join Condition to join the tables>

Note that the bitmap join index specifies the join criteria for all the tables and creates a bitmap indexthe junction table with the keys of other tables.

Bitmap Join Indexes in action

In a typical business relational database, if we are often joining the same two or three tables over andover. The bitmap join index can give us substantial gains when properly applied to many of thesecircumstances. In a bitmap join index, the rowids from one table are stored along with the indexed cofrom the joined table. The bitmap join index in Oracle9i is a lot like building a single index that spantables.

We must build a primary key or unique constraint on one of the tables. When we are looking for information from just the columns in the index or a count, then we will be able to access the single joindex. Let's look at a very simple example. Then we'll look at how to apply it on multiple columns antables.

Using Joined Columns

Consider our familiar friends ( tables provided by Oracle sample schema ) viz., EMP, DEPT.

We then must have a unique constraint (or have a primary key) to DEPT table to use this type of indePlease note that the table DEPT by default has this constraint.





We can then create the bitmap index on the EMP table that includes the columns of both tables.

CREATE BITMAP INDEX EmpDept_IDX ON Emp(Detp.DeptNo)FROM Emp, DeptWHERE Emp.Deptno = Dept.DeptNo;

We are now storing the rowid to the DEPT table in the bitmap index that maps to the DEPTNO columthe EMP table. To test this, let’s do simple count(*) of the intersection rows between the two tables,forcing the use of the bitmap index with an INDEX hint.

SELECT /*+ INDEX(Emp EmpDept_IDX) */ COUNT(*)FROM Emp, DeptWHERE Emp.DeptNo = Dept.DeptNo;

COUNT(*)-------------

14Elapsed: 00:00:00.67

Execution Plan---------------------------

0 SELECT STATEMENTOptimizer=CHOOSE

1 0 SORT (AGGREGATE)2 1 BITMAP CONVERSION (COUNT)3 2 BITMAP INDEX (FULL SCAN)

OF 'EMPDEPT_IDX'

You can see from the autotrace output that the bitmap index was used. While this example shows howcount an index (instead of accessing the table) and utilizes some benefits of the bitmap join index, thnext three examples show targeted areas where you may find the best use of the bitmap join index.

Using Columns Other Than the Join

Consider this example, where EMP and DEPT tables are once again joined on the deptno column. Hewe want to index the location column instead of the join column. This will allow us to select the loca(loc) column from the DEPT table by directly accessing the index and the EMP table only. Remembethe join condition must be on the primary key or unique column.

CREATE BITMAP INDEX EMP_DEPT_LOC ON Emp (Dept.LOC)





FROM Emp, DeptWHERE Emp.Deptno = Dept.DeptNo;

The following query would now be able to use the bitmap join index appropriately without accessingDEPT table.

SELECT Emp.EmpNo, Emp.Ename FROM Emp, DeptWHERE Emp.DeptNo = Dept.DeptNoAND Dept.Loc = 10;

Using Multiple Columns

Consider an example where we want an index on multiple columns. The syntax is still the same, but we include multiple columns (LOC, DNAME) in the index.

CREATE BITMAP INDEX Emp_Dept_LOC_DnameON Emp (Dept.Loc, Dept.Dname)FROM Emp, DeptWHERE Emp.DeptNo = Dept.DeptNo;

The following query would be able to use the bitmap join index appropriately without accessing theDEPT table.

SELECT Emp.EmpNo, Emp.Ename FROM Emp, Dept

WHERE Emp.DeptNo = Dept.DeptNoAND Dept.Loc =10AND Dept.Dname = 'CHICAGO';

Using Multiple Tables

The following example shows how to apply the bitmap join index to multiple tables. The syntax is stsame, but it has now been expanded to include multiple columns in the index and multiple tables bein

joined for the index. This example assumes that a unique constraint exists on SALES.EMPNO colum

CREATE BITMAP INDEX Emp_Dept_Loc_MS ON Emp (Dept.Loc, Sales.Marital_Status)FROM Emp, Dept, SalesWHERE Emp.DeptNo = Dept.DeptNoAND Emp.EmpNo = Sales.EmpNo;





The following query would now be able to use the bitmap join index appropriately without accessingDEPT or SALES tables.

SELECT Emp.EmpNo, Emp.Ename FROM Emp, Dept, SalesWHERE Emp.DeptNo = Dept.DeptNo;

AND Emp.EmpNo = Sales.EmpNoAND Dept.Loc =10 AND Sales.Marital_Status = 'M';

Note that this bitmap join index specified the join criteria for the three tables and created a bitmap inon the junction table (EMP ) with the LOC and MARITAL_STATUS keys.

Join query in 9i versus prior to 9i

Prior to Oracle9i, this SQL query would be serviced by an expensive NESTED LOOP JOIN or HASH JOIN of all three tables. With a bitmap join index, the index has pre-joined the tables, and thquery can quickly retrieve a row ID list of matching table rows in all three tables.

Bitmap join indexes versus Materialized views

A bitmap join index is a space-saving way to reduce the volume of data that must be joined, by performing restrictions in advance. For each value in a column of a table, a bitmap join index stores trowids of corresponding rows in another table. In a data warehousing environment, the join conditionan equi-inner join between the primary key column(s) of the dimension tables and the foreign keycolumn(s) in the fact table.

Bitmap join indexes are much more efficient in storage than materialized join views, an alternative fomaterializing joins in advance. This is because the materialized join views do not compress the rowidthe fact tables.

Benefits of Bitmap Join Indexes

Along with dynamic memory allocation of the SGA, the indexing makes the performance aspects of Oracle9i compelling. Bitmap indexes are generally fast for queries but slow for updates, inserts, anddeletes. Bitmap join indexes can greatly improve performance with Oracle9i when properly used; maan upgrade to Oracle9i definitely worth the return.

Oracle9i has introduced extremely sophisticated execution plan features that can dramatically improvquery performance, but these features cannot be used automatically. The Oracle9i professional's chalis to understand these new indexing features, analyze the trade-offs of additional indexing, and judgewhen the new features can be used to speed queries.





Restrictions on using bitmap join indexes

Oracle Benchmarks claim that bitmap join indexes can run a query more than eight times faster thantraditional indexing methods. However, this speed improvement is dependent upon many factors, and bitmap join is not a universal remedy. Some restrictions on using the bitmap join index include:

• The indexed columns must be of low cardinality—usually with less than 300 distinct values.

• The query must not have any references in the WHERE clause to data columns that are notcontained in the index.

• The overhead when updating bitmap join indexes is substantial. For practical use, bitmap joinindexes are dropped and rebuilt each evening about the daily batch load jobs. This means that bitmap join indexes are useful only for Oracle data warehouses that remain read-only during processing day.

Usage of bitmap join indexes in E-Marketing applications

Profile and its dependent applications are the best target areas of E-Marketing where we can apply bitmap join indexes. Consider the following tables

UCM_User UCM_ServiceUCM_Service_TypeUCM_Physical_AddressUCM_Country

Assume that we need to pull a report of all OTN community members belonging to the country Indiacan be achieved by joining 4-5 tables from the above list. The performance can be improved a lot if

create bitmap join index on appropriate columns. However as we know that the above tables of profisystem are transaction intensive and hence these tables directly are not the right candidates for creati bitmap join indexes because of the high overhead associated with updating bitmap indexes.

But consider the scenario in DWPRD database which is used by dashboard, GCD, Leads etc.,In most of the schemas of here, tables are built on top of the above mentioned PROFILE tables.We build/populate summary tables on regular basis, the data is gathered from the above source table profile system and the summary tables are populated. Once this is done the summary tables are NOTtransactional throughout the day. So, the collection of summary tables built on top of PROFILE tablethe best candidates for creating bitmap join indexes. However this requires proper planning.

Pointers and useful information.

Please go through the below document to see some of statistics on the performance of bitmap joinindexes.

Oracle Benchmark - 9i Database


http://technet.oracle.com/products/oracle9i/daily/Aug02.html

http://technet.oracle.com/products/oracle9i/daily/Aug02.html




Feedback and suggestions


Bitmap Join Indexes

Documents

Transcript of Bitmap Join Indexes