Partition/Subpartition by hash

create table demo_table (
ID number(9) primary key,
Col1 varchar2(10) not null,
Col2 varchar2(10) not null,
Col3 varchar2(10)
partition by hash(col1)
subpartition by hash (col2)
partitions 4 subpartitions 4;
Now I would expect there to be a total of 16 sub-partitions. However I only get seven. How do I tell it to do all four partitions with 4 subpartitions instead of just the first one?
select * from user_segments where segment_name = 'DEMO_TABLE';
SEGMENT_NAME | PARTITION_NAME | SEGMENT_TYPE
DEMO_TABLE | SYS_SUBP50061 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50062 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50063 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50064 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50065 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50066 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50067 | TABLE SUBPARTITION

11.2.0.3.0
Using the following insert statements...
insert into demo_table values (1,'abc','def',null);
insert into demo_table values (2,'abc','ghi',null);
insert into demo_table values (3,'abc','jkl',null);
insert into demo_table values (4,'abc','mno',null);
insert into demo_table values (5,'pqr','abc',null);
insert into demo_table values (6,'pqr','def',null);
insert into demo_table values (7,'pqr','ghi',null);
insert into demo_table values (8,'pqr','mno',null);
insert into demo_table values (9,'stu','abc',null);
insert into demo_table values (10,'stu','def',null);
insert into demo_table values (11,'stu','ghi',null);
insert into demo_table values (12,'stu','mno',null);
insert into demo_table values (13,'vwz','abc',null);
insert into demo_table values (14,'vwz','def',null);
insert into demo_table values (15,'vwz','ghi',null);
insert into demo_table values (16,'vwz','mno',null);
I get one partition with 8 rows, one with 0 rows, and two with 4 rows. The first partition's four subparitions have 5,0,0,3 rows. The other tables only have one subpartition even after all these rows were inserted. That one subpartition has all the rows for that partition.
The query of the user_segments table still shows the same seven partitions, even though I would expect the other subparitions to materialize.
(I have the same problem - hash-hash partitions only have 1 subparititon - on a much larger table with a million-plus rows but I'm using this demo table as an example since I want to post something others can replicate)
Edit: I thought hash-hash partition support was added in 11R2?

Similar Messages

  • Partitions/subpartitions

    Hey,
    - the standard configuration of Oracle: RAC 10gR2 on Unix, ASM, SAN;
    - an OLTP on-line telecom/phone purchasing/ordering DB system;
    - a big table of telecom/phone ordering/purchasing details (the hundreds of millions of rows ), composite partitioned:
    by range date-column (to have a monthly partitioning) +
    hashed by ids (to ease the contention during the concurrent inserts);
    - a table has the several local equi-partitioned indexes (to improve the queries performance);
    - the global indexes can not been created, because the aging data need to be removed on
    a regular basis, so no global indexes to avoid the multi-hours rebuilds;
    a question: the queries (by the dates' ranges) run relatively slow, because the subpartitioning(by hash);
    how to avoid the subpartitioning (it slows down the dates' ranges queries)? and at the same time how not lose a very good performance
    of inserts (a hashed subpartitioning definitely gives it to the DB system)?

    Hey,
    - the standard configuration of Oracle: RAC 10gR2 on Unix, ASM, SAN;
    - an OLTP on-line telecom/phone purchasing/ordering DB system;
    - a big table of telecom/phone ordering/purchasing details (the hundreds of millions of rows ), composite partitioned:
    by range date-column (to have a monthly partitioning) +
    hashed by ids (to ease the contention during the concurrent inserts);
    - a table has the several local equi-partitioned indexes (to improve the queries performance);
    - the global indexes can not been created, because the aging data need to be removed on
    a regular basis, so no global indexes to avoid the multi-hours rebuilds;
    a question: the queries (by the dates' ranges) run relatively slow, because the subpartitioning(by hash);
    how to avoid the subpartitioning (it slows down the dates' ranges queries)? and at the same time how not lose a very good performance
    of inserts (a hashed subpartitioning definitely gives it to the DB system)?

  • Large (highest ?) Number of Partitions / SubPartitions in *Production*

    In theory, the maximum number of Partitions/SubPartitions that Oracle supports for a table is 1024K-1 in 10gR2.
    Per MetaLink Note#76765.1, the limit was 64K-1 in 8i -- and, I understand from the 9i docs, was also the same limit in 9i. The Note candidly admits that only 1,000 Partitions have been tested.
    Have you implemented / seen implemented, say 64thousand Partitions for a table (and this being done for possibly half-a-dozen tables), with at leaste one corresponding LOCALly Partitioned Index ?
    What are the implications on :
    1. MetaData in the Shared Pool and Latching.
    2. Gather_Stats (done GLOBAL or PARTITION wise).
    3. Queries that, very unfortunately, end up scanning all the partitions, many of which are small 64K partitions only.

    .

  • 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

  • Query Optimization with partitioned/subpartitioned tables

    I have a 1 billion row table with 72 partitions by range and thousands of subpartitions by list. There is a bitmap index on the subpartition by list field.
    If I execute the following query which requests data from a single partition and a single subpartition:
    SQL> select * from cen00_demog_sf1_hp where
    ckey like '33011%' and demogname = 'P002006';
    the optimizer selects a single partition ('33...') and a single subpartition ('P002006'). The query takes only 6 seconds including displaying the 7,386 row result.
    However, if I then execute the following query which selects data from two partitions and a single subpartition within each partition:
    SQL> select * from cen00_demog_sf1_hp where
    (ckey like '33011%' or ckey like '35001%')
    and demogname = 'P002006';
    the optimizer scans all partitions rather than just scanning partitions 33 and 35. The query takes over 10 minutes to display the 17,972 row result. If this query is split into two separate queries, the same result set can be realized in a total 26 seconds including display the results to the screen.
    Any suggestions on how the multiple partition query can be modified to avoid an all rows scan?
    Thank you.

    I had previously tried reversing the WHERE clause statements in the query but it had no affect. The execution plan for the two partition query follows. Note the "ALL" on the partition range. I purposely did not index the ckey field believing that partitioning would be sufficent (ckey contains 8,262,363 unique keys out of 1,041,057,738 rows). As a test a query requesting a demogval based on a single ckey for a particular demogname returns a result in less than a second. Another test requesting data for a particular ckey without a demogname qualifier resulted in a full scan of a single partition (but not all the partitions) taking 4 minutes of elapsed time. Note that the only reason that there is a bitmap index on the demogname in table cen00_demog_sf1_hp is that normally the query is a join with another table containing an indexed demogname field. In sum, it appears that the optimizer defaults to an all partition scan when more than one partition is included in the query.
    Elapsed: 00:11:38.41
    Execution Plan
    0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=53824 Card=4 Bytes=148)
    1 0 PARTITION RANGE (ALL) (Cost=53824 Card=4 Bytes=148)
    2 1 PARTITION LIST (SINGLE) (Cost=53824 Card=4 Bytes=148)
    3 2 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CEN00_DEMOG_SF1_HP' (TABLE) (Cost=53824 Card=4 Bytes=148)
    4 3 BITMAP CONVERSION (TO ROWIDS)
    5 4 BITMAP INDEX (SINGLE VALUE) OF 'CEN00_DEMOG_SF1_HP_IDX' (INDEX (BITMAP))
    The single partition query trace shows selectivity on the partition range.
    Elapsed: 00:00:09.69
    Execution Plan
    0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=42 Card=133 Bytes=4655)
    1 0 PARTITION RANGE (SINGLE) (Cost=42 Card=133 Bytes=4655)
    2 1 PARTITION LIST (SINGLE) (Cost=42 Card=133 Bytes=4655)
    3 2 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CEN00_DEMOG_SF1_HP' (TABLE) (Cost=42 Card=133 Bytes=4655)
    4 3 BITMAP CONVERSION (TO ROWIDS)
    5 4 BITMAP INDEX (SINGLE VALUE) OF 'CEN00_DEMOG_SF1_HP_IDX' (INDEX (BITMAP))

  • Convert range partition to range-hash composite partition

    Hi,
    I have several tables that are range partitioned on date and each table has several partitions as they are partitioned for each day. Is there anyway I con convet these table using alter statements to make them a composite? Thanks.

    No, You can't with alter command change partitioning type.
    http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10739/partiti.htm
    Create a new table with needed one partitioning type and insert there all data.

  • 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

  • Will Hash Subpartition be out-dated in the era of Exadata?

    PARTITION BY RANGE(SALES_DAY) SUBPARTITION BY HASH(PRODUCT_ID) was a pretty common way to organize the fact tables in ORACLE.
    Since Exadata automatically distributes data across Storage Server based on 4MB block size, do we still need to subpartition table based on hash value of a high cardinality column? Will partition-wise join be offloaded to storage server without hash subpartition? Please advise and explain.
    Another question: Since both PARTITION BY HASH and SUBPARTITION BY HASH are based ORA_HASH() or the same algorithm as ORA_HASH(), what kind of hash function does Exadata use?
    Thanks.

    :-) Greg, we do need to specify the column or columns which are used to distribute the rows, but this does not have to be part of the partitioning structure. To illustrate, let's see a piece of Teradata DDL:
    PRIMARY INDEX PI_MY_BIG_SALES ( ORDER_ID )
    PARTITION BY (
        RANGE_N(WEBSITE_ID BETWEEN
            1 AND 12 EACH 1),
    CASE_N(IS_OPEN = ‘N’, IS_OPEN = ‘Y’)
    RANGE_N(ORDER_DATE BETWEEN
            DATE '2009-01-01' and DATE '2010-11-30' each interval '1' month,
            DATE '2009-12-01' and DATE '2011-01-31' each interval '1' day,
            NO RANGE
    RANGE_N(PRODUCT_ID BETWEEN
            1 and 99 each 1,
            1000 and 3000 each 100,
            4800 and 4800 each 1,
            5000 and 9999 each 500,
            30000 and 40000 each 1000,
            91900 and 92000 each 100,
            NO RANGE)
    RANGE_N(CATEGORY_ID BETWEEN
            1 and 100 each 10,
            101 and 1000 each 100,
            NO RANGE)
    )If the equivalent of row distribution is handled by ASM, then we can have one more level of partitioning structure to specify in the DDL. Currently, if I need to use HASH partition/subpartition, the only choice is to specify a very complex multi-level RANGE BY(WEBSITE_ID, ORDER_DATE, IS_OPEN, PRODUCT_ID, CATEGORY_ID) SUBPARTITION BY HASH(ORDER_ID) partition clause, instead of a simpler RANGE BY(WEBSITE_ID, ORDER_DATE) SUBPARTITION BY RANGE(IS_OPEN, PRODUCT_ID, CATEGORY_ID).
    Look forward to more powerful DW features and easier syntax in the future Exadata as well.

  • Hash-hash partition

    hi,
    what is the wrong in the bellow code
    1 create table hash_hash
    2 (
    3 empno number(10),
    4 ename varchar(20),
    5 deptno number(5)
    6 )
    7 partition by hash(empno)
    8 subpartition by hash(deptno)
    9 subpartition template
    10 (
    11 subpartition sp1 tablespace user1,
    12 subpartition sp2 tablespace tb1
    13 )
    14 (
    15 partition h1 tablespace user1,
    16 partition h2 tablespace tb1
    17* )
    SQL> /
    subpartition by hash(deptno)
    ERROR at line 8:
    ORA-00922: missing or invalid option
    plz give sugistions

    Unless I read a white paper when refers to hash-hash partitions, in the oficial documentation of 11.2
    http://download.oracle.com/docs/cd/E18283_01/server.112/e16541/part_admin001.htm#i1006565
    http://download.oracle.com/docs/cd/E11882_01/server.112/e16541.pdf
    do not show anything about it...
    I think it is not allowed this composite partition type....

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

  • Doubt in partition and subpartition

    hi gems...good afternoon...
    I have a doubt redgarding partitioning and subpartitioning...This may be a silly question, but i am really not getting this...please help me..
    I have a table which has Range-Hash composite partitioning.
    The Range partitioning is on the default tablespace TS_PROD (because I didnt mention any tablespace name in the Range partitions).
    The Hash subpartitioning are on the corresponding partition tablespaces (TS_PART1,TS_PART2,TS_PART3....TS_PART6).
    I have created total 8 Range partitions and the number of Hash subpartitions are 6 for each of them.
    Now when I query the DBA_TAB_PARTITIONS, then I got the desired output i.e. all the Range partitions are in the default tablespace.
    When I query the DBA_TAB_SUBPARTITIONS, then also I got the desired output i.e. all the Hash subpartitions are in the separate partition tablespaces.
    But when I have inserted data in that table, then I found that both the default tablespace and partition tablespaces are getting filled up.
    Moreover, the sum of the increase in sizes of the partition tablespaces is equal to the increase in default tablespace.
    I am not getting the concept of this. Where are the datas are getting stored??? In the default tablespace or in the partition tablespaces??
    Thanks a lot in advance..

    thanks a lot RP for your reply...
    and sorry for the late and miscommunication...
    Actually i am not so experienced in the DBA line and in my company suddenly my senior DBA left and i am the only one here...I got tensed... :( :(
    I have started reading documentation of Oracle, have started the Administrator's Guide first...
    Anyways...now i got the concept of the partitioning and subpartitioning i was doing...
    The mistake which I was doing is: I was not mentioning the primary key index tablespace and that segment is going into the default tablespace and thats why the size was increasing for both default tablespace and partitioned tablespaces. Because of that fact I was getting confused again and again.
    As soon as I mentioned the primary key index tablespace, the size of the default tablespace stopped increasing...
    Now the script from which I am getting the size of the tablespaces: (join of dba_datafiles and dba_free_space)
    select /* + RULE */ t.tablespace, t.totalspace as " Totalspace(MB)",
    round((t.totalspace-fs.freespace),2) as "Used Space(MB)",
    fs.freespace as "Freespace(MB)",
    round(((t.totalspace-fs.freespace)/t.totalspace)*100,2) as "% Used",
    round((fs.freespace/t.totalspace)*100,2) as "% Free"
    from
    (select round(sum(d.bytes)/(1024*1024)) as totalspace, d.tablespace_name tablespace
    from dba_data_files d
    group by d.tablespace_name) t,
    (select round(sum(f.bytes)/(1024*1024)) as freespace, f.tablespace_name tablespace
    from dba_free_space f
    group by f.tablespace_name) fs
    where t.tablespace=fs.tablespace
    order by t.tablespace;
    Thanks a lot RP for your help... :)

  • AVOID Subpartition(list) to be created when Splitting Main Partition(range)

    I have created a table structure as below:
    CREATE TABLE TEST_SUBPARTITIONS_1
    RECORD_ID INTEGER NOT NULL,
    SUB_ID VARCHAR2(100),
    COBDATE DATE,
    DESC VARCHAR2(2000)
    PARTITION BY RANGE (COBDATE)
    SUBPARTITION BY list(SUB_ID)
    PARTITION INITIAL_PARTITION VALUES LESS THAN (TO_DATE(' 2200-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    TABLESPACE TBS_DATA
    PCTFREE 10
    INITRANS 1
    MAXTRANS 255
    STORAGE
    INITIAL 64K
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    (SUBPARTITION INITIAL_SUBPARTITION VALUES ('INITIAL_DUMMY_SUB_ID') TABLESPACE TBS_DATA
    CREATE UNIQUE INDEX TEST_SUBPARTITIONS_1_PK ON TEST_SUBPARTITIONS_1 (COBDATE, RECORD_ID, SUB_ID) LOCAL;
    ALTER TABLE TEST_SUBPARTITIONS_1 ADD CONSTRAINT TEST_SUBPARTITIONS_1_PK PRIMARY KEY (COBDATE, RECORD_ID, SUB_ID);
    I am partitioning the table based on range (COBDATE) and subpartitioning based on list (SUB_ID).
    The table now is created with initial partitions and initial subpartition.
    We are splitting the partitions in our procedure as below
    ALTER TABLE TEST_SUBPARTITIONS_1 SPLIT PARTITION
    TST_SUB_R21001231 AT (TO_DATE(20130220,'YYYYMMDD') ) INTO
         (PARTITION TST_SUB_R20130219 TABLESPACE TBS_DATA, PARTITION TST_SUB_R21001231)
    The partition is getting split correctly with new partition as
    TST_SUB_R20130219, but the subpartition is also created automatically with some 'SYS' name.
    (i.e Name: SYS_SUBP693 , Values: INITIAL_DUMMY_SUB_ID)
    This happens after every split of range by COBDATE.
    Here it has created as below:
    Partition          SubPartition
    TST_SUB_R21001231     INITIAL_SUBPARTITION
    TST_SUB_R20130219     SYS_SUBP693
    TST_SUB_R20130220     SYS_SUBP694
    TST_SUB_R20130221     SYS_SUBP695
    I want to AVOID splitting subpartition when I split the main partition
    i.e a SYS subpartition should not be created when I split the partition for COBDATE.
    Let me know how do I avoid this in main "alter statement" above?
    Any other solution?     I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.

    >
    I want to AVOID splitting subpartition when I split the main partition
    i.e a SYS subpartition should not be created when I split the partition for COBDATE.
    Let me know how do I avoid this in main "alter statement" above?
    Any other solution? I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.
    >
    The subpartitions aren't being split. Oracle is creating new subpartitions for the new partition. The subpartitions need to exist since that is where the data is stored.
    You can avoid the SYS prefix on the name though by using a different naming convention.
    See the 'Splitting a *-List Partition' section of the VLDB and Partitioning Guide
    http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm#i1008028
    >
    The ALTER TABLE ... SPLIT PARTITION statement provides no means of specifically naming subpartitions resulting from the split of a partition in a composite partitioned table. However, for those subpartitions in the parent partition with names of the form partition name_subpartition name, the database generates corresponding names in the newly created subpartitions using the new partition names. All other subpartitions are assigned system generated names of the form SYS_SUBPn. System generated names are also assigned for the subpartitions of any partition resulting from the split for which a name is not specified. Unnamed partitions are assigned a system generated partition name of the form SYS_Pn.

  • Does hash partition distribute data evenly across partitions?

    As per Oracle documentation, it is mentioned that hash partitioning uses oracle hashing algorithms to assign a hash value to each rows partitioning key and place it in the appropriate partition. And the data will be evenly distributed across the partitions. Ofcourse following following conditions :
    1. Partition count should follow 2^n logic
    2. Data in partition key column should have high cardinality.
    I have used hash partitioning in some of our application tables, but data isn't distributed evenly across partitions. To verify it, i performed a small test :
    Table script :
    Create table ch_acct_mast_hash(
    Cod_acct_no number)
    Partition by hash(cod_acct_no)
    PARTITIONS 128;
    Data population script :
    declare
    i number;
    l number;
    begin
    i := 1000000000000000;
    for l in 1 .. 100000 loop
    insert into ch_acct_mast_hash values (i);
    i := i + 1;
    end loop;
    commit;
    end;
    Row-count check :
    select count(1) from Ch_Acct_Mast_hash ; --rowcount is 100000
    Gather stats script :
    begin
    dbms_stats.gather_table_stats('C43HDEV', 'CH_ACCT_MAST_HASH');
    end;
    Data distribution check :
    Select min(num_rows), max(num_rows) from dba_tab_partitions
    where table_name = 'CH_ACCT_MAST_HASH';
    Result is :
    min(num_rows) = 700
    max(num_rows) = 853
    As per the result, it seems there is lot of skewness in data distribution across partitions. Maybe I am missing something, or something is not right.
    Can anybody help me to understand this behavior?
    Edited by: Kshitij Kasliwal on Nov 2, 2012 4:49 AM

    >
    I have used hash partitioning in some of our application tables, but data isn't distributed evenly across partitions.
    >
    All keys with the same data value will also have the same hash value and so will be in the same partition.
    So the actual hash distribution in any particular case will depend on the actual data distribution. And, as Iordan showed, the data distribution depends not only on cardinality but on the standard deviation of the key values.
    To use a shorter version of that examle consider these data samples which each have 10 values. There is a calculator here
    http://easycalculation.com/statistics/standard-deviation.php
    0,1,0,2,0,3,0,4,0,5 - total 10, distinct 6, %distinct 60, mean 1.5, stan deviation 1.9, variance 3.6 - similar to Iordan's example
    0,5,0,5,0,5,0,5,0,5 - total 10, distinct 2, %distinct 20, mean 2.5, stan dev. 2.64, variance 6.9
    5,5,5,5,5,5,5,5,5,5 - total 10, distinct 1, %distinct 10, mean 5, stan dev. 0, variance 0
    0,1,2,3,4,5,6,7,8,9 - total 10, distinct 10, %distinct 100, mean 4.5, stan dev. 3.03, variance 9.2
    The first and last examples have the highest cardinality but only the last has unique values (i.e. 100% distinct).
    Note that the first example is lower for all other attributes but that doesn't mean it would hash more evenly.
    Also note that the last example, the unique values, has the highest variance.
    So this is no single attribute that is controlling. As Iordan showed the first example has a high %distinct but all of those '0' values will hash to the same partition so even using a perfect hash the data would use 6 partitions.

  • 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

  • Parent partition of subpartitions that move to a new TS

    PLATFORM_NAME: Solaris[tm] OE (64-bit)
    VERSION: 11.2.0.2.0
    In our system we have several tables that are partitioned by range. Some of these tables are then sub-partitioned by list. Well initially we were creating a new tablespace every month and creating the new monthly partition on the new tablespace. Well I got annoyed by this, so I decided to move all of the partitions/subpartitions to a single tablespace. And this went smooth, at first, in my dev region. I moved all of the segments to the new tablespace, but then I noticed something odd...
    Example:
    CREATE TABLE me.sub_partitioned_table
    my_range_partitioned_column date,
    my_list_partitioned_column varchar2(30)
    PARTITION BY RANGE (my_range_partitioned_column)
    SUBPARTITION BY LIST (my_list_partitioned_column)
    SUBPARTITION TEMPLATE
    (SUBPARTITION value4 VALUES (4),
    SUBPARTITION value23 VALUES (23),
    SUBPARTITION value60 VALUES (60),
    SUBPARTITION "DEFAULT" VALUES (DEFAULT)
    PARTITION P_HIST VALUES LESS THAN (TO_DATE(' 2007-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    TABLESPACE P_HIST
    ( SUBPARTITION P_HIST_value4 VALUES (4) TABLESPACE MONTHLY_PARTITION,
    SUBPARTITION P_HIST_value23 VALUES (23) TABLESPACE MONTHLY_PARTITION,
    SUBPARTITION P_HIST_value60 VALUES (60) TABLESPACE MONTHLY_PARTITION,
    SUBPARTITION P_HIST_DEFAULT VALUES (DEFAULT) TABLESPACE MONTHLY_PARTITION ),
    ...... and there are a lot more partitions/subpartitions
    So I create all of my alter table move subpartition statements, and the execute as they should. If I do:
    select tablespace_name from dba_tab_subpartitions where table_name = 'SUB_PARTITIONED_TABLE' and table_owner = 'ME', I see that all of my subpartitions are on the new, single tablespace. BUUUUUUT, if I do:
    select tablespace_name from dba_tab_partitions where table_name = 'SUB_PARTITIONED_TABLE' and table_owner = 'ME', I see all of the old tablespace names are still listed for my partitions.
    My question is, can this be changed? Did I screw something up? Is this a bug? If I try to alter the table and move the partition I get an error because I'm trying to move something that isn't a segment. Any help would be appreciated. Hopefully this makes sense. If you need clarification on anything, please let me know.
    Thanks!

    I found my answer...
    ALTER TABLE ME.sub_partitioned_table MODIFY DEFAULT ATTRIBUTES FOR PARTITION MONTHLY_PARTITION TABLESPACE NEW_BIG_TS;

Maybe you are looking for