Comment puis-je minimiser le risque de modification accidentelle d'une mauvaise base de données?

Je viens d'apprendre à la dure que la déconnexion d'un serveur dans l'Explorateur d'objets ne vous empêche pas par la suite d'exécuter des fenêtres de requête déjà ouvertes sur ce serveur.

Ma situation est la suivante: j'ai une instance de SSMS que j'utilise pour me connecter à notre serveur de développement / transfert et à notre serveur de production. J'ai dû supprimer un tas de données sur le développement, alors j'ai pensé que je devrais fermer ma connexion à la production, mais je n'ai pas fait attention à la fenêtre de requête que j'utilisais. (Heureusement, nous avions une sauvegarde de seulement quelques heures.)

Je ne suis pas la première personne à détruire les données de production et je ne serai pas la dernière, j'en suis sûr. Je recherche donc des listes de contrôle, des meilleures pratiques, etc. qui vous aident à minimiser le risque d'exécuter des requêtes sur la mauvaise base de données. Avez-vous déjà ressenti cela, et comment avez-vous adapté votre flux de travail pour essayer d'éviter cela?

Une chose que j'aime faire dans SSMS est d'utiliser des couleurs personnalisées lors de la connexion à la base de données. Vous choisissez donc un joli rouge vif pour les bases de données Live et un bleu ou vert doux pour les systèmes de développement ou de test. J'utilisais le SSMS intégré, mais ces jours-ci, je préfère le codage couleur de l'addon SSMS Tools.

Ou comme ça pour les outils SSMS (Un addon vraiment sympa, et je trouve la couleur meilleure quand elle est en haut, plutôt qu'en bas comme celle intégrée)

Selon qui vous demandez, cela demandera un peu plus de travail, mais j'ai l'habitude de toujours utiliser l'instruction ci-dessous pour toutes les fenêtres de requête de production ou de pré-production, et pour toutes UPDATE, DELETEet les INSERTinstructions dans tous les environnements.

BEGIN TRAN
-- END OF QUERY WINDOWS
ROLLBACK TRAN
PRINT 'Transaction rolled back.'

Si je vois cela, je saurai immédiatement "Oups, cette fenêtre de requête était toujours connectée" ou "Oh merde, j'ai fait quelque chose que je n'aurais pas dû" - et oui, vous pouvez fermer la base de données dans l'explorateur d'objets, mais un la fenêtre de requête peut toujours être connectée. Dans mon esprit, toutes les requêtes de production doivent être mises en évidence et exécutées avec BEGIN TRAN; un F5 accidentel sur tout, devrait tout faire reculer, non COMMIT. Ce que cela fait, c'est obliger l'utilisateur à être conscient de ses actions; similaire à prendre une photo de chaque repas que vous mangez vous aidera à perdre du poids car vous devez vous arrêter et réfléchir à ce que vous faites.

Est-ce que cela prend plus de temps? Oui. Arrête-t-il 100% des erreurs. Oui, car rien ne s’engage jamais, à moins que je ne force manuellement le COMMIT, en le tapant, ce que la nature même de l’obligera à considérer COMMIT.

Créez un deuxième compte utilisateur pour les modifications de production et révoquez l'accès dont votre compte dispose actuellement. Lorsque vous souhaitez effectuer des tâches en production, vous pouvez exécuter ssms en tant que deuxième utilisateur.

EDIT: Cela ne serait bénéfique que dans le cas des connexions de domaine. Si vous aviez deux comptes de domaine distincts, vous seriez obligé d'avoir des instances distinctes de SSMS pour DEV et PROD. Si vous n'utilisez pas de comptes de domaine, cette suggestion ne vous sera pas vraiment utile.

De plus, si vous utilisez des comptes de domaine distincts, vous pouvez ajuster vos paramètres de couleur SSMS par utilisateur, peut-être avec un arrière-plan rouge vif pour le compte qui se connecte à PROD.

Voici un bon livre blanc qui m'est également venu à l'esprit: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Il traite de choses comme ne pas donner à votre compte de connexion quotidien un accès SA complet.

Jetez un œil à mon complément: SSMSBoost. Il a exactement ce dont vous avez besoin. J'ai amélioré la fonction de coloration de la barre d'état SSMS pour qu'il suive votre base de données actuelle et change sa couleur. De plus, vous pouvez ajouter une info-bulle flottante "alerte DB importante":

En savoir plus sur cette fonctionnalité ici: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

Dans l'un de mes emplois, nous avons développé un outil à cet effet.

Si vous vouliez exécuter une instruction sur PROD, cela vous obligeait à écrire:

run_sql servername PROD <file_with_sqlstatements>.sql

Il écrirait les résultats dans un fichier journal et ajouterait l'exécution dans un journal de notre base de données de gestion. C'était très pratique, par exemple, lorsque nous voulions savoir qui était la dernière personne à changer une certaine table.

Dans SSMS, lorsque vous avez des serveurs enregistrés, vous pouvez appliquer une certaine couleur à une connexion, de sorte que, par exemple, toutes les connexions PROD ont une couleur rouge en bas. Mais il vaut mieux éviter d'utiliser des outils GUI sur un serveur de production si possible.

Juste deux autres conseils, car je ne vois rien de similaire ici déjà:

1. Dans mon flux de travail, je travaille souvent avec plusieurs instructions dans une seule fenêtre, et je suis assez habitué à sélectionner un texte, puis à exécuter un flux. Mais j'ai toujours peur d'appuyer accidentellement sur F5 quand aucun texte n'est sélectionné et d'exécuter toutes les instructions dans une fenêtre en conséquence. Donc, chaque fois que j'ouvre une nouvelle fenêtre, je commence par taper ce que SQL ordonné refusera de compiler. Cela rend effectivement le lot entier non exécutable. (Attention! Si vous utilisez plusieurs lots séparés par, des GOordures sont requises par lot.)

2. Lorsque vous effectuez des modifications de données sur le serveur de production (ou chaque fois que j'ai besoin d'une attention extrême) - les transactions implicites sont très utiles (vous pouvez SET IMPLICIT_TRANSACTIONS ONou modifier une option dans SSMS pour que l'option soit effective pour chaque nouvelle fenêtre). De cette façon, chaque instruction qui n'est pas en transaction - démarre une nouvelle transaction. Je ne m'engage que si je m'assure deux fois d'avoir fait ce que j'avais l'intention de faire.

Essayez d'utiliser un utilisateur Windows séparé, qui est le seul à avoir configuré la base de données de production. Définissez le thème de couleur entier de cet utilisateur sur le rouge. Avec un changement rapide d'utilisateur, cela ne devrait poser aucun problème.

N'utilisez jamais les informations d'identification de production dans un compte qui se trouve sur une machine de développement. Un court appel téléphonique ou une question de collègue et ensuite vous supprimez tout avec plaisir pour votre nouveau test ...

Une autre option (même idée) consiste à utiliser un bureau à distance ou une machine virtul avec un thème différent.

Une autre façon assez simple d'empêcher l'exécution de tout dans la fenêtre de requête lorsque vous appuyez sur F5 serait d'entourer tout le contenu avec / * et * /, faisant ainsi de l'ensemble un commentaire.

Vous pouvez toujours exécuter les instructions souhaitées en les mettant en surbrillance et en appuyant sur F5 de la manière habituelle, même si elles sont incluses dans un commentaire.

Remarque: si vous choisissez cette méthode, vous ne pourrez pas bénéficier de la coloration syntaxique ou de la saisie semi-automatique, mais si vous n'utilisez pas beaucoup ces fonctionnalités, il pourrait être utile de les sacrifier pour vous assurer qu'il est impossible à 100% d'endommager la base de données avec un F5 accidentel.

Modifier: vous ne pourrez pas non plus utiliser / * * / n'importe où dans la fenêtre de requête, sinon vous décommenterez par inadvertance le code suivant. Besoin de s'en tenir à la notation - à la place.

En accord avec le commentaire de swasheck sur la question d'origine, que diriez-vous d'exécuter ...

sélectionnez @@ nomserveur + '\' + @@ nomservice

... avant d'exécuter un DML, ou même de regarder la barre d'état pour voir à quelle instance vous êtes connecté, ou même d'exécuter tous les DML dans une transaction afin de pouvoir revenir en arrière si vous réalisez que vous avez fait une erreur? Beaucoup de bonnes suggestions ici, mais fondamentalement, en ce qui concerne le DML potentiellement destructeur, les gadgets ne vous permettront que de faire jusqu'ici. Je vérifie, vérifie et revérifie toujours. Et si j'ai affaire à une petite quantité de données, je pourrais même sélectionner SELECT INTO une nouvelle table avant le DML, exécuter mon DML, faire des comparaisons pour m'assurer que les choses fonctionnent correctement, puis supprimer le tableau de "sauvegarde". Travaillez plus intelligemment, pas plus dur.