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

12

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?

Stijn
la source
4
faites attention à ce que vous faites.
swasheck
Mon outil SQL (pas SSMS) me permet d'activer un "mode lecture seule" qui rejette simplement toute instruction qui pourrait potentiellement changer la base de données.
a_horse_with_no_name
Dormez suffisamment et faites de l'exercice, faites plus attention.

Réponses:

11

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.

Comme ça

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) Ou ca

Mikey Mouse
la source
2
+1 C'est ce que je fais. Utilisez le rouge pour la production, le jaune pour les environnements de test et le vert pour ma base de données de développement local. La vieille métaphore des feux de circulation fonctionne bien ici.
LeopardSkinPillBoxHat
6

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.

Question3CPO
la source
4
Je prêche également à propos de cette pratique (et c'est une autre fonctionnalité du pack d'outils SSMS - vous permettant de personnaliser le modèle de nouvelle requête), mais vous devez faire attention au scénario opposé - vous mettez en surbrillance BEGIN TRAN et la requête, mais oubliez d'exécuter le ENGAGEZ-VOUS ou ROLLBACK, puis sifflez en quittant le bâtiment pour le déjeuner, le week-end ou un congé sabbatique de 6 mois.
Aaron Bertrand
6

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.

Mark Wilkinson
la source
Vous voulez dire que cela désactiverait en quelque sorte l'accès à plusieurs serveurs à partir d'une seule instance SSMS? Ou qu'est-ce que j'ai raté?
Andriy M
Nous utilisons déjà différents comptes d'utilisateurs, je ne vois pas vraiment comment cela aide.
Stijn
1
Je suppose que cela ne s'appliquerait vraiment que si vous utilisiez des comptes de domaine. Si tel était le cas ou vous obligerait à utiliser une instance distincte si SSMS pour vos connexions DEV et PROD. Peut-être que je vais écrire un complément SSMS qui aide à ce scénario, peut-être faire apparaître un avertissement chaque fois que vous essayez d'exécuter du code sur votre connexion de production ...
Mark Wilkinson
Oof, désolé pour toutes les fautes de frappe dans le commentaire. Réponse tôt le matin par téléphone portable ... mais vous avez l'idée. :)
Mark Wilkinson
Oui, j'ai compris l'essentiel de votre réponse :) Peut-être pouvez-vous intégrer votre commentaire dans votre réponse?
Stijn
4

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":

entrez la description de l'image ici

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

Andrei Rantsevich
la source
2

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.

Scintille
la source
J'utilise SSMS sur ma machine uniquement, un excellent conseil sur la couleur de la chaîne de connexion.
Stijn
3
@Stijn note que la fonction de couleur intégrée ne fonctionne pas dans tous les scénarios - dépend de la façon dont vous ouvrez la fenêtre de requête. SSMS Tools Pack est un outil beaucoup plus fiable (mais pas gratuit sur SSMS 2012+) . Mladen vient de sortir une version compatible 2014.
Aaron Bertrand
@Aaron l'outil a l'air très intéressant, je vais jeter un œil à la version d'essai, merci!
Stijn
4
Une autre solution de coloration alternative est dans SQL Prompt qui, bien que non gratuit, est un kit assez astucieux. Cela colore les onglets en haut, plutôt que juste en bas, ce que fait SSMS.
Mark Sinkinson
1

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.

Kuba Wyrostek
la source
0

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.

awsm
la source
0

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.

ps.pf
la source
-1

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.

John Chase
la source