Move non-partition to Partition with order by cluse

Question

Hi,
I have non partition table of around 9GB and want to convert it into Partiiton table. Following is the des:
SQL> select num_rows,blocks from dba_tables where table_name='DEMAND_DRAFT_STATUS';
  NUM_ROWS     BLOCKS
  21720123    1228647
SQL> select index_name,index_type from dba_indexes where table_name='DEMAND_DRAFT_STATUS';
INDEX_NAME                     INDEX_TYPE
SYS_C0011138                   NORMAL
IDX_DEMD_DRFT_STAT_INSERTED_BY BITMAP
IDX_DEMD_DRFT_STAT_UPDATED_BY  BITMAP
SQL> select clustering_factor from dba_indexes where index_name='SYS_C0011138';
CLUSTERING_FACTOR
        387978241
SQL> select column_name,column_position from dba_ind_columns where index_name='SYS_C0011138';
COLUMN_NAME
COLUMN_POSITION
ISSU_BR_CODE
              1
ISSU_BANK_CODE
              2
ISSU_EXTN_CNTR_CODE
              3
COLUMN_NAME
COLUMN_POSITION
DD_NUM
              4
ISSUE_DATE
              5
DD_CRNCY_CODE
              6
COLUMN_NAME
COLUMN_POSITION
OT_TYPE
              7
PRODUCT_CODE
              8
CURRENCY_CODE
              9
9 rows selected.
SQL> desc DEMAND_DRAFT_STATUS
Name                                                                                                              Null?    Type
ISSU_BR_CODE                                                                                                      NOT NULL VARCHAR2(6)
ISSU_BANK_CODE                                                                                                    NOT NULL VARCHAR2(6)
ISSU_EXTN_CNTR_CODE                                                                                               NOT NULL VARCHAR2(2)
DD_NUM                                                                                                            NOT NULL VARCHAR2(16)
ISSUE_DATE                                                                                                        NOT NULL DATE
DD_CRNCY_CODE                                                                                                     NOT NULL VARCHAR2(3)
OT_TYPE                                                                                                           NOT NULL VARCHAR2(2)
PRODUCT_CODE                                                                                                      NOT NULL VARCHAR2(5)
CURRENCY_CODE                                                                                                     NOT NULL VARCHAR2(3)
DD_STATUS                                                                                                                  CHAR(1)
DD_STATUS_DATE                                                                                                             DATE
DD_AMT                                                                                                                     NUMBER(20,4)
DD_REVAL_DATE                                                                                                              DATE
PRNT_ADVC_FLG                                                                                                              CHAR(1)
PRNT_RMKS                                                                                                                  VARCHAR2(50)
PAYEE_BR_CODE                                                                                                              VARCHAR2(6)
PAYEE_BANK_CODE                                                                                                            VARCHAR2(6)
PAYING_BR_CODE                                                                                                             VARCHAR2(6)
PAYING_BANK_CODE                                                                                                           VARCHAR2(6)
ROUTING_BR_CODE                                                                                                            VARCHAR2(6)
ROUTING_BANK_CODE                                                                                                          VARCHAR2(6)
INSTRMNT_TYPE                                                                                                              VARCHAR2(6)
INSTRMNT_ALPHA                                                                                                             VARCHAR2(6)
INSTRMNT_NUM                                                                                                               VARCHAR2(16)
PUR_NAME                                                                                                                   VARCHAR2(80)
PAYEE_NAME                                                                                                                 VARCHAR2(80)
PRNT_OPTN                                                                                                                  CHAR(1)
PRNT_FLG                                                                                                                   CHAR(1)
PRNT_CNT                                                                                                                   NUMBER(3)
DUP_ISS_CNT                                                                                                                NUMBER(3)
DUP_ISS_DATE                                                                                                               DATE
RECTIFED_CNT                                                                                                               NUMBER(3)
PAID_EX_ADVC                                                                                                               CHAR(1)
ADVC_RCV_DATE                                                                                                              DATE
BC_FLG                                                                                                                     CHAR(1)
ENTERED_BY                                                                                                                 CHAR(1)
CAUTIONED_STAT                                                                                                             CHAR(1)
CAUTIONED_REASON                                                                                                           VARCHAR2(50)
PAID_ADVC_FLG                                                                                                              CHAR(1)
INVT_SRL_NUM                                                                                                               VARCHAR2(16)
PRNT_REM_CNT                                                                                                               NUMBER(2)
INSERTED_BY                                                                                                                NUMBER(10)
UPDATED_BY                                                                                                                 NUMBER(10)
INSERTED_ON                                                                                                                DATE
UPDATED_ON                                                                                                                 DATE
DEL_FLG                                                                                                                    CHAR(1)
LCHG_TIME                                                                                                                  DATE
RCRE_TIME                                                                                                                  DATE
BUSINESS_DATE                                                                                                              DATEFollowing questions:
1) I want to Range partition by ISSUE_DATE (there is no issue), but i'm thinking of reordering the column of index i.e 'SYS_C0011138' (which is also primary key). For example low cardinality columns i will place first and high selective column i would place at last in order. Is that a good idea?
2) While creating Partition table i want to give insert /*+ parallel 10 */ into partitiontable select * from DEMAND_DRAFT_STATUS order by CURRENCY_CODE,DD_CRNCY_CODE,PRODUCT_CODE,OT_TYPE,ISSU_BANK_CODE,ISSU_EXTN_CNTR_CODE,ISSUE_DATE,ISSU_BR_CODE,DD_NUM;
Why i'm doing this because index is going to be created on CURRENCY_CODE,DD_CRNCY_CODE,PRODUCT_CODE,OT_TYPE,ISSU_BANK_CODE,ISSU_EXTN_CNTR_CODE,ISSUE_DATE,ISSU_BR_CODE,DD_NUM columns so clustering factore os that index would be good(this is primary key index btw). Is it good?
3) Once partition is done i want to compress the old partitions, but i'm bit worried that i wont get enough compress ratio if i create partition table with ORDER by clause. whats your thought?
Please give recommendation
Regards

Answer 1

rp0428 wrote:
>
whats your thought?
>
Your post raises nothing but questions about WHY you are doing any of this. We can't suggest appropriate solutions without knowing what the problems are or what goals you are trying to achieve.
>
I have non partition table of around 9GB and want to convert it into Partiiton table
>
Ok - but WHY? Are you currently having problems? What are they? Is performance poor? For what type of queries or operations? Is management a problem - can't easily roll-off old data?
>Well its management decision to partitions the table which are expected to have high size in future. There reference of 6GB i gave only for explanation, actually we have 2-3 tables which are 500+GB and will grow.
Its a DWH environment where daily incremental load happens. So we came out of decision to have tables(which have daily incremental load) partitioned on monthly basis. And keep last quatat partitions on Cell Flash cache(its exadata)
CLUSTERING_FACTOR
387978241
>
Yep - that is a high factor for 1.2 million blocks. But are you sure it is correct? It's 17 times greater than the number of rows in the table. That suggests that to read the entire table using the index every block has to be read 17 times. That doesn't make sense - odds are the table and index stats you provided are not current.
Yes thats seems to be correct figure. I'll check once again and post..
>
And it has this quote from Tom Kyte's book Expert Oracle Database Architecture
>
we could also view the clustering factor as a number that represents the number of logical i/o’s against the table, that would be performed to read the entire table via the index.
>
Even assuming that index has a high clustering factor the next question is:
So what? That would only be relevant if you are using that index to access the entire table or large numbers of blocks.
Is there a problem you are having that you can identify the clustering factor as the main culprit?
If it ain't broke, don't fix it.
>Yes that correct but clustering factor worry me much after seeing its value which is very high as compared to # of blocks.
1) I want to Range partition by ISSUE_DATE (there is no issue), but i'm thinking of reordering the column of index i.e 'SYS_C0011138' (which is also primary key). For example low cardinality columns i will place first and high selective column i would place at last in order. Is that a good idea?
>
Range partitioning by a date can be useful so lets just assume it is in your case; maybe you are thinking about dropping old data. Is your primary key going to be global or local? That will affect performance if you drop old partitions; the global index has to be maintained but the local one doesn't.
I'm not going to drop any partitions of old data as of now but will compress them because they wont anticipate DMLS.(but might be select)
Now the question is about Primary key > wll it be Local of Global? Well i thought of having this Key as Local(because one of my primary key column will contain the partition key as well).
Reasons
1) better manageability( like if i want to compress old partitions, then having a gloabl parimary key index would become unusable state)
2) Might increase in select search criteria (assumption)
But having this as local will it impact any performance?
The primary key does include the partitioning column so it could be a local index. But the partitioning column is not the leading column so this would be a local nonprefixed index. Is that what you need or do you need prefixed index?
Have you researched the difference and determined which one you need for your use case?
No. My partition Key would not be in leading column of Primary key. But is there any difference if i not keep partition key as leading column of primary key?
See Local Partitioned Indexes in the VLDB and Partitioning Guide
http://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm
Is rearranging the key columns a good idea? Hard to say without knowing your usage pattern.
Why are you reordering the primary key columns? Why are you putting low cardinality columns first?Well i have read some where quite lot times that having Low cardinality columns as leading coluns would increase performance and later we can get better compression ratios. Let me know if i'm wrong.
You shouldn't be doing either of these without a solid reason. What are the reasons? How do you know that, for your usage pattern, you won't make things worse?
>
2) While creating Partition table i want to give insert /*+ parallel 10 */ into partitiontable select * from DEMAND_DRAFT_STATUS order by CURRENCY_CODE,DD_CRNCY_CODE,PRODUCT_CODE,OT_TYPE,ISSU_BANK_CODE,ISSU_EXTN_CNTR_CODE,ISSUE_DATE,ISSU_BR_CODE,DD_NUM;
Why i'm doing this because index is going to be created on CURRENCY_CODE,DD_CRNCY_CODE,PRODUCT_CODE,OT_TYPE,ISSU_BANK_CODE,ISSU_EXTN_CNTR_CODE,ISSUE_DATE,ISSU_BR_CODE,DD_NUM columns so clustering factore os that index would be good(this is primary key index btw). Is it good?
>
That should give a good initial clustering factor for the index unless a lot of DML is done.
>
3) Once partition is done i want to compress the old partitions, but i'm bit worried that i wont get enough compress ratio if i create partition table with ORDER by clause. whats your thought?
>
You are probably correct since having the low cardinality data first will break things up more. But you are still trying to solve a problem that you don't know even exists. How much space will each partition take if uncompressed? How much if compressed?
At a minimum you should perform a tests for a realistic subset of data (a sample issue date).
1. Create an unordered uncompressed table (new tablespace to make size data more accurate).
2. Create an unordered compressed table
3. Create an ordered uncompressed table
4. Create an ordered compressed table
Yes i have tries to simulate this for 9GB table(only) and size of unordered compressed table is 1.2GB and size of ordered compressed table is 1.9GB out of 9B(uncompressed)
Then you will have a good idea what the space savings might be.
I suggest you first document the issues and problems you are having and list specific goals for any architecture changes.
For partiioning I would focus on identifying the goals, the partition key(s), and the numbers and types (global or local) for the primary key and other indexes.
Application team have already identified the Partitions key on tables which are supposed to be partitioned And they say most of the queries are on those date columns. Secondly as i explained having partition we will keep old partition in compressed state and new partitions in Cell flash cache.
For the primary key index (that includes the partitioning key) determine if you need a prefixed or nonprefixed index.
again whats the difference if i dont have partition key column in leading column of index?
Based on your usage patterns determine the indexes and columns that are the most important for querying. The clustering factor might be ideal for the primary key but totally screwed up for the indexes and queries that really count. You can't get an ideal clustering factor for every index.
The data order for the initial load can be in the order that gives you the best clustering factor for the main index you need it for. That assumes that you actually need the index for a purpose that the clustering factor can help with.Thanks a lot your explanation was helpful.
This setup for tables (i.e. having high # of columns in primary key for example 6-7 out of 15 columns approx in a table) is common for mostly all of the tables which are going to be partition.
And most of the columns in parimary key have 2-3 distinct values out of 1Million rows, so was about to think that i should put them ahead while creating a new primary key (Local) on newly created partition.
While doing this i also take into consideration that i load the data in ORDER BY clause (i.e. order by all columns of PK) to get excellent CF and moreover we could benefit from Storage Index on Exadata. and thanks for inputs too highly appreciated