מאמר זה הוא המשך של מאמר קודם בנושא – לחלק 1 לחצו כאן.
אנחנו עדיין בשלב ההכנות לביצוע הטיונינג – הפעם נדבר על ניקוי ה-cache לפני שמתחילים בתהליך של כיוונון הביצועים. מאמר זה הוא יותר טיפ וסקריפט מאשר התעמקות בטיונינג עצמו אבל עדיין חשוב להכיר ולדעת לפני שמתחילים בעבודה… 🙂
ניקוי של Plan \Procedure Cache ו- Buffer Cache לפני תחילת כוונון.
לפני תחילת הכוונון, נבצע ניקוי של ה-buffer cache – כדי שיתבצע parse (קומפילציה) של השאילתה כשהיא מתבצעת ונחשב גם את הזמן הזה בזמן הריצה:
- DBCC FREEPROCCACHE– מנקה את כל ה- plan/procedure cache של SQL Server, מה שמאלץ לבצע קומפילציה של שאילתה בפעם הבאה שהיא רצה.
- DBCC FLUSHPROCINDB– כמו DBCC FREEPROCCACHE אבל עבור DB ספציפי.
שימו לב: הרצה של DBCC FREEPROCCACHE ו\או DBCC FLUSHPROCINDB בסביבת היצור תאלץ לבצע קומפילציה של כל השאילתות. לא מומלץ אלא בסביבת הפיתוח או הבדיקות בלבד.
- DBCC DROPCLEANBUFFERS– מנקה את כל ה- Data caches של SQL Servers. שימו לב: הרצה של DBCC תאלץ את השאילתה לבצע קריאה מהדיסק.
לפני תחילת כיוונן בסביבת בדיקות \פיתוח יש להריץ את קטע הקוד הבא. התוצאה היא איטיות לכל השאילתות והפרוצדורות שה – plan שלהם בזיכרון.
/* DBCC FREEPROCCACHE – Clears the plan cache or procedure cache of SQL Server and removes all cached query plans from memory. This causes any query to be compiled the next time it is run. DBCC FLUSHPROCINDB – Removes allcached query plans for a particular database. If, after executing this command on a particular database, any query execution request comes for that particular database, must be compiled again due to non-existence of its query plan in cache. Before running this query we cleared the data cache by running the DBCC DROPCLEANBUFFERS command to make sure that the query reads data from the disk and not from the data cache. Don’t use these commands on live environment, it gives you temporary slow performance for all stored procedure whose plan are saved and being in use. This is just for testing or development environment. */ DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS GO
ניתן להשתמש בקטע קוד זה לניקוי הזיכרון של SQL server בסביבת היצור כאשר יש לנו אפליקציה שה- DB שלה עם צריכת זיכרון גבוהה, יחסית לשאר ה- DBs. ב- SQL server 2008 failover Cluster דבר כזה יכול לגרום ל- failover של השרת ומעבר ל- Node אחר ב- Cluster. בהמשך נלמד לנטר את צריכת הזיכרון פר DB ופר אובייקט ב- DB.
דוד יצחק
Latest posts by דוד יצחק (see all)
- MongoDB ל DBA ומפתחים הלכה למעשה – חלק ב - 16/02/2016
- MongoDB ל DBA ומפתחים הלכה למעשה - 07/02/2016
- בדיקת ביצועים של Clustered ColumnStore Index - 06/11/2014
4 תגובות ל- “כוונון ביצועים ב-SQL Server ל-DBA העסוק – חלק 2”
[…] מאמר זה הוא מאמר שלישי בנושא – מומלץ לקרוא קודם את חלק 1 ו- חלק 2 […]
[…] מאמר בסדרה המתגלגלת. לקריאת המאמרים הקודמים: חלק 1, חלק 2, חלק 3, חלק […]
[…] למאמרים הקודמים בסדרה: חלק 1, חלק 2, חלק […]
[…] מאמר בסדרה המתגלגלת. לקריאת המאמרים הקודמים: חלק 1, חלק 2, חלק 3, חלק […]
השאר תגובה: