Reference partition

Hi everybody,
I have a little problem with distributed reference partition.
We work with Forte 30L2 and some connected environments, each one
corresponds as a node (a server).
1. ENV-DEVELOP: environment that contains repositories in which developers
are coding applications.
2. ENV-TEST: environment that contains repositories where some users and
help-desk test our applications.
3. ENV-DISTRIB: Super-Environment that contains repositories from where I
distribute, then deploy the versions for each connected env.
4. ENV-PRODUCTION: environment which contains some SO whose communicate
with our mainframes.
5-xx. ENVxx: our remote environments whose use our distributed applications.
The normal flow of our development is:
The developers work in ENV-DEVELOP
Once done, I export pex or cex into the ENV-TEST
Once ok, I export pex or cex into ENV-DISTRIB from where I distribute the
final applications into ENVxx.
In evidence, you imagine that the versions are different between this
consecutive flow.
The only way we can communicate with our mainframe is with ENV-PRODUCTION
where I have any sockets only available from this server. In this server I
have one SO which comes from ENV-DISTRIB (the only way I can distribute
app).
Let's say that this reference partition plan.SO's name is
MF_central.MF_online(CL1).
Now, my problem resides when I have to update and test this reference
partition with the different versions of our client applications (different
environments and repositories).
What I mean is :
Install a new version of MF_central.MF_online(CL2) on ENV-PRODUCTION (from
ENV-DISTRIB)
The source of this plan is the same in ENV-DEVELOP,ENV-TEST and
ENV-DISTRIB.
But I cannot communicate... The scope of this class is not the same.
The only way to run the client app properly is when I distribute the client
app. in the same environment from which I've distributed the ref.part. The
goal is to join this with all our versions of our application.
Thank you very much for your knowledge !

You can't do this with a trigger. And you really, really don't want to.
As you've discovered, Oracle performs a number of checks to determine whether an insert is valid before any triggers are executed. It is going to discover that there is no appropriate partition before your trigger runs. Even if you somehow worked around that problem, it's likely that you'd end up in a rather problematic position from a lock standpoint since you'd be trying to do DDL on the object in the autonomous transaction while doing an insert likely from a stored procedure that would itself be made invalid because of the DDL in another-- that's quite likely to cause an error anyway. And that's before we get into the effects of doing DDL on other sessions running at the same time.
Why do you believe that you need to add partitions dynamically? If you are doing ETL into a data warehouse, it makes sense to add any partitions you need at the beginning of the load before you start inserting the data, not in a trigger. If this is some sort of OLTP application, it doesn't make sense to do DDL while the application is running. I could see potentially having a default partition and then having a nightly job that does a split partition to add whatever list partitions you need but that would strike me as a corner case at best. If you really don't know what the possible values are and users are constantly creating new ones, list partitioning seems like a poor choice to me-- wouldn't a hash partition make more sense?
Justin

Similar Messages

Reference partition with Trigger

This post is an extended version if my previous post -Dynamic Reference partition by Trigger on Feb 24
I need to create a Dynamic Reference partition with Trigger.
Requirement:-
1. It should be a list partition
2. It should be a referencing Partition (There are 2 tables with Parent Child relation)
3. It should be dynamic(trigger) (Whenever new value enter to the List, It should be create a New partition by trigger, As per my understanding interval partitioning is dynamic but it will work only for range partition. )
In other way, I can manually create both the tables with List partition initially itself, but when the new value is added to the List the table supposed to add the new partition. List value is unknown at the time of creation. Since the List value may increase and in future it will be more than five, if it is five we need five partition so partition with a default clause also not possible here.
Almost I have completed this task, but facing some issues. Please find the example i have done. (Please note that it is just an example and not my actual requirement)
==============================================================================================================
--TABLE 1
create table customers
cust_id number primary key,
cust_name varchar2(200),
rating varchar2(1) not null
partition by list (rating)
partition pA values ('A'),
partition pB values ('B')
--TABLE 2
create table sales
sales_id number primary key,
cust_id number not null,
sales_amt number,
constraint fk_sales_01
foreign key (cust_id)
references customers
partition by reference (fk_sales_01);
--TRIGGER
CREATE OR REPLACE TRIGGER CUST_INSERT
BEFORE INSERT ON CUSTOMERS FOR EACH ROW
DECLARE
V_PARTITION_COUNT NUMBER;
V_PART_NAME VARCHAR2 (100) := :NEW.RATING;
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
SELECT COUNT (PARTITION_NAME)
INTO V_PARTITION_COUNT
FROM USER_TAB_PARTITIONS
WHERE TABLE_NAME = 'CUSTOMERS' AND PARTITION_NAME = V_PART_NAME;
IF V_PARTITION_COUNT = 0 THEN
EXECUTE IMMEDIATE 'ALTER TABLE CUSTOMERS ADD PARTITION '||V_PART_NAME||' VALUES ('''||V_PART_NAME||''')' ;
END IF;
END;
--INSERT TO CUSTOMER
insert into customers values (111, 'OOO', 'C');-- A and B are already in the Customer table List along with the create script, so I am inserting new row with 'C'
==============================================================================================================
When i am inserting the new value 'C' to the customer table it supposed to create a new partition along with new row to the table.
But I am getting an error like "ORA-14400: inserted partition key does not map to any partition", like partition is not exist.
But If I execute the same insert statement again it is inserting the row.
That means Even though it is a before insert trigger, insert is trying to happen before the partition creation.
Since it is before insert trigger My expectation is
a) Create a Partition first
b) Insert the record second
But actual behavior is
a) Try to insert first and failing
b) Creating the partition second
That is the reason when I am trying second time the record is getting inserted.
Can anyone help me on this, Thanks in advance.
Shijo

You can't do this with a trigger. And you really, really don't want to.
As you've discovered, Oracle performs a number of checks to determine whether an insert is valid before any triggers are executed. It is going to discover that there is no appropriate partition before your trigger runs. Even if you somehow worked around that problem, it's likely that you'd end up in a rather problematic position from a lock standpoint since you'd be trying to do DDL on the object in the autonomous transaction while doing an insert likely from a stored procedure that would itself be made invalid because of the DDL in another-- that's quite likely to cause an error anyway. And that's before we get into the effects of doing DDL on other sessions running at the same time.
Why do you believe that you need to add partitions dynamically? If you are doing ETL into a data warehouse, it makes sense to add any partitions you need at the beginning of the load before you start inserting the data, not in a trigger. If this is some sort of OLTP application, it doesn't make sense to do DDL while the application is running. I could see potentially having a default partition and then having a nightly job that does a split partition to add whatever list partitions you need but that would strike me as a corner case at best. If you really don't know what the possible values are and users are constantly creating new ones, list partitioning seems like a poor choice to me-- wouldn't a hash partition make more sense?
Justin

Reference partitioning and partition pruning

Hi All,
I am on v 11.2.0.3.
I have a pair of typical parent-child tables. Child table is growing like hell, hence we want to partition it, which will be used for deleting/dropping old data later on.
There is no partitioning key in the child table which I can use for relating the data to the time when data was created. So, I thought I can use the timestamp from parent table for partitioning the parent table and reference partition the child table.
I am more concerned about the child table (or the queries running on the child table) in terms of performance. ITEM_LIST_ID from the child table is extensively used in queries to access data from child table.
How will partition pruning work when the child table is queried on the foreign key? will it every time go to the parent table, find out the partition and then resolve the partition for child table?
The setup is given in the scripts below, will it cause lot of locking (to resolve partitions)? or am I worrying for nothing?
Here are the scripts
CREATE TABLE ITEM_LISTS /* Parent table, tens of thousands of records */
ITEM_LIST_ID    NUMBER(10)     NOT NULL PRIMARY KEY, /* Global index on partitioned table !!! */
LIST_NAME       VARCHAR2(500) NOT NULL,
FIRST_INSERTED TIMESTAMP(6)   NOT NULL
PARTITION BY RANGE ( FIRST_INSERTED )
partition p0 values less than ( to_date('20130101','YYYYMMDD') ),
partition p201301 values less than ( to_date('20130201','YYYYMMDD') ),
partition p201302 values less than ( to_date('20130301','YYYYMMDD') ),
partition p201303 values less than ( to_date('20130401','YYYYMMDD') ),
partition p201304 values less than ( to_date('20130501','YYYYMMDD') ),
partition p201305 values less than ( to_date('20130601','YYYYMMDD') )
CREATE INDEX ITEM_LISTS_IDX1 ON ITEM_LISTS ( LIST_NAME ) LOCAL ;
CREATE TABLE ITEM_LIST_DETAILS /* Child table, millions of records */
ITEM_ID        NUMBER(10)     NOT NULL,
ITEM_LIST_ID   NUMBER(10)     NOT NULL, /* Always used in WHERE clause by lots of big queries */
CODE           VARCHAR2(30)   NOT NULL,
ALT_CODE       VARCHAR2(30)   NOT NULL,
CONSTRAINT   ITEM_LIST_DETAILS_FK
FOREIGN KEY ( ITEM_LIST_ID ) REFERENCES ITEM_LISTS
PARTITION BY REFERENCE ( ITEM_LIST_DETAILS_FK )
CREATE INDEX ITEM_LIST_DETAILS_IDX1 ON ITEM_LIST_DETAILS (ITEM_ID) LOCAL;
CREATE INDEX ITEM_LIST_DETAILS_IDX2 ON ITEM_LIST_DETAILS (ITEM_LIST_ID, CODE) LOCAL;Any thoughts / opinions / corrections ?
Thanks in advance

To check how partition pruning works here, I inserted some data in these tables. Inserted data in ITEM_LISTS (parent) from DBA_OBJECTS ( object_id => item_list_id, object_name => list_name, first_inserted => manually created). Also created corresponding child data in ITEM_LIST_DETAILS, so that, for every item_list_id in parent about 5000 records go in child table.
Looking at the queries and plan below, my question is, what exactly does the operations "PARTITION REFERENCE SINGLE" and "PARTITION REFERENCE ITERATOR" imply ??
I gave a search on "PARTITION REFERENCE ITERATOR" in Oracle 11.2 documentation, it says "No exact match found" !!
/* Direct query on child table */
SQL> select count(*) from item_list_details where item_list_id = 6323 ;
COUNT(*)
      5000
1 row selected.
Execution Plan
Plan hash value: 2798904155
| Id | Operation                   | Name                   | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT            |                        |     1 |     5 |    22   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE             |                        |     1 |     5 |            |          |       |       |
|   2 |   PARTITION REFERENCE SINGLE|                        | 5000 | 25000 |    22   (0)| 00:00:01 |   KEY |   KEY |
|* 3 |    INDEX RANGE SCAN         | ITEM_LIST_DETAILS_IDX2 | 5000 | 25000 |    22   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
   3 - access("ITEM_LIST_ID"=6323)
SQL> select * from temp1; /* Dummy table to try out some joins */
OBJECT_ID OBJECT_NAME
      6598 WRH$_INTERCONNECT_PINGS
1 row selected.
/* Query on child table, joining with some other table */
SQL> select count(*)
2 from temp1 d, ITEM_LIST_DETAILS i1
3 where d.object_id = i1.item_list_id
4 and d.object_name = 'WRH$_INTERCONNECT_PINGS';
COUNT(*)
      5000
1 row selected.
Execution Plan
Plan hash value: 2288153583
| Id | Operation                      | Name                   | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
|   0 | SELECT STATEMENT               |                        |     1 |    70 |    24   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE                |                        |     1 |    70 |            |       | |       |
|   2 |   NESTED LOOPS                 |                        | 5000 |   341K|    24   (0)| 00:00:01 |       |       |
|* 3 |    TABLE ACCESS FULL           | TEMP1                  |     1 |    65 |     3   (0)| 00:00:01 |       |       |
|   4 |    PARTITION REFERENCE ITERATOR|                        | 5000 | 25000 |    21   (0)| 00:00:01 |   KEY |   KEY |
|* 5 |     INDEX RANGE SCAN           | ITEM_LIST_DETAILS_IDX2 | 5000 | 25000 |    21   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
   3 - filter("D"."OBJECT_NAME"='WRH$_INTERCONNECT_PINGS')
   5 - access("D"."OBJECT_ID"="I1"."ITEM_LIST_ID")

Reference partitioning?

If I have tables
A, B, C where I have 1->M->M
if I have reference partitioning everything ends up in the same partition based on A's partitioning defintion.
If when I query I only specify the partition key to quality C when I'm joining from A to B to C is the optimizer smart enough to know that everything is in the same partition and therefore even if I do like '%some state about an A' that that will result in only a full partition scan and not a full table scan? because the query has qualified C also with the partition key?
Is this a classic case of where reference partitioning is desired because you're qualfying your query only at the lowest level but you risk doing full table scans at the highest level because the query often uses wildcards and work top down instead of bottom up without this form of partitioning?
The alternative approach was to push the state '%some state about an A' down into C's table and instead of qualifying
A with wildcards you'd change that to C with wildcards with the same column. So the optimizer is smart enough to work bottom up instead of top down.
If you just have range partitions on all three tables. Why does the optimizer choose to do a full table scan on A when you use like '%some state about an A' even when you're joining to a C thru a B and specifying the partition key for the C in the query?
What Oracle SQL hints forces it to follow the partition key and not try to evaluate the query top down by first tablescanning A? Instead you want it to figure out from the C's what the B's are and then from the B's narrow to the full set of a A's and then using the wildcard pattern on the all the rowid's for A.
ie. bottom up instead of top down.
The idea then is that you avoid full tablescans on A.
Top down results in a full table scan
Bottom up results in a full partition scan only.
Edited by: steffi on Jan 19, 2011 9:08 PM

It sounds like you've found that it is not working to push the predicate on the partition key up to A, and therefore prune partitions on A. Do you have an explain plan to demonstrate that? I wouldn't be very suprised (though I would be disappointed) to find that it was so as I think the optimizer might reasonably assume that the partition pruning predicate could (should?) be placed on the parent table as easily as on the child.

Reference partitioning - thoughts

Hi,
At moment we use range-hash partitioning of a large dimension table (dimension model warehouse) table with 2 levels - range partitioned on columns only available at bottom level of hierarchy - date and issue_id.
Result is a partition with null value - assume would get a null partition in large fact table if was partitioned with reference to the large dimension.
Large fact table similarly partitioned date range-hash local bitmap indexes
Suggested to use would get automatic partition-wise joins if used reference partitioning
Would have thought would get that with range-hash on both dimension
Any disadvtanatges with reference partitioning.
Know can't us range interval partitioning.
Thanks

>
At moment, the large dimension table and large fact table are have the same partitioning strategy but partitioned independently(range-hash)
the range column is a date datatype and the hash column is the surrogate key
>
As long as the 'hash column' is the SAME key value in both tables there is no problem. Obviously you can't hash on one column/value in one table and a different one in the other table.
>
With regards null values the dimesnion table has 3 levels in it (part of a dimensional model data wqarehouse)i.e. the date on which tabel partitioned is only at the loest level of the diemnsion.
>
High or low doesn't matter and, as you ask in your other thread (Order of columsn in table - how important from performance perspective the column order generally doesn't matter.
>
By default in a diemsnional model data warehouse, this attribute not populated in the higher levels therefore is a default null value in the dimension table for such records
>
Still not clear what you mean by this. The columns must be populated at some point or they wouldn't need to be in the table. Can you provide a small sample of data that shows what you mean?
>
The problem the performance team are attempting to solve is as follows:
the tow tables are joined on the sub-partition key, they have tried joined the two tables together on the entire partition key but then complained they don'y get star transformation.
>
Which means that team isn't trying to 'solve' a problem at all. They are just trying to mechanically achieve a 'star transformation'.
A full partition-wise join REQUIRES that the partitioning be on the join columns or you need to use reference partitioning. See the doc I provided the link for earlier:
>
Full Partition-Wise Joins
A full partition-wise join divides a large join into smaller joins between a pair of partitions from the two joined tables. To use this feature, you must equipartition both tables on their join keys, or use reference partitioning.
>
They believe that by partitioning by reference as opposed to indepently they will get a partition-wise join automatically.
>
They may. But you don't need to partition by reference to get partition-wise joins. And you don't need to get 'star transformation' to get the best performance.
Static partition pruning will occur, if possible, whether a star transformation is done or not. It is dynamic pruning that is done AFTER a star transform. Again, you need to review all of the relevant sections of that doc. They cover most of this, with example code and example execution plans.
>
Dynamic Pruning with Star Transformation
Statements that get transformed by the database using the star transformation result in dynamic pruning.
>
Also, there are some requirements before star transformation can even be considered. The main one is that it must be ENABLED; it is NOT enabled by default. Has your team enabled the use of the star transform?
The database data warehousing guide discusses star queries and how to tune them:
http://docs.oracle.com/cd/E11882_01/server.112/e25554/schemas.htm#CIHFGCEJ
>
Tuning Star Queries
To get the best possible performance for star queries, it is important to follow some basic guidelines:
A bitmap index should be built on each of the foreign key columns of the fact table or tables.
The initialization parameter STAR_TRANSFORMATION_ENABLED should be set to TRUE. This enables an important optimizer feature for star-queries. It is set to FALSE by default for backward-compatibility.
When a data warehouse satisfies these conditions, the majority of the star queries running in the data warehouse uses a query execution strategy known as the star transformation. The star transformation provides very efficient query performance for star queries.
>
And that doc section ALSO has example code and an example execution plan that shows that the star transform is being use.
That also also has some important info about how Oracle chooses to use a star transform and a large list of restrictions where the transform is NOT supported.
>
How Oracle Chooses to Use Star Transformation
The optimizer generates and saves the best plan it can produce without the transformation. If the transformation is enabled, the optimizer then tries to apply it to the query and, if applicable, generates the best plan using the transformed query. Based on a comparison of the cost estimates between the best plans for the two versions of the query, the optimizer then decides whether to use the best plan for the transformed or untransformed version.
If the query requires accessing a large percentage of the rows in the fact table, it might be better to use a full table scan and not use the transformations. However, if the constraining predicates on the dimension tables are sufficiently selective that only a small portion of the fact table must be retrieved, the plan based on the transformation will probably be superior.
Note that the optimizer generates a subquery for a dimension table only if it decides that it is reasonable to do so based on a number of criteria. There is no guarantee that subqueries will be generated for all dimension tables. The optimizer may also decide, based on the properties of the tables and the query, that the transformation does not merit being applied to a particular query. In this case the best regular plan will be used.
Star Transformation Restrictions
Star transformation is not supported for tables with any of the following characteristics:
>
Re reference partitioning
>
Also this is a data warehouse star model and mentioned to us that reference partitioning not great with local indexes - the large fact table has several local bitmpa indexes.
Any thoughts on reference partitioning negatively impacting performance in this way compared to standalone partitioned table.
>
Reference partitioning is for those situations where your child table does NOT have a column that the parent table is being partitioned on. That is NOT your use case. Dont' use reference partitioning unless your use case is appropriate.
I suggest that you and your team thoroughly review all of the relevant sections of both the database data warehousing guide and the VLDB and partitioning guide.
Then create a SIMPLE data model that only includes your partitioning keys and not all of the other columns. Experiment with that simple model with a small amount of data and run the traces and execution plans until you get the behaviour you think you are wanting.
Then scale it up and test it. You cannot design it all ahead of time and expect it to work the way you want.
You need to use an iterative approach. That starts by collecting all the relevant information about your data: how much data, how is it organized, how is it updated (batch or online), how is it queried. You already mention using hash subpartitioning but haven't posted ANYTHING that indicates you even need to use hash. So why has that decision already been made when you haven't even gotten past the basics yet?

Unable to choose foreign key when creating reference partition

Hello
I have 2 foreign keys on a table. I am trying to choose the 2nd foreign key when creating a reference partition. I am unable to select the required foreign key.
The model has Table A -> Table B -> Table C. Table A has a list partition. Table B is the child of Table A. I created a reference partition on Table B. Table C is child of Table B. There are 2 FKs on table C. I am unable to choose the required FK to create reference partition on table C.
SQL Developer version - 3.0.0.665
Any help would be appreciated.

Hi,
The FK that can be selected is normally the oldest FK that was created for the Table.
So one option would be to delete and then recreate the FK that is selectable. This process may need to be repeated if there are several FKs that are "older" than the one you wish to use for Reference Partitioning.
David

Will JDeveloper support INTERVAL and REFERENCES partitioning methods soon?

JDeveloper is a fantastic tool, and I'm very impressed with its data modeling capabilities as they are quite robust. However, currently its support for Table Partitioning is limited to the feature level of Oracle 10g, as it does not support 11g INTERVAL or REFERENCES partitioning methods, nor the Composite List partitioning methods List-Range, List-Hash, and List-List.
Any idea when JDeveloper will support these Partitioning enhancements available in Oracle Database 11g? If it's in the works, I'd be happy to help beta test it!
Best regards,
Terry

Hi Terry
I love it that you are working with the data modeling and would love to hear how you are using it. Please email me direct with more info
We are working to get composite partitions (11g) into a future release but I don't have any timeframe for you at the moment.
rgds
Susan Duncan
Product Manager
susan.duncan@oracle

Reference partitioning in 11g

I am reading the Reference partitioning in 11g, it says "The child table is partitioned using the same partitioning key as the parent table without having to duplicate the key columns."
Does this mean the key column value is also not duplicated on disk ?

I am reading the Reference partitioning in 11g, it says "The child table is partitioned using the same partitioning key as the parent table without having to duplicate the key columns."
Does this mean the key column value is also not duplicated on disk ?
It means that you, the user, do not need to duplicate the parent table's partitioning key columns in the child table.
Did you review the examples provided in the 'Reference Partitioning' section of the VLDB and Partitioning doc?
http://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm#sthref60
Reference partitioning allows the partitioning of two tables related to one another by referential constraints. The partitioning key is resolved through an existing parent-child relationship, enforced by enabled and active primary key and foreign key constraints.
The benefit of this extension is that tables with a parent-child relationship can be logically equi-partitioned by inheriting the partitioning key from the parent table without duplicating the key columns. The logical dependency will also automatically cascade partition maintenance operations, thus making application development easier and less error-prone.
Immediately following that description is an example.

How to use Oracle partitioning with JPA @OneToOne reference?

Hi!
A little bit late in the project we have realized that we need to use Oracle partitioning both for performance and admin of the data. (Partitioning by range (month) and after a year we will move the oldest month of data to an archive db)
We have an object model with an main/root entity "Trans" with @OneToMany and @OneToOne relationships.
How do we use Oracle partitioning on the @OneToOne relationships?
(We'd rather not change the model as we already have millions of rows in the db.)
On the main entity "Trans" we use: partition by range (month) on a date column.
And on all @OneToMany we use: partition by reference (as they have a primary-foreign key relationship).
But for the @OneToOne key for the referenced object, the key is placed in the main/source object as the example below:
@Entity
public class Employee {
@Id
@Column(name="EMP_ID")
private long id;
@OneToOne(fetch=FetchType.LAZY)
@JoinColumn(name="ADDRESS_ID")
private Address address;
EMPLOYEE (table)
EMP_ID FIRSTNAME LASTNAME SALARY ADDRESS_ID
1 Bob Way 50000 6
2 Sarah Smith 60000 7
ADDRESS (table)
ADDRESS_ID STREET CITY PROVINCE COUNTRY P_CODE
6 17 Bank St Ottawa ON Canada K2H7Z5
7 22 Main St Toronto ON Canada L5H2D5
From the Oracle documentation: "Reference partitioning allows the partitioning of two tables related to one another by referential constraints. The partitioning key is resolved through an existing parent-child relationship, enforced by enabled and active primary key and foreign key constraints."
How can we use "partition by reference" on @OneToOne relationsships or are there other solutions?
Thanks for any advice.
/Mats

Crospost! How to use Oracle partitioning with JPA @OneToOne reference?

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.

Partitioning A table on a data column

Hi,
My requirement is to partition a table using a column with DATE datatype.
Example:
CREATE TABLE parttab
STATUS CHAR(1) DEFAULT 'a' NOT NULL,
UPDATER VARCHAR2(55) NOT NULL,
UPDTIME DATE DEFAULT SYSDATE NOT NULL
TABLESPACE part_tbs
Now i want to RANGE partition the above table on the "UPDTIME" column, so that it will look like:
Partition Value from Value till
P1 01-Jan 31-Mar
P2 01-Apr 30-Jun
P3 01-Jul 30-Sep
P4 MAXVALUE
I tried using the below syntax, but failed with error.
CREATE TABLE parttab
STATUS CHAR(1) DEFAULT 'a' NOT NULL,
UPDATER VARCHAR2(55) NOT NULL,
UPDTIME DATE DEFAULT SYSDATE NOT NULL
TABLESPACE part_tbs
LOGGING
PARTITION BY RANGE (UPDTIME)
PARTITION P1 VALUES LESS THAN (to_date('04','MM')) LOGGING COMPRESS TABLESPACE part_tbs_P1,
PARTITION P2 VALUES LESS THAN (to_date('07','DD-MM')) LOGGING COMPRESS TABLESPACE part_tbs_P2,
PARTITION P3 VALUES LESS THAN (to_date('10','DD-MM')) LOGGING COMPRESS TABLESPACE part_tbs_P3,
PARTITION P4 VALUES LESS THAN (MAXVALUE) LOGGING COMPRESS TABLESPACE part_tbs_P4
COMPRESS
NOCACHE
PARALLEL ( DEGREE 2 INSTANCES Default )
ROWDEPENDENCIES
NOMONITORING
ENABLE ROW MOVEMENT;
Please suggest.
Thanks in advance for the suggestions.

what is the error message and your Oracle version? this sample may assist I guess -
CREATE TABLE range_part (
prof_history_id NUMBER(10),
person_id       NUMBER(10) NOT NULL,
organization_id NUMBER(10) NOT NULL,
record_date     DATE NOT NULL,
ph_comments     VARCHAR2(200))
PARTITION BY RANGE (record_date) (
PARTITION yr0 VALUES LESS THAN (TO_DATE('01-JAN-2000','DD-MON-YYYY'))
TABLESPACE part1,
PARTITION yr1 VALUES LESS THAN (TO_DATE('01-JAN-2001','DD-MON-YYYY'))
TABLESPACE part2,
PARTITION yr2 VALUES LESS THAN (TO_DATE('01-JAN-2002','DD-MON-YYYY'))
TABLESPACE part3,
PARTITION yr9 VALUES LESS THAN (MAXVALUE) TABLESPACE part4);for more examples you may visit - http://psoug.org/reference/partitions.html

Slow inserts into partitioned table

I am having trouble inserting into a simple partitioned table after an upgrade to 11.2.0.3. I'm seeing insert speeds of subsecond up to 10 and 12 seconds. We have pre created the partitions for this table (and all children via reference partitioning). We have gathered dictionary and static object stats as well as statistics on all partitions.
Queries against the dictionary are incredibly slow as well and showing very high io.
Any help would be greatly appreciated. Thank you for your time.
Windows 2008 advanced server
Oracle Enterprise edition 11.2.0.3
Edited by: user593549 on Mar 26, 2012 11:16 AM

user593549 wrote:
I am having trouble inserting into a simple partitioned table after an upgrade to 11.2.0.3. I'm seeing insert speeds of subsecond up to 10 and 12 seconds. We have pre created the partitions for this table (and all children via reference partitioning). We have gathered dictionary and static object stats as well as statistics on all partitions.
Queries against the dictionary are incredibly slow as well and showing very high io.
Any help would be greatly appreciated. Thank you for your time.
Windows 2008 advanced server
Oracle Enterprise edition 11.2.0.3
Edited by: user593549 on Mar 26, 2012 11:16 AMThread: HOW TO: Post a SQL statement tuning request - template posting
HOW TO: Post a SQL statement tuning request - template posting

Jdev 11g defect: Error creating partition table diagram

I'm running Jdev 11.1.1.0.2 on JDK 1.6.0_06
When attempting to drag partitioned table from DB connection onto a DB Diagram I'm getting the following exception. Anybody got similar experience?
Also every time I create new diagram or off-line DB JDev starts spinning at 40 - 50 % CPU and gets stuck, so I have to "kill" the process and restart it. After which it works fine. Could it be some JDK compatibility issue?
May 13, 2009 4:09:54 PM oracle.ide.db.transfer
SEVERE: Prepare failed
java.lang.NullPointerException
     at oracle.javatools.db.ora.OracleTableBuilder.getOracleTablePartitions(OracleTableBuilder.java:584)
     at oracle.javatools.db.ora.OracleTableBuilder.buildNonBaseProperties(OracleTableBuilder.java:406)
     at oracle.javatools.db.ora.OracleTableBuilder.fillInObject(OracleTableBuilder.java:76)
     at oracle.javatools.db.AbstractDBObjectBuilder.buildObject(AbstractDBObjectBuilder.java:36)
     at oracle.javatools.db.dictionary.DictionaryDBObjectBuilder.buildObject(DictionaryDBObjectBuilder.java:55)
     at oracle.javatools.db.AbstractSchemaObject.checkInitEx(AbstractSchemaObject.java:229)
     at oracle.javatools.db.AbstractSchemaObject.checkInit(AbstractSchemaObject.java:144)
     at oracle.javatools.db.AbstractSchemaObject.checkInit(AbstractSchemaObject.java:267)
     at oracle.javatools.db.AbstractSchemaObject.copyToImpl(AbstractSchemaObject.java:64)
     at oracle.javatools.db.Table.copyTo(Table.java:81)
     at oracle.javatools.db.AbstractDBObject.copyTo(AbstractDBObject.java:90)
     at oracle.jdevimpl.offlinedb.transfer.OffToOffPolicy.copyForTransfer(OffToOffPolicy.java:192)
     at oracle.jdevimpl.offlinedb.transfer.OnToOffPolicy.copyForTransfer(OnToOffPolicy.java:134)
     at oracle.ide.db.transfer.TransferManager.prepare(TransferManager.java:158)
     at oracle.ide.db.transfer.TransferManager.prepareAndTransfer(TransferManager.java:418)
     at oracle.ideimpl.db.transfer.TransferRunnable.run(TransferRunnable.java:79)
     at oracle.ide.dialogs.ProgressBar.run(ProgressBar.java:643)
     at java.lang.Thread.run(Thread.java:619)

Hi nfk,
Are the tables in the question reference-partitioned?
I am able to reproduce the exception when copying to project the online reference partitioned tables to offline , and I have logged a bug for it.
Please give the details of the tables like partition type if your scenario is different.
As for the other issue , I have not seen any performance issues with DB diagram ..I have tried on jdk1.6.0_06 and jdk160_11.if it is reproducible, please add your machine configuration.
Many Thanks,
Geetha
Edited by: user647112 on May 15, 2009 5:19 AM

Suggestions for table partition for existing tables.

I have a table as below. This table contains huge data. This table has so many child tables .I am planning to do a 'Reference Partitioning' for the same.
create table PROMOTION_DTL
PROMO_ID              NUMBER(10) not null,
EVENT                 VARCHAR2(6),
PROMO_START_DATE      TIMESTAMP(6),
PROMO_END_DATE        TIMESTAMP(6),
PROMO_COST_START_DATE TIMESTAMP(6),
EVENT_CUT_OFF_DATE    TIMESTAMP(6),
REMARKS               VARCHAR2(75),
CREATE_BY             VARCHAR2(50),
CREATE_DATE           TIMESTAMP(6),
UPDATE_BY             VARCHAR2(50),
UPDATE_DATE           TIMESTAMP(6)
alter table PROMOTION_DTL
add constraint PROMOTION_DTL_PK primary key (PROMO_ID);
alter table PROMOTION_DTL
add constraint PROMO_EVENT_FK foreign key (EVENT)
references SP_PROMO_EVENT_MST (EVENT);
-- Create/Recreate indexes
create index PROMOTION_IDX1 on PROMOTION_DTL (PROMO_ID, EVENT)
create unique index PROMOTION_PK on PROMOTION_DTL (PROMO_ID)
-- Grant/Revoke object privileges
grant select, insert, update, delete on PROMOTION_DTL to SCHEMA_RW_ROLE;I would like to partition this table .Most of the queries contains the following conditions.
promo_end_date >=   SYSDATE
and
(event = :input_event OR
(:input_Start_Date <= promo_end_date
AND promo_start_date <= :input_End_Date))Any time the promotion can be closed by updating the PROMO_END_DATE.
Interval partioning on PROMO_END_DATE is not possible as PROMO_END_DATE is a nullable and updatable field.
I am now to table partition.
Any suggestions are welcome...

DO NOT POST THE SAME QUESTION IN MULTIPLE FORUMS PLEASE!
Suggestions for table partition of existing tables

REF partitioning is affecting on complex queries

Hi,
I am having 7 tables consider A,B,C,D,E,F,G. whereas A is master table and others are dependent on table A. columnA is referential key for all tables. Table A is having one DateRange column.
I have successfully created range partitioning with partitioning key is DateRange. and Refeernce partitioning on other tables with column referring to ColumnA with foreign key.
Also created local indexes on partitioned key DateRange.
Problem is that, while fetching complex queries for reports, it is taking more time as compared to non partitioning structure. Is ref partitioning affecting on complex queries, queries returning more rows ??? Please suggest me about it.
Thanks,
Avinash.

Did I miss anything ?Depends on what you've read about it sofar and why you decided to implement it.
http://www.oracle-base.com/articles/11g/partitioning-enhancements-11gr1.php#reference_partitioning
"The following conditions and restrictions apply to reference partitioning:
The child table must specify a referential integrity constraint defined on the table being created. This constraint must be in ENABLE VALIDATE NOT DEFERRABLE state (the default) and refer to a primary or unique key on the parent table.
The foreign key columns referenced in constraint must be NOT NULL.
The constraint cannot use the ON DELETE SET NULL clause.
The parent table referenced must be an existing partitioned table. All partitioning methods except interval partitioning are supported.
The foreign key cannot contain any virtual columns.
The referenced primary key or unique constraint on the parent table cannot contain any virtual columns.
Reference partitioning cannot be used for index-organized tables, external tables, or domain index storage tables.
A chain of reference partitioned tables can be created, but constraint used can't be self-referencing.
The ROW MOVEMENT setting for both tables must match.
Reference partitioning cannot be specified in a CREATE TABLE ... AS SELECT statement."

Reference partition

Similar Messages

Maybe you are looking for