איך אומרים? "לכל דבר טוב יש סוף…" וכפי שהתבשרנו זה מכבר גם התמיכה המורחבת ב- SQL Server 2008 ו- 2008R2. מסתיימת בימים אלו. או ליתר דיוק, הסתיימה כבר ב-9 ליולי 2019. "אז מה עושים?" זו השאלה שחוזרת על עצמה בקרב לקוחותינו המחזיקים עדיין במערכות העושות שימוש בגירסה זו של SQL Server. באופן כללי התשובה לשאלה זו קשורה לא מעט במערכות שעושות שימוש בבסיס הנתונים הזה. במקרים מסוימים מערכות אלו לא יתמכו במעבר לבסיס נתונים מסוג אחר או במעבר פשוט מ-on-prem לענן אלא ידרשו בחינה מעמיקה יותר  ובמאמר זה לא נתייחס לאפשרויות האלה אלא לתהליך העבודה של שדרוג. 

לאיזו גירסה של SQL Server כדאי לשדרג? 

שוב הכל מאוד תלוי במערכת העושה שימוש בבסיס הנתונים. אך אפשר להניח שבשלב הזה מרבית המערכות יתמכו במעבר לגירסת SQL Server 2017, שנחשבת כבר כיציבה ופופולרית. המאמר הזה מסכם את כל מה שהתחדש ב- SQL 2017 מאז גירסת 2008. 

תאימות בין סביבת המקור לסביבת היעד

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

• גודל אחסון – יש לוודא שגודל האחסון בדיסק של סביבת היעד מספיקה. אם זה לא מספיק יש להרחיב את גודל האחסון.   
• מיקום הלוגים והדאטה – יש לוודא שמיקום הלוגים והדאטה בסביבת היעד תואמת את מיקום הסביבה במקור. אני בדרך כלל ממליץ לשמר את אותם מאפיינים של האחסון כלומר אם יש דיסק "D" לקובץ הדאטה ודיסק L לקבצי הלוגים, אז לשמר את אותו סדר גם בשרת היעד.
• מאפייני בסיס הנתונים – יש לאסוף את המאפיינים של בסיס הנתונים ולוודא תאימות. מאפיינים אלו כוללים Auto Stats, DB Owner, Recovery Model, Compatibility level, Trustworthy option, ועוד. בזמן ההתקנה של בסיס הנתונים החדש יש לבחור את אותו path עבור ה- MDF, LDF, וה- backup. 
• בדיקת ה- Collation – יש לבדוק מה ה- Collation שהוגדר בבסיס הנתונים המקורי ולוודא שהוא מוגדר גם ביעד. מאמר זה מסביר על ההגדרות ומשמעות השימוש ב- Collation. 
• יישומים ושירותים תלוים – יש לאסוף נתונים על כל היישומים התלויים בבסיס הנתונים לרבות כל השירותים שהם מריצים.
• שירותים של בסיס הנתונים – יש לוודא שהשירותים של בסיס הנתונים הישן כמו SSIS, SSRS, ו- SSAS מוגדרים גם בבסיס הנתונים החדש. לא כל השירותים האלה מוגדרים בכל בסיס נתונים לכן יש לבחון אם הם היו קיימים בבסיס הנתונים במקור.  
• הרשאות – יש לאסוף נתונים על כל ההרשאות של בסיס הנתונים, לרבות משתמשים, לוגאינים, הרשאות וכו'. יש לבדוק אם ישנם משתמשים "יתומים" – מאמר זה מסביר כיצד למצוא משתמשים כאלה וכיצד לפעול בנושא. במקרים רבים ההרשאות מנוהלות באמצעות Active Directory ולכן אני ממליץ לשמור על אותו שם שרת ברשת עבור השרת היעד. זה ימנע את הצורך בהגדרות חדשות לכל המשתמשים. זה ימנע גם הגדרה מחודשת של ה- connection strings.  
• אובייקטים מקושרים – יש לבדוק אם ישנם אובייקטים מקושרים כמו SQL Agent Jobs או שרתים מקושרים כמו Link Server.  
• תוכנית תחזוקה וDR – יש לבדוק אם השרת נכלל בתוכנית תחזוקה כלשהי והאם הוא נכלל בתוך תוכנית Disaster Recovery, למשל אם יש לו Log shipping, mirroring או availability groups וכו'. יש לרשום את כל אלה ולבצע את אותן הגדרות גם בסביבת היעד.  

המעבר עצמו

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

• ניתוק השרת הישן – לפי אופציה זו מנתקים את השרת הישן, מעבירים את הקבצים לשרת החדש על ידי dettach. כמובן שכל זאת תוך שמירת על אותו path בשני השרתים. לאחר מכן ניתן להרים את השרת החדש. שיטה זו אינה כה נפוצצה כי זה אומר שיהיה downtime, אשר בדרך כלל אינו רצוי.
• שיטה של Backup ו- Restore – אומרים לכל העובדים להפסיק את עבודתם. לוקחים backup ואז עושים restore בשרת החדש. שיטה זו גם מצריכה הפסקת עבודה לזמן ממושך ואינה מומלצת בדרך כלל. אם בסיס הנתונים מאוד קטן אין בעיה לעשות זאת כי זה לא יקח זמן ממושך. 
• שיטת ה- Log Shipping – עושים גיבוי מלא של המקור ו- restore ביעד ואז מתחילים "לגלגל" לוגים אל עבר היעד. כך למעשה משחזרים את כל הפעולות שנעשו בבסיס הנתונים מאז הגיבוי. בזמן הזה ניתן לעבוד כרגיל בבסיס הנתונים המקורי. כשרואים השכל עובד כראוי עושים את ה- restore  של הלוג האחרון. כלומר עושים restore רק עבור הדלתא של השינויים האחרונים. בזמן הקצר הזה מפסיקים לעבוד, עושים את ה-restore לשרת החדש, מכבים את השרת הישן, משנים למכונה ביעד את שם המכונה ומעלים אותה. ואז כל ה- connection strings יכנסו כבר למכונה החדשה. כלומר ה-downtime במקרה הזה הינו ממש מינימלי למשל רבע שעה. 

מקווים שעזרנו במעט להתמודד עם ה- end of life של SQL Server 2008. לכל שאלה או בקשה צוות המומחים שלנו ישמח לעמוד לרשותכם: info@datasite.co.il