תקציר: שנת 2026 מתקרבת, וזה הזמן ליישר קו על SQL + Windows שמריצים PME.
בסיס נתונים שתופח פוגע בביצועים (Buffer Pool, TempDB, I/O) ובתחזוקה.
בפוסט הזה נציג למה כדאי לעצור סביב 6–7 שנים שמירה, איך זה משפר שאילתות ויציבות, ואילו צעדים פרקטיים ליישם כבר עכשיו—כולל אינדקסים/סטטיסטיקות ב‑SQL
ככל שבסיס הנתונים גדל, SQL Server מחזיק יותר דפים ב‑Buffer Pool, מפעיל יותר תחזוקה על סטטיסטיקות, ומבצע יותר I/O אקראי—מה שמאריך זמני תגובה ומגדיל לחץ על TempDB. זה נובע ממבנה ניהול הזיכרון של SQL שמטרתו לצמצם I/O אך מתקשה כשהנתונים חורגים מהיכולת המעשית של המערכת.
ראו ארכיטקטורת הזיכרון של Microsoft והשלכות עומס זיכרון/TempDB, וכן את ההשפעה של פירוק אינדקסים (fragmentation) על I/O וביצועים.
למידע נוסף:
SQL Server Memory Architecture (Microsoft),
Index Maintenance Best Practices (Microsoft)
ב‑PME (מסדי ION_*), שמירת נתונים ללא הגבלה מגדילה את ION_Data ופוגעת בביצועים של דוחות/חישובים ותחזוקה.
איזון טוב בין צרכים עסקיים/רגולטוריים לבין ביצועים הוא 6–7 שנים שמירה, עם משימות תחזוקה (Maintenance/Trim/Archive) מתוזמנות.
התהליכים הללו קיימים כברירת מחדל וניתנים להתאמה. במערכות SQL Express יש לעקוב בקפדנות אחרי מגבלת 10GB ולגזום אגרסיבית יותר.
ION_Data (Trim/Archive מתוזמנים; גיבוי לפני גיזום).בגרסאות מלאות של SQL אין “תקרה” ריאלית שתפגשו בשגרה; המגבלה היא ביצועים ועלות תחזוקה—not a hard cap. ב‑SQL Express קיימת מגבלת 10GB ועל כן חובה מדיניות Trim הדוקה.
PME Size Notification
ב‑PME מומלץ יומי כחלק מ‑Maintenance Tasks, כדי להבטיח תוכניות ביצוע מיטביות.
PME Planning
לקראת 2026, אימוץ מדיניות שמירה של 6–7 שנים ב‑PME לצד עדכון סטטיסטיקות יומי
רוצים בדיקת כשירות “Ready for 26” + תוכנית פעולה? צרו קשר