none
לגבי Autgrow עבור LDF/MDF RRS feed

  • שאלה

  • שלום,

    אשמח להמלצה לגבי בסיס נתונים ב SQL Server שגודל קובץ ה MDF שלו הוא 8GB וקובץ ה LDF  הוא 110MB

    ה Authogrow המעודכן עבור בסיס נתונים זה הוא : MDF 300MB ,  LDF 10%

    מה דעתכם על גודל ה LDF והאם כדאי לעשות לו shrink ?

    מה דעתכם על ה Authgrow עבור שני הקבצים - האם יש לשנות אותו?

    אשמח לכל דעה! תודה מראש!

    יום רביעי 26 פברואר 2014 09:52

תשובות

  • צהריים טובים,

    כמה נקודות שיכולות לכוון אותך:

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

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

    2. קביעת 10% או 50% לגדילה של קובץ הלוג שהגודל שלו 100MB גורר שבכל הגדלה של הקובץ שלך יתווספו לך 4 קבצים וירטואליים, אם תעבור לגדילה של 64% בדיוק אז תקבל התנהגות שונה לחוטין ובכל גדילה יתווספו לך 8 קבצים וירטואליים... שוב כדאי להבין את הדברים אחורי הקלעים.

    אתה יכול לעבור על הבלוג הקצרצר הבא כהתחלה:
    http://ariely.info/Blog/tabid/83/EntryId/130/Transaction-Log-File-Structure.aspx

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


    [Personal Site] [Blog] [Facebook]signature

    יום רביעי 26 פברואר 2014 11:50
    מנחה דיון
  • שלום,

    נתון חשוב ביותר שצריך לבדוק לפני שמתחילים לדון בשאלתך  - מה ה Recovery Model ?

    http://msdn.microsoft.com/en-us/library/ms189275.aspx

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

    נתון נוסף שכדאי לבדוק לפני שניגשים ל Shrink  הוא כמה מהשטח שהוקצה ללוג בשימוש
    DBCC SQLPERF(logspace)  - יתן לך את המידע הנ"ל

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

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

    • הוצע כתשובה על-ידי Eran Sharvit יום שלישי 04 מרץ 2014 10:09
    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 09 מרץ 2014 09:46
    יום רביעי 26 פברואר 2014 10:46

כל התגובות

  • שלום,

    נתון חשוב ביותר שצריך לבדוק לפני שמתחילים לדון בשאלתך  - מה ה Recovery Model ?

    http://msdn.microsoft.com/en-us/library/ms189275.aspx

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

    נתון נוסף שכדאי לבדוק לפני שניגשים ל Shrink  הוא כמה מהשטח שהוקצה ללוג בשימוש
    DBCC SQLPERF(logspace)  - יתן לך את המידע הנ"ל

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

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

    • הוצע כתשובה על-ידי Eran Sharvit יום שלישי 04 מרץ 2014 10:09
    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 09 מרץ 2014 09:46
    יום רביעי 26 פברואר 2014 10:46
  • צהריים טובים,

    כמה נקודות שיכולות לכוון אותך:

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

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

    2. קביעת 10% או 50% לגדילה של קובץ הלוג שהגודל שלו 100MB גורר שבכל הגדלה של הקובץ שלך יתווספו לך 4 קבצים וירטואליים, אם תעבור לגדילה של 64% בדיוק אז תקבל התנהגות שונה לחוטין ובכל גדילה יתווספו לך 8 קבצים וירטואליים... שוב כדאי להבין את הדברים אחורי הקלעים.

    אתה יכול לעבור על הבלוג הקצרצר הבא כהתחלה:
    http://ariely.info/Blog/tabid/83/EntryId/130/Transaction-Log-File-Structure.aspx

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


    [Personal Site] [Blog] [Facebook]signature

    יום רביעי 26 פברואר 2014 11:50
    מנחה דיון
  • תודה רבה,

    נועם, לגבי  shrink בדקתי את השימוש בלוג DBCC SQLPERF(logspace)

    אז בבסיס נתונים עם MDF של 110MB (קובץ MDF 7. GB) התוצאה הייתה:

    Log space used 11%

    מה דעתך? האם shrink חד פעמי ל LDF יפתור את הבעיה?

    בנוסף, איזו אינדיקציה נותת התוצאה של 11%, איך מסתכלים על זה..

    תודה רבה

    DBCC SQLPERF(logspace)

    יום ראשון 02 מרץ 2014 13:15
  • שיחה אישית לימור עם נועם :-), או שם לנו מותר לעזור?

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


    [Personal Site] [Blog] [Facebook]signature

    יום ראשון 02 מרץ 2014 23:50
    מנחה דיון
  • אשמח לתשובות ממי שיכול כמובן,

    ואכן התייחסתי לתשובתך, אך אשמח לתשובה לגבי ה Shrink אם יתבצע חד פעמית או פעם בחודשיים ללוגים הבעייתיים?

    תודה

    יום שני 03 מרץ 2014 07:28
  • 1. לימור התייחסת רק לנועם בתגובה שלך, ודיי ברור מהשאלה שאת עדיין לא הפנמת את העניין עליו כתבתי

    2. התשובה לגבי הכיווץ נתנה לך כבר מההתחלה (ההודעה שנועם הציע כתשובה)... :-(
    כלום לא השתנה בשרת בשבוע האחרון :-)

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

    התשובה היא חד משמעית לגבי ביצוע פעולה כזו כפעולה קבועה!

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

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


    [Personal Site] [Blog] [Facebook]signature

    יום שני 03 מרץ 2014 11:15
    מנחה דיון
  • אשמח לתשובות ממי שיכול כמובן,

    ואכן התייחסתי לתשובתך, אך אשמח לתשובה לגבי ה Shrink אם יתבצע חד פעמית או פעם בחודשיים ללוגים הבעייתיים?

    תודה

    היי לימור,

    כמו שרונן עומר, אין באמת דבר כזה "לוג בעיתי". את מנסה לפתור את הבעיה הלא נכונה. הלוג גדל על לגודל מסויים מסיבה מסויימת. יש פה כמה אפשרויות:

    1) אם הוא ממשיך לגדול לנצח, אז את לא מנהלת אותו נכון, כלומר לא מגבה אותו.

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

    3) לפי איך שהתרשמתי ממך, את חושבת שיש קשר ישיר בין גודל MDF וגודל ב-LDF וזה ממש לא נכון. גודל הלוג בעיקר קשור לאופן הפעילות המתבצעת מול DB, לכן יחס MDF/LDF יכול להיות לגמרי שונה וזה לגיטימי. 

    יום שני 03 מרץ 2014 14:07