Il y a des moments où vous devez corriger des données sur Prod qui n'existent pas sur d'autres serveurs. Il ne s'agit pas uniquement de bogues, mais pourrait provenir d'une importation de données d'un fichier envoyé par un client qui était incorrecte ou d'un problème causé par un piratage de votre système. Ou d'un problème causé par une mauvaise saisie de données. Si votre base de données est volumineuse ou critique, vous n'aurez peut-être pas le temps de restaurer la dernière sauvegarde et de corriger le dev.
Votre première défense (et quelque chose qu'aucune base de données d'entreprise ne peut se permettre de se passer!) Sont les tables d'audit. Vous pouvez les utiliser pour annuler les modifications de données incorrectes. De plus, vous pouvez écrire des scripts pour ramener les données à l'état précédent et les tester sur d'autres serveurs bien avant de devoir rétablir les données auditées. Ensuite, le seul risque est que vous ayez identifié les enregistrements corrects à rétablir.
Ensuite, tous les scripts pour modifier les données de production doivent inclure les éléments suivants:
Ils doivent être dans des transactions explicites et avoir un bloc TRY Catch.
Ils devraient avoir un mode de test que vous pouvez utiliser pour annuler les modifications après avoir vu ce qu'elles auraient été. Vous devez avoir un état sélectionné avant la modification et une exécution après la modification pour vous assurer que la modification était correcte. Le script doit s'assurer que le nombre de lignes traitées est affiché. Nous avons une partie de cette pré-mise en place dans un modèle qui garantit que les pièces sont terminées. Les modèles de modifications permettent également de gagner du temps lors de l'écriture du correctif.
S'il y a une grande quantité de données à modifier ou à mettre à jour, pensez à écrire le script à exécuter par lots avec des validations pour chaque lot. Vous ne voulez pas verrouiller l'ensemble du système pendant que vous corrigez un million d'enregistrements. Si vous avez de grandes quantités de données à corriger, assurez-vous qu'un administrateur de base de données ou quelqu'un qui est habitué à l'optimisation des performances examine le script avant de l'exécuter et de l'exécuter pendant les heures de repos, si possible.
Ensuite, tous les scripts pour changer quoi que ce soit en production sont examinés et mis en contrôle de code source. Tous - sans exception.
Enfin, les développeurs ne doivent pas exécuter ces scripts. Ils doivent être exécutés par dbas ou un groupe de gestion de configuration. Si vous n'avez ni l'un ni l'autre, alors seules les personnes qui sont des prospects technologiques ou supérieurs devraient avoir le droit d'exécuter des choses sur prod. Moins il y a de personnes qui exécutent des choses sur prod, plus il est facile de détecter un problème. Les scripts doivent être écrits de manière à être simplement exécutés, sans surligner les parties et à exécuter une étape à la fois. Ce sont les éléments de mise en évidence qui mettent souvent les gens en difficulté lorsqu'ils oublient de mettre en évidence la clause where.