content top

עשרת הדיברות ל-DBA

את הרשימה הבאה לא לקחתי משום מקום, זו הרשימה שלי, מהנסיון האישי.

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

  1. וודא שיש לך גיבויים עדכניים של בסיס הנתונים ושהם אכן עובדים
    • בצע ניסוי שיחזור כל כמה זמן כדי לוודא שאתה מסוגל לשחזר וגם כדי לבחון אם פרק הזמן שלוקח השיחזור מתאים לסוג בסיס הנתונים שאתה משחזר (קצר מידי, ארוך מידי).
    • וודא שה- recovery model  של בסיס הנתונים שלך מתאים לתכונות בסיס הנתונים (לדוגמא: simple אם אתה לא צריך לבצע גיבוי ל-T-LOG).
    • אם יש לך סביבת Disaster Recovery, נסה אותה כל כמה זמן. כלומר, רצוי ליזום מקרה של DR ולנסות להשתמש בסביבת ה-DR בתור סביבת הייצור.
    • וודא שאתה שומר גיבויים במקום מרוחק למקרה שתצטרך לשחזר הכל.
  2. capacity planning – דאג לכך שאתה יודע מראש כשקבצי ה DB-ים גדלים ושיש לך מספיק מקום על הדיסקים (כולל מקום לקבצי הגיבוי)
  3. דאג שגירסת מערכת ההפעלה ובסיס הנתונים עדכנית ככל שניתן, כולל Service Packs, security updates ו-hot fixes חשובים. לדוגמא: http://support.microsoft.com/kb/913089.
    מאחר ו-SQL 2000 כבר לא נתמך, חשוב מאוד לשדרג אותו מהר ככל שניתן.
    טיפ לעתיד: אם אתה קונה תוכנת מדף, וודא שיש סעיף בחוזה שבו הספק מתחייב לשדרג את המערכת לגירסת SQL חדשה לפני שהגירסה הישנה כבר לא בתמיכה. יש לי לקוחות שעדיין שוברים את השיניים על SQL 7 בגלל שהספק נעלם והם צריכים לשכתב מערכות.
  4. וודא שאתה באמת יודע מה קורה בבסיס הנתונים שלך, מבחינת שינויים (טבלאות, אינדקסים, פרוצדורות). ניתן לכתוב מנגנון כזה או להשתמש בתוכנה כדוגמת SQLChange של Idera.
    ב-SQL 2005 ניתן בקלות להשתמש ב-DDL TRIGGERS וב-SQL 2008 ניתן להשתמש ב-Data Access Audit feature.
  5. וודא שמבחינת אבטחה (SECURITY) אתה עומד בדרישות הבטיחות המתאימות למערכת שלך, לדוגמא: SOX, FDA. אתה יכול להוריד את ה-security baseline analyzer  של מייקרוסופט שיבדוק לך דברים בסיסיים בסביבה: http://technet.microsoft.com/en-us/security/cc184924.aspx
    דברים נוספים: בדוק אם הסביבה שלך עמידה בפני SQL INJECTION ונטר את מספר ההתחברויות הכושלות לבסיס הנתונים.
  6. נטר את ה ERRORLOG של ה-SQL ואת ה EVENT VIEWER. קבצים אלה מכילים אינפורמציה חשובה עבור ה-DBA. אנחנו, למשל כתבנו תוכנה שמנטרת את הקבצים הללו כל 5 דקות ומציגה הודעות. יש לנו פילטר על ההודעות כך שאנחנו מקבלים רק את ההודעות החשובות. דוגמאות להודעות כאלה: בעיות IO, שגיאות במערכת ההפעלה, עצירה של ה-Services וכד'.
  7. וודא שתוכניות התחזוקה שלך עובדות ומבצעות:
    • UPDATE STATISTICS לפני INDEX DEFRAGMENTATION
    • INDEX DEFRAGMENTATION "חכם": דפרגמנטציה של האינדקסים לפי רמת הפרגמנטציה  (פירוט – במאמר הבא…).
    • INTEGRITY CHECKS: בדיקת תקינות בסיס הנתונים. ככל שתגלה בעיות מוקדם יותר, כך תוכל לתקנן לפני שיהיה מאוחר.
      טיפ: אם אתה מאפשר תיקון טעויות מינוריות אוטומטית, זכור שבסיס הנתונים צריך להיות במצב של single user בזמן התיקון (אצלי למשל זה אף פעם לא מצליח כי תמיד יש פעילות ב DB-ים)
  8. נטר את ביצועי המכונה ואת ה-SQL Server instance על בסיס קבוע ותשווה ביצועים:
    • לאורך זמן
    • לפני ולאחר גירסה
    • לפני ולאחר ביצוע TUNING (הוספת אינדקסים, שינוי TSQL, וכד')
  9. וודא שאתה דואג למחוק הסטוריה של ריצות של JOBS ו MAINTENANCE PLANS מה-msdb. כשה-msdb מנופח, כל פעולת IO בו יכולה לגרום לבעיית ביצועים (גיבויים, maintenance plans, וכד').
  10. בצע בדיקות קבועות לוודא שה-SQL SERVER שלך "בריא":
    • נטר locks/blocks/deadlocks
    • הדלק את ה-FLAGS שנותנים לך אינפורמציה לגבי deadlocks, או הרץ SQL Traces שיראו לך את ה deadlock graph.
    • שלוף את 10-20 ה-TSQL הכבדים ביותר ב-DB או בכלל ובצע להם TUNING, או שלח אותם למתכנתים.

——————————————————————————————————————–

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

  • ווידוא שה-paging file מנוצל כמה שפחות.
  • ווידוא שתוכנת האנטי-ווירוס (אם מותקנת) לא גורמת לבעיית ביצועים: http://support.microsoft.com/kb/309422
  • הנחיות לגבי tempdb: לדוגמה http://msdn.microsoft.com/en-us/library/ms175527(SQL.90).aspx.
    מייקרוסופט ממליצים של- tempdb  ב-SQL 2005/2008 יהיו מספר קיבצי data בגודל שווה, קובץ לכל שניים עד ארבעה PROCESSOR CORES. לדוגמא: אם יש לך שני CPU QUAD CORE, מספר קיבצי tempdb צריך להיות 2 עד 4.
    ב-SQL 2000 – קובץ אחד לכל CPU CORE.
  • והרשימה עוד ארוכה…  המשך – במאמרים הבאים…

13 תגובות על “עשרת הדיברות ל-DBA”

  1. מאת אריאל:

    שלום

    תוכלי לתת עוד אינפרמציה על ניתור ה ERRORLOG דרך STP והקפצת ALERT ים כשקורה משהו חריג

    תודה

    אריאל

  2. מאת מיכל גוטצייט:

    הי אריאל,

    אנחנו עושים את זה "בעצמינו":

    אנחנו קוראים את ה-ERRORLOG באמצעות ה-SP
    EXEC master..xp_readerrorlog
    (שולפים את ההודעות שנרשמו מאז זמן הקריאה האחרון)
    יש לנו קובץ שמכיל את ההודעות הלא חשובות שמהן אנחו מתעלמים או שולחים ALERT רק אם הן קורות X פעמים ב-Y דקות.
    כל SERVER אצלינו הוא שונה וכן שונות ההודעות שדורשות התעלמות.

    אני חושבת שיש מוצרים מוכנים שעושים את זה.
    אישית אני אוהבת את ה-Diagnostic Manager של Idera, אבל אני לא זוכרת אם הם קוראים את ה-Errorlog.

    מקווה שזה עוזר…

  3. אפשר גם להשתמש במנגנון שכתבתי עליו כאן:
    http://www.sqlserver.co.il/?p=106
    הוא אמנם מיועד לאתר Failed logins, אבל אפשר להשתמש בו גם לאתר שגיאות.

  4. מאת אסף פרנקל:

    יופי של מאמר ותודה גם על הקרדיט בפוסט הקודם.

    לדעתי הדבר הראשון הוא – הפרד את ה data וה log לדיסקים נפרדים. תמיד מדהים אותי כמה לא עושים את זה….

  5. מאת מיכל גוטצייט:

    אסף, אתה צודק, אירגונים באמת לא נותנים חשיבות למיקום קיבצי ה-Data וה-Log ולרוב גם לא לסוגי ה-Raid שבהם משתמשים.
    הרבה פעמים אתה רואה שרת SQL שמנהל אפליקציות קריטיות עם הרבה טראנזאקציות, אבל מוגדר עבורו רק דיסק לוקאלי אחד לכל קיבצי בסיס הנתונים. אפילו אם כמות הזיכרון גדולה, תמיד יתבצע IO בדיסק והוא עלול להיות צוואר בקבוק רציני.

    אנחנו מצליחים להוכיח חדשות לבקרים שאפילו פיזור אובייקטים על פני קיבצי Data על דיסקים נפרדים (טבלאות/אינדקסים) יכול לשפר ביצועים בצורה משמעותית.

  6. הי מיכל,

    וואו מדהים לפגוש אותך כאן באתר
    כמה זמן לא דיברנו
    אשמח אם תשלחי מייל ונתעדכן.

    גולן

  7. מאת ליאור:

    מאיר , מדהים !
    ליאור

  8. מאת Yaniv:

    באנגלית הייתי אומר – well said , מה המקבילה בעברית?
    התוספת הקטנה שקפצה לי מאחר והוזכר קריאה מ errorlog היא שיש אפשרות לא לכתוב לקובץ את המידע המיגע אודות הגיבויים וכך לשמור את הקובץ בגודל קטן יותר (נכון בעיקר כשיש הרבה בסיסים על השרת והזמן בין אתחול לאתחול של ה service ארוך).

    DBCC TRACEON(3266, -1);

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

    -יניב

  9. מאת מיכל גוטצייט:

    יניב, הערה במקום !

    אנחנו למשל מנטרים הכל:
    * ג'וב הגיבוי
    * errorlog
    * עבור בסיסי נתונים קריטיים – על כל שרת יש לנו טבלה שמגדירה כמה זמן מקסימום מותר שלא יהיה גיבוי עבור כל בסיס נתונים (יש לנו שורה לכל סוג גיבוי ו-DB) ואז יש לנו ג'וב שבודק כל 5 דקות אם יש בסיסי נתונים שלא גובו בזמן
    * יש לנו חבילה/ג'וב שרץ פעם ביום ושולח דו"ח של כל בסיסי הנתונים שלא גובו בזמן.

    DBCC TRACEON(3266, -1);
    לא מצאתי את המספר הזה בשום מקום וזה נשמע מעניין (אתה בטוח שזה המספר?):
    http://msdn.microsoft.com/en-us/library/ms188396(SQL.90).aspx

    ולגבי הפקודות:
    DBCC TRACEON(, -1);
    הפקודה הזו מדליקה את ה Trace Flag אבל אם ה-instance של ה-SQL מאותחל, הדגל "נכבה", לכן כדאי להוסיף את הדגל לפקודה שמריצה את ה-SQL Server Service:
    http://msdn.microsoft.com/en-us/library/ms190737(SQL.90).aspx

  10. מאת ניר:

    לגבי ה Event log, כדאי להגביל אותו שייצור קובץ חדש כל כמה ימים – תלוי בכמות ההודעות.

    כך יותר קל לעבור בין הלוגים.
    אצלי מוגדר בג'וב להריץ את הפרוצדורה sp_cycle_Errorlog
    כל 3 ימים בחצות, ולשמור 10 קבצים, כך שיש לי חודש אחורה בקבצים סבירים.

  11. מאת יניב:

    DBCC TRACEON(3266, -1); פקודה לא מתועדת.
    אכן יש להדליק על ידי start-up פרמטר או פרוצדורה.

  12. נסו את גרין אס קיו אל יכול לפתור חלק מהסעיפים באופן אוטומטי

  13. מאת מויישה:

    שלום,
    באיזה תדירות נכון לבצע בדיקה של השרת ? שבועי ? חודשי ? רבעוני ?

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

thirteen − six =