Réparer en toute sécurité les données de la base de données de production

Question

Des bogues se produisent et parfois les données doivent être corrigées en production.Quelle est la manière la plus sûre de s'y prendre du point de vue d'une grande entreprise ?Existe-t-il des outils qui peuvent aider?Voici quelques considérations à l'origine de cette exigence...

1. Nous devons enregistrer qui a exécuté la requête et ce qu'il a exécuté
2. Idéalement, nous devons donner à la personne l'accès pour exécuter uniquement des requêtes sur les tables d'intérêt et uniquement pour une courte période.
3. Quelle que soit l'exécution des requêtes, elle doit être intelligente pour ne pas autoriser l'exécution longue et le verrouillage de SQL sans autorisation explicite.
4. Ce processus doit être indépendant de la base de données ou au moins comprendre DB2, Oracle et SQL Server.

Nous essayons de réduire le risque que les requêtes de correction de prod ad-hoc ne fassent la "mauvaise chose" et en même temps ajoutons un peu de sécurité/audit au processus.Pensées ou idées ?

Answer 1

Ne mettez jamais à jour manuellement les bases de données de production.

Écrire des scripts.

Vérifiez-les trois fois et demandez à plusieurs personnes de le faire, pas seulement à une seule personne de le faire trois fois.

Incluez des requêtes de validation post-modification dans ces scripts.

Chaque fois que la situation le permet, testez l'intégralité de la modification dans une transaction qui est annulée à la fin, après l'exécution de la validation post-modification.Lorsque vous êtes sûr des résultats, remplacez la restauration par un commit.

Testez ces scripts jusqu'à la nausée contre une base de données de test.

Effectuez une sauvegarde avant d'exécuter le script sur la base de données de production.

Exécutez les scripts.

Vérifiez, validez et vérifiez trois fois les données modifiées à l'aide des scripts de validation post-modification.

Faites quand même un contrôle visuel.

Si quelque chose semble éteint, reculez et restaurez la sauvegarde.

Ne continuez pas avec les données modifiées comme données de production jusqu'à ce que vous soyez absolument sûr que tout va bien et que vous ayez obtenu l'approbation des responsables (de l'entreprise) concernés.

Answer 2

La réponse de Marjan Venema est techniquement valable et doit être suivie dans la mesure du possible.Hélas, Marjan répond du point de vue d'un théoricien , ou d'un administrateur de base de données puriste qui aime faire les choses proprement.En pratique, parfois les contraintes métiers rendent impossible de faire les choses proprement.

Imaginez le cas suivant :

1. Il y a un bogue dans le produit logiciel qui l'empêche de fonctionner lorsqu'il détecte ce qu'il pense être une incohérence de données dans la base de données,

2. Tous les développeurs susceptibles de corriger le bug de l'application sont injoignables,

3. L'entreprise perd actuellement des milliers de dollars par heure (disons 6 000 $, ce qui signifie 100 $ par minute),

4. Le bug affecte plusieurs tables, dont une énorme, et ne concerne que les données elles-mêmes, pas le schéma,

5. Afin de contourner le bogue, vous devez expérimenter un peu les données, ce qui implique à la fois de les supprimer et de les modifier,

6. La base de données est volumineuse et il faudrait trois heures pour prendre ou restaurer la sauvegarde,

7. La dernière sauvegarde complète a été effectuée il y a trois semaines ;il existe également des sauvegardes incrémentielles quotidiennes, et la dernière sauvegarde incrémentielle quotidienne a été effectuée il y a 14 heures,

8. Les sauvegardes de base de données sont supposées fiables ;ils ont été mis à rude épreuve, y compris récemment,

9. Perdre 14 heures de données n'est pas acceptable, mais la perte d'une à deux heures de données l'est,

10. L'environnement de mise en scène a été utilisé pour la dernière fois il y a six mois ;il semble qu'il ne soit pas à jour, et cela peut prendre des heures pour le configurer,

11. La base de données est Microsoft SQL Server 2008 Entreprise.

La façon propre de faire les choses est de :

1. Restaurer la sauvegarde dans un environnement intermédiaire,

2. Expérimentez là,

3. Vérifiez le script final deux fois,

4. Exécutez le script sur le serveur de production.

La première étape coûtera 18 000 $ à votre entreprise.Le risque est assez faible si vous faites parfaitement la troisième étape, mais puisque vous travaillez sous une pression extrême, le risque serait beaucoup plus élevé.Vous pouvez vous retrouver avec un script qui a parfaitement fonctionné dans la mise en scène, puis visser la base de données de production.

Au lieu de cela, vous auriez pu faire comme ceci:

1. Créez un instantané (Microsoft SQL Server le prend en charge, et il faut quelques secondes pour rétablir (et rien à créer) un instantané d'une base de données qui prend une heure à sauvegarder ; j'imagine que d'autres produits de base de données prennent également en charge les instantanés),

2. Expérimentez directement sur la base de données de production, en revenant à l'instantané en cas de problème.

Alors qu'un puriste réparerait la base de données de manière propre et risquerait toujours de tout gâcher étant donné la pression du temps tout en gaspillant plus de 20 000 $ de son entreprise, un administrateur de base de données qui tient compte des contraintes commerciales réparera la base de données d'une manièrece qui minimisera les risques (grâce aux snapshots) tout en le faisant rapidement.

Conclusion

Je suis moi-même un puriste et je déteste faire les choses d'une manière qui n'est pas propre.En tant que développeur, je refactorise le code que je modifie, je commente les parties difficiles qui n'ont pas pu être refactorisées, je teste unitairement la base de code et je fais des revues de code.Mais je prends également en considération les circonstances dans lesquelles soit vous faites les choses proprement et le lendemain vous êtes viré, soit vous minimisez à la fois les risques et l'impact financier en faisant un hack rapide qui fonctionne.

Si un informaticien veut faire les choses proprement juste pour la propreté alors que cela cause des milliers de dollars de perte pour l'entreprise, cet informaticien a une profonde incompréhension de son travail.

Answer 3

Correction en toute sécurité des données de la base de données de production.Quelle est la manière la plus sûre de s'y prendre du point de vue d'une grande entreprise ?Existe-t-il des outils qui peuvent aider?

C'est une mauvaise pratique et une porte d'invitation pour plus de problèmes et de problèmes de données.Il y a même une phrase qui décrit cette approche comme " Quick and Dirty ".

Continuer les correctifs/mises à jour directement sur un serveur de production est très dangereux , car cela vous coûtera une fortune à vous/votre entreprise ( poursuites judiciaires, données mauvaises/sales, entreprises perdues, etc. )

Cependant, des bogues seront là et devront être corrigés.La norme industrielle de facto consiste à appliquer des correctifs / (scripts de déploiement) sur un Staging (environnement de pré-production avec la dernière copie de la base de données prod) et à laisser l'analyste de données / QA vérifier le correctif.Le même script doit être contrôlé en version et appliqué à l'environnement Prod pour éviter les problèmes.

Il y a un certain nombre de bonnes pratiques mentionnées dans cet article connexe - Bonnes pratiques de la base de données intermédiaire

Un bon ensemble de références à rechercher sont :

• En combien de temps pouvez-vous mettre un bogue corrigé en production ?
• Pyramide des coûts de développement logiciel
• Combien de temps doit être alloué pour les tests et la correction des bogues

Answer 4

Dans la plupart des organisations, j'ai travaillé à la mise à jour des données dans l'environnement en direct, qui était toujours effectuée par un petit groupe de personnes disposant des droits d'accès pour le faire, généralement avec un titre de poste tel que DBA.Comme les mises à jour ne peuvent être effectuées que par un petit nombre de personnes, il y a au moins une chance qu'elles se familiarisent avec les données et réduisent donc (mais n'éliminent pas) le risque de problèmes.

La personne qui écrit le script de mise à jour le ferait en test (selon les autres réponses) et obtiendrait l'approbation sérieuse des non-techniciens (ceux qui connaissent le système, ainsi qu'une personne ayant une autorité supérieure) que les fonctionnalités semblent être `` correctes '' dansen plus de leurs propres tests paranoïaques.Les scripts et les données seraient vérifiés de manière indépendante par un autre technicien (souvent le rôle DBA que j'ai mentionné) lors des tests avant d'être mis en production.Les résultats seraient vérifiés par rapport aux valeurs anticipées (uniques pour chaque scénario, mais souvent des choses comme le nombre de lignes, etc.)

Dans une entreprise pour laquelle j'ai travaillé, effectuer des sauvegardes n'était pas une option réaliste, mais toutes les lignes à mettre à jour ont été écrites dans un fichier texte pour référence AVANT la mise à jour, puis à nouveau APRÈS la mise à jour si quelqu'un devait s'y référer.Les scripts et ces données sont conservés dans un journal des modifications de données correctement organisé.

Chaque entreprise est unique et les risques liés à la mise à jour de certaines données sont nettement plus importants que pour d'autres.

En ayant un processus qui oblige les gens à sauter à travers des cerceaux pour faire ces mises à jour, j'espère que vous promouvez une culture qui donne envie aux gens de traiter cela comme un dernier recours, et créez une attitude saine de "double vérification, triple vérification" autour de ce genre de choses.

Answer 5

Il arrive parfois que vous deviez corriger des données sur Prod qui n'existent pas sur d'autres serveurs.Cela ne vient pas seulement de bogues, mais peut provenir d'une importation de données à partir d'un fichier envoyé par un client qui était incorrect ou d'un problème causé par quelqu'un qui a piraté 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 urgente, vous n'aurez peut-être pas le temps de restaurer la dernière sauvegarde et le dernier correctif sur dev.

Votre première défense (et quelque chose dont aucune base de données d'entreprise ne peut se permettre !) 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 bons enregistrements à rétablir.

Ensuite, tous les scripts de modification des 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 test que vous pouvez utiliser pour annuler les modifications après avoir vu ce qu'elles auraient été.Vous devriez avoir une instruction select avant que la modification ne soit effectuée 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 cela pré-configuré 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 la rédaction du correctif.

S'il y a une grande quantité de données à modifier ou à mettre à jour, envisagez d'écrire le script pour qu'il s'exécute par lots avec des validations pour chaque lot.Vous ne voulez pas verrouiller tout le 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 dba ou quelqu'un qui a l'habitude de régler les performances examine le script avant de l'exécuter et de l'exécuter pendant les heures creuses si possible.

Ensuite, tous les scripts pour changer quoi que ce soit en production sont passés en revue et placés dans le 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, seules les personnes qui sont des responsables techniques ou plus devraient avoir le droit de gérer les choses sur la production.Moins il y a de personnes qui exécutent des choses en prod, plus il est facile de détecter un problème.Les scripts doivent être écrits de manière à être exécutés simplement, sans surligner les parties et en s'exécutant une étape à la fois.C'est la mise en surbrillance qui cause souvent des problèmes aux gens lorsqu'ils oublient de mettre en surbrillance la clause where.

Answer 6

J'ai mis à jour les données à plusieurs reprises lors de l'exécution de bases de données de production.Je suis d'accord avec la réponse ci-dessus, que ce ne serait jamais une procédure d'exploitation standard.

Cela coûterait aussi cher (on se regarderait par-dessus les épaules et on discuterait de 2 ou 3 peut-être)

Et la règle d'or : faites toujours une instruction select pour montrer ce qui serait fait avant de faire une instruction update/delete/insert

La règle d'or étant appliquée par les deux autres personnes de l'équipe !

Answer 7

re: la réponse de MainMa...

Il y a un bogue dans le produit logiciel qui l'empêche de fonctionner lorsqu'il détecte ce qu'il pense être une incohérence de données dans la base de données,

• Comment savez-vous que c'est un "bug" ?Les données sont incohérentes selon les règles établies par le développeur du produit logiciel.

Tous les développeurs susceptibles de corriger le bogue dans l'application sont injoignables,

L'entreprise perd actuellement des milliers de dollars par heure (disons 6 000 $, ce qui signifie 100 $ par minute),

• Apparemment, une perte de 100 $/minute n'est pas assez importante pour la direction de l'entreprise pour qu'elle localise et s'assure que des développeurs compétents reviennent pour réparer leur erreur et vous aider à restaurer la base de données.

Le bogue affecte plusieurs tables, dont l'une est énorme, et ne concerne que les données elles-mêmes, pas le schéma,

• Tous les problèmes de base de données "concernent" le schéma.La façon dont le schéma est conçu est ce qui va déterminer comment vous résolvez ce problème.

Afin de contourner le bogue, vous devez expérimenter un peu les données, ce qui implique à la fois de les supprimer et de les modifier,

• C'est à cela que sert votre base de données intermédiaire.Vous devrez peut-être le repeupler avec des données "corrompues" de la base de données de production juste après avoir effectué une sauvegarde en ligne complète de la production.

La base de données est volumineuse et il faudrait trois heures pour prendre ou restaurer la sauvegarde,

• Ensuite, vous feriez mieux de commencer tout de suite afin qu'il puisse s'exécuter pendant que vous analysez le problème, développez vos scripts de correction, les testez et les affinez avec les développeurs et les autres DBA qui vous aident.

La dernière sauvegarde complète a été effectuée il y a trois semaines ;il existe également des sauvegardes incrémentielles quotidiennes, et la dernière sauvegarde incrémentielle quotidienne a été effectuée il y a 14 heures,

• Vous n'avez pas au moins de sauvegardes en ligne complètes quotidiennes ?T'es foutu.Mais vous êtes probablement habitué à cela.Heureusement que la sauvegarde complète que vous avez commencée ci-dessus est en cours d'exécution.Assurez-vous que la direction traite chaque minute des coûts qui auraient pu être évités avec des sauvegardes en ligne quotidiennes.

Les sauvegardes de base de données sont supposées fiables ;ils ont été sévèrement testés, y compris récemment,

• Excellent!Dans ce cas, vous n'aurez peut-être pas à restaurer la base de données plus d'une fois.

La perte de 14 heures de données n'est pas acceptable, mais la perte d'une à deux heures de données l'est,

• Dans le scénario que vous avez décrit, tous les paris sont ouverts.Il s'agit d'une situation de "gestion des catastrophes de l'information".Une bonne chose pour la direction de faire tout au long de cela est de documenter les coûts qui pourraient être évités à l'avenir avec des procédures et des ressources de sauvegarde et de récupération appropriées.

L'environnement de mise en scène a été utilisé pour la dernière fois il y a six mois ;il semble qu'il ne soit pas à jour, et cela peut prendre des heures pour le configurer,

• Si votre système de sauvegarde prend en charge les sauvegardes en ligne (c'est-à-dire que la base de données est pleinement opérationnelle pendant la sauvegarde), vous pouvez effectuer l'extraction pour repeupler la base de données intermédiaire en même temps si vous disposez de ressources matérielles suffisantes pour éviter de ralentir la sauvegarde.

La base de données est Microsoft SQL Server 2008 Entreprise.

• Plus difficile de faire tout cela mais pas impossible.Bonne chance!