יום רביעי, 1 באוגוסט 2012

האם אתם מוכנים?


בכל תחילת מסלול DBA  שאנו בוראסיטי מעבירים , אני מסביר לתלמידים שיש 3 דברים שכלDBA חייב לבדוק שבסיס הנתונים שלו מכוסה בהם:

1.      גיבויים ותוכנית DRP

2.      ביצועים וזמני תגובה

3.      אמינות המידע

(ממויין ללא קשר לרמת החשיבות).

הפעם ברצוני להתמקד בסעיף הראשון – גיבויים ותוכנית - DRP

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

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

תמיד אני מסביר לתלמידים שהיתרון בפייסבוק או בבינג לדוגמא הינה שתמיד כשאתם רוצים להיכנס ולהשתמש בשירותים שלהם – הם זמינים! לי לא קרה (מקווה שלא לכם) שבאתם להריץ חיפוש בבינג וקיבלתם הודעה ששרת ה- sql server שלו אינו זמין....

גיבויים:

·         כידוע ב- sql server ישנם יכולות מובנות לגיבויים ואין צורך בתוכנות צד שלישי.

ומ- sql server 2008  ישנה יכולת מצויינת בשם backup compress אשר מכווצת את הגיבויים שלכם עד 90% !! (אז ניתן לשמור עוד גרסאות אחורה של גיבויים ולהעלות את שרידות בסיס הנתונים שלכם).

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

אל תקבלו את ההחלטה הזו לבד! – זאת החלטה ברמת המנמ"ר או אפילו המנכ"ל.

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

לכן חשוב לבצע ניסוי גיבוי שחזור על בסיס קבוע!

DRP:

·         כל DBA צריך שיהיה לו Disaster Recovery Plan

תוכנית זו צריכה לכלול בין השאר:

o        מה עושים אם שרת בסיס הנתונים של הארגון נופל?

o        האם עוברים לאתר משני?

o        כיצד עוברים?

o        באיזו טכנולוגיה מיישמים בשוטף את העברת הנתונים?

o        כיצד חוזרים בחזרה?

o        מי מאשר לעבור ל- DRP?

o        ועוד...

·         כידוע ל- sql server ישנן טכנולוגיות מובנות ואין צורך במוצרים משלימים ליישום DRP -  חשוב שתשתמשו בהם!

·         עד גרסת sql server 2012 היו לנו את ה- log shipping ו- mirroring ומגרסת sql server 2012  הגיעה אלינו יכולת ה- always on.

כאשר אני בא לארגון ומספר לו על הסיבות להקמת אתר DRP ישנם שני סוגים של לקוחות:

1.      לקוחות שהאתר שלהם כבר נפל ואז אין צורך בשכנוע

2.      לקוחות שעדיין לא נפל להם האתר וצריכים הסבר קל על החשיבות.

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

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

אז כמובן שלא מדובר בתרחיש דמיוני וכמובן שעלות השבתה (+עלות איבוד לקוחות בעקבות ההשבתה וכו'..) עולה בדרך כלל על עלות הקמת שרת .

אז מ- SQL Server 2012 תהליך השכנוע שלי הרבה יותר קל!

מ- sql server 2012 כידוע יש לנו יכולת מגניבה בשם always on. בעזרת היכולת המובנית ניתן להקים רפליקה (או כמה) של בסיס הנתונים שלכם בקלות ובמהירות.

היתרון הגדול של ה- always on על פני היכולות הקודמות שהיו לנו הינו שהרפליקה כל הזמן זמינה וב- read only.

בזכות היכולת הזו אני יכול גם להקים אתר DRP  וגם להריץ את הדוחות הכבדים שלי בשוטף על השרת הזה. ככה גם אני משפר את שרידות האתר שלי וגם משפר ביצועים!

אז שלא נדע מצרות אבל שתיהיו מוכנים להם!

תגובה 1:

Oren Ben Shalom אמר/ה...

אכן חשוב מאוד, רצוי שיבינו את חשיבות תוכנית ה BCP בכל ארגון ולמרות העלויות לייצר ולתחזק את אתר ה DR באופן קבוע.