Jak dobrze wiemy, serwer bazy danych Oracle Database zapewnia odtwarzalno\u015b\u0107 realizowanych transakcji poprzez generowanie informacji Redo zapisywanych w dziennikach powt\u00f3rze\u0144 (redo logs). Gdy zdarzy si\u0119 awaria, informacje te pozwalaj\u0105 zrekonstruowa\u0107 stan bazy danych b\u0119d\u0105cy skutkiem transakcji zrealizowanych przed awari\u0105. Istniej\u0105 jednak sytuacje, w kt\u00f3rych programi\u015bcie wcale nie zale\u017cy na zabezpieczeniu transakcji, a wr\u0119cz postrzega on zapisy informacji Redo jako element spowalniaj\u0105cy funkcjonowanie ca\u0142ego systemu. Na przyk\u0142ad \u2013 podczas zapisywania w bazie danych informacji tymczasowych, kt\u00f3re wi\u0105\u017c\u0105 si\u0119 z aktualnie realizowanym algorytmem przetwarzania danych i po jego ewentualnej awarii s\u0105 ca\u0142kowicie bezu\u017cyteczne.<\/p>\n
Aby pozwoli\u0107 programi\u015bcie na decydowanie, kt\u00f3re operacje maj\u0105 by\u0107 zabezpieczane przez Redo, a kt\u00f3re niekoniecznie, Oracle ju\u017c kilka wersji temu wprowadzi\u0142 mechanizm tabel tymczasowych \u2013 Global Temporary Tables (chocia\u017c lokalnych si\u0119 ju\u017c nie doczekali\u015bmy…). Tabele tymczasowe maj\u0105 dwie wa\u017cne cechy: (1) nie zapewniaj\u0105 trwa\u0142o\u015bci wprowadzonych rekord\u00f3w, (2) operacje na nich generuj\u0105 mniej Redo ni\u017c w przypadku tabel trwa\u0142ych.<\/p>\n
Oto przyk\u0142ad prostego eksperymentu pokazuj\u0105cego ilo\u015b\u0107 informacji Redo generowanych podczas operacji DML na tabeli trwa\u0142ej (test_perm) i tabeli tymczasowej (test_temp):<\/p>\n
Zapisy Redo s\u0105 wyra\u017anie mniejsze dla tabeli tymczasowej ani\u017celi w przypadku tabeli trwa\u0142ej (a z tabeli trwa\u0142ej nale\u017ca\u0142oby dodatkowo jeszcze kiedy\u015b te rekordy usun\u0105\u0107!). Nadal jednak s\u0105 zauwa\u017calne. Dlaczego? Ot\u00f3\u017c wydaje si\u0119, \u017ce programi\u015bci Oracle przeoczyli pewien fakt \u2013 wprawdzie operacje DML wykonywane na tabeli tymczasowej nie generuj\u0105 bezpo\u015brednich zapis\u00f3w Redo, to jednak musz\u0105 generowa\u0107 zapisy Undo (zapewnianie sp\u00f3jno\u015bci transakcji), a te z kolei generuj\u0105 swoje zapisy Redo…<\/p>\n B\u0142\u0105d ten zosta\u0142 naprawiony w wersji 12c serwera bazy danych. Wprowadzono mechanizm pozwalaj\u0105cy umieszcza\u0107 Undo operacji na tabelach tymczasowych w przestrzeni tymczasowej (zamiast w przestrzeni wycofania), dzi\u0119ki czemu nie jest dla nich generowane Redo. Mechanizm ten, nazwany Temporary Undo, nale\u017cy w\u0142\u0105czy\u0107 za pomoc\u0105 parametru temp_undo_enabled=true (uwaga na \u201efeature\u201d opisane w http:\/\/docs.oracle.com\/database\/121\/ADMIN\/undo.htm#ADMIN13741 – \u201eWhen a session uses temporary objects for the first time, the current value of the TEMP_UNDO_ENABLED initialization parameter is set for the rest of the session. Therefore, if temporary undo is enabled for a session and the session uses temporary objects, then temporary undo cannot be disabled for the session. Similarly, if temporary undo is disabled for a session and the session uses temporary objects, then temporary undo cannot be enabled for the session.\u201d ):<\/p>\nSQL> set autotrace on
\nSQL> create table test_perm as select * from dba_extents where 1=0;
\nSQL> create global temporary table test_temp on commit delete rows as
\nselect * from dba_extents where 1=0;
\nSQL> insert into test_perm select * from dba_extents;
\n...
\nStatistics
\n--------------------------------
\n831896 redo size
\nSQL> insert into test_temp select * from dba_extents;
\n...
\nStatistics
\n--------------------------------
\n47360 redo size
\n<\/code><\/p>\n