Durch den Artikel "Subtle Changes You Might Have Missed" von Kalen Delaney in der Februar-Ausgabe des SQL Server Magazine wurde ich auf eine Änderung aufmerksam, die ich tatsächlich noch nicht bemerkt hatte.
Bislang war es im Wesentlichen so, dass der SQL-Server im Falle eines Deadlock die Transaktion zurück setze, die die wenigsten Änderungen durchgeführt hatte.
Durch die neuen Änderungen wird die Option "SET DEADLOCK_PRIORITY" so aufgemwertet, dass sie tatsächlich sinnvoll eingesetzt werden kann:
Man kann jetzt die Priorität von -10 bis 10 angeben. Neben den alten Werten LOW (=-5) und NORMAL (=0) wurde jetzt auch HIGH (=5) eingeführt.
Jetzt kann man diejenigen Transaktionen kennzeichnen, die nicht als Opfer ausgesucht werden sollen, bisher (also vor SQL Server 2005) konnte man nur festlegen, welche Transaktionen gerne Opfer wären.
Das war natürlich etwas weltfremd, wer ist schon gerne ein Opfer… Mit der neuen nummerischen Abstufung kann man ziemlich gut steuern, wer welche Priorität hat.
Dennoch sollte das nicht darüber hinwegtäuschen, dass man am besten auch gleich Deadlockvermeidungsstrategien verwendet, um die Situation möglichst zu verhindern….