Jak wspomniano Nick i Martin, ostateczny stan twojego zapytania zależy od tego, czy SQL Server wie o wyciągnięciu kabla sieciowego przed zakończeniem zapytania. Z Books Online (choć uważam za interesujące, że istnieją równoważne tematy w 2000 , 2005 , 2008 i 2008 R2 , ale nie 2012 lub 2014):
Jeśli błąd uniemożliwia pomyślne zakończenie transakcji, SQL Server automatycznie wycofuje transakcję i zwalnia wszystkie zasoby posiadane przez transakcję. Jeśli połączenie sieciowe klienta z wystąpieniem aparatu bazy danych zostanie zerwane, wszelkie zaległe transakcje dla połączenia zostaną wycofane, gdy sieć powiadomi o wystąpieniu przerwy. Jeśli aplikacja kliencka ulegnie awarii lub komputer kliencki ulegnie awarii lub zostanie zrestartowany, spowoduje to również przerwanie połączenia, a wystąpienie aparatu bazy danych cofa wszelkie zaległe połączenia, gdy sieć powiadomi go o przerwaniu. Jeśli klient wyloguje się z aplikacji, wszelkie zaległe transakcje zostaną wycofane.
(Nawiasem mówiąc, to słowo połączenia w drugim ostatnim zdaniu prawdopodobnie miało być transakcją . Nie wiem, jak się wycofuje połączenie).
W podobny sposób SQL Server może cofać lub ponawiać transakcje podczas odzyskiwania po nieoczekiwanym zamknięciu serwera, co będzie zależeć od stanu transakcji w momencie zamknięcia. Widziałem, jak ludzie używają tej taktyki, aby osiągnąć to, co próbowaliście zrobić (anulować transakcję), a kiedy serwer uruchomił się ponownie, znaczna część pracy została po prostu przerobiona (więc efekt netto ich gwałtownej reakcji był znacznie bliższy do zera niż się spodziewali).
Zamiast więc poddawać się temu, zamiast robić drastyczne rzeczy w panice, jak szarpanie kabla sieciowego lub wyłączanie maszyny, sugeruję w przyszłości lepszą dyscyplinę w uruchamianiu zapytań ad hoc względem ważnych systemów. Na przykład zamiast:
UPDATE dbo.sometable
-- where *oops* I forgot this part
Masz to:
BEGIN TRANSACTION;
UPDATE dbo.sometable
-- where *oops* I forgot this part
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;
Następnie, jeśli aktualizacja rzeczywiście była poprawna, możesz podświetlić tę COMMIT
część i uruchomić ją. Jeśli nie, możesz spokojnie zaznaczyć tę ROLLBACK
część i uruchomić ją. Możesz nawet użyć dodatków, takich jak SSMS Tools Pack, aby edytować New Query
szablon, aby uwzględnić ten szablon.
Teraz nadal może sprawiać kłopoty w przypadku uruchomienia zapytania, a następnie nie zatwierdzenia ani wycofania, ponieważ teraz transakcja blokuje innych użytkowników. Jest to jednak lepsze niż nieodwracalne modyfikowanie danych.
I oczywiście, jak zawsze, masz kopię zapasową, na której możesz polegać.