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

  • 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,
    Blama

    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

  • 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

  • Bitmap join indexes

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

    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.

  • 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

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

    here 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 AM

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

  • Bitmap join Index

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

    There'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
    --Pradeep                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

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