תופעות
שקול את התרחיש הבא:
-
יש לך טבלה הכוללת אינדקסים של columnstore באשכולות, והטבלה כוללת עמודות רבות (במאות).
-
הנתונים (סוג נתונים) של עמודות אלה הם נתונים דחוסה מאוד כגון varchar.
-
אתה מפעיל משפט select כנגד טבלה זו כדי לבחור קבוצת משנה גדולה או את כל העמודות מטבלה זו.
-
משפט select שלך כולל פסוקית where המגבילה את הפלט שלה לשורות מעטות ביותר (השאילתה בררנית מאוד).
בתרחיש זה, ייתכן שתיתקל באחת מהתופעות הבאות או בכולן:
-
עומס העבודה בו (שאילתות אחרות המופעלות באותו הזמן בשרת כשאילתה זו), עשויות להיתקל בירידה בביצועים ובאובדן התפוקה.
-
ייתכן שתראה שימוש לסירוגין ב-CPU גבוה.
-
אם אתה מבצע שאילתה על sys.dm_os_ring_buffers ומציג את הערכים של SchedulerMonitor type, אתה מוצא הודעות "מתזמן שאינו מניב" שנרשם בזמן ביצוע השאילתה.
-
ייתכן שתקבל שגיאת מתזמן שאינו מניב ביומן השגיאות וייתכן שייווצר קובץ dump של זיכרון סימפטום.
פתרון הבעיה
הבעיה נפתרה לראשונה בעדכון המצטבר הבא של SQL Server:
כל עדכון מצטבר חדש עבור SQL Server מכיל את כל התיקונים החמים ואת כל תיקוני האבטחה שנכללו בעדכון המצטבר הקודם. אנו ממליצים להוריד ולהתקין את העדכונים המצטברים האחרונים עבור SQL Server:
מידע נוסף
תיקון פרטיםהעובדים שמעבדים את מקטעי העמודות (מבטל את דחיסתם וסורקים אותם לקבלת שורות מוקדמות) משמשים לשימוש ב-"yield" של שימוש ב-CPU לעובדים אחרים/ביצוע שאילתות בו כאשר מספר סף מסוים של שורות היה פלט. כאשר המשפט where היה סלקטיבי מאוד להפקת כמה שורות, העובדים שמעבדים שאילתה זו מעבדים מספר לא דחוס וגדול של מקטעים (מכיוון ששורות מעטות מתאימה) לפני שמסרו את ה-CPU באופן שיתופי עבור עובדים אחרים לעבד את עומס העבודה שלהם. פעולה זו הובילה לשימוש קבוע ב-CPU והשפלה בתפוקה עבור עומס עבודה בו. התיקון ממטב ומשפר את אלגוריתם השיתוף של CPU עבור שאילתות columnstore מסוג זה.
הפניות
קבל מידע על המינוח שבו Microsoft משתמשת כדי לתאר עדכוני תוכנה.
