ניהול ותחזוק בסיס נתונים באופן מושלם – איך עושים את זה?

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

shutterstock servers

מאת איתי בנימין, ארכיטקט פתרונות ענן ובסיסי נתונים, מיקרוסופט ישראל.

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

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

תהליך מורכב שכזה מתקיים בדרך כלל כאשר "פתאום" יש בעיה בזמני התגובה במערכות, או ביצוע שינוי מכוון ברמת בסיס הנתונים (סכמה, תשתית ועוד…) אשר גררה ירידה בזמני התגובה. כמו-כן, Tuning session הינו תהליך שמבוצע לפני ביצוע פעילות קריטית בבסיס הנתונים ובאפליקציה כל זאת על מנת לזהות מבעוד מועד תהליכים בבסיס הנתונים שיכולים להיפגע מהשינויים הצפויים.

כלומר, Tuning session הינה סיטואציה שכיחה לנו, אנשי בסיסי הנתונים, תשתיות המידע ומנהלי מערכות המידע בארגונים שלנו.

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

במקרים שכאלה אנו ואנשינו מייחלים לשני תרחישים עיקריים:

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

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

לאחר מכן, שיפור ביצועים ברמה נקודתית (ברמת הטרזקציה הספציפית) על ידי חקירה הסטטיסטיקות וה- execution plans – פעולה אשר לוקחת לעיתים דקות ארוכות ואפילו שעות, וכמובן ברמה רוחבית על ידי שינוי הארכיטקטורה של מבנה הנתונים ו/ או הוספת משאבים – כל אלו פתרונות אפשריים אשר לצערנו גוזלים מאתנו יותר מידי זמן וכסף

כך תטפלו במהירות בבעיות ביצועים

אז איך בכל זאת אפשר לנסות למנוע ולטפל במהירות בבעיות ביצועים? להלן מספר טיפים:

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

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

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

התאמת משאבים מתאימים – אחד מהאתגרים של מנהל בסיס הנתונים ומנהל התשתיות בסביבת on premise הינו להתאים את כמות המשאבים המתאימה והמספקת ברמת החומרה לשרת בסיס הנתונים. הסיבה העיקרית הינה בגלל שבסיס הנתונים הינו בדרך כלל סביבה דינמית מבחינת צריכת משאבים, ולכן sizing לפי ה"פיק" יגרור אחריו בדרך כלל שרת יקר עם הרבה משאבים אשר ברוב הזמן לא ינוצלו. במקרים שכאלה מומלץ לשקול מעבר לסביבה דינמית בענן.

קרדיט תמונה: servers via shutterstock

הכתבה בחסות Microsoft Azure

SQL Server 2016 ו-Azure DB מציעים כעת יכולת חדשה: Query Store, אשר עושה שינוי וסדר בחוקי דרכי הפעולה הסטנדרטיים של מנהל ומתכנת בסיס הנתונים בעת תופעות של ירידה בזמני התגובה ועלייה בצריכת המשאבים וביכולת שלנו למנוע את המקרים הללו עוד לפני שהם משפיעים על הלקוחות.

ה-Query Store מאפשר למנהל בסיס הנתונים: לזהות בצורה קלה ומהירה תהליכים שזמני התגובה שלהם "התדרדרו" ולקבע לאותם תהליכים תכנית פעולה אופטימלית מול מנוע בסיס הנתונים, כך שירוצו בדרך היעילה והמהירה ביותר. כמו כן ה-Query Store אוגר בתוכו את ה- cache ותוכנית הפעולה ברמת הטרזקציה הבודדת במערכת שלנו לפני ואחרי שהם השתנו לאורך זמן. לבסוף כל המידע של ה- Query Store נשמר בתוך שאילתות מערכות מובנות – DMV אשר מוצגים ב- dashboard מובנה, ולכם יש את היכולת לתשאל את השאילתות הללו ולזהות ולהתריע על שינויים (לטובה או לרעה) בהתנהגות של התהליכים בבסיס הנתונים.

להתנסות בחינם לחץ כאן

כתב אורח

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

הגב

2 Comments on "ניהול ותחזוק בסיס נתונים באופן מושלם – איך עושים את זה?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
ג'וני
Guest

לא למלא אותו בזבל

Yehuda Lasri
Guest
פתרון בעיות תלוי ברמת אנשי המקצוע ובקשב ובזמינות לטפל בבעית ביצועים כול שכן למנוע אותה !! יש עוד שני פעולות שאני ממליץ לביצוע . ביקורת צד ג – הרבה פעמים אנחנו מקבלים ביטחון שאנחנו בטוחים שהמערכות תקינות לא תמיד אנו נלך לבדוק במקומות להם הינו נגשים בפעם הרשונה למערכת לפתור בעיות . אני ממליץ לכול חברה כולל אילו שיש להם DBA להעזר פעם ב שנה יותר או פחות לפי ההצלחה של אותו ביקור ביועץ חיצוני . אני מבטיח לכם אוצרות פעולה שנייה – ואני מודה שנוגעת אלי אישית הייתי שמח אם תתנסו במערכת שפתחנו בחברה לניתור ואיתור תקלות SQL SERVER… Read more »
wpDiscuz

תגיות לכתבה: