none
בעיה בגיבוי RRS feed

  • שאלה

  • אני בסביבת sql 2005 standard service pack 3

    מבצע גיבוי בצורה הזאת:

     BACKUP DATABASE db1
     TO DISK = '\\whatever\DatabaseBackups\db1.BAK'
        WITH INIT,
        NAME ='Backup data of db1',
        CHECKSUM

    ומקבל את השגיאה הבאה:

    BACKUP 'db1' detected an error on page (1:107675) in file 'D:\db1.MDF'.

    dbcc checkdb לא מחזיר שום אזהרה.

    כאשר אני מריץ את אותו משפט גיבוי רק בלי השימוש ב checksum הגיבוי מצליח.

    יש למישהו רעיון?

    יום חמישי 20 יוני 2013 13:28

תשובות

  • עוד דבר שהייתי מנסה  זה לבדוק את הpage  שמצוין בהודעה שקבלת.
    (אגב, האם תמיד מדובר באותו אחד? )

    המאמר הנ"ל מתאר איך ניתן להשתמש ב DBCC PAGE  על מנת לבדוק Page  חשוד...

    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/10/625659.aspx

    מקווה שעזרתי,
    נועם

    יום ראשון 23 יוני 2013 07:12
  • 1. אנא בדוק את התוכן של טבלת msdb..suspect_pages, התוכן של הטבלא יתן לך מושג טיפה יותר טוב מה מתרחש שם,ומה הבעייה, תוכל למצוא עוד מידע כאן: http://msdn.microsoft.com/en-us/library/ms191301(v=sql.90).aspx

    2. עפ"י BOL:

    CHECKSUM
    Specifies that the backup operation will verify each page for checksum and torn page, if enabled and available, and generate a checksum for the entire backup. This is the default behavior for a compressed backup.
    Using backup checksums may affect workload and backup throughput.

    כלומר עובר על כל הדפים.

    3. שוב, מה תוכן העמוד? נסה לבדוק ב suspect_pages ממתי החלה להופיע לך הבעייה, ותבדוק האם יש לך גיבוי מתקופה לפני כן - בהנחה והדף מכיל מידע היסטורי.

    4. תריץ dbcc checkdb (' dbname ') with physical_only, זה אמור לעלות על בעיות מסוג זה.

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


    אם עזרתי לכם, אשמח אם תצביעו כמועיל, בברכה, דן:)

    יום רביעי 03 יולי 2013 20:36
    • נערך על-ידי Noam Brezis יום רביעי 26 יוני 2013 20:18 edit
    • הוצע כתשובה על-ידי pituachMVP, Editor יום חמישי 27 יוני 2013 08:58
    • סומן כתשובה על-ידי Guy GlantserMVP, Moderator יום חמישי 15 אוגוסט 2013 18:23
    יום רביעי 26 יוני 2013 20:13
  • הי,

    ברזיס, ההסבר שצירפת הוא הסבר מצוין, אבל הוא עדיין לא מסביר לגמרי למה BACKUP WITH CHECKSUM מחזיר שגיאה, אבל DBCC CHECKDB לא מחזיר שגיאה. האפשרות היחידה שאני יכול לחשוב עליה (Paul Randal מזכיר אותה באחד מהפוסטים שלו שמוזכרים בלינק שצירפת), היא שכל זה קורה כחלק מ-Maintenance Plan, שבו קודם כל מבצעים גיבוי, אחרי זה בניה של כל האינדקסים, ורק אז מריצים DBCC CHECKDB. במצב כזה יתכן שהגיבוי נתקל ב-Corrupted Page ששייך לאחד האינדקסים, אבל אחרי בניה מחדש של האינדקס, ה-Page הזה כבר לא נמצא בשימוש, ואז DBCC CHECKDB בכלל לא בודק אותו. אבל אז הייתי מצפה שזה יקרה רק פעם אחת ולא יחזור על עצמו. נראה לי שבמקרה של VR-46, התופעה חוזרת על עצמה.

    VR-46, יש לי שתי שאלות אליך:

    1. יכול להיות שההסבר שנתתי כאן מתאים למקרה שלך?

    2. האם בדקת את ה-Page, כמו שנועם בנימיני הציע, והאם בדקת אם זה אותו Page כל פעם?

    תודה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום חמישי 27 יוני 2013 00:53
    מנחה דיון
  • שלום,

    אם אכן הבעיה היא בטבלאות system ( וכך נראה מהתיאור לעיל  ) - הפתרון היחידי הוא לבצע export של ה data  ל database  חדש.

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

    מקווה שעזרתי,
    נועם

    יום ראשון 07 יולי 2013 07:46
  • זו התשובה הרשמית של התמיכה ממיקרוסופט לכל המעוניין:

    -We can confirm that the database is corrupted, specifically, the pointed page

    -The reason DBCC checkdb didn´t reflect it is because this page doesn´t belong to any object. BDCC Behaviour is still under investigation by the product group to check if this is the expected behaviour or not

    -Our recommendation is to move to a non-corrupted database as soon as possible: to do so, use export and import wizard to create a new database with the same schema and data

    I will update you regarding the DBCC CHECKDB behavior

    יום ראשון 21 יולי 2013 12:01

כל התגובות

  • שלום,

    נשמע מוזר - אכן הייתי מצפה ש checkdb  יתן שגיאה כלשהי במצב כזה.

    האם השגיאה מתרחשת גם בגיבוי לדיסק מקומי ?

    האם תוכל להעתיק לכאן את תוצאות ה DBCC Checkdb ?

    נועם

    יום ראשון 23 יוני 2013 06:54
  • עוד דבר שהייתי מנסה  זה לבדוק את הpage  שמצוין בהודעה שקבלת.
    (אגב, האם תמיד מדובר באותו אחד? )

    המאמר הנ"ל מתאר איך ניתן להשתמש ב DBCC PAGE  על מנת לבדוק Page  חשוד...

    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/10/625659.aspx

    מקווה שעזרתי,
    נועם

    יום ראשון 23 יוני 2013 07:12
  • זו השורה התחתונה של dbcc checkdb:

    CHECKDB found 0 allocation errors and 0 consistency errors in database 'MyDb'.

    DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    גם בגיבוי לדיסק מקומי מתקבלת אותה השגיאה. רק בהורדת ה checksum הגיבוי מצליח.

    יום ראשון 23 יוני 2013 09:53
    • נערך על-ידי Noam Brezis יום רביעי 26 יוני 2013 20:18 edit
    • הוצע כתשובה על-ידי pituachMVP, Editor יום חמישי 27 יוני 2013 08:58
    • סומן כתשובה על-ידי Guy GlantserMVP, Moderator יום חמישי 15 אוגוסט 2013 18:23
    יום רביעי 26 יוני 2013 20:13
  • הי,

    ברזיס, ההסבר שצירפת הוא הסבר מצוין, אבל הוא עדיין לא מסביר לגמרי למה BACKUP WITH CHECKSUM מחזיר שגיאה, אבל DBCC CHECKDB לא מחזיר שגיאה. האפשרות היחידה שאני יכול לחשוב עליה (Paul Randal מזכיר אותה באחד מהפוסטים שלו שמוזכרים בלינק שצירפת), היא שכל זה קורה כחלק מ-Maintenance Plan, שבו קודם כל מבצעים גיבוי, אחרי זה בניה של כל האינדקסים, ורק אז מריצים DBCC CHECKDB. במצב כזה יתכן שהגיבוי נתקל ב-Corrupted Page ששייך לאחד האינדקסים, אבל אחרי בניה מחדש של האינדקס, ה-Page הזה כבר לא נמצא בשימוש, ואז DBCC CHECKDB בכלל לא בודק אותו. אבל אז הייתי מצפה שזה יקרה רק פעם אחת ולא יחזור על עצמו. נראה לי שבמקרה של VR-46, התופעה חוזרת על עצמה.

    VR-46, יש לי שתי שאלות אליך:

    1. יכול להיות שההסבר שנתתי כאן מתאים למקרה שלך?

    2. האם בדקת את ה-Page, כמו שנועם בנימיני הציע, והאם בדקת אם זה אותו Page כל פעם?

    תודה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום חמישי 27 יוני 2013 00:53
    מנחה דיון
  • אם אני מבין את הקישור שהביא נועם + הקישור מהקישור אז המשפט האחרון מסביר את הבעיה:

    DBCC CHECKDB only checks allocated pages it won't show inconsistencies in deallocated pages. The only situation I can imagine now is that BACKUP also backups those deallocated pages showing potential checksum errors that were skipped by DBCC CHECKDB.

    נשאלת אולי השאלה מדוע זה קורה והוא מנסה לענות עליה אבל זה נראה מקור העניין. ז"א ההבדל נובע בגלל deallocated pages שלא נבדקים בתהליך ה DBCC אבל כן בגיבוי.


    signature

    יום חמישי 27 יוני 2013 09:01
    מנחה דיון
  • הי,

    Deallocated Pages לא נבדקים בשום מקרה, לא במהלך גיבוי ולא במהלך הרצת DBCC CHECKDB. כך שזה לא מסביר את התופעה...

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום חמישי 27 יוני 2013 09:25
    מנחה דיון
  • קודם כל, תודה לכולכם על העזרה.

    דבר שני, זה תמיד אותו מספר page.

    לגבי סדר הדברים:

    כל לילה יש גיבוי מלא, כל שעה לוג.

    פעם בשבוע (בסופו של השבוע) יש בדיקת אינטגריטי. מיד אחריה יש index rebuild / reorganize.

    שאלה, אם אני אבצע שרינק לקובץ ה mdf, ועל ידי זה אני אשחרר ממנו מקום לא מנוצל, זה יוכל לפתור את הבעיה לדעתכם?

    יום ראשון 30 יוני 2013 10:35
  • הי,

    זה לא אמור לפתור את הבעיה, כי פעולת הכיווץ משחררת רק Deallocated Pages, וכאמור, ה-Page הבעייתי לא יכול להיות Deallocated, כי אם הוא היה, הוא לא היה נבדק בכלל. מצד שני, המקרה הזה מוזר, ואולי מדובר כאן בבאג, אז לך תדע...

    אתה יכול לבדוק את התוכן של ה-Page?

    תודה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום ראשון 30 יוני 2013 10:54
    מנחה דיון
  • האם ניסית DBCC Page ?

    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/10/625659.aspx

    תוכל לשתף אותנו בתוצאות?

    נועם

    יום ראשון 30 יוני 2013 15:05
  • 1. אנא בדוק את התוכן של טבלת msdb..suspect_pages, התוכן של הטבלא יתן לך מושג טיפה יותר טוב מה מתרחש שם,ומה הבעייה, תוכל למצוא עוד מידע כאן: http://msdn.microsoft.com/en-us/library/ms191301(v=sql.90).aspx

    2. עפ"י BOL:

    CHECKSUM
    Specifies that the backup operation will verify each page for checksum and torn page, if enabled and available, and generate a checksum for the entire backup. This is the default behavior for a compressed backup.
    Using backup checksums may affect workload and backup throughput.

    כלומר עובר על כל הדפים.

    3. שוב, מה תוכן העמוד? נסה לבדוק ב suspect_pages ממתי החלה להופיע לך הבעייה, ותבדוק האם יש לך גיבוי מתקופה לפני כן - בהנחה והדף מכיל מידע היסטורי.

    4. תריץ dbcc checkdb (' dbname ') with physical_only, זה אמור לעלות על בעיות מסוג זה.

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


    אם עזרתי לכם, אשמח אם תצביעו כמועיל, בברכה, דן:)

    יום רביעי 03 יולי 2013 20:36
  • טוב, קודם כל תודה לכל העוזרים.

    ועכשיו לעדכון (גיליתי כל מיני דברים אבל עדיין לא יצאתי מהבעיה):

    לאחר הורדת כל ה FK בבסיס הנתונים, יצרתי סקיפט שמריץ לולאה שבתוכה מבוצעת מחיקה של טבלה ולאחר מכן נסיון לביצוע גיבוי עם checksum. אף אחד מנסיונות הגיבוי לא צלח גם לאחר שלא נשארה אף טבלה (user table) בבסיס הנתונים. כלומר, הבעיה לא היתה בטבלאות / אינדקסים שלי. נותרתי עם בסיס נתונים ריק (מחקתי גם את כל הפונקציות / פרוצדורות וכו' מבסיס הנתונים).

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

    מה עוד:

    DBCC PAGE לא עוזר. אני לא יכול להגיע לשמות הטבלאות הדפוקות.

    זן התוצאה של select * from msdb..suspect_pages

    מה שעוד יותר מעניין הוא זה:

    כאשר אני מבצע גיבוי עם checksum, הוא נכשל. זו הבעיה המקורית. אבל, כאשר אני מבצע גיבוי עם checksum ובנוסף מציין NOFORMAT או CONTINUE_AFTER_ERROR אז הגיבוי מצליח אבל זו ההודעה שאני מקבל:

    Processed 3128 pages for database 'Austrelia', file 'Austrelia_Data' on file 1.
    100 percent processed.
    Processed 2 pages for database 'Austrelia', file 'Austrelia_Log' on file 1.
    BACKUP WITH CONTINUE_AFTER_ERROR successfully generated a backup of the damaged database. Refer to the SQL Server error log for information about the errors that were encountered.
    BACKUP DATABASE successfully processed 3130 pages in 11.108 seconds (2.307 MB/sec).

    דרך אגב, dbcc checkdb (' dbname ') with physical_only לא מעלה שום שגיאה.

    כמו כן, הרצתי select * על כל טבלאות הסיסטם ולא קיבלתי שגיאה באף select...

    מישהו? משהו? הצילו...


    • נערך על-ידי VR-46 יום ראשון 07 יולי 2013 07:37 עדכון
    יום ראשון 07 יולי 2013 06:39
  • שלום,

    אם אכן הבעיה היא בטבלאות system ( וכך נראה מהתיאור לעיל  ) - הפתרון היחידי הוא לבצע export של ה data  ל database  חדש.

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

    מקווה שעזרתי,
    נועם

    יום ראשון 07 יולי 2013 07:46
  • הי,

    אם אנחנו בעניין של ללמוד (ואני בעד ללמוד), אז חסרים לי עדיין שני דברים:

    1. מה מחזיר DBCC PAGE עבור הדפים הבעייתיים?

    2. מה מופיע ב-SQL Server Error Log אחרי הגיבוי עם CONTINUE_AFTER_ERROR?

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

    בהצלחה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il



    יום ראשון 07 יולי 2013 08:41
    מנחה דיון
  • dbcc page לפעמים מחזיר תשובה ולפעמים לא. תלוי בפרמטר האחרון שהוא מקבל. אבל אי אפשר ללמוד מהתשובות שלו הרבה במקרה הזה.

    זה מה שמופיע בלוג (שוב, אין יותר טבלאות משתמש ו select * מכל טבלאות הסיסטם עובר בהצלחה...) :

    07/07/2013 09:35:25,Backup,Unknown,Database backed up. Database: Austrelia<c/> creation date(time): 2013/07/03(14:23:11)<c/> pages dumped: 3231<c/> first LSN: 303714:14759:47<c/> last LSN: 303714:14779:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=DISK: {'E:\aus4.bak'}). This is an informational message only. No user action is required.
    07/07/2013 09:35:24,Backup,Unknown,BACKUP 'Austrelia' detected an error on page (1:107679) in file 'D:\Austrelia.MDF'.
    07/07/2013 09:35:24,Backup,Unknown,Error: 3043<c/> Severity: 16<c/> State: 1.
    07/07/2013 09:35:22,Backup,Unknown,BACKUP 'Austrelia' detected an error on page (1:107678) in file 'D:\Austrelia.MDF'.
    07/07/2013 09:35:22,Backup,Unknown,Error: 3043<c/> Severity: 16<c/> State: 1.
    07/07/2013 09:35:21,Backup,Unknown,BACKUP 'Austrelia' detected an error on page (1:107677) in file 'D:\Austrelia.MDF'.
    07/07/2013 09:35:21,Backup,Unknown,Error: 3043<c/> Severity: 16<c/> State: 1.
    07/07/2013 09:35:19,Backup,Unknown,BACKUP 'Austrelia' detected an error on page (1:107676) in file 'D:\Austrelia.MDF'.
    07/07/2013 09:35:19,Backup,Unknown,Error: 3043<c/> Severity: 16<c/> State: 1.
    07/07/2013 09:35:18,Backup,Unknown,BACKUP 'Austrelia' detected an error on page (1:107675) in file 'D:\Austrelia.MDF'.
    07/07/2013 09:35:18,Backup,Unknown,Error: 3043<c/> Severity: 16<c/> State: 1.

    בכל אופן פתחתי קריאה מול מיקרוסופט. מחכה לתשובה מהם.

    יום רביעי 10 יולי 2013 10:18
  • תודה על העדכון!

    נשמח לשמוע עדכונים בהמשך...

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום רביעי 10 יולי 2013 11:49
    מנחה דיון
  • זו התשובה הרשמית של התמיכה ממיקרוסופט לכל המעוניין:

    -We can confirm that the database is corrupted, specifically, the pointed page

    -The reason DBCC checkdb didn´t reflect it is because this page doesn´t belong to any object. BDCC Behaviour is still under investigation by the product group to check if this is the expected behaviour or not

    -Our recommendation is to move to a non-corrupted database as soon as possible: to do so, use export and import wizard to create a new database with the same schema and data

    I will update you regarding the DBCC CHECKDB behavior

    יום ראשון 21 יולי 2013 12:01
  • הי,

    תודה על העדכון!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום ראשון 21 יולי 2013 12:32
    מנחה דיון
  • אתה יכול לצרף לנו קישור ל CONNECT שפתחת?

    signature

    יום ראשון 21 יולי 2013 13:54
    מנחה דיון
  • זה היה מול התמיכה של מיקרוסופט. לא פתחתי Connect.
    יום שני 22 יולי 2013 05:01
  • הי,

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

    תודה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום שני 29 יולי 2013 05:53
    מנחה דיון