none
TIMEOUT הזוי שנפתר ע"י RECOMPILATION, אך לא ברור למה. RRS feed

  • שאלה

  • היי.

    לפני כמה ימים שאלתי פה שאלה בקשר למציאת recompilations:

    http://social.technet.microsoft.com/Forums/he-IL/sqlhe/thread/0c39d47e-e5c5-4c7d-8825-f8ab7ab68ca5

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

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

    • הפרוצדורה יכולה לרוץ מכמה מקומות (=בכמה מסכים באפליקציה).
    • חלק מהמידע לא תמיד מוחזר (לפי פרמטר).
    • 9 פרמטרים מועברים לפרוצדורה, על פי הפרמטרים מתבצעים הפילטורים.
    • הפרוצדורה קוראת לפונקציה טבלאית (מהסוג שמתנהג כמו VIEW), ואז מוסיפה JOIN-ים לעוד טבלאות.

    מה עשיתי עד עכשיו?

    הוספתי אינדקסים - לא משמעותי.

    קריאה מהפרוצדורה לארבע פרוצדורות לפי מקרים - ע"מ שתיווצר EXECUTION PLAN לכל מקרה וככה כל מקרה יהיה עם הבעיות שלו ולא יפריע לאחרים.

    החלוקה הייתה לפי:

    1. פעילויות מכל המערכת + מידע נוסף כלשהו נדרש.
    2. פעילויות מכל המערכת + מידע נוסף כלשהו לא נדרש.
    3. פעילויות ממקור ספציפי + מידע נוסף כלשהו נדרש.
    4. פעילויות ממקור ספציפי + מידע נוסף כלשהו לא נדרש.

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

    אגב, כדי שיהיה יותר כיף, התקלה משתחזרת רק ב-PRODUCTION של הלקוח, לא בשום מצב אצלי (כולל על DB כמעט זהה!).

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

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

    איפה אני עומד עכשיו?

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

    אולי כדי בפרוצדורה לעשות כמה תת שאילתות שיכניסו DATA מפולטר לטבלאות זמניות (או משתני טבלה) - כמה שידוע לי ביותר מדי JOIN-ים יש מצב להתבלבלות של האופטימייזר.

    האם זה האופטימייזר שמתחרפן? ולמה רק אצל הלקוח ולא אצלי?

    ישמצב שסתם עדכון סטטיסטיקות או משהו כזה יעזור?

    ואם כל זה לא ניתן לפתרון - יש למישהו פסיכולוג טוב??? :-)

    אשמח לעזרה, אם נדרש עוד מידע אביא עד כמה שאוכל.

    תודה מראש, איתי.

    אגב - קראי גם את השרשור הזה שנראה שמדבר על מקרה דומה, אבל לא מצאתי משהו בשבילי (או שיש ופספסתי אותו....)

    http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/29b1596c-61b2-4479-8692-11f724297f51/


    itaigitt, http://copypastenet.blogspot.com

    יום שני 29 אוקטובר 2012 14:46

תשובות

  • הי איתי,

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

    עוד דבר שהייתי עושה זה לנתח את ה-Wait Types בזמן שהשאילתה שלך רצה. בדוק את sys.dm_os_waiting_tasks ואת sys.dm_exec_requests. העובדה שהשאילתה מתנהגת בצורה שונה ב-Production ובסביבה שלך היא לא מפתיעה. אני בטוח שיש הרבה הבדלים בין הסביבות (תמיד יש). לדוגמא, יכול להיות שאצלך הסטטיסטיקות מעודכנות, וב-Production לא. יכול להיות שבגלל שהחומרה לא זהה, אצלך ה-Execution Plan הוא טורי, ואילו ב-Production הוא מקבילי, או ההיפך. יכול להיות שיש לך בכלל בעיה ב-Storage ב-Production, שלא קיימת בסביבה שלך... ה-Wait Type עשוי לתת לך רמז לסיבה שבגללה השאילתה שלך תקועה ב-Production.

    אין דרך לקבל בסקריפט את ערכי הפרמטרים בכל ריצה של ה-Stored Procedure, מכיוון שזה לא נשמר בשום מקום. לשם כך אתה צריך להריץ SQL Trace או Event Session, לשמור את התוצאות ואחר-כך לנתח אותן. אגב, אם בחרת להשתמש ב-SQL Trace, אני ממליץ בחום על Qure Analyzer. הכלי (החינמי) הזה עושה בשבילך את כל עבודת הניתוח של ה-Trace ומציג לך בצורה מאוד נוחה את כל ערכי הפרמטרים בכל ריצה של כל Stored Procedure.

    הלינק שצירפת בסוף מדבר על Timeout של ה-Optimizer ולא על Timeout של השאילתה. אני לא בטוח שזה קשור למקרה שלך...

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

    בהצלחה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    • הוצע כתשובה על-ידי pituachMVP, Editor יום שלישי 30 אוקטובר 2012 07:08
    • סומן כתשובה על-ידי Eran Sharvit יום רביעי 31 אוקטובר 2012 13:18
    יום שלישי 30 אוקטובר 2012 04:58
    מנחה דיון

כל התגובות

  • הי איתי,

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

    עוד דבר שהייתי עושה זה לנתח את ה-Wait Types בזמן שהשאילתה שלך רצה. בדוק את sys.dm_os_waiting_tasks ואת sys.dm_exec_requests. העובדה שהשאילתה מתנהגת בצורה שונה ב-Production ובסביבה שלך היא לא מפתיעה. אני בטוח שיש הרבה הבדלים בין הסביבות (תמיד יש). לדוגמא, יכול להיות שאצלך הסטטיסטיקות מעודכנות, וב-Production לא. יכול להיות שבגלל שהחומרה לא זהה, אצלך ה-Execution Plan הוא טורי, ואילו ב-Production הוא מקבילי, או ההיפך. יכול להיות שיש לך בכלל בעיה ב-Storage ב-Production, שלא קיימת בסביבה שלך... ה-Wait Type עשוי לתת לך רמז לסיבה שבגללה השאילתה שלך תקועה ב-Production.

    אין דרך לקבל בסקריפט את ערכי הפרמטרים בכל ריצה של ה-Stored Procedure, מכיוון שזה לא נשמר בשום מקום. לשם כך אתה צריך להריץ SQL Trace או Event Session, לשמור את התוצאות ואחר-כך לנתח אותן. אגב, אם בחרת להשתמש ב-SQL Trace, אני ממליץ בחום על Qure Analyzer. הכלי (החינמי) הזה עושה בשבילך את כל עבודת הניתוח של ה-Trace ומציג לך בצורה מאוד נוחה את כל ערכי הפרמטרים בכל ריצה של כל Stored Procedure.

    הלינק שצירפת בסוף מדבר על Timeout של ה-Optimizer ולא על Timeout של השאילתה. אני לא בטוח שזה קשור למקרה שלך...

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

    בהצלחה!

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    • הוצע כתשובה על-ידי pituachMVP, Editor יום שלישי 30 אוקטובר 2012 07:08
    • סומן כתשובה על-ידי Eran Sharvit יום רביעי 31 אוקטובר 2012 13:18
    יום שלישי 30 אוקטובר 2012 04:58
    מנחה דיון
  • היי גיא, תודה.

    הלוואי והייתי יכול לנתח את ה-Execution Plan של השאילתה.... אין לי גישה ל-TRACE אצל הלקוח, ואין לי גם את ה-Execution Plan.

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


    itaigitt, http://copypastenet.blogspot.com

    יום שלישי 30 אוקטובר 2012 08:43