your best bet is to do your reload into a new table, then do a partition switch(I think this is 9i only) or a partition merge to add the new table as a new partition. This will practically eliminate any user downtime.
>
> From: david wendelken <davewendelken_at_earthlink.net>
> Date: 2004/03/22 Mon PM 01:44:53 EST
> To: oracle-l_at_freelists.org
> Subject: Partitioning Question (2 of several)
>
>
> I'm working on an application that can easily be partitioned on one column that exists in most tables in the application.
>
> I know that I may need to load - then truncate and reload - any given new partition.
>
> I need to make sure that the user impact on other partitions is minimal or non-existent.
> (The application will control access to the partitions, so the users won't be able to mess with a partition that is inoperative.)
>
> It appears that local indexes would be a better fit than global ones in order to meet these design requirements.
>
> Do you agree, and if not, why not?
>
> Secondly, there are some reference tables that are not partitioned, and the partitioned tables will have foreign key constraints (with the corresponding indexes) to them. Does that mess up what I am trying to accomplish?
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Mon Mar 22 2004 - 20:06:40 CST
