Як згадували Нік та Мартін, можливий стан вашого запиту залежить від того, чи знає SQL Server про підключення мережевого кабелю до завершення запиту. З книг Інтернет (хоча мені здається цікавим, що для цього є рівнозначні теми у 2000 , 2005 , 2008 та 2008 рр. , Але не 2012 чи 2014 рр.):
Якщо помилка перешкоджає успішному завершенню транзакції, SQL Server автоматично відкочує транзакцію та звільняє всі ресурси, що містяться в транзакції. Якщо мережеве підключення клієнта до екземпляра двигуна бази даних порушено, будь-які невирішені транзакції для з'єднання будуть відмовлені, коли мережа повідомляє про примірник розриву. Якщо клієнтська програма виходить з ладу або якщо клієнтський комп'ютер виходить з ладу або перезапускається, це також розриває з'єднання, і екземпляр Двигуна баз даних скасовує будь-які непогашені з'єднання, коли мережа повідомляє його про перерву. Якщо клієнт виходить із програми, будь-які непогашені транзакції повертаються назад.
(До речі, що слово з'єднання в 2 - м останньому реченні, ймовірно , мав в виду, що операції . Я не знаю , як один відкочується з'єднання.)
Аналогічним чином SQL Server може скасувати або повторити транзакції під час відновлення після несподіваного вимкнення сервера, і це залежатиме від стану транзакції в момент відключення. Я бачив, як люди використовують цю тактику, щоб досягти того, що ви намагалися зробити (скасувати транзакцію), і коли сервер запустився знову, значна частина роботи була просто перероблена (тому чистий ефект від їхньої реакції на коліна був набагато ближчим до нуля, ніж вони очікували).
Тож замість того, щоб піддаватися цьому, замість того, щоб робити серйозні речі в паніці, як, наприклад, потріскувати мережевий кабель чи вимикати машину, я пропоную вам у майбутньому вдосконалити дисципліну щодо запуску спеціальних запитів щодо важливих систем. Наприклад, замість:
UPDATE dbo.sometable
-- where *oops* I forgot this part
Майте це:
BEGIN TRANSACTION;
UPDATE dbo.sometable
-- where *oops* I forgot this part
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;
Потім, якщо оновлення було дійсно правильним, ви можете виділити його COMMITчастину та запустити її. Якщо це не так, ви можете спокійно виділити ROLLBACKдеталь і запустити її. Ви навіть можете використовувати надбудови, такі як пакет SSMS Tools, щоб редагувати ваш New Queryшаблон, щоб включити цю коробку.
Тепер це все ще може зашкодити вам у випадку, якщо ви запустите запит, а потім не виконуватимете жодних зобов'язань або відкату, оскільки тепер ваша транзакція блокує інших користувачів. Але це краще, ніж безповоротно змінювати дані.
І звичайно, як завжди, є резервна копія, на яку можна покластися.
