נעילות

[רץ ברשת]

נעילות

בעקרון אני עובד עם MS SQL Server 2000/2005, אבל אני מניח שהשאלות הם כלליות :

Select 1. בעקרון בזמן ביצוע Select אין נעילות, אמת ? 2. האם יש אפשרות לבצע נעילה בזמן שליפה, כדי לקבל (למשל) רק את הרשומות שהיו קיימות לפני הפקודה, בלי מה שהתווסף במהלך ריצה השליפה

Insert 3. האם מתבצעת נעילה כלשהי בזמן הוספת רשומה חדשה ?

Delete 4. האם מתבצעת נעילה כלשהי בזמן מחיקת רשומה קיימת ?

Update 5. כאשר מעדכנים רשומה אחת, האם רק היא ננעלת ? 6. כאשר מעדכנים אוכלוסיה של רשומות, כל הרשומות המתעדכנות ננעלות, או כל הטבלה ?

כללי 7. באילו מצבים ננעלת כל הטבלה ? 8. מה אומר המודל הפסימי, ומה אומר האופטימי ? 9. מתי משתמשים ב no lock ולאיזו מטרה בדיוק ? 10. מה עוד חשוב לדעת בנושא נעילות ?

 

[ShlomoBenAri]

../images/Emo41.gif

Select 1. בערך,הרשמות נקראות עם אפשרות עריכה - עם nolock הקריאה יותר מהירה אך ללא אפשרות עריכה 2.מתבצע אוטומטית Insert 3.לא Delete 4.לא Update 5.כן 6.ננעלות עפ"י סדר עדכון (שהשרת קובע) כללי 7. בעידכון עם INNER JOIN מול בסיס נתונים אחר באותו שרת - באופן חלקי תלוי באינדקסים ומהירות גישה או מול שרת מרוחק - יש השפעה לזמני תגובה 8.לא שמעתי דעות חד משמעיות 9.ראה 1. 10.שירה . . . אלי אלי שלא ינעל לעולם..

לפי מיטבד ידיעתי, אם זכרוני אינו מטעני, בלי נדר אולי אם ירצה השם שלמה

 

[רץ ברשת]

../images/Emo13.gif ../images/Emo51.gif תגובה :

1. מה הכוונה "עם אפשרות עריכה" ? כיצד ניתן לערוך רשומות בעת ביצוע select ? 1.1 כלומר, כדאי תמיד לבצע select with no lock כדי לשפר ביצועים (כשרוצים באמת רק שליפה) ? 2. ואם רוצים לקבל גם את הרשומות שהתווספו במהלך ריצת ה select, אפשרי ? 6. כלומר, גם כשמעדכנים אוכלוסיה, ואפילו את כל הטבלה (ביצוע update ללא where), תמיד ברגע נתון רק רשומה אחת נעולה ? 7. כאשר מדובר בפעולות בתוך אותו DB בלבד, יש מצבים שבהם כל הטבלה ננעלת ? 8. אבל אתה יודע מה המושגים עצמם אומרים ? 9. האם no lock אפשר רק במשפט select ? 10. ענק

 

[ShlomoBenAri]

בקצרה

1.בזמן ה select אתה מקבל ערכת רשומות יש אפשרות ל"הודיע" לשרת על רשומה או ערכת רשומות שהם ב EditMode=Edit כמו בעבודה עם ADO או DAO הידועים מ VB6 או אקסס כנ"ל יש לאוביקטים של DotNet 1.1 נכון והתוצאה כמו SnapShot 2. קיימת אפשרות עם Cursor כשהוא מוגדר Dinamic , עם select לא בדקתי 6. לדעתי גם עם where 7. נתקלתי בנעילת טבלה בשאילתות לא מטויבות (כבדות ברמות) בגלל בעיית משאבים. נדמה לי שיש מצבים (Magic מול SQL ) שכל הטבלה ננעלה כשהישום ביקש זאת - הכריז על כל הטבלה שהיא במצב עריכה - ברירת המחדל של SQL נעילת רשומה בודדת וב 2005 זה השתפר 8. "המודל הפסימי" בגוגל החזיר דפים שקשורים לכדורגל - גישה פסימית או אופטימית שמעתי בימי עיון בעניין של נעילת טבלאות כאשר יש חשיבות לעדכון כל הרשומות בטבלה לפני שמאפשרים גישה נוספת לעדכון או אפילו ל select 9. כן, אך כדאי מאד לעיין ב BOL על כל אפשרויות הנעילה, הערך nolock מציג את כל האפשרויות: ROWLOCK ,PAGLOCK,TABLOCK,DBLOCK, וכו' 10. יותר ענק שהפעם הבא שאני אפגוש מחשב תיהיה ביום חמישי אלה אם כן יתקינו אקסס פוינט בזולות על הדן.

 

[רץ ברשת]

../images/Emo13.gif תודה רבה.

 

[s h i m s h o n]

שאלה

- מה קורה אם מבצעים DELETE לרשומה ומישהו אחר מנסה לעדכן או למחוק אותה? - מה קורה אם מבצעים INSERT לטבלה עם מפתח PK ומישהו אחר מנסה להכניס רשומה עם אותו המפתח? בברכה, ש.

 

[ShlomoBenAri]

הראשון משיג..(אין real time אמיתי)

 

[s h i m s h o n]

../images/Emo2.gif בטוח?

ומה אם הראשון ביצע ROLLBACK? איפה פה ה-Data Integrity? ההגיון אומר שתהיה נעילה. בברכה, ש.

 

[Ice Age]

תיקונים

מה שכתבת לא מדוייק: Select 1. בערך,הרשמות נקראות עם אפשרות עריכה - עם nolock הקריאה יותר מהירה אך ללא אפשרות עריכה אין מבחינת ה-DB "אפשרות עריכה". בשליפה הרשומה ננעלת ב-Shared lock (אלא אם משנים את רמת הנעילה באמצעות ה-isolation level של הטרנזקציה) שלא מאפשר לעדכן אותה, כי עדכון מנסה לשים exclusive lock. 2.מתבצע אוטומטית אם הרשומה נעולה, ניתן באמצעות snapshot isolation level לקרוא את המצב הקודם שלה. Insert 3.לא לא נכון, בהחלט מתבצעות נעילות במספר רמות, פרטים כאן. Delete 4.לא כנ"ל Update 5.כן לא נכון - SQL Server מחליט האם לנעול רשומה, דף או טבלה בהתאם למספר משתנים סביבתיים. בד"כ בעדכון בודד זה אכן יהיה רשומה בודדת. 6.ננעלות עפ"י סדר עדכון (שהשרת קובע) כנ"ל - תלוי במספר גורמים כמו כמות הנעילות הקיימת, מקסימום נעילות מוגדר וכו'. כללי 7. בעידכון עם INNER JOIN מול בסיס נתונים אחר באותו שרת - באופן חלקי תלוי באינדקסים ומהירות גישה או מול שרת מרוחק - יש השפעה לזמני תגובה אין כלל, אבל בד"כ כשיש חלק ניכר מהטבלה שמעודכן (נניח כמה עשרות אחוזים) אז הוא יחליט לנעול את כל הטבלה. 8.לא שמעתי דעות חד משמעיות זה שאלה תכנותית ולא של הDB עצמו, אבל הנה קישור. 9.ראה 1. בעיקרון עדיף אף פעם. זה עלול להביא תוצאות לא נכונות בשל צורת הקריאה. אם אתה מוכן לסבול את זה, זה חוסך נעילות ולכן יש כאלו שמשתמשים (וגם בגלל שהם לא מודעים לכך שהם עלולים לקבל תוצאות שגויות).

 

[רץ ברשת]

../images/Emo51.gif רק הבהרה לגבי 9 :

אם אני מבצע Select, מדוע שלא אשתמש ב no lock כדי להפחית נעילות פוטנציאליות ולשפר ביצועים ? מה התוצאות השגויות שאני עלול לקבל ?

 

[Ice Age]

צורת העבודה במקרה של nolock

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

 

[רץ ברשת]

הממ...

איזה דפים ? אתה מדבר על דפי זכרון המכילים את המידע ? לא יודע מה זה ISUG

אבל אםיש לך לינק שמוכיח ששימוש ב NO LOCK מסוכן, זה יכול מאוד לעזור...

 

[Ice Age]

תשובות

דפים - יחידת המידע הבסיסית של SQL Server היא דף, שמכיל בד"כ מספר רשומות. ISUG = Israeli SQL Server User Group. הנה קישור לפגישה עם הסקריפטים.

 

[רץ ברשת]

../images/Emo51.gif ../images/Emo70.gif

 

[חובב טניס]

NOLOCK

יכולות להיות מספר בעיות בשימוש בNOLOCK. הבעיה הראשונה והיותר מוכרת, היא שאתה יכול לקבל נתון לא נכון. אם אני מבצע טראנסקציה. ביצעתי שינוי ברשומה. לאחר מכן אתה מבצע משפט select עם nolock, אתה תקבל את השינוי שביצעתי גם אם לא סגרתי את הטראנסאקציה. במידה, שאני מבצע rollback, אתה לא יכול לדעת, שהנתון שלך לא נכון ולא נרשם בסופו של דבר בבסיס הנתונים. הבעיה השניה פחות מוכרת (אני לפחות שמעתי על זה רק לפני כ3 חודשים) והיא מתוארת, מוסברת, מודגמת, מנומקת ומפורטת באתר הבא - http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspx

 

[רץ ברשת]

../images/Emo51.gif ../images/Emo70.gif