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).
Do You Yahoo!?
Received on Fri May 12 2000 - 13:54:21 CDT
