התאוששות ( recovery )

התאוששות (recovery)

סוגי אחסון (storage types) • זיכרון נדיף (volatile storage): לדוגמא, זיכרון ראשי, מטמון (cache). • זיכרון לא נדיף (nonvolatile storage) לדוגמא, זיכרון משני, טייפ מגנטי. • זיכרון יציב (stable storage)יש רק קירוב של זיכרון כזה.

סוגי כשלים (failure types) • כשל לוגי (logical error) • שגיאת מערכת (system error) • נפילת מערכת (system failure) • כשל דיסק (disk failure)

לשם מה התאוששות? T read (A) A = A - 50 write(A) read(B) B = B + 50 write(B)

התאוששות מבוססת יומן שיטת ההתאוששות הנפוצה ביותר. כל רשומת יומן (log) מתארת כתיבה אחת לבה”נ וכוללת את השדות: • שם טרנזקציה. • שם פריט המידע. • ערך ישן. • ערך חדש.

רשומות יומן מיוחדות נוספות מתעדות אירועים מיוחדים במהלך העיבוד של הטרנזקציה, כמו למשל תחילת הטרנזקציה או סיומה (commitאו abort). לפני שטרנזקציה מבצעת פעולת כתיבה כלשהי, הכרחי לרשום קודם לכן את הרשומה המתאימה בקובץ היומן. <Tistart> <Ti , Xj, V1, V2> <Ticommit>

עדכון מושהה (deffered modification) בשיטה זו רושמים את פעולות העדכון לבה”נ ביומן, אך משהים את הביצוע של כל פעולות הכתיבה (write) עד שהטרנזקציה עוברת למצב partially commit. בשלב זה כל האינפורמציה ביומן הקשורה בטרנזקציה זו משמשת לביצוע העדכונים המושהים. אם המערכת קורסת לפני סיום הטרנזקציה, או אם היא עוברת למצב abort , פשוט מתעלמים מהאינפורמציה ביומן. התאוששות על ידי פעולות redo בלבד.

בהנחה של ביצוע סדרתי ושל ערכים התחלתיים: A=$1000 B=$2000 C=$700 ערכים סופיים: A=$950 B=$2050 C=$600 דוגמא T0 : read (A) A=A-50 write(A) read(B) B=B+50 write(B) T1: read (C) C=C-100 write(C) LOG RECORDS <T0 , start> <T0 , A, 950> <T0 , B, 2050> <T0 , commit> <T1 , start> <T1 , C, 600> <T1 , commit>

עדכון מיידי (immediate modification) בשיטה זו העדכון של בה”נ עשוי להתבצע כאשר הטרנזקציה במצב פעיל (active). פעולות עדכון שנרשמות על ידי טרנזקציה במצב פעיל נקראות uncommited modifications . במקרה של נפילה או של כישלון הטרנזקציה, השדה של הערך-הישן ברשומות היומן משמשות לשחזור הערכים ששונו לערכיהם בטרם תחילת הטרנזקציה. לפני כל ביצוע פעולת כתיבה (write(Xמתבצעת הוספת רשומה מתאימה ליומן. כאשר הטרנזקציה partially commits , נכתבת ליומן הרשומה <T , commit>. התאוששות על ידי פעולות redo ו undo.

בהנחה של ביצוע סדרתי ושל ערכים התחלתיים: A=$1000 B=$2000 C=$700 ערכים סופיים: A=$950 B=$2050 C=$600 דוגמא T0 : read (A) A=A-50 write(A) read(B) B=B+50 write(B) T1: read (C) C=C-100 write(C) LOG RECORDS <T0 , start> <T0 , A, 1000,950> <T0 , B, 2000,2050> <T0 , commit> <T1 , start> <T1 , C, 700,600> <T1 , commit>

ניהול החוצץ (buffer) • מסיבות של יעילות רצוי לרכז בחוצץ מספר עדכוני יומן, ולכותבם לזיכרון היציב יחד. • כדי לשמור על יכולת ההתאוששות ואטומיות הטרנזקציות יוטלו אילוצים נוספים על טכניקות ההתאוששות: • טרנזקציה Tiעוברת למצב commitרק לאחר שרשומת היומן <Ti commit> נכתבה לזיכרון היציב. • לפני שרשומת היומן <Ti commit> תיכתב לזיכרון היציב, כל רשומות היומן הקשורות לטרנזקציה Tiחייבות להיכתב לזיכרון היציב. • לפני שבלוק של מידע בזיכרון הראשי נכתב לבסיס הנתונים (דיסק), כל רשומות היומן הקשורות לנתוני המידע בבלוק, נכתבו לזיכרון היציב.

checkpoints במקרה של נפילת מערכת, על אילו טרנזקציות יש לבצע undo/redo? בעיקרון, יש לסרוק את כל היומן. חסרונות: • תהליך החיפוש מבזבז משאבים. • על פי האלגוריתם, על רוב הטרנזקציות נצטרך להפעיל redo, למרות שהן כבר כתבו את העדכונים שלהן לבסיס הנתונים - הארכה מיותרת של תהליך ההתאוששות.

checkpoints בנוסף לתחזוקת יומן כמתואר, (בשיטת העדכון המושהה או המיידי) המערכת מבצעת מידי פעם “ביקורת” checkpoint המחייבות את סדרת הפעולות הבאה: • כתוב את כל רשומות היומן הנמצאות בזיכרון הראשי לזיכרון/ אחסון יציב . • כתוב את כל הבלוקים המעודכנים שבחוצץ (buffer) על הזיכרון המשני. • כתוב רשומת יומן <checkpoint> לזיכרון /אחסון יציב.

Shadow paging - Basics דפים בזיכרון המשני טבלת דפים page table 1 2 3 4 5 n

Shadow paging הרעיון המרכזי: לתחזק שתי טבלאות דפים במהלך טרנזקציה: הטבלה הנוכחית current page tableוטבלת הצל shadow page table. בתחילת הטרנזקציה הטבלאות זהות. טבלת הצל אינה משתנה במהלך הטרנזקציה. הטבלה הנוכחית עשויה להשתנות עקב ביצוע פעולות כתיבה. כל פעולות ה inputוה outputמשתמשות בטבלה הנוכחית לאתר דפי בסיס נתונים על הזיכרון המשני.

shadow and current page tables דפים בזיכרון המשני shadow page table current page table 1 1 2 2 3 3 4 4 5 5 n n

shadow paging לעומת שיטות מבוססות יומן יתרונות shadow paging: • נחסכת העלות של כתיבת רשומות יומן. • התאוששות מהירה בהרבה, כיוון שאין צורך לבצעredo או undo. חסרונות shadow paging: • פרגמנטציה של הנתונים. • יצירת עמודי זבל (garbage) – יש להשתמש במנגנון של garbage collection. • מסובך הרבה יותר למימוש במערכות שבהן טרנזקציות מתבצעות בו זמנית.

Cascading Rollback במקרה של ביצוע בו זמני של טרנזקציה, התאוששות עלולה להביא לגלגול אחורנית של טרנזקצית אחדות: T1 T2 T3 read(A) read(B) write(A) read(A) write(A) read(A) read(C)

Recoverable Schedules הפרוטוקולים הבסיסיים לבקרת בו-זמניות עלולים ליצור תזמונים (בו-זמניים) שההתאוששות מהם אינה אפשרית. T4 T5 read(A) write(A) read(A) write(C) commit read(B)

סריקת יומן (Log Scanning) כאשר טרנזקציות מתבצעות בו זמנית, רשומת היומן של נקודת-הביקורת תהיה מהצורה <checkpoint, L> , כאשר Lהיא רשימה של כל הטרנזקציות הפעילות בזמן נקודת-הביקורת. בזמן ההתאוששות המערכת בונה שתי רשימות של טרנזקציות: undo-listו redo-listעל ידי סריקת היומן אחורנית עד ה checkpointהראשון שפוגשים: • לכל רשומת <Ti, commits> - מוסיפים את Tiל redo-list . • לכל רשומת <Ti, starts> - מוסיפים את Tiל undo-listאם Tiאינה שייכת ל redo-list . לאחר סריקת כל היומן, בודקים את L. כל כל טרנזקציה Tiב Lשאינה ב redo-listמוסיפים ל undo-list.

סריקת יומן - המשך תהליך ההתאוששות: 1. סורקים את היומן אחורנית ומבצעים undoלכל רשומת יומן השייכת לטרנזקציה Ti ב ל undo-list. 2. מאתרים את רשומת <checkpoint, L> האחרונה.ידי סריקת היומן אחורנית עד ה checkpointהראשון שפוגשים: 3. סורקים את היומן קדימה ומבצעים redoלכל רשומת יומן השייכת לטרנזקציה Ti בredo-list.

טיפול בנעילות מוות נעילת מוות (deadlock) - מערכת נמצאת בנעילת מוות אם קיימת קבוצה של טרנזקציות {T0,T1,…Tn} כך שT0 ממתינה לפריט מידע שמחזיקה T1, T1 ממתינה לפריט מידע שמחזיקה T2 … ו Tn ממתינה לפריט מידע שמחזיקה T0. גישות לטיפול בנעילת מוות • גילוי והתרה (detection & recovery) • מניעה (prevention)

גילוי של נעילות מוות והתרתן wait-for graphהוא גרף מכוון (G=(V,Eכאשר Vקבוצה של צמתים ו Eקבוצה של קשתות מכוונות. Vכוללת כל הטרנזקציות במערכת. קשת מכוונת מ Tiל Tjתהיה ב Eאם Tiמחכה לפריט מידע כלשהו המוחזק ע”י Tj. יש במערכת נעילת מוות אםם קיים מעגל מכוון ב wait-for-graph. התאוששות מנעילת מוות: • בחירת קורבן • גלגול אחורנית של ה”קורבן”

מניעה של נעילות מוות גישות למניעת נעילות מוות • נעילת כל פריטי המידע לפני תחילת הביצוע של הטרנזקציה • הגדרת סדר חלקי על פריטי המידע • הגדרת זכויות קדימה בין טרנזקציות ושימוש ב rollback :פרוטוקולי wait-die ו wound-wait

Wound-wait, Wait-die • כל טרנזקציה מקבלת חותמת זמן ייעודית (שונה מזו של בקרת בו זמניות) • טרנזקציה שומרת על חותמת הזמן המקורית שלה גם אם היא מגולגלת אחורנית. • נניח שטרנזקציה Tiמבקשת פריט מידע המוחזק על ידי Tj בנעילה לא קומפטיבילית: • wait-die: אם (TS(Ti) < TS(Tj (Ti זקנה יותר) Ti רשאית להמתין (wait) . אחרת Ti (צעירה יותר) מגולגלת אחורנית (die). • במילים פשוטות:רק טרנזקציות זקנות רשאיות להמתין לפריטי מידע נעולים. טרנזקציות צעירות אינן מורשות להמתין אלא הן מגולגלות אחורנית. • טרנזקציה עלולה "למות" מספר פעמים לפני שהיא מקבל פריט מידע מסוים • wound-wait: אם (TS(Ti) < TS(Tj (Ti זקנה יותר) Tj מגולגלת אחורנית (Ti פוגעת ב Tj) . אחרת Ti(צעירה יותר) מחכה (wait). • במילים פשוטות:טרנזקציות צעירות רשאיות להמתין לפריטי מידע נעולים. טרנזקציות זקנות המבקשות פריט מידע נעול גורמות לגלגול אחורנית של הטרנזקציה הצעירה המחזיקה אותו. • פרוטוקול פחות מועד לגלגולים מאשר wait-die

Wound-wait, Wait-die • הרעבה נמנעת כיוון שבשני הפרוטוקולים טרנזקציות שמגולגלות אחורנית שומרות על תגי הזמן המקוריים שלהן, ובסופו של דבר הופכות לזקנות ביותר, ובשלב זה תהיה להן אפשרות לסיים. • נעילות מוות נמנעות כיוון שהפרוטוקול אינו מאפשר מעגל של המתנות ב wait-for-graph • בwound-wait רק טרנזקציות צעירות יכולות להמתין לזקנות מהן • בwait-die רק טרנזקציות זקנות יכולות להמתין לצעירות מהן

התאוששות ( recovery )