Local Bitmap Index Confusions

Question

Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
For instance, in future, some rows get inserted in an existing partition where the local bitmap index is present, so then I should once again rebuild the index on that partition, because in case of insert Oracle would have disabled it?
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Thanks and best regards

Answer 1

The more I know, the more I know that how little I know. Thanks Jonathan for a very insightful answer. Please clarify some points and thanks for your valuable feedback.
Jonathan Lewis wrote:
Fahd Mirza wrote:
Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
That may depend on the software you use to load the data, it's not a necessity from the perspective of the database.I am using Oracle Warehouse Builder to load the data into the database.
>
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
Depends on the tools, and whether there is data in the table already - but Oracle will optimise index maintenance for bulk inserts in a way which means that it isn't necessary to worry about dropping/recreating if the index already exists and the table is empty.There is no data in the partitions prior to loading.
You may find that with one index it's more efficient to create the index with a lot of free space (51%, say) and leave it at that while another index works better if you mark unusable and rebuild.
Would you please elaborate on this point?
>
>>
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Your question raise more questions:
a) Does this mean you are only going to have a maximum of two bitmap indexes on this fact table with 60 million rows ? That doesn't sound like it's enough indexes.No, I will create local bitmap indexes on other columns too, which are likely to be used in the adhoc queries.
b) Are you hoping that the vactivity bitmap index will protect you against foreign key locking ? It won't. This (in part) is why people tend to set FK's to disable, novalidate, rely in data warehouses, they want bitmap indexes not btree indexesActually I haven't created the FK constraint.
d) Going back to the bitmap index on the date - is this column storing values that are date-only, or is it storing "date with time". If it's date-only then you've only got one date per partition and the index is a waste of space and processing overhead.The datatype of the column vdate is number. Actually it is refering to the pk of time dimension, in which we have preloaded the dates for the next ten years. Would the index be a total waste on this column?
>
>
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Here is the table. I have omitted many partitions for the sake of brevity:
CREATE TABLE CDR
  CLNG_NMBR          NUMBER,
   CL_RFRNC_NMBR      VARCHAR2(100 BYTE),
  DT_KY              NUMBER,
  TM_KY              NUMBER,
  HRLY_KY            NUMBER,
ACTVTY_KY          NUMBER,
  INS_DT             DATE,
  SRVC_ID            VARCHAR2(100 BYTE),
  MSC_ADRS           VARCHAR2(100 BYTE),
  TRF_ID             NUMBER,
  CL_TYP             NUMBER,
  LCTN_INFRMTN       VARCHAR2(100 BYTE),
  LCTN_KY            NUMBER,
  SRC_CLNG_NMBR      VARCHAR2(50 BYTE),
  ACTVTY_CL_TP       VARCHAR2(100 CHAR)
PARTITION BY RANGE(DT_KY)
PARTITION DAY_20DEC2009 VALUES LESS THAN (4153),
PARTITION DAY_21DEC2009 VALUES LESS THAN (4154),
PARTITION DAY_22DEC2009 VALUES LESS THAN (4155),
PARTITION DAY_23DEC2009 VALUES LESS THAN (4156),
PARTITION DAY_24DEC2009 VALUES LESS THAN (4157),
PARTITION DAY_25DEC2009 VALUES LESS THAN (4158),
PARTITION DAY_26DEC2009 VALUES LESS THAN (4159),
PARTITION DAY_27DEC2009 VALUES LESS THAN (4160),
PARTITION DAY_28DEC2009 VALUES LESS THAN (4161),
PARTITION DAY_31DEC2011 VALUES LESS THAN (4894),
PARTITION DAY_END_PART VALUES LESS THAN (MAXVALUE)
TABLESPACE cdr
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          80K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;Many many thanks and best regards
Fahd
Edited by: Fahd Mirza on Jun 3, 2010 2:00 PM
Edited by: Fahd Mirza on Jun 3, 2010 2:03 PM