Deadlock by insert one row

השבוע פנה אלי לקוח שהתלונן שלפתע התחילו אצלו כמויות אדירות של Deadlocks.

כאשר ביצע העברת גרסה שכללה שינוי לאינדקסים. (הוספת 2-3 עמודות לinclude ל-2 אינדקסים). הלקוח תהה האם הוספת עמודות נוספות לinclude יכולות לגרום לתופעה של המון Deadlocks בגלל גודל הטבלה(כ25 מיליון רשומות)?

על מסד הנתונים קיים לנו בשגרה איסוף נתונים לגבי Deadlocks (ע"פ מאמר שפרסמנו בעבר)

שלפנו את ה - Deadlock Graph –

ניתן לראות כמה נתונים שיכולים לעזור לנו לפענח את המקרה:

2 התהליכים מבצעים את אותו הקוד – הכנסה של רשומה חדשה לטבלה [Schema].[Table_X] ע"י Entity framework. הכנסה לטבלה ושליפה מידית למסך בטרנזקיה.
תהליך א' ביקש סוג נעילה X (מתוך Books On Line)

3. תהליך ב ביקש וקיבל נעילה מסוג IX

4. ניתן לראות שהנעילה היא לא על שורה כמו שמצופה אלא על הנתון –

objectlock lockPartition="26" objid="1450157815"

הטבלה אינה טבלה בעלת מספר Partition- ים אבל נתפס שיש נעילת Partition שונה מ0.

5. האם היה שינוי נוסף שנכנס באותה גרסה? הלקוח ענה שלא.

6. ביקשתי לראות את מה הסקריפט שהורץ בפועל.

כאשר מביטים בסריפיט הוא נראה ככל סקירפט רגיל, אך אם נביט טוב נשים לב שנבחרו 2 אופציות ששונו ע"י המפתח-

ALLOW_ROW_LOCKS. המשמעות – אל תיזום נעילת שורה על האינדקס – תתקבל הנעילה הבאה בתור – Page.
ALLOW_PAGE_LOCKS המשמעות – אל תיזום נעילת דף על האינדקס – תתקבל הנעילה הבאה בתור – OBJECT.

במקרה שלנו שתי האפשרויות היו כבויות, מתוך כוונה טובה אני חייב לציין (המפתח חשב שכך הוא ייצור את האינדקס ללא נעילות).

ולכן החלטנו לבצע שאילתה למציאת בעיות נוספות מאותו הסוג –

השאילה משנה רק את 2 סוגי המאפיינים בחזרה למצב ברירת המחדל שלהם – פעיל.

כאשר יישרנו קו, נעלמו הDeadlocks באותה הקלות שבה הן הופיעו...