ניטור גודל קבצי הלוג של בסיסי הנתונים וחשיבותו

חשוב לנטר את גודלם של קבצי הלוג של בסיסי הנתונים מהסיבות הבאות:

1. קובץ לוג הטראנזאקציות עלול להתמלא ולגרום לבעיות הבאות:
   1.1) טראנזאקציות עלולות להיכשל ולהיכנס לתהליך Roll Back.
   1.2) עלול לקחת לטראנזאקציות זמן ממושך להסתיים.
   1.3) עלולות להתרחש בעיות ביצועים.
   1.4) חסימות עלולות להתרחש.
2. קובץ הלוג עלול לצרוך את כל נפח הדיסק הפנוי ולאבן את המערכת.
3. קבצי לוג גדולים מדי מעידים לעיתים קרובות על העובדה שגיבויי לוג הטראנזאקציות לא התרחשו במשך זמן ממושך מדי על בסיס נתונים במוד Full Recovery.

אם אתה עד לגידול מהיר של קובץ הלוג, אלו הסיבות השכיחות ביותר לכך:

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

התרחישים נובעים בדרך כלל משתי סיבות:

1. אי הבנת מודי השחזור
   הימצאות במוד Full Recovery תוך כדי אי גיבוי לוגים היא הסיבה הנפוצה ביותר לגידול בלתי נשלט של קובץ הלוג.
   בשרת SQL יש שלושה מודי שחזור: מלא, Bulk Logged ופשוט. נתעלם במאמר זה מBulk Logged מכיוון שלרוב המשתמשים במצב זה יש סיבה מוצדקת לכך והם מבינים את מודי השחזור.
   מספר דברים חשובים שיש לדעת על קבצי לוג טראנזאקציות הם:
   1.1) קובץ לוג הטראנזאקציות קיים לצורכי התאוששות מנפילות ו/או אתחולים. כדי להמשיך ביצוע או לבצע Roll Back לטראנזאקציה שהחלה לפני התרסקות או אתחול אך לא הסתיימה בהצלחה. תפקיד לוג הטראנזאקציות לראות שטראנזאקציה החלה אך מעולם לא הסתיימה. במצב שזה התפקיד של היומן “לומר” “היי .. הטראנזאקציה לא הסתיימה, בוא נבצע Roll Back” במהלך התאוששות. תפקידו של הלוג הוא גם לראות שסיימת פעולה ומשהו והיישום בClient שלך קיבל אינדיקציה לסיומה (גם אם המידע עדיין לא הוקשח לקובץ הנתונים שלך) ו”לומר” “היי .. זה באמת קרה, בוא נמשיך את הטראנזאקציה עד הסוף ונגיע למצב עליו קיבל היישום אינדיקציה” לאחר הפעלה מחדש. קיימות גם מטרות נוספות, אבל זו המטרה העיקרית.1.2) מטרה אחרת לקובץ לוג הטראנזאקציות היא להיות מסוגל לתת לנו את היכולת לשחזר לנקודת זמן בשל תקלה במסד נתונים או כדי להבטיח נקודת שחזור במקרה של כשל חומרה בו מעורבים קבצי נתונים ו / או התחברויות למסד נתונים. אם קובץ לוג הטראנזאקציות מכיל רשומות של טראנזאקציות שכבר החלו והסתיימו לצורך התאוששות, SQL Server יכול לאחר מכן להשתמש במידע זה כדי להביא את מסד נתונים למצב בו היה לפני התרחשות התקלה אבל לא תמיד אפשרות זו זמינה עבורנו. כדי שזה יעבוד אנחנו צריכים שמסד הנתונים שלנו יהיה במוד השחזור הנכון וחובה עלינו לגבות את לוג הטראנזאקציות.

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

1. צרכי השחזור – במידה והכונן המחזיק את קובץ לוג הטראנזאקציות שלך מתקלקל, מידע של כמה זמן אתה יכול להרשות לעצמך לאבד? אם מדובר על 10 עד 15 דקות עליך לקבוע את תדירות גיבוי לוג הטראנזאקציות שלך לכל 10 עד 15 דקות, חד וחלק.
2. גידול קובץ לוג הטראנזאקציות – אם הארגון שלך יכול להרשות לעצמו לאבד נתונים ממשך זמן ממושך יותר, ייתכן שתספיק תדירות גיבויי לוג נמוכה בהרבה, כמו למשל פעם בארבע שעות, אך עליך לבחון כמה טראנזאקציות נוצרות במהלך ארבע שעות. האם גדילת קובץ לוג הטראנזאקציות במשך ארבע שעות לא תהפוך אותו לגדול מדי? האם משך הגיבוי לא יהיה ארוץ מדי? עליך לקחת זאת בחשבון.
3. טראנזאקציות ממושכות
   גם זו יכולה להיות סיבה לגידול בקובץ לוג הטראנזאקציות שלך, אפילו אם בסיס הנתונים נמצא במוד התאוששות Simple.

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

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

SELECT (size * 8.0)/1024.0 AS size_in_mb
, CASE
WHEN max_size = -1
THEN 9999999 -- Unlimited growth
ELSE (max_size * 8.0)/1024.0 END AS max_size_in_mb
FROM sys.database_files
WHERE data_space_id = 0

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