
הטקסט המלא של הדקות הראשונות בהרצאה «סיכום על טרנזקציות SQL» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אם כן, חברים וחברות, נשוב ונסכם את הנקודות העיקריות שראינו בדוגמאות האחרונות שלפנינו בנושא של Isolation Level ואת הבעיות שאיתן אנחנו התמודדנו וכיצר פתרנו אותן. הבעיה הראשונה זוהי Dirty Reads, קריאת נתונים שהותקנו במהלך חייה של הטרנזקציה ואשר בגינם בסופו של דבר בוצע rollback, שטרנזקציות אחרות עלולות לראות מידע מלוכלך זה במידה וה-Isolation
Level הוא Read Uncoded, אולם פתרנו את הבעיה הזאת כאשר עלינו לרמה של Read Data Committed בלבד. Read Committed אנחנו קוראים נתונים רק כאלו שבוצע בגינם Committed, אולם בעיה אחרת שנחשפנו אליה זה ה-Non-Repeatable Reads, טרנזקציה אחת שיש בתוכה שני סלקטים כאשר השאיפה
שלי ששני הסלקטים הללו אף שהם מופיעים בתחילתה של הטרנזקציה והשני בסיומה יקראו את אותם נתונים בדיוק צו זה היה בלתי אפשרי בעבודה מול read committed ולכן עברנו ל-isolation level המתקדם יותר שהוא ה-repeatable read מצב שבו בעת תחילתה של הטרנזקציה אנחנו בעצם נועלים את הרשומות ולא מאפשרים לאף משתמש אחר בכל קונקשן שהוא להתחבר לתוך הדאטאבייס,
להתחבר לתוך הנתון הרלוונטי עצמו ולעדכן לנו אותו. על מנת שכל הנתונים שאני רואה בתחילת בסופה של הטרנזקציה יהיו זהים לחלוטין לנתונים אותם ראיתי בתחילתה של הטרנזקציה.
נקודה נוספת בעייתית שראינו בעבודה מול data committed זה ה-lost מול read committed זהו ה-lost updates, עיבוד עדכונים. בשעה שאני פותח טרנזקציה שהיא ארוכה, היא שולפת נתונים ורק בסוף בסוף בסוף מעדכנת אותם בתוך הדאטאפס.
אם אנחנו עובדים במוד של read committed, כל טרנזקציות אחרות שייגשו לתוך אותה השאילתא, לתוך אותם נתונים, ויעדכנו אותם, ייכנסו להמתנה עד לסיומה של הטרנזקציה הנוכחית.
זהו ה-Lost Updates ואת שתי הבעיות הללו שלפניכם