Options de Haute disponibilités en 10G

Par Jaouad ZOUAGHI (home)

Découvrez les nouvelles options de hautes disponibilités sous Oracle 10G. Découvrez également comment paramétrer la flash_recovery_area

I. Introduction
I-A. Qu'est ce que la haute disponibilité ?
I-B. Recyclebin
I-C. Instruction Flashback
II. RecycleBin
II-A. Mise en place
II-B. Utilisation
II-C. Purge de la corbeille
II-C-1. Purge par objet
II-C-2. Purge par User
II-C-3. Purge DBA
II-C-4. Purge tablespace
II-D. Désactivez cette fonction
II-D-1. Désactivez au niveau de l'instance
II-D-2. Désactivez au niveau du system (après STARTUP ), uniquement en 10G R2
II-D-3. Désactivez au niveau Session uniquement en 10G R2
III. Instruction Flashback
III-A. Restauration complète
III-B. Restauration incomplète
III-C. Restauration Base

I. Introduction

I-A. Qu'est ce que la haute disponibilité ?

La haute disponibilité est un concept Oracle très important pour les DBA Oracle en environnement critique. Une base critique est une base qui doit être toujours disponible et ceci dans les meilleures conditions de sécurité : prévenir d'éventuels " crash ", mais également un accès le plus rapide aux données.
Différentes options ont déjà par le passé fait leur apparition pour se prémunir contre ce genre de désagrément :
StandBy Database
Hot backup

D'autres on été introduites avec la version précédente 9i, je pense notamment au

Log Miner
Ou Flashback query
Avec la dernière version Oracle répond à un désir de ses clients, créer une poubelle comme celle que vous avez sous windows. Ainsi il n'existe plus d'action qui nécessite irréversiblement une restauration à chaud de la base de données ou des compétences accrues : Flashback et Logminer

I-B. Recyclebin

RecycleBin est donc une poubelle ou sont stockés tous les index et les tables qui ont été supprimés ( sous certaines réserves que nous verrons par la suite ). Ce qui permet de restaurer une table, un index mais également de purger cette poubelle ainsi que diverses opérations d'administration.

I-C. Instruction Flashback

Cette instruction va nous permettre de pouvoir effectuer une restauration d'objets supprimés accidentellement mais pas uniquement, cette restauration pourra s'effectuer en fonction du SCN, de l'horodate, en changeant le nom de l'objet …

II. RecycleBin

RecycleBin est une pseudo table qui n'est que le synonyme de User_recyclebin.
En effet si dans une session utilisateur, cette dernière requête sur cette vue, il interroge en fait la vue user_recyclebin.

SQL>  create table dvp ( a number ) ;

Table créée.

SQL> drop table dvp;

Table supprimée.

SQL> set linesize 250

SQL> select ORIGINAL_NAME  , OPERATION      , CAN_UNDROP             from user_recyclebin ;

ORIGINAL_NAME                    OPERATION CAN
-------------------------------- --------- ---
DVP                              DROP      YES

SQL> select ORIGINAL_NAME  , OPERATION      , CAN_UNDROP             from recyclebin ;

ORIGINAL_NAME                    OPERATION CAN
-------------------------------- --------- ---
DVP                              DROP      YES

SQL> 
SQL>

II-A. Mise en place

Cette option que nous découvrons en 10g est activée par défaut. Elle est présente pour tous les utilisateurs. Afin de vérifier sa mise en place il suffit tout simplement de voir si le paramètre, _recyclebin, global de la base de données est activé :

SQL> r
  1  SELECT a.ksppinm, b.ksppstvl, b.ksppstdf
  2  FROM x$ksppi a, x$ksppcv b
  3  WHERE a.indx = b.indx
  4  AND a.ksppinm like '_recycle%'
  5  ORDER BY a.ksppinm
  6*

KSPPINM                KSPPSTVL             KSPPSTDF
----------------------- -------------------- ---------
_recyclebin            TRUE                 TRUE

Nous pouvons également agir sur ce paramètre au niveau session ainsi :

SQL> ALTER SESSION SET recyclebin = OFF;
SQL> ALTER SYSTEM SET recyclebin = OFF;

Attention ces dernières commandes ne sont valables que dans la release 2 d' Oracle 10G.
Autre différence, en 10gR1 la valeur par défaut de _RECYCLE est à TRUE, alors qu'en 10G R2 elle est à ON, d'ailleurs ce paramétre ne s'appelle plus _RECYCLE mais RECYCLE en release 2
Autre précision également, la commande ne fonctionne pas lorsque l'utilisateur à comme tablespace défaut : SYSTEM.

II-B. Utilisation

Donc dès que la corbeille est mise en place, elle a le même comportement qu'une corbeille classique. Notamment la corbeille de Windows ou alors le dossier Lost+Found d'Unix.
C'est donc un dossier virtuel qui contient tous les objets que nous avons supprimés. Ce qui veut dire que depuis la 10g, Oracle ne désalloue plus l'espace lors d'une opération classique de DROP. La table existe toujours ainsi que ses références : index , contraintes …, ils sont également toujours dans leur tablespace d'origine

Exemple :
Création d'une table dans un schéma vierge :

SQL> create table dvp ( a number ) ;

Table créée.

SQL> insert into dvp values (1) ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select table_name , tablespace_name from user_tables ;

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
DVP                            FA7_TBS_TBU

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

Nous voyons donc la table créée et son tablespace de destination, la corbeille est pour l'instant vide.
Nous allons supprimer la table :

SQL> drop table dvp ;

Table supprimée.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

OBJECT_NAME                    ORIGINAL_NAME                    OPERATION CAN
------------------------------ -------------------------------- --------- ---
BIN$BlBmdfdAMubgRAAPICsTjA==$0 DVP                              DROP      YES

Remarque : tout objet droppé acquière un nouveau nom qui est préfixé par BIN$
Un coté intéressant de cette table est que l'on continue à accéder à cette table et même à ses données même si elle est droppée.

SQL>  select * from "BIN$BlBmdfdBMubgRAAPICsTjA==$0" ;

         A
----------
         1

Donc vous l'aurez compris, il ne faut rien de plus pour activer cette option ni dans le paramétrage ni dans les commandes de DROP.
Un simple DROP place automatiquement les objets dans la corbeille, par contre un travail nécessaire de purge doit être fait par le DBA, si ce dernier ne veut pas qu'il y ait de la place inoccupée par les objets de la base.
On peut également supprimer une table sans que cette dernière ne soit placée dans la corbeille mais soit directement supprimée et purgée. Il suffit

SQL> create table dvp ( a number ) ;

Table créée.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

SQL> drop table dvp purge  ;

Table supprimée.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

Cas ou on drop deux fois la même table :

Ici nous allons voir comment Oracle gère le cas où l'on droppe deux tables avec le même nom.

SQL>  select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

SQL> create table dvp ( a number ) ;

Table créée.

SQL> drop table dvp ;

Table supprimée.

SQL> create table dvp ( a number ) ;

Table créée.

SQL> drop table dvp ;

Table supprimée.

SQL> set linesize 250

SQL> r
  1*
  select object_name , original_name , droptime  , dropscn  from recyclebin
  
  OBJECT_NAME                    ORIGINAL_NAME                    DROPTIME               DROPSCN
  ------------------------------ -------------------------------- ------------------- ----------
  BIN$BlG09kpASWTgRAAPICsTjA==$0 DVP                              2005-11-24:16:58:25     216290
  BIN$BlG09kpBSWTgRAAPICsTjA==$0 DVP                              2005-11-24:16:58:34     216314

Oracle gère donc ces deux instances avec le même ORIGINAL_NAME mais avec deux SCN différents
Dans ce cas la purge sur le nom original n'est plus pertinente préférez lui une purge sur le nom BIN$*

  1* purge table "BIN$BlG09kpASWTgRAAPICsTjA==$0"
  
SQL> l
  1* purge table "BIN$BlG09kpASWTgRAAPICsTjA==$0"
SQL> r
  1* purge table "BIN$BlG09kpASWTgRAAPICsTjA==$0"

Opération 200 réussie.

SQL> select object_name , original_name , droptime  , dropscn  from recyclebin ;

OBJECT_NAME                    ORIGINAL_NAME                    DROPTIME               DROPSCN
------------------------------ -------------------------------- ------------------- ----------
BIN$BlG09kpBSWTgRAAPICsTjA==$0 DVP                              2005-11-24:16:58:34     216314

SQL>

Comment voir les tables supprimées :

SQL>  select table_name  from user_tables where dropped='YES' ;

TABLE_NAME
------------------------------
BIN$BlI2x+7DDdDgRAAwbvQ3/Q==$0

SQL>

II-C. Purge de la corbeille

Comme vu précédemment, chaque utilisateur ou le DBA se doivent de purger régulièrement cet espace de travail.
Il y a différentes manières de purger cette corbeille car comme vous le supposez, il n'existe pas une seule corbeille.

II-C-1. Purge par objet

Pour ce faire, vous pouvez purger les tables et index en spécifiant après les mots clés le nom de l'objet :
Pour une table :

SQL> r
  1* purge table dvp

Opération 200 réussie.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

Pour un index :

SQL> Purge index index dvp ;

II-C-2. Purge par User

Dans ce cas on purge tous les objets du schéma qui ont été supprimés.

SQL> create table dvp ( a number ) ;

Table créée.

SQL> create index dvp on dvp ( a) ;

Index créé.

SQL> drop table dvp ;

Table supprimée.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

OBJECT_NAME                    ORIGINAL_NAME                    OPERATION CAN
------------------------------ -------------------------------- --------- ---
BIN$BlBmdfdCMubgRAAPICsTjA==$0 DVP                              DROP      NO
BIN$BlBmdfdDMubgRAAPICsTjA==$0 DVP                              DROP      YES

SQL> ed

écrit fichier afiedt.buf

  1* purge recyclebin
SQL> r
  1* purge recyclebin

Opération 197 réussie.

SQL> select object_name , original_name , operation , can_undrop from recyclebin ;

aucune ligne sélectionnée

II-C-3. Purge DBA

Lorsque le DBA souhaite libérer l'espace occupé par toutes les corbeilles, celui doit se connecter avec les privilèges SYSDBA :

SQL> conn system
Connecté.
SQL> l
  1* PURGE DBA_recyclebin
SQL> r
  1* PURGE DBA_recyclebin
PURGE DBA_recyclebin
*
ERREUR à la ligne 1 :
ORA-01031: insufficient privileges

$ sqlplus "/as sysdba "

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Nov 24 16:00:14 2005

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> PURGE DBA_recyclebin
  2  ;

DBA Recyclebin purged.

SQL>

D'ailleurs pour pouvoir purger un objet dans la corbeille il faut avoir l'un des deux privilèges suivants ( lorsque évidemment cet objet ne nous appartient pas )

SYSDBA
DROP ANY

II-C-4. Purge tablespace

Ici nous allons effectuer une purge mais en fonction d'un tablespace. Donc tous les objets appartenant à un tablespace mais qui ont été supprimés vont être purgés.

SQL> PURGE tablespace FA7_TBS_TBU
  2  ;

Tablespace purged.

Parce que plusieurs schémas peuvent partager le même tablespace, Oracle a voulut limiter les effets de cette commande. Ainsi on peut supprimer tous les objets dans un tablespace et appartenant à un utilisateur spécifique.

SQL> PURGE tablespace FA7_TBS_TBU USER dvp ;

Tablespace purged.

II-D. Désactivez cette fonction

Pour désactiver cette option, nous avons plusieurs méthodes :

II-D-1. Désactivez au niveau de l'instance

Positionner le paramètre suivant sur le SPFILE ou PFILE :
10g R1 :

_RECYCLEBIN = FALSE

10G R2 :

RECYCLEBIN = OFF

II-D-2. Désactivez au niveau du system (après STARTUP ), uniquement en 10G R2

SQL> alter system set recyclebin =OFF

II-D-3. Désactivez au niveau Session uniquement en 10G R2

SQL> alter session set recyclebin =OFF

III. Instruction Flashback

L'instruction Flashback va nous permettre de faire une restauration de nos objets qui ont été supprimés.
En effet cette instruction basée sur le paramètre UNDO_RETENTION, va nous permettre de faire une restauration complète d'un objet mais également une restauration incomplète d'un objet dont certaines lignes auront été supprimées.
Il faut également rappeler que cette restauration n 'est possible que dans un mode de gestion AUM ( Automatic Undo Management ) ce qui exclut les traditionnels rollabck .

III-A. Restauration complète

Vendredi 17heures, mon téléphone retentit, mon développeur préféré vient de dropper accidentellement une table en production. Dans une version inférieure à la 10G, cela est un réel problème qui nécessite un arrêt de la base avec un recovery incomplet, ou une utilisation du Log Miner pour trouver le UNDO SQL.
Dorénavant, et si la table n'a pas été supprimée avec l'option PURGE, il est possible de récupérer une table par un simple ordre SQL :

SQL> create table dvp ( a varchar2(20)) ;

Table créée.

SQL> insert into  dvp values ( 'jaouad') ;

 1 ligne créée.

SQL> analyze table dvp compute statistics ;

Table analysée.

SQL> select table_name , num_rows from user_tables ;

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
DVP                                     1

SQL> create index dvp_ind on dvp ( a ) ;

Index créé.


SQL> select object_name , original_name , CAN_UNDROP, dropscn  from recyclebin ;

aucune ligne sélectionnée

SQL> drop table dvp ;

Table supprimée.

SQL> select object_name , original_name , CAN_UNDROP, dropscn  from recyclebin ;

OBJECT_NAME                    ORIGINAL_NAME                    CAN    DROPSCN
------------------------------ -------------------------------- --- ----------
BIN$BlG09kpISWTgRAAPICsTjA==$0 DVP_IND                          NO      217575
BIN$BlG09kpJSWTgRAAPICsTjA==$0 DVP                              YES     217578

D'ailleurs ici nous découvrons l'utilité de la colonne CAN_UNDROP , si cette colonne a pour valeur NO alors on ne peut pas faire de FLASHBACK , c'est notamment le cas pour les index.
En effet, et c'est une limitation de l'outil on ne peut pas restaurer un autre objet qu'une table.
Restauration de la table :

SQL> select * from dvp ;
select * from dvp
              *
ERREUR à la ligne 1 :
ORA-00942: table or view does not exist

  1* flashback table dvp to before drop

Opération 202 réussie.

SQL> select * from dvp ;

A
--------------------
jaouad

SQL>

Autre limitation qui a également une incidence sur les performances, Oracle dans la version R1 ne restaure pas les statistiques.
Il faut également penser à re créer les contraintes afin d'avoir un environnement propre :

SQL> create table dvp ( a varchar2(10)) ;

Table créée.

SQL> alter table dvp  add constraint  dvp_pk primary key  (a) ;

Table modifiée.

SQL> insert into dvp values ('jaouad') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL>  insert into dvp values ('jaouad') ;
insert into dvp values ('jaouad')
*
ERREUR à la ligne 1 :
ORA-00001: unique constraint (DVP.DVP_PK) violated


SQL> drop table dvp ;

Table supprimée.


  1* flashback table dvp to before drop
SQL>
SQL>
SQL> r
  1* flashback table dvp to before drop

Opération 202 réussie.

SQL> select * from dvp ;

A
----------
jaouad

SQL> insert into dvp values ('jaouad') ;
insert into dvp values ('jaouad')
*
ERREUR à la ligne 1 :
ORA-00001: unique constraint (DVP.BIN$BlG09kpKSWTgRAAPICsTjA==$0) violated

SQL> select object_name , original_name , CAN_UNDROP, dropscn  from recyclebin ;

aucune ligne sélectionnée

SQL>
SQL>

Oracle ne garantit pas non plus la restauration des ROWID, ceci constitue un énième argument pour ne pas utiliser le ROWID en lieu et place d'une clé primaire.
Il est également possible de restaurer la table en lui affectant un autre nom :

flashback table dvp to before drop rename to dvp_club ;

Comment fonctionne la restauration :

Lorsque nous supprimons la table, Oracle ne la supprime plus instantanément. Il la marque comme supprimée est lui affecte un nouveau nom d'objet et il marque les extents libre dans le tablespace. D'ailleurs la vue DBA_FREE_SPACE reflète cet état de fait.
Donc dès qu'il y a assez d'espace dans la tablespace Oracle ne va pas purger cette table.
Plus précisément Oracle lorsqu'il y a une demande de place pour une création d'objet et/ou une extension d'objet cherche :

de la place libre dans le Tablespace :
Sinon purge les tables supprimées pour utiliser cet espace.
Sinon augmente la taille du Tablespace si possible

Nous allons créer une table, l'alimenter puis la supprimer et voir à chaque étape l'état de la vue DBA_FREE_SPACE :

SQL> CREATE 
  2       TABLESPACE test  DATAFILE
  3      '/ora/data/KIMTEST/u01/test.dbf' SIZE 200M REUSE AUTOEXTEND 
  4      ON NEXT  1024K MAXSIZE 200m EXTENT MANAGEMENT LOCAL 
  5      UNIFORM SIZE 1024K ;

Tablespace created.


SQL> SELECT b.bytes/1024/1024 espace_alloue , a.BYTES/1024/1024 espace_libre   FROM dba_free_space a
 , dba_data_files b  
 2  WHERE a.tablespace_name ='TEST' 
 3  AND a.tablespace_name =b.tablespace_name  ;

ESPACE_ALLOUE ESPACE_LIBRE
------------- ------------
          200          199




SQL> create table TEST ( a varchar2(20) , b number ) tablespace TEST ;

Table créée.

SQL> begin
  2  for i in 0..100000 
  3  loop 
  4  insert into test values ('club developpez',i) ; 
  5  end loop ; 
  6  commit ; 
  7  end ; 
  8  /

Procédure PL/SQL terminée avec succès.

SQL> SELECT b.bytes/1024/1024 espace_alloue , a.BYTES/1024/1024 espace_libre   FROM dba_free_space a
 , dba_data_files b  
  2  WHERE a.tablespace_name ='TEST' 
  3  AND a.tablespace_name =b.tablespace_name  ;

ESPACE_ALLOUE ESPACE_LIBRE
------------- ------------
          200          196

La table occupe donc un espace de 3 Méga.
Nous supprimons la table :

SQL> drop table test ;

Table supprimée.

Ce qui donne :

SQL> SELECT b.bytes/1024/1024 espace_alloue , a.BYTES/1024/1024 espace_libre   FROM dba_free_space a
 , dba_data_files b 
  2  WHERE a.tablespace_name ='TEST' 
  3  AND a.tablespace_name =b.tablespace_name  ;

ESPACE_ALLOUE ESPACE_LIBRE
------------- ------------
          200          196
          200            1
          200            1
          200            1

Nous resizons le tablespace :

SQL> alter database datafile '/ora/data/KIMTEST/u01/test.dbf' resize 4 M ;

Base de données modifiée.

La table est toujours disponible dans la corbeille ;

SQL> select object_name , original_name  from user_recyclebin  ;

OBJECT_NAME                    ORIGINAL_NAME
------------------------------ --------------------------------
BIN$CGtmng7AMNTgRAAwbvQ3/Q==$0 TEST

Par contre si nous créons une autre table et que nous l'insérons alors cette table va être purgée par Oracle .

SQL> create table dvp ( a varchar2(20) , b number ) tablespace TEST ;

Table créée.

SQL> begin
  2  for i in 0..100000 
  3  loop 
  4  insert into DVP  values ('club developpez',i) ; 
  5  end loop ; 
  6  commit ;  
  7  end ;   
  8  /

Procédure PL/SQL terminée avec succès.

SQL> select object_name , original_name  from user_recyclebin  ;

aucune ligne sélectionnée

SQL>

Quelles sont les opérations qui peuvent contourner la corbeille :

Lorsque celle ci est désactivée.
Drop table table_name purge
Drop tablespace_name including contents
Drop user user_name cascade.

Il existe une vue permettant de centraliser les informations lors de ces opérations :

SELECT operation , undo_sql , table_name  FROM flashback_transaction_query

III-B. Restauration incomplète

Nous verrons deux cas pratiques, le premier où nous ne souhaitons pas restaurer une table avec toutes ces lignes et la seconde ou nous souhaitons effacer les conséquences d'un malheureux DELETE.
Avant tout il faut absolument activer le " Row movement " avant de faire une restauration incomplète.

SQL> create table dvp ( a varchar2(20)) ;

Table créée.

SQL> insert into  dvp values ( 'jaouad') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select a, ora_rowscn from dvp ;

A                    ORA_ROWSCN
-------------------- ----------
jaouad                   219418

SQL> insert into  dvp values ( 'Léo') ;

1 ligne créée.

SQL> insert into  dvp values ( 'POM') ;

1 ligne créée.

SQL> insert into  dvp values ( 'Laly') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQLselect a, ora_rowscn from dvp ;

A                    ORA_ROWSCN
-------------------- ----------
jaouad                   219437
Léo                      219437
POM                      219437
Laly                     219437

SQL> insert into  dvp values ( 'FRED') ;

1 ligne créée.

SQL> insert into  dvp values ( 'sheik') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select * from dvp ;

A--------------------
jaouad
Léo
POM
Laly
FRED
sheik

6 ligne(s) sélectionnée(s).

SQL> ed
écrit fichier afiedt.buf  1* flashback table dvp to scn  (219418)

SQL> r
  1* flashback table dvp to scn  (219418)
flashback table dvp to scn  (219418)
                *
ERREUR à la ligne 1 :
ORA-08189: cannot flashback the table because row movement is not enabled

SQL> alter table dvp enable row movement ;

Table modifiée.

SQL> ed
écrit fichier afiedt.buf

  1* flashback table dvp to scn  (219418)

SQL> r
  1* flashback table dvp to scn  (219418)

Opération 205 réussie.

SQL> select * from dvp ;

A
--------------------
jaouad

SQL>

Maintenant voyons un cas un peu plus complexe ou on a effectué un DELETE suivi d'un commit et que l'on désire restaurer la table .

SQL> create table dvp ( a varchar2(20)) ;

Table créée.

SQL> insert into  dvp values ( 'jaouad') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select a, ora_rowscn from dvp ;

A                    ORA_ROWSCN
-------------------- ----------
jaouad                   219699

SQL> insert into  dvp values ( 'Léo') ;

1 ligne créée.

SQL> insert into  dvp values ( 'POM') ;

1 ligne créée.

SQL> insert into  dvp values ( 'Laly') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select a, ora_rowscn from dvp ;

A                    ORA_ROWSCN
-------------------- ----------
jaouad                   219701
Léo                      219701
POM                      219701
Laly                     219701

SQL> insert into  dvp values ( 'FRED') ;

1 ligne créée.

SQL> insert into  dvp values ( 'sheik') ;

1 ligne créée.

SQL> commit ;

Validation effectuée.

SQL> select a, ora_rowscn from dvp ;

A                    ORA_ROWSCN
-------------------- ----------
jaouad                   219703
Léo                      219703
POM                      219703
Laly                     219703
FRED                     219703
sheik                    219703

6 ligne(s) sélectionnée(s).

SQL> delete from dvp where a !='jaouad' ;

5 ligne(s) supprimée(s).

SQL> commit ;

Validation effectuée.

SQL> select * from dvp ;

A
--------------------
jaouad

SQL> alter table dvp enable row movement ;

Table modifiée.

SQL> ed
écrit fichier afiedt.buf

  1* flashback table dvp to scn  (219703)
SQL> r
  1* flashback table dvp to scn  (219703)

Opération 205 réussie.

SQL> select * from dvp ;

A
--------------------
jaouad
Léo
POM
Laly
FRED
sheik

6 ligne(s) sélectionnée(s).

SQL>

Cela marche, sur le même procédé, avec les opérations UPDATE et TRUNCATE.
Ce procédé fonctionne uniquement si nous sommes en mode AUM ( Automatic Undo Management ) et donc exclu de fait les Rollbacks.
Il est donc directement impacté par la valeur que peut avoir UNDO_RETENTION qui par défaut a comme valeur 900 secondes soit 15 minutes.
Il convient de bien positionner ce paramètre et d'agir rapidement lorsqu'il y a eu un drop de table malencontreux

III-C. Restauration Base

Nouveauté de la 10 G , oracle a désormais simplifié la restauration de la base est à mis en place une nouvelle restauration incomplète : La flash_recovery_area.
En effet ici le DBA a la possibilité de restaurer la base et l'intégralité des données jusqu' a un certain point dans la temps sans avoir à restaurer la dernière sauvegarde et à appliquer les nombreux archivelogs.
Flashback Database permet de restaurer très rapidement une base de données en éliminant les corruptions logiques en annulant tout simplement les ordres qui ont entraîné ces corruptions jusqu'à obtention d'un état cohérent.
Cette méthode peut être très utile lorsqu'une erreur se produit en fin de journée et qu'il faut agir rapidement avant les traitements " Batch " de nuit. En effet le temps de mise à disponibilité de la base ne se mesure plus à la taille de la base et à la volumétrie des archive à appliquer mais uniquement au nombre de modifications qui doivent être annulées.

Mode de fonctionnement :
Tout d'abord ce qu'il faut savoir est que cette méthode ne marche qu'en mode archivelog.
Cette fonctionnalité est implémentée grâce à un nouveau type de fichier : les fichiers journal Flashback database. Oracle va enregistrer périodiquement les images avant ( before images ) des blocs de données dans les journaux Flashback Database . Ces fichiers peuvent donc être utilisés pour rétablir rapidement les fichiers de données.
Ces journaux sont stockés dans la zone de récupération.
Oracle 10g démarre un nouveau processus RVWR qui s'occupe de la journalisation vers les fichiers flashback à partir de la mémoire tampon.

ps -eaf | grep ora_rvwr
oracle10 27208     1  0 15:47:05 ?         0:00 ora_rvwr_ORCL

Il est important d'avoir un Log buffer équivalent à au moins 8MO .
Il faut savoir également que les journaux flasback ne sont pas archivés .
Configuration Manuelle :
Il est possible d'effectuer une configuration avec OEM mais ici nous détaillerons la configuration manuelle qui est plus difficile que celle via la console graphique et surtout est, à mon sens, plus formatrice.
Tout d'abord il faut définir le paramètre DB_FLASHBACK_RETENTION_TARGET, ce paramètre exprimé en minutes et ayant par défaut une journée ( 1440 /60 = 24 heures ).
Puis il faut passer la commande suivante en mode MOUNT exclusive

SQL> startup mount exclusive 
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size                  1310024 bytes
Variable Size             312214200 bytes
Database Buffers          209715200 bytes
Redo Buffers                1048576 bytes
Database mounted.

SQL> alter database flashback on ; 
alter database flashback on
*
ERROR at line 1:
ORA-38706: Cannot turn on FLASHBACK DATABASE logging.
ORA-38709: Recovery Area is not enabled.

Comment déterminer la Flashback recovery area , il suffit tout simplement de positionner le paramétrage de démarrage DB_RECOVERY_FILE_DEST et ne pas également oublier de positionner le paramètre DB_RECOVERY_FILE_DEST_SIZE

SQL> startup mount exclusive 
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size                  1310024 bytes
Variable Size             312214200 bytes
Database Buffers          209715200 bytes
Redo Buffers                1048576 bytes
Database mounted.

SQL> alter database flashback on ; 

Database altered.

SQL> alter database open ;

Database altered.

SQL>

Comment vérifier que nous sommes bien en recovery_aréa :

SQL> select flashback_on from v$database  ; 

FLA
---
YES

SQL>

Voici un jeu d'essai

SQL> desc dvp 
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- ----------------------------
 A                                                  VARCHAR2(20)
 B                                                  NUMBER

SQL> select count (*) from dvp ;

  COUNT(*)
  ----------    
  100001

SQL> select max ( ora_rowscn ) from dvp ;

MAX(ORA_ROWSCN)
---------------
      451966950

SQL> drop table dvp ;

Table supprimée.

SQL> create table TEST ( a varchar2(20) , b number ) tablespace TEST ;

Table créée.

SQL> begin 
  2     for i in 0..100000 
  3     loop 
  4     insert into test values ('club developpez',i) ; 
  5     end loop ;
  6     commit ; 
  7    end ; 
  8  /

Procédure PL/SQL terminée avec succès.

SQL> select max ( ora_rowscn ) from  test ;

MAX(ORA_ROWSCN)
---------------
      451971993

--- Arrêt de la base

SQL> startup mount
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size                  1310024 bytes
Variable Size             312214200 bytes
Database Buffers          209715200 bytes
Redo Buffers                1048576 bytes
flasDatabase mounted.
SQL>             
   
SQL> flashback database to scn 451966950;

Flashback complete.

SQL> alter database open resetlogs ;

Database altered.

SQL> desc test
ERROR:
ORA-04043: object test does not exist

SQL> desc dvp 

 Nom                                       NULL ?   Type 
 ----------------------------------------- -------- --------------------- 
 A                                                  VARCHAR2(20) 
 B                                                  NUMBER

SQL> select count (*) from dvp ;

  COUNT(*)
  ----------
      100001

SQL>

La table DVP a été restaurée et la table TEST n'existe plus puisque sa création a un SCN supérieur a celui de la table DVP .
Notons que dans le répertoire ou FS désigné par DB_RECOVERY_FILE_DEST oracle crée un répertoire pour chaque instance puis deux répertoire un pour l'archivage et l'autre pour le flashback. Il est donc inutile de paramétrer log_archive_dest .
Désactivez le mode Flash recovery aréa :
Mettre en commentaire les paramètres dans la fichier INIT. Ou SPFILE :
Puis inhiber le mode flashback et le mode archivelog :

SQL> Startup mount exclusive 
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size                  1310024 bytes
Variable Size             312214200 bytes
Database Buffers          209715200 bytes
Redo Buffers                1048576 bytes
Database mounted. 

SQL> alter database flashback off ;

Database altered.

SQL> alter database noarchivelog ;

Database altered.

SQL> alter database open ;

Database altered.

Il faut également savoir que cette solution peut avoir un impact non négatif sur les performances générales car en plus des archivelogs Oracle génère des fichiers Flashback. De plus il a un impact certain sur la volumétrie car il demande de l'espace supplémentaire
Ne pas oublier également d'inclure cette zone dans la sauvegarde classique.

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.