Hash partitioning v. list partitioning on surrogate key + partition pruning

Hi,
Have a large fact table with surrogate keys, therefore queries are of form
select dimension.attribute..
from fact, dima, dimb..
where facta.dima_surrogate_key = dima.dimension_key
and facta.dimb_surrogate_key = dimb.dimension_key
and dima.attribute = <value>
and dimb.attribute = <value>
Would ideally like partition pruning to happen but will this happen if hash partition on facta.surrogate_key
Likewise could list partition on facta.dima_surrogate_key and further sub-partition on hash of factb.dima_surrogate_key.
Any advice much appreciated.

user5716448 wrote:
Hi,
Version 11.2.0.1
fact table structure
PRODUCT_ID NUMBER
RETAILER_ID NUMBER
OUTLET_ID NUMBER
CALENDAR_ID NUMBER
BRANCH_ID NUMBER
PUBLISHER_ID NUMBER
DISTRIBUTOR_ID NUMBER
TRANS_TYPE_ID NUMBER
TRANS_QTY NUMBER (10)
TRANS_VALUE (10,4)
No date on fact table (just surrogate_id for calendar whihc links to calendar/date dimension.
Although queries can be by date of transaction, most aren't.
Potential to grow to 3 billion rows.
Considering hash partitioning on the product_id, simply to break data down and product_id is the largest dimension.About hash partitioning – in this case it is probably all about the ability to run in parallel. Do not have any info on that, so I cannot comment further.
>
sqls are varied, lots of different types some query all dimensions, sometimes a few. Not the straightforward date examples in the manual.You can pick a dimension that is frequently used by the SQLs. I understand that there is no perfect one, but even if you pick just a “good” one you might have a good deal of partition elimination.
>
Users run 3rd part ad-hoc reporting layer which has to allow them to report against the star in any way they want.
Star transformation hint enabled. Have heard in deciding number of hash partitions, partition size should geneerally be < 2gb.
e.g transactions for a given product for customers belonging to a given multiple in a given week
select trans_qty, trans_value, m.prod_name, m.prod_num, r.cust_name, w.branch_name, rtt.trans_date, rtt,trans_type
from retailer_transaction rt, media m, wholesaler w, calendar c, retailer r, trans_type rtt
where rt.issue_id = m.dimension_key
and m.prod_num = 600
and rt.branch_id = w.dimension_key
and rt.outlet_id = r.dimension_key
and r.multiple_num = 700
and rt.calendar_id = calendar.dimension_key
and m.issue_year_week = 201110
and rt.trans_type_id = rtt.dimension_keyLastly, you need to focus on weather and how to partition your indexes (I assume you have bunch of bitmaps). This decision is at least as important as partitioning the table.

Similar Messages

  • Hash partitions+pruning+star transformation

    Hi there,
    We are considering partitioning our fact table on product_id (hash) range and list not suitable for us, most queries by product.
    Couple of questions
    1) does oracle create the hash partitions automaticall, if say hash by quantity what happens if later decide need more partitions - keen to keep maintenance to minimum
    2) Will partition pruning work
    simplified structure of fact table
    sales_qty
    product_id
    customer_id
    day_id (date of sale)
    simple query
    select sum(sale_qty)
    from sales, products, customers
    where sales.product_id = product.product_id
    and sales.customer_id = customer.customer_id
    and product.creation_week between 200901 and 200952
    all id's in the fact table are surrogate id's and are simply the dimesnion keys of the realetd dimensions, therefore users won't query omn these columns directly.
    If we hash partition on product_id and database parameter star_transformation enabled will this give us query performance benefits (i.e. partition pruning).
    Many Thanks

    Hi there,
    We are considering partitioning our fact table on product_id (hash) range and list not suitable for us, most queries by product.
    Couple of questions
    1) does oracle create the hash partitions automaticall, if say hash by quantity what happens if later decide need more partitions - keen to keep maintenance to minimum
    2) Will partition pruning work
    simplified structure of fact table
    sales_qty
    product_id
    customer_id
    day_id (date of sale)
    simple query
    select sum(sale_qty)
    from sales, products, customers
    where sales.product_id = product.product_id
    and sales.customer_id = customer.customer_id
    and product.creation_week between 200901 and 200952
    all id's in the fact table are surrogate id's and are simply the dimesnion keys of the realetd dimensions, therefore users won't query omn these columns directly.
    If we hash partition on product_id and database parameter star_transformation enabled will this give us query performance benefits (i.e. partition pruning).
    Many Thanks

  • Need help on List-Hash partition - oracle 11 feature !

    Can a list-hash partitioned tabled be exchanged for a partition?
    Say, the table is partitioned by list on CODE (varchar2) column and subpartitioned by a NUMBER column
    i.e. create table TAB1 (ID, Code, Number)
    partition by LIST (Code)
    subpartition by HASH (Number)
    subpartition template
    ( subpartition1 , subpartition2 , subpartition3)
    partition part1 values ('A'),
    partition part1 values ('B'),
    partition part1 values ('C')
    Lets say the subpartitions1,2 and 3 have values 1,2,3,4,5,6....10, how can I move only say value 1 and 2 into another table using exchange partition method? Is this possible?

    >
    Thanks for the reply. The db version details is as below. And I am more interested in knowing if and how can data be extracted from hash sub-partitions for a given sub-partition key value, using partition exchange. Can anyone demonstrate this or point to any article that demonstrates this? I am not even sure if something like is possible.
    >
    What part of my reply didn't you undertand?
    Except now you are saying 'extract' where before you wanted to exchange the hash subpartition. If you exchange then the subpartition will now have NO data since it will have been exchanged with an empty table.
    In a partition exchange ALL of the partition (or subpartition) is exchanged, not just part of it. So for a hash subpartition you either exchange ALL data or none of it. If you only want some of the data in the subpartition you have to query it out.
    No one can provide any samples until you provide a valid sample yourself. You said your partitions have character data
    partition part1 values ('A'),
    partition part1 values ('B'),
    partition part1 values ('C')
    );But then you ask about manipulating numeric data
    >
    Lets say the subpartitions1,2 and 3 have values 1,2,3,4,5,6....10, how
    >
    Which is it?
    Post the DDL for the table and show which subpartition you want to query or exchange.

  • HASH PARTITION TO LIST PARTITION

    version : Oracle 10g
    hi All,
          i have a table partitioned by hash(8 segments) with 200 millions records . now we want to move to list partition the same table by state.
          Is there a way to drop hash Partitions with out losing the data, and Add list partition.
        

    No, you can't "convert" the Hash Partitions to List Partitions.
    You have to create a new, empty, table that is List Partitioned and then move the data over to the new table.
    You could use Direct Path Insert (i.e. INSERT with APPEND Hint) with PARALLEL degree and NOLOGGING on the target table to speed up the copy.
    You could also use DBMS_REDEFINITION to migrate the data.
    In either case, you also have to create the Indexes on the new table.
    Hemant K Chitale

  • Is list partition and hash partition one and the same

    I am creating table with partition with the commands
    CREATE TABLE ABD (ENO NUMBER(5),CID NUMBER(3),ENAME VARCHAR2(10))
    PARTITION BY LIST (ENO)
    (PARTITION P1 VALUES (123),
    PARTITION P2 VALUES (143),
    PARTITION CLIENT_ID VALUES (746))
    ALTER TABLE ABD
    ADD PARTITION CLIENT_756 VALUES (756)
    but when i describe the table script it is showing like this
    CREATE TABLE ABD (
    ENO NUMBER (5),
    ENAME VARCHAR2 (10),
    CID NUMBER (3) )
    PARTITION BY HASH (ENO)
    PARTITIONS 4
    STORE IN ( USERS,USERS,USERS,
    USERS);
    actually i am creating list partition but it is showing hash partition why is it so?

    when i describe the table script it is showing like thisHow do you describe it, and which version are you on ?
    TEST@db102 SQL> CREATE TABLE ABD (ENO NUMBER(5),CID NUMBER(3),ENAME VARCHAR2(10))
      2  PARTITION BY LIST (ENO)
      3  (PARTITION P1 VALUES (123),
      4  PARTITION P2 VALUES (143),
      5* PARTITION CLIENT_ID VALUES (746))
    TEST@db102 SQL> /
    Table created.
    TEST@db102 SQL> ALTER TABLE ABD
      2* ADD PARTITION CLIENT_756 VALUES (756)
    TEST@db102 SQL> /
    Table altered.
    TEST@db102 SQL> select dbms_metadata.get_ddl('TABLE','ABD','TEST') from dual;
    DBMS_METADATA.GET_DDL('TABLE','ABD','TEST')
      CREATE TABLE "TEST"."ABD"
       (    "ENO" NUMBER(5,0),
            "CID" NUMBER(3,0),
            "ENAME" VARCHAR2(10)
       ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
      STORAGE(
      BUFFER_POOL DEFAULT)
      TABLESPACE "USERS"
      PARTITION BY LIST ("ENO")
    (PARTITION "P1"  VALUES (123)
      PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "USERS" NOCOMPRESS ,
    PARTITION "P2"  VALUES (143)
      PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "USERS" NOCOMPRESS ,
    PARTITION "CLIENT_ID"  VALUES (746)
      PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "USERS" NOCOMPRESS ,
    PARTITION "CLIENT_756"  VALUES (756)
      PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "USERS" NOCOMPRESS )
    TEST@db102 SQL>                                                                               

  • Cost to change hash partition key column in a history table

    Hi All,
    I have the following scenario.
    We have a history table in production which has 16 hash partitions on the basis of key_column.
    But the nature of data that we have in history table that has 878 distinct values of the key_column and about 1000 million data and all partitons are in same tablespace.
    Now we have a Pro*C module which purges data from this history table in the following way..
    > DELETE FROM hsitory_tab
    > WHERE p_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
    > AND t_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
    > AND ROWNUM <= 210;
    Now (p_date,t_data are one of the two columns in history table) data is deleted using thiese two date column conditions but key_column for partition is different.
    So as per aboove statement this history table containd 6 months data.
    DBA is asking to change this query and use partiton date wise.Now will it be proper to change the partition key_column (the existing hash partiton key_column >have 810 distinct values) and what things we need to cosider to calculate cost behind this hash partition key_column cahange(if it is appropriate to change >partition )key_column)Hope i explained my problem clearly and waiting for your suggestions .
    Thanks in advance.

    Hi Sir
    Many thanks for the reply.
    For first point -
    we are in plan to move the database to 10g after a lot of hastle between client.For second point -
    If we do partition by date or week we will have 30 or 7 partitions .As suggested by you as we have 16 partitions in the table best approach would be to have >partition by week then we will have 7 partitions and then each query will heat 7 partitions .For third point -
    Our main aim to reduce the timings of a job(a Pro*C program) which contains the following delete query to delete data from a history table .So accroding to the >query it is deleting data every day for 7 months and while deleting it it queries this hug etable by date.So in this case hash partition or range partiton or >hash/range partition which will be more suitable.
    DELETE FROM hsitory_tab
    WHERE p_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
    AND t_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
    AND ROWNUM <= 210;I have read in hash partition is used so that data will be evenly distributed in all partitions (though it depends on nature of data).In my case i want some suggestion from you to take the best approach .

  • Hash Partitioning and Partition-Wise Joins

    Hi,
    For the ETL process of a Data Warehouse project I have to join 2 tables (~10M rows) over their primary key.
    I was thinking of hash partitioning these 2 tables over their PK. Through this the database (9.2) should be able to do a Hash-Hash Full Partition-wise Join. For more detail about that you can have a look at:
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96520/parpart.htm#98291
    What I'm looking for are some documents or recommandation concerning the number of hash partitions to create depending on the number of rows of the tables, CPU of the server or any other parameters.
    I would be grateful if someone could give some input.
    Mike

    here you have all papers:
    Oracle9i Database List of Books
    (Release 2 (9.2))
    http://otn.oracle.com/pls/db92/db92.docindex?remark=homepage
    Joel P�rez

  • How data is distributed in HASH partitions

    Guys,
    I want to partitions my one big table into 5 different partitions based on HASH value of the LOCATION field of the table.
    My question is, Will the data be distributed equally in partitions or will end up in one partition or I need to have 5 diferent HASH value for location key to end up in five partitions.

    Hash partitioning enables easy partitioning of data that does not lend itself to range or list partitioning. It does this with a simple syntax and is easy to implement. It is a better choice than range partitioning when:
    1) You do not know beforehand how much data maps into a given range
    2) The sizes of range partitions would differ quite substantially or would be difficult to balance manually
    3) Range partitioning would cause the data to be undesirably clustered
    4) Performance features such as parallel DML, partition pruning, and partition-wise joins are important
    The concepts of splitting, dropping or merging partitions do not apply to hash partitions. Instead, hash partitions can be added and coalesced.
    What I think that is, in your case list partitioning can be of choice.
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i462869

  • Creation of Hash Partitioned Global Index

    Hash Partion Index creation
    Hi friends,
    Could you suggest me whether we can create a hash partitioned index by using syntax as below in 9i.
    CREATE INDEX hgidx ON tab (c1,c2,c3) GLOBAL
    PARTITION BY HASH (c1,c2)
    (PARTITION p1 TABLESPACE tbs_1,
    PARTITION p2 TABLESPACE tbs_2,
    PARTITION p3 TABLESPACE tbs_3,
    PARTITION p4 TABLESPACE tbs_4);
    I am getting error ORA-14005 Missing Key word Range.
    Thanks in advance for your help.

    Yaseer,
    Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
    Yes
    We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
    Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
    You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
    Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
    Above staement will create non-partitioned index
    Here is an example of creating global partitioned indexes
    CREATE INDEX month_ix ON sales(sales_month)
       GLOBAL PARTITION BY RANGE(sales_month)
          (PARTITION pm1_ix VALUES LESS THAN (2)
           PARTITION pm2_ix VALUES LESS THAN (3)
           PARTITION pm3_ix VALUES LESS THAN (4)
            PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

  • Uneven distribution in Hash Partitioning

    Version :11.1.0.7.0 - 64bit Production
    OS :RHEL 5.3
    I have a range partitioning on ACCOUNTING_DATE column and have 24 monthly partitions.
    To get rid of buffer busy waits on index, i have created global partitioned index using below ddl
    DDL :
    CREATE INDEX IDX_GL_BATCH_ID ON SL_JOURNAL_ENTRY_LINES(GL_BATCH_ID)
    GLOBAL PARTITION BY HASH (GL_BATCH_ID) PARTITIONS 16 TABLESPACE OTC_IDX PARALLEL 8 INITRANS 8 MAXTRANS 8 PCTFREE 0 ONLINE;After index creation, i realized that only one index hash partition got all rows.
    select partition_name,num_rows from dba_ind_partitions where index_name='IDX_GL_BATCH_ID';
    PARTITION_NAME                   NUM_ROWS
    SYS_P77                                 0
    SYS_P79                                 0
    SYS_P80                                 0
    SYS_P81                                 0
    SYS_P83                                 0
    SYS_P84                                 0
    SYS_P85                                 0
    SYS_P87                                 0
    SYS_P88                                 0
    SYS_P89                                 0
    SYS_P91                                 0
    SYS_P92                                 0
    SYS_P78                                 0
    SYS_P82                                 0
    SYS_P86                                 0
    SYS_P90                         256905355As far as i understand, HASH partitioning will distribute evenly. By looking at above distribution, i think, i did not benefit of having multiple insert points using HASH partitioning as well.
    Here is index column statistics :
    select TABLE_NAME,COLUMN_NAME,NUM_DISTINCT,NUM_NULLS,LAST_ANALYZED,SAMPLE_SIZE,HISTOGRAM,AVG_COL_LEN from dba_tab_col_statistics where table_name='SL_JOURNAL_ENTRY_LINES'  and COLUMN_NAME='GL_BATCH_ID';
    TABLE_NAME                     COLUMN_NAME          NUM_DISTINCT  NUM_NULLS LAST_ANALYZED        SAMPLE_SIZE HISTOGRAM       AVG_COL_LEN
    SL_JOURNAL_ENTRY_LINES         GL_BATCH_ID                     1          0 2010/12/28 22:00:51    259218636 NONE                      4

    It looks like that inserted data has always the same value for the partitioning key: it is expected that in this case the same partition is used because
    >
    For optimal data distribution, the following requirements should be satisfied:
    Choose a column or combination of columns that is unique or almost unique.
    Create multiple partitions and subpartitions for each partition that is a power of two. For example, 2, 4, 8, 16, 32, 64, 128, and so on.
    >
    See http://download.oracle.com/docs/cd/E11882_01/server.112/e16541/part_avail.htm#VLDBG1270.
    Edited by: P. Forstmann on 29 déc. 2010 09:06

  • What is the significance of Hash Partition ?

    Hi All,
    First time i am going to implement Hash partition as well as subpartition also.before implementing i have some query regarding that.
    1.What is the Max no. of partition or sub partition we can specify and default ?
    2.How do we know whch data comes under whch Hash partition ? i mean suppose incase of range partition based on specified range we are able to know what data comes under what partition. Same incase of List partition.
    Does anyone have any idea.
    Thanks n advance.
    Anwar

    1. Take a look here : http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/limits003.htm
    2. Take a look here : Re: Access to HASH PARTITION
    Nicolas.
    Correction of link
    Message was edited by:
    N. Gasparotto

  • How many Hash Partitions do I need?

    Is there a general rule, guideline or best practice that I can follow to derive the optimum number of hash partitions I should create for a table to be hash partitioned?
    I see that oracle recommends to consider partitioning if the table exceeds 2GB, so should I attempt to limit the size of the partitions to 2GB?
    Why is this recommendation based on number of bytes vs. number or rows? It seems to me that a 100m row table should be consdidered for partitioning regardless if it has 1gb of data or 5gb of data. Please advise as to why the number of bytes is consdered a key factor vs. number of rows.
    -Pat

    Thanks for the response. Actually I currently have a table with 1.1 billion rows and growing daily. This table is currently hash partitioned with 8 partitions. I'm thinking we should go to 64 partitions, but I really don't have any information for which to base this on other than a gut feel. Based on the access patterns for this table I do not believe that there is any real downside for creating 64 partitions, but before having the customer take the down time to go to 64 partitions it would be nice to have some basis for justifying the 64 partitions.

  • Design capture of hash partitioned tables

    Hi,
    Designer version 9.0.2.94.11
    I am trying to capture from a server model where the tables are hash partitioned. But this errors because Designer only knows about range partitions. Does anyone know how I can get Designer to capture these tables and their constraints?
    Thanks
    Pete

    Pete,
    I have tried all three "current" Designer clients 6i, 9i, and 10g, at the "current" revision of the repository (I can post details if interested). I have trawled the net for instances of this too, there are many.
    As stated by Sue, the Designer product model does not support this functionality (details can be found on ORACLE Metalink under [Bug No. 1484454] if you have access), if not, see excerpt below. It appears that at the moment ORACLE have no urgent plans to change this (the excerpt is dated as raised in 2001 and last updated in May 2004).
    Composite partitioning and List partitioning are equally affected.
    >>>>> ORACLE excerpt details STARTS >>>>>
    CDS-18014 Error: Table Partition 'P1' has a null String parameter
    'valueLessThan' in file ..\cddo\cddotp.cpp function
    cddotp_table_partition::cddotp_table_partition and line 122
    *** 03/02/01 01:16 am ***
    *** 06/19/01 03:49 am *** (CHG: Pri->2)
    *** 06/19/01 03:49 am ***
    Publishing bug, and upping priority - user is stuck hitting this issue.
    *** 09/27/01 04:23 pm *** (CHG: FixBy->9.0.2?)
    *** 10/03/01 08:30 am *** (CHG: FixBy->9.1)
    *** 10/03/01 08:30 am ***
    This should be considered seriously when looking at ERs we should be able to
    do this
    *** 05/01/02 04:37 pm ***
    *** 05/02/02 11:44 am ***
    I have reproduced this problem in 6.5.82.2.
    *** 05/02/02 11:45 am *** ESCALATION -> WAITING
    *** 05/20/02 07:38 am ***
    *** 05/20/02 07:38 am *** ESCALATED
    *** 05/28/02 11:24 pm *** (CHG: FixBy->9.0.3)
    *** 05/30/02 06:23 am ***
    Hash partitioning is not modelled in repository and to do so would require a
    major model change. This is not feasible at the moment but I am leaving this
    open as an enhancement request because it is a much requested facility.
    Although we can't implement this I think we should try to detect 'partition by
    hash', output a warning message that it is not supported and then ignore it.
    At least then capture can continue. If this is possible, it should be tested
    and the status re-set to '15'
    *** 05/30/02 06:23 am *** (CHG: FixBy->9.1)
    *** 06/06/02 02:16 am *** (CHG: Sta->15)
    *** 06/06/02 02:16 am RESPONSE ***
    It was not possible to ignore the HASH and continue processing without a
    considerable amount of work so we have not made any changes. The existing
    ERROR message highlights that the problem is with the partition. To enable
    the capture to continue the HASH clause must be removed from the file.
    *** 06/10/02 08:32 am *** ESCALATION -> CLOSED
    *** 06/10/02 09:34 am RESPONSE ***
    *** 06/12/02 06:17 pm RESPONSE ***
    *** 08/14/02 06:07 am *** (CHG: FixBy->10)
    *** 01/16/03 10:05 am *** (CHG: Asg->NEW OWNER)
    *** 02/13/03 06:02 am RESPONSE ***
    *** 05/04/04 05:58 am RESPONSE ***
    *** 05/04/04 07:15 am *** (CHG: Sta->97)
    *** 05/04/04 07:15 am RESPONSE ***
    <<<<< ORACLE excerpt details ENDS <<<<<
    I (like I'm sure many of us) have an urgent immediate need for this sort of functionality, and have therefore resolved to looking at some form of post process to produce the required output.
    I imagine that it will be necessary to flag the Designer meta-data content and then manipulate the generator output once it's done its "raw" generation as a RANGE partition stuff (probably by using the VALUE_LESS_THAN field as its mandatory, and meaningless for HASH partitions!).
    An alternative would be to write an API level generator for this using the same flag, probably using PL/SQL.
    If you have (or anyone else has) any ideas on this, then I'd be happy to share them to see what we can cobble together in the absence of an ORACLE interface to their own product.
    Peter

  • Hash Partitioning

    Hi All,
    Does hash partitioning always use the same hashing function, and will it always produce the same result if a new table is created with the same number of hash partitions hashed on the same field?
    For example, I have to join a multi-million record data set to table1 this morning. table1 is hash partitioned on row_id into 32 partitions.
    If I create a temp table to hold the data I want to join and hash partition it likewise into 32 partitions on row_id, will any given record from partition number N in my new table find its match in partition number N of table?
    If so, that would allow us to join one partition at a time which performs exponentially better in the resource-contested environment.
    I hope you can help.

    Using 10gR2
    Partition pruning does occur when joined to a global temporary table with hash partitioning. Providing the parimary key on the global temp table is the key used for hashing the relational table:
    SQL> create table t (
      2    a number)
      3    partition by hash(a) (
      4      partition p1 ,
      5      partition p2 ,
      6      partition p3 ,
      7      partition p4
      8    )
      9  /
    Table created.
    SQL>
    SQL> alter table t add (constraint t_pk primary key (a)
      2  using index local (partition p1_idx
      3                   , partition p2_idx
      4                   , partition P3_idx
      5                   , partition p4_idx)
      6  )
      7  /
    Table altered.
    SQL> insert into t (a) values (1);
    1 row created.
    SQL> insert into t (a) values (2);
    1 row created.
    SQL> insert into t (a) values (3);
    1 row created.
    SQL>  insert into t (a) values (4);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL>
    SQL> create global temporary table tm (a number)
      2  /
    Table created.
    SQL> insert into tm (a) values (2);
    1 row created.
    SQL> set autotrace traceonly explain
    SQL> select tm.a from tm, t
      2  where tm.a = t.a
      3  /
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=26)
       1    0   NESTED LOOPS (Cost=2 Card=1 Bytes=26)
       2    1     TABLE ACCESS (FULL) OF 'TM' (TABLE (TEMP)) (Cost=2 Card=
              1 Bytes=13)
       3    1     PARTITION HASH (ITERATOR) (Cost=0 Card=1 Bytes=13)
       4    3       INDEX (UNIQUE SCAN) OF 'T_PK' (INDEX (UNIQUE)) (Cost=0
               Card=1 Bytes=13)As you can see from the above, a full scan was performed on the global temp table, but partition pruning occured on TM. So, in theory, whatever data you load the global temp table with, will be matched to the partition.
    P;

  • Hash Partition on non unique column

    I have Dim and fact tables expected volumns early growth 250 million rows.
    I have Hash partitioned Dim table where i have unique Key but on Fact table i do not have a single unique key column(fact is child of Dim ).
    Since fact table doesn't has single unique column,how to do hash partition on Fact Table ?
    Need advice.

    Hi there, I have similar kind of a situation, need your suggestions.
    we are using the Oracle version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    We have a HR data approximately of about 270 mill for 100,000 persons in an SAP module, & we need to load this data into an oracle table.
    This is an accumulated data for the past 2 yrs starting from Jan 2011. & the assumpitions are the data that will be incrementally loaded every day is about 600,000.
    The data granularity is available at the fraction of the day known as TIME_TYPE for a given day.
    for example an person can have multiple records on a given day, depending upon the TIME_TYP.
    sample data:
    Pers_ID     Payroll_date     Time_Type      Day_Hrs
    1960     1-Jan-11     Maximum Vacation     4
    1960     1-Jan-11     Vacation Quota Maximum     2
    1960     1-Jan-11     Maximum Sick     2
    1960 2-Jan-11     Paid Eligible OT Hrs     3
    1960     2-Jan-11     Paid Hours     3
    1960     2-Jan-11     WW Eligible OT Hrs     2
    1960     5-Jan-11     Daily Overtime Hours     2
    1960     5-Jan-11     Weekly Additional Hours     2
    1960      5-Jan-11     Personal Quota Balance     2
    1960     5-Jan-11     Total Overtime Hours     2
    The above data is of an individual person, his time spent on a particular day over a 3 day period.
    My question is how best I can design the table (partitioned table), so that the data loading process can be fast (for the initial load as well as the daily incremental load)
    also we have lot of reporting on this table, few reports such as total no. of hrs utilized by a particular employee, whats the most time_typ used by a group of employees, & so on.
    please let me know your suggestions & thoughts.
    Edited by: user3084749 on Feb 5, 2013 1:46 PM

Maybe you are looking for