Как я могу минимизировать риск случайного изменения неправильной базы данных?

Я только что узнал, что отключение от сервера в обозревателе объектов не мешает вам впоследствии выполнять окна запросов, которые уже были открыты на этом сервере.

Моя ситуация такова: у меня есть один экземпляр SSMS, который я использую для подключения к нашему dev / staging server и нашему производственному серверу. Мне пришлось удалить кучу данных в dev, поэтому я решил закрыть свое соединение с производством, но я не обратил внимания на окно запроса, которое использовал. (К счастью, у нас была резервная копия всего несколько часов назад.)

Я не первый, кто уничтожает производственные данные, и я не буду последним, я уверен. Поэтому я ищу контрольные списки, лучшие практики и т. Д., Которые помогут вам минимизировать риск выполнения запросов в неправильной базе данных. Было ли это с вами раньше, и как вы адаптировали свой рабочий процесс, чтобы избежать этого?

Одна вещь, которую мне нравится делать в SSMS, это использовать пользовательские цвета при подключении к базе данных. Таким образом, вы выбираете красивый ярко-красный для баз данных Live и нежно-синий или зеленый для систем разработки или тестирования. Раньше я использовал встроенную SSMS, но сейчас я предпочитаю цветовую кодировку Addon Tools Addon.

Или как для SSMS Tools (действительно хороший аддон, и я нахожу цвет лучше, когда он сверху, а не снизу, как встроенный)

В зависимости от того, кого вы спрашиваете, это потребует немного больше работы, но у меня в привычку всегда использовать ниже заявление для всех производственных или предварительно производства окон запроса, а также для всех UPDATE, DELETEи INSERTзаявления во всех средах.

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

Если я увижу это, я сразу же узнаю: «К сожалению, это окно запроса все еще подключено» или «О, дерьмо, я автоматически сделал то, чего не должен был» - и да, вы можете закрыть базу данных в проводнике объектов, но окно запроса все еще может быть подключено. На мой взгляд, все производственные запросы должны быть выделены и выполнены с BEGIN TRAN; случайный F5 на все, должен откатить все назад, а не COMMIT. Это заставляет пользователя осознавать свои действия; Подобно тому, как сфотографировать каждую еду, которую вы едите, поможет вам похудеть, потому что вы должны остановиться и подумать о том, что вы делаете.

Это займет больше времени? Да. Останавливает ли это 100% ошибок. Да, потому что ничего не происходит, если только я вручную не форсирую COMMIT, пост, печатая его, что сама природа заставит меня рассмотреть COMMIT.

Создайте вторую учетную запись пользователя для производственных изменений и отмените доступ, который есть у вашей учетной записи. Когда вы захотите сделать что-то на производстве, вы можете запустить ssms как второй пользователь.

РЕДАКТИРОВАТЬ: Это будет полезно только в случае входа в домен. Если у вас есть две отдельные учетные записи домена, вы будете вынуждены иметь отдельные экземпляры SSMS для DEV и PROD. Если вы не используете учетные записи домена, это предложение не очень поможет вам.

Кроме того, если вы используете отдельные учетные записи домена, вы можете настроить параметры цвета SSMS для каждого пользователя, возможно, имея ярко-красный фон для учетной записи, которая подключается к PROD.

Вот хорошая белая книга, которая также пришла на ум: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Здесь обсуждаются такие вещи, как не предоставление вашей ежедневной учетной записи полного доступа к SA.

Взгляните на мою надстройку: SSMSBoost. Это именно то, что вам нужно. Я улучшил функцию окрашивания строки состояния SSMS, чтобы она отслеживала вашу текущую базу данных и меняла ее цвет. Кроме того, вы можете добавить всплывающую подсказку «Важное предупреждение БД»:

Подробнее об этой функции читайте здесь: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

На одной из моих работ мы разработали инструмент для этой цели.

Если вы хотите запустить оператор в PROD, он заставит вас написать:

run_sql servername PROD <file_with_sqlstatements>.sql

Он записывает результаты в файл журнала и добавляет выполнение в журнал в нашей базе данных управления. Это очень пригодилось, например, когда мы хотели выяснить, кто был последним, кто изменил определенную таблицу.

В SSMS, когда у вас есть зарегистрированные серверы, вы можете применить определенный цвет к соединению, чтобы, например, все PROD-соединения имели красный цвет внизу. Но лучше по возможности избегать использования GUI-инструментов на рабочем сервере.

Еще два совета, поскольку я уже не вижу ничего подобного здесь:

1. В моем рабочем процессе я часто работаю с несколькими операторами в одном окне, и я довольно привык выбирать поток текста, а затем запустить. Но я всегда боюсь случайно нажать клавишу F5, когда текст не выделен, и в результате выполнить все операторы в окне. Таким образом, каждый раз, когда я открываю новое окно, я начинаю с того, что набираю мусор, который SQL откажет от компиляции. Это фактически делает всю партию неисполнимой. (Предупреждение! Если вы используете несколько пакетов, разделенных GOсимволом «мусор», то для каждой партии требуется мусор.)

2. При выполнении изменений данных на производственном сервере (или всякий раз, когда мне требуется крайняя осторожность) - неявные транзакции очень полезны (вы либо SET IMPLICIT_TRANSACTIONS ONизменяете параметр в SSMS, чтобы этот параметр действовал для каждого нового окна). Таким образом, каждая инструкция, которой нет в транзакции, запускает новую транзакцию. Я только обязуюсь, если я дважды удостоверился, что сделал то, что намеревался.

Попробуйте использовать отдельного пользователя Windows, который является единственным , у которого настроена производственная база данных. Установите всю цветовую тему этого пользователя на красный. С быстрым переключением пользователей это не должно быть проблемой.

Никогда не используйте производственные учетные данные в учетной записи, которая находится на компьютере разработчика. Короткий телефонный звонок или вопрос сотрудника, и после этого вы счастливо удаляете все для своего нового теста ...

Другой вариант (та же идея) - использовать удаленный рабочий стол или виртуальную машину с другой темой.

Другим довольно простым способом предотвращения выполнения всего в окне запроса при нажатии клавиши F5 было бы окружение всего содержимого символами / * и * /, таким образом, делая все это комментарием.

Вы все еще можете выполнить нужные операторы, выделив их и нажав F5 обычным способом, даже если они включены в комментарий.

Примечание: если вы выберете этот метод, вы не сможете извлечь выгоду из подсветки синтаксиса или автозаполнения, но если вы не используете эти функции слишком много, то может быть целесообразно пожертвовать ими, чтобы гарантировать, что это на 100% невозможно повредить База данных со случайным F5.

Изменить: вы также не сможете использовать / * * / в любом месте окна запроса, в противном случае вы непреднамеренно раскомментируете последующий код. Нужно придерживаться обозначения - вместо этого.

В согласии с комментарием swasheck по первоначальному вопросу, как насчет выполнения ...

выберите @@ имя_сервера + '\' + @@ servicename

... перед запуском любого DML, или даже глядя на строку состояния, чтобы увидеть, к какому экземпляру вы подключены, или даже запустив весь DML в транзакции, чтобы вы могли откатиться, если обнаружите, что допустили ошибку? Здесь много хороших предложений, но в основном, когда дело доходит до потенциально разрушительного DML, уловки только дойдут до вас. Я всегда проверяю, перепроверяю и проверяю снова. И если я имею дело с небольшим количеством данных, я мог бы даже ВЫБРАТЬ ВНУТРИ новую таблицу до DML, запустить мой DML, сделать некоторые сравнения, чтобы убедиться, что все работает правильно, а затем отбросить «резервную» таблицу. Работай умом, а не силой.