content top
מושחתים נמאסתם

מושחתים נמאסתם

במסגרת עבודתי כיועץ SQL קיבלתי פנייה לטפל בתקלה של בסיס נתונים לא תקין.  הסימפטום שבגינו פנה אלינו מנהל התשתיות של הלקוח היה כישלון עקבי בריצת תהליך התחזוקה השבועי.

כדי להבין את מהות התקלה בדקתי את ההיסטוריה של תהליך התחזוקה וגיליתי שהוא קורס בעקבות מספר רב של Inconsistencies במספר אינדקסים וטבלאות.

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

  1. הוחלף אחסון ומכונות וירטואליות הועברו מאחסון אחד לשני בעזרת VMWare V-Motion
  2. הוחלפה מערכת גיבוי.
  3. שודרגה האפליקציה

בדקתי וגיליתי שבהיסטוריה של ה Job יש מידע רק על חודש אחורה. באותו חודש כל הריצות של תהליך התחזוקה נכשלו.

בדיקה נוספת העלתה שללקוח אין גיבוי זמין של השרת ממועד מספיק רחוק שבו בסיס הנתונים היה תקין.  – הלקוח שמר על גיבויים למשך שבועיים בלבד.

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

כמו כן בסיס הנתונים הוא Publisher ברפליקציה בין שתי מערכות אפליקטיביות קריטיות בארגון.

 

בדיקות נוספות שבוצעו:

  1. פעולת גיבוי מלאה של בסיס הנתונים הצליחה ללא הערות.
    כמו כן ה SQL אפשר לשחזר את הגיבוי לבסיס נתונים בצד.
  2. ניסיתי לשכפל את הסכמה של בסיס הנתונים בעזרת Script generate Wizard והרצה של הסקריפט.
    בדיקה של Schema Compare בעזרת הכלי של Redgate הראתה שהסכמה הועתקה ללא שום שגיאות.
  3. ביצעתי ניסוי לבצע Export של הנתונים והטבלאות אל בסיס נתונים אחר. – לאחר ביטול של Check constraints ואיפשור לכתוב לשדות Identity הניסוי עבר בהצלחה לכל הטבלאות פרט לשתיים.
  4. הרצת DBCC CHECKDB הציגה את אותן התקלות גם על עותק משוחזר של בסיס הנתונים.
    הרצת DBCC CHECKDB with allow_data_Loss לא הצליחה לתקן את בסיס הנתונים גם אחרי מספר ריצות.
  5. לאחר מספר ניסיונות העתקה של נתונים משתי הטבלאות התקולות הצלחתי לזהות שכל התקלות מופיעות ברשומות שהוכנסו לבסיס הנתונים בין התאריכים שבהם בוצעה החלפת מערך האחסון.
    האחסון הוחלף תוך שימוש ב V-Motion . כאמור במהלך הזמן הזה ה VMWare ביצע את שכפול המידע עבור פעולת ה V-Motion .

פירוט התקלות שאובחנו ע"י DBCC CHECKDB


  • Table error: Object ID 1915153868, index ID 1, partition ID 72057596956704768, alloc unit ID 72057597190340608 (type In-row data). B-tree page (1:5972736) has two parent nodes (0:1), slot 0 and (1:13006617), slot 62.

התקלה מציגה נתון אשר לו הפנייה משני מקומות ב Clustered Index . התקלה מופיעה מספר רב של פעמים.

התקלות מסוג זה תוקנו בעזרת DBCC CHECKDB (DatabaseName,REPAIR_ALLOW_DATA_LOSS) .

 


  • Msg 8945, Level 16, State 1, Line 2
    Table error: Object ID 1915153868, index ID 1 will be rebuilt.

הודעה זו מציגה תקלה שלא ניתנת לתיקון בעזרת DBCC CHECKDB ב Clustered Index . הורדה של ה Clustered Index ובנייתו מחדש לא הייתה אפשרית.

 


  • Table error: Object ID 1972918100, index ID 1, partition ID 72057596969287680, alloc unit ID 72057594065780736 (type LOB data). The off-row data node at page (1:2040109), slot 2, text ID 522059776 is referenced by page (1:13005418), slot 11, but was not seen in the scan.

ההודעה מציגה תקלה במידע בשדה מסוג BLOB (Binary/Text) והיא הופיעה מספר פעמים .
משמעות התקלה היא שיש הפניה למידע בשדה אך המידע לא קיים ב Page הפיזי.  בניסיון לגשת אל הרשומות  הספציפיות בעזרת שאילתת SELECT ה SQL סגר את ה Connection . תקלה זו לא תוקנה ע"י DBCC CHECKDB (DatabaseName,REPAIR_ALLOW_DATA_LOSS) .

 

טיפים לאיתור מיקום התקלה:

Table error: Object ID 1972918100, index ID 1, partition ID 72057596969287680, alloc unit ID 72057594065780736 (type LOB data). The off-row data node at page (1:2040109), slot 2, text ID 522059776 is referenced by page (1:13005418), slot 11, but was not seen in the scan.

 

  1. כאשר יש Object ID בהודעה הוא בד"כ מפנה אל הטבלה בתקולה. יש אפשרות לקבל את שם הטבלה ע"י
    SELECT OBJECT_NAME ( object_id [, database_id ] )
  2. index ID 1 מצביע על ה CLUSTERED INDEX .
  3. נתונים נוספים על ה Page התקול אפשר לקבל בעזרת פקודת DBCC PAGE המובאת לדוגמה בשאילתה הבאה:

DBCC TRACEON (3604);

DBCC PAGE (<db_id>, 1, 2040109, 3);

DBCC TRACEOFF (3604);

GO

תוכנית עבודה לתיקון התקלה:

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

בסוף התהליך נדרש לייצר מחדש את הרפליקציה אשר משתמשת בבסיס הנתונים כ Publisher.

להלן פירוט השלבים בתהליך:

  1. הורדת האפליקציה כדי שמידע לא יוכנס למערכת תוך כדי התהליך.
  2. יצוא סקריפטים לבניית הרפליקציה.
  3. יצוא סקריפטים לבניית הסכמה של בסיס הנתונים.
  4. בניית בסיס נתונים מקביל בעזרת הסקריפט ליצירת סכמה (משלב 3)
  5. העברת המידע מכל הטבלאות התקינות בבסיס הנתונים הישן לחדש בעזרת Export Data wizard כולל הגדרה לאפשר עדכון Identity וביטול בדיקה של Check constraints .
  6. העתקת הנתונים מהטבלאות הפגומות בעזרת פקודות INSERT INTO SELECT FROM תוך סינון הנתונים מהתאריכים התקולים.
  7. בדיקת בסיס הנתונים החדש בעזרת DBCC CHECKDB וקבלת אישור שהוא תקין.
  8. מחיקת הרפליקציה מבסיס הנתונים התקול.
  9. החלפת שם בסיס הנתונים התקול ושינוי שם בסיס הנתונים החדש שיחליף את הישן.(ביצוע הצרחה בין בסיסי הנתונים)
  10. בניית הרפלקציות מבסיס הנתונים החדש אל מערכות ארגוניות.
  11. בדיקת הרפלקציות ווידוא תקינות
  12. העלאת האפליקציה וביצוע בדיקות
  13. פתיחת המערכת לגישת משתמשים.

 

מסקנות בעקבות התקלה:

  1. לפני מהלכים קריטיים של החלפת אחסון \ החלפת מערכת גיבוי נדרש לבצע גיבוי של בסיסי הנתונים ושמירה של הגיבוי באופן שבו הגיבוי יהיה זמין.
    – מומלץ לבצע גם ניסוי שחזור כדי לוודא שקובץ הגיבוי תקין.
  2. שינויים תשתיתיים כגון החלפת סטוראג' מומלץ לבצע כשה SQL לא פעיל אלא במקרים בהם ספק החומרה מתחייב שהתהליך נתמך.
  3. לא לבצע מספר שינויים קריטיים לאותה מערכת אחד אחרי השני.
  4. לבצע לאחר כל שינוי קריטי בדיקות ומעקב לאורך זמן לפני שפונים לשינוי הבא על אותה מערכת.

 

קישורים למידע שימושי:

How to use DBCC PAGE
Finding a table name from a page ID
DBCC CHECKDB – Use and Abuse


3 תגובות על “מושחתים נמאסתם”

  1. מאת יוסי:

    אחלה מאמר,
    לצערי יש לא מעט אירגונים שיש להם בלאגן כזה.
    לגבי התיקון, יש לי רק הערה אחת.
    נתקלתי במקרים שבאמת לא היה גיבוי לDB, אבל היה גיבוי של המכונה הוירטואלית, שווה לבדוק אם יש גם כזה.

  2. מאת נירה:

    תודה על ההסבר המפורט.

  3. יוסי שלום
    לגבי" היה גיבוי של המכונה הוירטואלית" עוד תובנות :
    אם זה HYPERV , צ"ל שהגיבוי של המכונה הוירטואלית רץ אחרי הגיבוי הרגיל של MSSQL כדי שהגיבוי יהיה קונסיסטנטי .
    גם אז השליפה של מחיצת הגיבויים היא בעייתית , כי צריך לחבר את ה LUN לשרת אחר ולשלוף את הגיבוים . אי אפשר לחבר את דיסק הגיבוי לאותו שרת , כי יהיה 2 דיסקים עם אותו ID

    זה מהניסיון שלי אם הגיבוי של המכונה הוירטואלית נעשה עם Snap Manager For Hyper V .

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

twenty + seventeen =