אם אתם עובדים עם SQL Server בסביבת production, אתם צריכים לעקוב אחרי רשימת ה- CU שמתפרסמים. אם אתם DBA-ים, אז כנראה שזה לא מחדש עבורכם (אני מקווה…). אם, לעומת זאת, אתם מפתחים שיוצא להם לעבוד עם אפליקציה מבוססת DB, ואתם אלה “שחיים” את האפליקציה, פותרים בעיות שצצות בה (גם ברמת התחזוקה), ומתמודדים עם נושאים לכל רוחב הגזרה (כולל דטאבייסים) – אז אולי אתם לא יודעים שקיים כזה דבר, וחבל.
ב- SQL Server (כאשר אני מדבר על גרסת ה- on-prem, ולא על SQL Azure)– מיקרוסופט מוציאה גרסא עיקרית חדשה פעם במס’ שנים. הגרסא החדשה כוללת בד”כ פיצ’רים נוספים, יכולות חדשות, שיפורים ביכולות קיימות – וכו’. לכולנו ברור שבשביל להישאר רלוונטיים, מפתח צריך להתעניין ולהכיר מה יש בגרסאות החדשות של מוצרים שאיתם הוא עובד, רצוי הרבה לפני שהן יוצאות – עוד כשהן בשלבי preview / RC וכו’.
בנוסף לגרסאות העיקריות, אחת לכמה זמן מיקרוסופט מוציאה Service Pack, שגם זה מונח שכולנו מכירים, ואנשים (כולל אלה שאינם DBA-ים) מכירים ומודעים לחשיבות שלו.
מה שאולי פחות מוכר זה הקונספט של ה- Cummulative Updates. בעולם ה- SQL Server, מיקרוסופט מוציאה בערך פעם בחודשיים חבילת עדכונים שכוללת בעיקר תיקוני באגים שונים(לעיתים יש גם תוספות פיצ’רים, אבל בד”כ דברים מינוריים יחסית). מדובר בבאגים שקשורים לבעיות יציבות, בעיות ביצועים ובאגים (למשל, יכולים להיות באגים של החזרת תוצאה לא נכונה). מהניסיון שלי, אני יכול להגיד לכם שלא פעם מדובר בתיקונים קריטיים שכדאי מאד להתקין, ולא לחכות עד ל-SP שייצא אחרי שנה ויכלול את העדכונים הללו.
אם אתם לא מכירים, אתם צריכים להוסיף את בלוג העדכונים של SQL Server כבר היום לקורא ה-RSS שלכם, כדי שתתעדכנו כל פעם שיוצאת גרסא חדשה ו- CU חדש. ההמלצה (גם שלי, גם של מיקרוסופט)היא להתקין את העדכונים הללו שיוצאים. הם פותרים באגים, לא פעם גם באגים עיקריים (כאלה שיש סיכוי טוב שנתקלתם בהם). לכל הפחות, צריך לעבור כשיוצא עדכון כזה על רשימת ה-FIX-ים הכלולים בו (כאן תוכלו למצוא למשל את ה- KB של CU1, שהוא האחרון שיצא עד היוםל-MSSQL 2016 SP1) ולראות אם אחד מהדברים שמופיעים שם “מצלצל” לכם. גם אם נראה לכם ששום דבר לא רלוונטי אליכם – עדיין כדאי להתקין. יכול להיות שחלק מהבאגים (בעיקר באגים של פגיעה בביצועים) משפיעים עליכם, למרות שאתם לא מודעים לזה.
בכל אופן, קחו בחשבון שאין צורך להתקין את כל היסטוריית העדכונים. אתם צריכים להתקין רקאת ה- CU האחרון שרלוונטי אליכם (כלומר, ה- CU האחרון שיצא לגרסא וה-SP שמותקן אצלכם). כל CU כולל גם את העדכונים הקודמים, כך שהוא מביא אתכם לרמה העדכנית ביותר.
כדאי לדעת שבגרסאות מעודכנות – השאילתה SELECT @@VERSION מחזירה לכם string שמתאר גם את ה-CU שמותקן (בניגוד לעבר שה-CU לא היה מופיע בבירור ב- string של הגרסא).
נקודה נוספת שכדאי להכיר, היא ששינויים ב- query optimizer לא מופעלים כברירת מחדל על דטאבייסים קיימים, כדי להפחית את הסיכוי ששאילתות קיימות ייפגעו ויווצר עבורם execution plan פחות טוב מהנוכחי. עם זאת, עבור אפליקציות “חיות” (כלומר, אפליקציות שיש משאבי פיתוח שמופנים אליהם, שיש מי שמסתכל עליהם וכו’) כדאי לאפשר הפעלה של Query Optimizer Fixes- כאשר כמובן שרצוי אחרי שדרוגים לתת תשומת לב מיוחדת ולראות שלא נפגעו לכם שאילתות. כדי לאפשר לעדכונים ל- query optimizer לפעול (גם ב- primary וגם ב- secondary שקיימים), השתמשו בפקודות הבאות:
USE [SO]
GO
ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES = ON;
GO
ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY SET QUERY_OPTIMIZER_HOTFIXES = OFF;
GO
בהצלחה!
כתיבת תגובה