Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: UNDO Tablespace, and how NOT to use

Re: UNDO Tablespace, and how NOT to use

From: <>
Date: Mon, 06 Aug 2007 00:33:06 -0700
Message-ID: <>

> Do you mean a global temporary table or an imitation of aSQL Server
> trick that kills performance and scalability?
> You mean aSQL Servertype temporary ... stop it. This is Oracle notSQL Serverand what you are doing is both unnecessary and bad practice.
> Likely you need no intermediary table at all but should you need one
> then you should use a global temporary table which is a permanent table
> in which the data is temporary.
> To stop duplicatingSQL Servermethodology get copies of Tom Kyte's
> books and read the sections that relate to temporary tables and general
> concepts and architecture.
> --
> Daniel A. Morgan
> University of Washington
> (replace x with u to respond)
> Puget Sound Oracle Users

I have no doubt that Daniels recomendations around which oracle books to read and which tecniques to employ are correct, his comments re SQL Server are not.

The current SQL Server lock and transaction managers are new code and have been for several releases, they have nothing to do with Sybase never mind Ingres. Daniel appears to forget that SQL Server 2005 includes support for 2 snapshot based isolation levels that address many of his out of date points about SQL Servers lock escalation policies. And finally the VAST majority of customers I have seen using temp tables in almost 10 years of working with SQL Server have nothing to do with locking or transaction isolation models in terms of reasoning. And of course when properly used in SQL Server(just as in Oracle) use of these objects does not automatically equal performance or scale problems. A badly designed and/or implemented database independent of which platform it is, is the cause of poor performance and scale, not the platform itself.

I will happily agree with Daniel that SQL Server customers use more temp tables that Oracle customers and that the usage models do not translate well. Received on Mon Aug 06 2007 - 02:33:06 CDT

Original text of this message