עיבוד תנועות בסביבת SQL Transaction Processing

עיבוד תנועות - מטרה שמירה על אמינות ושלמות בסיס הנתונים בסביבה עתירת תנועות ומרובת משתמשים מערכת RDBMS צריכה להבטיח את הצלחת רצף פקודות העדכון ולא רק את הצלחת הפקודה הבודדת

דוגמא לביצוע תנועה אירוע: רישום סטודנט שמספרו 210 לקורס M-100 לסמסטר קיץ 2007

דוגמא לביצוע תנועה Grades ציונים STUDENT_ID COURSE_ID SEMESTER TERM מס. סטודנט מס. קורס סמסטר מועד ציון 105 C-55 SUM2007 A 70 210 M-100 AUT2008 90 B 50 C-200 85 80 B-10 WIN2008 B-40 245 200 65 WIN2007 95 310 100

דוגמא לביצוע תנועה האירוע מצריך: * הוספת שורה חדשה לטבלת ציונים (עמודת הציונים - ריקה) * עדכון מספר הסטודנטים שנרשמו לקורס בטבלת קורסים INSERT INTO GRADES (COURSE_ID,STUDENT_ID,SEMESTER,TERM) VALUES (‘M-100’,’210’,’SUM2007’,’A’) H UPDATE COURSES SET CUR_ENROLL=CURR_ENROLL+1 WHERE COURSE_ID=‘M-100’J

דוגמא לביצוע תנועה רצף של 2 הפקודות חייב להתבצע כאילו הן פקודה אחת אחרת בסיס המתונים יהיה משובש ולא אמין

דוגמא נוספת עדכון מספר שורות תוך כדי ביצוע פקודה אחת: עדכון כל הציונים (מתן בונוס) לכל הסטודנטים שלמדו בקורס M-100 בסמסטר קיץ 1998 2007 SUM2007

הגדרת תנועה

תכונות של תנועה כל תנועה חייבת לקיים 4 תכונות (ACID) * אטומיות (Atomicity) - תנועה חייבת להתבצע בשלמות * עקביות (Consistency) - תנועה חייבת להעביר את בסיס הנתונים ממצב תקין אחד למצב תקין אחר אפילו שתוך כדי פעולתה התנועה מפירה זמנית את תקינות בסיס הנתונים * אי תלות (Independency) - תנועות חייבות להתבצע באופן בלתי תלוי זו מזו * נצחיות (Durability) - ברגע שהתנועה הסתימה בהצלחה העדכונים חייבים להירשם בבסיס הנתונים

הפקודה COMMIT כפקודת SQL מאפשרת לתוכנית היישום: * להודיע למערכת RDBMS שהתנועה הסתימה בהצלחה * כל פקודות העדכון שהיו צריכות להתבצע כחלק מהתנועה - בוצעו ומצב בסיס הנתונים - תקין

הפקודה COMMIT - דוגמא INSERT INTO GRADES (COURSE_ID,STUDENT_ID,SEMESTER,TERM) VALUES (‘M-100’,’210’,’SUM2007’,’A’) H UPDATE COURSES SET CUR_ENROLL=CURR_ENROLL+1 WHERE COURSE_ID=‘M-100’J COMMIT

הפקודה ROLLBACK גלילה לאחור מאפשרת לתוכנית היישום לבקש מבסיס הנתונים לבטל את כל העדכונים שבוצעו מתחילת התנועה

הפקודה ROLLBACK - AUT2008 AUT2008 AUT2008

מודל התנועות - Transaction Model לפי תקן SQL מגדיר את האופן שבו מערכת RDBMS מזהה את תחילת התנועה, את סיומה המוצלח או את כשלון ביצוע התנועה

מודל התנועות תחילת תנועה - פקודת העדכון הראשונה בתוכנית או פקודת העדכון הראשונה לאחר הפקודה COMMIT סיום תנועה תקין - או ע”י ביצוע הפקודה COMMIT או אם תוכנית היישום מסתימת סיום תנועה לא תקין - או ע”י ביצוע הפקודה ROLLBACK או אם תוכנית היישום “עפה”

בדיקה מושהית של אילוצים שפת SQL מכילה פקודה המאפשרת לקבוע האם בדיקת אילוץ (כגון: מספר מכסימלי של בחינות לסטודנט) תתבצע מיד לאחר כל פקודת עדכון של טבלה (ברירת מחדל) או להשהות הבדיקה לאחר סיום מוצלח של התנועה אם בדיקת האילוץ תיכשל מערכת RDBMS לא תבצע את התנועה כולה והיא תבוטל דוגמא: SET CONSTRAINTS MAX_NUM_OF_EXAMS DEFFERED

יומן אירועים (LOG FILE) המנגנון המאפשר להפעיל את פקודת ה- ROLLBACK הינו יומן האירועים

יומן אירועים הרשומה מכילה את הנתונים האלה: * שם התנועה * הזמן והתאריך בו בוצעה התנועה * זיהוי המשתמש ותחנת העבודה שממנו בוצעה התנועה * הפעולה שבוצעה (ביטול, עדכון, הוספת, תחילת תנועה, סוף תנועה) * שם הטבלה שבה בוצעה הפעולה * תוכן השורה לפני העדכון (Before Values) כולל מפתח השורה * תוכן השורה לאחר העדכון (After Values)

תהליך שיחזור לאחור - Backward Recovery מופעל במקרה של ביצוע פקודת ROLLBACK : * יומן האירועים יקרא בסדר כרונולוגי הפוך * מערכת RDBMS תחזיר את בסיס הנתונים למצבו שלפני העדכון

תהליך שיחזור לפנים - Recovery Forward יומן האירועים משמש גם ב- “שיחזור לפנים” של בסיס הנתונים במקרה של תקלה ניתן להפעיל על קובץ הגיבוי האחרון את כל השורות “שאחרי העדכון” (After Image) לפי סדר כרונולוגי שבו הם בוצעו

דוגמא של קטע מקובץ יומן אירועים After Values Before Values Table Action Terminal User-id Time Date Tran-id   Start Ter-05 Dan 07:30:35 12/02/2008 Grd-01 ………… Grades Update 07:31:01 Ter-08 Ron 07:31:28 Dpt-08 Insert 07:32:02 Departments Delete 07:32:25 Commit 07:32:54 Ter-10 Eyal 07:33:10 Dpt-07 07:33:18 07:33:34

דוגמא של קטע מקובץ יומן אירועים המשתמש Eyal הפעיל תנועה Dpt-07 בשעה 7:33:10 והספיק להוסיף שורה לטבלת מחלקות התנועה לא הספיקה להסתיים מכיוון שלא נרשמה רשומת Commit ביומן האירועים כדי לבצע Rollback נצטרך לבטל את השורה מטבלת “מחלקות” שהמפתח שלה רשום ביומן האירועים כחלק מעמודת “Before Values” “After

פרוטוקול “רישום מראש” פרוטוקול Write Ahead Log Protocol קיים ברוב מערכות ה- RDBMS לפי פרוטוקול זה מערכת RDBMS מעדכנת תחילה את יומן האירועים ורק לאחר מכן את בסיס הנתונים

עדכון בו-זמני Concurrent Updates מצב שבו 2 משתמשים או יותר מנסים לעדכן בסיס נתונים אחד באותו זמן בסביבה מרובת משתמשים (Multi User Environment) כל משתמש מקבל עותק משלו של תוכנית היישום בזיכרון העותק תופס 2 שטחי זיכרון: * עבור פקודות התוכנית * עבור שטח עבודה שבו נרשמים המשתנים והנתונים המעובדים

שיטת ה- Reentrant רב-כניסות אפשרות אחרת - רק עותק אחד של תוכנית היישום נשמר יחד עם מראה מקום נפרד עבור כל משתמש כל משתמש מקבל שטחי עבודה נפרדים

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

גישות בניהול תנועות גישת הנעילות (Oracle) גישת הגירסאות

בעיית “העדכון האבוד" (Lost Update) נגרמת כתוצאה מעדכון בו-זמני דוגמא: 2 סטודנטים מנסים להירשם באותו זמן לאותו קורס נתבונן במה שקורה עם טבלת “קורסים” שמכילה בין השאר 2 עמודות: * “מספר סטודנטים מכסימלי לקורס” * “מספר סטודנטים שכבר נרשמו לקורס”

בעיית “העדכון האבוד" (Lost Update) סטודנט א’ נרשם לקורס C-200 תוכנית היישום מבצעת Select ושולפת את שורת קורס C-200 מבסיס הנתונים אל שטח העבודה שהוקצה לסטודנט א’

בעיית “העדכון האבוד" (Lost Update) סטודנט ב’ מבקש להירשם לאותו קורס

בעיית “העדכון האבוד" (Lost Update) סטודנט א’ מאשר את ההרשמה תוכנית היישום: * מגדילה ב- 1 את מונה “מספר הסטודנטים שכבר נרשמו” * מעדכנת את בסיס הנתונים * מבצעת Commit * משחררת את שטח העבודה של סטודנט א’

בעיית “העדכון האבוד" (Lost Update) סטודנט ב’ מאשר אף הוא את ההרשמה

בעיית “העדכון האבוד" (Lost Update) הבעיה - כל משתמש קרא את אותם נתונים מבסיס הנתונים לשטחי העבודה שבזיכרון מבלי להתייחס לעובדה שהנתונים עומדים להתעדכן בינתיים ע”י משתמש אחר

בעיית עדכון רשומה שנמצאת בתהליך עדכון (Uncommitted Update)

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא מופעלות 2 תוכניות יישום שונות: * אחת - לעדכון המספר המכסימלי של סטודנטים לקורס (מ- 85 ל- 95) * השניה - רישום לקורס

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא

בעיית ניתוח נתונים לא עקבי Inconsistent Analysis תוכנית א’ מפיקה דו”ח המציג את מספר הסטודנטים שנרשמו בפועל לפי קורס תוכנית זו מתחילה לעבוד ולשלוף נתונים מבסיס הנתונים תוך כדי העבודה מתחילה לפעול תוכנית ב’ לרישום סטודנטים לקורס ומעדכנת את נתוני אחד הקורסים שכבר נקראו ע”י תוכנית א’ כאשר תוכנית א’ מסיימת לעבוד היא מציגה נתונים שכבר אינם נכונים מאחר ותוך כדי פעולתה בסיס הנתונים התעדכן

מנגנון הנעילות (Locking) כאשר תוכנית מבקשת לנעול אובייקט נעול היא תכנס לתור התוכניות הממתינות לאובייקט זה עד אשר התוכנית הקודמת לה תשחרר את הנעילה

רמת הנעילה (Locking Granularity) תחום בסיס הנתונים שכפוף להוראת הנעילה

רמות הנעילה האפשריות עמודה בתוך שורה (Column Level Locking) - מונעת גישה מתוכניות אחרות המבקשות לעדכן אותה עמודה באותו שורה לא מונעת גישה של תוכניות אחרות לאותה שורה כדי לעדכן עמודות אחרות בגלל המורכבות - רוב מערכות RDBMS אינן תומכות בנעילה ברמה זו

רמות הנעילה האפשריות שורה (Row Level Locking) - * מערכת RDBMS תבצע נעילה של כל השורה מבלי להתייחס אילו עמודות בשורה מתעדכנות * רוב המערכות המסחריות תומכות בשיטת נעילה זו דף (Page Level Locking) - פעולות קלט/פלט מתבצעות תמיד ברמה של דף פיסי (Page) שיכול להכיל שורה אחת או יותר

רמות הנעילה האפשריות טבלה (Table Level Locking) - * מערכת RDBMS תבצע נעילה של כל הטבלה מבלי להתייחס אילו שורות ואילו עמודות בטבלה מתעדכנות * קלה למימוש אולם מקטינה את כמות העבודה במקביל * אינה מתאימה לסביבה מרובת-משתמשים בסיס הנתונים (Data Base Level Locking) * קלה ביותר לשימוש * מיושמת במצבים נדירים

סוגי הנעילות (Lock Type) נעילה בלבדית (Exclusive Lock) - אף תוכנית יישום אחרת אינה מורשית לקרוא או לעדכן את הנתונים נעילה שיתופית (Shared Lock) - * תוכנית יישום המבקשת לקרוא שורה מסוימת מחזיקה אותה בסטטוס של “נעילה שיתופית” ובכך מתירה לתוכניות אחרות לקרוא אותה שורה אך לא לעדכן אותה * ברגע שהתוכנית מבקשת לעדכן את השורה היא צריכה להעביר את הנעילה מ- “שיתופית” ל- “בלבדית”

טבלת החלטות לקבלת נעילות

Consistent read אם נוצר מצב של "הרעבה" (Starvation) "הרעבה" – יישום מבקש לבצע קריאה בלבד לרשומה נעולה למשך זמן רב פיתרון – Consistent Read קריאה של רשומה מגירסה קודמת (לפני העדכון) מצריך ניהול גירסאות

טבלת החלטות לקבלת נעילות בצע נעילת כתיבה קרא מגירסה קודמת

נעילה ללא מוצא (Deadlock) מצב נצחי של המתנה לשורה מצב שבו 2 תוכניות יישום (או יותר) נועלות אובייקט שהתוכנית השניה מבקשת להשתמש בו

נעילה ללא מוצא - דוגמא 2 תוכניות יישום המעדכנות 2 שורות שונות אולם בסדר הפוך: * תוכנית א’ מתחילה לפעול ושולפת שורה A ומבצעת לשורה נעילת בלבדית (כתיבה) לקראת עדכון * תוכנית ב’ מתחילה לפעול ושולפת שורה B ומבצעת לה נעילה בלבדית (כתיבה) * תוכנית א’ מבקשת לקרא את שורה B ולבצע לה נעילה בלבדית מכיוון ששורה זו כבר נעולה התוכנית מוכנסת למצב המתנה * תוכנית ב’ מבקשת לקרא את שורה A ולבצע לה נעילה בלבדית מכיוון ששורה זו כבר נעולה התוכנית מוכנסת למצב המתנה

היחלצות ממצב של נעילה ללא מוצא ביצוע כל הנעילות לפני עדכון - * כל תוכנית צריכה להכריז מראש על כל השורות שהיא מבקשת לנעול * מערכת RDBMS מתחילה לבצע את הנעילות * אם שורה מסוימת כבר נעולה משחררים את כל השורות שכבר ננעלו והתהליך מתחיל מחדש * קשה ליישם כי בד”כ תוכנית יישום אינה יודעת מראש את כל השורות שתרצה לעדכן

היחלצות ממצב של נעילה ללא מוצא איתור מצב נעילה ללא מוצא - * מערכת RDBMS קובעת זמן המתנה (Time Out) כך שאם תוכנית יישום ממתינה מעבר לו תופסק פעולתה של תוכנית יישום כל שהיא תוך כדי ביצוע פעולה Rollback וביטול כל העדכונים שהתוכנית כבר ביצעה * הקריטריון לבחירת התוכנית שפעולתה תופסק: - התנועה האחרונה שהתחילה לפעול - התנועה שהספיקה לבצע הכי מעט עדכונים

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא תוכנית יישום TR1 קוראת שורה של קורס C-200 מטבלת “קורסים” ומעדכנת אותה תוכנית יישום TR2 קוראת את השורה של מחלקת CS מטבלת “מחלקות”, קוראת את השורה של קורס C-200 מטבלת “קורסים” ולבסוף מעדכנת את השורה של מחלקת CS בטבלת “מחלקות”

בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא TR1 SELECT (C-200) COURSES UPDATE (C-200) COURSES TR2 SELECT (CS) DEPARTMENTS SELECT (C-200) COURSES UPDATE (CS) DEPARTMENTS

דוגמא לניהול נעילות ע”י מערכת RDBMS

דוגמא לניהול נעילות ע”י מערכת RDBMS

גירסאות מערכת Framework – Hibernet מתוצרת Apache סביבה מונחית עצמים שפת JAVA בסיס נתונים Oracle ה- Framework מנהל את העבודה (SELECT, UPDATE) עם הנתונים

גירסאות – מספר עדכני ו-מספר שוטף לכל שורה בטבלה נשמר "מספר גרסה" יישום המבקש לעדכן שורה בטבלה – קורא שורה מהדיסק (בעזרת ה- Framework) היישום (בעזרת ה- Framework) מעלה ב- 1 את ה- "מספר הגרסה" של שורת הטבלה היישום שומר את השורה בשטח העבודה שלו ב- RAM עם "מספר הגירסה" – "מספר גירסה של היישום"

גירסאות – עדכון שורה כאשר יישום מבקש לעדכן רשומה הוא מבצע פקודה: PDATE…WHERE "מספר גרסה של היישום" ="מספר הגירסה (של שורת הטבלה)" אם השוויון אינו מתקיים היישום מתחיל מחדש אם השוויון מתקיים ונרשמה פקודת Commit - העדכון יתבצע

מספר גירסה של שורת קורס: C-200 = 5 דוגמא: 2 יישומים מבקשים לרשום 2 סטודנטים לאותו קורס - בעיית העדכון האבוד מספר גירסה של שורת קורס: C-200 = 5 יישום א' רוצה לעדכן רשומה לכן הוא קורא רשומת הקורס מהדיסק ומעלה את המספר הגרסה ל- 6 כך שב- RAM שלו מצויה עותק הרשומה עם גירסה 6 יישום ב' רוצה לעדכן אותה רשומה לכן הוא קורא אותה רשומה מהדיסק מעלה את מספר הגרסה ל- 7 כך שב- RAM שלו מצויה עותק הרשומה עם גירסה 7

דוגמא: 2 יישומים מבקשים לרשום 2 סטודנטים לאותו קורס היישום הראשון מבצע פקודת UPDATE אשר לא תתבצע כי מספר הגרסה ב- RAM שלו הינה 6 ואילו "מספר הגירסה" של השורה הינו 7 (היישום יתחיל להתבצע מחדש) היישום השני מבצע פקודת UPDATE אשר תתבצע כי מספר הגירסה ב- RAM שלו הינה 7 הזהה ל- "מספר הגירסה" של השורה

בעיית עדכון רשומה שנמצאת בתהליך עדכון (Uncommitted Update) יישום א' רוצה לעדכן רשומה (מספר נרשמים מכסימלי מ- 85 ל- 95) הוא קורא רשומת הקורס מהדיסק ומעלה את המספר הגרסה ל- 6 כך שב- RAM שלו מצויה עותק הרשומה עם גירסה 6 היישום מבצע פקודת UPDATE אשר לכאורה תתבצע כי מספר הגרסה ב- RAM זהה ל- "מספר הגירסה" של השורה ואולם מאחר ולא בוצע COMMIT כי אז לא תתבצע עדיין כתיבה על הדיסק ממש (RDBMS יחכה עד לפקודת ה- (COMMIT יישום ב' רוצה לעדכן אותה רשומה (מספר נרשמים עד כה מ- 38 ל- 39) לכן הוא קורא רשומה מהדיסק (ללא שינויים של יישום א') מעלה את מספר הגרסה ל- 7 כך שב- RAM שלו מצויה עותק הרשומה עם גירסה 7

בעיית עדכון רשומה שנמצאת בתהליך עדכון (Uncommitted Update) היישום הראשון מבצע פקודת ROLLBACK אשר בעצם מוחק את שורת הטבלה מזיכרון ה- RAM של היישום ולא מהדיסק היישום השני מבצע פקודת UPDATE אשר תתבצע כי מספר הגירסה ב- RAM שלו הינה 7 הזהה ל- "מספר הגירסה" של השורה

תנועה עם מספר עדכונים לדוגמא: רישום סטודנט לקורס כולל עדכון "מספר סטודנטים שנרשמו עד כה" וכן הוספת שורה בטבלת "ציונים" ברגע שנרשמה פקודת COMMIT כי אז לכל עדכון ועדכון - * מתבצעת השוואה בין מספר הגירסה של שורת הטבלה עם מספר הגרסה של היישום * אם קיים שוויון יתבצע העדכון פיזית בדיסק * אחרת ימחקו כל העדכונים מזיכרון ה- RAM של היישום * היישום יתחיל להתבצע מחדש

תרגילים .1 מנה לפחות 2 סיבות מדוע תנועה עלולה להסתיים .1 מנה לפחות 2 סיבות מדוע תנועה עלולה להסתיים בכישלון 2. הסבר את החשיבות של קובץ יומן האירועים ואיזה שירותים הוא מספק 3. חווה דעתך על אורך התקופה שבה כדאי לשמור יומן אירועים 4. הסבר מהו “שיחזור לאחור” ומהו “שיחזור לפנים” ומתי נדרש כל אחד מהם

תרגילים 4 נתון מצב הנעילות הבא: * משתמש דן נעל את האובייקטים: R3, R2, R1 וממתין לאובייקט R4 * משתמש רון נעל את האובייקטים R6, R5, R4 וממתין לאובייקט R8 * משתמש אייל נעל אובייקטים: R9, R8 וממתין לאובייקט R10 * משתמש צבי נעל אובייקטים R11, R10 וממתין ל R2 * הראה כיצד בא לביטוי העובדה שזהו מצב של נעילה ללא מוצא