Généralités sur les systèmes d'exploitation - Site personnel de ...

LO14 : Université Technologique de Troyesétait physique, soit de tuer définitivement cette transaction si le problème était logique (mauvaiseconception de la transaction).2 Les classes d'incidentsUn système informatique, comme tout autre appareil est sujet à des pannes diverses, l'une des plusfréquentes étant sans doute la coupure d'alimentation. L'existence de la propriété de durabilité passe par lacapacité de l'environnement transactionnel à récupérer les trois classes d'incidents suivantes :• INCIDENT-TRANSACTION : c'est la transaction elle-même qui décide de s'arrêter. Statistiquement ladisponibilité est de 97% sur cet incident. Pour un système à haut débit (1000 transactions par secondeou TPS) il y a plus de 30 incidents de ce genre à traiter par seconde.• INCIDENT-SYSTEME : la mémoire principale ne représente plus l'image de la base, arrive deux à troisfois par an.• INCIDENT-SUPPORT : le support physique, c'est à dire le disque est endommagé. Cela arrive de une àdeux fois par ans.Dans un tel cas, la perte de données peut s'avérer catastrophique. Le SGBD doit donc proposer unmécanisme permettant de reprendre des traitements interrompus en cours d'exécution.Il n'est bien sûr pas concevable, dans le cas d'une mise à jour interrompue suite à une panne, ni de relancerla requête à nouveau, car dans ce cas les tuples modifiés avant la panne seraient modifiés une secondefois, ni d'abandonner son traitement. Dans les deux cas, la base deviendrait alors incohérente.L'exemple classique concerne une application bancaire dans laquelle on doit transférer une somme S d'uncompte A à un compte B. L'une des contraintes du système d'information consiste à toujours vérifier que lasomme des soldes des comptes A et B est constante avant et après transfert, ce qui garantit de ne pasperdre d'argent lors d'un virement. Deux ordres doivent être exécutés pour ce traitement :update compteset solde = solde - Swhere num_compte = A ;update compteset solde = solde + Swhere num_compte = B ;Si la contrainte est bien vérifiée avant et après ces deux ordres, la base passe évidemment par une phaseincohérente entre les deux ordres UPDATE. Une panne entre l'exécution de ces deux ordres aurait desconséquences dramatiques.3 La tolérance aux pannesPour assurer la reprise sur panne, les SGBD actuels utilisent la notion de journal.Définition: Un journal est un fichier texte dans lequel le SGBD inscrit, dans l'ordre, toutes les actions demise à jour qu'il effectue.Il existe plusieurs méthodes de gestion d'atomicité d'une transaction à l'aide d'un journal. L'une des plusutilisées est l'utilisation d'un journal incrémental avec mise à jour immédiate. Ce journal doit être stocké enmémoire sûre, généralement sur mémoire non volatile avec réplication.Le principe d'utilisation de ce type de journal est le suivant :Chaque ordre inscrit dans le journal est préfixé par le nom de la transaction. Commençons par donner unexemple :TransactionT1x=read(A)x=x-50write(A,x)Journal incrémentalT1,startT1,A,1550,1500T1,commitOn peut constater :• l'écriture de l'ordre start en début de journal.• qu'un ordre d'écriture dans la base est accompagné par l'inscription contenant notamment le nom del'article concerné, l'ancienne valeur de cet article et la nouvelle valeur à affecter.• La fin de la transaction correspond à un ordre commit est inscrit au journal.En cas d'arrêt intempestif du système deux cas se présentent :64 /98 S. Moutou : Cours