מפתחות לממלכה: ניהול שרת SQL באמצעות גילוי דינמי

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

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

אריק קוואנה: בסדר גבירותיי ורבותיי. ברוך הבא שוב. שמי אריק קוואנה. הדברים חמים. הדברים מתחממים כאן. אני לא יודע מה קורה. אה, זה נכון, הגיע הזמן להוט טכנולוגיות. אכן כן, שמי, שוב, אריק קוואנה. אתה יכול למצוא אותי ב- @eric_kavanagh. זו התוכנית שנועדה לדבר על החם בשוק. הכותרת היום, "מפתחות לממלכה: ניהול SQL Server עם Dynamic Discovery." דברים טובים. יש באמת שלך. אוקיי, התמונה הזו הייתה מלפני כמה שנים. אני לא מתכוון לשקר, אני נראה קצת יותר מבוגר, אבל זה בסדר.

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

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

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

מאגר המידע ההתייחסותי הומצא בשנות ה -70 והתקיים מבחינת אבות-טיפוס בשנות ה -80 וסוג המתיחה שלו בשוק כבר מתחילת שנות ה -90 ואילך. ובסיסי נתונים יחסיים הם עדיין דומיננטיים לחלוטין בפופולריות. אם תקרא את העיתונות תשמע הרבה דברים שנאמרו על אלה - מסדי נתונים של SQL ולאחרונה יש הרבה רעש על מסדי נתונים גרפיים. ואלו מעניינים, אם תרצו, אך למעשה עדיין במספרי המכירות האחרונים, למאגרי מידע יחסיים יש 95% מהשוק. ו- Microsoft SQL Server עליו אנו עומדים לדון בעומק כלשהו היום הוא השני הפופולרי ביותר לאורקל.

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

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

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

וכך המסקנה של השקופית הזו היא שמסדי נתונים הם אסטרטגיים והם מתפתחים, הם משתפרים. וזה בהחלט היה המקרה עם Oracle ו- Microsoft SQL Server. אתם בטח, מעטים מכם זוכרים את הימים בהם הופיעו לראשונה מאגרי מידע, אבל אני הייתי אז ילד. הרעיון המקורי היה שיהיה מאגר נתונים יחיד וזה היה רעיון רעיוני שלעולם לא השתרש. היה ניסיון של יבמ עם ה- AS / 400 לקיים למעשה מערכת קבצים מבוססת בסיס נתונים, אך גם זה לא שלט. נותרה לך העובדה שמאגרי מידע מקוטעים באופן טבעי. יש לך באופן טבעי מקרים מרובים. ישנן סוגיות מדרגיות. בסיס הנתונים מוגדר רק לגודל מסוים, יש להודות כי הגודל גדל עם השנים, אך היו להם גבולות.

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

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

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

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

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

דז בלנשפילד: תודה רבה. אני הולך לקחת אותנו למסע קצת מהנה ואנקדוטלי סביב הסיבה לכך שכל הנושא שהיום עומד עליו והוא קריטי מתמיד. לפני זמן לא רב הייתי מעורב בפרויקט בו העברנו פלטפורמה ממשלתית ממשלתית ששימשה לרישום רישיון ורישום רכב ומגוון שלם של דברים סביב הנושא הזה, מפלטפורמה מרכזית של פוג'יטסו שמפעילה דבר שנקרא A + Addition, שהוא מערכת הפעלה של Solaris, או במילים אחרות, יוניקס, מפעילה את אורקל ועושה את זה עבודה טובה מאוד. והדעה הייתה שהדבר הזה מתיישן והגיע הזמן להעביר אותו למשהו אחר. היה לנו כיף להריץ את יוניקס במיינפריים וזה היה מאוד יציב ומאוד מאובטח ובאופן די מוזר את פלטפורמת SDL וזה פשוט היה מהיר לחלוטין. אבל החוכמה הייתה שהגיע הזמן לרדת מהמסגרת המרכזית ולעבור דירה.

האתגר המשמעותי הזה של מיפוי כל המערכות וההיגיון העסקי וסביבת ה- SQL עבור בסיסי הנתונים שמתחתיו ובחינת איך אנו הולכים לארכיטקט ולהנדס בית חדש עבורו. ובסופו של דבר לקחנו את זה לאחד הדברים האלה שהם כבר כמה שנים, אבל אחד הקצוות העליונים של שרתי ה- Starfire של מערכת Sun rack. וזו ככל הנראה חלק מהפח הגדול ביותר שתוכלו לקנות בכוכב הלכת שכולם חיים בתיבה אחת גדולה ושרת מעבד רב-סימטרי. זו הייתה מערכת בינוניים בעולם שלנו. זה ניהל את יוניקס וזה ניהל את אורקל באופן טבעי והנוף היה, "מה יכול להשתבש?" ובכן, מסתבר, הרבה.

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

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

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

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

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

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

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

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

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

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

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

בולט מאלה: אין בעיה. האם זה טוב יותר?

אריק קוואנה: זה הרבה יותר טוב. קח את זה מפה.

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

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

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

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

וזה מצחיק מכיוון שהמונח, אתה לא יכול לנהל את מה שאתה לא יכול למדוד, תמיד בא עם כלי ביצועים שיש לנו, כמו SQL Diagnostic Manager, אבל אתה באמת לא יכול לנהל שום דבר אם אתה לא יודע את זה "זה" אפילו שם מלכתחילה. כך שזה גם חלק גדול מהכלי הזה, היכולת רק לדעת לדעת שהוא שם.

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

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

ואז החלק האחר של זה מבוסס על המאפיינים האלה, היציאות ודברים אחרים, מפתחות הרישום של WMI וסוגי הדברים האלה, אנו יכולים לאסוף ולוודא ש- SQL ככל הנראה פועלת ומותקנת באותו מופע או בסביבה הספציפית ההיא. ברור שזו שיטה טובה בהרבה משיטת הסניקרס או שיטת sneaker express. כעת, הדבר המגניב הוא שכל המידע אותו אנו אוספים על המופע נשמר במאגר והוא יכול להשתנות ככל שהסביבה תשתנה. זה לא קשור רק "היי, יש מקרה, הנה רשימה שמצאנו", אלא זה כמו ה- DBA, או האדם שמנהל את המופעים, היכולת לקבוע אם הוא רוצה להפוך את החלק הזה למלאי, ואז מתי זה לא חלק מהמלאי, כדי להיות מסוגל להפסיק את המופע הזה. וכך יש להם מחזור החיים של כל התהליך של מופע ה- SQL Server שניתן יהיה להבין אותו בקלות בכלי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אז אם אתה הולך ואתה באמת מתיישב עם DBA ואתה אומר, "תראה, אנחנו יודעים שיש לך 20 מקרים או 10 מקרים אלה מתוך 300 שנמצאים תחת פיקוח עם הכלי הזה שמיועד לפקח על זה ולהתאים ל- SOAs שלך קבל התראות וכל מיני דברים טובים כאלה, "מה שמצאנו גם שאם שאלת" אז מה עם 280 המקרים האחרים שיש לך? אכפת לך מאלה? ", ואכן, אכפת להם מהם, אבל הם פשוט לא רוצים בהכרח לבצע השקעה כדי לפקח על אלה ברמת העומק שניתן לעשות במקרים אלה לעומת אותם 10 או 20 באמת, קריטיים באמת. מקרי מוצר.

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

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

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

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

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

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

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

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

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

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

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

ג'וסלין: אני הולך להפריע לך ממש מהר. לא ראית את ההדגמה שלך.

בולט מאלה: אתה לא?

ג'וסלין: לא.

בולט מאלה: ובכן זה לא טוב, בוא נראה.

אריק קוואנה: אם אתה הולך לפינה השמאלית העליונה, לחץ על התחל, לחץ עליו.

בולט מאלה: אה בסדר.

אריק קוואנה: ועכשיו עשו שתף מסך.

בולט מאלה: מצטער על זה. כן.

אריק קוואנה: זה בסדר. לתפוס שם טוב, המפיק ג'וסלין.

בולט מאלה: בסדר אז זה יותר טוב? אתה רואה את זה עכשיו?

רובין בלור: אכן כן.

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

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

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

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

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

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

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

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

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

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

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

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

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

אריק קוואנה: זה נשמע נהדר. אז רובין? דז? יש שאלות?

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

אריק קוואנה: זה נכון.

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

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

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

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

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

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

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

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

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

דז בלנשפילד: דבר אחד שעולה לי בראש, אוי סליחה לך -

רובין בלור: זה בסדר, אתה הולך בדצמ. התכוונתי לשאול שאלה שאינה רלוונטית אולי.

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

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

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

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

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

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

בולט מאלה: ובכן אני מתכוון שהעניין בזה הוא שמה שאמרת - הכל צריך מסד נתונים עכשיו, אז הרבה פעמים יש הרבה כנראה שיש הרבה מסדי נתונים שהוכנסו לסביבה ש- DBA עצמם לא עשו אפילו מודע לכך כי לא קשה מאוד להתקין שרת SQL בסביבה, באופן כללי.

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

כמה DBA שאני מדבר איתם, אני יכול לחשוב על הפעם האחרונה שהייתי ב- SQL Server PASS, שנמצא בסיאטל, אתה שואל את השאלה "אכפת לך ממסדי הנתונים המהירים שלך?" וזה היה כחמישים וחמישים. חלק מהאנשים, הם רצו לדעת עליהם כ- DBA מכיוון שהם הרגישו שהם חלק מהאחריות שלהם, אפילו אלה שמסרו נתונים שמבטאים שהם עדיין יכולים להכיל מידע קריטי; הם עדיין צריכים לעבור את תהליך הגיבוי ועדיין צריכים לוודא שכל הדברים עובדים מנקודת מבט בריאותית עליהם. אבל עצם הידיעה שהם קיימים חשובה לא פחות אם לא חשובה יותר.

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

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

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

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

בולט מאלה: כן.

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

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

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

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

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

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

בולט מאלה: אם תעבור ל- Idera, I-D-E-R-A.com, תראה, ואני יכול ממש ממש להציג את זה במהירות אמיתית. מעבר לאתר של אידרה אתה תעבור למוצרים, עבור למנהל המלאי. תראה קישור קישור להורדה כאן. אתה רק קובע איזה מבנה ברצונך להתקין על 64 או 32 סיביות, וזה יעבור לך ותוכל להתחיל את הגילוי שלך משם.

רובין בלור: מצגת נהדרת, נהדרת, מצוין, תודה רבה.

בולט מאלה: תודה.

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

בולט מאלה: מצטער על זה.

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

בולט מאלה: תודה.

רובין בלור: אבל היה נהדר לראות גם את זה חי אגב, כל הכבוד.

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