Jak mogę zminimalizować ryzyko przypadkowej modyfikacji niewłaściwej bazy danych?

Właśnie dowiedziałem się na własnej skórze, że rozłączenie się z serwerem w Eksploratorze obiektów nie powstrzymuje cię później przed uruchomieniem okien zapytań, które były już otwarte na tym serwerze.

Moja sytuacja wygląda następująco: mam jedno wystąpienie SSMS, którego używam do łączenia się z naszym serwerem deweloperskim / pomostowym i serwerem produkcyjnym. Musiałem usunąć wiele danych z dev, więc pomyślałem, że powinienem zamknąć połączenie z produkcją, ale nie zwróciłem uwagi na okno zapytań, którego używałem. (Na szczęście mieliśmy kopię zapasową sprzed zaledwie kilku godzin.)

Nie jestem pierwszą osobą, która niszczy dane produkcyjne i nie będę ostatnią, jestem tego pewien. Szukam więc list kontrolnych, najlepszych praktyk itp., Które pomogą zminimalizować ryzyko wykonywania zapytań w niewłaściwej bazie danych. Czy zdarzyło Ci się to wcześniej i jak dostosowałeś przepływ pracy, aby tego uniknąć?

Jedną z rzeczy, które lubię robić w SSMS, jest używanie kolorów niestandardowych podczas łączenia się z bazą danych. Więc wybierasz ładną, jasnoczerwoną bazę danych Live i delikatną niebieską lub zieloną dla systemów deweloperskich lub testowych. Kiedyś korzystałem z wbudowanego SSMS, ale obecnie wolę kodowanie kolorami narzędzi SSMS Addon.

Lub tak jak w przypadku Narzędzi SSMS (Naprawdę fajny dodatek, i znajduję kolor lepiej, gdy jest na górze, niż na dole, jak wbudowany)

W zależności od tego, kogo zapytasz, będzie to wymagało trochę więcej pracy, ale mam w zwyczaju zawsze używając poniżej zestawienia dla wszystkich okien zapytań produkcyjnych lub pre-produkcji, a dla wszystkich UPDATE, DELETEi INSERToświadczenia we wszystkich środowiskach.

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

Jeśli to zobaczę, od razu będę wiedział: „Ups, okno kwerendy było nadal podłączone” lub „O cholera, automatycznie zrobiłem coś, czego nie powinienem” - i tak, możesz zamknąć bazę danych w eksploratorze obiektów, ale okno zapytania może być nadal połączone. Moim zdaniem wszystkie zapytania produkcyjne powinny być wyróżnione i uruchomione BEGIN TRAN; przypadkowy F5 na wszystkim, powinien wszystko przewrócić, a nie COMMIT. To powoduje, że użytkownik musi być świadomy swoich działań; podobnie jak robienie zdjęć każdemu jedzonemu posiłkowi pomoże ci schudnąć, ponieważ musisz przestać myśleć o tym, co robisz.

Czy to trwa dłużej? Tak. Czy zatrzymuje 100% błędów. Tak, ponieważ nic się nigdy nie popełnia, chyba że ręcznie wymuszę COMMITwpis, wpisując go, co sama natura zmusi mnie do rozważenia COMMIT.

Utwórz drugie konto użytkownika dla zmian produkcyjnych i odwołaj dostęp, który aktualnie ma twoje konto. Jeśli chcesz robić rzeczy w produkcji, możesz uruchomić ssms jako drugi użytkownik.

EDYCJA: Byłoby to korzystne tylko w przypadku logowania do domeny. Jeśli masz dwa oddzielne konta domeny, będziesz zmuszony mieć osobne instancje SSMS dla DEV i PROD. Jeśli nie korzystasz z kont domeny, ta sugestia nie bardzo by Ci pomogła.

Ponadto, jeśli korzystasz z oddzielnych kont domeny, możesz dostosować ustawienia kolorów SSMS dla każdego użytkownika, być może mając jasne czerwone tło dla konta, które łączy się z PROD.

Oto dobra biała księga, która przyszła mi do głowy: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Omówiono takie rzeczy, jak nieprzyznawanie codziennego konta logowania pełnego dostępu SA.

Zobacz mój dodatek: SSMSBoost. Ma dokładnie to, czego potrzebujesz. Ulepszyłem funkcję kolorowania paska stanu SSMS, dzięki czemu śledzi twoją bieżącą bazę danych i zmienia jej kolor. Dodatkowo możesz dodać pływającą etykietkę „ważny alert DB”:

Przeczytaj więcej o tej funkcji tutaj: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

W jednym z moich zadań opracowaliśmy narzędzie do tego celu.

Jeśli chcesz uruchomić instrukcję na PROD, zmusza cię to do napisania:

run_sql servername PROD <file_with_sqlstatements>.sql

Zapisuje wyniki w pliku dziennika i dołącza wykonanie do dziennika w naszej bazie danych zarządzania. Przydało się to na przykład, gdy chcieliśmy dowiedzieć się, kto był ostatnią osobą, która zmieniła określony stół.

W SSMS, gdy masz zarejestrowane serwery, możesz zastosować określony kolor do połączenia, aby na przykład wszystkie połączenia PROD miały kolor czerwony u dołu. Ale najlepiej, jeśli to możliwe, unikać używania narzędzi GUI na serwerze produkcyjnym.

Jeszcze dwie wskazówki, ponieważ nie widzę tu już nic podobnego:

1. W moim przepływie pracy często pracuję z wieloma instrukcjami w jednym oknie i jestem dość przyzwyczajony do wybierania tekstu i uruchamiania. Ale zawsze boję się przypadkowego naciśnięcia klawisza F5, gdy żaden tekst nie jest zaznaczony, i w rezultacie wykonuję wszystkie instrukcje w oknie. Tak więc za każdym razem, gdy otwieram nowe okno, zaczynam od wpisywania śmieciowego SQL, który odmówi kompilacji. To skutecznie powoduje, że cała partia nie jest wykonywalna. (Uwaga! Jeśli używasz wielu partii oddzielonych, GOśmieci są wymagane na partię).

2. Podczas dokonywania zmian danych na serwerze produkcyjnym (lub za każdym razem, gdy potrzebuję szczególnej uwagi) - transakcje niejawne są bardzo przydatne (albo SET IMPLICIT_TRANSACTIONS ONzmieniasz opcję w SSMS, aby opcja była skuteczna dla każdego nowego okna). W ten sposób każde wyciągi, które nie są w transakcji - rozpoczynają nową transakcję. Popełniam tylko, jeśli dwa razy upewnię się, że zrobiłem to, co zamierzałem.

Spróbuj użyć oddzielnego użytkownika systemu Windows, który jako jedyny ma skonfigurowaną produkcyjną bazę danych. Ustaw cały motyw kolorystyczny tego użytkownika na czerwony. Przy szybkiej zmianie użytkownika nie powinno to stanowić problemu.

Nigdy nie używaj poświadczeń produkcyjnych na koncie na komputerze programistycznym. Krótkie pytanie telefoniczne lub pytanie do współpracownika, a następnie z radością usuwasz wszystko dla nowego testu ...

Inną opcją (ten sam pomysł) jest użycie zdalnego pulpitu lub maszyny virtul z innym motywem.

Innym dość prostym sposobem zapobiegania wykonywaniu wszystkiego w oknie zapytania po naciśnięciu F5 byłoby otoczenie całej zawartości / * i * /, czyniąc z tego komentarz.

Nadal możesz wykonać żądane instrukcje, podświetlając je i naciskając F5 w zwykły sposób, nawet jeśli są one zawarte w komentarzu.

Uwaga: jeśli wybierzesz tę metodę, nie będziesz mógł skorzystać z podświetlania składni lub autouzupełniania, ale jeśli nie użyjesz tych funkcji aż tak bardzo, warto poświęcić je, aby upewnić się, że uszkodzenie jest w 100% niemożliwe baza danych z przypadkowym klawiszem F5.

Edycja: nie będziesz mógł używać / * * / nigdzie w oknie zapytania, w przeciwnym razie nieumyślnie odkomentujesz kolejny kod. Zamiast tego należy trzymać się notacji.

W zgodzie z komentarzem swasheck do pierwotnego pytania, co powiesz na wykonanie ...

wybierz @@ nazwa serwera + '\' + @@ nazwa usługi

... przed uruchomieniem dowolnego DML, a nawet spojrzeniem na pasek stanu, aby zobaczyć, z którą instancją jesteś połączony, a nawet uruchomieniem całego DML w transakcji, abyś mógł cofnąć, jeśli zauważysz, że popełniłeś błąd? Wiele świetnych sugestii tutaj, ale w zasadzie, jeśli chodzi o potencjalnie destrukcyjny DML, sztuczki doprowadzą cię tylko do tej pory. Zawsze sprawdzam, sprawdzam dwukrotnie i sprawdzam ponownie. A jeśli mam do czynienia z niewielką ilością danych, mogę nawet WYBRAĆ nową tabelę przed DML, uruchomić mój DML, dokonać porównań, aby upewnić się, że wszystko działa poprawnie, a następnie upuścić tabelę „kopii zapasowej”. Pracuj mądrzej, nie ciężej.