Les incohérences et pertes de données accidentelles

10.4.1 Définition

Par incohérence accidentelle, on entend toute coupure non intentionnelle des liens logiques entre les données d'une BD.

Exemple d'une incohérence accidentelle:

Dans les systèmes multi-utilisateur, il se peut que deux utilisateurs accèdent en même temps, aux mêmes enregistrements d'une BD sur le serveur. On parle d'un accès concurrent.

Nous supposons, que les deux utilisateurs exécutent en même temps, de façon indépendante l'un de l'autre, les deux requêtes suivantes:

Utilisateur 1 Utilisateur 2 UPDATE Employés SET fldDépartement="CPT" WHERE fldDépartement="Comptabilité"; UPDATE Employés SET fldSalaire=fldSalaire*1.1 WHERE fldDépartement="Comptabilité" AND fldDateNaiss<#1/1/70#;

Nouvelle codification pour le service de comptabilité.

Tous les employés du service comptabilité nés avant le 1/1/70 , subissent une hausse de salaire de 10%.

Nous supposons en plus que la requête de l'utilisateur numéro 2 est exécutée quelques instants avant l'autre requête.

Cependant, la requête de l'utilisateur 1 s'exécute un peu plus vite que l'autre, puisque pour chaque enregistrement, il y a uniquement un seul critère de sélection à vérifier.

A un certain moment, l'exécution de la requête 1 aura dépassée celle de la requête 2, donc pour certains enregistrements, le code "Comptabilité" est changé en "CPT", avant que la

requête 2 ne puisse effectuer la modification du salaire. Parmi tous les employés ayant droit à une hausse de salaire, certains sont donc "ignorés".

Le problème des accès concurrents se pose surtout dans les systèmes avec beaucoup d'utilisateurs émettant beaucoup de requêtes, tels que par exemple la gestion des dépôts d'une banque.

Ce problème peut être résolu par le mécanisme de la sérialisation d'exécution des requêtes1_,

supporté automatiquement par tous les SGBD multi-utilisateur exécutés sur un serveur de BD. Ce mécanisme garantit une exécution en série de plusieurs requêtes, même lorsque celles-ci sont envoyées par plusieurs utilisateurs en même temps.

Exercice

Donnez un exemple supplémentaire d'une incohérence accidentelle et d'une perte accidentelle.

10.4.2 La protection contre les incohérences et pertes de

données accidentelles

Tous les SGBD implémentent des fonctionnalités, qui garantissent la cohérence des données en fonctionnement normal. A titre d'exemple mentionnons les contraintes d'intégrité et la sérialisation d'exécution des requêtes.

Une incohérence accidentelle peut donc en principe uniquement apparaître suite à une perte accidentelle de données. Citons la perte d'enregistrements, qui contiennent des clés primaires liées à des clés étrangères d'une autre table.

Par conséquent, nous allons limiter la discussion suivante aux pertes accidentelles.

Les causes des pertes de données accidentelles sont réparties en trois groupes: 1. Les pertes provoquées par des erreurs humains;

2. Les pertes des données en mémoire interne (RAM). 3. Les pertes des données stockées sur disque dur.

10.4.2.1 Les pertes provoquées par des erreurs humaines

Ce type de pertes est difficilement maîtrisable. Toutefois, une bonne formation des utilisateurs d'un système aide à réduire le nombre de telles pannes.

Exemple d'une perte provoquée par une erreur humaine:

Une requête de suppression mal formulée en SQL, efface trop d'enregistrements.

10.4.2.2 Les pertes des données en mémoire interne (RAM)

Les BD résidant normalement sous forme de fichier(s) sur le disque dur, sont partitionnées en blocs de longueur fixe, avec chaque bloc contenant un ou plusieurs enregistrements. Un SGBD appelle les blocs nécessaires en mémoire centrale et les retourne sur le disque suite aux modifications effectuées.

Les données résidant en mémoire interne ne résistent pas à un crash; et sont perdues de façon irrécupérable. Comme les blocs avec les enregistrements sont généralement retournés vers le disque dur assez vite après une opération de modification, l'impact d'une perte de données en mémoire interne n'est toutefois pas très grand.

Exemples de causes pour la perte de données en mémoire interne:

• un crash système provoqué par un défaut matériel; • un crash système provoqué par un défaut logiciel; • une coupure d'alimentation électrique.

10.4.2.3 Les pertes des données stockées sur disque dur

Les données stockées sous forme de fichier(s) sur disque dur peuvent en principe également être perdues, mais heureusement il existe des mesures de prévention d'une perte de données sur disque, puisque l'impact d'une telle perte peut être énorme, et peut dans le pire, aboutir dans la perte complète de la BD.

Exemples de causes pour la perte de données sur disque dur:

• une manipulation erronée effectuée par un utilisateur;

• une erreur de logiciel (angl. Bug) a causé une incohérence de certaines données; • une panne d'un disque.

10.4.3 Les mesures de prévention contre la perte de données

10.4.3.1 La sauvegarde des données (angl. backup)

Une méthode préventive contre la perte de données sur disque dur est la sauvegarde régulière des données du (des) disque(s).

L'opération de sauvegarde (ang. backup) d'une BD consiste dans la copie du resp. des fichiers qui contiennent la BD, du disque dur vers un support de sauvegarde. Ceci est fait au niveau du système d'exploitation.

Lors d'une perte de données d'un disque, on peut restituer (angl. restore) les données sur le disque à partir du support de sauvegarde.

Afin de pouvoir effectuer une sauvegarde des fichiers BD au niveau du système d'exploitation, la BD doit être "fermée", ce qui veut dire que personne ne doit être en train d'effectuer n'importe quelle manipulation. Sinon, on risque de sauvegarder des fichiers incohérents.

Au niveau des SGBD pour serveurs, il existe des systèmes, qui permettent la sauvegarde "intelligente" d'une table pendant que celle-ci est consultée ou même modifiée.

On distingue généralement deux types de sauvegardes: 1. La sauvegarde complète (angl. full backup)

Toutes les données sont sauvegardées