Unless there is a clear definition of who wins (i.e.
which schema is absolutely the most important) and a
willingness to sacrifice the work of everyone else,
this is risky business and bound to make you real
unpopular if there is a crash requiring database
recovery. Tablespace point in time recovery is still
full of hidden 'features'.
Lot's of very recent scar tissues on this. We are
considering taking the opposite direction because of
the recovery issue.
- Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
wrote:
>
> The option for tablespace point in time recovery
> might turn out to be useful - equivalent to recovery
> on a per-user basis. The point about files is good
> though - I'm not sure that the theoretical limit of
> 65,000
> can actually be reached in Oracle 8, and performance
> of checkpoints and queries against v$filestat can
> be pretty horrendous after the first 20,000 or so
> files.
>
>
> However I think there are some issues which make
> 'hundreds' of users a liability anyway.
>
> Think how big the rowcache would have to be to
> keep all the dictionary data for hundreds of
> schema.
>
> Think how long the library cache chains could get
> if a large number of users were running textually
> identical SQL that resolved to different objects.
>
> Although the database could handle the strategy
> in terms of notional object limits and simple size,
> I'm not sure that you could avoid process contention
>
> on a remarkable scale.
>
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> Next Seminar - UK, April 3rd - 5th
> http://www.jlcomp.demon.co.uk/seminar.html
>
> Host to The Co-Operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
> Author of:
> Practical Oracle 8i: Building Efficient Databases
>
>
> -----Original Message-----
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> Date: 06 March 2002 23:06
>
>
> |Ben,
> |
> |In addition to Dennis' comments, I would add that
> using a separate
> |tablespace for
> |each user doesn't make much sense to me.
> |
> |What is the perceived benefit of this?
> |
> |Oracle will accomodate a large number of users and
> objects without
> |putting each in their own tablespace. This seems
> like it would just
> |create a lot of extra work for you.
> |
> |An extreme number of database files can have an
> adverse affect
> |on performance as well.
> |
> |Jared
> |
>
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Jonathan Lewis
> INET: jonathan_at_jlcomp.demon.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).
Pete Barnett
Lead Database Administrator
The Regence Group
pnbarne_at_regence.com
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Peter Barnett
INET: regdba_at_yahoo.com
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 Wed Mar 06 2002 - 20:18:23 CST
