Як я можу мінімізувати ризик випадкового зміни неправильної бази даних?

Щойно я навчився важкому шляху того, що відключення від сервера в Провіднику об’єктів не зупиняє вас згодом від виконання вікон запитів, які вже були відкриті на цьому сервері.

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

Я не перша людина, яка знищила дані про виробництво, і я не буду останньою, в чому впевнена. Тому я шукаю контрольні списки, кращі практики тощо, які допоможуть вам мінімізувати ризик виконання запитів у неправильній базі даних. Чи траплялось вам раніше, і як ви адаптували свій робочий процес, щоб спробувати цього уникнути?

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

Або як це для інструментів SSMS (дійсно приємний додаток, і я вважаю, що колір краще, коли він знаходиться зверху, а не знизу, як вбудований)

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

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

Якщо я це побачу, я одразу знаю: "На жаль, це вікно запитів все-таки було підключено" або "О, дерьмо, я автоматично зробив щось, чого не мав" - і так, ви можете закрити базу даних в "Провіднику об'єктів", але Вікно запиту все ще може бути підключено. На мій погляд, усі виробничі запити слід висвітлювати і виконувати з ними BEGIN TRAN; випадковий F5 у всьому, повинен відкотити все назад, а не COMMIT. Це робить змушувати користувача усвідомлювати свої дії; подібно до фотографування кожної їжі, яку ви їсте, допоможе схуднути, тому що ви повинні зупинитися і подумати, що ви робите.

Це займе більше часу? Так. Чи зупиняє це 100% помилок. Так, тому що нічого ніколи не вчиняється, якщо я не вручну примушувати цю COMMITпосаду, друкуючи її, що сама природа волі змусила мене розглянути COMMIT.

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

EDIT: Це було б корисно лише у випадку входу в домен. Якщо у вас було два окремі облікові записи домену, ви змушені мати окремі екземпляри 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

У ньому обговорюються такі речі, як ненадання повного доступу до вашої облікової записи щоденного входу.

Подивіться на мою надбудову: 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, який єдиний з налаштованою виробничою базою даних. Встановіть всю кольорову тему цього користувача на червону. При швидкій комутації користувача це не повинно бути проблемою.

Ніколи не використовуйте виробничі дані в обліковому записі, який знаходиться на машині розробки. Коротке запитання щодо телефонного дзвінка або колеги, і після цього ви радісно видаляєте все для вашого нового інструменту ...

Інший варіант (та сама ідея) - використання віддаленого робочого столу або машини virtul з іншою темою.

Ще одним досить простим способом запобігання виконанню всього, що знаходиться у вікні запиту при натисканні на F5, буде оточення всього вмісту за допомогою / * та * /, таким чином, роблячи все це коментарем.

Ви все ще можете виконати потрібні твердження, виділивши їх і натиснувши F5 звичайним способом, навіть якщо вони укладені в коментарі.

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

Редагувати: ви також не зможете використовувати / * * / де-небудь у вікні запиту, інакше ви ненавмисно відмежуєте наступний код. Потрібно дотримуватися позначення - замість цього.

Відповідно до коментаря swasheck на первісне питання, як щодо виконання ...

виберіть @@ ім'я сервера + '\' + @@ ім'я служби

... перед тим, як запустити будь-який DML або навіть переглядати рядок стану, щоб побачити, до якого екземпляра ви підключені, або навіть запустити весь DML в транзакції, щоб ви могли відкатати, якщо зрозуміли, що помилилися? Тут багато чудових пропозицій, але в основному, якщо мова йде про потенційно руйнівний DML, трюки отримають вас лише поки що. Я завжди перевіряю, двічі перевіряю і ще раз перевіряю. І якщо я маю справу з невеликою кількістю даних, я можу навіть ВИБІРТИ ДО нової таблиці перед DML, запустити мій DML, зробити порівняння, щоб переконатися, що все працювало правильно, а потім відкиньте таблицю "резервного копіювання". Працюйте розумніше, не важче.