שאלה על נעילות ב-SQL Server

[גרי רשף]

שאלה על נעילות ב-SQL Server../images/Emo22.gif

שאילתת Select שהרצתי משרת אחד על שרת אחר- גרמה לאחד השרתים להיתקע. כך לפחות טוען ה-DBA, למרות שבעיני זה תמוה. גורם אחר במערכת שכבר קיבלתי ממנו בעבר עצה טובה אחת או שתיים טען שיש להשתמש באפשרויות Using NOLOCK ו-Security Level כדי למנוע תופעות כאלו. מעיון במספר מקורות הבנתי שהאפשרויות הנ"ל מאפשרות לי לנעול טבלאות או להתגבר על נעילות, אבל הן אינן מונעות נעילת טבלאות על ידי.. במילים אחרות- אם מסיבה כל שהיא נעלתי טבלה בתום לב על ידי פעולת Select, המשתמשים האחרים צריכים להשתמש ב-NOLOCK או ב-Security Level כדי להתגבר על כך. והשאלה- אם הבנתי נכון, מי שגורם לנעילת טבלה לא יכול לעשות דבר כדי לעזור למשתמשים האחרים (אלא אם כן הוא נעל בכוונה). האמנם?

 

[eli_leiba]

לגבי נעילות

sql server עובד ב default כ read committed זה אומר שבזמן שאתה שולף מידע (בזמן ביצוע השליפה) יש share Lock על הנתונים , זה אומר שאחרים יכולים לשלוף אך לא לעדכן בזמן השליפה שלך! על מנת לאפשר להם לעדכן (שים לב - בזמן! שאתה שולף - שזה גם יכול להיות בעייה עבורך בעיקר) יש לשנות את ה isolation level של ה session ל read Uncommitted מצב זה יפתור לאחרים את הבעייה אבל נתונים שלך יכולים להשתנות תוך כדי שליפה! אלי

 

[גרי רשף]

שאלת הבהרה../images/Emo22.gif

אם X מעניין לשלוף רשומות ובמקביל Y מעוניין לעדכן אותן אזי- 1. אם X התחיל לשלוף ראשון והוא רוצה לאפשר ל-Y להתחיל לשנות אזי עליו להכריז על Read Uncommitted. 2. אם Y התחיל לעדכן ראשון ו-X רוצה לשלוף את הרשומות תוך כדי כך עליו להכריז על NOLOCK. האמנם?

 

[eli_leiba]

אתה יכול להכריז על צורת isolation

מסוג read uncommitted ואז גם x יכול לשלוף ללא נעילה וגם y יכול לעדכן ובו בזמן להיות נקרא מתהליך אחר בתנאי ששניהם read uncomitted זה כמובן יכול להיות מואוד בעייתי בכ"ז קרא על set isolation level ב BOL