Bitmap Join Index Exclusions
Hi,
I have come across the following statement in some of the oracle Db related forums
'For queries that have additional criteria in the WHERE clause that doesn't appear in the bitmap join index, Oracle9i will be unable to use this index to service the query.'
Does this stand good for oracle 11gr2 also?
Here is two good articles about bitmap join indexes,
http://articles.techrepublic.com.com/5100-10878_11-1051931.html
http://www.lorentzcenter.nl/awcourse/oracle/server.920/a96520/indexes.htm
Bitmap Join Indexes have the following restrictions:
1. Parallel DML is currently only supported on the fact table. Parallel DML on one of the participating dimension tables will mark the index as unusable.
2. Only one table can be updated concurrently by different transactions when using the bitmap join index.
3. No table can appear twice in the join.
4. You cannot create a bitmap join index on an index-organized table or a temporary table.
5. The columns in the index must all be columns of the dimension tables.
6. The dimension table join columns must be either primary key columns or have unique constraints.
7. If a dimension table has composite primary key, each column in the primary key must be part of the join.
Thanks
Similar Messages
-
Has anyone successfully used bitmap join indexes? I've created several over what is logically a fact table and dimension tables (fits the model as best I can tell), but queries that sure look like they should use the index don't. I've tried it on 9.0.1.0.0 on Solaris, and 9.2.0.1.0 on AIX. Here's an example (mmw_drug_pack is the fact table, the others are dimension tables). Any thoughts or ideas? Is there an unpublished initialization parameter that activates this capability?
Bitmap join index:
CREATE BITMAP INDEX ext_drug_pack_i12
ON mmw_drug_pack (mmw_drug_route.description,
mmw_drug_route.abbrev,
mmw_drug_doseform.description,
mmw_drug_doseform.abbrev,
mmw_drug_labeler.namefull,
mmw_drug_disp.rpid,
mmw_drug_disp.pnid,
mmw_drug_disp.descdisplay)
FROM mmw_drug_pack, mmw_drug_route, mmw_drug_doseform, mmw_drug_disp, mmw_drug_labeler
WHERE mmw_drug_pack.rtid = mmw_drug_route.rtid
AND mmw_drug_pack.dfid = mmw_drug_doseform.dfid
AND mmw_drug_pack.ddid = mmw_drug_disp.ddid
AND mmw_drug_pack.labelerid = mmw_drug_labeler.labelerid
TABLESPACE indx COMPUTE STATISTICS;
Statement that (I think) should use the bitmap join index, but doesn't. Even if I add an additional filter predicate like "mmw_drug_pack.rtid = 1", Oracle still doesn't use the index.
select mmw_drug_pack.*,
mmw_drug_route.description as routedesc,
mmw_drug_route.abbrev as routeabbrev,
mmw_drug_doseform.description as doseformdesc,
mmw_drug_doseform.abbrev as doseformabbrev,
mmw_drug_labeler.namefull as labelername,
mmw_drug_disp.rpid,
mmw_drug_disp.pnid,
mmw_drug_disp.descdisplay as dispdescription
from mmw_drug_pack,
mmw_drug_route,
mmw_drug_doseform,
mmw_drug_disp,
mmw_drug_labeler
where mmw_drug_pack.rtid = mmw_drug_route.rtid
and mmw_drug_pack.dfid = mmw_drug_doseform.dfid
and mmw_drug_pack.ddid = mmw_drug_disp.ddid
and mmw_drug_pack.labelerid = mmw_drug_labeler.labelerid
[and mmw_drug_pack.rtid = 1 --additional filter predicate]Well, I didn't finally get an execution plan that uses the bitmap join index. The following statement with hint will use it, but I'm somewhat surprised that the optimizer doesn't choose this index without a hint. I'm still looking for more knowledge on this issue, so if you have any experiences to share regarding these bitmap join indexes, please do post.
Thanks,
Dave
select /*+ INDEX(mmw_drug_pack ext_drug_pack_i12) */ mmw_drug_pack.*,
mmw_drug_route.description as routedesc,
mmw_drug_route.abbrev as routeabbrev,
mmw_drug_doseform.description as doseformdesc,
mmw_drug_doseform.abbrev as doseformabbrev,
mmw_drug_labeler.namefull as labelername,
mmw_drug_disp.rpid,
mmw_drug_disp.pnid,
mmw_drug_disp.descdisplay as dispdescription
from mmw_drug_pack,
mmw_drug_route,
mmw_drug_doseform,
mmw_drug_disp,
mmw_drug_labeler
where mmw_drug_pack.rtid = mmw_drug_route.rtid
and mmw_drug_pack.dfid = mmw_drug_doseform.dfid
and mmw_drug_pack.ddid = mmw_drug_disp.ddid
and mmw_drug_pack.labelerid = mmw_drug_labeler.labelerid -
Hi all,
here's the background to my problem: have 4 large tables (40 mill records) - each with an id (same id for all of them) and lots of low-cardinality columns ('classification'-columns).
The objective is to be able to do a fast count of the id's across the tables based on various criterias for the 'classification' columns.
I also need to be able to add tables of the same format ideally without having to rebuild the whole thing.
To this end I've been experimenting with bitmap-indexes and bitmap join indexes.
Quering one table with a bitmap index on each of the 'class' columns achieves the performance goal:
select count(*)
from cl_dumc1
where class1 in (1,2,3)
and class2 = 4
and class3=2
However when I need to select across 2 or more tables I do not get the required performance:
select count(*)
from cl_dumc1 c1,
cl_dumc2 c2
where c1.class1 in (1,2,3)
and c1.class2 = 4
and c1.class3=2
and c2.class21=5
and c1.id = c2.id
As you know a bitmap index is a map (one map per distinct value of the column) onto the rowid's in the table.
So what I really wanted was bitmap indexes that maps not to the the rowids but my ID column (since this is common across all the tables).
I figured I could do this by having a skinny table (cl_central) with only one column (ID), and then create bitmap join indexes that binds my 'real' tables together to one central id (being the rowid of my cl_central table).
Here's a sample script:
create sequence dum;
create table cl_central
(id number);
insert into cl_central
select dum.nextval,dum.nextval
from all_objects;
create table cl_dumc1(id number, class1 number, class2 number, class3 number, class4 number, class5 number);
insert into cl_dumc1
select id,mod(id,4), mod(id+1,4), mod(id+2,4), mod(id+3,4), mod(id+4,4) from cl_central;
create table cl_dumc2
(id number, class21 number, class22 number, class23 number, class24 number, class25 number);
insert into cl_dumc2
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4) from cl_central;
create table cl_dumc3 (id number, class31 number, class32 number, class33 number, class34 number, class35 number);
insert into cl_dumc3
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4)from cl_central;
create table cl_dumc4(id number, class41 number, class42 number, class43 number, class44 number, class45 number);
insert into cl_dumc4
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4)from cl_central;
create unique index cl_central_pk on cl_central (id);
alter table cl_central add constraint cl_central_pk primary key (id);
create unique index cl_dumc1_pk on cl_dumc1 (id);
create unique index cl_dumc2_pk on cl_dumc2 (id);
create unique index cl_dumc3_pk on cl_dumc3 (id);
create unique index cl_dumc4_pk on cl_dumc4 (id);
alter table cl_dumc1 add constraint cl_dumc1_pk primary key (id);
alter table cl_dumc2 add constraint cl_dumc2_pk primary key (id);
alter table cl_dumc3 add constraint cl_dumc3_pk primary key (id);
alter table cl_dumc4 add constraint cl_dumc4_pk primary key (id);
declare
i number;
begin
for c in (select table_name,column_name from user_tab_columns where table_name in ('CL_DUMC1','CL_DUMC2','CL_DUMC3','CL_DUMC4') and column_name !='ID') loop
select count(*) into i from user_indexes where index_name=c.column_name;
if i = 0 then
EXECUTE IMMEDIATE 'CREATE BITMAP INDEX '||c.column_name||'
ON cl_central('||c.table_name||'.'||c.column_name||')
FROM cl_central, '||c.table_name||'
WHERE cl_central.id = '||c.table_name||'.id';
end if;
end loop;
end;
Test some queries:
select /*+INDEX(z class1)
count(*)
from cl_central z,
cl_dumc1 c1
where z.person_urn = c1.person_urn
and c1.class1=0
Explain plan:
SELECT STATEMENT Cost= 15
SORT AGGREGATE
BITMAP CONVERSION COUNT
BITMAP INDEX SINGLE VALUE CLASS1
So far so good - very quick with just selecting on the bitmap.
select /*+INDEX(z class1)
INDEX(z class21)
INDEX(z class31)
INDEX(z class41)
INDEX(z class42)
count(*)
from cl_central z,
cl_dumc1 c1,
cl_dumc2 c2,
cl_dumc3 c3,
cl_dumc4 c4
where z.id= c1.id
and z.id = c2.id
and z.id = c3.id
and z.id = c4.id
and c1.class1=0
and c2.class21=0
and c3.class31=0
and c4.class41=0
SELECT STATEMENT Cost= 4
SORT AGGREGATE
BITMAP CONVERSION COUNT
BITMAP AND
BITMAP INDEX SINGLE VALUE CLASS1
BITMAP INDEX SINGLE VALUE CLASS21
BITMAP INDEX SINGLE VALUE CLASS31
BITMAP INDEX SINGLE VALUE CLASS41
Look great - very fast accessing just small bitmap indexes.
select /*+INDEX(z class1)
INDEX(z class21)
INDEX(z class31)
INDEX(z class41)
INDEX(z class42)
count(*)
from cl_central z,
cl_dumc1 c1,
cl_dumc2 c2,
cl_dumc3 c3,
cl_dumc4 c4
where z.id = c1.id
and z.id = c2.id
and z.id = c3.id
and z.id = c4.id
and c1.class1=0
and c2.class21=0
and c3.class31=0
and c4.class41=0
and c4.class42 =1
SELECT STATEMENT Cost= 16
SORT AGGREGATE
HASH JOIN
TABLE ACCESS FULL CL_DUMC4
TABLE ACCESS BY INDEX ROWID CL_CENTRAL
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP INDEX SINGLE VALUE CLASS1
BITMAP INDEX SINGLE VALUE CLASS21
BITMAP INDEX SINGLE VALUE CLASS31
BITMAP INDEX SINGLE VALUE CLASS41
BITMAP INDEX SINGLE VALUE CLASS42
Disaster (well it is with my volumes...) - it visits the tables in addition to the bitmaps - AND I CANT SEE THE REASON FOR IT - all I did was to add a second condition to the last classification table.
Does anyone have any explanation for this?Is the cardinality of
c4.class41 and c4.class42
combined also low?
Probably Oracle thinks that the cardinality of class41 and class42 column values is not low and it needs to do a full table access of table C4. Check the cardinality of class41 and class42 put together.
Did you try creating a bitmap index (or a regular composite index) on both class41 and class42 columns? A regular index on both the columns together will help in this case.
Shakti
(http://www.impact-sol.com)
(Developers of Guggi Oracle - Tool for DBAs and Developers) -
2 problem with BITMAP JOIN INDEX and access plan
On my schema ("LSA") I have 3 tables:
AAB_VENDUTO (~4.200.000 record)
AAB_ARTICOLO (~8.200 record)
AAB_CLIENTE (~15.000 record)
AAB_ARTICOLO.MARCA has 1079 distinct values
AAB_CLIENTE.TITOLO_STUDIO has 22 distinct values
I create 2 different bitmap join index:
CREATE BITMAP INDEX lsa.AAB_V_ARTICOLO_MARCA_IDX ON LSA.AAB_VENDUTO(MARCA)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_ARTICOLO aa WHERE vv.articolo_id=aa.articolo_id;
CREATE BITMAP INDEX lsa.AAB_V_CLIENTE_TIT_STUDIO_IDX ON LSA.AAB_VENDUTO(TITOLO_STUDIO)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_CLIENTE cc WHERE vv.cliente_id=cc.cliente_id;(star_trasformation_enabled is TRUE)
I run (on SQL Developer 1.5.5) these similar queries:
SELECT DISTINCT VV.cliente_id FROM LSA.AAB_VENDUTO VV JOIN LSA.AAB_ARTICOLO AA on VV.articolo_id=AA.articolo_id
WHERE (MARCA='ALGIDA' OR MARCA='SAMMONTANTA');
SELECT DISTINCT VV.cliente_id FROM LSA.AAB_VENDUTO VV JOIN LSA.AAB_CLIENTE CC on VV.cliente_id=CC.cliente_id
WHERE (titolo_studio='LAUREA BREVE' OR titolo_studio='MAGISTRALE');The first one use correctly the bitmap join index, this is the access plan:
!http://bitlgs.altervista.org/_altervista_ht/marca.png!
but the second query...
!http://bitlgs.altervista.org/_altervista_ht/titolo_studio.png!
why the second query doesn't use the bitmap index?
problem #2:
I create another bitmap index:
CREATE BITMAP INDEX LSA.AAB_V_CLIENTE_SESSO_IDX ON LSA.AAB_VENDUTO(SESSO)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_CLIENTE cc WHERE vv.cliente_id=cc.cliente_id;and I run this query:
SELECT VV.cliente_id, COUNT(*) FROM LSA.AAB_VENDUTO VV JOIN LSA.AAB_CLIENTE CC on VV.cliente_id=CC.cliente_id
WHERE sesso='Donna' and (titolo_studio='LAUREA BREVE' or titolo_studio='MAGISTRALE') GROUP BY VV.cliente_id;this is the access plan:
!http://bitlgs.altervista.org/_altervista_ht/terzo.png!
In my opinion, the part that I have marked as 'A' is superfluous...
why it make a join with AAB_CLIENTE table? Why it filter again the titolo_studio and sesso field?
Edited by: Nirpol on 4-set-2009 13.25Nirpol wrote:
I create 2 different bitmap join index:
CREATE BITMAP INDEX lsa.AAB_V_ARTICOLO_MARCA_IDX ON LSA.AAB_VENDUTO(MARCA)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_ARTICOLO aa WHERE vv.articolo_id=aa.articolo_id;
CREATE BITMAP INDEX lsa.AAB_V_CLIENTE_TIT_STUDIO_IDX ON LSA.AAB_VENDUTO(TITOLO_STUDIO)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_CLIENTE cc WHERE vv.cliente_id=cc.cliente_id;
What happens if you just create two plain bitmap indexes without the join?
CREATE BITMAP INDEX lsa.AAB_V_ARTICOLO_MARCA_IDX ON LSA.AAB_VENDUTO(MARCA);
CREATE BITMAP INDEX lsa.AAB_V_CLIENTE_TIT_STUDIO_IDX ON LSA.AAB_VENDUTO(TITOLO_STUDIO) ;You can also go with normal indexes on the FK rows (cliente_id) and the optimizer can do a bitmap conversion from normal index to bitmap index if needed. Are the column values evenly distributed? If not you might need to go for some column histogram. but I don't have the impression that this is really useful in your case. -
Schema Design for 10^6+ rows table (Indicator Column / Bitmap Join Index?)
Hi all,
I read following suggestion for a SELECT with LEFT OUTER JOIN in a DB2 consulting company paper for a 10 million-rows table:
SELECT columns
FROM ACCTS A LEFT JOIN OPT1 O1
ON A.ACCT_NO = O1.ACCT_NO
AND A.FLAG1 = ‘Y’
LEFT JOIN OPT2 O2
ON A.ACCT_NO = O2.ACCT_NO
AND A.FLAG2 = ‘Y’
WHERE A.ACCT_NO = 1
For DB2, according to the paper, the following is true: Iff A.FLAG1 <> ‘Y’ Then no Table or Index Access on OPT1 is done. Same for A.FLAG2/OPT2.
I recreated the situation for ORACLE with the following script and came to some really interesting questions
DROP TABLE maintbl CASCADE CONSTRAINTS;
DROP TABLE opt1 CASCADE CONSTRAINTS;
DROP TABLE opt2 CASCADE CONSTRAINTS;
CREATE TABLE maintbl
id INTEGER NOT NULL,
dat VARCHAR2 (2000 CHAR),
opt1 CHAR (1),
opt2 CHAR (1),
CONSTRAINT CK_maintbl_opt1 CHECK(opt1 IN ('Y', 'N')) INITIALLY IMMEDIATE ENABLE VALIDATE,
CONSTRAINT CK_maintbl_opt2 CHECK(opt2 IN ('Y', 'N')) INITIALLY IMMEDIATE ENABLE VALIDATE,
CONSTRAINT PK_maintbl PRIMARY KEY(id)
CREATE TABLE opt1
maintbl_id INTEGER NOT NULL,
adddat1 VARCHAR2 (100 CHAR),
adddat2 VARCHAR2 (100 CHAR),
CONSTRAINT PK_opt1 PRIMARY KEY(maintbl_id),
CONSTRAINT FK_opt1_maintbltable FOREIGN KEY(maintbl_id) REFERENCES maintbl(id)
CREATE TABLE opt2
maintbl_id INTEGER NOT NULL,
adddat1 VARCHAR2 (100 CHAR),
adddat2 VARCHAR2 (100 CHAR),
CONSTRAINT PK_opt2 PRIMARY KEY(maintbl_id),
CONSTRAINT FK_opt2_maintbltable FOREIGN KEY(maintbl_id) REFERENCES maintbl(id)
INSERT ALL
WHEN 1 = 1 THEN
INTO maintbl (ID, opt1, opt2, dat) VALUES (nr, is_even, is_odd, maintbldat)
WHEN is_even = 'N' THEN
INTO opt1 (maintbl_id, adddat1, adddat2) VALUES (nr, adddat1, adddat2)
WHEN is_even = 'Y' THEN
INTO opt2 (maintbl_ID, adddat1, adddat2) VALUES (nr, ADDdat1, ADDdat2)
SELECT LEVEL AS NR,
CASE WHEN MOD(LEVEL, 2) = 0 THEN 'Y' ELSE 'N' END AS is_even,
CASE WHEN MOD(LEVEL, 2) = 1 THEN 'Y' ELSE 'N' END AS is_odd,
TO_CHAR(DBMS_RANDOM.RANDOM) AS maintbldat,
TO_CHAR(DBMS_RANDOM.RANDOM) AS adddat1,
TO_CHAR(DBMS_RANDOM.RANDOM) AS adddat2
FROM DUAL
CONNECT BY LEVEL <= 100;
COMMIT;
SELECT * FROM maintbl
LEFT OUTER JOIN opt1 ON maintbl.id = opt1.maintbl_id AND maintbl.opt1 = 'Y'
LEFT OUTER JOIN opt2 ON maintbl.id = opt2.maintbl_id AND maintbl.opt2 = 'Y'
WHERE id = 1;
Explain plan for "Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi":
http://i.imgur.com/f0AiA.png
As one can see, the DB uses a view to index-access the opt tables iff indicator column maintbl.opt1='Y' in the main table.
Explain plan for "Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production":
http://i.imgur.com/iKfj8.png
As one can see, the DB does NOT use the view, instead uses a pretty useless case-statement
Now my questions:
1) What does the optimizer do in 11.2 XE?!?
2) In General: Do you suggest this table-setup? Does your yes/no suggestion depend on the rowcount in the tables? Of course I see the problem with incorrectly updated columns and would NEVER do it if there is another truly relational solution with same performance possibly.
3) Is there a way to avoid performance issues if I don't use an indicator column in ORACLE? Is this what a [Bitmap Join Index|http://docs.oracle.com/cd/E11882_01/server.112/e25789/indexiot.htm#autoId14] is for?
Thanks in advance and happy discussing,
BlamaFair enough. I've included a cut-down set of SQL below.
CREATE TABLE DIMENSION_DATE
DATE_ID NUMBER,
CALENDAR_DATE DATE,
CONSTRAINT DATE_ID
PRIMARY KEY
(DATE_ID)
CREATE UNIQUE INDEX DATE_I1 ON DIMENSION_DATE
(CALENDAR_DATE, DATE_ID);
CREATE TABLE ORDER_F
ORDER_ID VARCHAR2(40 BYTE),
SUBMITTEDDATE_FK NUMBER,
COMPLETEDDATE_FK NUMBER,
-- Then I add the first bitmap index, which works:
CREATE BITMAP INDEX SUBMITTEDDATE_FK ON ORDER_F
(DIMENSION_DATE.DATE_ID)
FROM ORDER_F, DIMENSION_DATE
WHERE ORDER_F.SUBMITTEDDATE_FK = DIMENSION_DATE.DATE_ID;
-- Then attempt the next one:
CREATE BITMAP INDEX completeddate_fk
ON ORDER_F(b.date_id)
FROM ORDER_F, DIMENSION_DATE b
WHERE ORDER_F.completeddate_fk = b.date_id;
-- which results in:
-- ORA-01408: such column list already indexed -
I'm using oracle9i.2.
When I execute select * from v$option;
Bit-mapped indexes FALSE
How can I enable Bitmap Join Index ?
Is bitmap join index feature enable in Standard Edition ?Nanda Kishore,
Unfortunately you cannot currently define bitmap join indexes in Warehouse Builder. We are planning to include those in an upcoming release.
Mark. -
Bitmap Join Index generation in DDL
I am unable to figure out how to have a bitmap join index defined in the Physical Model be generated in the DDL out of Oracle SQL Deleveloper Data Modeler.
Please advise how this can be done.
Thanks!Hi,
The Properties Editor for a Bitmap Join Index has an "Index Columns" tab. The relevant columns on the related "Dimension" Tables should be moved to the "Selected Columns" list on this tab.
As Philip said, you need to make sure the Physical Model is open before you do the DDL generation.
When you select the Generate button, the DDL Generation Options dialog is displayed. This has a set of tabs below the main panel. You can select the Bitmap Join Indexes tab, and check that your Bitmap Join Index appears there and its "Selected" check box is selected. (If it's not selected, select it.)
The DDL for your Bitmap Join Index should appear close to the end of the generated DDL.
David -
Bitmap Join Index on Partitioned Table
Are there any restrictions on creating a bitmap join index on a partition table (I think that the bitmap indexes can only be created as local on partitioned tables)?
Thanks in advance
Murthy.Fair enough. I've included a cut-down set of SQL below.
CREATE TABLE DIMENSION_DATE
DATE_ID NUMBER,
CALENDAR_DATE DATE,
CONSTRAINT DATE_ID
PRIMARY KEY
(DATE_ID)
CREATE UNIQUE INDEX DATE_I1 ON DIMENSION_DATE
(CALENDAR_DATE, DATE_ID);
CREATE TABLE ORDER_F
ORDER_ID VARCHAR2(40 BYTE),
SUBMITTEDDATE_FK NUMBER,
COMPLETEDDATE_FK NUMBER,
-- Then I add the first bitmap index, which works:
CREATE BITMAP INDEX SUBMITTEDDATE_FK ON ORDER_F
(DIMENSION_DATE.DATE_ID)
FROM ORDER_F, DIMENSION_DATE
WHERE ORDER_F.SUBMITTEDDATE_FK = DIMENSION_DATE.DATE_ID;
-- Then attempt the next one:
CREATE BITMAP INDEX completeddate_fk
ON ORDER_F(b.date_id)
FROM ORDER_F, DIMENSION_DATE b
WHERE ORDER_F.completeddate_fk = b.date_id;
-- which results in:
-- ORA-01408: such column list already indexed -
Bitmap Join Indexes Still Causing Problems
Hello again,
I thought I had fixed this problem in a previous post, but it turns out I was incorrect. Once again, there is an issue with bitmap join indexes in Oracle 10g EE. I'm getting an empty result when I shouldn't be. Below I've pasted the output of a SQL session to illustrate the point, but here's a summary of what's in the trace:
I run a query and get an empty result. Then I drop a bitmap join index and re-run the query and get a result. Then I recreate the bitmap join index and run the same query again, but get an empty result. Then I show the explain plan for the query.
This is clearly wrong behavior, so I'm wondering if there are any restrictions, perhaps not well documented, on when it's ok to use bitmap join indexes. For example, what's the maximum length allowed on a varchar field that the bitmap index is on? Is there some cardinality threshold? I'm aware that bitmap indexes are intended for columns with low cardinality, but even if that's not the case, it shouldn't affect the correctness of the result, only the computation time. Does anyone have an idea of what exactly is going wrong here? Do I have any chance of fixing it?
Trace follows:
SQL*Plus: Release 10.2.0.3.0 - Production on Tue May 5 02:07:50 2009
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SELECT
2 o1.lex as label,
3 o2.lex as "comment",
4 o4.lex as producer
5 FROM
6 bmTriples250K t1, bmsNodes250K s1, bmpNodes250K p1, bmoNodes250K o1,
7 bmTriples250K t2, bmpNodes250K p2, bmoNodes250K o2,
8 bmTriples250K t3, bmpNodes250K p3,
9 bmTriples250K t4, bmpNodes250K p4, bmoNodes250K o4
10 WHERE
11 t1.s = s1.hash
12 and t1.p = p1.hash
13 and t1.o = o1.hash
14 and s1.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399'
15 and p1.lex = 'http://www.w3.org/2000/01/rdf-schema#label'
16 and t1.s = t2.s
17 and t2.p = p2.hash
18 and t2.o = o2.hash
19 and p2.lex = 'http://www.w3.org/2000/01/rdf-schema#comment'
20 and t1.s = t3.s
21 and t3.p = p3.hash
22 and p3.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/producer'
23 and t3.o = t4.s
24 and t4.p = p4.hash
25 and t4.o = o4.hash
26 and p4.lex = 'http://www.w3.org/2000/01/rdf-schema#label';
no rows selected
SQL>
SQL> DROP INDEX BMSJOINNODES250K;
Index dropped.
SQL> SELECT
2 o1.lex as label,
3 o2.lex as "comment",
4 o4.lex as producer
5 FROM
6 bmTriples250K t1, bmsNodes250K s1, bmpNodes250K p1, bmoNodes250K o1,
7 bmTriples250K t2, bmpNodes250K p2, bmoNodes250K o2,
8 bmTriples250K t3, bmpNodes250K p3,
9 bmTriples250K t4, bmpNodes250K p4, bmoNodes250K o4
10 WHERE
11 t1.s = s1.hash
12 and t1.p = p1.hash
13 and t1.o = o1.hash
14 and s1.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399'
15 and p1.lex = 'http://www.w3.org/2000/01/rdf-schema#label'
16 and t1.s = t2.s
17 and t2.p = p2.hash
18 and t2.o = o2.hash
19 and p2.lex = 'http://www.w3.org/2000/01/rdf-schema#comment'
20 and t1.s = t3.s
21 and t3.p = p3.hash
22 and p3.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/producer'
23 and t3.o = t4.s
24 and t4.p = p4.hash
25 and t4.o = o4.hash
26 and p4.lex = 'http://www.w3.org/2000/01/rdf-schema#label';
LABEL
comment
PRODUCER
surcharged rekindles wireworm
shimmery colures stockpiles pipetted globes majuscule gaggled crypto poisonously
corrosively explanted unaccepted chippewas filmsets clocks fluctuating vindicat
or emeerate impending duffle werwolves fishers manumissions luxuriance centavos
lumping cancan begrimes cheerer bustards influxes frogfishes peevishly photosphe
rically expropriating udder authored styleless idyl collards foreknow balkers ch
ews damner hawknoses onerosities macs araks seines pawl physiques readers recoil
LABEL
comment
PRODUCER
monstrosities penes choiring hydrocephalies familiarity lumberers ricked offbea
ts weightlessness weakness synergist stained mouthpieces brakes gnarlier twittin
g draper misarranges misinterpretations japanner runout carbonates catalepsy enf
eoffing engined pallor partitioning pseudoartistic resistances wideness teacakes
payers profferers dolts conceited scrunches thickener relishable heehawed greys
transparency durableness pandemics finable groomers heirships
ethicians fondler turks
LABEL
comment
PRODUCER
SQL>
SQL> CREATE BITMAP INDEX BMSJOINNODES250K
2 ON BMTRIPLES250K(BMSNODES250K.LEX)
3 FROM BMTRIPLES250K, BMSNODES250K
4 WHERE BMTRIPLES250K.S = BMSNODES250K.HASH;
Index created.
SQL> SELECT
2 o1.lex as label,
3 o2.lex as "comment",
4 o4.lex as producer
5 FROM
6 bmTriples250K t1, bmsNodes250K s1, bmpNodes250K p1, bmoNodes250K o1,
7 bmTriples250K t2, bmpNodes250K p2, bmoNodes250K o2,
8 bmTriples250K t3, bmpNodes250K p3,
9 bmTriples250K t4, bmpNodes250K p4, bmoNodes250K o4
10 WHERE
11 t1.s = s1.hash
12 and t1.p = p1.hash
13 and t1.o = o1.hash
14 and s1.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399'
15 and p1.lex = 'http://www.w3.org/2000/01/rdf-schema#label'
16 and t1.s = t2.s
17 and t2.p = p2.hash
18 and t2.o = o2.hash
19 and p2.lex = 'http://www.w3.org/2000/01/rdf-schema#comment'
20 and t1.s = t3.s
21 and t3.p = p3.hash
22 and p3.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/producer'
23 and t3.o = t4.s
24 and t4.p = p4.hash
25 and t4.o = o4.hash
26 and p4.lex = 'http://www.w3.org/2000/01/rdf-schema#label';
no rows selected
SQL>
SQL>
SQL>
SQL> explain plan for
2 SELECT
3 o1.lex as label,
4 o2.lex as "comment",
5 o4.lex as producer
6 FROM
7 bmTriples250K t1, bmsNodes250K s1, bmpNodes250K p1, bmoNodes250K o1,
8 bmTriples250K t2, bmpNodes250K p2, bmoNodes250K o2,
9 bmTriples250K t3, bmpNodes250K p3,
10 bmTriples250K t4, bmpNodes250K p4, bmoNodes250K o4
11 WHERE
12 t1.s = s1.hash
13 and t1.p = p1.hash
14 and t1.o = o1.hash
15 and s1.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399'
16 and p1.lex = 'http://www.w3.org/2000/01/rdf-schema#label'
17 and t1.s = t2.s
18 and t2.p = p2.hash
19 and t2.o = o2.hash
20 and p2.lex = 'http://www.w3.org/2000/01/rdf-schema#comment'
21 and t1.s = t3.s
22 and t3.p = p3.hash
23 and p3.lex = 'http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/producer'
24 and t3.o = t4.s
25 and t4.p = p4.hash
26 and t4.o = o4.hash
27 and p4.lex = 'http://www.w3.org/2000/01/rdf-schema#label';
Explained.
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3609661641
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 1716 | 23 (5)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 1716 | 23 (5)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 1520 | 22 (5)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 1324 | 21 (5)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 1287 | 19 (6)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 1091 | 18 (6)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 895 | 17 (6)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 699 | 16 (7)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 662 | 14 (8)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 466 | 13 (8)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 270 | 12 (9)| 00:00:01 |
|* 11 | HASH JOIN | | 1 |74 | 11 (10)| 00:00:01 |
| 12 | TABLE ACCESS BY INDEX ROWID | BMTRIPLES250K | 10 | 370 | 5 (0)| 00:00:01 |
| 13 | BITMAP CONVERSION TO ROWIDS| | | | | |
|* 14 | BITMAP INDEX SINGLE VALUE | BMSJOINNODES250K | | | | |
| 15 | TABLE ACCESS BY INDEX ROWID | BMTRIPLES250K | 10 | 370 | 5 (0)| 00:00:01 |
| 16 | BITMAP CONVERSION TO ROWIDS| | | | | |
|* 17 | BITMAP INDEX SINGLE VALUE | BMSJOINNODES250K | | | | |
|* 18 | TABLE ACCESS BY INDEX ROWID | BMPNODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | PKBMPNODES250K | 1 | | 0 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | BMONODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | PKBMONODES250K | 1 | | 0 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID | BMPNODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | PKBMPNODES250K | 1 | | 0 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | PKBMTRIPLES250K | 1 |37 | 2 (0)| 00:00:01 |
| 25 | TABLE ACCESS BY INDEX ROWID | BMONODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | PKBMONODES250K | 1 | | 0 (0)| 00:00:01 |
|* 27 | TABLE ACCESS BY INDEX ROWID | BMPNODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | PKBMPNODES250K | 1 | | 0 (0)| 00:00:01 |
|* 29 | TABLE ACCESS BY INDEX ROWID | BMSNODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | PKBMSNODES250K | 1 | | 0 (0)| 00:00:01 |
|* 31 | INDEX RANGE SCAN | PKBMTRIPLES250K | 1 |37 | 2 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID | BMONODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | PKBMONODES250K | 1 | | 0 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | BMPNODES250K | 1 | 196 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | PKBMPNODES250K | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
11 - access("T3"."O"="T4"."S")
14 - access("T4"."SYS_NC00006$"='http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399')
17 - access("T3"."SYS_NC00006$"='http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399')
18 - filter("P3"."LEX"='http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/producer')
19 - access("T3"."P"="P3"."HASH")
21 - access("T4"."O"="O4"."HASH")
22 - filter("P4"."LEX"='http://www.w3.org/2000/01/rdf-schema#label')
23 - access("T4"."P"="P4"."HASH")
24 - access("T1"."S"="T3"."S")
26 - access("T1"."O"="O1"."HASH")
27 - filter("P1"."LEX"='http://www.w3.org/2000/01/rdf-schema#label')
28 - access("T1"."P"="P1"."HASH")
29 - filter("S1"."LEX"='http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product399')
30 - access("T1"."S"="S1"."HASH")
31 - access("T1"."S"="T2"."S")
33 - access("T2"."O"="O2"."HASH")
34 - filter("P2"."LEX"='http://www.w3.org/2000/01/rdf-schema#comment')
35 - access("T2"."P"="P2"."HASH")
67 rows selected.Well, I didn't finally get an execution plan that uses the bitmap join index. The following statement with hint will use it, but I'm somewhat surprised that the optimizer doesn't choose this index without a hint. I'm still looking for more knowledge on this issue, so if you have any experiences to share regarding these bitmap join indexes, please do post.
Thanks,
Dave
select /*+ INDEX(mmw_drug_pack ext_drug_pack_i12) */ mmw_drug_pack.*,
mmw_drug_route.description as routedesc,
mmw_drug_route.abbrev as routeabbrev,
mmw_drug_doseform.description as doseformdesc,
mmw_drug_doseform.abbrev as doseformabbrev,
mmw_drug_labeler.namefull as labelername,
mmw_drug_disp.rpid,
mmw_drug_disp.pnid,
mmw_drug_disp.descdisplay as dispdescription
from mmw_drug_pack,
mmw_drug_route,
mmw_drug_doseform,
mmw_drug_disp,
mmw_drug_labeler
where mmw_drug_pack.rtid = mmw_drug_route.rtid
and mmw_drug_pack.dfid = mmw_drug_doseform.dfid
and mmw_drug_pack.ddid = mmw_drug_disp.ddid
and mmw_drug_pack.labelerid = mmw_drug_labeler.labelerid -
Hi,
I have a db of version 10.2.0.3 on a Unix box. This is used for DW.
I have a dbms job which is basically creates 6 bit map join indexes between two tables parallelly. One of the table (Fact table) has almost 170 million data and the other one (Dimension table) has 1.2 million data. Fact table is partioned and the indexes are local index.
For the last couple of days, this job is taking almost 70+ minutes whereas previously, it used to take around 44 to 48 minutes.
My pga_aggregate_size is 50GB and temp tablespace size is 33GB.
Per day 1 million data gets populated in the Fact table.
It used to run fine earlier. One fine morning we found this performance issue.
It will be really helpful, if we get some suggesstion about the tuning options.
Regards,
SoumyajitJeet wrote:
I have a db of version 10.2.0.3 on a Unix box. This is used for DW.
I have a dbms job which is basically creates 6 bit map join indexes between two tables parallelly. One of the table (Fact table) has almost 170 million data and the other one (Dimension table) has 1.2 million data. Fact table is partioned and the indexes are local index.
For the last couple of days, this job is taking almost 70+ minutes whereas previously, it used to take around 44 to 48 minutes.
My pga_aggregate_size is 50GB and temp tablespace size is 33GB.
Per day 1 million data gets populated in the Fact table.
It used to run fine earlier. One fine morning we found this performance issue.
It will be really helpful, if we get some suggesstion about the tuning options.Soumyajit,
since you probably don't have suitable data available from those runs (by "data" I mean e.g. SQL traces with row source operation statistics, wait event information and number of I/Os etc.) where it used to be faster it's going to be hard to tell where the difference comes from since there are many possibilities.
If really nothing else has changed apart from the data volume then one possible explanation could be that the join operation that is required to populate the bitmap join index switched from e.g. single pass to multi-pass due to the increased data volume.
Another explanation could be that one of the tables used to be cached in the buffer cache (small table threshold) but has now exceeded the default 2% limit for cached table scans and therefore requires more physical I/O than previously.
But there is a multitude of other possibilities starting from changes to the software/hardware (patches to Oracle, O/S, storage etc.), concurrent processes running at the same time, changes to the logging attributes of the tablespace/database, different execution plan due to statistics change, ASMM automatic cache buffer shrinkage etc. etc.
It definitely makes sense to trace the execution now to have that information available, furthermore you could try to check if the usage of the TEMP tablespace has increased in comparison to previous runs which could indicate above mentioned switch to a less efficient pass mode of the join.
Can you pinpoint already if only particular bitmap join indexes take longer than before or all six are slower than before?
Do I understand this correctly, that you run six jobs in parallel to create the indexes, or is it one job that runs the create index statements one after the other?
And do you use the PARALLEL DDL option to create each individual index? What about LOGGING/NOLOGGING?
By the way, what is reason that you rebuild the indexes every day? Is this after a load into a particular partition to rebuild the indexes of that partition after the data load? Or is it a rebuild of all partitions?
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Does BI 7.0 use bit map join indexes?
I have seen several threads on SDN which show that SAP BI is using bit map indexes with Oracle database. However, it is not clear whether BI utilizes bit map join indexes or just bit map index. Bit map index is on a single table whereas bitmap join index is on a join of two or more tables.
It will make sense for SAP BI to use bit map join indexes with star transformations where a join is done among fact and dimension tables.> Thanks. Another question, are bit map indexes used both for F and E fact tables or just for F. I am not using real-time cubes (where SAP BI uses B-Tree indexes for F table to avoid dead locks).
Why don't you simply check this in your BI system yourself?
And, yes, of course it uses bitmap indexes for both fact table types.
E-fact tables are the same as F-Facttables except that they contain the compressed/rolled up data.
regards,
Lars -
Problem with bitmap partitioned index
My order table (3.6 M rows) has got 4 partitions (one per year). I've defined 24 LOCAL BITMAP INDEXES on the data (DSS environment); every index is built on one column.
The cardinality of these columns is quite various (from 10% to 80%) - I know in some case the use of bitmap index is not OK -.
The table is manipulated in this way:
- Nightly it has about 5K new rows inserted.
- All of this rows have update after insertion (only some of this update are referred to indexed column).
- Early in the morning the partition table referred to actual data, is analyzed with COMPUTE STATISTICS option.
- During the day the data are queried thousand times.
The problem is:
1. Before table/index partitioning all the indexes of the table were BITMAP too, and their size were acceptable; these size did not grow up to much during the time. We use to rebuild index once at 2-3 months.
2. After table/index partitioning some of the bitmap indexes related to the partition that contain actual data, get poor in few days. Their size grow up very quickly (about 16mb at day) and they can allocate 100 times more space than before partitioning. So, I must rebuild these indexes / partitions once at 2-3 days. I have checked the distinct values of poor indexes column, and there is not correlation between cardinality and growth (I mean, this problem happens on index with low cardinality as well as high cardinality).
3. I have the same order table in another schema with the same indexes and similar number of rows (1.7 M). Any of these indexes have strange growth. (I.E.: size of index on AGENT column is normally 2Mb; the poor index is about 200Mb after 4 work days).
We work with 8.1.7.2 on Windows 2000.
Does anyone have any idea about my problem?
Thanks in advance L.Nirpol wrote:
I create 2 different bitmap join index:
CREATE BITMAP INDEX lsa.AAB_V_ARTICOLO_MARCA_IDX ON LSA.AAB_VENDUTO(MARCA)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_ARTICOLO aa WHERE vv.articolo_id=aa.articolo_id;
CREATE BITMAP INDEX lsa.AAB_V_CLIENTE_TIT_STUDIO_IDX ON LSA.AAB_VENDUTO(TITOLO_STUDIO)
FROM LSA.AAB_VENDUTO vv, LSA.AAB_CLIENTE cc WHERE vv.cliente_id=cc.cliente_id;
What happens if you just create two plain bitmap indexes without the join?
CREATE BITMAP INDEX lsa.AAB_V_ARTICOLO_MARCA_IDX ON LSA.AAB_VENDUTO(MARCA);
CREATE BITMAP INDEX lsa.AAB_V_CLIENTE_TIT_STUDIO_IDX ON LSA.AAB_VENDUTO(TITOLO_STUDIO) ;You can also go with normal indexes on the FK rows (cliente_id) and the optimizer can do a bitmap conversion from normal index to bitmap index if needed. Are the column values evenly distributed? If not you might need to go for some column histogram. but I don't have the impression that this is really useful in your case. -
Creation of logical index terminated. Join index create error.
Hi to all,
After running for a few weeks fine. See my earlier message Delete and recreate BWA index of a cube in process chain.
Chains are "terminating" again. I get the following error messages:
Creation of logical index '[Technical Cube_name]' terminated. Error text:
Join index create error;index=bwp_[technical cube_name],location
=nlscli63:30203 2433
Creation of BIA index for InfoCube '[Technical Cube_name]' terminated during activation
A manual deletion by the program RSDDTREX_INDEX_DELETE and a recreation in RSDDV is necessarry to get the index active.
Has anyone a clue on beforehand what is happening or same experiences, before i put in a SAP OSS message.
Regards,
RenéHi
Firstly please ensure that no error exists for the cube when you are
trying to create the index. You can check that in RSRV. Also you need
to check if no change run or loading is occuring.
Please also check that you are not using the backup mode mutual
as this can cause the problem, please refer to the SAP note 1383228.
Best Regards,
Des Gallagher -
If there are no filter in the where clause of a sql statement and just joins would not use any index, becuase it fetches all the rows no matter of join type (outer etc..). Is this statement correct?. Thx.
flip@FLOP> create table a ( id number(9) primary key, d date );
Table created.
Elapsed: 00:00:00.00
flip@FLOP> create table b ( id number(9) primary key, d date );
Table created.
Elapsed: 00:00:00.00
flip@FLOP>
flip@FLOP> insert into a
2 select object_id,last_ddl_time from all_objects
3 where object_id is not null;
23669 rows created.
Elapsed: 00:00:01.05
flip@FLOP>
flip@FLOP> insert into b
2 select object_id,last_ddl_time from all_objects where rownum < 11
3 and object_id is not null;
10 rows created.
Elapsed: 00:00:00.00
flip@FLOP>
flip@FLOP> analyze table a compute statistics for table for all indexes for all indexed columns;
Table analyzed.
Elapsed: 00:00:00.03
flip@FLOP> analyze table b compute statistics for table for all indexes for all indexed columns;
Table analyzed.
Elapsed: 00:00:00.00
flip@FLOP>
flip@FLOP> set autotrace traceonly
flip@FLOP>
flip@FLOP> select a.id, b.id
2 from a, b
3 where a.id = b.id
4 ;
10 rows selected.
Elapsed: 00:00:00.01
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=10 Bytes=80)
1 0 NESTED LOOPS (Cost=3 Card=10 Bytes=80)
2 1 INDEX (FULL SCAN) OF 'SYS_C003757' (UNIQUE) (Cost=1 Card
=10 Bytes=40)
3 1 INDEX (UNIQUE SCAN) OF 'SYS_C003756' (UNIQUE)
Statistics
0 recursive calls
0 db block gets
14 consistent gets
0 physical reads
0 redo size
588 bytes sent via SQL*Net to client
499 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed
flip@FLOP>
flip@FLOP> select a.*, b.*
2 from a, b
3 where a.id = b.id
4 ;
10 rows selected.
Elapsed: 00:00:00.01
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=10 Bytes=260)
1 0 NESTED LOOPS (Cost=5 Card=10 Bytes=260)
2 1 TABLE ACCESS (FULL) OF 'B' (Cost=2 Card=10 Bytes=130)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'A' (Cost=2 Card=1 Byte
s=13)
4 3 INDEX (UNIQUE SCAN) OF 'SYS_C003756' (UNIQUE)
Statistics
42 recursive calls
0 db block gets
34 consistent gets
0 physical reads
0 redo size
846 bytes sent via SQL*Net to client
499 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed -
How can I create a local [b]bitmap[/b] index on a [b]list-partitionintable?
Hello there,
Could anyone show me a sample code of How to create a local bitmap index on a list-partitioning table?
I tried some code such as
1):
CREATE BITMAP INDEX bix_CID
ON Sales(Customer_ID)
TABLESPACE INDX
STORAGE (INITIAL 32K NEXT 32K PCTINCREASE 0)
LOCAL NOLOGGING;
I can create the index with this statement, but when the status of the index is 'N/A' (means 'INVALID').
2):
CREATE BITMAP INDEX bix_ver ON Versions
(VERNUM) TABLESPACE INDX
LOCAL
(PARTITION par1
,PARTITION par2
,PARTITION par3
,PARTITION par4
,PARTITION par5
,PARTITION par6
,PARTITION par7
THen I get ORA-600 error.
Thanks a lot!
wendyYou are creating the index properly. When you create a local index, it creates same number of partitions as the partitions in the table which are tightly coupled to table partitions.
I guess you are checking the status of index in dba_indexes or user_indexes table. The status here could be misleading since this table gives status of non-partitioned indexes.
For partitioned indexes you should check for status in dba_ind_partitions or user_ind_partitions which gives status of each partition in index.
Chanda
Maybe you are looking for
-
Error when creating a ReportDocument object in ver 11.5.3300.0
When I try to create a new ReportDocument from .NET the application exists with no other information. There is an event log entry similar to this one: Faulting application CrystalTest1.vshost.exe, version 9.0.21022.8, time stamp 0x47316898, faulting
-
Can I set an af:setActionListener on the search button of a af:query ?
Hi, I want to store a flag in the session scope when the search button of an <af:query> form is pressed. The flag is used to determine if the query has been executed and the result table iterator should provide the result. I'm still looking for a sol
-
Missing folders in iTunes music folder.
There are several artist folders missing in my iTunes music folder, but in the song info in iTunes it says the songs are located in the missing folders. What could the problem be??
-
IOS6 beta 2 downgrade to 5.1.1
Hi, I have upgraded my iPad 3 with iOS 6 beta 2. How do I downgrade it back to 5.1? any ideas? Thanks
-
HT1766 iphone 3gs could not activate after trying to update to new version
in the middle of updating, the itune shows that the iphone was not installed, but it is. Have try numbers of time but still the same, anyone can help me on that??