Comme mentionné par Nick et Martin, le statut final de votre requête dépend de si SQL Server est au courant de votre tirage de câble réseau avant la fin de la requête. De Books Online (bien que je trouve intéressant qu'il y ait des sujets équivalents pour cela en 2000 , 2005 , 2008 et 2008 R2 , mais pas 2012 ou 2014):
Si une erreur empêche la réussite d'une transaction, SQL Server annule automatiquement la transaction et libère toutes les ressources détenues par la transaction. Si la connexion réseau du client à une instance du moteur de base de données est rompue, toutes les transactions en suspens pour la connexion sont annulées lorsque le réseau notifie l'instance de la rupture. Si l'application cliente échoue ou si l'ordinateur client tombe en panne ou est redémarré, cela interrompt également la connexion et l'instance du moteur de base de données annule toutes les connexions en attente lorsque le réseau l'informe de la rupture. Si le client ferme la session sur l'application, toutes les transactions en suspens sont annulées.
(En passant, ce mot connexions dans l'avant-dernière phrase était probablement censé être des transactions . Je ne sais pas comment on annule une connexion.)
De la même manière, SQL Server peut annuler ou rétablir les transactions pendant la récupération après l'arrêt inattendu du serveur, et cela dépendra de l'état de la transaction au moment de l'arrêt. J'ai vu des gens utiliser cette tactique pour réaliser ce que vous tentiez de faire (annuler la (les) transaction (s)) et lorsque le serveur a redémarré une grande partie du travail a simplement été refaite (donc l'effet net de leur réaction de genou était beaucoup plus proche). à zéro que prévu).
Donc, plutôt que d'être soumis à cela, au lieu de faire des choses drastiques dans la panique, comme tirer un câble réseau ou éteindre la machine, je suggère à l'avenir que vous ayez une meilleure discipline pour exécuter des requêtes ad hoc sur des systèmes importants. Par exemple, au lieu de:
UPDATE dbo.sometable
-- where *oops* I forgot this part
Avoir ceci:
BEGIN TRANSACTION;
UPDATE dbo.sometable
-- where *oops* I forgot this part
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;
Ensuite, si la mise à jour était en effet correcte, vous pouvez mettre en surbrillance la COMMITpièce et l'exécuter. Si ce n'est pas le cas, vous pouvez calmement mettre en évidence la ROLLBACKpièce et l'exécuter. Vous pouvez même utiliser des compléments tels que SSMS Tools Pack pour modifier votre New Querymodèle afin d'inclure ce passe-partout.
Maintenant, il pourrait toujours vous poser des problèmes dans le cas où vous exécutez la requête et que vous ne validiez ni ne rétrogradiez, car maintenant votre transaction bloque d'autres utilisateurs. Mais cela vaut mieux que de modifier irrévocablement les données.
Et bien sûr, comme toujours, disposez d'une sauvegarde sur laquelle vous pouvez compter.
