none
לוג מתנפח - SOS RRS feed

  • שאלה

  • בשרת הרפליקציה (TRANSACTIONAL REP)

    יש לוג שתופס כבר 500G!!!

    הבסיס נתונים בSIMPALE MODE

    ואן טרנסקציות פתוחות.


    שאני מריץ:

    DBCC OPENTRAN;

    מקבל:

    No active open transactions.
    DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    מה עושים?

    יום חמישי 29 ינואר 2015 09:53

תשובות

  • שבת שלום,

    לפני הכל אני חייב להגיד שמשהו נשמע לחלוטין לא הגיוני בתיאור שלך. אתה נמצא ב FULL ומבצע גיבוי בכל פעם ל 500G?!?

    בכל מקרה נקודת מפתח חשובה היא להבין ש truncated של הנתונים מהלוג מבוצע רק כאשר יש פעולה של checkpoint וגם כאשר כל הנתונים שסומנו כ replication עובדו וסומנו בהתאם (בדרך כלל FULL מתאים הרבה יותר למסדי נתונים גדולים ולדעתי גם הרבה יותר מתאים לרפליקציה, ולמרות שאין שום מניעה לרפליקציה במצב SIMPLE).

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

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

    * אני מציע לקרוא על נושא ניהול הקבצים הוירטואליים בקובץ הלוג, אם דיברתי סינית עד כה :-)

    מה השלב הבא אם כן (זה לחא ממש עבודה מסודרת אלא מהזכרון פעולות שצריך לנטר)?

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

    select name,log_reuse_wait_desc from sys.databases
    GO

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

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

    אתה יכול לקרוא יותר על האפרויות השונות בקישור הבא: https://technet.microsoft.com/en-us/library/ms345414.aspx

    2. נעבור למסד נתונים הבעייתי עתה בעזר USE ונריץ את השאילתה הבאה כדי לבדוק את מצב הקבצים הוירטואלים של מסד הנתונים

    DBCC LOGINFO 
    GO

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

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

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

    4. בדוק כמה מקום באמת תופס קובץ הלוג שלך, וכמה מקום פנוי

    dbcc SQLperf(logspace)
    GO

    5. כמו שאמרת צריך כמובן גם לבדוק שטרנזקציות פתוחות:

    DBCC OPENTRAN  WITH TABLERESULTS

    6. בלב אחרון אם מוצאים בעיות אפשר תמיד לחקור את קובת הלוג עם fn_dblog

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

    ++++++++ מידע נוסף ++++++

    כדאי לעבור על המדריך הבא: http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/

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


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




    • נערך על-ידי pituachMVP, Editor שבת 31 ינואר 2015 15:26
    • סומן כתשובה על-ידי Yossi Drori יום ראשון 01 פברואר 2015 14:05
    שבת 31 ינואר 2015 14:54
    מנחה דיון

כל התגובות

  • זה שרת המקור או היעד שמתנפח?
    יום חמישי 29 ינואר 2015 10:00
  • יעד 
    יום חמישי 29 ינואר 2015 10:02
  • אם אתה עושה SHRINK זה עובד לך?
    יום חמישי 29 ינואר 2015 11:35
  • שבת שלום,

    לפני הכל אני חייב להגיד שמשהו נשמע לחלוטין לא הגיוני בתיאור שלך. אתה נמצא ב FULL ומבצע גיבוי בכל פעם ל 500G?!?

    בכל מקרה נקודת מפתח חשובה היא להבין ש truncated של הנתונים מהלוג מבוצע רק כאשר יש פעולה של checkpoint וגם כאשר כל הנתונים שסומנו כ replication עובדו וסומנו בהתאם (בדרך כלל FULL מתאים הרבה יותר למסדי נתונים גדולים ולדעתי גם הרבה יותר מתאים לרפליקציה, ולמרות שאין שום מניעה לרפליקציה במצב SIMPLE).

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

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

    * אני מציע לקרוא על נושא ניהול הקבצים הוירטואליים בקובץ הלוג, אם דיברתי סינית עד כה :-)

    מה השלב הבא אם כן (זה לחא ממש עבודה מסודרת אלא מהזכרון פעולות שצריך לנטר)?

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

    select name,log_reuse_wait_desc from sys.databases
    GO

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

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

    אתה יכול לקרוא יותר על האפרויות השונות בקישור הבא: https://technet.microsoft.com/en-us/library/ms345414.aspx

    2. נעבור למסד נתונים הבעייתי עתה בעזר USE ונריץ את השאילתה הבאה כדי לבדוק את מצב הקבצים הוירטואלים של מסד הנתונים

    DBCC LOGINFO 
    GO

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

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

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

    4. בדוק כמה מקום באמת תופס קובץ הלוג שלך, וכמה מקום פנוי

    dbcc SQLperf(logspace)
    GO

    5. כמו שאמרת צריך כמובן גם לבדוק שטרנזקציות פתוחות:

    DBCC OPENTRAN  WITH TABLERESULTS

    6. בלב אחרון אם מוצאים בעיות אפשר תמיד לחקור את קובת הלוג עם fn_dblog

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

    ++++++++ מידע נוסף ++++++

    כדאי לעבור על המדריך הבא: http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/

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


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




    • נערך על-ידי pituachMVP, Editor שבת 31 ינואר 2015 15:26
    • סומן כתשובה על-ידי Yossi Drori יום ראשון 01 פברואר 2015 14:05
    שבת 31 ינואר 2015 14:54
    מנחה דיון