نقشه اجرایی و یا Execution Plan لغتی است که مابین کسانی که با مبحث Performance Tuning درگیر هستند زیاد مورد استفاده قرار میگیرد. در این مقاله می خواهیم مروری داشته باشیم بر آموزش Execution Plan در SQL Server
Execution Plan ترتیب اجرای فیزیکی دستورات را مشخص میکند. تصویر زیر یک Execution Plan و یا نقشه اجرایی را در SQL Server مشخص میکند.
همانگونه که در تصویر بالا مشاهده میکنید آیتمهای مختلفی در آن موجود است که هر کدام از آنها عملیاتی خاص در سیستم را انجام میدهند. برای اینکه اطلاعات بیشتری درباره هر کدام از این آیتمها بدست آورید میتوانید بسته افزایش سرعت در SQL Server مراجعه نمایید.
اما نحوه خواندن Execution Plan در SQL Server چگونه میباشد؟
خواندن Execution Plan از سمت راست به چپ و بالا به پایین انجام میشود.
برای بدست آوردن Execution Plan در SQL Server چه کارهایی باید انجام دهیم؟
Execution Plan در SQL Server بر دو نوع میباشد.
1- Estimated Execution Plan :
نقشه اجرایی تخمینی، این نوع نقشه بدون اجرای کوئری ایجاد شده و تخمینی از عملکرد کوئری میباشد. برای بدست آوردن این نوع نقشه کافی است کوئری مورد نظر را Highlight کرده و کلید Ctrl+L را فشار داده و یا از Tool Bar همانند تصویر زیر بر روی دکمه Display Estimated Execution Plan کلیک کنید تا تصویر گرافیکی Execution Plan به شما نمایش داده شود.
2- Actual Execution Plan :
نقشه اجرایی واقعی، این نوع نقشه پس از اجرای کوئری ایجاد شده و عملکرد واقعی کوئری میباشد. برای بدست آوردن این نوع نقشه کافی است کوئری مورد نظر را Highlight کرده و کلید Ctrl+M را فشار داده و یا از Tool Bar همانند تصویر زیر بر روی دکمه Include Actual Execution Plan کلیک کنید.
پس از انجام اینکار کوئری مورد نظر خود را اجرا نمایید. پس از اجرای کوئری و نمایش نتایج آن در قسمت پایین یک Tab جدید با نام Execution Plan ایجاد میشودکه حاوی نقشه اجرایی واقعی کوئری شما میباشد.
اعدادی که در کنار هر کدام از آیتمهای موجود در Execution Plan نوشته شده است نمایانگر چه چیزی میباشد؟
این اعداد بر حسب درصد بوده و نمایانگر Cost (هزینه) کوئری هر کدام از آیتمها میباشد. این هزینه بر اساس برآیندی از IO و CPU میباشد. هر چه قدر هزینه هر کدام از آیتمها بالا باشد نشان دهنده مصرف IO و CPU بیشتر در آن قسمت میباشد. برای مثال در Execution Plan مربوط به کوئری زیر همانگونه که مشاهده میکنید هزینه Key Lookup به مراتب بالاتر از سایر آیتمهای دیگر میباشد.
[code] USE AdventureWorks2014 GO SELECT SalesPersonID, YEAR(orderdate) AS OrderYear, COUNT(*) AS NumOrders FROM Sales.SalesOrderHeader WHERE CustomerID = 29994 GROUP BY SalesPersonID, YEAR(OrderDate) HAVING COUNT(*) ORDER BY OrderYear DESC GO [/code]
تصویر زیر را با دقت بررسی کنید.
6 دیدگاه
امین ثریا
ممنون خیلی خوب بود اما برای برطرف کردن هر کدوم از آیتم ها تخصص مربوط بهش لازمه و فک میکنم یه راه میانبر تهیه محصول بسته افزایش سرعت در SQL Server باشه
http://academyit.net
بله درسته
مالک انوری انوری
سلام
تشکر از وقت گذاری شما
یه سوال: اخیرا متوجه شدم که زمانیکه برای یک اسکریپت که حدودا 1 ساعت اجرای آن زمان می برد، گزینه include actual execution plan رو فعال میکنم و بعد آنرا اجرا میکنم در مدت زمانی حدود 8 دقیقه حجم دیتابیس TempDB v رو به حداکثر میزان رشدش که حدود 15 گیگ هست میرسونه و بعد هم خطا میده و متوقف میشه…چه دلیلی میتونه داشته باشه؟ فعال کردن این گزینه چه اتفاقی رو توی دیتابیس TempDB رقم میزنه؟
ممنون
نکته دیگه: اگر امکانی در سایت فراهم بشه که هرکس بتونه هر زمان لاگین کرد همه نظرات قبلی خودش و جواب های کاربران رو یک جایی مشاهده کنه خیلی خوبه
بازم ممنون
مسعود طاهری
سلام وقت بخیر
من احتمال می دهم در اسکریپت شما
1- کرسر
2- مشکلات مربوط به تخمین نادرست تعداد رکوردهای بازگشتی
3- Spill to disk
4- کوئری های Tune نشده
5- و…
وجود داشته باشد
در این حالت (مخصوصا اولی) استفاده از Actual Plan روش مناسبی برای مشاهده پلن نیست می توان از امکانات Extended Event و Query Store استفاده کرد.
در دوره Performance & Tuning این موضوع بررسی شده است
مالک انوری انوری
سلام
تشکر از پاسخ شما
دقیقا همون مورد شماره 1 هست که اشاره کردین
دلیل رشد زیاد حجم TempDB رو میشه بفرمایین چیست؟
مسعود طاهری
تخمین اشتباه تعداد رکوردها
مسئاله Spill to disk
و صدها دلیل دیگه
سعی کنید کلا تا جایی که امکان دارد از کرسر استفاده نکنید کرسر بدترین و ساده ترین روشی است که همه برای حل مسئال خود به آن فکر می کنند
در دوره پروفورمنس 2017 نکات خیلی زیادی در این خصوص توضیح داده شده است