TIMESTAMP(6) Partitioned Key -   Range partitioned table ddl needed

What is DDL syntax for TIMESTAMP(6) Partitioned Key, Range partitioned table
Edited by: oracletune on Jan 11, 2013 10:26 AM

>
What is DDL syntax for TIMESTAMP(6) Partitioned Key, Range partitioned table
>
Not sure what you are asking. Are you asking how to create a partitioned table using a TIMESTAMP(6) column for the key?
CREATE TABLE TEST1
    USERID                 NUMBER,
    ENTRYCREATEDDATE     TIMESTAMP(6)
PARTITION BY RANGE (ENTRYCREATEDDATE) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
    PARTITION P0 VALUES LESS THAN (TO_DATE('1-1-2013', 'DD-MM-YYYY'))
)See my reply Posted: Jan 10, 2013 9:56 PM if you need to do it on a TIMESTAMP with TIME ZONE column. You need to add a virtual column.
Creating range paritions automatically

Similar Messages

  • Query with non partition key in partitioning table

    i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
    time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
    i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
    whether the transfer from one partition to another partition takes time?
    this example sql trace query select for 3,4 and 6 partition
    3 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.70       7.57      25291     1157583
    total        5.70       7.57      25291     1157583
    Parsing user id: 61  (SKENARIO1)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.46       8.03      25126     1157583
    total        5.46       8.03      25126     1157583
    Parsing user id: 62  (SKENARIO2)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.73       9.13      25190     1157583
    total        5.73       9.13      25190     1157583
    Parsing user id: 63  (SKENARIO3)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6thanks
    best regards
    eko

    ekopur wrote:
    i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
    time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
    i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
    whether the transfer from one partition to another partition takes time?
    this example sql trace query select for 3,4 and 6 partition
    3 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.70       7.57      25291     1157583
    total        5.70       7.57      25291     1157583
    Parsing user id: 61  (SKENARIO1)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.46       8.03      25126     1157583
    total        5.46       8.03      25126     1157583
    Parsing user id: 62  (SKENARIO2)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.73       9.13      25190     1157583
    total        5.73       9.13      25190     1157583
    Parsing user id: 63  (SKENARIO3)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6
    I'm assuming you recreated the table a couple of times with different numbers of hash partitions. (Tip: always use a power of two for the number of hash partitions - it keeps them all around the same size if you are using the feature on an appropriate data set.)
    There isn't really enough difference in time within the database to make any sensible comment about the difference in times. I note that you have also edited out the fetch count for the 1.1 million rows fetched, and have not captured (or perhaps just not printed) the wait times, so we don't know where you spent the time inside and outside the database.
    For all we can tell, the difference you are worried about might simply be network time on the fetch calls, and have nothing to do with the extract you've published.
    Regards
    Jonathan Lewis

  • Best way to change partition key on existing table

    Hi,
    Using Oracle 11.20.3 on AIX.
    We have a table about 800 million rows and 120gb in size.
    Want to try copies oif this table to evalaute different partitiong strategies.
    What is the quickest way to do this?
    Would have liked say datapump table 1 tro disk and datapumo import the data to new table but do the tables need to be of the same format.
    Thanks

    >
    Using Oracle 11.20.3 on AIX.
    We have a table about 800 million rows and 120gb in size.
    Want to try copies oif this table to evalaute different partitiong strategies.
    What is the quickest way to do this?
    Would have liked say datapump table 1 tro disk and datapumo import the data to new table but do the tables need to be of the same format.
    >
    First your subject asks a different question that the text you posted: Best way to change partition key on existing table. The answer to that question is YOU CAN'T. All data has to be moved to change the partition key since each partition/subpartition is in its own segment. You either create a new table or use DBMS_REDEFINITION to redefine the table online.
    Why do you want to export all data to a file first? That just adds to the time and cost of doing the op.
    What problem are you trying to use partitioning to solve? Performance? Data maintenance? For performance the appropriate partitioning key and whether to use subpartitions depends on the types of queries and the query predicates you typically use as well as the columns that may be suitable for partition keys.
    For maintenance a common method is to partition on a date by year/month/day so you can more easily load new daily/weekly/monthly data into its own partition or drop old data that no longer needs to be kept online.
    You should use a small subset of the data when testing your partitionings strategies.
    Can you do the partitioning offline in an outage window? If not then using the DBMS_REDEFINITION is your only option.
    Without knowing what you are trying to accomplish only general advice can be given. You even mentioned that you might want to use a different set of columns than the curren table has.
    A standard heap table uses ONE segment for its data (ignoring possible LOB segments). A partitioned/subpartitioned table uses ONE segment for each partition/subpartition. This means that ALL data must be moved to partition the table (unless you are only creating one partition).
    This means that every partitioning scheme that uses a different partition key requires ALL data to be moved again for that test.
    Provide some information about what problem you are trying to solve.
    >
    Is this quicker than datapump?
    >
    Yes - exporting the data simplying moves it all an additional time. Ok to export if you need a backup before you start.
    >
    Found artcle which talks about using merge option on datapump import to convert partitioned table to non-partitioned table.
    >
    How would that apply to you? That isn't what you said you wanted to do.

  • Remove partition key from partitoned table

    can somebody help me with a sql syntax to remove a partition key from a partiton table . The scenario is explained as follows:
    create table t1 (c1 number, c2 number ,c3 number)
    partition by range (c1, c2)
    (partition p1 values less than 11,
    partition p1 values less than 21,
    partition p1 values less than 31 );
    i have data in this table and lot of indexes built, so i cannot drop this table to recreate it.
    All i want is to remove c1 from partition key (c1,c2).
    I will appreciate if somebody can give me a SQL syntax for this.
    Ajay Nerumati.

    Have you used the debugger and checked that the selectedRowKey is filled?
    Can you elaborate what you mean by {qoute} ...does not work ...>
    Do you have a reason not to use the current selection listener selectionListener="#{bindings.NotificationOfDifficultiesVO.collectionModel.makeCurrent}" on your table to let the framework do the work for you and then simply call the delete method on the VO?
    Timo

  • Partitioning Question - range partition?

    Hello all
    we have an issue with the amount of data we have in a particular schema that we are using to store production metrics. I have looked at a few options and are now trying to design a solution using partitioning. At a very high level we have data in 7 tables that need to utilise partitioning:
    JOBS
    FILES
    MAILPIECES
    MAILPIECE_DETAILS
    TNT_DATA
    BAGFILES
    POSTAL_BAGS
    Ideally I would like to use a RANGE partition as I can fairly easily use a date as the range - my issue here though is that only the FILES table has a DATE column on it.
    So my question is, for the other tables, is it best practice to use the same 'sort of' partitions - in which case I would need to add a DATE column to each subsequent table and populate it correctly (based on the date in the FILES table - as the FILES table is acting as the PARENT table for all the other tables). Or, should each table be treated individually and partitioned using whatever method is appropriate for that table?
    Any help would be greatly appreciated.
    Many thanks
    Paul

    Hi,
    if you are running 11g and all other tables are indeed children to FILES then consider reference partitioning.

  • Problem exchanging partitions using range partitioning

    I have a range-partitioned table. Here's a cut down version....
    CREATE TABLE MY_TABLE
       (     VALUE           NUMBER,
         PARTITION_KEY      NUMBER
      PARTITION BY RANGE ("PARTITION_KEY")
    (PARTITION "P1"  VALUES LESS THAN (2),
      PARTITION "P2"  VALUES LESS THAN (3),
      PARTITION "P3"  VALUES LESS THAN (4),
      PARTITION "P4"  VALUES LESS THAN (5),
      PARTITION "P5"  VALUES LESS THAN (6),
      PARTITION "P6"  VALUES LESS THAN (7),
      PARTITION "P7"  VALUES LESS THAN (8));For the process I'm working on, I want to be able to:
    - create a table as a copy of one of the partitions
    - do some processing on that table
    - exchange the updated table back into the partitioned table
    I can achieve this as follows....
    CREATE TABLE MY_TABLE_COPY_P7 AS (SELECT * FROM MY_TABLE WHERE PARTITION_KEY = 7);
    ... do processing ...
    ALTER TABLE MY_TABLE DROP PARTITION P7;
    ALTER TABLE MY_TABLE ADD PARTITION P7 VALUES LESS THAN (8);
    ALTER TABLE MY_TABLE EXCHANGE PARTITION P7 WITH TABLE MY_TABLE_COPY INCLUDING INDEXES;However, this only works if the partition I'm adding back in is the highest partition.
    If I try do take out one of the middle partitions, then add it back I get an error:
    SQL] ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6);
    ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6)
    ERROR at line 1:
    ORA-14074: partition bound must collate higher than that of the last partitionAny ideas on how I can exchange one of the middle partitions with having to first drop the higher ones?
    Btw, I have to use range partitioning as we're using spatial, which only supports range partitioning.
    Cheers,

    Actually, you can do the exchange partition thing with 8i and over. After creating my_table from your script, I did:
    SQL> INSERT INTO my_table VALUES (1,7.5);
    1 row created.
    SQL> INSERT INTO my_table VALUES (2, 7.2);
    1 row created.
    SQL> INSERT INTO my_table VALUES (3,7.7);
    1 row created.
    SQL> CREATE TABLE my_tab_tmp AS
      2  SELECT * FROM my_table
      3  WHERE 1=2;
    Table created.
    SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
    Table altered.
    SQL> SELECT * FROM my_tab_tmp;
         VALUE PARTITION_KEY
             1           7.5
             2           7.2
             3           7.7
    SQL> SELECT * FROM my_table;
    no rows selected
    SQL> UPDATE my_tab_tmp
      2  set value = value * 20;
    3 rows updated.
    SQL> COMMIT;
    Commit complete.
    SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
    Table altered.
    SQL> SELECT * FROM my_tab_tmp;
    no rows selected
    SQL> SELECT * FROM my_table;
         VALUE PARTITION_KEY
            20           7.5
            40           7.2
            60           7.7You will, of course, need to re-build any global indexes on my_table.
    When you first create my_tab_tmp, you should also create indexes to match any local indexes on the partitions, then do the exchange partition using the INCLUDING INDEXES clause. You could also skip creating the indexes and then re-create them after exchanging the updated table with the partition.
    Note that none of this will work if you are changing values of partition_key so thatthey fall out of the range for the partition.
    HTH
    John

  • NULL partition key in RANGE partition

    All,
    This is regarding partitioning a table using RANGE partition method. But the partition key contains null. How do I handle this situation? This is because there is no DEFAULT partition in RANGE partition though its present in LIST partition. Will rows with NULL partition key fall in MAXVALUE partition? Seeking your guidence.
    Thanks,
    ...

    NULLS would fit into the MAXVAL partition yes.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2590
    Thanks
    Paul

  • Find range partition key information

    Hello, I try to insert a row in a table and I get this msg: "inserted partition key is beyond highest legal partition key". This table has a range partitioning key but I don't know on which colmn(s) this partioning is working.
    Is there a way to find this information?
    - which column
    - which are the values
    Thx in advance,
    Pascal

    Look at the following views, you should be able to find the information
    USER_IND_PARTITIONS
    USER_IND_SUBPARTITIONS
    USER_LOB_PARTITIONS
    USER_LOB_SUBPARTITIONS
    USER_TAB_PARTITIONS
    USER_TAB_SUBPARTITIONS

  • 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

  • How to Implement 30 days Range Partitioning with Date column. Not Interval

    Hi,
    I am using the db:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit
    Current table structure is:
    CREATE TABLE A
    a NUMBER,
    CreationDate DATE
    PARTITION BY RANGE (CreationDate)
    INTERVAL ( NUMTODSINTERVAL (30, 'DAY') )
    (PARTITION P_FIRST
    VALUES LESS THAN (TIMESTAMP ' 2001-01-01 00:00:00'))
    How can I define virtual column based partitioning with RANGE partitioning without using INTERVAL partitioning.
    And that is with Intervals of 30 days.
    For monthly I am trying as
    CREATE TABLE A
    a NUMBER,
    CreationDate DATE,
    monthly_interval date as (to_char(CreationDate,'MM-YYYY')) VIRTUAL
    PARTITION BY RANGE (monthly_interval)
    partition p_AUG12 values less than (to_date('08-2012','mm-yyyy')),
    partition p_SEP12 values less than (to_date('09-2012','mm-yyyy')),
    partition p_OCT12 values less than (to_date('10-2012','mm-yyyy'))
    Enable ROw Movement
    BUT CAN'T INSERT the data even for that:
    Insert into a (a, CreationDate)
    Values (1, '12-10-2012')
    Insert into a (a, CreationDate)
    Values (1, '12-10-2012')
    Please suggest..

    Hi rp,
    Interval Partitioned to Range. Created Daily Partitions from Monthly Part. got complicated so I am posting here.
    Basically,
    I know Interval Partitioning is a kind of Range partitioning. But explicitly for Interval Partitioned tables XML Indexes are not allowed as discussed here:
    XMLIndexes on an Interval Partitioned Table??
    I can do monthly partitions as :
    CREATE TABLE A
    a NUMBER,
    CreationDate DATE,
    monthly_interval varchar2(8) as (to_char(CreationDate,'MM-YYYY')) VIRTUAL
    PARTITION BY RANGE (monthly_interval)
    partition p_AUG12 values less than ('09-2012'),
    partition p_SEP12 values less than ('10-2012'),
    partition p_OCT12 values less than ('11-2012')
    ) Enable ROw Movement
    Insert into a (a, CreationDate)
    Values (1, '12-SEP-2012')
    Insert into a (a, CreationDate)
    Values (1, '14-SEP-2012')
    Select * from A partition (p_SEP12)
    Select * from A partition (p_AUG12)
    Select * from A partition (p_OCT12)
    Can we do it for 30 days partitions, instead of the monthly partitions. ANY suggestions..
    Thanks..

  • Anbody used Hash partioning? - what about queries not using partition key

    Hi there,
    We have a table, will have over 3 billion rows when loaded and wish to implement partioning.
    Brief structure
    cal_id -- relates to date of transaction
    prod_id
    cust_id,
    sales_qty
    The id's are all surrogate id's/dimension keys
    About 80% of queries expected to use by on_sale_date of product rather than date of transaction hence considering using hash partition on product_id.
    Queries will hit > 1 partition in general and also some e.g 15% of queries wil be by date of transaction.
    Qusetions I have - how will these 15% of queries be affected. I expect will be poorer performance-wise because of partioning but becuase of size of table and 80% queries by product have to use partition.
    Also will partition-pruning work if queries use between rather than = operator
    Anbody used hash partioning - keen to hear other people's ideas/experience with hash partioning.
    Many Thanks

    Hi,
    When partition pruning is not used, then that depend on the access path.
    If it does a full table scan, then there is nearly no overhead to full scan all partitions (compared with full scanning the same non-partitioned table)
    If it is an index access and if indexes are local, then all indexes must be read. But with global index, again, there is no overhead in comparison with a non-partitioned table (except that indexes are a bit larger when global on partitioned table)
    However can be expected to partition even when reading all partitions, especially with parallel query.
    the between is not optimal with hash partitions, s it is hash partition, not range partition.
    Regards,
    Franck.

  • Help on Partition Key .

    Team ,
    I'm tasked to gather some stats to decide on Partition Key for our Orders table .
    It has about 54288107 rows and i need to justify between Order_ID and Insert_Date for ideal partition key .
    CREATE TABLE [dbo].[WEb_Order](
    [order_id] [int] NOT NULL,
    [merchant] [varchar](20) NOT NULL,
    [vendor] [varchar](20) NOT NULL,
    [Status] [varchar](30) NOT NULL,
    [Substatus] [varchar](30) NOT NULL,
    [PONumber] [varchar](50) NOT NULL,
    [Insert_Date] [datetime] NOT NULL,
    [Order_Date] [datetime] NOT NULL,
    [line_count] [int] NOT NULL,
    [download_date] [datetime] NOT NULL,
    CONSTRAINT [PK_WEB_order] PRIMARY KEY CLUSTERED
    [order_id] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
    ON [PRIMARY]
    ) ON [PRIMARY]
    GO
    SET ANSI_PADDING OFF
    GO
    Note : I've removed some redundant columns which are of no use  on pasted table structure above .
    So , What steps do i need to perform so as to decide between  order_id or Insert_date such that my partitions are uniform  and effective . 
    Thanks for your pointers in advance !
    Rajkumar Yelugu

    Partitioning will not always yield to a better performance. 
    Answer to your question,
    You have to use both Order_ID and Insert_Date and define the partition key based on date column.
    CREATE TABLE [dbo].[WEb_Order](
    [order_id] [int] NOT NULL,
    [merchant] [varchar](20) NOT NULL,
    [vendor] [varchar](20) NOT NULL,
    [Status] [varchar](30) NOT NULL,
    [Substatus] [varchar](30) NOT NULL,
    [PONumber] [varchar](50) NOT NULL,
    [Insert_Date] [datetime] NOT NULL,
    [Order_Date] [datetime] NOT NULL,
    [line_count] [int] NOT NULL,
    [download_date] [datetime] NOT NULL,
    CONSTRAINT [PK_WEB_order] PRIMARY KEY CLUSTERED
    [order_id] ASC,[Insert_Date]
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
    ON [PRIMARY]
    ) ON [PRIMARY]
    OR
    ALTER TABLE Web_Orders ADD CONSTRAINT pk_Orders PRIMARY KEY (Order_ID, Insert_Date);
    You can refer the below links
    https://www.simple-talk.com/sql/database-administration/gail-shaws-sql-server-howlers/
    http://www.toadworld.com/platforms/sql-server/w/wiki/9655.partitioned-table-rules-and-gotchas.aspx
    --Prashanth

  • Regarding Range Partition

    Hi,
    Is it possible to add a partition which will only contain NULL values for RANGE PARTITIONING.
    Actually I cann't add a partition like "VALUES LESS THAN (MAXVALUE)"
    as dynamically we will drop and add partition in this table and if I add a partition like "VALUES LESS THAN (MAXVALUE)" then we cann't add a partition, as it will gives an error "ORA-14074: partition bound must collate higher than that of the last partition". Is there any way of adding only NULL partition for range partition.
    Thanks in advance,
    Koushik

    Hi,
    Yes, you won't be able to add a new partition.. but did you think about SPLIT partition instead of ADD ?
    Regards,
    Yoann.

  • Hash Partition vs Range

    I have a table into which data is inserted daily and contain customer nos. Most of the queries contain where clauses with customer no. field and date field.
    I am looking for some suggestions on the type table to be created (IOT or Normal) and also the partitioning options, hash/range on date/customer no or composite partitioning. Range partitioning on date is an obvious solution but the table may need maintantance in the future creating new partitions.

    You didn't specify Which oracle version and OS you are using. How can we know that what you are running and your table structure.
    Also, your buffer busy waits are culprit and this might due to index range scan happening for every insert. But this is a guess

  • Can I change some partitions of the partitioned table read-only?

    I have a table partitioned by range( partitioned hourly).
    I want to keep the history data online for query (the history data is rarely accessd). But in this way the table is too large. The performance may be a big problem. So some problems may be raised:
    How can I change the aged partition read-only?
    How to decrease the workload on this table and improve the performance?
    Oracle 10g (10.2.0.3)+Solaris 10

    How can I change the aged partition read-only?In 10.2.x.x I think only tablespaces can be made read only.
    In 11g you can place tables in read only mode, but I don't know about specific partitions.

Maybe you are looking for