11 décembre 2008
4
11
/12
/décembre
/2008
20:11
Bonsoir,
Mais qu'est ce donc que ce Recycle Bin ?
Il s'agit d'une table du dictionnaire de donnée contenant des informations sur les objets supprimés. Pour simplifier, c'est une vulgaire corbeille comme vous pouvez en avoir sur windows.
Cela signifie tout simplement que depuis Oracle 10, vous pouvez vous permettre le luxe de supprimer une table par hasard et de la faire réapparaitre sans même l'intervention de votre DBA préféré.
Comment ca fonctionne ?
Pour commencer je crée une table ex1 que je vais ensuite supprimer.
CREATE TABLE ex1 (i NUMBER);
DROP TABLE ex1;
A ce moment, on peut penser que c'est terminé, ma table ex1 est partie dans le néant et les données qu'elle contenait également. En fait c'est ce qui se passait avant que cette corbeille apparaisse !
La table n'est plus visible mais elle a été placée dans la corbeille. Ce qui signifie aussi que l'espace qu'occupait cette table n'a pas été rendu !
Alors pour savoir quels sont les objets qui sont dans votre corbeille, il suffit d'interroger la vue User_RecycleBin ou encore plus simplement le synonyme associé RecycleBin.
SELECT * FROM RecycleBin;
Quelles informations avons nous ?
Alors si c'est bien d'avoir une corbeille, il est aussi interessant de savoir ce que l'on peut faire avec.
En générale depuis une corbeille, soit on restaure, soit on purge pour liberer de la place.
Remarque : La corbeille est propre a chaque schema, et en se connectant en sys on peut accèder à la vue DBA_RecycleBin qui permet de voir tous les objets dans la corbeille quelque soit le propriétaire. On n'a d'ailleurs une colonne Owner en plus pour identifier ce propriétaire.
1er cas : Purge complète de la corbeille (en owner).
PURGE RecycleBin; (on ne peut pas faire plus simple)
2ème cas : Purge d'un objet en particulier.
PURGE TABLE ex2;
ou
PURGE TABLE BIN$............
Remarque : Si il existe plusieurs verson de la table et que vous utilisez PURGE TABLE No_Table; alors seule la version la plus récemment supprimée sera purgée.
3ème cas : Restauration d'un objet.
FLASHBACK TABLE ex1 TO BEFORE DROP;
ou (si vous êtes maso ou si vous avez plusieurs versions de la table)
FLASHBACK TABLE BIN$............... TO BEFORE DROP;
Remarque : Si votre table avait des indexes (ou /et ) des contraintes, les indexes et contraintes seront restaurés avec le nom de corbeille (BIN$....) et non pas le nom d'origine, il convient donc de renommer les objets après restauration (ex: ALTER INDEX "BIN$......." RENAME TO Nom_Origine;)
4ème cas : Purge de tous les objets de la base
CONNECT / as sysdba
PURGE Dba_RecycleBin;
ATTENTION : Je ne serai pas complet, si je ne disais pas qu'il existait un paramètre système qui permet de d'inactiver cette fonction.Par défaut, à l'installation d'ORACLE, cette fonction est activée.
CONNECT system/*******
ALTER SYSTEM SET RECYCLEBIN=OFF;
On peut également désactiver la fonction au niveau d'une session
ALTER SESSION SET RECYCLEBIN=OFF;
A mon sens, il est relativement stupide de désactiver cette option.
Pourquoi ?
ATTENTION : UN DROP USER ou DROP TABLESPACE, ne passe pas par la corbeille. Il faut passer par une sauvegarde pour récupérer les objets perdus.
ATTENTION : Si vous utilisez des scripts de maintenance appelant la table User_Objects vous devez vous attendre à quelques soucis. Il faut prévoir une clause pour exclure les nom d'objets commencant par BIN$ a moins que vous soyez assez malade pour appeler des indexes ou des tables de la sorte. Autre solution, préferez les vues USER_INDEXES et USER_TABLES que USER_OBJECTS avec une clause sur la colonne TYPE.
LAO.
Mais qu'est ce donc que ce Recycle Bin ?
Il s'agit d'une table du dictionnaire de donnée contenant des informations sur les objets supprimés. Pour simplifier, c'est une vulgaire corbeille comme vous pouvez en avoir sur windows.
Cela signifie tout simplement que depuis Oracle 10, vous pouvez vous permettre le luxe de supprimer une table par hasard et de la faire réapparaitre sans même l'intervention de votre DBA préféré.
Comment ca fonctionne ?
Pour commencer je crée une table ex1 que je vais ensuite supprimer.
CREATE TABLE ex1 (i NUMBER);
DROP TABLE ex1;
A ce moment, on peut penser que c'est terminé, ma table ex1 est partie dans le néant et les données qu'elle contenait également. En fait c'est ce qui se passait avant que cette corbeille apparaisse !
La table n'est plus visible mais elle a été placée dans la corbeille. Ce qui signifie aussi que l'espace qu'occupait cette table n'a pas été rendu !
Alors pour savoir quels sont les objets qui sont dans votre corbeille, il suffit d'interroger la vue User_RecycleBin ou encore plus simplement le synonyme associé RecycleBin.
SELECT * FROM RecycleBin;
Quelles informations avons nous ?
- Object_Name => le nom de l'objet dans la corbeille, commencant toujours par BIN$ suivant d'un identifiant unique de 26 caractère + un numéro de version dans le cas ou on s'amuserait à créer et a supprimer plusieurs fois la même table.
- Original_Name => Vous aurez deviné qu'il s'agit du nom d'origine de l'objet (dans mon cas ex1)
- Type => Correspond au type d'objet supprimé (Table, Index)
- CreateTime => Date de création de l'objet.
- DropTime => Date de suppression de l'objet.
- DropScn => numero de scn, utile si on veut restaurer une version particulière de la table.
- Space => Nombre de blocks utilisé par l'objet en question. (vous allez peut être découvrir quelques GO de libre...)
Alors si c'est bien d'avoir une corbeille, il est aussi interessant de savoir ce que l'on peut faire avec.
En générale depuis une corbeille, soit on restaure, soit on purge pour liberer de la place.
Remarque : La corbeille est propre a chaque schema, et en se connectant en sys on peut accèder à la vue DBA_RecycleBin qui permet de voir tous les objets dans la corbeille quelque soit le propriétaire. On n'a d'ailleurs une colonne Owner en plus pour identifier ce propriétaire.
1er cas : Purge complète de la corbeille (en owner).
PURGE RecycleBin; (on ne peut pas faire plus simple)
2ème cas : Purge d'un objet en particulier.
PURGE TABLE ex2;
ou
PURGE TABLE BIN$............
Remarque : Si il existe plusieurs verson de la table et que vous utilisez PURGE TABLE No_Table; alors seule la version la plus récemment supprimée sera purgée.
3ème cas : Restauration d'un objet.
FLASHBACK TABLE ex1 TO BEFORE DROP;
ou (si vous êtes maso ou si vous avez plusieurs versions de la table)
FLASHBACK TABLE BIN$............... TO BEFORE DROP;
Remarque : Si votre table avait des indexes (ou /et ) des contraintes, les indexes et contraintes seront restaurés avec le nom de corbeille (BIN$....) et non pas le nom d'origine, il convient donc de renommer les objets après restauration (ex: ALTER INDEX "BIN$......." RENAME TO Nom_Origine;)
4ème cas : Purge de tous les objets de la base
CONNECT / as sysdba
PURGE Dba_RecycleBin;
ATTENTION : Je ne serai pas complet, si je ne disais pas qu'il existait un paramètre système qui permet de d'inactiver cette fonction.Par défaut, à l'installation d'ORACLE, cette fonction est activée.
CONNECT system/*******
ALTER SYSTEM SET RECYCLEBIN=OFF;
On peut également désactiver la fonction au niveau d'une session
ALTER SESSION SET RECYCLEBIN=OFF;
A mon sens, il est relativement stupide de désactiver cette option.
Pourquoi ?
- C'est se priver d'une possibilité rapide et simple de faire face à une erreur humaine.
- Un utilisateur lambda peut même réparer son erreur sans l'intervention du DBA.
- Etant donné que l'on peut modifier le comportement au niveau session, si vraiment dans le cas d'un traitement particulier (table temporaire), on ne veut pas garder de trace il suffit de faire un ALTER SESSIONDROP TABLE ma_table PURGE; Dans ce cas la table va directement dans la néant sans passer par la case corbeille. ou utiliser la commande
- Ca peut même devenir un outil puissant. Exemple : Une application crée par traitement de nuit un pseudo datawarehouse en plusieurs heures en prenant soin de supprimer les tables existantes avant de commencer. Pour une raison inconnu, le traitement se plante. Et bien les utilisateurs finaux n'ont pas accès à leur datawarehoure préféré. En admettant que la hotline soit dans un pays lointain,cela peut prendre plusieurs jours. Grace à une restauration des tables via la corbeille on peut revenir à l'état J-1 très rapidement. (Remarque : Toute information ressemblant à des faits issues du vrai monde, ne serait que pure coincidence !)
- Il convient néanmoins au DBA de surveiller à ce que cette corbeille ne devienne pas trop encombrante et éventuellement de programmer un traitement périodique pour effectuer une purge des objets les plus anciens ou inutiles.
ATTENTION : UN DROP USER ou DROP TABLESPACE, ne passe pas par la corbeille. Il faut passer par une sauvegarde pour récupérer les objets perdus.
ATTENTION : Si vous utilisez des scripts de maintenance appelant la table User_Objects vous devez vous attendre à quelques soucis. Il faut prévoir une clause pour exclure les nom d'objets commencant par BIN$ a moins que vous soyez assez malade pour appeler des indexes ou des tables de la sorte. Autre solution, préferez les vues USER_INDEXES et USER_TABLES que USER_OBJECTS avec une clause sur la colonne TYPE.
LAO.
Partager cet article
