Ask hash algortihm in partitioning table by hash

hi all,
I wanted to ask about the hash algortihm in partitioning table by hash .How hash algorithm evenly distribute the data on each partisi??anybody know??

A simple calculation probably isn't going to be possible. The problem is that a simple hash function is unlikely to produce the nearly uniform data distribution and a function that produces the nearly uniform data distribution is unlikely to be particularly simple to compute. ORA_HASH has to balance the desire to be quick to compute against the desire to produce nearly uniform data. I don't know what algorithm Oracle picked or where relatively they made the trade off-- I expect that the algorithm may well change across releases.
Conceptually, though, if you had a perfect hash algorithm, it would provide a perfect "fingerprint" of the data and any valid input would have an equal a priori probability of being mapped anywhere in the valid output set-- just like a perfect encryption algorithm generates encrypted output that would appear totally random. If you can look at a piece of data and know that its hash was more likely to be in one part of the output set than another, that would mean that there would be an opportunity to attack the hash-- you could probabilistically reconstruct data if you knew the hash.
If you assume that ORA_HASH is a perfect hash (it probably isn't, but it's probably close enough for this analysis so long as the range is a power of 2), then for any given input, any output is equally likely. If you create a hash partitioned table with 8 partitions, that basically equates to asking ORA_HASH to generate a hash that is between 0 and 7 and puts the data in whichever partition comes out. Since each value is equally likely to be in any of the partitions, you'd expect that the data would be equally distributed. Unless of course there is a lot of repetition in the values in the column you are partitioning by-- the hash for two identical values is identical, so that sort of repetitive data would cause the data distribution to be unequal.
To take a simplistic example, let's assume you were hashing numbers and let's say you have 8 partitions. The simplest possible hash algorithm would be "mod 8". That is, if you insert a value x, insert it into the partiition (x mod 8). If x = 2, 2 mod 8 = 2, so put it in partition 2. If x = 10, 10 mod 8 = 2, so put it in partition 2. If x = 14, 14 mod 8 = 6 so put it in partition 6. If the numeric values that you insert are uniformly distributed (not unlikely if you're dealing with large amounts of data and very likely if you're dealing with sequence-generated primary keys), all 8 partitions will be roughly equally full.
Of course, this algorithm is far from perfect-- if all the data you are inserting is a power of 2, for example, then all the odd partitions would be empty and the even numbered partitions would be full. ORA_HASH needs to be quite a bit more complex than a simple mod N in order to provide more uniform mapping even if there are patterns in the input.
Justin

Similar Messages

  • 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

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

  • 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

  • Need to uncompress a hash partitioned table

    I am working on oracle 11.1.0.7 database on solaris.
    We had issues loading data into compressed tables, so we are trying to uncompress the tables and their partitions.
    When I tried uncompressing a hash partitioned table, I am getting this error
    SQL> alter table sample move partition SYS_1 nocompress;
    alter table sample move partition SYS_1 nocompress
    ERROR at line 1:
    ORA-14260: incorrect physical attribute specified for this partition
    I am able to move the table, it is just the nocompress option which doesn;t work.
    SQL> alter table sample move partition SYS_1;
    Table altered.
    Can't we uncompress a hash partitioned table which is compressed?

    You have to do it in two steps
    alter table sample modify partition SYS_1 nocompress;
    alter table sample move partition SYS_1;Best regards
    Maxim

  • Altering Hash Partition table

    Hi ,
    version: 10gR2
    I have a table that built with 5 hash partitions.
    Since oracle recommand that hash partition table should built with power of two
    (e.g: 2,4,8,16...) partition , i would like to rebuilt the table with 8 hash partition.
    Its a table that contain more then 100 milion records and its size is more then 2 giga.
    I understand that there isnt any: alter table .. for this kind of issue.
    Please advice me what is the best way to do this task.
    Thanks.

    use
    ALTER TABLE <table> SPLIT PARTITION <partition> AT
    (<value>) INTO ( PARTITION <partition1> TABLESPACE <tbs> , PARTITION <partition2> TABLESPACE <tbs>);to divide your partitions
    bye
    aldo

  • Drop partitions in HASH partitioned table

    SELECT * FROM product_component_version
    NLSRTL      10.2.0.4.0     Production
    Oracle Database 10g Enterprise Edition      10.2.0.4.0     64bi
    PL/SQL      10.2.0.4.0     Production
    TNS for Solaris:      10.2.0.4.0     ProductionI have a table which is partitioned by HASH into several partitions. I would like to remove them all the same way I can DROP partitions in a LIST or RANGE partitioned tables.
    I COALESCE-d my table until it remained with only one partition. Now I've got a table with one HASH partition and I would like to remove it and to end up with unpartitioned table.
    How could it be accomplished?
    Thank you!

    Verdi wrote:
    I have a table which is partitioned by HASH into several partitions. I would like to remove them all the same way I can DROP partitions in a LIST or RANGE partitioned tables.
    I COALESCE-d my table until it remained with only one partition. Now I've got a table with one HASH partition and I would like to remove it and to end up with unpartitioned table.
    How could it be accomplished?
    You cannot turn a partitioned table into a non-partitioned table, but you could create a replacement table (including indexes etc.) and then use the 'exchange partition' option on the partitioned table. This will modify the data dictionary so the data segments for the partition exchange names with the data segments for the new table - which gives you a simple table, holding the data, in minimum time and with (virtually) no undo and redo.
    The drawback to this method is that you have to sort out all the dependencies and privileges.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Author: <b><em>Oracle Core</em></b>

  • Effect of appending  standard internal table to hashed one ?

    hi,
    in my main program i have an internal table called NAST which is hashed. i call a function module which returns an internal table called xNAST, whose records i append to NAST. since i dealt with TABLES tab of FM, i had to receive this xNAST of type standard table (and not hashed).
    i appended the lines of xNAST to NAST using INSERT statement.
    Now at one point, i have a statement,
    READ TABLE *nast INTO *xxx WITH KEY mmm = '100'.
    so when i inserted the records into NAST from xNAST, they r automatically hashed, right ? and this statement will work without any issues ?
    thks

    Hello,
    WITH KEY
    For hashed tables, the hash algorithm is used if the specified search key includes the table key. Otherwise the search is linear. The addition BINARY SEARCH is not permitted for hashed tables.
    Alternative
    WITH TABLE KEY
    Effect:
    Each component of the table key must listed either directly as comp_name1 comp_name2 ..., or as a bracketed character-type data object name1 name2 ..., which contains the name of the component when the statement is executed (before release 6.10 in upper case). If name contains spaces only, this component specification is ignored when the statement is executed. A data object must be assigned to each component, which is compatible with or can be converted to the data type of the component. The first found line of the table is read, for which the values in the columns of the table key match the values in the assigned data objects dobj1 dobj2 .... If necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison.
    The different table types are accessed as follows:
    standard tables are searched using a linear search.
    sorted tables are searched using a binary search.
    For hashed tables, the hash algorithm is used.
    Regards.

  • How to identify Which table is hashed

    DB : 10.2.0.3
    OS : AIX 6.1
    I have a query that is using hash join. Below is the query and execution plan.
    SELECT  tj.jq_id jq_id        ,
            tj.ref_key1 ref_key1  ,
            tj.ref_key3 ref_key3  ,
            tj.ref_key2 ref_key2  ,
            tj.ref_key4 ref_key4  ,
            th.rcp_id rcp_id      ,
            th.tp_id tp_id        ,
            th.transmittal_no trno,
            status_flag           ,
            tj.ref_key5 ref_key5  ,
            TO_CHAR(tj.date_finished, 'DD-MM-YYYY HH:MI:SS PM') finished
    FROM    transmittal_job_queues tj,
            transmittal_headers th
    WHERE   tj.job_type_id          = :1
            AND tj.expiration_date IS NULL
            AND th.expiration_date IS NULL
            AND tj.ref_key1         = th.th_id
            AND ref_key2           IS NULL
            AND tj.status_flag     IN ('R', 'A')
    ORDER BY status_flag,
            th.tp_id    ,
            tj.effective_date DESC
    PLAN_TABLE_OUTPUT
    Plan hash value: 1402657176
    | Id  | Operation           | Name                   | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |                        | 18734 |  1335K|       | 10347   (2)| 00:02:05 |
    |   1 |  SORT ORDER BY      |                        | 18734 |  1335K|  3272K| 10347   (2)| 00:02:05 |
    |*  2 |   HASH JOIN         |                        | 18734 |  1335K|  1184K| 10022   (2)| 00:02:01 |
    |*  3 |    TABLE ACCESS FULL| TRANSMITTAL_JOB_QUEUES | 18570 |   961K|       |  1623   (2)| 00:00:20 |
    |*  4 |    TABLE ACCESS FULL| TRANSMITTAL_HEADERS    |  1046K|    19M|       |  6739   (2)| 00:01:21 |
    Query Block Name / Object Alias (identified by operation id):
       1 - SEL$1
       3 - SEL$1 / TJ@SEL$1
       4 - SEL$1 / TH@SEL$1
    Predicate Information (identified by operation id):
       2 - access("TH"."TH_ID"=TO_NUMBER("TJ"."REF_KEY1"))
       3 - filter(("TJ"."STATUS_FLAG"='A' OR "TJ"."STATUS_FLAG"='R') AND
                  "TJ"."JOB_TYPE_ID"=TO_NUMBER(:1) AND "REF_KEY2" IS NULL AND "TJ"."EXPIRATION_DATE" IS NULL)
       4 - filter("TH"."EXPIRATION_DATE" IS NULL)
    Column Projection Information (identified by operation id):
       1 - (#keys=3) "STATUS_FLAG"[VARCHAR2,1], "TH"."TP_ID"[NUMBER,22],
           INTERNAL_FUNCTION("TJ"."EFFECTIVE_DATE")[7], "TJ"."JQ_ID"[NUMBER,22],
           "TJ"."REF_KEY1"[VARCHAR2,20], "TJ"."REF_KEY3"[VARCHAR2,20], "TJ"."REF_KEY2"[VARCHAR2,20],
           "TJ"."REF_KEY4"[VARCHAR2,90], "TH"."RCP_ID"[NUMBER,22], "TJ"."REF_KEY5"[VARCHAR2,20],
           "TH"."TRANSMITTAL_NO"[NUMBER,22], TO_CHAR(INTERNAL_FUNCTION("TJ"."DATE_FINISHED"),'DD-MM-YYYY
           HH:MI:SS AM')[22]
       2 - (#keys=1) "TJ"."JQ_ID"[NUMBER,22], "TJ"."REF_KEY1"[VARCHAR2,20],
           "REF_KEY2"[VARCHAR2,20], "TJ"."REF_KEY3"[VARCHAR2,20], "TJ"."REF_KEY4"[VARCHAR2,90],
           "TJ"."REF_KEY5"[VARCHAR2,20], "TJ"."STATUS_FLAG"[VARCHAR2,1], "TJ"."DATE_FINISHED"[DATE,7],
           "TJ"."EFFECTIVE_DATE"[DATE,7], "TH"."RCP_ID"[NUMBER,22], "TH"."TP_ID"[NUMBER,22],
           "TH"."TRANSMITTAL_NO"[NUMBER,22]
       3 - "TJ"."JQ_ID"[NUMBER,22], "TJ"."REF_KEY1"[VARCHAR2,20], "REF_KEY2"[VARCHAR2,20],
           "TJ"."REF_KEY3"[VARCHAR2,20], "TJ"."REF_KEY4"[VARCHAR2,90], "TJ"."REF_KEY5"[VARCHAR2,20],
           "TJ"."STATUS_FLAG"[VARCHAR2,1], "TJ"."DATE_FINISHED"[DATE,7], "TJ"."EFFECTIVE_DATE"[DATE,7]
       4 - "TH"."TH_ID"[NUMBER,22], "TH"."RCP_ID"[NUMBER,22], "TH"."TP_ID"[NUMBER,22],
           "TH"."TRANSMITTAL_NO"[NUMBER,22]
    46 rows selected.
    sys@TESTDB> select count(*) from TRANSMITTAL_JOB_QUEUES;
      COUNT(*)
        586928
    sys@TESTDB> select count(*) from TRANSMITTAL_HEADERS;
      COUNT(*)
       1314095
    sys@TESTDB> select sum(bytes)/1024/1024 from dba_segments where segment_name='TRANSMITTAL_JOB_QUEUES'
    SUM(BYTES)/1024/1024
                    65.5
    sys@TESTDB> select sum(bytes)/1024/1024 from dba_segments where segment_name='TRANSMITTAL_HEADERS';
    SUM(BYTES)/1024/1024
                     271I wanted to know, which table is hashed in memory among "TRANSMITTAL_JOB_QUEUES" & "'TRANSMITTAL_HEADERS" ?

    Thanks, but is a thumb rule that smaller table will be hashed ?
    Also, how can i be sure by seeing the executing plan that smaller table is hashed ?

  • Hash keys and the table Pagesize.

    Hi,
    We look to be running into some performance issues running on TimesTen 5.1.25, and feel that we may be running into a problem of having the hash size set too small, as we are seeing lock contention on the index hash values.
    The documentation says that the hash size can only be changed by recreating the table, however the documentation also states, that to resize a hash index, the "ALTER TABLE owner.name SET PAGES = CURRENT;" statement can be used.
    Could you please explain which of these statements is correct, and whether this may be leading to greater lock contention, or whether we should be looking elsewhere.
    Regards,
    mgh

    Yes, an undersized hash index can lead to performance issues and excessive contention. One should always size the index based on the formula PAGES = (maximum number of rows) / 256. The ttXactAdmin utility can be used to investigate lock and latch contention on the hash index. The degree of impact depends on the ratio of actual rows to expected rows. If A is the actual number of rows and H is the number of rows for which the hash index has been sized then the ratio A / H should always be <= 1. If it exceeds 1 by a small amount (e.g. 1.1) then the impact is small but once it exceeds one by a significant amount e.g. 1.5 upwards then the impact increases very quickly.
    In 5.1, the only way to resize the index is by unloading the table data to a file (ttBulkCp), dropping the table, re-creating with the 'correct' hash index sizing and then reloading the data (ttBulkCp).
    The ability to resize the index using ALTER TABLE was introduced in TimesTen 6.0.
    Since this is an obvious and well known source of performance problems and increased contention I would recommend that you try to eliminate this issue in the first instance and see if that improves things. If it does not then you can move on to investigate other areas.
    Chris

  • How to delete the data from partition table

    Hi all,
    Am very new to partition concepts in oracle..
    here my question is how to delete the data from partition table.
    is the below query will work ?
    delete from table1 partition (P_2008_1212)
    we have define range partition ...
    or help me how to delete the data from partition table.
    Thanks
    Sree

    874823 wrote:
    delete from table1 partition (P_2008_1212)This approach is wrong - as Andre pointed, this is not how partition tables should be used.
    Oracle supports different structures for data and indexes. A table can be a hash table or index organised table. It can have B+tree index. It can have bitmap indexes. It can be partitioned. Etc.
    How the table implements its structure is a physical design consideration.
    Application code should only deal with the logical data structure. How that data structure is physically implemented has no bearing on application. Does your application need to know what the indexes are and the names of the indexes,in order to use a table? Obviously not. So why then does your application need to know that the table is partitioned?
    When your application code starts referring directly to physical partitions, it needs to know HOW the table is partitioned. It needs to know WHAT partitions to use. It needs to know the names of the partitions. Etc.
    And why? All this means is increased complexity in application code as this code now needs to know and understand the physical data structure. This app code is now more complex, has more moving parts, will have more bugs, and will be more complex to maintain.
    Oracle can take an app SQL and it can determine (based on the predicates of the SQL), which partitions to use and not use for executing that SQL. All done totally transparently. The app does not need to know that the table is even partitioned.
    This is a crucial concept to understand and get right.

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

  • Create Partition table using CTAS

    Hi there,
    Is it possible to create a duplicate partition table from a existing partition table using CTAS method? If yes, could you explain how ?If No , how to make a duplicate partition table?
    Thanks in advance?
    Rajesh Marath

    Easily:
    conn / as sysdba
    CREATE TABLESPACE part1
    DATAFILE 'c:\temp\part01.dbf' SIZE 50M
    BLOCKSIZE 8192
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
    SEGMENT SPACE MANAGEMENT AUTO
    ONLINE;
    CREATE TABLESPACE part2
    DATAFILE 'c:\temp\part02.dbf' SIZE 50M
    BLOCKSIZE 8192
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
    SEGMENT SPACE MANAGEMENT AUTO
    ONLINE;
    CREATE TABLESPACE part3
    DATAFILE 'c:\temp\part03.dbf' SIZE 50M
    BLOCKSIZE 8192
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
    SEGMENT SPACE MANAGEMENT AUTO
    ONLINE;
    ALTER USER uwclass QUOTA UNLIMITED ON part1;
    ALTER USER uwclass QUOTA UNLIMITED ON part2;
    ALTER USER uwclass QUOTA UNLIMITED ON part3;
    conn uwclass/uwclass
    CREATE TABLE hash_part (
    prof_history_id  NUMBER(10),
    person_id        NUMBER(10) NOT NULL,
    organization_id  NUMBER(10) NOT NULL,
    record_date      DATE NOT NULL,
    prof_hist_comments VARCHAR2(2000))
    PARTITION BY HASH (prof_history_id)
    PARTITIONS 3
    STORE IN (part1, part2, part3);
    CREATE TABLE duplicate_hash_part
    PARTITION BY HASH (prof_history_id)
    PARTITIONS 3
    STORE IN (part1, part2, part3) AS
    SELECT * FROM hash_part;Follow the same logic for list and range partitions

  • Partition Tables - issue

    I have lots of partitioned tables in my schema , the requirement is to identify the current partition of the table.
    Let me explain this with an eg.
    Lets say I have a table T , with 24 partitions .. starting for Jan -04 to Dec-05. Now , my current partition is Dec-04. Partition w.r.t sysdate
    How can I achive this by querying the data dictionary

    120196, I think you are mistaken. There is no such thing as "current" partition. Oracle offers 3 types of partition, i.e. range partitioning, hash partitioning and composite partitioning. For all 3 types of partitions, you specify the column you want to partition on. Then, then when you insert/update/delete rows, Oracle does "partition elimination" (if the columns you partitioned is part of the query), which greatly improves performance. So, the partition you deal with (I guess this is what you mean by current partition) is the same one your row has to deal with. Hope this makes it clearer and gives you a 10,000 foot view. There is lots more to partitioning.
    -Raj Suchak
    [email protected]

  • Problem of full table scan on a partitioned table

    hi all
    There is a table called "si_sync_operation" that have 171040 number of rows.
    I partitioned that table into a new table called "si_sync_operation_par" with 7 partitoins.
    I issued the following statements
    SELECT * FROM si_sync_operation_par.
    SELECT * FROM si_sync_operation.
    The explain plan show that the cost of the first statement is 1626 and that of the second statments is 1810.
    The "cost" of full table scan on partitioned table is lower than the that of non-partitioned table.That's fine.
    But the "Bytes" of full table scan on partitioned table is 5761288680 and that of the non-partitioned table is 263743680.
    Why full table scan on partitioned table access more bytes than non-partitioned table?
    And how could a statment that access more bytes results a lower cost?
    Thank u very much

    As Hemant metioned bytes reported are approximate number of bytes. As far as Cost is concerned, according to Tom its just a number and we should not compare queries by their cost. (search asktom.oracle.com for more information)
    SQL> drop table non_part purge;
    Table dropped.
    SQL> drop table part purge;
    Table dropped.
    SQL>
    SQL> CREATE TABLE non_part
      2        (id  NUMBER(5),
      3         dt    DATE);
    Table created.
    SQL>
    SQL> CREATE TABLE part
      2        (id  NUMBER(5),
      3         dt    DATE)
      4         PARTITION BY RANGE(dt)
      5         (
      6         PARTITION part1_jan2008 VALUES LESS THAN(TO_DATE('01/02/2008','DD/MM/YYYY')),
      7         PARTITION part2_feb2008 VALUES LESS THAN(TO_DATE('01/03/2008','DD/MM/YYYY')),
      8         PARTITION part3_mar2008 VALUES LESS THAN(TO_DATE('01/04/2008','DD/MM/YYYY')),
      9         PARTITION part4_apr2008 VALUES LESS THAN(TO_DATE('01/05/2008','DD/MM/YYYY')),
    10         PARTITION part5_may2008 VALUES LESS THAN(TO_DATE('01/06/2008','DD/MM/YYYY'))
    11       );
    Table created.
    SQL>
    SQL>
    SQL> insert into non_part select rownum, trunc(sysdate) - rownum from dual connect by level <= 140;
    140 rows created.
    Execution Plan
    Plan hash value: 1731520519
    | Id  | Operation                     | Name | Rows  | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
    |   1 |  COUNT                        |      |       |            |          |
    |*  2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
    |   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter(LEVEL<=140)
    SQL>
    SQL> insert into part select * from non_part;
    140 rows created.
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> commit;
    Commit complete.
    SQL>
    SQL> set line 10000
    SQL> set autotrace traceonly exp
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  3080 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> exec dbms_stats.gather_table_stats(user, 'non_part');
    PL/SQL procedure successfully completed.
    SQL> exec dbms_stats.gather_table_stats(user, 'part');
    PL/SQL procedure successfully completed.
    SQL>
    SQL>
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  1540 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  1540 |     3   (0)| 00:00:01 |
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  1540 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    SQL>After analyzing the tables, notice that the Bytes column has changed value

Maybe you are looking for

  • How come my comments are visible in iweb but not on published site?

    I published my site (after many frustrating attempts and publish errors) and had allowed comments. I made a blog entry and published to .mac and found out from a friend that that particular entry didn't have an option to add a comment. I tried to rep

  • Returning Connections to Pool

    Does anyone know how long iAS 6.5 SP1 (on W2K) takes to return connections to the pool after close() is called? Does the app server wait until the end of a transaction to return connections to the pool, even if close() was called earlier?

  • EPM single Managed Server for all applicatoins vs EPM multiple managed servers

    Hi Guys There are two options of setting my managed serves in weblogic 1 - All application comes under single managed server. 2 - Every application have it's own managed server. (Please correct me if there are other ways to other than this.) What are

  • Characreset Conversion Problem In Export

    I have created a Database on Oracle8i ver.8.1.5 on Novell using WE8ISO8859P1 chracherset. Because I use this database to store 8 Bit ASCII data. My application is working fine. But when I export the data using export utility on Novell Server it conve

  • Package parametеr "overwrite records with match key" (BPC 10)

    Hi all. We load data from DSO in SAP BW to BPC. We use the /CPMB/LOAD_INFOPROVIDER process chain for that. In the package we use the "overwrite records with match key" parameter for the "Handling of records in target" setting. But if there's no data