none
השפעות של פרוצדורות וטבלה אחת על השניה RRS feed

  • שאלה

  • היי.

    בעיה שאני מתמודד איתה:

    יש לי פרוצדורה אחת שמקצה משאבים לאירועים (לצורך הדוגמא נקרא לה spr_allocate), ופרוצדורה אחת שנותנת רשימה של האירועים, שמושפעת מההקצעות (נקרא לה spr_list).

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

    אבל, כאשר אני מריץ את spr_allocate - בתקופת זמן מסויימת לאחר מכן (כשעתיים) - כל פעם שאריץ את spr_list היא תרוץ בזמן של מעל דקה!

    חילקתי את הבעיה לכמה חלקים:

    1. שיפור spr_list - שיפרתי את הביצועים עד למצב שהרשימה עולה מייד (כאשר בלי השיפור היא עולה אחרי דקה בערך)

    2. מציאת הגורם לכך שאחרי הרצת spr_allocate ביצועי spr_list מורעים בצורה קיצונית כ"כ.

    לכאורה, השיפור בסעיף 1 היה יכול לסדר אותי, אבל מכיוון שעדיין חשוב להבין התופעה של סעיף 2 לא הטמעתי את השינוי והמשכתי לחפור.

    אני מנסה להבין מה קורה לאחר שמסתיימת ההרצה של spr_allocate שעדיין חוסם\נועל\WHATEVER ומשפיע על דברים אחרים. לא מצאתי סימנים לנעילות או משהו דומה (אבל אולי פספסתי?)

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

     

    dbcc freeproccache

    go

    dbcc dropcleanbuffers

    go

     

    ביצועי spr_list משתפרים מייד, ללא קשר למתי רצה spr_allocate.

    יש משהו שאני יכול לעשות כדי לנקות את ה-cache בצורה מסויימת מתישהו שלא תיקרה הבעיה הנ"ל?

    דבר נוסף: ה-DB עדיין קטן, אבל גליתי שטבלת ההקצעות גדלה מ-250 שורות ל-380 לאחר הרצת spr_allocate - עלייה של כמעט 50% במספר הרשומות.

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

    dbcc dbreindex ('TABLENAME', '')

    שיפרה את הרצת spr_list , אבל לא לזמן מספק.

     

    רעיונות לנסיבות התופעה?

    תודה, איתי.


    itaigitt, http://copypastenet.blogspot.com

    • נערך על-ידי itaigitt יום שני 19 ספטמבר 2011 08:45
    יום שני 19 ספטמבר 2011 08:43

תשובות

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

    הבעיה אכן הייתה, כמו שהיה נראה מהתחלה, בשינויים ב-PLANS וכו' שנגרמו כתוצאה מהשינוי הגדול (באחוזים) בטבלת ההקצאות, שקראנו לה AllocationsTable.

    לכן, freeproccache ו-dropcleanbuffers ניקו את ה-cache ה"מלוכלך" ופתרו את הבעיה. 

    הסיבה ש-WITH RECOMPILE על הפרוצדורה לא עבד (ובעצם בגלל זה לא נסגר הפוסט כבר מזמן) היא שהבעייתיות בפרוצדורה spr_list (שגם תוקנה על ידי כמו שרשמתי), הייתה בעצם בקריאה לפונקציה, והתיקון\שיפור נעשה בפונקציה ולא בפרוצדורה - ובמקרה כזה WITH RECOMPILE לא משפיע. גם OPTION (RECOMPILE) לא יעזור במקרה הזה.

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

    לסיכום, אלו זמני הריצה:

    בזמן הבעיה: 

    • הרצה רגילה - בעייה, מעל דקה.
    • הרצת התיקון שלי בפונקציה - כ-5 שניות. טוב לנו (כאמור, לא מדובר פה על פתרון מקסימלי אלה מספק).
    • RECOMPILE בצורותיו השונות - לא משפיע כמו שרשמתי, מעל דקה.
    • הרצת הפונקציה כפרוצדורה - 5 שניות. טוב!
    • הרצת הפונקציה כפרוצדורה עם התיקון שלי - 4 שניות. טוב!

    בזמן "רגיל", כשהבעיה לא משתחזרת (cache נקי):

    • הרצה רגילה - הרצה ראשונה כ-6 שניות, כאשר ההרצה נכנסת ל-cache - 1-2 שניות.
    • הרצת התיקון שלי בפונקציה - באופן לא ברור (כי התיקון לא אמור להיות מושפע משום דבר....) - תמיד כשניה מעל ההרצה הרגילה, אבל עדיין בסדר.
    • RECOMPILE בצורותיו השונות - כמו בריצה רגילה, כי כאמור הוא לא משפיע - לא משפר ולא מזיק.
    • הרצת הפונקציה כפרוצדורה - כמו בריצה רגילה.
    • הרצת הפונקציה כפרוצדורה עם התיקון שלי - כמו בריצה רגילה.

    זהו, נפתרה התעלומה.

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

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

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

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


    itaigitt, http://copypastenet.blogspot.com
    • סומן כתשובה על-ידי itaigitt יום שני 26 ספטמבר 2011 06:32
    יום שני 26 ספטמבר 2011 06:32

כל התגובות

  • לדעתי מה שקורה זה שתוכנית הביצוע של הפרוצדורה spr_list נבנית על בסיס סטטיסטיקות שהיו נכונות לפני ההרצה של ה- spr_allocate.

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

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

    ע"מ לבדוק את התרחיש, מה שאתה צריך לעשות זה להוסיף לקריאה של spr_list את הפקודה with recompile ולראות האם זמן הריצה ישתפר.

    במידה וכן אז זו הסיבה ובמידה ולא יש לי עוד כמה כיוונים לבדיקה אז תעדכן אותנו  .

    יום טוב


    אסף שלם
    יום שני 19 ספטמבר 2011 10:43
  • היי אסף ותודה.

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


    itaigitt, http://copypastenet.blogspot.com
    יום שני 19 ספטמבר 2011 11:10
  • איתי זה ממש מאכזב כשזה בה ממישהו כמוך :-(
    * זו מחמאה כי ציפתי ממך להרבה יותר :-)

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

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

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

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

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

    יום שני 19 ספטמבר 2011 11:13
    מנחה דיון
  • הי איתי,

    תצרף את הפלט של ה- Statistics Io לפני טעינת הארועים

    היינו תריץ

    Set statistics io on

    exec spt_list

    ואחרי טעינת הארועים.

    במידה ויהיה שינוי גדול ב- Physical reads אזי העיקוב הוא בהחלפת הPages ב- cache. 

    במידה ולא עדין אפשר להבין מה המשאב "המעקב"

     


    אסף שלם
    יום שני 19 ספטמבר 2011 11:39
  • היי.

    אסף - נסיתי, לצערי זה לא זה.

    רונן - קודם כל תודה על המחמאה :-).

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

    דבר נוסף - יש בעיות בקוד, אני יודע, וכמו שרשמתי למעלה, את spr_list כבר שיפרתי לאפס זמן.

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

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


    itaigitt, http://copypastenet.blogspot.com
    יום שני 19 ספטמבר 2011 12:05
  • היי.

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

    גם כאשר אני מריץ את הפרוצדורות בטרנזקציה, ואחרי ה-rollback מריץ שוב את spr_list, מתרחשת הבעייה:

     

    begin tran

    exec spr_allocate ...

    exec spr_list ...

    rollback tran

    exec spr_list ...

     

    השוויתי execution plans לפני הטרנזקציה (שרץ מהר) ואחרי (שרץ לאט) - וזה נראה אותו דבר. יכול להיות שזה רמז לזה שהעניין הוא לא ב-execution plan.

    שוב - זה לא בטוח כי freeproccache+dropcleanbuffers מסדרים את העניין ו-spr_list חוזרת לרוץ מהר.

    אגב, ה-execution plan נראית בסדר.

    כאשר הצגתי extimated execution plan הוא המליץ לי על אינדקס כלשהו. ההמלצה הזו לא עזרה, אז לא קבלתי אותה....

     

    אולי עכשיו למישהו יהיו עוד רעיונות????? תודה!


    itaigitt, http://copypastenet.blogspot.com
    יום שלישי 20 ספטמבר 2011 08:22
  • הי איתי,

    שתי שאלות:

    1. אם במקום Rollback אתה עושה Commit זה גם רץ לאט?

    2. האם אתה מריץ את הפקודה exec spr_list כהמשך ל- Rollback או ב- Session אחר?

    יום טוב,


    אסף שלם
    יום שלישי 20 ספטמבר 2011 09:42
  • היי אסף ותודה.

    1. כן. ה-Rollback זה סתם בשביל הנוחות. 
    2. לא כהמשך ל-Rollback.

    מה שכן, זה שגם במקרה של Rollback וגם במקרה של Commit הפרוצדורה השניה רצה לאט זה מוזר מבחינתי מהעניין של ה-execution plan - כי ה-PLAN אמורה להיות מושפעת מ-spr_allocate בצורה זהה בשני המקרים, אבל ה-DATA בזמן הרצת spr_list אינו זהה (Commit/Rollback) - ובשני המקרים התוצאה היא איטיות.

    אגב, לאחר freeproccache+dropcleanbuffers זמן הרצת spr_list בפעם הראשונה הוא 4-5 שניות, ובפעמים הבאות 0-1 שניות, כלומר אחרי נקיון ה-cache והרצת הפרוצדורה בפעם הראשונה נבנית איזושהי PLAN שטובה להרצות הבאות. משהו ב-spr_allocate משבש משהו איכשהו, וזאת בעצם החידה פה.....

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


    itaigitt, http://copypastenet.blogspot.com
    יום שלישי 20 ספטמבר 2011 10:25
  • הי,

    spr_allocate יכול לשבש בשתי צורות:

    1. משנה באופן משמעותי את הנתונים כך שה- plan שקיים ב- Cache עבור spr_List משמעותית לא אופטימלי.

    2. התהליך spr_allocate ממלא את ה- Cache ב- Data pages שלא רלוונטים להרצה של spr_list ולכן בזמן ההרצה הראשונית של spr_list יש לייבא את הדפים (4-5 שניות) Physical read ובנוסף כמובן יצירת תוכנית הביצוע. וההרצות הבאות כבר מבצעות בעיקר logical reads מככון שהדפים כבר ב- Cache.

    זה בגדול מה שאני חושב שקורא


    אסף שלם
    יום שלישי 20 ספטמבר 2011 10:41
    1. זאת הייתה גם ההשערה הראשונית שלי. אבל, גם כשאני משתמש ב-WITH RECOMPILE (בהרצת הפרוצדורה או בקוד של הפרוצדורה) זה לא פותר את הבעייה.
    2. אשמח אם תפרט עוד קצת על האפשרות הזאת, ועל פתרון אפשרי. תודה!

    itaigitt, http://copypastenet.blogspot.com
    יום שלישי 20 ספטמבר 2011 10:58
  • הי,

    ה- With recompile רק פותר את עניין ה- execution plan.

    לדעתי יש גם עניין של physical reads.

    תריץ את התהליך עם set statistics io on בשני המקרים ותראה האם יש הבדל משמעותי בכמות ה- Physical reads.

    אני הסביר:

    נניח שה- cache ריק מנתונים, היינו אחרי reastart של ה- SQL Server service.

    בזמן הרצה ראשונית של פרוצדורה יש להביא את הנתונים שרלוונטים לשאילתא מהדיסק ל- Cache.

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

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

    בקצרה:

    הרצה ראשונה צריכה להביא נתונים ל- cache וההרצות הבאות כבר "נהנות" מהמידה ששמור ב- Cache.

    כמובן שזמן קריאה מה- cache לאומת הדיסק הוא מהיר בעשרות מונים.

     


    אסף שלם
    יום שלישי 20 ספטמבר 2011 11:31
  • physical reads 0, בכל המקרים....

    אני בטוח מפספס פה משהו.... כי זה בטוח משהו עם ה-cache, אבל מה?????


    itaigitt, http://copypastenet.blogspot.com
    יום שלישי 20 ספטמבר 2011 12:07
  • הי,

    בהחלט משונה, תנסה בעזרת הפקודה הנ"ל לראות מה לוקח זמן

    SET

    STATISTICS TIME ON

    במידה וזה עדין לא ברור אתה יכול להפעיל פרופיילר ולנסות למצוא את הסיבה.

    במידה וזה עדין בגדר תעלומה אשמח אם תוכל לשתף איתי את ה- Desktop (יש לי סיווג ביטחוני :) ) ונדבג את זה ביחד.

    ערב טוב


    אסף שלם
    יום שלישי 20 ספטמבר 2011 14:00
  • שוב שלום....

    ה- STATISTICS TIME ON לא נתן לי הרבה לצערי....

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

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

    אני אוסיף עוד כמה דברים שיוכלו אולי לעזור:

    כמו שרשמתי למעלה, spr_allocate מקצה משאבים לאירועים, כלומר מוסיפה שורות לטבלת ההקצאות, נקרא לה לצורך העניין AllocationsTable.

    במקרים שאני בודק, השינוי הוא אכן גדול - מאיזור ה-120-150 שורות לאיזור ה-280, כלומר סביב 50%. זה אכן יכול לגרום לשינויים ב-PLAN, סטטיסטיקות וכל מה שכבר נאמר פה, ולכן החשד שלי ושל רוב מי שניסה לעזור לי היה בכיוון ה-CACHE.

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

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

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

     

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

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

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

    with recompile היה אמור לעזור, אבל משום מה הוא לא עזר. מה עוד יכול להיות???


    itaigitt, http://copypastenet.blogspot.com
    יום חמישי 22 ספטמבר 2011 09:26
  • הי,

    יש לך אולי רישום ל- notifications על הטבלה?

    יש תהליך ברקע שרץ ואולי מושפה משינויים בטבלה הזו.

    אולי משהו שמתוזמן ברקע ע"י Job?

    יש רפליקציות או מירור לטבלה?

     


    אסף שלם
    • נערך על-ידי Assaf_Shalem יום חמישי 22 ספטמבר 2011 09:35
    יום חמישי 22 ספטמבר 2011 09:34
  • התשובה לכל השאלות היא שאין....
    itaigitt, http://copypastenet.blogspot.com
    יום חמישי 22 ספטמבר 2011 10:28
  • תופעה מעניינת, יש מצב מחר או מתי שנוח לך לאיזה Session קצר של שנינו על השרת?

    אין לי ספק שנמצא את הפתרון


    אסף שלם
    יום חמישי 22 ספטמבר 2011 11:11
  • אני מתכוון להגיע עם לפ-טופ דרכו אוכל להראות את המקרה ביום א' ב-USER GROUP
    itaigitt, http://copypastenet.blogspot.com
    יום חמישי 22 ספטמבר 2011 14:31
  • איתי/אסף

    אני מקווה שאגיע לפגישה של ראש השנה אבל לא בטוח שאוכל (תלוי בכמה עבודה אספיק לבצע בסוף השבוע)

    אנא תזכרו לעלות את הממצאים לפורום :-)

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

    הבעיה אכן הייתה, כמו שהיה נראה מהתחלה, בשינויים ב-PLANS וכו' שנגרמו כתוצאה מהשינוי הגדול (באחוזים) בטבלת ההקצאות, שקראנו לה AllocationsTable.

    לכן, freeproccache ו-dropcleanbuffers ניקו את ה-cache ה"מלוכלך" ופתרו את הבעיה. 

    הסיבה ש-WITH RECOMPILE על הפרוצדורה לא עבד (ובעצם בגלל זה לא נסגר הפוסט כבר מזמן) היא שהבעייתיות בפרוצדורה spr_list (שגם תוקנה על ידי כמו שרשמתי), הייתה בעצם בקריאה לפונקציה, והתיקון\שיפור נעשה בפונקציה ולא בפרוצדורה - ובמקרה כזה WITH RECOMPILE לא משפיע. גם OPTION (RECOMPILE) לא יעזור במקרה הזה.

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

    לסיכום, אלו זמני הריצה:

    בזמן הבעיה: 

    • הרצה רגילה - בעייה, מעל דקה.
    • הרצת התיקון שלי בפונקציה - כ-5 שניות. טוב לנו (כאמור, לא מדובר פה על פתרון מקסימלי אלה מספק).
    • RECOMPILE בצורותיו השונות - לא משפיע כמו שרשמתי, מעל דקה.
    • הרצת הפונקציה כפרוצדורה - 5 שניות. טוב!
    • הרצת הפונקציה כפרוצדורה עם התיקון שלי - 4 שניות. טוב!

    בזמן "רגיל", כשהבעיה לא משתחזרת (cache נקי):

    • הרצה רגילה - הרצה ראשונה כ-6 שניות, כאשר ההרצה נכנסת ל-cache - 1-2 שניות.
    • הרצת התיקון שלי בפונקציה - באופן לא ברור (כי התיקון לא אמור להיות מושפע משום דבר....) - תמיד כשניה מעל ההרצה הרגילה, אבל עדיין בסדר.
    • RECOMPILE בצורותיו השונות - כמו בריצה רגילה, כי כאמור הוא לא משפיע - לא משפר ולא מזיק.
    • הרצת הפונקציה כפרוצדורה - כמו בריצה רגילה.
    • הרצת הפונקציה כפרוצדורה עם התיקון שלי - כמו בריצה רגילה.

    זהו, נפתרה התעלומה.

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

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

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

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


    itaigitt, http://copypastenet.blogspot.com
    • סומן כתשובה על-ידי itaigitt יום שני 26 ספטמבר 2011 06:32
    יום שני 26 ספטמבר 2011 06:32