Transactions et accès concurrents

Les transactions

Les transactions sont des mécanismes normalisés dans la définition du langage SQL. En revanche, leur implémentation est l’une des caractéristiques qui établit la différence entre les divers fournisseurs de base de données. Notion de transaction Les transactions doivent respecter les principes résumés par l’acronyme ACID : Atomicité : une fois lancée, une transaction doit toujours s’exécuter complètement ou pas du tout. Elle ne peut pas être à moitié exécutée. Cohérence : une transaction assure l’intégrité des données et réalise le passage des données d’un état cohérent à un autre. En cas de problème, pour respecter le principe d’atomicité, l’état cohérent initial est restauré. Isolation : les transactions qui s’exécutent simultanément n’interfèrent pas entre elles. Elles s’exécutent comme si elles étaient lancées séquentiellement. Durabilité : les résultats d’une transaction qui s’est déroulée correctement ne doivent pas être affectés par une panne quelconque du système. Une transaction n’a que deux issues possibles : le succès « COMMIT » ou l’échec « ROLLBACK ». Il n’y a pas de situation intermédiaire. Une transaction est donc un ensemble d’ordres SQL qui ont pour objectif de faire passer la base de données, en une seule étape, d’un état cohérent à un autre état cohérent. Elle comporte un début, une suite d’ordres SQL, puis une fin. Si elle réussit, la base de données est dans un nouvel état cohérent. Si elle échoue (volontairement ou involontairement), les modifications déjà effectuées dans la base sont annulées, de sorte qu’elle retrouve l’état cohérent antérieur au début de la transaction. C’est Oracle 10g qui se charge entièrement de toute cette gestion. Une application, quel que soit l’outil de développement, est composée d’un ensemble de transactions. Le choix et le contenu des transactions sont laissés à l’appréciation des développeurs et parfois même à celle de l’utilisateur final. Les ordres SQL sont regroupés au sein d’une transaction en fonction de plusieurs critères : • les ordres SQL d’une même transaction se complètent souvent pour préserver la cohérence de la base. C’est le cas d’opérations comptables de type « débit-crédit », dans lesquelles chaque opération de débit doit obligatoirement s’accompagner d’un crédit sur un autre compte. Les ordres de débit et de crédit sont alors situés dans la même transaction ; • pour répondre à des impératifs d’ergonomie, chaque transaction ne doit pas être composée d’un trop grand nombre d’ordres SQL. En effet, il faut éviter la suppression de nombreuses informations saisies par l’utilisateur en cas d’annulation d’une transaction. Les règles d’ergonomie préconisent la validation fréquente de transactions courtes .

Les segments d’annulation

Chaque base de données abrite un ou plusieurs segment d’annulation ou segment UNDO. Il contient les anciennes valeurs des enregistrements en cours de modification dans les transactions, qui sont utilisés pour assurer une lecture consistante des données, pour annuler des transactions et en cas de restauration. Principe d’un segment d’annulation Un segment d’annulation ou UNDO gère toutes les transactions de la base. Entre autres choses, il comporte le numéro de fichier, l’identifiant du block contenant les données modifiées et le block de données dans son état initial. Oracle 10g enregistre toutes les actions d’une transaction dans un même segment. Ainsi, la base dispose de tous les éléments pour effectuer l’annulation d’une transaction, c’est-à-dire son ROLLBACK. Dans ce cas, Oracle 10g copie le bloc de données depuis le segment d’annulation vers son ancien emplacement. Segment UNDO et rollback segment Oracle 10g apporte le principe du segment UNDO. Auparavant, seuls les rollback segment existaient. Ils étaient d’une gestion complexe et source de bien des difficultés pour l’administrateur Oracle. La notion de SAVEPOINT est très utile dans la conception de programmes batch, quel que soit le langage utilisé, dont le PL/SQL. Ni les utilisateurs ni l’administrateur ne peuvent accéder ou lire le contenu d’un segment d’annulation ; seul le logiciel Oracle 10g peut l’atteindre. Il est la propriété exclusive de l’utilisateur SYS, quel que soit son créateur.  Oracle affectait alors chaque transaction à un rollback segment unique. En revanche, un rollback segment contenait simultanément les transactions de plusieurs utilisateurs. Pour minimiser les contentions d’accès aux disques, il était très fortement conseillé d’utiliser plusieurs rollback segments. Une méthode simple consistait à disposer de n/3 rollback segments, n étant le nombre maximal d’utilisateurs accédant simultanément à la base. Chaque base Oracle 10g contient encore un rollback segment, propriété de l’utilisateur SYS et situé dans le tablespace SYSTEM. Il est affecté à la gestion du dictionnaire de données et l’administrateur Oracle ne doit effectuer aucune action sur lui. Par leur simplicité et facilité de gestion, nous vous conseillons d’utiliser les tablespaces de type UNDO décrits au chapitre 23, Gestion de l’espace disque et des fichiers. Les lectures consistantes Une des caractéristiques d’Oracle 10g est sa capacité à gérer l’accès concurrent aux données, c’est-à-dire l’accès simultané de plusieurs utilisateurs à la même donnée. Sans des mécanismes perfectionnés de contrôle des accès, les mises à jour simultanées des données pourraient compromettre leur intégrité. Pour pallier la difficulté, il suffit, pour de multiples utilisateurs, de n’autoriser que des accès successifs à une même information, créant ainsi des temps d’attente. Le rôle d’Oracle 10g sera de réduire cette attente jusqu’à la rendre imperceptible. La lecture consistante, telle qu’elle est prévue par Oracle 10g assure : • qu’au sein d’un ordre SQL, les données interrogées ou manipulées ne changeront pas de valeur entre le début et la fin. Tout se passe comme si un « cliché » était effectué sur la totalité de la base au début de l’ordre et que seul ce cliché soit utilisé tout au long de son exécution ; • les lectures ne seront pas bloquées par des utilisateurs effectuant des modifications sur les mêmes données ; • les modifications ne seront pas bloquées par des utilisateurs effectuant des lectures sur ces données ; • un utilisateur ne peut lire les données modifiées par un autre, si elles n’ont pas été validées. Pour lui, elles resteront dans leur état validé précédent ; • il faudra patienter pour modifier des informations en cours de modification dans une autre transaction. Pour gérer à la fois les lectures et les mises à jour, Oracle 10g conserve les deux informations : les données mises à jour sont écrites dans les segments de données de la base et les anciennes valeurs sont consignées dans les segments d’annulation ou UNDO segments. Ainsi, l’utilisateur de la transaction modifiant les valeurs lira les données modifiées et tous les autres liront les données non modifiées. Un autre utilisateur accédera à la fois aux données conservées dans la table (toutes les données n’ont pas été modifiées) et aux anciennes données stockées dans les segments d’annulation.