True, a partitioned table is generally spread across several tablespaces, and
I've done that. But on the other hand, I don't have just one partition of one
table in a tablespace, but all partitions of related tables in the same
tablespace. This way I have only one tablespace to mess with when doing
periodic maintenance which was the intent. Also, although I like the idea of
one application per tablespace I also share the opinion of breaking a very large
application up across several tablespaces based on the activity of the
underlying tables. I like to group tables as reference, low activity and high
activity. Define "activity" as the amount of insert, update, delete actions
taken on the tables. Again, when maintenance time comes you only have to mess
with one tablespace at a time. I still don't like the ides of one table per
tablespace.
____________________Reply Separator____________________
Subject: RE: TSPITR and one table per tablespace
Author: "A. Bardeen" <abardeen1_at_yahoo.com>
Date: 5/12/00 11:54 AM
And what, pray tell, is one of the common
implementations of a partitioned table, but to put
each partition into its own tablespace?
I agree that it would be pretty foolish in an OLTP db
which is likely to have thousands of tables (ever
worked with a BAAN db?!), but for DSS environments
with a small number of very large tables this doesn't
seem so foolish, especially if running Oracle7 where
partitioned tables aren't available.
Just playing devil's advocate ;)
- Anita
- Stephen Dance <steved_at_capbankcf.co.uk> wrote:
> I agree that putting every table in its own Tspace
> is a pretty Dilbert
> thing to do.
>
> However, we run Peoplesoft and had I the disk
> spindles available, there
> are at least a dozen or so of the most heavily hit
> tables which I would
> cheerfully put individually on their own Tspace on
> their own spindle.
>
> Sometimes when I see the disk activity on the RAID
> subsystem I think it
> might go into meltdown.
>
> >----------
> >From: dgoulet_at_vicr.com[SMTP:dgoulet_at_vicr.com]
> >Sent: May 12 2000 15:48
> >To: Multiple recipients of list ORACLE-L
> >Subject: Re:TSPITR and one table per tablespace
> >
> >Kapil,
> >
> > I'm sure that some of the list members will
> disagree with me, but that is
> >one of the most Dilbert ideas I've heard since the
> VARCHAR2(255) idea.
> >Assuming
> >you implement such an idea, consider that each
> tablespace MUST consist of at
> >least one file and that files CANNOT be shared
> across tablespaces. That
> >means
> >that you need one data file for each table. Now
> the question becomes, how
> >many
> >tables do you have and how many files will the OS
> let you have open at one
> >time?? The former will be larger that the latter
> in a short time.
> >Personally I
> >like isolating one application to one tablespace as
> a minimum. That way, if
> >I
> >have to recover a tablespace then at least that
> application should be
> >consistent
> >when I'm done. Consider our PeopleSoft application
> with more than 2000
> >tables???
> >
> >Sheesh, what did you buy? A sophisticated RDBMS or
> a very expensive file
> >manager??
> >
> >Dick Goulet
> >Senior Oracle DBA
> >Vicor Corporation
> >
> >
> --
> Author: Stephen Dance
> INET: steved_at_capbankcf.co.uk
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from). You may
> also send the HELP command for other information
> (like subscribing).
Received on Sat May 13 2000 - 12:13:34 CDT