overkomt een ieder wel eens dat hij gegevens kwijt raakt en vervolgens uren
bezig is om deze gegevens weer terug te krijgen of erger het blijkt dat ze voorgoed verdwenen zijn.

Oracle heeft voldoende oplossingen geboden die dit nagenoeg uitsluit. Om het terughalen van deze gegevens nog makkelijker te maken heeft Oracle de Flashback technologie geïntroduceerd. Dit biedt de dba tal van mogelijkheden om de verloren data terug te halen.

Na de introductie van de Flashback Query optie in Oracle 9, 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 deze opties mogelijk te maken is in Oracle 10g de Flashback Recovery Area geïntroduceerd, waarin de data die nodig is voor Flashback wordt opgeslagen.

Flashback Database

In het verleden was het noodzakelijk om een restore van de database uit te voeren om terug in de tijd te kunnen gaan. Met de optie Flashback Database is het uitvoeren van een aantal commando’s genoeg om dit voor elkaar te krijgen:

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

Indien de database middels Flashback database is teruggezet, gelden dezelfde beperkingen als met een Point In Time Recovery (PITR): vanaf het tijdstip waar de database naar terug is gegaan, start de database een nieuwe incarnatie. Met andere woorden: Alle informatie die na het flashback-punt aanwezig was is verloren.

Om gebruik te kunnen maken van de flashback technologie, is het noodzakelijk de database hiervoor geschikt te maken middels het zetten van een aantal 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)

Het spreekt voor zich dat de database ook in ArchiveLog Mode draait. Hierna kan Flashback geactiveerd worden:

shutdown abort 
startup mount 
alter database flashback on alter database open

Nadeel van deze functionaliteit is dat de performance van de database negatief beïnvloed wordt. Oracle claimt echter dat dit niet meer dan 2% bedraagt.

De grootte van de Flash Recovery Area bepaald hoever men terug in de tijd terug kan gaan.

Flashback Database through ResetLogs

Omdat de historische informatie in de Flash Recovery Area is opgeslagen, is het zelfs mogelijk een flashbak database uit te voeren welke door een resetlog punt van de database teruggaat. Ofwel indien men na de flashback database nog een uur terugmoet naar een vorige incarnatie, kan men door het zonet gemaakte resetlog punt heen. In voorgaande versies was dit alleen mogelijke via het uitvoeren van een PITR

shutdown abort 
startup mount 
flashback database to before resetlogs 
flashback database to timestamp
to_timestamp(’11-08-2009 10: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, de aan de tabel gekoppelde objecten zoals indexen, constraints en triggers worden consistent gehouden. 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 net als Flashback Query gebruik van de historische informatie die is opgeslagen in de UNDO ruimte. Let op hoe verder terug hoe meer diskruimte. Indien de ruimte niet volstaat 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. Flashback drop is eenvoudiger en sneller dan andere recovery opties, 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.

Uiteraard zijn er wel een aantal beperkingen:

• recyclebin functionaliteit is alleen beschikbaar voor niet system, locally managed tablespaces
• er is geen garantie hoe lang objecten beschikbaar blijven in de recyclebin (heeft Oracle de ruimte nodig dan pakt hij deze)
• 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

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 moeten/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.

Om 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

Flashback Transactions Query

Tot nu toe werd gebruik gemaakt van de data welke in de undo stond om informatie over een object te verkrijgen, Flashback Transaction Query gaat iets verder. Deze optie 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 acties mogelijk te maken.

De view die hiervoor gebruik wordt is FLASHBACK_TRANSACTION_QUERY. Omdat hier vertrouwelijke informatie in kan staan is het privilege SELECT ANY TRANSACTION noodzakelijk. Alleen SYS en de DBA role hebben dit recht automatisch.

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

Naast informatie over wie, wat wanneer gedaan heeft, is ook het SQL statement waarmee e.e.a. ongedaan gemaakt kan worden.

Restore Points

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.

Het voordeel van een restore point is dat deze in tegenstelling tot Flashback gegarandeerd kan worden. De logs worden pas 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.