I was running a test on a huge table with a bitmap index on one of the columns. But bitmap index is not getting used. Below are the test details.
create table test (col1 number, col2 number);
begin
for i in 1..1000000
loop
if mod(i,2) = 0 then
insert into test values(i, 'Y');
else
insert into test values(i, 'N');
end if;
end loop;
end;
COMMIT;
The intention here is to have only two distinct values in the entire table. Based on these values I will not build BITMAP index on col2.
CREATE BITMAP INDEX BITMAP_TEST on TEST(col2) COMPUTE STATISTICS;
Now when I run the below query, it doesn't uses BITMAP index. Instead the explain plan shows a full table scan.
select * from test where col2 = 'Y';
Now when I force ORACLE to use index through hint, the cost is too high while using the bitmap index(probably why the ORACLE chose not to use the index at the first stage).
I have read somewhere, that BITMAP index is useful when we have more than 1 or 2 bitmap indexes on other columns of the same table as well And the query should be like
select * from table where col1 = 'Y' and sex = 'F';
In this case oracle will use BITMAP but not in the case where there is only one column that has BITMAP index.
Considering all the factors stated above, is there any way I can fine tune my original query?
I was executing following query and it was taking about 20 sec's to execute before i decided to create B-Tree(Normal) index on column DeliVery.
Select DeliVery,Code,Sum(Units),Sum(Loads),Count(units), Count(Loads) Where
[code]...
After creating B-Tree index on Column Delivery the execution time has been reduced to one second ,thats what i wanted. But If i create Bitmap index on the same column then execution time is not getting reduced and is still same around 20 sec.I think theoratically "Delivery" column is the right candidate for Bitmap index? whether should i create bitmap index or stick with B-Tree index?
i want to create a bitmap index,but getting the error shown below..i created primary key on column dname of dept and unique constraint on empno of emp.
SQL> create bitmap index bindx on dept d(d.dname) from emp e,dept d where e.deptno=d.deptno; create bitmap index bindx on dept d(d.dname) from emp e,dept d where e.deptno=d.deptno * ERROR at line 1: ORA-25954: missing primary key or unique constraint on dimension
oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production PL/SQL Release 11.1.0.6.0 - Production "CORE 11.1.0.6.0 Production"
I have a procedure that is run weekly to load the data, for which it calls another procedure. This weekly procedure, disables the index, load the data, and rebuilds the index. During rebuilding of index, its giving ORA-00054: resource busy and acquire with NOWAIT error. I dont have privileges to look for session id, and kill the session. How to avoid this error.
create or replace PROCEDURE "WCL_WEEKLY_UPLOAD" ( p_event_id IN NUMBER ) [code]....
As you can see, after the procedure wc_upload, COMMIT is issued, and then the rebuilding of the index is starting. So dont know what is causing the table to lock.
gives different result when we exchange the index ksr_valid_until_i on table kreditkarten_sets_rs. For some reasons we changed the index from bitmap to normal and are getting different results. Switching back gives us the same results as before. When we avoid the usage of this index in the statement than we are getting the same results as when we are using the normal index.
is there some performance/access difference between a bitmap index on a number column and char(1) column? Both columns are not null with a default value.My application has a querie like this:
If I create a bitmap index on column "column_char", the access plan is not changed. But changing the column datatype to number(1) and obviously the values, the index is accessed and the cost decreases.This table has 4.000.000 rows. Oracle 11.2.0.2SO
When I try to find the ranges matching (intersecting) a certain range (e.g. '21112'-'2111299999'), optimizer does a FULL TABLE SCAN, which is not opimal in my opinion. I use the hint to force the optimizer use the indexes.
select /*+ index_combine(rng2 x_rng2_start, x_rng2_end) */ * from rng2 where rng2.rng_start <= '2111999999' and rng2.rng_end >= '2111'; Plan SELECT STATEMENT ALL_ROWSCost: 60 Bytes: 17,344 Cardinality: 1,084 7 TABLE ACCESS BY INDEX ROWID TABLE LUMAMIPA.RNG2 Cost: 60 Bytes: 17,344 Cardinality: 1,084 6 BITMAP CONVERSION TO ROWIDS 5 BITMAP AND 2 BITMAP MERGE 1 BITMAP INDEX RANGE SCAN INDEX (BITMAP) LUMAMIPA.X_RNG2_START 4 BITMAP MERGE 3 BITMAP INDEX RANGE SCAN INDEX (BITMAP) LUMAMIPA.X_RNG2_END
However, when I try to join the 2 sets of ranges by matching the intersecting ranges, then the range scan and "BITMAP AND" of the 2 indexes is not done, even though the hint is specified:
select /*+ index_combine(rng2 x_rng2_start, x_rng2_end) */ count(*) cnt from rng1 join rng2 on rng1.rng_start <= rng2.rng_end and rng1.rng_end >= rng2.rng_start; [code]...
How to make the optimizer use the range scan of both indexes? Is there a better way to match the ranges?
I have a few dimension tables with surrogate keys and a fact table with foreign keys on columns referring to the dimension table. I want to create primary keys on the dimension tables and foreign keys on the fact table, but with minimal overhead of constraint validation when loading the data.
Other than bitmap indexes on the FK columns on the fact table, I also want to create a bitmap join index on the fact table joined to the dimension table on a handful of dimension columns.
Which is the best suited constraint definition? Only RELY, or RELY + DISABLE, or RELY + DISABLE + NOVALIDATE, or RELY + NOVALIDATE, or any other?
I have added a bitmap image in my workbook but when i am exporting it into excel or HTML ,only text part of the title is exporting into excel file . The bitmap is only visible in discoverer workbook ,after exporting to excel or HTML, it disappears,
I am on 11.2.0.3 Enterprise Edition. We are using the new feature "Composite Domain Index" for a Domain index on a very large table (>250.000.000 rows). It really works with mixed queries. We added two number columns using FILTER BY.We have lots of DML on this table. Therefore, we are executing synchronize and optimize once the week. The synch behaves pretty normal. But "optimize_index" takes a very very long time to complete. I have switsched on 'logging' for the optimize process. The $I table takes some time but is finished normally. But the optimization of the $S table (that is the table created for the CDI feature) is running over 12 hours now - and far from being finished. From the logfile, I can see that it optimizes 1000 rows every 20 minutes. Here is the output of the logfile:
Oracle Text, 11.2.0.3.0 14:33:05 06/26/12 begin logging 14:33:05 06/26/12 event 14:33:05 06/26/12 process $N for optimize: SEQDEV.GEN_GES_DESCRIPTION_CTX_I 14:33:16 06/26/12 14:33:16 06/26/12 [code]....
I haven't found a recommendation from Oracle not to use "optimize_index" for Domain Indexes with CDI. But in my case, it would be much faster just to drop and recreate the Domain Index in question.
I have a huge table (about 60 gb) partition over range. The index on this table is global index created on 4 columns together. I have a query which is running very slowly. The explain plan is showing the use of this global index.Explain plan is not showing pstart and pend because the index is global.
I am facing the error "ORA-01502: index or partition of such index is in unusable state " while loading the text data using sql loader with direct path (direct = Y ,rows = 10000) option. Table consists an composite non unique index. If I query the dba indexes for the effected index it shows the index status as VALID. There was no maintaince done on the effected table or index. I have tried loading the same data using conventional path but didn't found any issues for the same.
where @var is user supplied input at runtime...We had a index on a.c2 . The CBO would use this index to generate an opitimised query plan.We found some records from table "b" were dropping due to inner join. So we made a change in join. It'd be like
a.c1(+)=b.c1 and nvl(a.c2,@var)=@var
This query is no longer using the index, instead its doing a full table scan causing the query to slowdown.I have tried creating index on nvl(a.c2,'31-dec-9999')
But the CBO won't use it.Anyway to create index on this col so that full table scan can be avoided?
We have occurrences of enq : TX - index contentions in the database. Using the SQL ID, we have identified the INSERT statement and the table which they are trying to insert.
This table has almost 25 different indexes, some of which are unique as well.I am wondering how to identify the actual index causing issue, out of these 25 indexes.
Is there any way to pin point to the name of index which is causing the lock?My plan is, once the index is identified, I would like to check the extents and inittrans and other attributes of this index to fix.
Let's consider such table that all rows fit into single block:
SQL> create table test as select rownum id, '$'||rownum name from dual connect by level <= 530; Table created. SQL> create index i_test on test(id); Index created. SQL> SQL> begin
[code].....
why does approach with full scan take longer even if table occupies only one data block? PS. 11gR2
I'm using Oracle 11g and I have a bunch of indexes and I want to check if they are being used. I just ran my workloads and now I want to see when each one was last used so I can see if it was during my timeframe or not.
After I ran my test, I found the below, but since I did not enable this, plus I have many indexes.
--Monitor an index to see if it's used alter index SAMPLE_INDEX monitoring usage; select * from v$object_usage where index_name = 'SAMPLE_INDEX'; alter index SAMPLE_INDEX nomonitoring usage;
There is an index with degree 16 on a rac env. The base table has no degree. The table and index are not partitioned. Does the degree of index only affect index DDL (alter, rebuild etc)? Any effects on query (PQ)?
i have a application which uses 32 tables for retrieval in this 4 tables are important and have a size more than 100 mb can i move the index of these 4 tables cache memory to improve the applications retrieval performance if i done so ,then that will affect any other applications performance