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...

Similar Messages

  • 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

  • Bitmap index or Composite index better on a huge table

    Hi All,
    I got a question regarding the Bitmap index and Composite Index.
    I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
    This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
    I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
    Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
    My question is which one is BETTER. BTree or BITMAP Index and WHY?
    Appreciate your valuable inputs on this one.
    Regars,
    Madhu K.

    Dear,
    Hi All,
    I got a question regarding the Bitmap index and Composite Index.
    I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
    This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
    I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
    Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
    My question is which one is BETTER. BTree or BITMAP Index and WHY?
    Appreciate your valuable inputs on this one.First of all, bitmap indexes are not recommended for write intensive OLTP applications due to the locking threat they can produce in such a kind of applications.
    You told us that this table is never updated; I suppose it is not deleted also.
    Second, bitmap indexes are suitable for columns having low cardinality. The question is how can we define "low cardinality", you said that you have 100,000 distincts group_no on a table of 100,000,000 rows.
    You have a cardinality of 100,000/100,000,000 =0,001. Group_no column might be a good candidate for a bitmap index.
    You said that order_no is unique so you have a very high cardinality on this column and it might not be a candidate for your bitmap index
    Third, your query where clause involves only the group_no column so why are you including both columns when testing the bitmap and the b-tree index?
    Are you designing such a kind of index in order to not visit the table? but in your case the table is made only of those two columns, so why not follow Hermant advise for an Index Organized Table?
    Finally, you can have more details about bitmap indexes in the following richard foot blog article
    http://richardfoote.wordpress.com/2008/02/01/bitmap-indexes-with-many-distinct-column-values-wotsuh-the-deal/
    Best Regards
    Mohamed Houri

  • Btree vs Bitmap.  Optimizing load process in Data Warehouse.

    Hi,
    I'm working on fine tuning a Data Warehousing system. I understand that Bitmap indexes are very good for OLAP systems, especially if the cardinality is low and if the WHERE clause has multiple fields on which bitmap indexes exist for each field.
    However, what I'm finetuning is not query, but load process. I want to minimize the total load time. If I create a bitmap index on a field with cardinality of one million, and if the table has one million rows (each row has a distinct field value), then my understanding is
    The total size of the bitmap index = number of rows * (cardinality / 8) bytes
    (because there are 8 bits in a byte).
    Hence the size of my bitmap index will be
    Million * Million / 8 bytes = 116 GB.
    Also, does anyone know what would be the size of my B-tree index? I'm thinking
    The total size of the B-tree index = number of rows * (field length+20) bytes
    (assuming that the field length of rowid is 20 charas).
    Hence the size of my b-tree index will be
    Million * (10+20) bytes = 0.03 GB (assuming that my field length is 10 charas).
    That means B-tree index is much lesser than the size of the Bitmap index.
    Is my math correct? If so, then the disk activity will be much higher for a bitmap index than a B-tree index. Hence, creation of the bitmap index should take much longer than the B-tree index if the cardinality is high.
    Please let me know your opinions.
    Thanks
    Sankar

    Hi Jaffar,
    Thanks to you and Jonathan. This is the kind of answer I have been looking for.
    If I understand your email correctly, for the scenario from my original email, bitmap index will be 32MB where as Btree will be 23MB. Is that right?
    Suppose there is an order table with 10 orders. There are four possible values for OrderType. Based on your reply, now I understand that the bitmap index is organized as shown below.
    Data Table:
    RowId     OrderNo     OrderType
    1     23456     A
    2     23457     A
    3     23458     B
    4     23459     C
    5     23460     C
    6     23461     C
    7     23462     B
    8     23463     B
    9     23464     D
    10     23465     A
    Index table:
    OrderType     FROM     TO
    A     1     2     
    B     3     3     
    C     4     6     
    B     7     8     
    D     9     9     
    A     10     10     
    That means, you might have more entries in the index table than the cardinality. Is that right? That means, the size of the index table cannot be EXACTLY determined based on cardinality. In our example, the cardinality is 4 while there are 6 entries in the index table.
    In an extreme example, if no two adjacent records have the same OrderType, then there will be 10 records in the index table as well, as shown in the example below.
    Data Table (second example):
    RowId     OrderNo     OrderType
    1     23456     A
    2     23457     B
    3     23458     C
    4     23459     D
    5     23460     A
    6     23461     B
    7     23462     C
    8     23463     D
    9     23464     A
    10     23465     B
    Index table (second example):
    OrderType     FROM     TO
    A     1     1     
    B     2     2     
    C     3     3     
    D     4     4     
    A     5     5     
    B     6     6     
    C     7     7
    D     8     8
    A     9     9
    B     10     10
    That means, the size of the index table will be somewhere between the cardinality (minimally) and the table size (maximally).
    Please let me know if I make sense.
    Regards
    Sankar

  • 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

  • Creating a bit map index on a partitioned table

    Dear friends,
    I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
    ERROR at line 1:
    ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
    Trying to use the keyword local in front leads to wrong syntax.
    Thanks in advance !!
    Somnath

    ORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
    Cause: An attempt was made to create a global bitmap index on a partitioned table.
    Action: Create a local bitmap index instead
    Example of a Local Index Creation
    CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
    Example is about btree and I think it will work for bitmap also.

  • Estimation of Local Partitioned Bitmap Index size in Oracle

    Its datawarehousing project and the we have around 20 partitioned dimensional tables . The requirement is to create local partitioned bitmap index on almost all columns of dimension tables excluding primary key columns as they are already indexed.We need to estimate the size of index partitionwise.
    Please let me have if there is any ready piece of script which will help me in estimating size of bitmap local partitioned index.

    You may want to look into the DBMS_SPACE.CREATE_INDEX_COST procedure.
    Usage Notes* The table on which the index is created must already exist.
    * The computation of the index size depends on statistics gathered on the segment.
    * It is imperative that the table must have been analyzed recently.
    * In the absence of correct statistics, the results may be inaccurate, although the procedure will not raise any errors.

  • 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 Not Used in PROD and used in DEV

    I am in a situation where in in DEV Bitmap Index is used and in PROD bitmap Index is not used. I checked the count, in PROD I have 10 mil rows and in DEV I have 16 mil rows. Optimizer is CHOOSE and also when I tried to force to use index in PROD, I got higher cost.
    Any suggestions why Index is not used in PROD as opposed to DEV

    As other says, no guarantee that the same query with same setting OS, ORACLE to produce the same execution plan. Also, as Justin said, dont every take cost as your tuning parameter, pay attention to response time, also, number of logical reads and physical reads. What are the wait events during?
    For an index, most important factors are, blevel, clustering_factor, number of distinct values. Clustering actor make a lot of difference. You said, when you force index to use, your performance has gained. If so, why not, why the HINTS there in place? Go ahed and use it, but, after all the R&D. Are the Optimizer* paraemters same on the both databases?
    If possible, post the execution plan of the query, with HINT and without HINT as well.
    Jaffar

  • Application Table Index not being created

    Since this is slightly different than my last post, I created a new one.
    I am using the example as a basis to complete the Bulk process from the Staging table to the Application table with the following code snippet:
    public void completeBulk(String completeBulkFlags) throws Exception {
    GraphOracleSem graph = null;
    try {
    graph = getModel().getGraph();
    try {
    graph.dropApplicationTableIndex();
    } catch (SQLException e) {}
    graph.getBulkUpdateHandler().completeBulk(completeBulkFlags, null);
    graph.rebuildApplicationTableIndex();
    finally {
    if (graph != null)
    graph.close();
    It appears to be dropping the 'applicationTableIndex', however when the call 'rebuildApplicationTableIndex' the <MODEL_NAME>_IDX does not exist in the database.  And i'm not seeing errors anywhere alerting me that the index was not created.
    Since this index is not created, deletes on the model do not have an index to scan over the <MODEL_NAME>_TPL table and takes forever.  For the time being, we are creating this index manually.  However is there something that we are doing wrong using the Jena Adapter API?
    We are using the newest Jena Adapter and 11.2.0.3 Database instance.
    Thanks
    -Michael

    Hi Michael,
    Your code looks fine.
    Hmmm. That is strange. The code path for rebuilding application table index is quite straightforward. Can you please drop your own index and re-run the following by itself?
    graph.rebuildApplicationTableIndex();
    Thanks,
    Zhe Wu

  • 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?

  • 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

  • Which Event Classes i should use for finding good indexs and statistics for queries in SP.

    Dear all,
    I am trying to use pro filer to create a trace,so that it can be used as workload in
    "Database Engine Tuning Advisor" for optimization of one stored procedure.
    Please tel me about the Event classes which i  should use in trace.
    The stored proc contains three insert queries which insert data into a table variable,
    Finally a select query is used on same table variable with one union of the same table variable, to generate a sequence for records based on certain condition of few columns.
    There are three cases where i am using the above structure of the SP, so there are three SPS out of three , i will chose one based on their performance.
    1) There is only one table with three inserts which gets  into a table variable with a final sequence creation block.
    2) There are 15 tables with 45 inserts , which gets into a tabel variable with a final
    sequence creation block.
    3)
    There are 3 tables with 9 inserts , which gets into a table variable with a final
    sequence creation block.
    In all the above case number of record will be around 5 lacks.
    Purpose is optimization of queries in SP
    like which Event Classes i should use for finding good indexs and statistics for queries in SP.
    yours sincerely

    "Database Engine Tuning Advisor" for optimization of one stored procedure.
    Please tel me about the Event classes which i  should use in trace.
    You can use the "Tuning" template to capture the workload to a trace file that can be used by the DETA.  See
    http://technet.microsoft.com/en-us/library/ms190957(v=sql.105).aspx
    If you are capturing the workload of a production server, I suggest you not do that directly from Profiler as that can impact server performance.  Instead, start/stop the Profiler Tuning template against a test server and then script the trace
    definition (File-->Export-->Script Trace Definition).  You can then customize the script (e.g. file name) and run the script against the prod server to capture the workload to the specified file.  Stop and remove the trace after the workload
    is captured with sp_trace_setstatus:
    DECLARE @TraceID int = <trace id returned by the trace create script>
    EXEC sp_trace_setstatus @TraceID, 0; --stop trace
    EXEC sp_trace_setstatus @TraceID, 2; --remove trace definition
    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

  • Error while attempting to create bitmap index

    I get the error below while creating a bitmap index on a table in SQL Developer.
    How do a go about enabling this feature? I looked on Tools | Preferences menu and didn't see anything.
    Using Version 1.0.0.14.67
    >>>
    Error starting at line 1 in command:
    CREATE BITMAP INDEX "SYSTEM"."PUB_SRC_INDX_0197_US4" ON "SYSTEM"."PUB_SRC_TBL_0197_US" ("STATUS_ID")
    Error report:
    SQL Error: ORA-00439: feature not enabled: Bit-mapped indexes
    >>>
    Thanks

    Nevermind.. I found it on google. You must have an SE version of Oracle which does not support Bitmapped Indexes. You will have to use another index type.

  • 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

Maybe you are looking for

  • C Form against Purchase order

    Hi all, can anyone tell me about C form layouts in Std.SAP... also i want to know how to map the process flow to see layout standard SAP please guide Regards Rahul

  • Mail (again!) .. how do I clean all existing settings of Mail and start again?

    I have (Yosemite) Mail linking into BT.  I have a problem that occurred with Mavericks and continues with Yosemite Mail. Mail works fine for a month or two then goes wrong... almost a pattern!  Usually I put it right by deleting the account and set i

  • System Hangup

    I just bought a k7n2 delta platinum motherboard, 2500+ Sempron processor, 1GB of DDR Ram, and a Geforce 5700 LE video card.  When the system boots the D-Bracket always hangs at led 1 green, and 2-4 are red.  While it's hanging here I also can not get

  • Cannot import a cd at all.

    I just want to put a cd onto my ipod. It is suppose to be easy, i know, but when i put in a cd absolutely nothing happens. The cd does not show up, and the option to import does not show up. I can't figure out what else to try.

  • Numbered headers with centered text: the numbers are off to the side.

    Hi, I'm trying to create typical numbered headers as they appear in law reviews. For example, (I used underscore characters here to represent characters): ___________________III.Judge-made law However, Pages seems to only do this: III._______________