Re: Sorry, but...

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Mon, 16 Jan 2012 04:43:49 +0000 (UTC)
Message-ID: <pan.2012.01.16.04.43.48_at_gmail.com>



On Sun, 15 Jan 2012 17:28:03 -0800, Noons wrote:

> or do the same as temp tablespaces: assign a set of schemas to each.
> I do multiple temps all the time, one for each application set.
> Why can't I do the same for undo?

It cannot be done for the undo, because undo records store the previous values (sort of) for the rows. Any transaction with enough privilege to modify the table can modify the rows in the table, regardless of the 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?

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.

-- 
http://mgogala.byethost5.com
Received on Sun Jan 15 2012 - 22:43:49 CST

Original text of this message