Firebird Documentation IndexFirebird 1.5 Guide de démarrage → Comment corrompre une base de données
Firebird Home Firebird Home Précédent: SauvegardeFirebird Documentation IndexNiveau supérieur: Firebird 1.5 Guide de démarrageSuivant: Et ensuite

Comment corrompre une base de données

1. Modifier les tables de métadonnées vous-même
2. Désactiver les écritures forcées (forced writes) sous Windows
3. Restaurer une sauvegarde sur base en cours d'exécution
4. Permettre aux utilisateurs de se connecter pendant une restauration

1. Modifier les tables de métadonnées vous-même

Firebird stocke et maintient toutes les métadonnées de ses propres objets ainsi que ceux que vous définissez dans : une base de données Firebird ! Plus précisément, il stocke ceux-ci en relations (tables) directement dans la base elle même. Les identifiants pour les tables système, leurs colonnes ainsi que plusieurs autres types d'objets système commencent avec les caractères RDB$.

Puisqu'ils sont des objets de base de données ordinaires, ils peuvent être interrogés et manipulés comme les objets que vous définissez. Cependant, ce n'est pas parce que vous le pouvez que vous le devez. Le moteur de Firebird implémente un ensemble d'outils SQL de haut niveau (DDL) dans le but de définir et maintenir les métadonnées, classiquement à l'aide des commandes CREATE, ALTER et DROP.

On ne peut jamais recommander assez de n'utiliser que DDL – pas d'opérations directes en SQL sur les tables systèmes – pour modifier ou supprimer des métadonnées. Evitez les « trucs et astuces » tant que votre connaisance du SQL et du moteur Firebird ne sont pas à un niveau très élevé. Une base de données sabordée coûte cher en réparations.

2. Désactiver les écritures forcées (forced writes) sous Windows

Firebird est installé avec le paramêtre forced writes (ecritures synchrones) activé par défaut. Les modifications ou les nouvelles données sont immédiatement écrites sur le disque dès leur signalement.

Il est possible de configurer une base de données pour qu'elle utilise l'écriture des données asynchrone – ce qui permet de garder en mémoire cache les nouvelles données ou modifications. La mémoire cache est vidée périodiquement sur le disque par le sous-système d'entrée sortie du système d'exploitation. Le terme commun pour cette configuration est forced writes off (ou désactivé). Il est quelquefois intéressant d'y avoir recours afin d'améliorer les performances pendant de grandes operations en lots.

Le mot d'ordre ici est : ne désactivez pas les écritures forcées sur un serveur Windows. On a observé que les serveurs Windows ne vident pas le cache tant que le service Firebird n'est pas arrété. Indépendament des coupures de courant electrique, il y a trop de choses qui peuvent mal fonctionner sur un serveur Windows. Si votre serveur plante, le système d'E/S ne fera pas son travail et vos utilisateurs perdront leur travail au redémarrage.

Note

Windows 9x et ME ne supportent pas les écritures différées

Désactiver les écritures forcées (forced writes) sous Linux

Les serveurs Linux sont plus fiables pour exécuter une opération avec les écritures forcées désactivées temporairement. Toutefois, ne les laissez pas désactivées une fois votre opération terminée, sauf si vous avez un système très robuste de protection contre les coupures de courant électrique.

3. Restaurer une sauvegarde sur base en cours d'exécution

Une des options de restauration de l'utilitaire gbak (gbak -r[eplace]) vous permet de restaurer un fichier gbak par dessus une base de données existante. Il est possible d'effectuer ce style de restauration sans même avertir les utilisateurs connectés à la base de données. Dans un tel cas, il est presque certain que la base de données sera endommagée.

Avertissement

Soyez attentif au fait que vous devez écrire vos outils d'administration de manière à éviter qu'un utilisateur (y compris SYSDBA) ne puisse restaurer une base active si un utilisateur y est connecté.

Note

Pour plus de détail sur gbak, voir le chapitre 21, Sauvegarde et restauration de base de données, dans Utiliser Firebird.

Pour les instructions permettant de bloquer l'accès des utilisateurs, voir le chapitre 14, Obtenir l'accès exclusif à une base de données, dans Utiliser Firebird.

Si cela est possible, il est recommandé de restaurer sur un autre espace disque en utilisant l'option gbak -c[reate] et tester la base restaurée en utilisant isql ou votre outil préféré d'administration. Si la base restaurée est bonne, arrêtez le serveur Firebird. Faites une copie de votre ancienne base puis copiez le ou les fichiers de la base restaurée en lieu et place des fichiers originaux.

4. Permettre aux utilisateurs de se connecter pendant une restauration

Si vous ne bloquez pas l'accès des utilisateurs pendant le processus de restauration en utilisant gbak -r[eplace] alors les utilisateurs peuvent se connecter et tenter de faire des opérations sur les données. La structure sera alors endommagée.

Précédent: SauvegardeFirebird Documentation IndexNiveau supérieur: Firebird 1.5 Guide de démarrageSuivant: Et ensuite
Firebird Documentation IndexFirebird 1.5 Guide de démarrage → Comment corrompre une base de données