IOT or Hash partition

Hi all,
I want to insert large data into a table to be retreived later using a key column (like emp no).
To the performance point of view, which is more efficient: IOT (Index Organized Table) or Hash Partition ?

I highly appreciate your time Justin. Your explanation clarified many things to me.
However, I have small notes on your comments:
Firt:
<<IOT's tend to be useful when you have thin, tall tables (many rows, few columns) where you always want to retrieve all the rows.>>
Regarding this claim, I referred to the following sources:
1. Sybex-Oracle9i Performance Tuning book
"If you access the table using its primary key, an IOT will return the rows more quickly than a traditional table."
2. http://www.tlingua.com/articles/iot.html
For single row fetch,"IOTs could provide a substantial performance gain as well as reducing the demand for disk drives"
For Index Range Scans,"IOTs significantly outperform the standard B-tree/table model during index range scans."
3. Oracle9i Database Administrator’s Guide Release 2 (9.2)
"Index-organized tables are particularly useful when you are using applications that must retrieve data based on a primary key."
As you can see Justin, none of them mentioned the thin-tall-table fact. Did you obtain it from practical experience or from some source?
Also they all showed that IOT is most useful when retreiving based on PK.
Second:
"In general, partitioning works best when you are doing set-based processing where you can use partition elimination to concentrate on a particular subset of the data."
In Sybex-Oracle9i Performance Tuning book it is stated that "Hash partitions work best when applications retrieve the data from the partitioned table via the unique key. Range lookups on hash partitioned tables derive no benefit from the partitioning.".
I can see there is some confilict, isn't it?
Thanks in advance.

Similar Messages

  • 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

  • Modify HUGE HASH partition table to RANGE partition and HASH subpartition

    I have a table with 130,000,000 rows hash partitioned as below
    ----RANGE PARTITION--
    CREATE TABLE TEST_PART(
    C_NBR CHAR(12),
    YRMO_NBR NUMBER(6),
    LINE_ID CHAR(2))
    PARTITION BY RANGE (YRMO_NBR)(
    PARTITION TEST_PART_200009 VALUES LESS THAN(200009),
    PARTITION TEST_PART_200010 VALUES LESS THAN(200010),
    PARTITION TEST_PART_200011 VALUES LESS THAN(200011),
    PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE)
    CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR, LINE_ID);
    Data: -
    INSERT INTO TEST_PART
    VALUES ('2000',200001,'CM');
    INSERT INTO TEST_PART
    VALUES ('2000',200009,'CM');
    INSERT INTO TEST_PART
    VALUES ('2000',200010,'CM');
    VALUES ('2006',NULL,'CM');
    COMMIT;
    Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
    How do I change the current partition of the table from HASH partition to RANGE partition and a sub-partition (HASH) without losing the data and existing indexes?
    The table after restructuring should look like the one below
    COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
    CREATE TABLE TEST_PART(
    C_NBR CHAR(12),
    YRMO_NBR NUMBER(6),
    LINE_ID CHAR(2))
    PARTITION BY RANGE (YRMO_NBR)
    SUBPARTITION BY HASH (C_NBR) (
    PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
    PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
    PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
    PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
    CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
    Pls advice
    Thanks in advance

    Sorry for the confusion in the first part where I had given a RANGE PARTITION instead of HASH partition. Pls read as follows;
    I have a table with 130,000,000 rows hash partitioned as below
    ----HASH PARTITION--
    CREATE TABLE TEST_PART(
    C_NBR CHAR(12),
    YRMO_NBR NUMBER(6),
    LINE_ID CHAR(2))
    PARTITION BY HASH (C_NBR)
    PARTITIONS 2
    STORE IN (PCRD_MBR_MR_02, PCRD_MBR_MR_01);
    CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
    Data: -
    INSERT INTO TEST_PART
    VALUES ('2000',200001,'CM');
    INSERT INTO TEST_PART
    VALUES ('2000',200009,'CM');
    INSERT INTO TEST_PART
    VALUES ('2000',200010,'CM');
    VALUES ('2006',NULL,'CM');
    COMMIT;
    Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
    How do I change the current partition of the table from hash partition to range partition and a sub-partition (hash) without losing the data and existing indexes?
    The table after restructuring should look like the one below
    COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
    CREATE TABLE TEST_PART(
    C_NBR CHAR(12),
    YRMO_NBR NUMBER(6),
    LINE_ID CHAR(2))
    PARTITION BY RANGE (YRMO_NBR)
    SUBPARTITION BY HASH (C_NBR) (
    PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
    PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
    PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
    PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
    CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
    Pls advice
    Thanks in advance

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

  • Best Way to Load Data in Hash Partition

    Hi,
    I have partitioning by Hash on a Large Table of 5 TB. We have to load Data say more than 500GB daily on that table from ETL.
    What is the best way to Load data into that Big Table which has hash Partition .
    Regards
    Sahil Soni

    Do you have any specific requirements to match records to lookup tables or it just a straight load - that is an insert?
    Do you have any specific performance requirements?
    The easiest and fastest way to load data into Oracle is via external file and parallel query/parallel insert. Remember that parallel DML is not enabled by default and you have to do so via alter session command. You can leverage multiple CPU cores and direct path operation to perform the load.
    Assuming your database is on a linux/unix server - you could NFS load the file if it is on a remote system, but then you will be most likely limited by network transfer speed.

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

  • 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

  • Can we compress hash partitioned table in 9.2

    Hi
    Can we compress the hash partitioned table? How to check the compression? Is there any way to check for the partition size after compression?
    Thanks

    hi
    go through below link
    hope it will help you.
    http://www.dbazine.com/oracle/or-articles/foot6
    http://www.google.ae/search?hl=en&q=compressed+hash+partition+++oracle+9i&meta=
    also check in google seconed point... Table compression do and don't.
    hope this helps
    Taj.

  • [Need help] Would Hash partitioning preferable here?

    I have idea about Hash partitioning.
    Now in my case volume of data is very high while search criteria on that table is dynamically coming from GUI.
    There is search criteria for date range but date filed is dynamically decided.
    In database terminology, different queries with different date type columns in where clause are executed based on the search criteria selected from GUI.
    While using Range partition, we are allowed to use only one date column so query that do not use this date column would not get benefit from partitioning.
    so i feel i can't go for range partitioning.
    So here i need suggestion that would Hash partitioning would help in this case ?

    The only reason i have put my query in this forum is
    that here i found instant answers.So seeing that it is obvious that the only right way for such question is to divert them to the right forum and not provide any answer. Otherwise people start to become ignorant to polite requests.
    And this forum is all about "feedback and suggestion"
    again i am also asked for suggestions so i feel i am
    right here.Are you blind or unable to read? Already 2 users asked you to post in more appropriate forum and when you open this forum there is following text just after the forum title:
    "Use this forum for feedback about OTN programs, Web site content, and systems - product-related questions cannot be answered here. "
    Is this not enough?
    Gints Plivna
    http://www.gplivna.eu

  • 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

  • A question on Hash Partition

    Hi,
    I'm facing a proble.My table has 16 partition and all the partitions are hash partitioned.
    But i found only one partition is being populated heavily rather than the other ones it near to 3-4 times of other partitions.
    My database version is 9i.
    Can anyone suggest me in this.
    Thanks in advance
    say my table structure like this ..
    CREATE TABLE TAB1(COL1 NUMBER,COL2 VARCHAR2(10),COL3 VARCHAR(10));
    PARTITON BY HASH(COL3)
    PARTITION P1 TABLESPACE TS1
    PARTITION P16 TABLESPACE TS1
    And i have only one index i.e
    create index indx on tab1(col1,col2,col3);
    Edited by: bp on Feb 17, 2009 4:40 AM

    bp wrote:
    My table has near 1000 million data as it is a history table.
    Partition_key (col3) has distinct 926 values.
    One thing is sure as the cardinality of col3 is very low in comparison with the amount of data in the table data is not evenly distributed.
    Now another problem is one value (say col3 =1) of col3 from the 926 distinct values only goes to p16 partition but surprisingly this is not going to any other partitons.We have no other objects on this table to control the flow of data between partitions.
    I really counld not find any reason of such behaviour.I'm not sure if I understand what you attempt to describe. You mean to say that in partition p16 there is only one value of COL3 found, and this partition holds more rows than the other partitions. Whereas the remaining partitions cover more COL3 values but hold less rows.
    A single COL3 value always maps to the same hash value, so if you don't change the number of hash partitions and cause a "rebalancing" the same value should always map to the same partition (it still does after rebalancing but it might be a different partition now). You might be unlucky that there is currently no other value than "1" that maps to the same hash value. You could think about adding/removing hash partitions to change the distribution of the rows, but this could be a quite expensive operation given the amount of data in your table.
    Are these 926 distinct values evenly distributed or is the data skewed in this column? Your description suggests that the data is skewed if a single value in a partition holds more rows than the other partitions that cover multiple values.
    You could do a simple
    SELECT COUNT(*), COL3
    FROM TAB
    GROUP BY COL3
    ORDER BY COUNT(*) DESC
    to find this out, or check the column statistics if there is an histogram on that column describing the column skew. If that query takes too long use a SAMPLE size (...FROM TAB SAMPLE (1)...) indicates a 1 percent sampling. You need to scale the counts then by the sampling factor.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

Maybe you are looking for