none
SQL Server 2016 SP1 Error:9002 Severity:17 state:1. The transaction log for database 'x' is full due to CHECKPOINT

    שאלה

  • אני מנסה להגדיל ידנית את קובץ הלוג או באמצעות פקודה ולא מצליחה - מקבלת את הודעת השגיאה הנ"ל.

    מבחינת הגדרות הקובץ הוא יכול לגדול עד 2097152 MB ויש מקום על הדיסק.

    מסד הנתונים ב- 'simple'.

    I try to make the log file bigger manually or with a command but I get the 9002 error.

    The log file size is limited to 2097152 MB and there is enough space on disk.

    The recovery model is Simple.







    • נערך על-ידי gnira יום ראשון 07 ינואר 2018 06:59
    יום חמישי 04 ינואר 2018 16:35

כל התגובות

  • כיצד ניסית להגדיל את הקובץ?

    האם ניסית להריץ שאילתה מתאימה או אתה עובד עם ה GUI?

    מה הודעת השגיאה המדוייקת והמלאה שאתה מקבל



    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום שלישי 09 ינואר 2018 02:02
    מנחה דיון
  • רונן תודה רבה.

    אני ניסיתי להגדיל את הקובץ גם עי הפקודה ALTER DATABASE וגם ע"י ה- gui.

    הודעת השגיאה:

    Error: 9002 Severity: 17 state: 1

    The transaction log for database 'X ' is full due to 'CHECKPOINT'

    Could not write a checkpoint record in database X because the log is out of space. Contact the database administrator to truncate the log or allocate more space to the database log files

    יום שלישי 09 ינואר 2018 14:45
  • רונן תודה רבה.

    אני ניסיתי להגדיל את הקובץ גם עי הפקודה ALTER DATABASE וגם ע"י ה- gui.

    הודעת השגיאה:

    Error: 9002 Severity: 17 state: 1

    The transaction log for database 'X ' is full due to 'CHECKPOINT'

    Could not write a checkpoint record in database X because the log is out of space. Contact the database administrator to truncate the log or allocate more space to the database log files

    היי,

    בעתיד תמיד צריך לצרף את הודעת השגיאה המלאה כפי שסיפקת לנו כרגע, אבל עדיין לא סיפקת את השאילתה המדוייקת שמחמזירה את השגיאה. למה לקצר כמה אלפיות שנייה של העתקת השאילתה להודעה בכך שאתה מנסה לספק מידע חלקי כמו למשל "אני ניסיתי להגדיל את הקובץ גם עי הפקודה ALTER DATABASE". היכן השאילתה וכיצד בדיוק הפעלת את הפקודה? איזה פרמטרים הפעלת וכו'

    בכל מקרה במקרה הנוכחי מדובר בשגיאה ידועה ומוכרת :-)

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

    0. תחילה נסה לפנות בדיסק

    1. לפני הכל בצע גיבוי מלא של מסד הנתונים! אני מקווה שלא הגעת למצב שאין מקום בלוג גם לביצוע הגיבוי שכולל פעולת CHECKPOINT 

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

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

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

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

    4. עבור למצב EMERGENCY ונסה לבצע CHECKPOINT - זה אמור להצליח

    אם הצלחת להריץ CHECKPOINT אז אתה יכול לנסות שוב לקבוע את הגודל של קובץ הלוג

    צרף לנו את השאילתה המדוייקת שאתה מנסה להריץ!

    * קבע גודל מקסימלי סביר ולא ברירת המחדל של המקסימום וקבע גידול אוטומטי של ערך קבוע ולא באחוזים

    עבור לעומק על המדריך הבא מהדויומנטציה הרשמית לגבי הבעיה:
    https://docs.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002

    וכמובן דווח לנו את הפעולות הצליחו או אם צריך לעבור לשלב הבא :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]



    יום שלישי 09 ינואר 2018 22:08
    מנחה דיון
  • רונן תודה רבה.

    הפעלת השאילתא ב- SSMS ב- QUERY:

    USE MASTER

    ALTER DATABASE [X] MODIFY FILE ( NAME = N'X_log', MAXSIZE = 30GB)

    GO

    הודעת השגיאה:

    msg 9002, level 17, state 1, line 3 

    The transaction log for database 'X' is full due to 'CHECKPOINT'

    0. יש מספיק מקום פנוי על הדיסק.

    1. גיבוי מלא נכשל עם הודעה:

    Failed executing the query "BACKUP DATABASE [X] TO DISK=N'...'" failed with the following error: "Could not clear 'DIFFERENTIAL' bitmap in database 'X' because of error 9002

    2. ביצוע הפקודה CHECKPOINT נכשל עם הודעה:

    Msg 5901, Level 16, State 1, Line 1

    One or more recovery units belonging to database 'X' failed to generate a checkpoint. This is typically caused by lack of system resources such as disk or memory, or in some cases due to database corruption. Examine previous entries in the error log for more detailed information on this failure.

    Msg 9002, Level 17, state 1, Line 1

    The transaction log for database 'X' is full due to 'CHECKPOINT'

    Msg 9002, Level 17, State 1, Line

    4. מעבר למצב EMERGENCY וביצוע CHECKPOINT הצליח.

    חזרה ל- ONLINE נכשל עם הודעת שגיאה 9002.

    

    יום רביעי 10 ינואר 2018 13:41
  • משום מה נראה ששכחת שלב 3 שהוא החלק הכי חשוב שרשמתי בצורה מודגשת  - גיבוי! גיבוי! גיבוי!

    אם איןו לך גיבוי אז כל אסור היה לך להמשיך לשלב הבא!

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]


    יום רביעי 10 ינואר 2018 15:06
    מנחה דיון
  • שלום רונן,

    שלב 1 היה ניסיון לבצע גיבוי מלא של מסד הנתונים. הגיבוי נכשל עם הודעת השגיאה שכתבתי בתגובה הקודמת.

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

    המטרה שלשמה העליתי את השאלה:

    א. האם אפשר לתקן מסד נתונים תקול עם שגיאה 9002.

    ב. האם זו בעיה מוכרת של SQL Server 2016.

    קראתי מאמרים בנושא מניעת שגיאה 9002 - לא מצאתי משהו שיכולתי ליישם במקרה הנ"ל.

    יום רביעי 10 ינואר 2018 15:23
  • היי

    לפי מה שאני מבין אתה החלטת לדלג לחלוטין על שלב 3 שהדגשתי לבצע וגם לוודא שהוא בוצע טוב, והחלטת לקפוץ לשלב 4 משום מה :-(

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

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

    אתה לא יכול להחליט מה לבצע מתוך מסלול של פעולות ומה לא לבצע. אתה שובר את כל המסלול לפתרון ויכול ליצור מצב הרבה יותר מורכב בצורה כזו!

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

    עכשיו אני חושש שכל מה שאני אציע יבצע באופן שרירותי וחלקי ולא הייתי רוצה שתחריף את המצב :-(

    -----------

    >> א. האם אפשר לתקן מסד נתונים תקול עם שגיאה 9002.

    בדרך כלל כן. לא נתקלתי עד היום בבמקרה שהתשובה היתה לא, כמובן אם עובדים מסודר

    * לעיתים יש איבוד מידע אבל בדרך כלל לא אמורה להיות בעיה. כמובן שאת כל המשחקים צריך לבצע עם הגיבוי בשרת שנועד למשחקים ולא בשרת החי

    >> ב. האם זו בעיה מוכרת של SQL Server 2016.

    זו בעיה שיכולה לצוץ בכל גרסה אני מניח.

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

    אני מניח שזה אומר איבוד מידע, השאלה אם אתה כיול "לספוג" את איבוד המידע או צריך להעמיק בפתרון ?

    המשך עבודה חייב להעעשות בססיבת בדיקות ולא בשרת החי !!!!

    המשך עבודה חייב להעעשות בססיבת בדיקות ולא בשרת החי !!!!

    המשך עבודה חייב להעעשות בססיבת בדיקות ולא בשרת החי !!!!

    וכדי להדגיש את הנושא...

    המשך עבודה חייב להעעשות בססיבת בדיקות ולא בשרת החי !!!!

    המשך עבודה חייב להעעשות בססיבת בדיקות ולא בשרת החי !!!!

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

    יוצרים מסד נתונים חדש עם אותו שם והגדרות גודל מתאימות -> סוגרים את השרת -> מעתיקים את הקבצים הישנים ודורסים את הקבצים החדשים שהם ריקים בעזרת הקבצים מהגיבוי -> מפעילים את השרת ובודקים את הכל תקין. רק אם הכל תקין אז אפשר לבצע גיבוי של מסד הנתונים מהשרת הבדיקות ולחזר לשרת החי רק אחרי בדיקות שהכל תקין ב 100%.



    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום חמישי 11 ינואר 2018 04:46
    מנחה דיון
  • אני לא אמליץ לך מה לעשות וכמובן שאף אחד בפורום לא יקח אחריות על כלום כאשר אין לנו כמובן מידע שלם על המצב אלא רק התיאורים שלך, ויותר ממכך העניין שאתה עלול לבצע את הדברים בצורה לקויה. כמובן וכל מה שאתה עושה על אחריותך, אז אני אגיד פשוט מה אני הייתי עושה ככל הנראה במקרה דומה אם לא היהי לי מידע נוסף :-)

    > בשלב זה אולי כדאי לבדוק מה הנזק שיש במסד הנתונים אם יש כזה בעזרת DBCC

    * מכיוון שאין לך גיבוי עדכני אל תמהר להגדיר את הפקודה עם האפשרות לאיבוד מידע

    > אני לא יכול להמליץ אבל אפשר לנסות את הפעלה שהזכרתי מעל:
    https://www.sqlskills.com/blogs/paul/disaster-recovery-101-hack-attach-a-damaged-database/

    > ואם אין ברירה, אז מכיוון שמסד הנתונים במצב simple אני יכול להניח כניראה שהמידע בקובץ הלוג כולל בעיקר טרנזקציות פתוחות, CDC וכו' ואין בו הרבה מידע שיכולים לאבד. כמובן שרק מי שמכיר את מסד הנתונים יכול להניח מה קורה בו, אבל אם ההנחה נכונה, אז אולי אפשר לנסות לבצע פעולה פשוטה של שחזור מסד הנתונים ללא קובץ הלוג - מה שיוצר קובץ לוג חדש. אם הכל מצליח כמצופה אז אנחנו יכולים פשוט להמשיך לעבוד עם מסד הנתונים החדש (במקרה כזה אפשר לבצע detach ואז ליצור את המסד החדש אבל!!!! פעולת detach למסד במצב EMERGENCY לא יאפשר לבצע חיבור למסד הנתונים ככל הנראה ישירות ביחד עם קובץ הלוג ולכן זה משהו שחייב להילקח בחשבון ואני לא יכול להמליץ עליו כמובן)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]





    יום חמישי 11 ינואר 2018 04:53
    מנחה דיון
  • שלום רונן,

    תודה רבה על הסיוע.

    מבדיקות מקיפות עולה שהשרת לא תקין.

    ושוב תודה רבה.

    נירה

    יום חמישי 11 ינואר 2018 10:00
  • לא ברור לי מה הכוונה שהשרת לא תקין וכיצד הגעת למסקנה?

    אולי את מתכוונת שמסד הנתונים לא תקין?
    זה יותר סביר במקרה שתיארת כאן

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

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

    אני ממליץ לא למהר להספיד מסדי נתונים :-)
    כמובן ששחזור מסד נתונים בהגיע לרמת נזק גדולה יכול להיות יקר מדי ובדרך כלל בשביל זה יש לנו גיבויים

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום חמישי 11 ינואר 2018 12:39
    מנחה דיון