Re: ORACLE Data Partitioning?

From: Alan J. Heckman <aheckman_at_us.oracle.com>
Date: 1995/04/10
Message-ID: <3mbt5l$nkp_at_dcsun4.us.oracle.com>#1/1


Joe Minnich (jminnich_at_bugaboo.ssnet.com) wrote:
> In article <3lc1a9$5q1_at_usenet.rpi.edu>, hoffma_at_rpi.edu (Adam Hoffman) writes:
> |> Does anyone out there know if any version of ORACLE can physically
> |> partition a single table into seperate disks based on a data rule?
> |>
> |> Example:
> |>
> |> A very large table which contains 4 fiscal years worth of transactions
> |> would be partitioned onto 4 seperate disks based on fiscal year
> |> with the current fiscal year on the fastest one. When a query is
> |> made against this table using the fiscal year, only the disk where
> |> the applicable fiscal year resides is accessed.
> |>
> |> I know that DB2 can do this but I would like to know if ORACLE can?
> |> Any comments would be appreciated. Thanks.
 

> i do not know of a way in which oracle will currently do this
> type of partitioning for you. you can however strip your tablespace
> across n disks and use the parallel loader to load the individual
> files. indexed access would then achieve what you are looking for.
> i think that oracle is going to continue to improve in this area.
> it is only going to get better. we have done quite alot of work in
> this area - 714 has some "features" that will be enhanced in 716 and 72x.
 

> --
 

> Thanks,
> -------------------------------------------------------
> Joe Minnich jminnich_at_bugaboo.ssnet.com
> System Administrator 302-791-8662
> Electronic Payment Services

You can "partition" by partitioning the data into 4 files readable by SQLLOAD, creating a tablespace with 4 data files, one on each disk if you insist (Although I would still stripe them !!!), and directing SQLLOAD to load the data from each source file to a specific data file within the tablespace (see the file parameter).


| Alan J. Heckman                                                    |
| Email: aheckman_at_us.oracle.com    My opinions...                    |
======================================================================
Received on Mon Apr 10 1995 - 00:00:00 CEST

Original text of this message