660 likes | 763 Views
עיבוד תנועות בסביבת SQL Transaction Processing. עיבוד תנועות - מטרה. שמירה על אמינות ושלמות בסיס הנתונים בסביבה עתירת תנועות ומרובת משתמשים מערכת RDBMS צריכה להבטיח את הצלחת רצף פקודות העדכון ולא רק את הצלחת הפקודה הבודדת. דוגמא לביצוע תנועה.
E N D
עיבוד תנועות בסביבת SQL Transaction Processing
עיבוד תנועות - מטרה • שמירה על אמינות ושלמות בסיס הנתונים בסביבה עתירת תנועות ומרובת משתמשים • מערכת RDBMS צריכה להבטיח את הצלחת רצףפקודות העדכון ולא רק את הצלחת הפקודה הבודדת
דוגמא לביצוע תנועה • אירוע: רישום סטודנט שמספרו 210 לקורס M-100 לסמסטר קיץ 2007
דוגמא לביצוע תנועה • האירוע מצריך: *הוספת שורה חדשה לטבלת ציונים (עמודת הציונים - ריקה) *עדכוןמספר הסטודנטים שנרשמו לקורס בטבלת קורסים • 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 תחזיר את בסיס הנתונים למצבו שלפני העדכון
תהליך שיחזור לפנים - RecoveryForward • יומן האירועים משמש גם ב- “שיחזור לפנים” של בסיס הנתונים במקרה של תקלה • ניתן להפעיל על קובץ הגיבוי האחרון את כל השורות “שאחרי העדכון” (After Image) לפי סדר כרונולוגי שבו הם בוצעו
דוגמא של קטע מקובץ יומן אירועים • המשתמש 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) • הבעיה נוצרת כאשר תוכנית יישום אחת (תוכנית ב’) נמצאת בתהליך עדכון שורה שעודכנה קודם לכן ע”י תוכנית יישום אחרת (תוכנית א’) שעדיין לא ביצעה Commit ואח”כ יבוצע גלילה לאחור של תוכנית א’
בעייתעדכון רשומה שנמצאת בתהליך עדכון - דוגמא • מופעלות 2 תוכניות יישום שונות: * אחת - לעדכון המספר המכסימלי של סטודנטים לקורס (מ- 85 ל- 95) * השניה - רישום לקורס
בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא
בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא
בעיית עדכון רשומה שנמצאת בתהליך עדכון - דוגמא
בעיית ניתוח נתונים לא עקבי Inconsistent Analysis • תוכנית א’ מפיקה דו”ח המציג את מספר הסטודנטים שנרשמו בפועל לפי קורס • תוכנית זו מתחילה לעבוד ולשלוף נתונים מבסיס הנתונים • תוך כדי העבודה מתחילה לפעול תוכנית ב’ לרישום סטודנטים לקורס ומעדכנת את נתוני אחד הקורסים שכבר נקראו ע”י תוכנית א’ • כאשר תוכנית א’ מסיימת לעבוד היא מציגה נתונים שכבר אינם נכונים מאחר ותוך כדי פעולתה בסיס הנתונים התעדכן
מנגנון הנעילות (Locking) • הגדרת נעילה (Lock) - פעולה המבצעת סימון של אובייקט בבסיס הנתונים (שורה, טבלה..) כדי להצביע על כך שהאובייקט נמצאכרגעבתהליך של עדכון ולכן הוא חסום לגישה ע”י משתמשים נוספים • כאשר תוכנית מבקשת לנעול אובייקט נעול היא תכנס לתור התוכניות הממתינות לאובייקט זה עד אשר התוכנית הקודמת לה תשחרראתהנעילה
רמת הנעילה (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ולבצע לה נעילה בלבדית מכיוון ששורה זו כבר נעולה התוכנית מוכנסת למצב המתנה