Disable bitmap indexes

Hi!
I was wondering if someone has a stash of good script for disable bitmap indexs and then enabling them again, a script for just for that specific table or the user indexes doesnt matter.
Cheers

So does the script in the previous post work or not ? For what you want, probably yes. But why don't you try it out?
But realize,
SQL> create table t(x number);
Tabel er oprettet.
SQL>
SQL> create bitmap index bix on t(x);
Indeks er oprettet.
SQL>
SQL> alter index bix unusable;
Indeks er µndret.
SQL>
SQL> insert into t (x) values (1);
1 rµkke er oprettet.
SQL>
SQL> commit;
Bekrµftelse er udf°rt.
SQL>
SQL> select x from t;
         X
         1
SQL>
SQL> select /*+ index(t bix))*/ * from t;
select /*+ index(t bix))*/ * from t
FEJL i linie 1:
ORA-01502: index 'BRUGER.BIX' or partition of such index is in unusable state
SQL>Regards
Peter

Similar Messages

  • Unable to create a bitmap index

    Hi,
    I want to create a bitmap index on one of the colums on a table. I fired following query and it failed.
    SQL> CREATE BITMAP INDEX TRANS_N_BITMAPIDX_VEH_PLATFORM ON TRANSACTION_NEW(VEH_PLATFORM) LOCAL;
    Error starting at line 2 in command:
    CREATE BITMAP INDEX TRANS_N_BITMAPIDX_VEH_PLATFORM ON TRANSACTION_NEW(VEH_PLATFORM) LOCAL
    Error at Command Line:2 Column:70
    Error report:
    SQL Error: ORA-01408: such column list already indexed
    01408. 00000 -  "such column list already indexed"
    *Cause:   
    *Action:I found there is a combined NORMAL index with VEH_PLATFORM column called ‘IDX$$_30AA00021’. It has following columns
    •     VEH_PLATFORM
    •     VEH_MODEL
    •     MODL_YR_NBR
    •     VEH_MAKE
    •     TXN_PROCS_DT
    But I was able to create bitmap index on VEH_MODEL,MODL_YR_NBR and VEH_MAKE columns without any error.
    Why does it error out for VEH_PLATFORM column?
    Regards,
    Sam

    Hi,
    I am sure that BITMAP index is only created for
    VEH_MAKE
    VEH_MODEL
    MODL_YR_NBR
    BUILD_REGION
    VEH_LINE_SERIES
    TRANS_CTG_ID
    and not for VEH_PLATFORM.
    SQL> SELECT * FROM USER_INDEXES WHERE INDEX_TYPE='BITMAP' AND TABLE_NAME='TRANSACTION_NEW';
    INDEX_NAME                     INDEX_TYPE                  TABLE_OWNER                    TABLE_NAME                     TABLE_TYPE  UNIQUENESS COMPRESSION PREFIX_LENGTH          TABLESPACE_NAME                INI_TRANS              MAX_TRANS              INITIAL_EXTENT         NEXT_EXTENT            MIN_EXTENTS            MAX_EXTENTS            PCT_INCREASE           PCT_THRESHOLD          INCLUDE_COLUMN         FREELISTS              FREELIST_GROUPS        PCT_FREE               LOGGING BLEVEL                 LEAF_BLOCKS            DISTINCT_KEYS          AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR      STATUS   NUM_ROWS               SAMPLE_SIZE            LAST_ANALYZED             DEGREE                                   INSTANCES                                PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL FLASH_CACHE CELL_FLASH_CACHE USER_STATS DURATION        PCT_DIRECT_ACCESS      ITYP_OWNER                     ITYP_NAME                      PARAMETERS                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED VISIBILITY DOMIDX_MANAGEMENT SEGMENT_CREATED
    TRANS_N_BITMAPIDX_MAKE         BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      6102                   20                     305                     611                     12226                  N/A      12226                  2208                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    TRANS_N_BITMAPIDX_MODEL        BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      11284                  158                    71                      144                     22813                  N/A      22813                  2321                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    TRANS_N_BITMAPIDX_BUILD_REGION BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      2911                   5                      582                     1161                    5808                   N/A      5808                   5808                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    TRANS_N_BITMAPIDX_MODL_YR_NBR  BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      2911                   5                      582                     1161                    5808                   N/A      5808                   5808                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    TRANS_N_BITMAPIDX_TRANS_CTG_ID BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      7547                   43                     175                     359                     15457                  N/A      15457                  2345                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    TRANS_N_BITMAPIDX_VEH_LINE_S   BITMAP                      VISUAL                         TRANSACTION_NEW                TABLE       NONUNIQUE  DISABLED                                                                                                                                                                                                                                                                                                                                                      2                      10581                  253                    41                      84                      21477                  N/A      21477                  2247                   11-MAY-11                 1                                        1                                        YES         N         N         N         DEFAULT     DEFAULT     DEFAULT          NO                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       YES                                                       NO         NO                      NO      VISIBLE                      N/A            
    6 rows selectedRegards,
    Sam

  • Local Bitmap Index Confusions

    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

    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

  • How to disable a index

    hi all,
    how to disable an index created by
    create index cc on sample(serialno);what are b-tree and bitmap indexes in detail.
    what is meant by HASH function.
    what is meant by reverse index.
    thanks and regards,
    sri ram.

    Some Links:
    Look here under unusable and rebuild (take care of restrictions, also described there):
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_1008.htm#i2136020
    You can find a bit of informtion about b-tree-indexes here:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref961
    Reverse key Indexes:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref998
    Bitmap-Indexes:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref1008

  • Diff b/w btree and bitmap index ?

    What is the difference between btree and bitmap index ?
    which one to used and when.
    how they are differ from each other.

    you'd love to see
    http://www.oracle.com/technology/pub/articles/sharma_indexes.html

  • Multi-column BITMAP index vs. multiple BITMAP indices?

    Given the table (simple, made-up example):
    CREATE TABLE applicant_diversity_info (
    applicant_diversity_id NUMBER(12), PRIMARY KEY(applicant_diversity_id),
    apply_date DATE,
    ssn_salted_md5 RAW(16),
    gender CHAR(1), CHECK ( (gender IS NULL OR gender IN ('M','F')) ),
    racial_continent VARCHAR2(30), CHECK ( (racial_continent IS NULL
    OR racial_continent IN ('Europe','Africa','America','Asia_Pacific')) ),
    ethnic_supergroup VARCHAR2(30), CHECK ( (ethnic_supergroup IS NULL OR ethnic_supergroup IN ('Latin American','Other')) ),
    hire_salary NUMBER(11,2),
    hire_month DATE,
    termination_salary NUMBER(11,2),
    termination_month DATE,
    termination_cause VARCHAR2(30), CHECK ( (termination_cause IS NULL
    OR termination_cause IN ('Resigned','Leave of Absence','Laid Off','Performance','Cause')) )
    Oracle (syntactically) allows me to create either one BITMAP index over all four small-cardinality columns
    CREATE BITMAP INDEX applicant_diversity_diversity_idx ON applicant_diversity_info (
    gender, racial_continent, ethnic_supergroup, termination_reason );
    or four independent indexes
    CREATE BITMAP INDEX applicant_diversity_gender_idx ON applicant_diversity_info ( gender );
    CREATE BITMAP INDEX applicant_diversity_race_idx ON applicant_diversity_info ( raceial_continent );
    etc.
    What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
    And, if I define one multi-column BITMAP index, does the order of columns matter?

    >
    What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
    And, if I define one multi-column BITMAP index, does the order of columns matter?
    >
    You may want to read this two-part blog, that answers that exact question, by recognized expert Richard Foote
    http://richardfoote.wordpress.com/2010/05/06/concatenated-bitmap-indexes-part-i-two-of-us/
    http://richardfoote.wordpress.com/2010/05/12/concatenated-bitmap-indexes-part-ii-everybodys-got-to-learn-sometime/
    As with many things Oracle the answer is 'it depends'.
    In short the same considerations apply for a concatenated index whether it is bitmap or b-tree: 1) will the leading column usually be in the predicate and 2) will most or all of the index columns be specified in the queries.
    Here are some quotes from part 1
    >
    Many of the same issues and factors in deciding to create a single, multi-column index vs. several, single column indexes apply to Bitmap indexes as they do with B-Tree indexes, although there are a number of key differences to consider as well.
    Another thing to note regarding a concatenated Bitmap index is that the potential number of index entries is a product of distinct combinations of data of the indexed columns.
    A concatenated Bitmap index can potentially use less or more space than corresponding single column indexes, it depends on the number of index entries that are derived and the distribution of the data with the table.
    >
    Here is the lead quote from part 2
    >
    The issues regarding whether to go for single column indexes vs. concatenated indexes are similar for Bitmap indexes as they are for B-Tree indexes.
    It’s generally more efficient to access a concatenated index as it’s only the one index with less processing and less throwaway rowids/rows to contend with. However it’s more flexible to have single column indexes, especially for Bitmap indexes that are kinda designed to be used concurrently, as concatenated indexes are heavily dependant on the leading column being known in queries.

  • Bitmap index Vs B-Tree index

    Hi All,
    Could some one please let me know how Bitmap indexes are useful compared to B-Tree indexes on low-cardinality columns ?.
    Thanks,
    -Kumar.

    >>
    As Re: why oracle db 9i optimizer can't choose to use the bitmap index? there are a number of issues with bitmap indexes. Your best bet is to read these three articles by Jonathan Lewis.
    It does pay us to understand how the optimizer works with bitmap indexes. I posted some Re: Cost-based optimizer behavior to show how indexes on even very low valued columns can be useful in certain circumstances.
    Cheers, APC
    Blog : http://radiofreetooting.blogspot.com/

  • Partitioned IOT of Object Type - mapping table not allowed for bitmap index

    Hi,
    looks like a feature available for standard Partitioned IOTs is not supported for object based tables, namely the MAPPING TABLE construct to support secondary local bitmap indexes.
    Can you confirm behaviour is as expected/documented?
    If so, is a fix/enhancement to support mapping table for object-based Partitioned IOTs in the pipeline?
    Results for partition-wise load using pipelined table function are very good, look-ups across tens of millions of rows are excellent.
    Environment = Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    OS = Oracle Enterprise Linux Server release 5.2 (Carthage) 2.6.18 92.el5 (32-bit)
    Here's the potted test-case...
    1) First the non object based Partitioned IOT - data is range-partitioned across the alphabet
    CREATE TABLE IOT_Table (
    textData VARCHAR2(10),
    numberData NUMBER(10,0),
    CONSTRAINT IOT_Table_PK PRIMARY KEY(textData))
    ORGANIZATION INDEX MAPPING TABLE PCTFREE 0 TABLESPACE Firewire
    PARTITION BY RANGE (textData)
    (PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
    NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
    SQL> table IOT_TABLE created.
    2) Create the local secondary bitmap index utilising the underlying mapping table
    CREATE BITMAP INDEX IOT_Table_BMI1 ON IOT_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    SQL> bitmap index IOT_TABLE_BMI1 created.
    3) Quick test to confirm all ok
    SQL> INSERT INTO IOT_Table VALUES ('ABC123',100);
    SQL> 1 rows inserted.
    SQL> SELECT * FROM IOT_Table;
    TEXTDATA NUMBERDATA
    ABC123     100
    4) Now create a minimal object type to use as the template for object table
    CREATE TYPE IOT_type AS OBJECT
    textData VARCHAR2(10 CHAR),
    numberData NUMBER(10,0)
    ) FINAL
    SQL> TYPE IOT_type compiled
    5) Attempt to create an object-based range partitioned IOT, including MAPPING TABLE clause as per step (1)
    CREATE TABLE IOTObj_Table OF IOT_type (textData PRIMARY KEY)
    OBJECT IDENTIFIER IS PRIMARY KEY ORGANIZATION INDEX
    MAPPING TABLE -- we'd like to use this feature to enable use of Bitmap Indexes...
    PCTFREE 0 TABLESPACE Firewire
    PARTITION BY RANGE (textData)
    (PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
    NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
    This errors out with the following...
    SQL Error: ORA-25182: feature not currently available for index-organized tables
    25182. 00000 - "feature not currently available for index-organized tables"
    *Cause:    An attempt was made to use one or more of the following feature(s) not
    currently supported for index-organized tables:
    CREATE TABLE with LOB/BFILE/VARRAY columns,
    partitioning/PARALLEL/CREATE TABLE AS SELECT options,
    ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
    *Action:   Do not use the disallowed feature(s) in this release.
    6) Re-running the create table statement in step 5 without the MAPPING TABLE clause works fine. Not surprisingly an attempt to create a secondary local bitmap index on this table fails as there's no mapping table, like so...
    CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    CREATE TABLE with LOB/BFILE/VARRAY columns,
    partitioning/PARALLEL/CREATE TABLE AS SELECT options,
    ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
    *Action:   Do not use the disallowed feature(s) in this release.
    CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL
    Error at Command Line:99 Column:13
    Error report:
    SQL Error: ORA-00903: invalid table name
    00903. 00000 - "invalid table name"
    7) Creating a secondary local b-tree index is fine, like so...
    SQL> CREATE INDEX IOTObj_Table_I1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    index IOTOBJ_TABLE_I1 created.
    8) A quick test to ensure object table ok...
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
    SQL> 1 rows inserted.
    SQL> SELECT * FROM IOTObj_Table;
    TEXTDATA NUMBERDATA
    DEF456     500

    Thanks Dan,
    the intention is to range partition based on the initial character, so A* -> Text_Part_A, B* -> Text_Part_B, and so on.
    Here's an example, using an empty IOTObj_Table as created previously.
    1) Set up & confirm some test data (two 'D's, one 'N', and two 'Z's)
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DDD111',510));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('N3000',515));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('ZZ1212',520));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
    SQL> COMMIT;
    SQL> SELECT * FROM IOTObj_Table;
    TEXTDATA NUMBERDATA
    DDD111     510
    DEF456     500
    N3000     515
    Z111X     530
    ZZ1212     520
    2) Just to prove our IOT is enforcing the Primary Key based on the TextData attribute, try to insert a duplicate
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
    Error starting at line 141 in command:
    INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530))
    Error report:
    SQL Error: ORA-00001: unique constraint (OCDataSystems.SYS_IOT_TOP_84235) violated
    00001. 00000 - "unique constraint (%s.%s) violated"
    *Cause:    An UPDATE or INSERT statement attempted to insert a duplicate key.
    For Trusted Oracle configured in DBMS MAC mode, you may see
    this message if a duplicate entry exists at a different level.
    *Action:   Either remove the unique restriction or do not insert the key.
    3) Now confirm that our data has been slotted into the range-based partition we expect using the PARTITION clause of SELECT...
    - The two 'D's...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_D);
    TEXTDATA NUMBERDATA
    DDD111     510
    DEF456     500
    - The single 'N'...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_N);
    TEXTDATA NUMBERDATA
    N3000     515
    - The two 'Z's...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_Z);
    TEXTDATA NUMBERDATA
    Z111X     530
    ZZ1212     520
    4) And to wrap up confirm an empty partition
    SELECT * FROM IOTObj_Table PARTITION (Text_Part_W);

  • Does dropping bitmap index and creation of b- index cause any dead locks

    Does dropping a bitmap index on table which is being used continuously for DML operations and creation of b- index cause any dead locks on a table
    in oracle 10g database
    ( 10.1.0.4.0 - 64bi).
    we have seen alert log file which has dead lock occurrence.. would index change/re-creation resulted dead lock or some other reason?
    Could you please give us info or help us on this.. thanks in advance..

    Bitmap indexes can be the cause of deadlocks on busy systems.
    Dropping indexes may cause some locking.
    Creating indexes may cause some locking.
    You haven't given any traces or scripts or lock information, so difficult to say which one (if any) was the cause of your deadlocks.
    It would be better to do this activity when the system is not busy.

  • Creation of bitmap index taking long time

    Hi
    I have OLTP compression enabled on the table
    CREATE BITMAP INDEX
    I1 ON
    T1(
    col 1Asc
    NOLOGGING TABLESPACE ts_index01
    taking very long time.
    The wait event is : cell single block physical read.
    Any ideas what I can do?
    Thank u

    Hi Marc
    thanks for your answer. The issue is this is a cOTS product(Siebel Analytics). The indexes are created by DAC(Informatica) automatically. I do not have away to "create index index_name parallel degree 24" clause in there.
    Thanks

  • Select count from large fact tables with bitmap indexes on them

    Hi..
    I have several large fact tables with bitmap indexes on them, and when I do a select count from these tables, I get a different result than when I do a select count, column one from the table, group by column one. I don't have any null values in these columns. Is there a patch or a one-off that can rectify this.
    Thx

    You may have corruption in the index if the queries ...
    Select /*+ full(t) */ count(*) from my_table t
    ... and ...
    Select /*+ index_combine(t my_index) */ count(*) from my_table t;
    ... give different results.
    Look at metalink for patches, and in the meantime drop-and-recreate the indexes or make them unusable then rebuild them.

  • How to create partitioned bitmap index in SQL Developer?

    I am running SQL Developer version 3.0.04.34 ; on Windows 7 (64 bit) against:
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    PL/SQL Release 11.1.0.7.0 - Production
    CORE     11.1.0.7.0     Production
    TNS for Linux: Version 11.1.0.7.0 - Production
    NLSRTL Version 11.1.0.7.0 - Production
    I am trying to create a bitmap index on a partitioned fact table which is part of a data warehouse. The index is in support of a single-column foreign-key to a dimension table. Heretofore, we had been using partitioned B-Tree indexes. According to the Data Warehousing Guide, we should consider using bitmap indexes for this purpose. Accordingly, I was trying to create such an index in our development environment. I used SQL Developer to edit the table, and attempted to create a bitmap index using the advanced screen from the index edit screen. I changed the partition type to "Local" from "None" using the radio button. When I attempt to save this change, I get an error message "A bitmap index cannot have a global partition". This happens whether or not I have assigned storage for the partitions. The index partition names are the ones used successfully for the existing B-tree indexes. I can create the SQL for the index creation by hand, but it would be simpler and easier to maintain if I could use SQL Developer.
    Any help on this issue would be appreciated.
    Vin Steele

    There is a radio button for index type in the New Index... dialog and in the index section of the edit table dialog.
    Which version of SQL Developer are you using?

  • Which index  I should create  Btree or Bitmap  index?

    I have table with columns c1,c2,c3
    I want to create index on column c1
    which index I should create Btree or Bitmap index
    the column contain 50% unique values and 50% duplicate values
    If Btree why?
    If Bitmap Why?
    I know that
    Btree is used when there more unique values (high cardinality)
    Bitmap is used when there less unique values (low cardinality)

    read this -
    Deadlocks with Bitmap Indexes
    Bitmap indexes were designed to be used solely within data warehouses, i.e. where the vast majority of the database activity is reading data,
    and there's very little (or no) data modification, except for batch processes which occasionally re-populate the warehouse.
    Each "row" in the bitmap index contains references to potentially many different rowids, in contrast to a B*-tree index which references a single rowid.
    It should be obvious, therefore, that, since the transactional mechanism is the same for all database operations, that any DML on a table which impacts the bitmap index may end up locking (or attempting to lock) many different "rows" within the index.
    This is the key concept with deadlocks in bitmap indexes, you're not being deadlocked on the underlying table, but on the index blocks. Courtesy - http://www.oratechinfo.co.uk/deadlocks.html
    hope u got it now...

  • Bad performance "CREATE BITMAP INDEX"

    Hi,
    i just create a bitmap index on a fact table with ~90.000.000 entries. The indexed table is the artice dimension with a cardinality of about 900.000 articles.
    The process is running since 24 hours with a parallel degree of 4, 3 slaves finished their work, only one is still collecting/sorting. PGA_AGGREGATE_TARGET is 4 GB.
    Oralce has allocated a temporary segment in the temp. tablespace which has a size of 760 MB up to now.
    Any idea how to speed up the process except increasing the degree for parallel query ?
    Is there a space limit for processes allocating main memory in the PGA. Or is it absolutely impossible to setup Oracle memory for workareas in a way, so that such a big bitmap can be created in main memory ? I dont want to switch back to the 8i features CREATE_BITMAP_AREA_SIZE,...
    Any hint is welcome, thx in advance...
    Paul

    Hello,
    Please check <Bug:3048661>
    Hdr: 3048661 9.2.0.3.0 RDBMS 9.2.0.3.0 RAM INDEX PRODID-5 PORTID-23
    Abstract: CREATE BITMAP INDEXES TAKES LONGER IN 9203 WHEN PGA => 2GB
    Thanks
    Ashish

  • How to maintain bitmap index on a large table in DW?

    Hi all,
    We have many tables which are constantly doing either FULL or INCREMENTAL loading.
    And we have created many BITMAP indexes and several B*Tree index (caused by PRIMARY KEY or UNIQUE key constraints) on those tables.
    So, what I want to know is, how to maintain those BITMAP (and B*Tree) indexes for different loading mode?
    like, should I drop the index before the full load and re-create it after that?
    and do nothing in INCREMENTAL loading? I am aware that it will take more time to load with indexes.
    any links, books, articles or opinions would be highly appreciated.
    Thanks

    Just to reiterate, add to what Adam said. From Oracle Doc
    http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/indexes002.htm#CIHJIDJG
    Unusable indexes
    An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is to improve bulk load performance. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later re-creating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then rebuild it.
    You can create an index in the unusable state, or you can mark an existing index or index partition unusable. In some cases the database may mark an index unusable, such as when a failure occurs while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
    An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
    Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
    The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter. When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
    •DML statements against the table proceed, but unusable indexes are not maintained.
    •DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
    •For nonpartitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
    •For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and nonpartitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
    When SKIP_UNUSABLE_INDEXES is FALSE, then:
    •If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
    •For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.
    Incremental load really matters the volume and whether for new dats you just add new partitions or subpartitions . If my incremntal go all over place and/or if I am touching few thousand rows. Yes might want to keep the indexes valid and let Oracle maintain it. IF millions added or incremental data just added to new part/subpart . Keeping indexes unsable for those partitions/subpartitions and the rebuilding it later may yield better results.

Maybe you are looking for

  • Macbook Pro doesn't power up. How to make sure that's a logic board or IO board issue?

    Hi there, I've got Macbook Pro of this model http://everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.16- 15-specs.html It's quite old. but as his owner told me it was working properly. Just in one day it went down. If he remember

  • I have installed firefox3.6 on my mac with snow leopard, but firefox will not open when I click on the icon.

    It seems that firefox installed correctly, but then it wouldn't open. I restarted my computer and still the same problem. I uninstalled it and reinstalled it and still the same problem.

  • H97 Gaming 3 : Booting issue (A2)

    Hello, here's my config : H97 Gaming 3 motherboard (bios 1.6) MSI GTX 750 Ti Twin Frozr Gaming 8 GB Ram (Kingston) 1 SSD CRUCIAL 128Go 1 Western Digital Black Edition 1 To 1 Western Digital Green Edition 4 To 1 BD-R Writer 650W corsair power supply W

  • Adding Supplier details

    Expert, We are buying an engine assembly from our Vendor, but there is no visibility for us to verify that Fixed Process Control(FPC) (quality)requirements have been met by the engine. So we need to know the details of the inner parts of the engine a

  • About setup tables in R/3 system

    Hello BI Gurus, During Production Support, if a requirement arises where new fields have to be included in a Datasource that is covered by the LO Cockpit, then in such a case do we need to necessarily delete the setup tables and reload. regards, gaur