آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server
مقدمه و مسئلهای که این موضوع حل میکند
آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server برای اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure استفاده میشود. این مقاله از تعریف پایه شروع میکند و سپس Scope، Queryهای تشخیصی، مثالهای قابل اجرا و تصمیمهای عملیاتی را بهصورت مرحلهای توضیح میدهد.
مخاطب اصلی Database Developer، DBA و مهندس Performance است. پیشنیاز، دسترسی خواندن Metadata و شناخت مقدماتی Execution Plan، DMVs و Transaction است. در پایان میتوانید تشخیص دهید چه زمانی EXECUTE ... WITH RECOMPILE انتخاب مناسبی است و چه زمانی باید روش دیگری بهکار رود.
این موضوع بخشی از خانواده راهنمای جامع Plan Cache Commands و DMVs در SQL Server است. مسیر کامل مجموعه در مقاله مادر این خانواده قرار دارد.
دسترسی سریع
- تعریف و Scope موضوع
- Syntax یا روش Configuration
- منطق اجرا و کنترل State
- ده مثال عملی
- اشتباهات رایج و Performance
- Best Practices، FAQ و چکلیست
تعریف و جایگاه موضوع
EXECUTE ... WITH RECOMPILE در SQL Server بهطور مشخص برای اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure بهکار میرود. جایگاه آن در چرخه Troubleshooting میان جمعآوری Evidence، تحلیل Root Cause، اجرای Change و کنترل نتیجه قرار میگیرد.
مفاهیم کلیدی این مقاله شامل EXECUTE WITH RECOMPILE، one-time compile، parameter sniffing، execution context، plan isolation است. این مفاهیم باید در کنار هم دیده شوند؛ برای نمونه افزایش EXECUTE WITH RECOMPILE بدون بررسی one-time compile الزاماً نشانه مشکل یا موفقیت نیست.
این تصویر جایگاه آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server را میان اجزای مرتبط نشان میدهد و مشخص میکند EXECUTE WITH RECOMPILE چگونه به one-time compile و parameter sniffing متصل میشود.
پیشنیاز، Configuration و Rollback
این Feature یا Configuration در Scope مشخص Database عمل میکند. Compatibility Level، Edition، State فعلی و Storage باید پیش از تغییر بررسی شوند.
Syntax یا Query پایه
EXEC dbo.usp_GetOrder @OrderID = 1001 WITH RECOMPILE;
رفتارهای ویژه و محدودیت سازگاری
رفتار EXECUTE ... WITH RECOMPILE ممکن است با Version، Edition، Compatibility Level و Permission تغییر کند. مقدار NULL، نبود داده، Restart سرویس، Eviction از Cache یا READ_ONLY شدن Query Store باید بهعنوان حالت معتبر در طراحی Query در نظر گرفته شود.
اجزای اصلی و منطق اجرا
Scope و داده مرجع
برای آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server نخست باید Scope اندازهگیری مشخص باشد. اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure بدون تعیین Database، Instance، Session یا Query هدف میتواند به نتیجهگیری نادرست منجر شود.
- ثبت EXECUTE WITH RECOMPILE در Baseline
- تعیین ارتباط با one-time compile
- مشخصکردن Reset Condition برای parameter sniffing
معیار موفقیت و کنترل تغییر
معیار موفقیت باید قبل از اجرا نوشته شود؛ برای مثال کاهش Latency یا Logical Reads بدون افزایش Compile، Blocking یا I/O. execution context و plan isolation باید در گزارش Before/After حضور داشته باشند.
Audit و قابلیت بازبینی
زمان Capture، Login اجراکننده، نسخه SQL Server، Compatibility Level و Change Ticket را کنار نتیجه نگه دارید. این کار تحلیل Incident و انتقال دانش به تیم بعدی را قابلاعتماد میکند.
هشدار عملیاتی
این روش باید برای مورد خاص استفاده شود و اگر دائماً لازم است طراحی Query یا Plan Strategy باید بازنگری شود.
این جریان، مسیر واقعی از ورودی و State اولیه تا نتیجه قابلمشاهده در آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server را نمایش میدهد؛ نقاط کنترل EXECUTE WITH RECOMPILE، one-time compile و execution context در آن برجسته شدهاند.
مثالهای عملی از ساده تا پیشرفته
مثال 1: بررسی State قبل از اقدام
قبل از استفاده از EXECUTE ... WITH RECOMPILE باید State فعلی ثبت شود.
SELECT TOP (20)
cp.cacheobjtype, cp.objtype, cp.usecounts, cp.size_in_bytes, cp.plan_handle
FROM sys.dm_exec_cached_plans AS cp
ORDER BY cp.size_in_bytes DESC;
| خروجی | تفسیر |
|---|
| checked_at | زمان Baseline |
| state | وضعیت قبل |
نکته عملی: Baseline امکان مقایسه Before/After و Rollback تصمیم را فراهم میکند.
مثال 2: Syntax پایه و کنترلشده
نمونه اصلی EXECUTE ... WITH RECOMPILE با Scope روشن نمایش داده میشود.
EXEC dbo.usp_GetOrder @OrderID = 1001 WITH RECOMPILE;
| خروجی | تفسیر |
|---|
| command | پذیرفته شد یا خطای دقیق |
| scope | Database یا Instance |
نکته عملی: Commandهای تغییردهنده را ابتدا در Test اجرا کنید و در Production بدون Change Approval استفاده نکنید.
مثال 3: کنترل نسخه SQL Server
نسخه Engine و Compatibility Level میتواند Availability یا رفتار گزینه را تغییر دهد.
SELECT
SERVERPROPERTY(N'ProductVersion') AS product_version,
SERVERPROPERTY(N'ProductLevel') AS product_level,
SERVERPROPERTY(N'Edition') AS edition,
compatibility_level
FROM sys.databases
WHERE database_id = DB_ID();
| خروجی | تفسیر |
|---|
| product_version | نسخه Engine |
| compatibility_level | سطح سازگاری |
نکته عملی: مستندات داخلی سازمان باید نسخه و Edition هدف را صریح ثبت کند.
مثال 4: کنترل Permission اجرا
برای جلوگیری از خطای Runtime، Permission مرتبط پیش از Change Window بررسی میشود.
SELECT
IS_SRVROLEMEMBER(N'sysadmin') AS IsSysadmin,
IS_MEMBER(N'db_owner') AS IsDbOwner,
ORIGINAL_LOGIN() AS OriginalLogin;
| خروجی | تفسیر |
|---|
| IsSysadmin | 0 یا 1 |
| IsDbOwner | 0 یا 1 |
نکته عملی: بهجای افزایش دائمی Permission، مجوز حداقلی و فرایند کنترلشده تعریف کنید.
مثال 5: ثبت Baseline Plan Cache
برای موضوعهای Cache یا Recompile، وضعیت Plan Cache قبل و بعد مقایسه میشود.
SELECT
COUNT_BIG(*) AS cached_plan_count,
SUM(CONVERT(bigint, size_in_bytes)) / 1024 AS cached_size_kb,
SUM(CONVERT(bigint, usecounts)) AS total_usecounts
FROM sys.dm_exec_cached_plans;
| خروجی | تفسیر |
|---|
| cached_plan_count | تعداد Plan |
| cached_size_kb | حجم KB |
نکته عملی: تغییر Count بدون مشاهده CPU و Latency برای نتیجهگیری کافی نیست.
مثال 6: ثبت Baseline Query Store
در Databaseهای دارای Query Store، Runtime Statistics برای مقایسه نگهداری میشود.
SELECT TOP (10)
q.query_id, p.plan_id,
SUM(rs.count_executions) AS executions,
AVG(rs.avg_duration) AS avg_duration_microseconds
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
GROUP BY q.query_id, p.plan_id
ORDER BY avg_duration_microseconds DESC;
| خروجی | تفسیر |
|---|
| query_id | شناسه Query |
| avg_duration | میانگین Duration |
نکته عملی: اگر Query Store خاموش است، این مثال باید با Baseline دیگری جایگزین شود.
مثال 7: اجرای Transactional Guard
برای Commandهای Metadata یا Configuration، ابتدا Database Context و شرط ایمنی کنترل میشود.
IF DB_NAME() IN (N'master', N'model', N'msdb')
THROW 51000, N'برای این مثال یک Database کاربری انتخاب کنید.', 1;
-- پس از تأیید Change Window اجرا شود:
EXEC dbo.usp_GetOrder @OrderID = 1001 WITH RECOMPILE;
| خروجی | تفسیر |
|---|
| validation | Database کاربری |
| execution | پس از Guard |
نکته عملی: Guard ساده جایگزین Backup و Change Management نیست، اما خطای Context را کم میکند.
مثال 8: سناریوی Rollback یا بازگشت State
هر تغییر باید یک مسیر بازگشت روشن داشته باشد.
SELECT N'ثبت State قبل از تغییر' AS step_name, SYSDATETIME() AS step_time;
-- دستور Rollback متناسب با Change Plan در این بخش ثبت میشود.
SELECT N'کنترل State بعد از Rollback' AS step_name, SYSDATETIME() AS step_time;
| خروجی | تفسیر |
|---|
| step_name | قبل و بعد |
| step_time | زمان Audit |
نکته عملی: برای عملیات حذف داده یا Cache، Rollback واقعی ممکن نیست؛ در آن حالت Recovery Plan و Monitoring جایگزین است.
مثال 9: روش اشتباه و نسخه اصلاحشده
اجرای Command بدون Scope، Baseline و هشدار Production یک Anti-pattern است.
-- روش اشتباه:
-- اجرای فوری بدون ثبت Baseline
-- نسخه اصلاحشده:
SELECT TOP (20)
cp.cacheobjtype, cp.objtype, cp.usecounts, cp.size_in_bytes, cp.plan_handle
FROM sys.dm_exec_cached_plans AS cp
ORDER BY cp.size_in_bytes DESC;
-- سپس اجرای Change در Window تأییدشده
| خروجی | تفسیر |
|---|
| روش اشتباه | بدون Baseline |
| نسخه اصلاحشده | Baseline و Approval |
نکته عملی: هر Command باید Owner، زمان، هدف، معیار موفقیت و تصمیم توقف داشته باشد.
مثال 10: مقایسه Performance قبل و بعد
Metricهای CPU، Reads و Execution Count قبل و بعد از اقدام مقایسه میشوند.
SELECT TOP (20)
qs.plan_handle,
qs.execution_count,
qs.total_worker_time,
qs.total_logical_reads,
qs.total_elapsed_time
FROM sys.dm_exec_query_stats AS qs
ORDER BY qs.total_worker_time DESC;
| خروجی | تفسیر |
|---|
| total_worker_time | CPU تجمعی |
| total_logical_reads | Reads تجمعی |
نکته عملی: بهبود یک Metric نباید با بدترشدن Blocking، Compile یا I/O پنهان شود.
کاربردهای واقعی در پروژه
در پروژه واقعی، EXECUTE ... WITH RECOMPILE زمانی ارزشمند است که به یک Runbook متصل شود. Trigger استفاده، Owner تصمیم، Query جمعآوری Evidence، مقدار Baseline، محدوده Change و معیار توقف باید پیش از Incident نوشته شده باشد.
برای Workload سازمانی میتوان خروجی EXECUTE WITH RECOMPILE را با one-time compile، Query Store، Extended Events و Metricهای سیستمعامل همبسته کرد. این همبستگی کمک میکند مشکل Application، Storage، Compile یا Concurrency با یک علامت منفرد اشتباه نشود.
اشتباهات رایج و روش اصلاح
- اقدام بر اساس یک Snapshot: راه اصلاح، Capture چندبازهای و مقایسه EXECUTE WITH RECOMPILE با Baseline است.
- نادیدهگرفتن Scope: Database، Instance، Session یا Plan هدف را قبل از اجرای EXECUTE ... WITH RECOMPILE مشخص کنید.
- اجرای Change بدون معیار موفقیت: CPU، Reads، Latency، Compile و Blocking را قبل و بعد ثبت کنید.
- فرض دائمیبودن Counterها: Restart، Eviction، Cleanup یا Reset میتواند تاریخچه one-time compile را تغییر دهد.
- استفاده از Permission بیش از نیاز: دسترسی حداقلی و حساب سرویس مجزا برای مانیتورینگ تعریف کنید.
Performance Considerations
هزینه اصلی در این موضوع به نرخ Polling، حجم خروجی، Compile، I/O و Scope Change وابسته است. Query مانیتورینگ باید فقط ستونهای لازم را بخواند و از SELECT ستاره در Loop پرتکرار دوری کند. برای Changeهای Cache یا Query Store، اثر روی CPU و Latency بعد از تغییر باید در Window کوتاه کنترل شود.
SARGability و Index زمانی مهم میشوند که داده EXECUTE ... WITH RECOMPILE در Repository دائمی ذخیره و گزارشگیری شود. روی جدول Snapshot، Columnهای زمان Capture، Database ID، Query ID یا Plan ID را متناسب با الگوی گزارش Index کنید؛ خود DMVها را نمیتوان Index کرد.
Best Practices
- Scope را کوچک و قابلاندازهگیری انتخاب کنید.
- قبل از تغییر، Baseline مربوط به EXECUTE WITH RECOMPILE و one-time compile را ذخیره کنید.
- Version، Edition و Compatibility Level را در Runbook بنویسید.
- Change را در Test یا Canary اجرا و سپس مرحلهای گسترش دهید.
- پس از اجرا، parameter sniffing، execution context و Metricهای کاربر نهایی را دوباره اندازه بگیرید.
- برای عملیات برگشتناپذیر، Backup Evidence و تأیید دومرحلهای داشته باشید.
این پنل تصمیم نشان میدهد در سناریوی آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چه زمانی مسیر پیشنهادی انتخاب شود، کجا Overhead یا ریسک افزایش مییابد و چگونه EXECUTE WITH RECOMPILE با plan isolation سنجیده شود.
مزایا، محدودیتها و زمان نامناسب استفاده
| بُعد | توضیح تصمیممحور |
|---|
| مزیت | ایجاد Evidence دقیق برای اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure |
| محدودیت | وابستگی به Scope، Permission و State مربوط به EXECUTE WITH RECOMPILE |
| زمان نامناسب | وقتی Baseline، Change Window یا امکان کنترل one-time compile وجود ندارد |
| جایگزین مکمل | Query Store، Extended Events، Repository Snapshot و Monitoring سیستمعامل |
سؤالات متداول
آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server دقیقاً چه مسئلهای را حل میکند؟
مسئله اصلی، اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure است. ارزش واقعی زمانی ایجاد میشود که خروجی با Baseline و Context درست تفسیر شود.
برای شروع کار با آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چه پیشنیازی لازم است؟
دسترسی مناسب، شناخت Scope، ثبت State اولیه و آشنایی با EXECUTE WITH RECOMPILE و one-time compile ضروری است.
آیا استفاده از آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server هزینه زیرساخت را کاهش میدهد؟
در صورت استفاده هدفمند، میتواند هزینه ناشی از CPU، I/O، Incident و زمان عیبیابی را کاهش دهد؛ نتیجه باید با Metric مالی و فنی سنجیده شود.
این موضوع برای پروژههای سازمانی چه ارزشی دارد؟
در پروژه سازمانی، استانداردسازی EXECUTE WITH RECOMPILE و parameter sniffing باعث Audit بهتر، تصمیم سریعتر و کاهش ریسک Change میشود.
آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server با روشهای جایگزین چه تفاوتی دارد؟
تفاوت اصلی در Scope، میزان جزئیات، اثر عملیاتی و قابلیت بازگشت است؛ انتخاب باید بر اساس سناریو باشد نه محبوبیت ابزار.
برای پیادهسازی حرفهای آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server میتوان از خدمات تخصصی استفاده کرد؟
بله، آموزش، مشاوره، طراحی Runbook و اجرای پروژه SQL Server میتواند متناسب با Workload و محدودیت سازمان انجام شود.
رایجترین خطا در استفاده از آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چیست؟
رایجترین خطا، اقدام بدون Baseline و تفسیر جداگانه EXECUTE WITH RECOMPILE بدون توجه به execution context است.
آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چه اثری بر Performance دارد؟
اثر به نرخ اجرا، Scope و Workload وابسته است. CPU، Logical Reads، Compile، Blocking و Latency باید همزمان بررسی شوند.
Best Practice اصلی برای آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چیست؟
با Scope کوچک شروع کنید، State را ثبت کنید، معیار موفقیت تعریف کنید و پس از تغییر، one-time compile و plan isolation را دوباره اندازه بگیرید.
آیا آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server در همه نسخههای SQL Server یکسان است؟
خیر. Availability گزینهها، Permissionها، ستونها و رفتار ممکن است با Version، Edition و Compatibility Level تفاوت داشته باشد؛ محیط هدف را مستقیماً بررسی کنید.
سؤالات مصاحبه
- چگونه Scope و Reset Condition مربوط به آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server را توضیح میدهید؟
- برای اندازهگیری اثر آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server چه Baseline و Metricهایی انتخاب میکنید؟
- تفاوت Diagnostic Action و Change Action در این موضوع چیست؟
- اگر EXECUTE WITH RECOMPILE بهتر ولی one-time compile بدتر شود، تصمیم شما چیست؟
- چه Rollback Plan و Audit Trail برای استفاده از آموزش جامع EXECUTE ... WITH RECOMPILE در SQL Server تعریف میکنید؟
چکلیست نهایی
- Database و Instance هدف را تأیید کنید.
- Permission لازم را بدون افزایش دائمی Role بررسی کنید.
- Baseline و زمان شروع اندازهگیری را ذخیره کنید.
- Query یا Command را ابتدا با Scope محدود اجرا کنید.
- Output، Messages و Errorها را در Change Log ثبت کنید.
- Metricهای Before/After را با SLA مقایسه کنید.
- در صورت Regression، Rollback یا توقف مرحله بعد را اجرا کنید.
- نتیجه و درسآموخته را در Runbook خانواده ثبت کنید.
جمعبندی
EXECUTE ... WITH RECOMPILE زمانی انتخاب مناسبی است که هدف شما اجرای موردی Stored Procedure با WITH RECOMPILE بدون تغییر دائمی تعریف Procedure باشد و بتوانید Scope، Baseline و اثر تغییر را کنترل کنید. استفاده بدون Evidence یا تکرار مکانیکی Command میتواند نتیجه معکوس ایجاد کند.
قدم بعدی، مقایسه این موضوع با سایر اعضای راهنمای جامع Plan Cache Commands و DMVs در SQL Server و ساخت Runbook متناسب با Workload واقعی است.
خدمات برنامهنویسی و پایگاه داده
برنامهنویسی در اصفهان؛ قبول سفارشهای برنامهنویسی و پایگاه داده با شماره 09131253620.
انجام پروژه، آموزش برنامهنویسی و آموزش SQL Server توسط مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی تاکنون.
برای سفارش پروژههای برنامهنویسی، پایگاه داده، سیستمهای تحت وب و راهکارهای نرمافزاری با 09131253620 تماس بگیرید؛ ایتا، واتساپ و تماس مستقیم در دسترس است.
تماس با ما