SGBD distribué - Échec et validation

Un système de gestion de base de données est susceptible de subir un certain nombre de pannes. Dans ce chapitre, nous étudierons les types d'échec et les protocoles de validation. Dans un système de base de données distribué, les pannes peuvent être globalement classées en pannes logicielles, pannes matérielles et pannes réseau.

Panne douce

La défaillance logicielle est le type de défaillance qui provoque la perte de la mémoire volatile de l'ordinateur et non du stockage persistant. Ici, les informations stockées dans le stockage non persistant comme la mémoire principale, les tampons, les caches ou les registres, sont perdues. Ils sont également connus sous le nom de crash système. Les différents types de pannes logicielles sont les suivants:

• Panne du système d'exploitation.
• Crash de la mémoire principale.
• Échec de la transaction ou avortement.
• Erreur générée par le système comme un dépassement d'entier ou une erreur de division par zéro.
• Échec du logiciel de support.
• Panne électrique.

Échec dur

Une défaillance matérielle est le type de défaillance qui entraîne la perte de données dans le stockage persistant ou non volatile comme le disque. Une panne de disque peut entraîner une corruption des données dans certains blocs de disque ou une panne du disque total. Les causes d'une défaillance grave sont -

• Panne électrique.
• Défauts dans les médias.
• Dysfonctionnement en lecture-écriture.
• Corruption des informations sur le disque.
• Crash de la tête de lecture / écriture du disque.

La récupération après une panne de disque peut être courte, s'il existe un nouveau disque formaté et prêt à l'emploi en réserve. Sinon, la durée comprend le temps nécessaire pour obtenir un bon de commande, acheter le disque et le préparer.

Panne de réseau

Les pannes de réseau sont fréquentes dans les bases de données distribuées ou réseau. Celles-ci comprennent les erreurs induites dans le système de base de données en raison de la nature distribuée des données et du transfert des données sur le réseau. Les causes de la défaillance du réseau sont les suivantes -

• Échec de la liaison de communication.
• La congestion du réseau.
• Corruption des informations lors du transfert.
• Pannes du site.
• Partitionnement du réseau.

Protocoles de validation

Tout système de base de données doit garantir que les propriétés souhaitables d'une transaction sont conservées même après des échecs. Si un échec survient lors de l'exécution d'une transaction, il peut arriver que toutes les modifications apportées par la transaction ne soient pas validées. Cela rend la base de données incohérente. Les protocoles de validation empêchent ce scénario en utilisant l'annulation de transaction (restauration) ou la restauration de transaction (restauration en avant).

Point de validation

Le moment auquel la décision est prise de valider ou d'abandonner une transaction est appelé point de validation. Voici les propriétés d'un point de validation.

• C'est un moment où la base de données est cohérente.

• À ce stade, les modifications apportées par la base de données sont visibles par les autres transactions. Toutes les transactions peuvent avoir une vue cohérente de la base de données.

• À ce stade, toutes les opérations de transaction ont été exécutées avec succès et leurs effets ont été enregistrés dans le journal des transactions.

• À ce stade, une transaction peut être annulée en toute sécurité, si nécessaire.

• À ce stade, une transaction libère tous les verrous qu'elle détient.

Annuler la transaction

Le processus d'annulation de toutes les modifications apportées à une base de données par une transaction est appelé annulation de transaction ou annulation de transaction. Ceci est principalement appliqué en cas de défaillance logicielle.

Rétablir la transaction

Le processus de réapplication des modifications apportées à une base de données par une transaction est appelé transaction redo ou transaction roll forward. Ceci est principalement appliqué pour la récupération après une panne matérielle.

Journal des transactions

Un journal des transactions est un fichier séquentiel qui assure le suivi des opérations de transaction sur les éléments de la base de données. Comme le journal est de nature séquentielle, il est traité séquentiellement depuis le début ou depuis la fin.

Objectifs d'un journal des transactions -

• Pour prendre en charge les protocoles de validation pour valider ou prendre en charge les transactions.
• Pour faciliter la récupération de la base de données après une panne.

Un journal des transactions est généralement conservé sur le disque afin qu'il ne soit pas affecté par les pannes logicielles. En outre, le journal est périodiquement sauvegardé sur un stockage d'archives comme une bande magnétique pour le protéger également des pannes de disque.

Listes dans les journaux de transactions

Le journal des transactions gère cinq types de listes en fonction de l'état de la transaction. Cette liste aide le gestionnaire de récupération à vérifier l'état d'une transaction. L'état et les listes correspondantes sont les suivants -

• Une transaction qui a un enregistrement de début de transaction et un enregistrement de validation de transaction est une transaction validée - maintenue dans la liste de validation.

• Une transaction qui a un enregistrement de début de transaction et un enregistrement d'échec de transaction mais pas un enregistrement d'abandon de transaction, est une transaction ayant échoué - maintenue dans la liste des échecs.

• Une transaction qui a un enregistrement de début de transaction et un enregistrement d'abandon de transaction est une transaction abandonnée - conservée dans la liste d'abandons.

• Une transaction qui a un enregistrement de début de transaction et un enregistrement de transaction avant validation est une transaction avant validation, c'est-à-dire une transaction dans laquelle toutes les opérations ont été exécutées mais non validées - conservées dans la liste avant validation.

• Une transaction qui a un enregistrement de début de transaction mais aucun enregistrement d'avant-validation, de validation, d'abandon ou d'échec, est une transaction active - maintenue dans la liste active.

Mise à jour immédiate et mise à jour différée

La mise à jour immédiate et la mise à jour différée sont deux méthodes de gestion des journaux de transactions.

Dans immediate updatemode, lorsqu'une transaction s'exécute, les mises à jour effectuées par la transaction sont écrites directement sur le disque. Les anciennes valeurs et les valeurs de mises à jour sont écrites dans le journal avant d'écrire dans la base de données sur le disque. Lors de la validation, les modifications apportées au disque sont rendues permanentes. Lors de la restauration, les modifications apportées par la transaction dans la base de données sont ignorées et les anciennes valeurs sont restaurées dans la base de données à partir des anciennes valeurs stockées dans le journal.

Dans deferred updatemode, lorsqu'une transaction s'exécute, les mises à jour apportées à la base de données par la transaction sont enregistrées dans le fichier journal. Lors de la validation, les modifications du journal sont écrites sur le disque. Lors de la restauration, les modifications du journal sont ignorées et aucune modification n'est appliquée à la base de données.