Re: One large tablespace.
- From: Jared Still <jkstill@xxxxxxxxx>
- To: Tom.Terrian@xxxxxxx
- Date: Mon, 14 Nov 2005 18:42:12 +0000
Hi Tom,
The primary reason for multiple tablespaces is management, not performance.
Case in point - a large table that grows extensively and has large amounts
of data periodically removed. Managing space for this table and it's indexes
is less work for the DBA if it is separated from more stable objects in the
DB.
Need to reclaim the space from removing half the data in the table?
No problem - build it in a new tablespace and blow the old one away.
This becomes a bit more work if there are other objects in the TBS.
Partitioning is another example.
HTH
Jared
On 11/14/05, Terrian, Tom (Contractor) (J6D) <Tom.Terrian@xxxxxxx> wrote:
>
> Oracle 10.1.0.4 <http://10.1.0.4>
>
> HPUX 11.11
>
> Backups with RMAN
>
> We have two 250gb RAID 5 mount points that are made up of 5 disk drives
> each. We have been discussing the pros and cons of the following:
>
> 1. Creating 1 large locally managed tablespace (uniform extent size of
> 4m) with a datafile on each mount point for all of our data and indexes.
> Interesting.
>
> 2. Creating lots of locally managed tablespaces with different uniform
> extent sizes (128k, 4m, 128m) with datafiles on each mount point.
>
> Certainly option 2 is the more traditional approach but is there anything
> wrong with option 1. Is it slower? Harder to maintain? Any type of file
> locking problems?
>
> Thanks,
>
> Tom
>
>
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
