Jak dobrze wiemy, serwer bazy danych Oracle Database zapewnia odtwarzalność realizowanych transakcji poprzez generowanie informacji Redo zapisywanych w dziennikach powtórzeń (redo logs). Gdy zdarzy się awaria, informacje te pozwalają zrekonstruować stan bazy danych będący skutkiem transakcji zrealizowanych przed awarią. Istnieją jednak sytuacje, w których programiście wcale nie zależy na zabezpieczeniu transakcji, a wręcz postrzega on zapisy informacji Redo jako element spowalniający funkcjonowanie całego systemu. Na przykład – podczas zapisywania w bazie danych informacji tymczasowych, które wiążą się z aktualnie realizowanym algorytmem przetwarzania danych i po jego ewentualnej awarii są całkowicie bezużyteczne.
Aby pozwolić programiście na decydowanie, które operacje mają być zabezpieczane przez Redo, a które niekoniecznie, Oracle już kilka wersji temu wprowadził mechanizm tabel tymczasowych – Global Temporary Tables (chociaż lokalnych się już nie doczekaliśmy…). Tabele tymczasowe mają dwie ważne cechy: (1) nie zapewniają trwałości wprowadzonych rekordów, (2) operacje na nich generują mniej Redo niż w przypadku tabel trwałych.
Oto przykład prostego eksperymentu pokazującego ilość informacji Redo generowanych podczas operacji DML na tabeli trwałej (test_perm) i tabeli tymczasowej (test_temp):
SQL> set autotrace on
SQL> create table test_perm as select * from dba_extents where 1=0;
SQL> create global temporary table test_temp on commit delete rows as
select * from dba_extents where 1=0;
SQL> insert into test_perm select * from dba_extents;
...
Statistics
--------------------------------
831896 redo size
SQL> insert into test_temp select * from dba_extents;
...
Statistics
--------------------------------
47360 redo size
Zapisy Redo są wyraźnie mniejsze dla tabeli tymczasowej aniżeli w przypadku tabeli trwałej (a z tabeli trwałej należałoby dodatkowo jeszcze kiedyś te rekordy usunąć!). Nadal jednak są zauważalne. Dlaczego? Otóż wydaje się, że programiści Oracle przeoczyli pewien fakt – wprawdzie operacje DML wykonywane na tabeli tymczasowej nie generują bezpośrednich zapisów Redo, to jednak muszą generować zapisy Undo (zapewnianie spójności transakcji), a te z kolei generują swoje zapisy Redo…
Błąd ten został naprawiony w wersji 12c serwera bazy danych. Wprowadzono mechanizm pozwalający umieszczać Undo operacji na tabelach tymczasowych w przestrzeni tymczasowej (zamiast w przestrzeni wycofania), dzięki czemu nie jest dla nich generowane Redo. Mechanizm ten, nazwany Temporary Undo, należy włączyć za pomocą parametru temp_undo_enabled=true (uwaga na „feature” opisane w http://docs.oracle.com/database/121/ADMIN/undo.htm#ADMIN13741 – „When 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.” ):
SQL> alter session set temp_undo_enabled=true;
SQL> insert into test_temp select * from dba_extents;
...
Statistics
--------------------------------
272 redo size
I nareszcie jesteśmy zadowoleni!