חסכנו מקום וזמן, חסכנו כסף - סקירה בוידאו על הכלי החדש: Virtual Database של idera 

פיצ?ר מדליק חדש נוסף בגרסא הזו הוא מנוע גיבויים ברשת שלא מושפע מתקלות ברשת. זאת אומרת, הכלי הוא network fault-tolerance וזה אומר שהגיבויים יותר לא ייכשלו בגלל packet שהלך לאיבוד או קפיצת מתח בסוויצ?.

למי שלא מכיר את SQLSafe, כמה מילים בכלליות:

מטרת הכלי היא לנהל את כל מדיניות הגיבויים בארגון.

הוא משתמש ב Repository שבו הוא אוגר את הנתוניו לגבי השרתים שהוא מנהל ובאמצעות Agent על השרתים מבצע את הפעילויות. הוא מאפשר לנו להגדיר מספר סטים של מדיניות (בדומה ל policy based management החדש ב - 2008, רק בתחום הגיבויים) וניתן לקשר לכל סט מדיניות שכזה כמה אינסטנסים שנרצה. זאת אומרת - קבוצת שרתי ה SAP תגובה 3 פעמים ביום, קבוצת שרתי השרפוינט תגובה פעם בשבוע וכו?. כמובן שברגע ששרת חורג מהמדיניות (כי אין לו גיבוי תקף או כל סיבהה אחרת) נראה זאת מיד על המסך הראשי.

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

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

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

אההה, דבר נוסף, ניתן לגשת ל DB הוירטואלי באמצעות כל כלי, ממש כאילו זה היה DB רגיל.

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

מהפכני או לא מהפכני??

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

SQLSafe



השוויתי בין שלוש שיטות גיבוי בשני פרמטרים - זמן ומקום בדיסק: (גיביתי DB בגודל של 5389 MB, בעיקר עמודות טקסט)

1) גיבוי native - לקח 3 דקות ו 22 שניות וגודל קובץ הגיבוי היה 3.4 GB

2) גיבוי באמצעות דחיסה של SQL 2008 (קיים רק בגרסת ה enterprise) - לקח דקה ו 21 שניות וגודל קובץ הגיבוי היה 65 MB.

3) גיבוי באמצעות SQLSafe - לקח דקה ו 19 שניות וגודל קובץ הגיבוי היה 12 MB.

אכן, תוצאות יפות מאוד. (חסכון במקום של כ 99%)



בגיבוי של ה AdventureWorks שהוא DB קצת יותר מגוון מהקודם התוצאות היו קצת שונות מן הסתם:

1) גיבוי native - לקח 11 שניות וגודל קובץ הגיבוי היה 168 MB.

2) גיבוי באמצעות דחיסה של SQL 2008 (קיים רק בגרסת ה enterprise) - לקח 7 שניות וגודל קובץ הגיבוי היה 35 MB.

3) גיבוי באמצעות SQLSafe - לקח 6 שניות וגודל קובץ הגיבוי היה 27 MB.

גם כאן אנו רואים שה SQLSafe יעיל יותר אפילו מהדחיסה של ה SQL...



לסיום השוותי בין הזמנים של השחזורים (של ה DB הגדול):

1) שחזור של גיבוי רגיל באמצעות native לקח 4 דקות ו 35 שניות.

2) שחזור של גיבוי דחוס של SQL לקח 4 דקות ו 3 שניות.

3) שחזור גיבוי SQLSafe לקח 3 דקות ו 6 שניות.



Virtual Database



וידוי: אני מתרגש. טוב, אולי אני מגזים..., אבל הכלי הזה פשוט אדיר!
אני מבטיח לכם שאחרי שתראו אותו, תחלקו את חייכם כ DBA לפני ואחרי ה Virtual DB.

מה שהוא עושה, תיאורטית, מאוד פשוט (אין לי שום מושג איך זה קורה, אבל זה נראה - ?פשוט?). הוא לוקח קובץ BAK ובמקום לשחזר אותו הוא יוצר ממנו DB.
לפני תחילת התהליך אנחנו מספקים שם ל DB הוירטואלי החדש, Instance שבו יווצר ה DB ואת קובץ ה BAK ממנו אנחנו רוצים לקרוא.

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

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

אבל זה לא DB רגיל! אין לו קבצים והוא לא תופס מקום (חוץ מה BAK). מה שכן אפשר לעשות איתו זה כמעט הכל:

- להוסיף טבלאות, למחוק טבלאות, לשלוף מידע, להכניס מידע - כל דבר שאפשר לעשות ב DB.

בדקתי קצת יותר לעומק וחקרתי את ה DMV?s כדי לראות איך ה DB הזה מיוצג, אלו התוצאות:
- הוא מופיע כ DB ב sys.databases

- יש לו קבצים וירטואלים שמופיעים ב sys.master_files

- יש לו טבלאות מערכת משלו כגון sys.tables

זה יכול להימשך לנצח, הוא פשוט DB לכל דבר!

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

אחד החסרונות בגרסת ה BETA הנוכחית הוא חוסר התמיכה ב 2008. לא באינסטנס של 2008 ולא בגיבוי של DB מ 2008. אך אל דאגה, בגרסה 1.2 שאמורה לצאת בעוד כ 90 יום, התמיכה ב 2008 תהיה חלק מהמוצר.

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

RedGate SQL Object Level Recovery - מספק יכולות בסיסיות מאוד של שחזור אובייקט ספציפי מתוך קובץ גיבוי. התוכנה יודעת לקרוא את תוכן קובץ הגיבוי ומאפשרת ליצור סקריפט שישחזר רק אובייקט ספציפי. הסבר- היא קוראת את תוכן קובץ הגיבוי ויוצרת סקריפט של create ושל Insert לטבלאות או לכל אובייקט אחר שבחרנו - מכאן אנו יכולים להריץ את הסקריפט בעצמנו או לאפשר לתוכנה להריץ את הסקריפט. לא מחוכם במיוחד ולא מתקרב אפילו ליכולות של VDB- אין כאן DB פעיל שניתן לגשת אליו בכל דרך!

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

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

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

לסיכום, אומנם ל SQLSafe יש מתחרים, אך כשהוא חובר ל VDB הם מציגים ביחד חבילה שעשויה לחסוך זמן רב וחשוב מכך וכנגזרת מכך גם כסף רב.

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



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