Re: Sorry, but...

From: Noons <wizofoz2k_at_gmail.com>
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

Original text of this message