To make that possible, the database needs that undo. The reason is that the undo for global temporary tablespace is required as Oracle needs it in cases an application issues a roll back and Oracle has to provide a read consistent image. For situations in which a developer inserts some information into a global temporary table and then issues a SELECT statement against it, followed by an UPDATE or a DELETE, the rules of read consistency state that the SELECT statement cannot see the effects of the UPDATE or DELETE. why does the changes in temporary tablespace generate undo ? If Oracle wrote a huge code to log these changes there would be some reason, right ? Any guesses ? Now the question is that as this REDO isn’t required for recovery purposes whats the point of writing all that stuff to redo logs i.e. Performing DML on a Global Temporary Table doesn’t generate redo, because the data is stored in a temporary tablespace, but it does generate undo which in turn will generate redo since the undo is stored in a permanent tablespace. Just to clarify this for newbies:-Ī Global Temporary Table stores its data in a Temporary Tablespace where the data is retained for the duration of either a single transaction or the lifetime of a session. We all know that the operations such as INSERT, UPDATE, MERGE, and DELETE on global temporary tables generated redo.

Global temporary table in oracle 10g