sqlschool.gr logo


Articles of SQLschool.gr Team

Intra-query parallelism deadlock

Antonios Chatzipavlis
Monday 08 May 2017

Το τελευταίο καιρό ασχολούμαι με την υποδομή ενός μεγάλου πελάτη με σκοπό το optimization και φυσικά τo performance.

Μέσα στο διάστημα αυτό έχουμε κάνει αρκετές αλλαγές που οδήγησαν τα πράγματα στο σωστό δρόμο. Μια όμως από αυτές τις αλλαγές ενώ αρχικά δούλευε όπως είχε σχεδιαστεί μετά από μερικές μέρες άρχισε να εμφανίζει σε τυχαία διαστήματα συμπτώματα deadlock.

Εννοείται ότι κάτι τέτοιο δεν το αφήνεις να περάσει χωρίς να το ερευνήσεις.

Analyzing deadlock graph

Βλέποντας το deadlock graph (δείτε το άρθρο μου αυτό για το πως μπορείτε να πάρετε εύκολα το deadlock graph) είχα την παρακάτω εικόνα που ξεφεύγει από τα συνηθισμένα.

deadlock graph

To graph έδειχνε αρκετά αλλά παρόλα αυτά όμως μου ήταν δύσκολο να καταλάβω ακριβώς τι συμβαίνει. Οπότε κατέφυγα στο διάβασμα του xml που παράγει το deadlock graph και το οποίο περιέχει περισσότερες πληροφορίες και αφού πρώτα έκανα ένα φρεσκάρισμα διαβάζοντας από τα BOL το τι δίνει το xml deadlock report.

Από αυτό δείχνω παρακάτω μόνο αυτά που έχουν σημασία για την κατανόηση του προβλήματος

    <victimProcess id="process314c074cf8" />
    <process id="process314c074cf8" waitresource="PAGE: 9:1:810905 " schedulerid="1" kpid="14688" status="suspended" spid="229" sbid="0" ecid="5" ...
    <process id="process456be51868" waitresource="PAGE: 9:1:810905 " schedulerid="10" kpid="27244" status="suspended" spid="96" sbid="0" ecid="7" ... 
    <process id="process314c074928" schedulerid="1" kpid="19956" status="suspended" spid="229" sbid="0" ecid="9" ...
    <process id="process2dbbc38" schedulerid="1" kpid="17532" status="suspended" spid="229" sbid="0" ecid="0" ...
    <pagelock fileid="1" pageid="810905" dbid="9" subresource="FULL" objectname="XXXXXXXX" id="lock15f43f0b00" mode="U" associatedObjectId="72057630202331136">
        <owner id="process456be51868" mode="U" requestType="wait" />
        <waiter id="process314c074cf8" mode="U" requestType="wait" />
    <pagelock fileid="1" pageid="810905" dbid="9" subresource="FULL" objectname="XXXX" id="lock15f43f0b00" mode="U" associatedObjectId="72057630202331136">
        <owner id="process2dbbc38" mode="U" />
        <waiter id="process456be51868" mode="U" requestType="wait" />
    <exchangeEvent id="Pipe39b93bfa00" WaitType="e_waitPipeGetRow" nodeId="35">
        <owner id="process314c074cf8" />
        <waiter id="process314c074928" />
    <exchangeEvent id="Porta3c7ef1500" WaitType="e_waitPortOpen" nodeId="7">
        <owner id="process314c074928" />
        <waiter id="process2dbbc38" />

Αν παρατηρήσουμε στο process-list τα processes θα δούμε ότι τρία από αυτά έχουν το ίδιο session id (spid="229").

Αυτά έχουν διαφορετικό schedulerid το ίδιο system batch id (sbid="0") και διαφορετικό execution context id (ecid) πράγμα που σημαίνει ότι το συγκεκριμένο statement (update με join στην περίπτωση μου) έχει παραλληλίσει για αυτό και υπάρχουν τα exchange events στο deadlock graph.

Αναλύοντας το section του resource-list επιβεβαίωσα αυτό που αρχικά δεν είχα δει με την πρώτη ματιά και που ήταν στην ουσία ότι το συγκεκριμένο statement αυτό-μπλοκαριζόταν καθώς κάποιο από τα threads που είχαν δημιουργηθεί εξαιτίας του παραλληλισμού διάβαζε περισσότερα data σε σχέση με τα άλλα με αποτέλεσμα το deadlock.

Σε αυτές τι περιπτώσεις ο SQL Server βγάζει το εξής λάθος

Msg 8650, Level 13, State 1, Line 1 Intra-query parallelism caused your server command (process ID #??) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1).

Το οποίο όμως δυστυχώς δεν το κάνει log στα SQL Server Logs αλλά το δείχνει μόνο στο application το οποίο όμως δεν το έκανε σωστά log και έτσι το χάναμε.

My solution

Για την επίλυση του προβλήματος όμως δεν είναι πάντα ιδανικό αυτό που προτείνει το συγκεκριμένο error message καθώς θα καθυστερεί περισσότερο η διαδικασία. Αναλύοντας το statement αποφάσισα ότι ένας POC Index στα πεδία που εμπλέκονται στο statement ήταν η καλύτερη λύση και έτσι πλέον δεν παραλληλίζει το update μου εξαιτίας του join με τους άλλους πίνακες που εμπλέκονταν σε αυτό.


Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.


Use Apache Spark in Microsoft Fabric


More Episodes...


Refresh Intellisence in SSMS

Για να κάνουμε refresh το intellisence μέσα στο SSMS αρκεί να πατήσουμε Ctrl+Shift+R

More Tips...

Become a member

If you want to receive updates from us become a member to our community.




sqlschool.gr © 2010-2023 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.