دسترسی سریع به مقاله‌های تخصصی

این مجموعه از معماری اجرا شروع می‌کند و سپس هر DMV را در مقاله‌ای مستقل با Syntax، ستون‌های مهم، ده مثال، خروجی نمونه، خطاهای رایج، Performance، FAQ و سؤال‌های مصاحبه پوشش می‌دهد.

• آموزش کامل sys.dm_os_schedulers
• آموزش کامل sys.dm_os_workers
• آموزش کامل sys.dm_os_tasks
• آموزش کامل sys.dm_os_threads
• آموزش کامل sys.dm_os_nodes
• آموزش کامل sys.dm_os_ring_buffers
• آموزش کامل sys.dm_os_sys_info
• آموزش کامل sys.dm_os_process_memory
• آموزش کامل sys.dm_os_host_info

مقدمه: از کندی CPU تا شواهد قابل دفاع

وقتی کاربران از کندی SQL Server شکایت می‌کنند، مشاهده درصد بالای CPU تنها آغاز بررسی است. باید مشخص شود آیا درخواست‌ها واقعاً در صف CPU هستند، Worker کافی وجود ندارد، Taskها منتظر منبع دیگری‌اند، بار میان Schedulerها و NUMA Nodeها نامتوازن است یا یک Process بیرونی CPU را مصرف می‌کند. DMVهای SQLOS برای پاسخ مرحله‌ای به همین پرسش‌ها ساخته شده‌اند.

SQL Server روی لایه‌ای به نام SQLOS منابع اجرای خود را مدیریت می‌کند. Request وارد موتور می‌شود، یک یا چند Task می‌سازد، هر Task به Worker متصل می‌شود و Worker روی Scheduler اجرا می‌گردد. در سطح پایین‌تر Thread سیستم‌عامل کار واقعی را حمل می‌کند و Nodeها locality پردازنده و حافظه را سازمان می‌دهند. فهم این زنجیره مانع می‌شود واژه‌های Task، Worker و Thread به جای یکدیگر استفاده شوند.

Schedulerهای SQL Server از مدل Cooperative Scheduling برای بخش مهمی از کار موتور استفاده می‌کنند. Worker پس از Quantum یا هنگام انتظار کنترل را واگذار می‌کند تا Worker دیگری اجرا شود. RUNNABLE یعنی کار آماده اجراست اما نوبت CPU نگرفته، SUSPENDED معمولاً به معنی انتظار برای منبع یا رخداد است و RUNNING اجرای جاری را نشان می‌دهد. این Stateها باید همراه Wait و Duration خوانده شوند.

یک Snapshot فقط وضعیت همان لحظه را می‌بیند. بسیاری از Counterها از زمان Start سرویس تجمعی‌اند و با Restart صفر می‌شوند. بنابراین هر Collector حرفه‌ای Timestamp UTC، sqlserver_start_time و شناسه Instance را ذخیره می‌کند و به‌جای مقدار خام، Delta بازه‌های هم‌اندازه را مقایسه می‌کند.

قاعده طلایی عیب‌یابی: ابتدا علامت را اندازه بگیرید، سپس آن را به لایه معماری درست نسبت دهید و در پایان با شواهد مستقل تأیید کنید.

معماری Scheduler، Worker، Task، Thread و Node

Request همان درخواست اجرایی ثبت‌شده برای Session است. یک Request سریال معمولاً Execution Context اصلی دارد، اما Query موازی می‌تواند چند Context و Task بسازد. اگر پس از Join تعداد ردیف‌ها زیاد شد، نباید cpu_time یا elapsed_time Request را روی همه ردیف‌ها جمع کرد؛ در غیر این صورت Double Count رخ می‌دهد.

Task واحد کاری است که SQLOS زمان‌بندی می‌کند. Task می‌تواند Pending، Runnable، Running یا Suspended باشد و با session_id، request_id و exec_context_id به لایه Query متصل شود. sys.dm_os_tasks بهترین پل میان معماری داخلی و Request فعال است.

Worker موجودی اجرایی SQLOS است که Task را حمل می‌کند. State Worker، Wait اخیر، I/O معلق و زمان ورود به Runnable یا Suspended در sys.dm_os_workers دیده می‌شود. work_queue_count مثبت در Scheduler یعنی Task هنوز Worker نگرفته و با صف Runnable که Worker دارد اما CPU ندارد متفاوت است.

Scheduler معمولاً به یک Logical CPU نگاشت می‌شود و Schedulerهای VISIBLE ONLINE بار معمول کاربران را پردازش می‌کنند. HIDDEN Schedulerها برای کار داخلی‌اند و DAC Scheduler نقش ویژه دارد. فیلتر وضعیت به‌جای تکیه بر یک مرز عددی، اسکریپت را خواناتر و ایمن‌تر می‌کند.

Thread موجودی سیستم‌عامل است و os_thread_id امکان تطبیق با ابزارهای OS را می‌دهد. زمان Kernel و User، Stack، Affinity و Processor Group در sys.dm_os_threads دیده می‌شوند. Addressهای Thread و Worker فقط در عمر جاری Process اعتبار دارند.

Nodeهای SQLOS locality سخت‌افزار NUMA یا Soft-NUMA را منعکس می‌کنند. parent_node_id در Scheduler به node_id متصل می‌شود. مقایسه بار Nodeها به کشف Affinity نامناسب، توزیع اتصال نابرابر یا فشار متمرکز کمک می‌کند، اما اختلاف کوتاه به‌تنهایی مشکل نیست.

Ring Bufferها رکوردهای داخلی محدود و چرخشی‌اند و sys.dm_os_ring_buffers برای سرنخ Incident مفید است. شکل XML ممکن است تغییر کند و تاریخچه با ورود رکورد جدید بازنویسی شود؛ بنابراین برای قرارداد مانیتورینگ و حسابرسی، Extended Events و منابع پایدارتر انتخاب بهتری هستند.

sys.dm_os_sys_info Context ظرفیت، Uptime، توپولوژی، VM و Soft-NUMA را می‌دهد. sys.dm_os_process_memory مصرف و اعلان فشار Memory Process را نشان می‌دهد و sys.dm_os_host_info Platform و Release میزبان را ثبت می‌کند. بدون این Context، مقایسه دو Snapshot از سرورهای متفاوت می‌تواند گمراه‌کننده باشد.

جدول مقایسه‌ای DMVهای این مجموعه

معرفی و مسیر مطالعه هر DMV

sys.dm_os_schedulers

برای هر Scheduler یک ردیف ارائه می‌کند و صف Runnable، Workerها، I/O معلق و بار ادراک‌شده SQLOS را نشان می‌دهد. این DMV نمای صف‌بندی در سطح Scheduler است؛ sys.dm_os_tasks واحدهای کار و sys.dm_os_workers مجریان آن واحدها را نشان می‌دهند. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_schedulers با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_workers

برای هر Worker سیستم یک ردیف برمی‌گرداند و State، Wait اخیر، I/O، Context Switch و پیوند آن با Task و Thread را آشکار می‌کند. Worker موجودی اجرایی SQLOS است؛ Task واحد کار و Thread موجودی سطح سیستم‌عامل است که Worker روی آن اجرا می‌شود. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_workers با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_tasks

برای هر Task فعال یا داخلی یک ردیف فراهم می‌کند و State، Scheduler، Session، Request، Execution Context و I/O منتظر را نشان می‌دهد. Task واحد زمان‌بندی‌شونده کار است؛ یک Request موازی می‌تواند چند Task و Execution Context داشته باشد. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_tasks با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_threads

اطلاعات Threadهای سیستم‌عامل مرتبط با SQL Server، از جمله OS Thread ID، زمان CPU، Stack، Affinity و Processor Group را ارائه می‌کند. Thread موجودی سیستم‌عامل است؛ Worker انتزاع SQLOS برای اجرای Task روی Thread یا Fiber محسوب می‌شود. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_threads با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_nodes

ساختار Nodeهای SQLOS، ظرفیت CPU، Schedulerهای آنلاین و بیکار، Workerهای فعال، Affinity و Resource Monitor را نمایش می‌دهد. Node لایه locality و منابع را نشان می‌دهد؛ Schedulerهای قابل مشاهده از طریق parent_node_id به Node خود متصل می‌شوند. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_nodes با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_ring_buffers

رکوردهای چرخشی و محدود داخلی SQLOS را برای سرنخ‌های Scheduler Monitor، Resource، Exception و Connectivity در دسترس قرار می‌دهد. این DMV منبع داخلی و نسخه‌پذیر است؛ برای پایش قراردادی و تاریخچه دائمی، Extended Events و منابع پشتیبانی‌شده اولویت دارند. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_ring_buffers با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_sys_info

یک Snapshot تک‌ردیفی از CPU، حافظه، Uptime، توپولوژی NUMA، مجازی‌سازی، Container، Soft-NUMA و منبع زمان ارائه می‌کند. این DMV ظرفیت و Context سیستم را می‌دهد؛ مصرف جاری Process را باید از sys.dm_os_process_memory و فشار Scheduler را از sys.dm_os_schedulers گرفت. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_sys_info با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_process_memory

مصرف فیزیکی، Locked Pages، Large Pages، Virtual Address Space، Page Fault و اعلان‌های کمبود حافظه Process را گزارش می‌کند. این DMV در سطح Process است؛ جزئیات مصرف‌کننده‌های داخلی حافظه از Memory Clerkها و ظرفیت کل سیستم از sys.dm_os_sys_info به دست می‌آید. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_process_memory با ۱۰ مثال عملی و خروجی نمونه

sys.dm_os_host_info

Platform، Distribution، Release، سطح سرویس، SKU و زبان سیستم‌عامل میزبان را برای Inventory و Automation چندسکویی ارائه می‌کند. این DMV مشخصات میزبان را می‌دهد؛ نسخه و Edition موتور با SERVERPROPERTY و ظرفیت CPU و حافظه با sys.dm_os_sys_info تکمیل می‌شود. برای استفاده درست، Stateهای لحظه‌ای را از Counterهای تجمعی جدا کنید و نتیجه را با زمان نمونه‌برداری و Restart بسنجید.

آموزش جامع sys.dm_os_host_info با ۱۰ مثال عملی و خروجی نمونه

روش تشخیص گام‌به‌گام فشار CPU و Worker

1. زمان دقیق کندی، Sessionهای درگیر و اثر روی SLA را ثبت کنید.
2. ظرفیت CPU، Uptime، VM و Soft-NUMA را از sys.dm_os_sys_info بگیرید.
3. در sys.dm_os_schedulers صف Runnable و work_queue_count را در چند Snapshot بررسی کنید.
4. Taskهای Runnable یا Suspended را با Session و Request پیوند دهید.
5. Worker State و مدت حضور در صف را با ms_ticks محاسبه کنید.
6. بار را میان Scheduler و NUMA Node مقایسه کنید.
7. Query Store، Wait Statistics و Metrics سیستم‌عامل را برای تأیید علت اضافه کنید.
8. پس از تغییر، همان Baseline و بازه را دوباره اندازه بگیرید.

اگر runnable_tasks_count پایدار و CPU سیستم بالا باشد، رقابت پردازنده محتمل است. اگر work_queue_count مثبت و Wait نوع THREADPOOL دیده شود، کمبود Worker یا مصرف طولانی Workerها بررسی می‌شود. اگر Taskها عمدتاً Suspended هستند، علت اصلی ممکن است Lock، I/O، Memory Grant یا شبکه باشد، نه CPU.

Capacity Planning از Snapshot حادثه متفاوت است. برای ظرفیت‌سنجی باید صدک‌ها، ساعت اوج، روند رشد، تعداد Query و SLA در هفته‌ها یا ماه‌ها ثبت شود. خرید CPU بیشتر بدون اصلاح Query یا Parallelism ممکن است فقط هزینه را بالا ببرد و علت را پنهان کند.

مثال‌های ترکیبی کاربردی

مثال 1: Snapshot فشار Scheduler

این Query صف CPU و صف انتظار Worker را در Schedulerهای قابل مشاهده جدا می‌کند. هر دو شاخص باید در چند Snapshot و همراه با مصرف CPU تفسیر شوند.

SELECT scheduler_id, parent_node_id,
       runnable_tasks_count, work_queue_count,
       active_workers_count
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE'
ORDER BY runnable_tasks_count DESC;

Runnable پایدار نشانه رقابت CPU است؛ work_queue_count مثبت بیشتر به کمبود Worker اشاره می‌کند.

مثال 2: اتصال Request، Task و Worker

برای رسیدن از Session کاربر به State اجرایی SQLOS، Request با Task و Worker پیوند داده می‌شود. در اجرای موازی چند Task برای یک Request طبیعی است.

SELECT r.session_id, r.command, r.status,
       t.exec_context_id, t.task_state,
       w.state AS worker_state, w.last_wait_type
FROM sys.dm_exec_requests AS r
JOIN sys.dm_os_tasks AS t
  ON t.session_id = r.session_id
 AND t.request_id = r.request_id
LEFT JOIN sys.dm_os_workers AS w
  ON w.worker_address = t.worker_address
WHERE r.session_id > 50;

تعداد ردیف‌ها معادل تعداد Request نیست؛ Grain خروجی Task و Execution Context است.

مثال 3: خلاصه بار در سطح NUMA Node

تجمیع Schedulerها در Node کمک می‌کند عدم تعادل بار با توپولوژی NUMA مقایسه شود.

SELECT n.node_id, n.cpu_count,
       SUM(s.runnable_tasks_count) AS runnable_tasks,
       SUM(s.active_workers_count) AS active_workers
FROM sys.dm_os_nodes AS n
JOIN sys.dm_os_schedulers AS s
  ON s.parent_node_id = n.node_id
WHERE s.status = N'VISIBLE ONLINE'
GROUP BY n.node_id, n.cpu_count
ORDER BY runnable_tasks DESC;

اختلاف پایدار Nodeها می‌تواند بررسی Affinity، Soft-NUMA و الگوی اتصال را ضروری کند.

مثال 4: Uptime و ظرفیت CPU

پیش از تفسیر Counterهای تجمعی، Uptime و تعداد CPU دیده‌شده باید ثبت شوند.

SELECT cpu_count, socket_count, numa_node_count,
       sqlserver_start_time,
       ms_ticks / 1000 / 60 / 60 AS uptime_hours
FROM sys.dm_os_sys_info;

Restart Reset شمارنده‌ها را توضیح می‌دهد و باید در هر گزارش Performance دیده شود.

مثال 5: وضعیت حافظه Process

پرچم‌های Low Memory و مصرف فیزیکی یک Snapshot سریع از Process SQL Server فراهم می‌کنند.

SELECT physical_memory_in_use_kb / 1024 AS sql_memory_mb,
       memory_utilization_percentage,
       process_physical_memory_low,
       process_virtual_memory_low
FROM sys.dm_os_process_memory;

مقدار باید با حافظه کل سیستم، max server memory و تاریخچه فشار مقایسه شود.

مثال 6: Inventory میزبان و نسخه موتور

ترکیب Host Info و SERVERPROPERTY Context لازم برای تفسیر تفاوت Platform و نسخه را ثبت می‌کند.

SELECT h.host_platform, h.host_distribution, h.host_release,
       CONVERT(nvarchar(128), SERVERPROPERTY('ProductVersion')) AS sql_version,
       CONVERT(nvarchar(128), SERVERPROPERTY('Edition')) AS sql_edition
FROM sys.dm_os_host_info AS h;

نسخه و Platform تعیین می‌کنند کدام ستون و مجوز در دسترس است؛ Inventory باید کنار Snapshot نگه داشته شود.

مجوزها، نسخه‌ها و ایمنی Production

DMVهای سطح سرور می‌توانند اطلاعات Sessionها، نام سرور یا جزئیات اجرایی حساس را آشکار کنند. حساب مانیتورینگ باید فقط مجوز لازم داشته باشد و دسترسی به جدول تاریخچه نیز محدود شود. از اجرای Query ناشناخته یا XML سنگین در ساعت اوج خودداری کنید.

در SQL Server 2022 و نسخه‌های جدیدتر، بسیاری از DMVهای Performance به VIEW SERVER PERFORMANCE STATE نیاز دارند؛ در نسخه‌های قدیمی‌تر معمولاً VIEW SERVER STATE مطرح است. Azure SQL و Synapse نام، دامنه ردیف‌ها یا مجوز متفاوتی دارند و اسکریپت On-premises نباید بدون آزمون منتقل شود.

ستون‌های اطلاعاتی داخلی ممکن است در نسخه‌ای اضافه شوند یا تضمین سازگاری آینده نداشته باشند. Collector سازمانی باید نسخه را ثبت، ستون‌های اختیاری را کنترل و در نبود آن‌ها Fail واضح یا مسیر جایگزین داشته باشد.

سؤالات متداول

DMVهای CPU و Scheduler چه مشکلی را حل می‌کنند؟

آن‌ها لایه اجرای SQLOS را قابل مشاهده می‌کنند تا صف CPU، کمبود Worker، State Task، Thread و توپولوژی NUMA با شواهد سنجیده شود. این داده علت را به‌تنهایی ثابت نمی‌کند و باید با Query و OS تطبیق یابد.

برای شروع کدام DMV مهم‌تر است؟

معمولاً sys.dm_os_schedulers برای صف CPU و Worker نقطه شروع خوبی است؛ سپس sys.dm_os_tasks و sys.dm_os_workers بار مشخص را آشکار می‌کنند. sys.dm_os_sys_info Context ظرفیت و Uptime را فراهم می‌کند.

آیا CPU صد درصد یعنی SQL Server مقصر است؟

خیر. مصرف Processهای دیگر، Hypervisor و بار سیستم‌عامل باید بررسی شود. حتی اگر SQL Server مصرف‌کننده اصلی باشد، Query Store و پلن‌ها برای یافتن منبع مصرف لازم‌اند.

فرق Runnable Queue و Work Queue چیست؟

Runnable Task Worker دارد و منتظر CPU است؛ Work Queue شامل Taskهایی است که هنوز Worker نگرفته‌اند. اولی بیشتر به رقابت CPU و دومی به ظرفیت Worker Pool مربوط می‌شود.

آیا افزایش max worker threads مشکل را حل می‌کند؟

معمولاً تنظیم پیش‌فرض مناسب است و افزایش کورکورانه می‌تواند حافظه و Context Switching را بدتر کند. ابتدا Block شدن، Parallelism، اتصال و THREADPOOL با شواهد بررسی می‌شوند.

برای پروژه مانیتورینگ حرفه‌ای چه داده‌ای ذخیره شود؟

Timestamp UTC، Uptime، Instance، Scheduler Queue، Worker State، Taskهای کاربری و Context ظرفیت کافی است. طراحی خدماتی خوب شامل Retention، Alert قابل اقدام و Runbook پاسخ است.

رایج‌ترین خطای تحلیل Scheduler چیست؟

تبدیل یک Snapshot به نتیجه قطعی و نادیده گرفتن Counter تجمعی رایج‌ترین خطاست. خطای دیگر جمع‌زدن Request پس از Join چند Task و ایجاد Double Count است.

Polling DMVها چه اثر Performance دارد؟

Query محدود معمولاً سبک است، اما Polling ثانیه‌ای همه ستون‌ها، Sort بزرگ و XML Ring Buffer هزینه‌زا است. Interval و ستون‌ها باید با هدف تشخیص تنظیم شوند.

Best Practice برای Baseline چیست؟

داده ساعت عادی، اوج و Incident با Interval ثابت ذخیره می‌شود. صدک‌ها و روند با SLA مقایسه می‌شوند و Restart در تحلیل Counterها لحاظ می‌گردد.

آیا Queryها در همه نسخه‌های SQL Server یکسان‌اند؟

خیر. ستون‌ها، مجوزها و Platformهای پشتیبان فرق دارند. SQL Server 2022 برای بسیاری از DMVها VIEW SERVER PERFORMANCE STATE می‌خواهد و نسخه‌های Azure نیز تفاوت دامنه دارند.

سؤالات مصاحبه و پاسخ کوتاه

Cooperative Scheduling در SQL Server چیست؟

Worker کنترل Scheduler را هنگام انتظار یا پایان Quantum واگذار می‌کند تا Worker دیگر اجرا شود. Runnable Queue محل انتظار Worker آماده برای CPU است.

چطور CPU Pressure را اثبات می‌کنید؟

صف Runnable پایدار در چند Scheduler، CPU بالای سیستم، Waitهای سازگار و Queryهای CPU-heavy با هم بررسی می‌شوند. یک Counter منفرد کافی نیست.

THREADPOOL با CPU Pressure چه تفاوتی دارد؟

THREADPOOL یعنی Task برای Worker منتظر است و work_queue_count می‌تواند مثبت شود؛ CPU Pressure یعنی Worker آماده در Runnable Queue نوبت پردازنده نمی‌گیرد.

چرا NUMA در Performance مهم است؟

Locality پردازنده و حافظه روی دسترسی و توزیع بار اثر دارد. Node و Scheduler کمک می‌کنند نامتوازنی Affinity یا اتصال دیده شود.

Ring Buffer چه محدودیتی دارد؟

حافظه محدود و چرخشی است، Schema داخلی می‌تواند تغییر کند و تاریخچه پایدار نیست. برای قرارداد رخداد از Extended Events استفاده می‌شود.

چرا Delta از مقدار خام بهتر است؟

Counter تجمعی تحت تأثیر Uptime است. Delta بازه هم‌اندازه فعالیت جدید را جدا می‌کند و مقایسه منصفانه‌تری می‌سازد.

چک‌لیست نهایی عیب‌یابی

• زمان و اثر Incident ثبت شده است.
• Uptime و Restart بررسی شده است.
• Schedulerهای VISIBLE ONLINE فیلتر شده‌اند.
• Runnable و Work Queue از هم جدا شده‌اند.
• Task، Worker و Request با Grain درست Join شده‌اند.
• NUMA و Affinity در صورت عدم تعادل بررسی شده‌اند.
• حافظه Process و Context میزبان ثبت شده است.
• شواهد Query Store، Wait و OS جمع‌آوری شده‌اند.
• تغییر تنها پس از Baseline و آزمون اعمال شده است.
• نتیجه پس از تغییر با همان معیار سنجیده شده است.

جمع‌بندی و ادامه مطالعه

مجموعه DMVهای CPU و Scheduler یک نقشه لایه‌ای از اجرای SQL Server می‌سازد. Scheduler صف CPU و Worker را نشان می‌دهد، Task و Worker بار را به Request متصل می‌کنند، Thread پل سیستم‌عامل است، Node توپولوژی را می‌دهد و سه DMV اطلاعات سیستم، حافظه و میزبان Context تصمیم را کامل می‌کنند.

برای تشخیص قابل دفاع، از سؤال مشخص، Query محدود، Snapshot زمان‌دار و شواهد مکمل استفاده کنید. پس از اثبات علت، تغییر Query، Index، Parallelism، Affinity یا سخت‌افزار باید با آزمون و معیار قبل و بعد ارزیابی شود.

• ادامه مطالعه: sys.dm_os_schedulers
• ادامه مطالعه: sys.dm_os_workers
• ادامه مطالعه: sys.dm_os_tasks
• ادامه مطالعه: sys.dm_os_threads
• ادامه مطالعه: sys.dm_os_nodes
• ادامه مطالعه: sys.dm_os_ring_buffers
• ادامه مطالعه: sys.dm_os_sys_info
• ادامه مطالعه: sys.dm_os_process_memory
• ادامه مطالعه: sys.dm_os_host_info