Gestion des annulations

Présentation au sujet: "Gestion des annulations"— Transcription de la présentation:

1 Gestion des annulations
Réalisé par: ZARID Mohamed SOULAIMANI Imane Encadré par: Mr HANOUNE

2 PLAN: Introduction. Définition des annulations.
Le principe des annulations. Mode manuel de gestion de l’espace des annulations. Mode automatique de gestion des annulations. Conclusion.

3 DÉFINITION DES ANNULATIONS
Sont une copie de données d’origine avant une modification. Sont capturées pour toute transaction qui modifie des données. Sont conservées au minimum jusqu'à la fin de la transaction. Permettent : Les opérations d’annulations. Les interrogations cohérentes en lecture et les interrogations flashback. La récupération suite à l’échec de la transaction. Les données des annulations :  Sont une copie de données d’origine avant une modification (Oracle enregistre les anciennes valeurs (données d'annulation) lorsqu'un processus modifie des données dans une base. Ces données sont stockées telles qu'elles étaient avant la modification.)  Sont capturées pour toute transaction qui modifie des données (La capture de données d'annulation permet aux utilisateurs de changer d'avis, c'est-à-dire de procéder à une annulation (rollback).  Sont conservées au minimum jusqu'à la fin de la transaction(  Permettent : • Les opérations d’annulations • Les interrogations cohérentes en lecture et les interrogations flashback(Les interrogations cohérentes en lecture sont des interrogations qui commencent avant une modification des données et qui se terminent après la modification. Oracle fournit des résultats qui sont cohérents par rapport aux données au moment du lancement de l'interrogation. Pour qu'une interrogation cohérente en lecture réussisse, les informations d'origine doivent être présentes sous forme d'informations d'annulation. Tant que ces informations sont conservées, Oracle peut recréer les données afin de satisfaire aux interrogations cohérentes en lecture. Les interrogations flashback sont des interrogations qui demandent, dans un but précis, une image des données telles qu'elles étaient à un instant passé. Tant que les informations d'annulation correspondant à cet instant sont conservées les interrogations flashback peuvent d’annulation conservées, être exécutées • La récupération suite à l’échec de la transaction (Les données d'annulation sont également utilisées pour la récupération suite à l'échec de transactions. Une transaction échoue lorsqu'une session utilisateur se termine de façon anormale (par exemple suite à des erreurs réseau ou à la défaillance de l'ordinateur client), avant que l'utilisateur n'ait décidé de valider (commit) ou d'annuler la transaction. Les transactions peuvent également échouer suite à une défaillance de l'instance. En cas d'échec d'une transaction, le comportement le plus sûr est choisi et Oracle annule toutes les modifications apportées par un utilisateur, en rétablissant les données d'origine.

4 PRINCIPE DES ANNULATIONS
Session 1 SQL> select * from myids;     ID      1      2      3      4 SQL> insert into myids values(5); 1 row created. SQL> select * from myids;     ID      1      2      3      4      5 COMMIT; SQL> select * from myids;     ID      1      2      3      4      5 Session 2 Le principe des annulations est assez simple. En effet, lorsqu’on travaille dans sa session, nous allons créer des transactions (suite d’ordres DML considérée comme indivisible, pour maintenir les données consistentes.). Lors de ces transactions, nous voyons nos données modifiées ... mais pas d’une autre session (principe d’isolation). La validation de la transaction sera appliquée, et donc visible par d’autres sessions, lors du COMMIT. On voit bien dans cet exemple que la transaction n’est pas visible pour tout le monde. Et bien, on a là, tout le mécanisme des annulations. Les transactions qui ne sont pas enregistrées durablement dans la base sont contenues dans des segments spécifiques appelés segments d’annulation. Ces segments permettent d’etablir un ordre ROLLBACK et de retrouver un état en début de transaction. Enfin, les annulations sont également très utiles après un crash d’instance. Si il y avait eu un crash d’instance après mon ordre INSERT, toutes les transactions non validées auraient été annulés lors du redémarrage de l’instance (par SMON). Si un administrateur avait tué ma session, le mécanisme aurait été identique (annulation effectuées par PMON).

5 PRINCIPE DES ANNULATIONS
Et bien réellement, il existe des segments spéciaux appelés RollBack Segments (RBS). Ces segments spéciaux sont en fait des segments circulaires (un segment étant composé d’extensions, elles-mêmes composées de Blocs Oracle), dans lequel toutes les anciennes valeurs seront enregistrées. A ce point, deux scenarii : • un COMMIT valide la transaction alors : o la valeur du SCN est incrémentée o le segment d’annulation est libéré pour d’autres opérations (par incrément du SCN courant) o les données modifiées sont inscrites durablement dans la base (dans les redo log). • un ROLLBACK invalide la transaction alors : o les données contenues dans le RBS sont remises en place dans le segment de données o les données d’annulations sont invalidées et le segment peut-être utilisé pour d’autres annulations.

6 LES MODES DE GESTION DES ANNULATIONS:
MODE MANUEL. MODE AUTOMATIQUE.

7 MODE MANUEL DE GESTION DES ANNULATIONS
Démarrage d’une instance en mode manuel de gestion des annulation Le positionnement du paramètre d'initialisation UNDO_MANAGEMENT à la valeur MANUAL fait que la commande STARTUP démarre l'instance en mode manuel de gestion des annulations. Quand l'instance démarre, elle met un certain nombre de rollback segments en ligne tel que: PARAMETRE D'INITIALISATION DESCRIPTION ROLLBACK_SEGMENTS Spécifie les rollback segments à "acquérir" au démarrage de l'instance TRANSACTIONS Spécifie le nombre maximal de transactions concurrentes TRANSACTIONS_PER_ROLLBACK_SEGMENT Spécifie le nombre de transactions concurrentes que chaque rollback segment espère "supporter". MAX_ROLLBACK_SEGMENTS Spécifie le nombre maximal de rollback segments qui peuvent être en ligne pour une instance. II - MODE MANUEL DE GESTION DE L'ESPACE D'ANNULATION Une instance Oracle est dite opérationnelle en mode manuel de gestion de l'annulation lorsque l'administrateur utilise la méthode "rollback segment" de gestion de l'espace d'annulation. Le positionnement du paramètre d'initialisation UNDO_MANAGEMENT à la valeur MANUAL fait que la commande STARTUP démarre l'instance en mode manuel de gestion des annulations (en anglais : manual undo management mode). Si le paramètre d'initialisation UNDO_MANAGEMENT n'est pas spécifié, l'instance démarre en mode manuel de gestion des annulations. Quand l'instance démarre, elle met un certain nombre de rollback segments en ligne tel que déterminés par : - le paramètre d'initialisation ROLLBACK_SEGMENTS ; - les paramètres d'initialisation TRANSACTIONS et TRANSACTIONS_PER_ROLLBACK_SEGMENT. Le tableau ci-dessous décrit brièvement ces paramètres.

8 MODE MANUEL DE GESTION DES ANNULATIONS
Démarrage d’une instance en mode manuel de gestion des annulation Un ou plusieurs tablespaces peuvent être créés pour les rollback segments. Et ces derniers sont créés manuellement dans ces tablespaces par l'administrateur qui doit préalablement calculer/estimer leur nombre et tailles. Nombre de transactions concurrentes (N) Nombre de rollback segments recommandés N inférieur à 16 4 16 inf. ou égal à N et N inf. à 32 8 32 inf. ou égal à N N/4 Un ou plusieurs tablespaces peuvent être créés pour les rollback segments. Et ces derniers sont créés manuellement dans ces tablespaces par l'administrateur qui doit préalablement calculer/estimer leur nombre et tailles. La taille d'un rollback segment est déterminée par les valeurs du paramètre de stockage du rollback segment (Voir plus loin les commandes "CREATE ROLLBACK SEGMENT" et "ALTER ROLLBACK SEGMENT"). Cette taille peut affecter les performances de la base de données Oracle. Pour le nombre de rollback segments, Oracle fournit les recommandations générales que nous reproduisons dans le tableau ci-dessous. En ce qui concerne les tailles, Oracle donne les règles qui suivent : - Assigner de grands rollback segments aux transactions qui modifient des données pendant que ces dernières sont sélectionnées (commande SQL select) par des requêtes longues qui en général requièrent l'accès à des rollback segments pour reconstruire une version consistante (en lecture) des données modifiées. - Assigner de grands rollback segments aux transactions qui modifient de grandes quantités de données et qui du coup, génèrent beaucoup d'entrées volumineuses d'annulation, à des fins d'amélioration des performances de telles transactions. - Assigner les transactions OLTP (Online Transaction Processing) à de petits rollback segments qui ont une probabilité plus forte de rester stockés dans le cache de tampon où ils peuvent être accédés rapidement. Un rollback segment typique OLTP doit avoir deux extents et une taille de 10 Ko environ. La meilleure façon d'éviter les contentions, c'est de créer beaucoup de rollback segments et d'assigner chaque transaction à sa propre rollback segment. - Utiliser la commande SET TRANSACTION pour assigner des transactions aux rollback segments appropriés comme ci-après : SET TRANSACTION USE ROLLBACK SEGMENT rbs_oltp13

9 MODE MANUEL DE GESTION DES ANNULATIONS
Types et règles de fonctionnement des rollback segments Oracle distingue: Les ROLLBACK segments system. Les ROLLBACK segments non-system. Création et modification des rollback segments Création des rollback: CREATE [PUBLIC] ROLLBACK SEGMENT  STORAGE(INITIAL [KM] NEXT [KM] MINEXTENTS  MAXEXTENTS  OPTIMAL [KM]) Une transaction ne peut utiliser qu'un seul rollback segment pour stocker des enregistrements de rollback. En revanche, plusieurs transactions peuvent écrire dans un même rollback segment. Oracle distingue les rollback segments SYSTEM et non-SYSTEM. Les modifications apportées aux objets du tablespace SYSTEM sont stockées dans le rollback segment SYSTEM qui est créé automatiquement lors de la création de la base de données. Une base de données qui contient des tablespaces non-SYSTEM nécessite au moins deux rollback segments non-SYSTEM. Les rollback segments non-SYSTEM peuvent être privés, publics ou en état différé.

10 PARAMETRE COMMENTAIRES INITIAL Oracle recommande que INITIAL=NEXT afin que les extents soient toujours de même taille ; le paramètre PCTINCREASE ne pouvant être spécifié, il vaut toujours 0. NEXT - MINEXTENTS Ne peut avoir une valeur inférieure à 2 pour les rollback segments. MAXEXTENTS Oracle recommande d'éviter d'attribuer la valeur UNLIMITED à ce paramètre car cela pourrait provoquer une extension inutile d'un rollback segment et même de fichiers de données à la suite d'une erreur de programme. OPTIMAL Est utilisé pour spécifier la taille à laquelle un rollback segment se rétrécira après s'être étendu automatiquement. Définir la valeur de ce paramètre en fonction de l'espace nécessaire pour une transaction moyenne. Si l'on ne dispose pas des informations nécessaires, indiquer une valeur correspondant à la taille initiale (MINEXTENTS * EXTENT_SIZE). C'est la valeur minimale recommandée.

11 MODE MANUEL DE GESTION DES ANNULATIONS
Création et modification des rollback segments Modification des rollback: ALTER ROLLBACK SEGMENT  {ONLINE OFFLINE STORAGE(NEXT MAXEXTENTS OPTIMAL ) SHRINK [TO [KM]] La nature d'un rollback segment, public ou privé ne peut être modifié par la suite. La solution consiste à le supprimer et à le recréer. L'option SHRINK permet au rollback segment de se rétrécir à la taille spécifiée ou à la valeur à laquelle le paramètre OPTIMAL a été positionné. Toutefois le rétrécissement s'arrête si un extent ne peut pas être libéré parce qu'il est actif. Lors de la mise hors ligne d'un rollback segment, si des transactions l'utilisent encore, l'état du rollback segment passe à "PENDING OFFLINE" et est consultable dans la vue de performance dynamique V$ROLLSTAT. Une fois les transactions terminées, le rollback segment est mis hors ligne. La suppression d'un rollback segment se fait à l'aide de la commande DROP ROLLBACK SEGMENT supression d’un rollback segment: DROP ROLLBACK SEGMENT 

12 MODE AUTOMATIQUE DE GESTION DES ANNULATIONS
Démarrage d’une instance en mode automatique de gestion des annulation Le positionnement du paramètre d'initialisation UNDO_MANAGEMENT à la valeur AUTO fait que la commande STARTUP démarre l'instance en mode automatique de gestion des annulations Un undo tablespace dans lequel Oracle stockera les enregistrements d'annulation doit être disponible. l'administrateur peut spécifier au démarrage qu'il souhaite que l'instance utilise un undo tablespace spécifique en positionnant le paramètre d'initialisation UNDO_TABLESPACE : UNDO_TABLESPACE = undotbs_01. Une instance Oracle est dite opérationnelle en mode automatique de gestion de l'annulation lorsque l'administrateur utilise la méthode "undo tablespace" de gestion de l'espace d'annulation. III-1) Démarrage d'une instance en mode automatique de gestion d'annulation Un undo tablespace dans lequel Oracle stockera les enregistrements d'annulation doit être disponible. Quand l'instance démarre, Oracle sélectionne automatiquement le premier undo tablespace disponible. Et s'il n'y en a pas de disponible, l'instance utilise le rollback segment SYSTEM et écrit un message d'alerte dans le fichier d'alertes pour avertir que le système s'exécute sans un undo tablespace. Ceci est fortement déconseillé dans les circonstances normales. Optionnellement, On peut créer plusieurs undo tablespaces par base de données. Mais un seul peut être actif à un moment donné par instance. A tout moment, l'administrateur peut basculer dynamique sur un undo tablespace différent en changeant en ligne le paramètre UNDO_TABLESPACE (commande ALTER SYSTEM). Cependant, s'il veut basculer entre les modes d'annulation automatique et manuel, il doit redémarrer la base de données. On peut effectuer des opérations DDL (create, alter, drop) sur les undo tablespaces ; cependant, on ne peut pas effectuer des opérations DDL sur les undo segments. Nous récapitulons dans les deux tableaux ci-dessous les principaux paramètres utilisés pour le mode automatique de gestion des annulations et ce qu'il faut en retenir.

13 MODE AUTOMATIQUE DE GESTION DES ANNULATIONS
Description des paramètres de gestion automatique d'annulation PARAMETRE DESCRIPTION ET COMMENTAIRES UNDO_MANAGEMENT Détermine si la gestion automatique des annulations (AUM) est activée dans la base de données. La valeur AUTO active l'AUM et la valeur MANUAL le désactive. UNDO_RETENTION Définit la longueur minimale de temps pendant lequel Oracle retient les données d'annulation après leur génération et après l'achèvement de la transaction les ayant générées. UNDO_SUPPRESS_ERRORS Permet de contrôler l'affichage de messages d'erreurs qui résulte de certaines commandes SQL quand la base de données est en mode automatique de gestion des annulations. UNDO_TABLESPACE Définit un ou plusieurs undo tablespaces qui seraient utilisés par Oracle pour la gestion automatique des annulations.

14 MODE AUTOMATIQUE DE GESTION DES ANNULATIONS
Spécificités des paramètres de gestion automatique d'annulation PARAMETRE VALEUR PAR DEFAUT VALEURS VALIDES DYNAMIQUE ? UNDO_MANAGEMENT MANUAL AUTO, MANUAL NON UNDO_RETENTION 900 secondes 0 à la valeur maximale autorisée par 32 bits OUI (immediat pour le système) UNDO_SUPPRESS_ERRORS TRUE TRUE, FALSE Immediat pour le système ; autorisé pour la session UNDO_TABLESPACE On peut utiliser ce paramètre pour spécifier le nom du undo tablespace à utiliser par l'instance. Si ce paramètre n'est pas spécifié, alors Oracle choisira le premier undo tablespace disponible sys_undotbs, ou le rollback segment system si aucun aucun undo tablespace n'est disponible. Nom de undo tablespace valide. Plusieurs undo tablespaces ne sont pas supportés bien qu'Oracle ne génère pas une erreur. Immediat pour le système

15 MODE AUTOMATIQUE DE GESTION DES ANNULATIONS
Informations relatives aux undo segments VUE/TABLE DESCRIPTION DBA_SEGMENTS Vue stockant les informations relatives aux segments créés dans la base de données : leur taille, tablespace, type, paramètres de stockage, etc. DBA_ROLLBACK_SEGS Vue stockant des informations relatives à tous les segments d'annulation : leur status, nom de tablespace, tailles, etc. V$ROLLNAME Vue stockant les numéros et noms de tous les segments d'annulation en ligne. V$ROLLSTAT Vue contenant les statistiques relatives aux annulations : taille de segment, valeur OPTIMAL, nombre de "morceaux depuis le démarrage de l'instance, nombre de transactions actives, extents, status, etc. V$UNDOSTAT Vue collectant des "photographies/instantanés" qui reflètent la performance du tablespace d'annulation comme aide à l'ajustement de sa taille pour supporter les exigences de charge du système qui évolue.

16 MODE AUTOMATIQUE DE GESTION DES ANNULATIONS
Quelques exemples de requêtes Les segments d’annulation de la base de données SQL> select segment_name, owner, tablespace_name, status from dba_rollback_segs ; Statistiques sur les segments d’annulation actuellement utilisés SQL> select n.name, s.extents, s.rssize, s.hwmsize, s.xacts, s.status from v$rollname n, v$rollstat s where n.usn = s.usn ; Vérification que les transactions en cours utilisent un segment d’annulation: SQL> select s.username, t.xidusn, t.ubafil, t.ubablk, t.used_ublk from v$session s, v$transaction t Where s.saddr = t.ses_addr ;

17 CONCLUSION