La version 9i apporte la notion de “flashback recovery” sous la forme de packages PL/SQL et qui implémente une méthode qui permet globalement de “rattraper” quelques malencontreux ordres DDL de DBAs dans certains cas (drop, …) et qui permet d’éviter un recovery pénible.

La version 10g améliore énormément les techniques de FLASHBACK , la rend accessible en SQL, et permet aux DBAs de disposer véritablement d’une alternative aux recovery classiques (restauration et application des archivelogs) dans de nombreux cas. La notion ne varie quasiment pas en 11g.

1 – Introduction au FlashBack :

1.1) Sur quoi est basé la technologie FlashBack ?

Le FLASHBACK est un terme générique désignant un ensemble de fonctionalités permettant d’éviter les recovery en indiquant au moteur de base de données qu’il doit revenir à un état de la base pour un timestamp donné ou plustot pourun SCN donné.

Les archivelogs sont aux journaux d’une database ce que la zone de restauration rapide est aux segments d’annulations (UNDO SEGMENTS). En effet, les fonctionnalités de FLASHBACK utilisent les informations stockées dans les segments des tablespaces d’annulation pour “revenir en arrière” sur toute transaction jusqu’à une en particulier identifiée par un SCN précis (même s’il existe des approches temporelles comme nous le verrons plus loin).

Attention, seules les informations validées (COMMIT) des segments d’annulations de la zone de récupération rapide seront considérés, en effet, il serait stupide de vouloir revenir à un état de la database qui serait un état d’incohérence.

1.2) Rappels sur la conservation des blocs :

Le tablespace UNDO est caractérisé, entre autre, par le paramètre RETENION qui caractérise la manière dont la rétention est gérée dans les segments d’annulation, cette valeur peut être  :

a – “RETENTION GARANTEE” : indique que le tablespace UNDO garde toutes les transactions y compris celles qui n’ont pas abouties (ROLLBACK ou pas de COMMIT) (habituellement utilisé en production). Le paramètre UNDO_RETENTION spécifie alors le nombre de secondes (3600 par défaut) pendant lesquelles les données sont assurées d’ête conservées dans le tablespace UNDO.

b – “RETENTION NOGARANTEE” : les blocs sonts conservés uniquement pour les transactions commitées. (non recommandé en production)

La valeur des paramètre RENETENTION et UNDO_RENETION sont modifiables par “ALTER SYSTEM”.

1.3) Paramètrage du FLASHBACK:

1.3.a) Zones de stockage

Il est vivement conseillé aux DBAs d’utiliser la zone FLASHBACK sans lésiner sur l’espace disque utilisé par celle-ci. En effet, nous avons vu que la zone de flashback était liée à une sorte de stockage des informations stockées habituellement dans les segments d’annulation.

Lorsqu’une information présente dans un tablespace UNDO va expirer (UNDO_RENETION atteint par exemple) alors, si le FLASHBACK est activé, cette information va être stockée dans un journal UNDO. Il faut donc, en fonction de la vie de la database, des zones de stockage de ces “journaux” d’annulation plus ou moins grande. Lorsque cela est possible, Il convient de définir un espace suffisament grand pour stoquer toutes les informations transactionelle d’une ou deux journées afin pouvoir faire un “retour arrière” sur cette période.

En effet, une base qui ne fait que très peut de mise à jour n’aura pas besoin d’une zone de stockage des informations d’annulation à journaliser très grande.

La zone de stockage des données nécessaires au flashback est définie par DB_RECOVERY_FILE_DEST. La taille maximale à utiliser pour le FlashBack sous cette arborescence est DB_RECOVERY_FILE_DEST_SIZE.

1.3.b) Durée de rétention des informations FlashBack

Parallèlement à la notion de UNDO_RETENTION, il existe la même notion à appliquer aux informations journalisées de la zone de FlashBack, celle – ci se définie grâce au paramètreDB_FLASHBACK_RETENTION_TARGET. Attention, prenez garde à ce que cette valeur soit supérieure à UNDO_RETENTION.

1.4) Activation / Désactivation du FlashBack :

ALTER DATABASE FLASHBACK [ ON | OFF ]

Et c’est tout !

2) Les technologies de FlashBack :

Il existe en fait plusieurs façon d’aborder le flashback, le principe est globalement toujours le même, se servir des informations archivées des transactions (Undo Segments), mais les méthodes sont sensiblement différentes. Nous parlerons communément de “FlashBack de base de données”, de “FlashBack de Table” ou de gestion de la “Corbeille” ou encore de “FlashBack de données” (ou de lignes).

2.1) FlashBack Query : (ou FlashBack de lignes / de données)

2.1.a) Interrogation de données dans le temps

Le FlashBack Query permet d’interroger une ou plusieurs tables et de lire les données qu’elles contiennent à un SCN bien précis.

Cette information sera trouvée dans les segments d’annulation ou bien encore, si ceux-ci ne possèdent plus cette information car leur retention a expirée, dans les stockage de ces informations dans la zone DB_RECOVERY_FILE_DEST de la FlashBack.

Syntaxe:

[ Requete SQL de selection ] AS OF [ SCN | TIMESTAMP ] [ critères SQL de la requête ]

Exemple:

SQL> select current_scn from dual;
10/01/2008         11:00:20           176032
SQL> select valeur from compteur where id_compteur=1;
44
SQL> update compteur set valeur=valeur+1 from compteur where id_compteur=1;
SQL> commit;
SQL> select current_scn from dual;
10/01/2008         11:00:20           176054
SQL> select valeur from compteur where id_compteur=1;
45
SQL> update compteur set valeur=(select valeur from compteur AS OF SCN=176032 where id_compteur=1)
where id_compteur=1;

SQL> select valeur from compteur where id_compteur=1;
44

Nous avons ainsi pu consuler la valeur d’une donnée en revenant dans l’historisation des transactions et en parcourant les données des tablespaces UNDO ou des journaux de la zone de FlashBack.

2.1.b) Interrogation des données et de leurs différentes versions

Il se peut que vous ne disposiez pas exactement du SCN exact pour un retour arrière ou que vous ne sachiez pas exactement quelle valeur conviendrait correctement à un retour arrière cohérent. Il est possible de consulter un ensemble de versions de valeurs pour une ou plusieurs données situées entre deux SCN ou deux TIMESTAMP en guise d’intervalle (mot clé BETWEEN).

Lors des interrogation des versions d’une ligne, vous pouvez aussi spécifier dans votre requête des noms de pseudo-colonnes qui permettent de cibler l’information, à savoir :

a) VERSIONS_STARTTIME (/ENDTIME) : date et heure de début (/fin) de validité d’une version.
b) VERSIONS_STARTSCN (/ENDSCN) : scn de début (/fin) de validité d’une version.
c) VERSIONS_XID : identifiant d’une transaction associée à une version
d) VERSIONS_OPERATION : I, U, D pour “INSERT”, “UPDATE” ou “DELETE”

Syntaxe:

[ requete SQL ] VERSIONS BETWEEN [ SCN1 | TS1 ] [ expression 1 | min] [ expression2 | max]

Exemple:

SQL> select version_startscn, versions_endscn
     from personnes 

     versions between scn 17000 and 18000
     where personne_id=24; /

2.1.b) La vue FLASHBACK_TRANSACTION_QUERY

Cette vue accessible aux DBAs permet de voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps.

Les champs de cette vue sont :

XID
START_SCN
START_TMPESTAMP
COMMIT_SCN
COMMIT_TIMESTAMP
LOGON_USER : user connecté
OPERATION : nature de l’opération ‘insert/delete/update)
TABLE_NAME : nom de la table impactée
TABLE_OWNER
ROW_ID
UNDO_SQL  :  ordre sql permettant une opération INVERSE

Il peut être intéressant par exemple de rechercher toutes les opérations de DELETE sur la table personnes la dernière journée afin de réappliquer les ordres sql inverses (UNDO_SQL) sans pour cela annuler les éventuelles mises à jour (UPDATES) qui auraient été éffectuées, ce qui aurait été malheureusement le cas lors d’un recovery!

2.2) FlashBack Table :

Les opérations FlashBack de niveau “TABLE” permettent d’éffectuer un retour arrière complet sur des opérations LMD de tables. Depuis la version 10g, cette notion a été étendue aux opérations DDL, une utilisation à manier avec précaution.

2.2.a) FlashBack TABLE LMD :

Cette opération permet d’effectuer un retour arrière sur les valeurs d’une table, avec ou non l’activation de ses triggers (non recommandés dans bien des cas : valeur par défaut non activé), que cela-soit en fonction d’un SCN ou d’un TimeStamp.

Syntaxe :

FLASHBACK TABLE <table_name> to [ TimeStamp | SCN ] <expression> [ enable TRIGGERS ]

Note: L’utilisateur qui donne un ordre FLASHBACK TABLE doit disposer des privileges “flashback any tables”, “[insert / select / alter] sur la table correspondante. La table à restaurer doit autoriser le déplacement de lignes (ALTER TABLE <table_name> ENABLE ROW MOVMENT)

2.2.b) FlashBack TABLE DDL (ou “FlashBack DROP” ou gestion de la “CORBEILLE”) :

Attention : Cette fonctionalité n’existe que depuis la version 10g.

Cette fonctionalité, dite aussi “gestion de la corbeille”, permet de revenir en arrière sur un ordre DDL de typeDROP TABLE, ce que n’inculait pas le FLASHBACK TABLE.

En fait, si les fonctions de FlashBack sont activées, une table n’est pas supprimée après un DROP mais simplement renommée et son espace n’apparait plus dans DBA_FREE_SPACE (cette méthodologie est également valable pour les index des tables droppées).

Les objets temporairement renommés ne sont pas écrasés tant qu’un éventuel manque de place ne survient pas dans le tablespace concerné. Oracle commencera alors par supprimer les objets les plus anciennements supprimés, comme dans une gestion “classique” de corbeille sous votre OS préféré (FIFO).

La corbeille est à tout moment interrogeable à travers les vues USER_RECYCLEBIN ou DBA_RECYCLEBIN.

Syntaxe:

FLASHBACK TABLE <table_name> to BEFORE DROP [ rename to <new_tablename>]

Note: Les DROP de tables spécifiés avec l’expression PURGE ne pourront pas être récupérés dans la corbeille.

Note: La corbeille peut être vidée de son contenu par “PURGE DBA_RECYCLEBIN”.

Note: Attention aux surprises lors de la restauration d’une table qui est dans la corbeille : n’oubliez pas par exemple que certains triggers ont pu être activés lors du DROP et que les contraintes d’intégrité référentielles ne fonctionneront probablement plus à la restauration. Cette opération peut être utile pour récupérer les données proprement dites de cette table mais il est rare de pouvoir restaurer une table sans problème avec cette méthode en production, à moins que celle-ci ne soit liée à aucunne autre donnée (table paramètre, …).

Note: Le Flashback Table BEFORE DROP n’a aucun rapport avec le stockage des données UNDO (archivées ou non) dans la zone de restauration rapide. En effet, une table droppée sur une database où la Corbeille est activée ne sera pas supprimée mais simplement renommée  avec un nom barbare du style “$RECYCLEBIN_379837983 …” (l’espace que celle-ci consomme dans les segments deumeurera par ailleur le même jusqu’à purge de la corbeille). Une restauration de table dropée sera un simple renommage inverse de table. Une problèmatique existe cependant en 10g et 11g : les index associés et les primary key gardent les noms des tables stockées en corbeille ($RECYCLEBIN_ …) ce qui pose un réél problème d’exploitation par la suite .. à méditer.

2.3) FlashBack Database :

le FlashBack DATABASE est sans aucun doute la plus puissante des options de FlashBack puisqu’elle permet de ramenner la database à un état précis sans pratiquer de recovery.

Cette méthode consiste à parcourir les logs de la flashback (ie les journaux d’annulations archivés de la fhashback_recovery_area) à l’envers: il est donc inutile de restaurer une version cohérente et antérieure de la database pour lui appliquer classiquement des archivelogs, ce qui est un gain de temps énorme!

La seule difficulté est de dimensionner correctement la zone de flashback car, si celle ci est trop petite, Oracle réduira alors sans vous le dire la durée de rétention des informations d’annulation archivées (DB_FLASHBACK_RENTETION) et vous ne pourrez peut être plus remonter aussi loin dans le temps que vous l’auriez souhaité.

Syntaxe SQL :

FLASHBACK DATABASE TO [ SCN | TIMESTAMP ] <expression>

Syntaxe SQL sous RMAN :

FLASHBACK DATABASE TO [ SCN | TIMESTAMP ] [ = ] <expression>

ATTENTION : Une database qui a subit un flashback est cohérente au SCN demandé, il faut absoluement vider les journaux en ligne et de les synchroniser avec ce SCN pour pouvoir ouvrir cette base de données.

Exemple:

SQL> shutdown immediate;
SQL> startup mount;
SQL> flashback database to timestamp sysdate-1/24;
Flashback terminé.
SQL> alter database open RESETLOGS;
Base de données modifiée.
SQL> alter database open;

D’une simplicité enfantine, d’une rapidité déconcertante.

Remarque: Il n’est pas recommandé (au contraire de ce qui est fait dans cet exemple) d’éffectuer un flashback (ou une autre opération de recovery) à l’aide d’un TimeStamp mais plustot à l’aide d’un SCN si vous en avez la possibilité. En effet, Oracle ne connait que les SCN et les valeurs temporelles sont approximées et peuvent parfois s’avérer fausse! Vous pouvez ainsi restaurer une database à un point qui n’est pas vraiment celui qui avait été voulu…

Remarque: Avant tout flashback, faites une sauvegarde complète de tous les fichiers de la base de données y compris ceux de la FlashBackArea : Cette opération vous permettra d’éffectuer de nouveau un FlashBack au cas où le SCN demandé ou le TimeStamp demandé n’était pas exactement celui souhaité dans une première tentative.