נסיון של 3 שנים לפחות כ- DBA ORACLE
נסיון בפיתוח PL/SQL
הכרות עם LINUX
נסיון בעבודה בסביבת ייצור מורכבת מרובת שרתים

  • נסיון של 4 שנים לפחות- חובה.
  • דגש על תשתיות.
  • Azure- יתרון משמעותי!

המשרה דינמית אצל לקוחות החברה.

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

מהו Azure Site Recovery?

זהו שירות ענן מנוהל של Microsoft Azure המאפשר התאוששות מאסון (Disaster Recover) עבור ארכיטקטורות ענן או ארכיטקטורות היברידיות. השירות מאפשר לשכפל בקלות כל מכונה ווירטואלית, כולל מערכות פיזיות On-prem בענן (בדרך כלל ב-Region אחר). בעת אסון או השבתה מתוכננת או לא מתוכננת, המערכת מבצעת Failover תוך שחזור מהיר של כל הנתונים בתהליך מובנה, מוכח ומסודר שמבטיח המשכיות עסקית רציפה.

פתרון Azure Site Recovery מאפשר לבצע המשכיות עסקית במספר תרחישים שונים:

  • Hyper-V to Azure – המשכיות עסקית לסביבת Hyper-V המקומית בAzure.
  • Hyper-V to Hyper-V – המשכיות עסקית מסביבת Hyper-V מקומית וסביבת Hyper-V משנית.
  • VMware/Physical to Azure – המשכיות עסקית לסביבת VMware או שרתים פיזיים.
  • VMware/Physical to VMware – המשכיות עסקית מסביבת VMware לסביבת VMware משנית.
  • Azure to Azure – המשכיות עסקית לשרתי IaaS ב-Azure מ-Region אחד ל-Region אחר.

כלומר, השימוש בשירות ASR אינו מצריך בהכרח שאתר היעד לרפליקציה יהיה בענן של Azure. ניתן לעשות בו שימוש לרפליקציה בין שני אתרים שונים של אותה חברה.

ההגדרה והניהול של ההמשכיות העסקית מבוצעים במסגרת ה- Azure Management Portal. אין צורך בניהול של patchים או של תחזוקת שרתים, הכל מנוהל במסגרת השירות. באמצעות השימוש בשירות ASR ניתן להנות מRTO (Recovery Time Objective) וRPO (Recovery Point Objective) נמוכים במיוחד.

כיצד מקימים פרוייקט המשכיות עסקית?

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

  • שלב התכנון – זהו שלב קריטי המשלב הביטים טכניים ועסקיים גם יחד. כך למשל, בשלב זה בוחנים את הצרכים מבחינת RPO ו- RTO, נפחי האחסון הנדרשים, רוחבי הפס של הרשת וכו'.
  • הקמת הסביבות והגדרתן – לאחר שלב התכנון מגיע שלב ההטמעה. במסגרת זו מגדירים את הסביבות ואת תהליך הרפליקציה. תהליך זה כולל הגדרת סביבת הDR בענן, הגדרת הרשת, האחסון ומדיניות הרפליקציה.
  • רפליקציה ראשונית – תהליך הרפליקציה הראשוני לוקח זמן ממשוך מכיוון שהוא כולל את כל (או רוב) המידע ולא רק את הדלתא\השינויים. זהו תהליך רגיש, לכן יש לתכננו באופן מוקפד ומבעוד מועד כך שלא יפריע למהלך התקין של הארגון.
  • בדיקת ההתאוששות (Failover) – בשלב זה ניתן לבדוק את תהליך ההתאוששות מאסון. ASR מאפשר לבצע בדיקה שכזאת על ידי כך שמדמים מצב שבו צריך לבצע Failover וכך לבחון את מוכנות הסביבות והמערכות.
  • ניטור הרפליקציה ופתרון בעיות – כחלק מתהליך ה-DR מאוד חשוב לנטר את הרפליקציות ולבדוק שיעדי ה- RPO נשמרים. מעבר לאספקת התראות על Jobים שונים, ASR גם כולל Event Log Source משלו המשמש לבצע תהליך פתרון בעיות עבור בעיות שונות ברפליקציה.
  • ביצוע מיגרציה – באמצעות יכולת המיגרציה של ASR ניתן לבצע מיגרציה והמערכת באופן אוטומטי דואגת לכך שה- workload יעבור מיגרציה במלואו, תהליך הרפליקציה יפסק, והחיוב עבור המכונה שממנה בוצעה המיגרציה יפסק.

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

 

 

 

לארגון גדול דרוש/ה ר"צ DBA SQL SERVER לצוות תשתיות.

נדרש נסיון ניהולי בשילוב HO.

המשרה בתל אביב על קו הרכבת.

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

– ניסיון בתכנון והטמעה של מערכות מורכבות ב- Microservice
– שליטה מלאה ב-CLOUD כדוגמת AWS/ AZURE.
– לא פחות מ- 12 שנות נסיון, מתוכן לפחות 5 שנים בפיתוח WEB
(hands-on)
– נסיון ב- UI frameworks כגון ANGULAR, REACT.
– נסיון ב- PYTHON.
– ניסיון במתודולוגיית פיתוח Agile.
– נסיון ב- PostgreSQL – יתרון.
– יכולות ניהול – יתרון.
– נסיון מוכח בקבלת החלטות לטווח ארוך תוך שיתופי פעולה.

נסיון של 4-5 שנים לפחות- חובה.
נסיון בפיתוח APS. NET , C#, AJAX
נסיון בפיתוח HTML, JAVASCRIPT, JQUERY, CSS
נסיון בבניית שאילתות מורכבות ב MSSQL SERVER</p
יתרון משמעותי- תואר ראשון במדעי המחשב/ הנדסת תוכנה

כיום ארגונים רבים מעבירים את התשתיות שלהם לסביבות מנוהלות בענן. כחלק משירות ה- PaaS מספקים ספקי מחשוב ענן גם תשתיות בסיסי נתונים מנוהלות. התפיסה העומדת בבסיס השירות הינה אספקת תוכנות תשתית הנדרשות לצורך הרצת או פיתוח מערכת בסביבה מנוהלת. אלא שהמושג "סביבה מנוהלת" נשמע כאילו הוא מיתר את הצורך באנשי תשתיות בכלל וב- DBAים בפרט כמו שמכוניות אוטונומיות יחליפו יום אחד את נהגי המוניות. כפי שנראה במאמר הזה נכון לעכשיו אמנם ה- PasS מספק אוטומציה בהיבטים שונים, אך עדיין ברוב המקרים יש צורך באנשי DBA שילוו ויתחזקו את המערכות לאורך כל שלבי החיים שלה. במאמר זה אתמקד ביכולות של Azure עם SQL Server אבל ניתן להניח שהמצב דומה עבור ספקי ענן אחרים.

מה מתוחזק באופן אוטומטי?

Azure PaaS מספק שירותים רבים. אך למעשה היתרונות הבולטים נובעים מכך שלא צריך לדאוג לנושא האחסון והגיבויים מבוצעים באופן אוטומטי. עם זאת, אם רוצים לקחת את בסיס הנתונים "הצידה" ולשחזר אותו בסביבת Dev יש צורך ב- DBA שיעשה זאת במסגרת תהליך מובנה.

אז למה צריך DBA?

אם מדובר במערכת שמתקינים פעם אחת ולא עושים בה עוד שום שינוי, לא ממש צריך DBA. אלא שאז גם ב- on-prem לא צריך DBA לתחזוקה של מערכת כזאת. ברוב המקרים גם אם לוקחים בחשבון את כל האוטומציה, עדיין יש צורך ב-DBA לאורך כל שלבי החיים:

שלב ההקמה

כשמקימים את בסיס הנתונים קיים הבדל משמעותי בין on-prem לבין PaaS בכך שבהתקנה המקומית ה- DBA חייב לדאוג לאחסון (למשל באיזה דיסקים ישב כל DB) ואילו ב- Azure PaaS לא צריך לדאוג לאחסון באופן שכזה. כל שאר הפעולות נשארות כפי שהיו טיוב שאילתות, אינדקסים, פיתוח דוחות, הגדרת הרשאות פנימיות לבסיס הנתונים, וכו'.

שלב התחזוקה

לאחר ההקמה הראשונית מגדירים לפי הצורך תהליכי תחזוקה תקופתיים קבועים, למשל יומי, שבועי, חודשי וכו'. התהליכים האלה בדרך כלל כוללים תחזוקת סטטיסטיקות ותחזוקת אינדקסים, הכולל בדיקות של יצירת אינדקסים חדשים ומחיקת אינדקסים מיותרים. במסגרת יצירת אינדקסים אמנם ישנה אופציה ב- Azure שהמערכת תמצא את האינדקסים שהיא חושבת שנכונים ותעדכן אותם, אבל האינדקסים שהיא מוצאת כאופציונאליים יכולים להיות לא שימושיים כי למשל הינם באורך של כל הטבלה, דבר אשר עלול להכביד על גודל הטבלאות ולמלא מהר מאוד את מקום האחסון. או שהאינדקס פשוט שגוי וכך עלול לגרום לנעילות בעדכוני הטבלאות, ב- insertים וכו'. על כן חייבים DBA שיבין את הנתונים ומבנה בסיס הנתונים ויעשה את ההתאמה הזאת.  גם זיהוי של אינדקסים שיש למחוק יעשה על ידי ה- DBA.

ניטור ופתרון בעיות ביצועים

במסגרת התחוקה השוטפת ה- DBA ינטר את ה- DB כדי למצוא ולפתור בעיות ביצועים למשל על ידי קביעת baseline וזיהוי שאילתות שלוקחות יותר מדי זמן (לדוג' יותר מחצי שניה).

  • פתרון בעיית נעילות – אחת הבעיות הנפוצות בבסיסי נתונים הינה זיהוי ופתרון של נעילות. כשיש ריבוי קריאות וכתיבות לטבלה מסויימת המהלך יכול להנעל ותהליכים שונים עלולים לקבל (deadlocks). בעיה שכזאת ניתנת לזיהוי מוקדם במסגרת תהליך תחזוקתי ומתן פתרונות מגוונים.
  • פתרון בעיית תכנון אינדקסים – זה יכול להיות אינדקס שחסר או אינדקס מיותר. אמנם Azure אמור לדעת לזהות אינדקסים שחסרים אך מומלץ לראות בנתונים שהמערכת מספקת כהמלצה בלבד אשר נבחנת על ידי DBA מנוסה.
  • פתרון בעיות של סטטיסטיקות – אלו גם בעיות נפוצות המשפיעות על הביצועים. כל למשל יכולה להיות פרוצדורה שרצה ובעקבות טעינה גדולה לטבלה מקבלים ביצועים שאינם אופטימליים. המערכת של Azure לא תדע לזהות את זה, אלא רק DBA  יכול לזהות ולטפל בבעיה שכזאת.

שדרוגי גרסה

שדרוגי גרסה של המערכת\אפליקציה שעושה שימוש בבסיס הנתונים לרוב מצריכה שינויים בסכמה של ה-DB, טבלאות נוספות, פרוצדורות, שאילתות וכו'. לפני שהשדרוג מבוצע, מומלץ ש-DBA יבצע Code Review על מנת לוודא שהקוד נכתב בצורה יעילה שתואמת את ה- best practices. כשהכל מוכן, יש לקחת baseline חדש כדי למדוד שינויים בביצועים ומומלץ מאוד לבצע בדיקות ביצועים (stress tests) המדמות עומסים צפויים.

לסיכום

כפי שראינו גם בסביבת PaaS יש צורך בליווי של DBA אשר יבצע תחזוקה שוטפת, יפתור בעיות, יבצע אופטימיזציות של ביצועים, ויתמוך בתהליכים שונים כמו שדרוגי גירסה, פיתוח של דוחות חדשים, הגדרת תהליכי ETL (Extract, Transform, Load) ועוד. מומלץ להתייעץ עם הDBA לגבי תדירות הבדיקה הנדרשת במקרים של שינויים במבנה הנתונים, עדכונים משמעותיים כמו גרסאות ועוד. הDBAים שלנו ישמחו ללוות אתכם בתחזוקה וכן בייעוץ בהתאם לצרכי הארגון.

כותב: תומר לב,  ארכיטקט DATA, מנכ"ל ובעלים DATASITE 

ישנם רבים שחושבים שבסיסי הנתונים מסוג No SQL, כדוגמת MongoDB, מהווים את ה"דור החדש" של בסיסי הנתונים. לפי גישה זו, אפליקציות חדשות, שאינן "כבולות" לבסיס נתונים כזה או אחר יכולות פשוט להשתמש בבסיס נתונים מסוג NoSQL וכך להנות מהיתרונות של הקידמה, היעילות והעלויות הנמוכות. ובכן לצערי (או לשמחתי, תלוי איך מסתכלים על זה)  זהו מיתוס שאינו נכון. אמנם טכנולוגית ה- NoSQL היא יותר חדשה, אך אין זה אומר שהיא מתאימה לכל אפליקציה. כפי שאסביר במאמר זה, הטכנולוגיה הזו פותחה לתת מענה לסוג מסויים של שימושים בלבד, כך שבחירה לא נכונה יכולה להוביל לחוסר יעילות ובזבוז רב, ובמקרים מסויימים זה פשוט לא יעבוד. במאמר זה אנסה לעשות סדר בבלגן תוך מתן טיפים לבחירה הנכונה בסוג ה- DB המתאים ביותר.

מה זה NoSQL וכיצד הוא שונה מבסיסי נתונים רלציוניים?

ובכן סוג זה של בסיס נתונים נועד לתת מענה יעיל לנפחים גדולים של מידע שאינו מאורגן לפי שיטה מסויימת, כלומר מידע בלתי מובנים (Unstructured) שהינו מגוון מאוד כך שלא ניתן לסדר אותו בטבלאות. דוגמאות לסוגי מידע שכאלה הינם: לייקים ושיתופים ברשתות חברתיות, תגובות של גולשים, תמונות, מידע מסנסורים ועוד. בנוסף, בסיסי נתונים מסוג NoSQL נפוצים יותר במערכות Big Data וכן במערכות זמן אמת.

ההבדל העיקרי בין בסיס נתונים  NoSQL ו-רלציוניים הוא שמערכות RDBMS מגדירות באופן נוקשה את האופן שבו כל הנתונים שהוכנסו לבסיס הנתונים חייבים להיות מוקלדים ומורכבים, ואילו בסיס הנתונים  NoSQL מבוססים סכימת נתונים בכל צורה שהיא, ומאפשרים לאחסן ולטפל בנתונים בלתי מובנים ומובנים למחצה.

הבדל חשוב נוסף הינו העובדה שבסיסי הנתנים הרלציוניים תומכים ב- vertical scaling בלבד. כלומר כדי לגדול יש להוסיף יכולות לאותה מכונה. ואילו NoSQL תומך ב- horizontal scaling, המאפשר גדילה רוחבית על פני מספר בלתי מוגבל של מכונות.

בסיסי נתונים NoSQL מתחלקים לכמה משפחות עיקריות, כאשר כל אחת מאופיינת במטרות וביצועים שונים:

  • Document Databases – בסיס נתונים בו המסמך הוא המפתח והתוכן של המסמך, באשר הוא, הוא הערך. דוגמה לבסיס נתונים זה הינו MongoDB.
  • Graph Stores – בנויים על סכימה שמכילה קשרים בין נתוים ובין אובייקטים במטרה להציג את הנתונים ואת הניתוח באמצעות גרפים חזותיים. סוג זה של בסיס נתונים משמש לרשתות חברתיות ולמערכות למניעת הונאה. דוגמה לבסיסי נתונים זה הינו Neo4J.
  • Key Value Store – מאחסנות זוגות של ערכי מפתח ומספקות פונקציונליות בסיסית לאחזור הערך המשויך למפתח ידוע. הפשטות בשמירת נתונים באופן הזה הופכת את מערכות אלה למותאמות היטב ל embedded databases, כאשר הנתונים המאוחסנים אינם מורכבים במיוחד ומהירותם היא בעלת חשיבות עליונה. דוגמה לבסיס נתונים זה הינו Redis.
  • Wide-Column Stores – בסיס נתונים מבוססי עמודות (במקום שורות), בו משמשים בעיקר לשאילתות על מערכי מידע גדולים במיוחד. דוגמה לבסיס נתונים זה הינו Cassandra.

איזה סוג DB מתאים לפרוייקט שלך?

אלה המאפיינים שעבורם בסיס נתונים רלציוני (SQL) הינו אידאלי:

  • מידע מובנה (structured) – אם המידע שבפרוייקט הינו מובנה, כלומר מבנה הנתונים צפוי מראש (שדות, טבלאות, וכו') עם הרבה מאוד קשרים בין מערכים של דאטה, אז ככל הנראה אתם זקוקים לבסיס נתונים רלציוני.
  • שלמות המידע (ACID) – ACID הינו ראשי תיבות של Atomicity, Consistency, Isolation, Durability. המשמעות הינה מנגנונים השומרים על שלמות ונכונות הנתונים תוך הגדרה מדויקת של תהליכים טרנזקציניים. לכן אם שלמות ונכונות המידע חיוניים עבור הפרוייקט שלכם סוג זה של יכולות יכול להתאים יותר.
  • שימוש ב- Joinים – אם אתם זקוקים לאחזר סטים שונים של מידע השמורים בטבלאות שונות, תוכלו לעשות זאת בקלות בבסיס הנתונים הרלציוני. לעומת זאת ב- document databases אין אפשרות לבצע זאת כך ותאלצו לבצע מספר שאילתות כדי לאחזר סטים שונים של מידע.

אלה המאפיינים שעבורם בסיס נתונים לא-רלציונלי (NoSQL) הינו אידאלי:

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

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

 

3 שנות נסיון בפיתוח PHP- חובה.
נסיון בטכנולוגיות צד קליינט – HTML5, CSS3, Bootstrap, Jquery, JavaScript
שליטה ב – SQL

איך אומרים? "לכל דבר טוב יש סוף…" וכפי שהתבשרנו זה מכבר גם התמיכה המורחבת ב- 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