| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Partitioning Question (2 of several)
definitely consider using alter table exchange to lessen impact.
if you're not familiar with it, it lets you swap data between a partition and a non-partitioned table. so you load the data into a "temp non-paritioned table", build the needed indexes and then do the exchange, and poof its there(ok pretty darn close to poof).
joe
>
> 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
> -----------------------------------------------------------------
-- 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 - 13:10:54 CST
 |
 |