Re: Sorry, but...
Date: Mon, 16 Jan 2012 19:36:14 -0800 (PST)
Message-ID: <6454e754-6623-4b8b-86e9-6f979c19d758_at_s8g2000pbj.googlegroups.com>
On Jan 16, 3:43 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> schema that initiated it. There must be the place that RDBMS will look
> for the modifications of the table, if it needs a read consistent block
> or if rollback is needed. That space cannot depend on the schema, only on
> the table. Process owned by SYSTEM schema can delete all rows in the
> table SCOTT.EMP. If the schema SCOTT is allowed its own undo tablespace,
> where will a process owned by user HR, who incidentally needs the old
> rows because of the read consistency, look for the old rows? In the
> SCOTT undo tablespace or in the SYSTEM undo tablespace?
Make the undo an attribute of the table. Which defaults to the systemwide
one if there isn't a schema level undo. It's really not that
difficult.
I can compartmentalize and apportion what runs under what in a single
instance as well as I can in RAC, so why not? Note that we are not
talking about a general purpose database usecase.
We are talking about running multiple independent applications in a
single instance.
The same way they can be run in multiple instances of the same
database (RAC).
Ie, apportioned and self-contained.
Presumably, one would think they would not share updates to the same
table, for precisely the same reasons that is not a good idea with RAC
if the main concern is nosebleed performance.
If RAC can run multiple undos in the same db (and share updates!) ,
why can't a single instance? The cynical moah says: to sell more RAC
licenses...
> Temporary tablespaces are different. If you need to perform a hash
> algorithm or a sort algorithm, that's only work space, nobody else will
> ever need it.
Yes, I know that. I used them as just an example of what is shared or not. Received on Mon Jan 16 2012 - 21:36:14 CST