כיום ארגונים רבים מעבירים את התשתיות שלהם לסביבות מנוהלות בענן. כחלק משירות ה- 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ים שלנו ישמחו ללוות אתכם בתחזוקה וכן בייעוץ בהתאם לצרכי הארגון.