Bitmap index query is slow

Question

All,
I have Dataware house environment. I have bitmap index in all the dimension id's in fact table. Here is the query. This query took 10 min... It is not affordable time.
Any help?..
SELECT count(*)
FROM quote a, enterprise_sales_det_fact b, orders c
WHERE a.quote_dim_sid = b.quote_dim_sid
AND b.order_dim_sid = c.order_dim_sid
We have bit map index on quote_dim_sid & order_dim_sid .
Here is the analyze statement i used.
exec dbms_stats.gather_table_stats(ownname => 'QUOTEPRD', tabname => 'ORDERS',estimate_percent => 10, method_opt => 'FOR ALL COLUMNS SIZE 1',cascade => true);
Step # Step Name
12 SELECT STATEMENT
11 SORT [AGGREGATE]
10 NESTED LOOPS
8 NESTED LOOPS
6 . VIEW
5 HASH JOIN
2 BITMAP CONVERSION [TO ROWIDS]
1 QUOTEPRD.ENT_FACT_ORDER_BIDX BITMAP INDEX [FULL SCAN]
4 BITMAP CONVERSION [TO ROWIDS]
3 QUOTEPRD.ENT_FACT_QUOTE_BIDX BITMAP INDEX [FULL SCAN]
7 QUOTEPRD.QUOTE_UIDX INDEX [UNIQUE SCAN]
9 QUOTEPRD.ORDERS_UIDX INDEX [UNIQUE SCAN]
Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves one or more ROWIDs by scanning all bits in the bitmap index ENT_FACT_ORDER_BIDX to find the rows which satisfy a condition specified in the querys WHERE clause. -- -- --
2 This plan step accepts a bitmap representation of an index from its child node, and converts it to a ROWID that can be used to access the table.
3 This plan step retrieves one or more ROWIDs by scanning all bits in the bitmap index ENT_FACT_QUOTE_BIDX to find the rows which satisfy a condition specified in the querys WHERE clause. -- -- --
4 This plan step accepts a bitmap representation of an index from its child node, and converts it to a ROWID that can be used to access the table.
5 This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. -- 27,037,540 290,442.324
6 This plan step represents the execution plan for the subquery defined by the view . 26,527 27,037,540 290,442.324
7 This plan step retrieves a single ROWID from the B*-tree index QUOTE_UIDX. -- 1 0.007
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 26,528 27,037,540 475,269.258
9 This plan step retrieves a single ROWID from the B*-tree index ORDERS_UIDX. -- 1 0.007
10 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 26,529 27,037,540 660,096.191
11 This plan step accepts a row set (its only child) and returns a single row by applying an aggregation function. -- 1 0.024
12 This plan step designates this statement as a SELECT statement. 26,529 -- --

Answer 1

All, i forgot to give one more information about table count.
enterprise_sales_det_fact table has 30 million. quote has 2 million, orders has 3 millions. FYI.
Regards
Govind