none
קובץ LDF מתנפח RRS feed

  • שאלה

  • שלום לכולם,

    יש לי בעיה שהיא די נפוצה.

    קובץ הLDF שלי מתנפח הרבה יותר מקובץ הMDF

    לדוגמא:

    MDF-500MB

    LDF- 30GB

    יש מקרים שבהם אפשר לצמצם את קובץ הלוג ע"י העברה של הDB למצב SIMPLE ב RECOVERY 

    ואז לבצע שרינק על קובץ הLDF

    האם השיטה הזו נכונה לצימצום הנפח של הLDF  ומה מפסידים כשמעבירים למצב SIMPLE?

    והאם יש עוד שיטות שלא כוללות שרינק?

    תודה מראש :)

    יום רביעי 16 מרץ 2016 14:35

כל התגובות

  • חד משמעית השיטה שלך לא נכונה וברור מהתיאור שלך שהאריכטקטורה של המערכת שלכם לא טובה

    הנה כמה נקודות למחשבה:

    > מה ההגיון מאחורי הרעיון להחזיק מסד נתונים במצב FULL?
    זו השאלה הכי חשובה! מה שאתה עושה מנוגד לחלוטין ושובר את כל השרשרת של הגיבויים (זה גם הנקודה המרכזית שעונה על השאלה "מה מפסידים כשמעבירים למצב SIMPLE"). אם לא הובן מפסידים את כל הסיבות שבשבילם בוחרים להחזיק את מסד הנתונים במצב FULL!

    > למה קובץ הלוג גדל?
    משהו גורם לקובץ לגדול... אם הוא גדל אז מה ימנע ממנו לגדול שוב? האם זה מקרה חד פעמי או תהליך קבוע של תחזוקה?

    > מה ההשלכה על הביצועים של תהליך "גדילת" הקובץ?
    ההשלכה ענקית דרך אגב

    > מה ההשלכה על הביצועים של תהליך הצימצום של הקובץ?!?
    * משהו שדרך אגב לא אמור להעשות

    > כיצד מנוהל קובת הלוג מאחורי הקלעים ומה קורה בכל פעם שהוא מתרחב או מצומצם???
    * אני מאוד ממליץ לחפש חומר על virtual log file (בקיצור נקרא VLF) ולהבין כיצד הקובץ מנוהל מאחורי הקלעים!
    * מומלץ על הדרך להבין מה ההלכה של מספר ה VLF ומה המנגנון שקובע כמה יתווספו בכל פעם או ימחקו.

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

    אז מה כן צריך לבצע?

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

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

    בניהול נכון קובץ הלוג לא משתנה (כמעט)

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

    3. להחליט על מודול הגיבוי הנכון לכם ולבחור נכון SIMPLE או FULL בהתאם לצורך.
    כלל הזהב שלי אומר שאם אתה לא יודע מה לבחור ו/או אין לך סיבה לעבוד עם FULL אז תבחר ב SIMPLE (לכן השם SIMPLE מתאים). במקרה שלכם בברור אין משמעות לעבודה במצב FULL 

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

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

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


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

    יום רביעי 16 מרץ 2016 17:15
    מנחה דיון
  • דרך אגב הגדלים שאתה מציג ניראים במבט ראשוני באמת אבסורדיים ומרמזים על אפשרות ניהול לא נכון של הגיבויים במצב FULL כניראה.

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

    * האם הגדרתם במקרה עבודה עם CDC?

    כאמור צריך להבין מה נכלל בקובץ, למה הוא גדל, למה הוא לא מתרוקן כדי להבין את שורש הבעיה

    מצאתי את הספר החינמי הבא (הספר לא בחינם אבל יש גירסה בחינם בקובץ PDF):
    https://www.red-gate.com/library/sql-server-transaction-log-management
    מאוד מומלץ!


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



    יום רביעי 16 מרץ 2016 17:29
    מנחה דיון