Quelles sont les pratiques que vous suivez pour éviter les mises à jour de données erronées dans les grandes bases de données?
Un conseil typique avant tout déploiement de production est de sauvegarder la base de données en premier. De cette façon, si la nouvelle mise à jour présente un problème qui peut entraîner une perte de données potentielle ou une corruption des données logiques, vous disposez toujours d'une sauvegarde pour comparer et corriger les anciens enregistrements.
Cependant, cela peut bien fonctionner jusqu'à ce que la taille de la base de données soit de quelques Go. Une fois que la taille de la base de données est énorme, les sauvegardes prennent beaucoup de temps. Quelles sont les meilleures pratiques à suivre dans de telles situations, afin d'éviter la corruption des données logiques en raison de problèmes logiques dans un déploiement de code?
En tant que personne qui s'occupe régulièrement de la mise à jour de la base de données de production pour les clients pour nos mises à niveau logicielles, je vous dis que la meilleure façon de minimiser les erreurs est de faire des mises à jour aussi simples que possible.
Si vous pouvez modifier tous les enregistrements plutôt que des enregistrements spécifiques, il est préférable.
En d'autres termes, si vous recevez une liste d'ID d'enregistrements dont l'état doit être modifié, vous devez vous demander pourquoi la mise à jour est effectuée dans le contexte du programme. Cela peut être celui des 10 enregistrements que vous devez mettre à jour, le tableau uniquement a 10 éléments. Par conséquent, vous devriez vous demander si, conceptuellement, tout ce que vous faites est de mettre à jour l'état de tous les enregistrements.
Si vous pouvez insérer, c'est préférable.
L'acte d'ajouter un enregistrement est autonome. J'entends par là qu'il n'y a qu'un seul effet secondaire de l'ajout d'un enregistrement, et c'est l'existence d'un enregistrement qui n'existait pas auparavant. Par conséquent, à moins que vous n'ajoutiez un enregistrement qui ne devrait pas y figurer, il ne devrait y avoir aucun problème.
Si vous pouvez éviter la suppression, il est préférable.
Si vous effectuez une suppression, vous supprimez des données qui seraient autrement irrécupérables sans sauvegarde. Si possible, essayez d'organiser les données de manière à pouvoir désactiver les enregistrements en modifiant son état plutôt qu'en supprimant physiquement l'enregistrement. L'excédent de données peut être placé dans une partition ou il peut être entièrement supprimé ultérieurement lorsque vous êtes sûr qu'il n'y a pas de problème.
Ayez une politique de mise à jour cohérente.
Si vous devez mettre à jour un enregistrement, plusieurs choses peuvent se produire:
- Votre dossier n'existe pas.
- Votre dossier existe mais il a déjà été modifié.
- Votre dossier existe et nécessite le changement.
Vous devez avoir une politique pour déterminer la marche à suivre si quelque chose ne se passe pas comme prévu. Pour des raisons de simplicité, vous devez être cohérent dans tous les domaines et appliquer cette stratégie dans une situation de ce type any, et pas seulement pour des tables spécifiques. Cela facilite la récupération ultérieure des données. Généralement, ma politique est d'écrire le script de manière à pouvoir le ré-exécuter plus tard. Si le script échoue, il est bon de savoir que vous pouvez effectuer les ajustements appropriés et réexécuter, mais vous êtes libre de choisir votre propre politique qui vous convient le mieux.
Sauvegardes
Cela ne vous excuse en aucun cas d'effectuer une sauvegarde avant d'effectuer une mise à jour dans un environnement de production! Bien que même avec une sauvegarde, je considère que c'est un échec d'avoir à utiliser la sauvegarde. La perte de données ne peut pas être une possibilité même dans le scénario pire des cas.
Conclusion
Tu ne vas pas toujours pouvoir l'avoir à ta façon. Le schéma de table ne sera probablement pas déterminé par vous, et en tant que tel, cela signifie que les types de mises à jour que vous pouvez vous attendre à effectuer seront à la fois compliqués et risqués. Bien que si vous avez un mot à dire à ce sujet, il est utile de garder ces points à l'esprit car ils effectuent des mises à jour directement et sans risque significatif.
Bonne chance!
À ce stade, vous devriez utiliser un système DB de qualité commerciale qui prend en charge instantanés (Oracles l'appelle Flashback ) - c'est exactement le genre de chose à laquelle ils sont destinés.
Gardez à l'esprit que vous avez quand même besoin d'un concept de sauvegarde - avoir plus de données ne signifie pas que vous supprimez les sauvegardes car elles deviennent difficiles, bien au contraire. Vous avez besoin d'une sorte de sauvegarde continue, par exemple basé sur la réplication avec basculement automatique.
C'est un domaine énorme - alors attendez-vous à ce que cette question soit fermée dans un délai assez court, mais, du haut de ma tête (en tant qu'ancien DBA sur d'énormes bases de données):
Mart/Repository
Vous pouvez atténuer certains risques si vous disposez d'une base de données distincte pour les mises à jour et d'une base de données distincte que tout le monde utilise. Ensuite, il s'agit simplement de copier les données d'un DB à l'autre une fois que diverses vérifications ont été effectuées. Mart/repository est la façon dont il est parfois décrit, mais vous pouvez avoir primaire/secondaire, maître/esclave, etc.
Code source
Pour tout ce qui peut changer, ayez un code source qui se rapporte à comment les données ont été mises à jour. Le nombre de ceux-ci varie d'une base de données à l'autre, mais vous pouvez en avoir un pour chaque utilisateur, rôle, flux de données, module de code, etc.
date de création/mise à jour
La création et la mise à jour des données pour chaque ligne peuvent être très utiles lors du suivi des problèmes. Ensuite, vous pouvez voir d'un coup d'œil quelles lignes ont été mises à jour.
ETL
Si la mise à jour de la base de données fait partie d'une fabrique de données, vous pourrez peut-être restaurer un millésime précédent à partir de fichiers plats.
Sauvegarde
Les sauvegardes complètes prennent bien sûr beaucoup d'espace mais le scénario habituel est qu'une sauvegarde complète se produise à intervalles réguliers (dit, hebdomadaire) et partielles plus fréquemment (quotidiennement, etc.).
Récupération ponctuelle
Selon le SGBDR que vous utilisez, certains points de support prennent en charge la récupération dans le temps. Cela vous permet de revenir à l'époque où un bon état était connu. Cela nécessite cependant une grande quantité de stockage qui augmente en fonction de la distance que vous souhaitez parcourir.
Audit
Les tables d'audit vous diront qui (ou quoi) a mis à jour une ligne. Cela peut vous donner un bon point de départ pour une enquête.
Histoire
Pour certaines tables critiques, une copie de la ligne pertinente est prise au moment de la mise à jour afin que les données puissent être restaurées si nécessaire.
Validation des données
Assurez-vous que les contrôles de validation de base sont effectués sur les données avant leur stockage - en plus des contrôles de type de données de base.
Intégrité référentielle
L'intégrité référentielle n'est pas une solution miracle, mais elle peut aider à garantir que les données sont bien structurées.
Plusieurs fois, si nous effectuons une mise à jour "en une fois", nous prenons une sauvegarde de la production et la restaurons sur un serveur de test. Ensuite, nous créons une combinaison de tests et exécutons le one shot. Nous vérifions que les données ont changé via les tests et nous nous assurons que cette mise à jour réussira et modifions les données d'une manière que nous attendons. C'est ce qu'on appelle un essai à sec ou d'essai. Je recommande de faire ça.
Cela donne à tout le monde un bon sens que le one shot réussira. Nous ne pouvons pas garantir 100% car les données seront mises à jour à partir de la date de l'essai, mais nous renforçons la confiance et les facteurs de réussite. Cela donne également une vraie idée de tous les problèmes qui se produiront puisque nous utilisons une copie de la production. Maintenant, si pour une raison quelconque, la mise à jour échoue, nous pouvons toujours revenir à la version précédente avant de restaurer si nécessaire, mais nous aurions dû trouver et corriger tout problème lié à la version sèche.
Si vous ne pouvez pas prendre l'intégralité de la base de données (si elle est vraiment grande), essayez d'exporter une taille d'échantillon plus petite et exécutez la mise à jour (petite analyse à sec) par rapport aux données réelles. Je préférerais l'ensemble des données si possible pour garantir que le test est aussi complet que possible.