Oracle 10G Flashback Features

Maart 2007 - Iedereen die met computers werkt overkomt het wel eens: we raken allemaal wel eens belangrijke gegevens kwijt. Een vervelend fenomeen, vooral als het terughalen van die gegevens een tijdrovend proces is of, nog erger, als uiteindelijk blijkt dat ze voorgoed verdwenen zijn.

Oracle heeft in de loop van de tijd bewezen goede oplossingen te bieden die het ongewenst verlies van data nagenoeg uitsluiten. Om het terughalen van verloren gegevens nog gemakkelijker te maken is in de Oracle database de Flashback technologie geintroduceerd. Flashback biedt een scala aan mogelijkheden om data terug te halen of zelfs, al terug reizend in de tijd, te kunnen bekijken.

Na de introductie van de Flashback Query optie in Oracle server release 9i (zie ook het eerder gepubliceerde Whitebook), zijn in release 10g de Flashback mogelijkheden aanzienlijk uitgebreid. De volgende functionaliteit is nu beschikbaar:

• Flashback Database
• Flashback Database through Resetlogs
• Flashback Table
• Flashback Drop
• Flashback Version Query
• Flashback Transaction Query

Om e.e.a. mogelijk te maken is in Oracle 10g de Flashback Recovery Area geintroduceerd, waarin de voor Flashback benodigde data wordt opgeslagen.

Hieronder volgt een korte uiteenzetting van de nieuwe Oracle 10g Flashback Technology mogelijkheden.

Flashback Database

Deze optie maakt het mogelijk op een eenvoudige manier de stand van de database terug te draaien in de tijd. Was in het verleden nog een restore noodzakelijk van de benodigde bestanden, met Flashback Database kan volstaan worden met het uitvoeren van een beperkt aantal commando’s:

shutdown abort 
startup mount 
flashback database to timestamp    
  to_timestamp(’21-03-2007 21:00:00’,’dd-mm-yyyy hh24:mi:ss’) 
alter database open resetlogs 

Wordt een database teruggezet in de tijd dan gelden dezelfde beperkingen als bij een traditionele Point In Time Recovery (PITR): vanaf het tijdstip waar de database naar terug is gegaan start de database een nieuw leven Alle informatie die na het flashback-punt aanwezig was is verloren.

Om gebruik te kunnen maken van de ingebouwde flashback technologie, moet de database hiervoor geschikt gemaakt worden. Dit kan gedaan worden door het zetten van deze parameters:

DB_RECOVERY_FILE_DEST		(locatie van de Flash Recovery Area) 
DB_RECOVERY_FILE_DEST_SIZE	(beschikbare ruimte voor de logs) 
DB_FLASHBACK_RETENTION_TARGET	(gewenste bewaartijd van de logs) 

Ook moet de database in ArchiveLog Mode draaien. Vervolgens kan Flashback geactiveerd worden:

shutdown abort 
startup mount 
alter database flashback on alter database open 

De keerzijde van deze functionaliteit is dat het een negatieve invloed heeft op de performance van de database. Oracle claimt echter dat dit niet meer dan 2% bedraagt.

Afhankelijk van hoever men in de tijd terug wil kunnen gaan, dient er voldoende diskruimte beschikbaar te zijn in de in Oracle 10g geïntroduceerde ‘Flash Recovery Area’.

Flashback Database through ResetLogs

Dankzij de historische informatie opgeslagen in de Flash Recovery Area is het ook mogelijk in versie 10gR2 een Flashback Database uit te voeren die door een ResetLog punt van de database teruggaat. Met andere woorden, als de herstel operatie vereist dat de database teruggezet wordt in de tijd naar een vorige incarnatie (een vorig leven) van de database kan men zelfs in één operatie terugspoelen naar deze vorige versie dwars door het ResetLog punt heen. Dit was in de voorgaande versies alleen te realiseren door een restore van de oude incarnatie terug te zetten en daarop een Point In Time Recovery uit te voeren.

shutdown abort 
startup mount 
flashback database to before resetlogs 
flashback database to timestamp
  to_timestamp(’21-03-2007 20:00:00’,’dd-mm-yyyy hh24:mi:ss’) 
alter database open resetlogs 

Flashback Table

Met de Flashback Table optie is het mogelijk een of meerdere tabellen terug te zetten in de tijd. Deze operatie kan direct en online uitgevoerd worden, waarbij de aan de tabel gekoppelde objecten zoals indexen, constraints en triggers consistent gehouden worden. Standaard worden door Oracle de triggers tijdens de flashback actie uitgezet. Is dit niet gewenst dan bestaat de mogelijkheid de triggers wel te activeren.

De Flashback Table optie maakt gebruikt van hetzelfde mechanisme als de Flashback Query, namelijk de historische informatie opgeslagen in de UNDO ruimte. Ook hier geldt dat, naarmate men verder terug wil in de tijd, de beschikbare diskruimte voldoende moet zijn. Is dit niet het geval dan zal de flashback operatie niet succesvol verlopen wegens gebrek aan voldoende Undo informatie.

Flashback Drop

Oracle Flashback Drop biedt de mogelijkheid om op een eenvoudige manier een ongewenste verwijdering van een complete tabel ongedaan te maken. Gebruik van Flashback Drop is eenvoudiger en vele malen sneller dan andere recovery opties beschikbaar in deze situatie, zoals Point In Time Recovery.

Als een tabel verwijderd wordt (DROP TABLE), vindt geen fysieke verwijdering plaats. In plaats daarvan worden de tabel en de bijbehorende objecten van naam veranderd en in de zogenaamde RECYCLEBIN geplaatst. Dit is een logische container voor alle verwijderde tabellen en bijbehorende objecten. In werkelijkheid blijven de objecten gewoon waar ze waren. De objecten in de recyclebin kunnen net als alle andere objecten m.b.v. SQL bekeken worden.

Alle objecten blijven in de recyclebin tot het moment dat ze bewust verwijderd worden (PURGE) of tot het moment dat Oracle de beschikbare ruimte nodig heeft voor andere objecten. Op dat moment zal Oracle zoveel objecten verwijderen als nodig is volgens het principe van first in, first out. De situatie dat Oracle ruimte wil vrijmaken wordt “space pressure” genoemd.

Er bestaan wel beperkingen en restricties voor het gebruik van deze functionaliteit. Enkele hiervan zijn:

• recyclebin functionaliteit is alleen beschikbaar voor niet system, locally managed tablespaces
• er is geen garantie hoe lang objecten beschikbaar blijven in de recyclebin
• uitsluitend raadplegen van gegevens in de recyclebin is mogelijk, DML en DDL operaties echter niet
• een tabel en al zijn gerelateerde objecten gaan tegelijk in de recyclebin en worden ook bij een Flashback Drop weer gezamenlijk opgehaald
• referentiele constraints worden niet behouden en moeten achteraf handmatig weer aangemaakt worden

Voorbeeld

drop table t1;  

select object_name,original_name,operation,type from recyclebin;  
OBJECT_NAME                    ORIGINAL_NAME        OPERATION TYPE 
------------------------------ -------------------- --------- ----- 
BIN$LCFfn+2o5bjgQKjAKAslog==$0 IDX1                 DROP      INDEX 
BIN$LCFfn+2p5bjgQKjAKAslog==$0 T1                   DROP      TABLE  

flashback table t1 to before drop;   

select object_name, object_type, created from user_objects;  

OBJECT_NAME                    OBJECT_TYPE         CREATED 
------------------------------ ------------------- --------- 
T1                             TABLE               20-MAR-07 
BIN$LCFfn+2o5bjgQKjAKAslog==$0 INDEX               20-MAR-07 

Na de Flashback Drop is de tabel en zijn gerelateerde objecten weer als normale database objecten beschikbaar. De tabel heeft zijn originele naam weer gekregen, de indexen en eventuele constraints echter niet. Deze kunnen handmatig hernoemd worden.

Flashback Versions Query

Flashback Versions Query biedt de mogelijkheid om over een bepaalde periode rijen in een tabel te bekijken. Oracle slaat de status van een rij op het moment van COMMIT op. Deze versies kunnen vervolgens bekeken worden. Hiervoor wordt gebruik gemaakt van Automatic Undo Management.

Flashback Versions Query kan o.a. gebruikt worden voor auditing doeleinden, voor analyses, maar ook om te achterhalen hoe en wanneer iets gebeurd is.

Om deze informatie op te kunnen halen is het SELECT statement uitgebreid met een VERSION BETWEEN clausule. Ook zijn er additionele kolommen die meer detail informatie geven over de transactie:

• VERSIONS_XID
• VERSIONS_OPERATION
• VERSIONS_STARTSCN
• VERSIONS_ENDSCN
• VERSIONS_STARTTIME
• VERSIONS_ENDTIME

select employee_id, last_name, salary from employees where employee_id = 150;   

EMPLOYEE_ID LAST_NAME                    SALARY  
----------- ------------------------- ---------          
        150 Tucker                        10000   

update employees set salary = salary * 1.1 where employee_id = 150;  
commit;   

update employees set salary = salary * 11 where employee_id = 150;  
commit;   

select salary, versions_xid, versions_operation, versions_startscn,  
  versions_endscn, versions_starttime, versions_endtime  
from employees versions between scn minvalue and maxvalue  
where employee_id = 150; 

   SALARY VERSIONS_XID     V VERSIONS_STARTTIME  
--------- ---------------- - ----------------------     
   121000 01001100CF020000 U 20-MAR-07 08.59.26 PM      
    11000 06002600D1030000 U 20-MAR-07 08.59.26 PM      
    10000  

Flashback Transactions Query

Daar waar Flashback Table Query en Flashback Versions Query de undo data gebruiken om informatie over een object te verkrijgen, gaat Flashback Transaction Query verder. Deze feature haalt alle informatie behorende bij een transactie op, ongeacht het aantal objecten wat ermee gemoeid was. Daarnaast voorziet Flashback Transactions Query je van de benodigde SQL die gebruikt kan worden om eventuele herstel akties mogelijk te maken.

De view die hierbij van belang is heet FLASHBACK_TRANSACTION_QUERY. Gezien het feit dat de data in deze view vertrouwelijk kan zijn is deze beschermd. Het SELECT ANY TRANSACTION privilege moet toegewezen zijn, wil je de data kunnen benaderen. Alleen SYS en de DBA role hebben dit recht automatisch.

Name                                                  Null?    Type 
----------------------------------------------------- -------- -------------- 
XID                                                            RAW(8) 
START_SCN                                                      NUMBER 
START_TIMESTAMP                                                DATE 
COMMIT_SCN                                                     NUMBER 
COMMIT_TIMESTAMP                                               DATE 
LOGON_USER                                                     VARCHAR2(30) 
UNDO_CHANGE#                                                   NUMBER 
OPERATION                                                      VARCHAR2(32) 
TABLE_NAME                                                     VARCHAR2(256) 
TABLE_OWNER                                                    VARCHAR2(32) 
ROW_ID                                                         VARCHAR2(19) 
UNDO_SQL                                                       VARCHAR2(4000) 

Flasback Versions Query en Flashback Transactions Query zijn aan elkaar gerelateerd d.m.v. de XID en de VERSIONS_XID kolommen.

Uitgaande van het voorgaand voorbeeld, willen we meer weten over het feit hoe het salaris opeens 121.000 kon worden. Uit het query resultaat zien we dat transactid id 01001100CF020000 hiervoor verantwoordelijk was. Met dit gegeven benaderen we nu de view:

select LOGON_USER,OPERATION,COMMIT_SCN,COMMIT_TIMESTAMP,UNDO_SQL 
from flashback_transaction_query where XID = hextoraw('01001100CF020000');  

LOGON_USER   OPERATION    COMMIT_SCN COMMIT_TI 
------------ ------------ ---------- --------- 
HR           UPDATE          1653515 20-MAR-07 
HR           BEGIN           1653515 20-MAR-07  

UNDO_SQL 
-----------------------------------------------------------------------
update "HR"."EMPLOYEES" set "SALARY" = '11000' 
  where ROWID = 'AAAMieAAFAAAABYAAy'; 

Naast informatie omtrent wie, wat wanneer gedaan heeft, zien we ook het SQL statement waarmee e.e.a. ongedaan gemaakt kan worden. In dit geval is het slechts 1 statement. Waren er in de transaktie meerdere tabellen geraakt, dan zouden ook hiervoor herstel statements beschikbaar zijn.

Restore Points

Wanneer Point In Time Recovery nodig is, zal bepaald moeten worden tot welk tijdstip of tot welk System Change Number (SCN) dit moet gebeuren. In Oracle10g Release 2 is hiervoor een eenvoudiger alternatief gekomen, namelijk het RESTORE_POINT. Dit is een zelf gekozen naam die een alias is voor een SCN of tijdstip waarmee een bepaalde gebeurtenis gemarkeerd kan worden (bijv. het begin van een lang lopende update, een schema update, etc.). Hiervan kunnen dan weer Flashback Database, Flashback Table en RMAN gebruik maken.

Een groot voordeel van een restore point is dat deze gegarandeerd kan worden. Is bij gebruik van Flashback het slagen van een operatie afhankelijk van de beschikbare Flashback Logs (welke overschreven kunnen zijn door gebrek aan ruimte), bij gegarandeerde restore points zal de benodigde informatie altijd beschikbaar zijn. De logs worden pas weer vrij gegeven als het restore point verwijderd wordt.

Of een restore point gegarandeerd is, kan worden gecontroleerd door de V$RESTORE_POINTS view te raadplegen.

Conclusie

Het behoeft geen betoog dat de Flashback Features van Oracle nieuwe mogelijkheden bieden. Vooral in ontwikkel en testomgevingen kan Flashback gemakkelijk ingezet worden om de stand van de database of tabel snel terug te zetten naar een gewenst punt in de tijd.

Het inzetten van deze technologie in een productie omgeving, dient een weloverwogen besluit te zijn, waarbij zowel de voordelen als de nadelen tegen elkaar afgezet moeten worden.

Flashback Technology biedt interessante mogelijkheden om voorheen complexe en tijdrovende operaties sneller uit te kunnen voeren en dient daarom zeker in overweging genomen te worden.

Meer informatie

• Oracle10g Release 2 New Features Guide
• Oracle10g Release 2 Concepts
• Oracle10g Release 2 Backup and Recovery Basics
• http://www.oracle.com/technology/documentation/database10gr2.html
• http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm