השוואה בין 2 SP's

[AvidaEinav]

השוואה בין 2 SP's

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

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

וכאן השאלות:
1. איזה שורות קוד צריך לכתוב על מנת לבצע בחינה אמיתי כמו שצריך
2. האם שימוש ב DBCC DROPCLEANBUFFERS וכל השאר, לא מוחקים את המידע שנאגר באותו DB? מה שיגרום לכל ה SP's לעבוד לאט.

אני עובד על MS SQL 2008

תודה מראש לעונים..

 

[pitoach]

DBCC FREEPROCCACHE

Using DBCC FREEPROCCACHE will clear the procedure cache and remove all cached query plans.

 

[AvidaEinav]

בהמשך לשאלה..

תודה על התשובה,
אם הבנתי נכון מחומר שקראתי על מה שכתבת,הפקודה הזאת משחררת את המידע מכל הDB.. אני משתמש ב DB שהוא Production ואין לי אפשרות לעשות את זה.. הבנתי שצריך למצוא את ה plan handle של SP מסויים:
Remove one plan from the cache--
Get the plan handle for a cached plan--
[SELECT cp.plan_handle, st.[text
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
'%WHERE [text] LIKE N'%/* GetOnlineSearchResultsMonday
ולהריץ את הפקודה עם התוצאה :
DBCC FREEPROCCACHE (0x05000800F7BA926C40C15055070000000000000000000000);
ואת כל התהליך הזה צריך לעשות לפני כל בדיקה של SP..

האם הבנתי נכון? כי זה לא נשמע הגיוני..אני רוצה לאפס ספציפית SP's מסויימים והאם אני צריך לשים את זה בתוך ה SP או להריץ את זה לפני שאני מריץ אותו?

תודה

 

[AvidaEinav]

עוד אופציה

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

 

[pitoach]

2 נקודות

1. שימוש ב with recompile הוא רמז (hint) שקובע לא לעשות שימוש בתוכנית ההרצה הקיימת אבל זה לא ינקה את מסד הנתונים ממה שקיים.

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

אם יש לי שאילתה אחת שזמן הקימפול שלה הוא שעה אבל היא רצה אחרי הקימפול בשניה ויש לי שאילתה שנייה שזמן הקימפול שלה הוא שנייה אבל אחרי הקימפול היא רצה שעה אז מה יהיה עדיף לך?!?

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

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

 

[AvidaEinav]

אז מה עושים כדי לדעת???

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

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

 

[pitoach]

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

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

כך שהתשובה היא כמובןם כן זה יעזור ואין צורך לנקות הכל

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

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


לסיכום: בשלב זה (של תמיכה תיאורטית בפורום) הייתי מציע לך לבדוק בנפרד את השאילתות בתוך ה SP, לבדוק את ה SP עם ניקוי מלא (של מה שקשור אליהם בלבד), ולסיום לבדוק את המצב אחרי שכל הרקע מוכן (תריץ איזה 10 פעמים ותבדוק רק את הפעם ה 11 למשל בלי ניקוי)

ואז בסיום תבצע הערכה שלך מתוך הכרות של המערכת ו"ניחוש"

 

[AvidaEinav]

עוד בעניין שיפור ביצועים..

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

תודה על הזמן,ההשקעה והידע היקר.

 

[pitoach]

כתבתי על זה פעם בלוג

אתה יכול לקרוא שם

SELECT-INTO-BULK-INSERT-vs-INSERT-INTO
http://ariely.info/Blog/tabid/83/EntryId/79/SELECT-INTO-BULK-INSERT-vs-INSERT-INTO.aspx

אם משהו לא מכוסה שם תרשום לי נקודות ואני אוכל להוסיף לשם בצורה מסודרת

 

[AvidaEinav]

לפי מה שהבנתי שכתוב שם

הנעילה אמורה להיות זהה במצב שמעבירים כמות גדולה של נתונים ב 2 השיטות:
SELECT a,b,c INTO #TMP FROM BigTable
INSERT INTO #TMP(a,b,c) SELECT a,b,c FROM BigTable

מה שאומר שבמצב הזה תמיד עדיף (אם אין חשיבות לאינדקסים,נקודות ריקברי וכו') להשתמש ב SELECT INTO.

האם אני צודק או שפיספסתי משהו?

 

[pitoach]

כ"כלל אצבע" אתה צודק במסקנה אבל

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

בעקרון זה נכון (בסיטואציה הזו)

ואכן כ"כלל אצבע" עובדים עם מכלול נתונים ולא עם אוסף של נתונים (אם נעזר במושגים שהגדרתי בבלוג)

 

[AvidaEinav]

 

[pitoach]

תודה על התודה