none
זיהוי מהיר האם שרת SQL באויר RRS feed

  • שאלה

  • שלום רב

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

    האם ניתן לזהות מיידית ששרת אינו זמין?

    תודה

    אירה


    אריה שטרן

    יום שני 20 יוני 2016 08:46

תשובות

  • אהלן אריה,

    יש עוד משהו שאפשר לעזור או לדון בו?
    אני לא חושב שיש לי מה להוסיף על מה כתבתי :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    • סומן כתשובה על-ידי אריה שטרן יום ראשון 03 יולי 2016 12:13
    יום ראשון 03 יולי 2016 11:28
    מנחה דיון
  • בעבר, כתבתי קוד קצר לביצוע PING ל IP של השרת המרוחק וביצעתי TELNET ל PORT מסוים. זה נתן תשובה מהירה אם השרת באוויר, ורק במקרה של תשובה חיובית ניסיתי לפתוח CONNECTION. באותם מקרים שהשרת לא זמין התשובה מהירה למדי (דגמתי זמני התגובה כשהשרת באוויר לאורך תקופה, וקבעתי את הסף בהתאם)

    • נערך על-ידי Israel H יום שני 04 יולי 2016 18:45
    • נערך על-ידי pituachMVP, Editor יום שלישי 05 יולי 2016 04:13 פירמוט ההודעה - הטקסט היה קטן מאוד ובילתי קריא בעקבות באג בפורום כאשר מעבירים את הטקסט למצב מימין לשמאל
    • סומן כתשובה על-ידי pituachMVP, Editor יום שישי 08 יולי 2016 20:50
    יום שני 04 יולי 2016 18:29

כל התגובות

  • sp_who פקודה ב sql

     

    כמובן מומלץ שימוש בשרת לניטור

    scom 

    הסרויס ולניטור הפרוסס.


    יום שני 20 יוני 2016 12:51
  • אהלן ניר וברוך הבא לפורום.
    אם יורשה לי, אני אמשיך את הרעיון השני שלך :-)

    תחילה לגבי הרעיון הראשון וקצת באופן כללי:

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

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

    * גם אם אנחנו עובדים עם System Center Operations Manager - SCOM עדיין צריך להתחבר למשהו שיכול להיות שהוא נפל...

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

    יותר מכך!!!

    נניח שאתה מבצע חיבור מאפליקציה לשרת מרוחק... השרת חי ושמח, אבל האפליקציה מנותקת?!?
    ז"א מה אם המכונה שעליה יושבת האפליקציה מנותקת אבל השרת חי?

    ישנם כמה אפשרויות שעומדות בפנינו וקשורות לארכיטקטורה של מערכת מסדי הנתונים שלנו והרשת שלנו. בלי מידע נוסף והכרת המערכת אני יכול רק להציג דברים כלליים :-)

    > נסתמך על הרעיון של ניר, ניתן להקים שרת או אפליקציה קטנה (עדיף במקרה שכל הצורך הוא לשמור נתון של חי/מת) אשר אנחנו בטוחים שהוא שמין וחיי תמיד. כאן זה מקום טוב כן לעשות שימוש למשל ב AZURE, מתוך הנחה שהזמינות שלו קרוה ל 100%. אנחנו יכולים להקים למשל שירות web app כמו Azure function או שירות WCF שיפנו את השרת כל X שניות ויבדקו אם הוא חי. השירות ישמור את הנתון בזכרון ואנחנו יכולים לפנות אליו לפני החיבור למסד הנתונים על מנת לוודא האם השרת SQL חי כרגע או לא (זה לא בדיוק כרגע אבל קרוב מאוד).

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

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

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

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

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

    אני מציע לחפש בגוגל כיצד להגדיר configure timeout connection בהתאם לטכנולוגיות והשפות בהם אתם עובדים בפיתוח. למשל בקישור הבא יש פתרונות לעבודה עם SignalR.

    מייקרוסופט ממליצים להגידר זמן בעבודה עם SQL ב AZURE של 30 שניות. ברירת המחדל אם לא הגדדרת כלום בשרשרת ההתחברות הוא של 15 שניות. אם אתה בטוח שיש לכם רשת מהירה אתה יכול להגדיר זמן קצר יותר. בקירו הבא אתה כיול לראות מאפייני התחברות לשרת וכיצד לבצע הגדרה של הזמן כאשר עובדים עם המחלקה SqlConnection.ConnectionString של דוט-נט.

    > וכן הלאה...


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]


    יום שני 20 יוני 2016 16:18
    מנחה דיון
  • מה זה מייד?!?

    חיבור לוקח זמן...
    האם שנייה זה מייד מבחינתך או אלפית שנייה או אולי 15 שניות?

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

    תעבור על ההודעה שכתבתי בהמשך לפרטים נוספים :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום שני 20 יוני 2016 16:20
    מנחה דיון
  • תודה למגיבים.

    מייד, לצורך העניין, 100 MS


    אריה שטרן

    יום שלישי 21 יוני 2016 06:02
  • מה זה MS 100 ?!?

    לא הבנתי מה ההפתעה שמצפה לנו :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום שלישי 21 יוני 2016 09:01
    מנחה דיון
  • עומדת בפני בעיה.

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

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

    אריה


    אריה שטרן

    יום שלישי 21 יוני 2016 10:28
  • כפי שהזכרתי, המילה "מיידית" אינה רלוונטית מפני שאתה לא יכול להתחבר מיידית לשום שרת מרוחק. החיבור לוקח זמן

    * כפי שאני אומר תמיד אי אפשר לייעץ מה לעשות ולתת לך המלצה לארכיטקטורה של אפליקציה בלי להכיר את המערכת לעומק וכמובן את כל האפיון שלכם :-(

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

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

    ** אם אתה עובד עם אפליקציית WEB למשל אזייתכן ששימוש ב AJAX בדיוק מתאים לכם
    AJAX stands for Asynchronous JavaScript and XML


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]





    יום שלישי 21 יוני 2016 11:06
    מנחה דיון
  • רונן ואריה שלום,

    קראתי את המשך התשובות שלכם,

    ראשית לא לכולם יש scom או oms בענן.

    במידה ויש scom2012 למיטב ידיעתי ניתן להגדיר APM

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

    IIS - שתשלח התראה במידה ואין גישה לשירות יחד עם בדיקות זמנים.

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


    יום רביעי 22 יוני 2016 18:33
  • אהלן אריה,

    יש עוד משהו שאפשר לעזור או לדון בו?
    אני לא חושב שיש לי מה להוסיף על מה כתבתי :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    • סומן כתשובה על-ידי אריה שטרן יום ראשון 03 יולי 2016 12:13
    יום ראשון 03 יולי 2016 11:28
    מנחה דיון
  • תודה לכולם !


    אריה שטרן

    יום ראשון 03 יולי 2016 12:14
  • בעבר, כתבתי קוד קצר לביצוע PING ל IP של השרת המרוחק וביצעתי TELNET ל PORT מסוים. זה נתן תשובה מהירה אם השרת באוויר, ורק במקרה של תשובה חיובית ניסיתי לפתוח CONNECTION. באותם מקרים שהשרת לא זמין התשובה מהירה למדי (דגמתי זמני התגובה כשהשרת באוויר לאורך תקופה, וקבעתי את הסף בהתאם)

    • נערך על-ידי Israel H יום שני 04 יולי 2016 18:45
    • נערך על-ידי pituachMVP, Editor יום שלישי 05 יולי 2016 04:13 פירמוט ההודעה - הטקסט היה קטן מאוד ובילתי קריא בעקבות באג בפורום כאשר מעבירים את הטקסט למצב מימין לשמאל
    • סומן כתשובה על-ידי pituachMVP, Editor יום שישי 08 יולי 2016 20:50
    יום שני 04 יולי 2016 18:29
  • רעיון מעולה!

    החיבור לשרת ה SQL לוקח זמן נוסף למציאת המכונה עצמה

    בהחלט רעיון טוב מאוד

    +5


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום שלישי 05 יולי 2016 04:10
    מנחה דיון
  • אתמול בכינוס היסכמנו שאין בעיות בילתי פתירות, רק לצאת מהקופסא / כסף
    יום שלישי 05 יולי 2016 06:26
  • LOL :-)

    אני שמח שמשהו  תפס

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

    הבלוג מתחיל ככה:

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

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

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

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

    ...

    --- בקיצור אני מסכם עם ציון 2 על האירוח ומנהלה, וציון 10 למנשתתפים (ציון להרצאה רק אחרים יכולים לתת)... ---

    * אני אפרסם תוך כמה ימים את כל הדוגמאות קוד והמצגת המלאה...


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]



    יום שלישי 05 יולי 2016 10:06
    מנחה דיון