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
Similar Messages
-
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 -
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 -
Bitmap join indexes in 9i?
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. -
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 -
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 -
Local index vs global index in partitioned tables
Hi,
I want to know the differences between a global and a local index.
I'm working with partitioned tables about 10 millons rows and 40 partitions.
I know that when your table is partitioned and your index non-partitioned is possible that
some database operations make your index unusable and you have tu rebuid it, for example
when yo truncate a partition your global index results unusable, is there any other operation
that make the global index unusable??
I think that the advantage of a global index is that takes less space than a local and is easier to rebuild,
and the advantage of a local index is that is more effective resolving a query isn't it???
Any advice and help about local vs global index in partitioned tables will be greatly apreciatted.
Thanks in advancehere is the documentation -> http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2570
In general, you should use global indexes for OLTP applications and local indexes for data warehousing or DSS applications. Also, whenever possible, you should try to use local indexes because they are easier to manage. When deciding what kind of partitioned index to use, you should consider the following guidelines in order:
1. If the table partitioning column is a subset of the index keys, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 2.
2. If the index is unique, use a global index. If this is the case, you are finished. If this is not the case, continue to guideline 3.
3. If your priority is manageability, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 4.
4. If the application is an OLTP one and users need quick response times, use a global index. If the application is a DSS one and users are more interested in throughput, use a local index.
Kind regards,
Tonguç -
How to find global index in partition table
Hi guys ,
need one help
How to find global index on partition table
How to find local index on partition table
Need query
Thanks in advance
Edited by: nav on Feb 17, 2012 6:51 AMnav wrote:
Hi Solomon,
so I have to identify partition & index are created or not,
also I have check the status of index ( both global and local)So what's the problem? Table/index partition is an object, so you can query DBA_OBJECTS:
SELECT SUBOBJECT_NAME,
CREATED
FROM DBA_OBJECTS
WHERE OWNER = partitioned-table-owner
AND OBJECT_NAME = partitioned-table-name
AND CREATED >= TRUNC(SYSDATE)
/This will give you partitions created today. So if you run this right after your job (I hope your job doen't run too close to midnight), you'll get table partition name your job created. Same logic can be applied to indexes.
SY. -
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. -
Can I create unpartitioned index on partitioned table??
Hi,
I am not clear about the concepts of partitioned and non partitioned index.I was under impression that If we create a index on partitioned table it will be automatically becomes a partitioned index.But I cheked in my DB there are many unpartitioned indexes on large partitioned tables.
Which one of these is efficient? wht is the concept of local and global related to these partitioned and unparitioned.I am bit confused.pls help me.
ThanksThere's nothing prevent you from creating a nonpartitioned index on partitioned table. The official name for it is Global Nonpartitioned Indexes
Global Nonpartitioned Indexes
Global nonpartitioned indexes behave just like a nonpartitioned index. They are commonly used in OLTP environments and offer efficient access to any individual record.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i461446 -
Indexing on partitioned tables
I was wondering if there are any good standards for indexing very large partitioned tables (i.e. what should I index). Also, if there are any good standards for indexing these partitioned tables when running queries that do not include the partitioned column in the query?
There's no real difference in what you would index, other than maybe a slightly lower requirement for indexing on tha partitioning key column(s).
You ought to be considering whether you need local or global indexes though, and you'll find a lot of information on that over at http://asktom.oracle.com and in the documentation -- to simplify, OLTP usually uses global indexes and DWH usually uses local indexes. You'll want to understand the pro's and con's or each before deciding on your own situation though. -
Partition Eliminiation on views and joins with other partitioned tables
I have a bunch of tables that are daily partioned and other which are not. We constantly join all these tables. I have noticed that partition elimination doesn't happen in most cases and I want some input or pointers on these.
Case 1
We have a view that joins a couple of partitioned tables on the id fileds and they the partition key is timestamp with local time zone.
TABLEA
tableaid
atime
TABLEB
tablebid
tableaid
btime
The view basically joins on tableaid, a.tableaid = b.tableaid(+) and a bunch of other non partitioned tables. atime and btime are the individal partition keys in the tables and these time do not match up like the id's in other words there is a little bit of correlation but they can be very different.
When I run a query against the view providing a time range for btime, I see partition elimination on tabled in the explain plan with KEY on Pstart/Pstop. But its a full tablescan on tablea. I was hoping there would be somekind of partition elimination here since its also partioned daily on the same datatype timestamp with local time zone.
Case 2
I have a couple of more partitioned tables
TABELC
tablecid
tablebid
ctime
TABLED
tabledid
tablebid
dtime
As you can see these tables are joined with tablebid and the times here generally correlate to tableb's timestamp as well.
Sub Case 1
When I join these tables to the view and give a time range on btime, I see partition elimination happening on tableb but not on tablea or any of the other tables.
Sub Case 2
Then I got rid of the view, wrote a query that us similar to the view where I join on tableaid (tablea and tableb), then on tablebid (tableb, tablec and tabled) and a few other tables and execute the query with some time range on btime and I still see that partition elimination happens only on tableb.
I thought that if other tables are also partitioned on a similark key that partition eliminition should happen? Or what am I missing here that is preventing from partition elimination on the other tables.Performance is of utmost importance and partition pruning is going to help in that. I guess that's what I'm trying to acheive.
To achive partition elimination on tablec, d, etc I'm doing an outer join with btime and that seems to work. Also since most of the time after the partition elimination, I don't need a full tablescan since the period I will be querying most of the time will be small I also created a local index on id field that I'm using to join so that it can do a "TABLE ACCESS BY LOCAL INDEX ROWID" this way it should peform better than a global index since the index traversal path should be small when compared to the global index.
Of couse I still have problem with the tablea not being pruned, since I cannot do an outer join on two fields in the same table (id and time). So might just include the time criteria again and may be increase the time range a little more when compared to what the actual user submitted to try not to miss those rows.
Any suggestions is always welcome. -
Local Vs Global Index on partitioned table?
Hello All,
DESC PS_P1_EMP_QRYSCRTY
Name Null? Type
EMPLID NOT NULL VARCHAR2(11)
EMPL_RCD NOT NULL NUMBER(38)
ROWSECCLASS NOT NULL VARCHAR2(30)
ACCESS_CD CHAR(1)
MY SQL QUERY IS:-
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
This query was taking around 15 mins to run at sql-prompt
I have created a partitioned table based on PS_P1_EMP_QRYSCRTY :-
CREATE TABLE PS_P1_EMP_QRYSCRTY_BAK
TABLESPACE PSNEWTAB
PARTITION BY HASH(ROWSECCLASS)
( PARTITION PART1 ,
PARTITION PART2 ,
PARTITION PART3 ,
PARTITION PART4 ,
PARTITION PART5 ,
PARTITION PART6 ,
PARTITION PART7 ,
PARTITION PART8 ,
PARTITION PART9 ,
PARTITION PART10 ,
PARTITION PART11 ,
PARTITION PART12 ,
PARTITION PART13 ,
PARTITION PART14 ,
PARTITION PART15 ,
PARTITION PART16
ENABLE ROW MOVEMENT
AS SELECT * FROM PS_P1_EMP_QRYSCRTY
I created a local index like on PS_P1_EMP_QRYSCRTY_BAK
CREATE INDEX PS_P1_EMP_QRYSCRTY_BAK
ON PS_P1_EMP_QRYSCRTY_BAK(ROWSECCLASS,EMPLID,EMPL_RCD)
TABLESPACE PSINDEX
LOCAL;
The Following is an extract From PS_P1_EMP_QRYSCRTY_BAK
1ST COLUMN =TABLE NAME
2ND COLUMN = PARTITION NAME
3RD COLUMN = NUM OF DISTINCT ROWSECCLASS IN THE PARTITION
4TH COLUMN = NUM OF TOTAL ROWS IN THE PARTITION
TABLE_NAME PARTITION_NAME NUM_OF_DISTINCT_ROWSECCLASS NUM_OF_ROWS
PS_P1_EMP_QRYSCRTY_BAK | PART1 | 25 | 289058
PS_P1_EMP_QRYSCRTY_BAK | PART2 | 25 | 154537
PS_P1_EMP_QRYSCRTY_BAK | PART3 | 27 | 364219
PS_P1_EMP_QRYSCRTY_BAK | PART4 | 33 | 204528
PS_P1_EMP_QRYSCRTY_BAK | PART5 | 23 | 527974
PS_P1_EMP_QRYSCRTY_BAK | PART6 | 22 | 277210
PS_P1_EMP_QRYSCRTY_BAK | PART7 | 23 | 517125
PS_P1_EMP_QRYSCRTY_BAK | PART8 | 30 | 307634
PS_P1_EMP_QRYSCRTY_BAK | PART9 | 28 | 523169
PS_P1_EMP_QRYSCRTY_BAK | PART10 | 38 | 192565
PS_P1_EMP_QRYSCRTY_BAK | PART11 | 27 | 120062
PS_P1_EMP_QRYSCRTY_BAK | PART12 | 33 | 407829
PS_P1_EMP_QRYSCRTY_BAK | PART13 | 37 | 522349
PS_P1_EMP_QRYSCRTY_BAK | PART14 | 25 | 275991
PS_P1_EMP_QRYSCRTY_BAK | PART15 | 21 | 259676
PS_P1_EMP_QRYSCRTY_BAK | PART16 | 23 | 468071
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
Now when i run this query it gives result in around 5-6 mins
MY PS_P1_EMP_QRYSCRTY_BAK table contains sumwhat 6 million rows...
Now My Questions are:-
1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance By increasing or decreasing the number of partitions.
2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of the query....
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
i mean in where clause rowsecclass is used thats why i partitioned my table on ROWSECCLASS.
And in select clause i m selecting EMPLID and EMPL_RCD
Thats y i made a local index on ROWSECCLASS,EMPLID ,EMPL_RCD .
Thanks
--Pradeep1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance >By increasing or decreasing the number of partitions.
2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of >the query....You'll have to see for yourself what is optimal. Every system is different. Here are some ideas, though.
Your query
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSIDappears to read all qualifying rows across all qualifying partitions. Since you are partitioning by an id that would appear to exclude range and list partitioning instead so the hash partition is probably the best for your application.
Regarding global vs local partitions, I have seen timings indicate that global indexes can improve cross-partition queries slighly. I have not worked with partitions for a while but remember that global partition maintenance is difficult; anything the partition structure changes the global index had to be rebuild. You can check the documentation to see if that has changed.
If possible creating a unique index should give better performance than using an index allowing duplicates.
Maybe you are looking for
-
Material valuation based on Invoice price
Dear SAPERS, Please provide some help regarding one of my clients requirement. My client wants to calculate the material cost or price based on FIFO invoice price at the time of Issuing materials from store to any consumption.(instead of standard or
-
Adobe Premiere Elements 10 unable to import *.mt2
When I attempt to import a file with the .mt2 extension into Adobe Premiere Elements 10 I recieve a message that says "Online Services encountered an error. The service will now be terminated or paused if possible." Then I am unable to generate the
-
I need help choosing a new Palm phone.
No device I'm trying to get a new Palm phone but the HP website has no useful information. I would appreciate anyone's help with choosing a new phone to replace my Palm Centro. I want to continue using the Palm because it sounds like iphones and oth
-
HT1933 I was charged three times for one of my purchases. How do I get a refund?
There were problems with iTunes while I was purchasing and I was charged three times for the same purchase. I am not on the same workstation here iTunes is installed now. How do I get a refund without using the receipt function?
-
Liquify Filter PS CS5: Zooming Out Glitch in Keyboard Shortcut?
I've been regularly encountering a problem using the keyboard shortcut for Zoom Out ("Cmd -") when using the Liquify filter and wonder whether this problem has been encountered by other users. "Cmd -" has the opposite effect of its intended purpose,