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 Corporation All Rights Reserved

Change Record

Date Printed On: 11/22/2011

Page 1

Oracle 9i New features Date 16 June 03

24 June 03

Author
Srinivas Kasam

Version
1.0 Original Version

Change Details

Srinivas Kasam

1.1

Added diff between Join Index & Materialized Views

Date Printed On: 11/22/2011

Page 2

Oracle 9i New features

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

Date Printed On: 11/22/2011

Page 3

Oracle 9i New features

Overview
Oracle began making significant advances in indexing with the introduction of the function-based index in Oracle8i. 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 tables. The 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 bitmap index. Bitmap indexes are most helpful in data warehousing because they are generally fast when we are only selecting data. A bitmap index is smaller than a b-tree index because it stores only the rowid and a series of bits. In a bitmap index, if a bit is set, it means that a row in the corresponding rowid (also stored) contains a key value. For example, consider the Emp table with two new columns, GENDER and MARRIED:
Empno 1001 1002 1003 1004 1005 Gender (M/F) F F F M M Married=Y 1 1 0 0 1 Married (Y/N) Y Y N N Y

The actual storage depends on the algorithm used internally, but the bitmaps stored may be:
Empno= Gender=F 1001 1002 1003 1004 1005 1 1 1 0 0

We can see from the above example that it would be easy to find all of the females by returning the rows where the gender bit is set to a '1.' We can similarly find all of those married or even quickly find a combination of gender and marital status. B-tree indexes are usually used when columns are unique or near unique; bitmap indexes should be used, or at least considered, in all other cases. While we would not generally use a b-tree index when retrieving 40 percent of the rows of a table, a bitmap index is often still faster than doing a full table scan. This is seemingly in violation of the 80/20 rule, which is to generally use an index when retrieving 20 percent or less 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 Date Printed On: 11/22/2011 Page 4

Oracle 9i New features percentages (20 to 80 percent) of a table. Bitmaps can also be used to retrieve conditions based on nulls (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 database indexes, the indexed columns don't reside in the table. Oracle has revolutionized index creation by allowing a WHERE clause to be included in the index creation syntax. This feature revolutionizes the way relational 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 bitmap index for the join of two or more tables. 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 the rowids of corresponding rows in another table. In a data warehousing environment, the join condition is an equi-inner join between the primary key column(s) of the dimension tables 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 index on the 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 and over. The bitmap join index can give us substantial gains when properly applied to many of these circumstances. In a bitmap join index, the rowids from one table are stored along with the indexed column from the joined table. The bitmap join index in Oracle9i is a lot like building a single index that spans two tables. 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 join index. Let's look at a very simple example. Then we'll look at how to apply it on multiple columns and tables.

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 index. Please note that the table DEPT by default has this constraint. Date Printed On: 11/22/2011 Page 5

Oracle 9i New features 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, Dept WHERE Emp.Deptno = Dept.DeptNo; We are now storing the rowid to the DEPT table in the bitmap index that maps to the DEPTNO column in the EMP table. To test this, lets 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, Dept WHERE Emp.DeptNo = Dept.DeptNo;
COUNT(*) ------------14 Elapsed: 00:00:00.67 Execution Plan --------------------------0 SELECT STATEMENT Optimizer=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 how to count an index (instead of accessing the table) and utilizes some benefits of the bitmap join index, the next 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. Here, we want to index the location column instead of the join column. This will allow us to select the location (loc) column from the DEPT table by directly accessing the index and the EMP table only. Remember, the join condition must be on the primary key or unique column. CREATE BITMAP INDEX EMP_DEPT_LOC ON Emp (Dept.LOC) Date Printed On: 11/22/2011 Page 6

Oracle 9i New features FROM Emp, Dept WHERE Emp.Deptno = Dept.DeptNo; The following query would now be able to use the bitmap join index appropriately without accessing the DEPT table. SELECT Emp.EmpNo, Emp.Ename FROM Emp, Dept WHERE Emp.DeptNo = Dept.DeptNo AND Dept.Loc = 10; Using Multiple Columns Consider an example where we want an index on multiple columns. The syntax is still the same, but now we include multiple columns (LOC, DNAME) in the index. CREATE BITMAP INDEX Emp_Dept_LOC_Dname ON Emp (Dept.Loc, Dept.Dname) FROM Emp, Dept WHERE Emp.DeptNo = Dept.DeptNo; The following query would be able to use the bitmap join index appropriately without accessing the DEPT table. SELECT Emp.EmpNo, Emp.Ename FROM Emp, Dept WHERE Emp.DeptNo = Dept.DeptNo AND Dept.Loc =10 AND Dept.Dname = 'CHICAGO';

Using Multiple Tables The following example shows how to apply the bitmap join index to multiple tables. The syntax is still the same, but it has now been expanded to include multiple columns in the index and multiple tables being joined for the index. This example assumes that a unique constraint exists on SALES.EMPNO column. CREATE BITMAP INDEX Emp_Dept_Loc_MS ON Emp (Dept.Loc, Sales.Marital_Status) FROM Emp, Dept, Sales WHERE Emp.DeptNo = Dept.DeptNo AND Emp.EmpNo = Sales.EmpNo;

Date Printed On: 11/22/2011

Page 7

Oracle 9i New features The following query would now be able to use the bitmap join index appropriately without accessing the DEPT or SALES tables. SELECT Emp.EmpNo, Emp.Ename FROM Emp, Dept, Sales WHERE Emp.DeptNo = Dept.DeptNo; AND Emp.EmpNo = Sales.EmpNo AND 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 index on 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 the query 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 the rowids of corresponding rows in another table. In a data warehousing environment, the join condition is an equi-inner join between the primary key column(s) of the dimension tables and the foreign key column(s) in the fact table. Bitmap join indexes are much more efficient in storage than materialized join views, an alternative for materializing joins in advance. This is because the materialized join views do not compress the rowids of the 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, and deletes. Bitmap join indexes can greatly improve performance with Oracle9i when properly used; making an upgrade to Oracle9i definitely worth the return. Oracle9i has introduced extremely sophisticated execution plan features that can dramatically improve query performance, but these features cannot be used automatically. The Oracle9i professional's challenge is to understand these new indexing features, analyze the trade-offs of additional indexing, and judge when the new features can be used to speed queries.

Date Printed On: 11/22/2011

Page 8

Oracle 9i New features

Restrictions on using bitmap join indexes

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

The indexed columns must be of low cardinalityusually with less than 300 distinct values. The query must not have any references in the WHERE clause to data columns that are not contained in the index. The overhead when updating bitmap join indexes is substantial. For practical use, bitmap join indexes 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 the 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_Service UCM_Service_Type UCM_Physical_Address UCM_Country Assume that we need to pull a report of all OTN community members belonging to the country India, this can be achieved by joining 4-5 tables from the above list. The performance can be improved a lot if we create bitmap join index on appropriate columns. However as we know that the above tables of profile system are transaction intensive and hence these tables directly are not the right candidates for creating 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 tables of profile system and the summary tables are populated. Once this is done the summary tables are NOT transactional throughout the day. So, the collection of summary tables built on top of PROFILE tables are the 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 join indexes. Oracle Benchmark - 9i Database

Date Printed On: 11/22/2011

Page 9

Oracle 9i New features

Feedback and suggestions

Date Printed On: 11/22/2011

Page 10