چگونه رویداد مناسب را برای مسئله Performance انتخاب کنیم؟

برای زمان اجرای درخواست‌های برنامه، rpc_completed و sql_batch_completed نمای کلی مناسبی می‌دهند. وقتی لازم است هزینه هر دستور جدا شود، sql_statement_completed یا sp_statement_completed انتخاب دقیق‌تری هستند. در تحلیل طرح اجرا و توزیع کار میان Workerها، query_post_execution_showplan و query_thread_profile اطلاعات عمیق‌تری فراهم می‌کنند؛ با این تفاوت که سربار و حجم آن‌ها بیشتر است و باید هدفمند استفاده شوند.

مشکلات انتظار و هم‌زمانی با wait_info، wait_completed، blocked_process_report و xml_deadlock_report بررسی می‌شوند. رویدادهای sort_warning، hash_warning، exchange_spill و spilling_report_to_memory_grant_feedback به فشار حافظه، tempdb و رفتار عملگرهای اجرایی می‌پردازند. error_reported و attention نیز مرز میان خطای موتور، لغو کلاینت و Timeout را روشن می‌کنند. این دسته‌بندی اجازه می‌دهد به جای یک Session بسیار بزرگ، چند Session کوچک و قابل مدیریت ساخته شود.

مقایسه رویدادها، کاربرد و مسیر آموزش کامل

شش مثال کاربردی برای ساخت مسیر پایش

مثال جامع 1: کشف رویدادهای موجود در Package sqlserver

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 1 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

SELECT name, description
FROM sys.dm_xe_objects
WHERE object_type = N'event'
  AND name IN (N'rpc_completed', N'sql_batch_completed', N'xml_deadlock_report')
ORDER BY name;

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

مثال جامع 2: ساخت Session ترکیبی برای درخواست‌های کند

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 2 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

CREATE EVENT SESSION [XE_Performance_Overview] ON SERVER
ADD EVENT sqlserver.rpc_completed
(
 ACTION(sqlserver.sql_text, sqlserver.database_id)
 WHERE ([duration] > (1000000))
),
ADD EVENT sqlserver.sql_batch_completed
(
 ACTION(sqlserver.sql_text, sqlserver.database_id)
 WHERE ([duration] > (2000000))
)
ADD TARGET package0.event_file
(SET filename=N'C:\XE\performance_overview.xel');
GO

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

مثال جامع 3: فعال‌سازی Session فقط در بازه عیب‌یابی

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 3 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

ALTER EVENT SESSION [XE_Performance_Overview] ON SERVER STATE = START;
GO
-- پس از بازتولید مشکل
ALTER EVENT SESSION [XE_Performance_Overview] ON SERVER STATE = STOP;
GO

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

مثال جامع 4: خواندن فایل و گروه‌بندی تعداد رخدادها

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 4 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

SELECT object_name, COUNT_BIG(*) AS event_count
FROM sys.fn_xe_file_target_read_file
(N'C:\XE\performance_overview*.xel', NULL, NULL, NULL)
GROUP BY object_name
ORDER BY event_count DESC;

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

مثال جامع 5: استخراج زمان و متن SQL از XML

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 5 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

WITH X AS
(
 SELECT CAST(event_data AS xml) AS event_xml
 FROM sys.fn_xe_file_target_read_file
 (N'C:\XE\performance_overview*.xel', NULL, NULL, NULL)
)
SELECT
 event_xml.value('(event/@name)[1]','sysname') AS event_name,
 event_xml.value('(event/@timestamp)[1]','datetime2(3)') AS utc_time,
 event_xml.value('(event/action[@name="sql_text"]/value)[1]','nvarchar(max)') AS sql_text
FROM X;

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

مثال جامع 6: کنترل Sessionهای فعال و Targetهای آن‌ها

این مثال بخشی از چرخه استاندارد پایش است و نشان می‌دهد چگونه از طراحی Session تا استخراج خروجی پیش برویم. اجرای آن باید با مسیر فایل، مجوزها و نسخه سرور هماهنگ شود. هدف مثال 6 جلوگیری از جمع‌آوری بی‌هدف و ساخت خروجی قابل گزارش است.

SELECT s.name AS session_name, t.target_name, t.execution_count
FROM sys.dm_xe_sessions AS s
INNER JOIN sys.dm_xe_session_targets AS t
 ON t.event_session_address = s.address
WHERE s.name LIKE N'XE_Performance%';

نکته فنی: نتیجه نمونه برای فهم ساختار نمایش داده شده است؛ مقدار واقعی به بار، نسخه و رخدادهای ثبت‌شده در سرور وابسته خواهد بود.

معرفی مستقل هر رویداد و معیار استفاده

1. rpc_completed: پایان فراخوانی‌های RPC

این رویداد زمانی ثبت می‌شود که یک فراخوانی Remote Procedure Call در موتور پایگاه داده به پایان رسیده باشد و برای تحلیل اجرای رویه‌های ذخیره‌شده از سمت برنامه‌های کاربردی بسیار ارزشمند است. در سناریوی «سامانه فروش آنلاین که از طریق ADO.NET رویه ثبت سفارش را فراخوانی می‌کند و گاهی با افزایش زمان پاسخ روبه‌رو می‌شود» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن duration، cpu_time، logical_reads، writes هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل rpc_completed با ده مثال، خروجی نمونه و نکات Performance

2. sql_batch_completed: پایان Batchهای کامل T-SQL

این رویداد پایان اجرای یک Batch کامل T-SQL را نشان می‌دهد؛ بنابراین برای مشاهده هزینه کلی مجموعه دستورهایی که در یک ارسال از کلاینت اجرا شده‌اند مناسب است. در سناریوی «گزارش مدیریتی که چندین SELECT و محاسبه را در یک Batch اجرا می‌کند و در ساعات شلوغ کند می‌شود» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن duration، cpu_time، logical_reads، physical_reads هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل sql_batch_completed با ده مثال، خروجی نمونه و نکات Performance

3. sql_statement_completed: پایان هر Statement مستقل

این رویداد پایان اجرای یک دستور T-SQL مستقل را ثبت می‌کند و دیدی ریزدانه‌تر از Batch در اختیار تحلیل‌گر قرار می‌دهد. در سناریوی «صفحه جست‌وجوی کالا که در یک Batch چند پرس‌وجو اجرا می‌کند اما فقط یکی از آن‌ها اسکن سنگین دارد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن duration، cpu_time، logical_reads، writes هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل sql_statement_completed با ده مثال، خروجی نمونه و نکات Performance

4. sp_statement_completed: پایان Statementهای داخل Stored Procedure

این رویداد هر Statement تکمیل‌شده درون رویه ذخیره‌شده را گزارش می‌کند و برای شکستن هزینه یک Stored Procedure به اجزای داخلی آن کاربرد دارد. در سناریوی «رویه تسویه حساب که شامل اعتبارسنجی، ثبت سند، به‌روزرسانی موجودی و ثبت لاگ است و فقط یکی از مراحل آن کند شده است» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن duration، cpu_time، logical_reads، writes هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل sp_statement_completed با ده مثال، خروجی نمونه و نکات Performance

5. query_post_execution_showplan: طرح اجرای واقعی پس از پایان Query

این رویداد طرح اجرای واقعی را پس از اجرای Query تولید می‌کند و اطلاعاتی مانند عملگرها، تخمین‌ها و تعداد واقعی ردیف‌ها را در قالب Showplan XML در اختیار قرار می‌دهد. در سناریوی «گزارش مالی که در محیط آزمایش سریع است اما در تولید به علت برآورد اشتباه Cardinality چند دقیقه طول می‌کشد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن showplan_xml، duration، cpu_time، database_id هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل query_post_execution_showplan با ده مثال، خروجی نمونه و نکات Performance

6. query_thread_profile: پروفایل عملگرها در سطح Thread

این رویداد داده‌های پروفایل اجرای Query را در سطح Thread و عملگر فراهم می‌کند و برای مشاهده جریان واقعی ردیف‌ها در طرح‌های موازی یا پیچیده مفید است. در سناریوی «پرس‌وجوی تحلیلی موازی که یک Worker بسیار بیشتر از سایر Workerها کار می‌کند و زمان کل را بالا می‌برد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن node_id، thread_id، row_count، estimate_row_count هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل query_thread_profile با ده مثال، خروجی نمونه و نکات Performance

7. wait_info: جزئیات انتظارهای زمان اجرا

این رویداد برای مشاهده انتظارهای رخ‌داده در جریان اجرای درخواست‌ها استفاده می‌شود و به تحلیل‌گر کمک می‌کند زمان سپری‌شده خارج از CPU را طبقه‌بندی کند. در سناریوی «سامانه‌ای که CPU آزاد دارد اما کاربران کندی حس می‌کنند و احتمال قفل یا انتظار I/O مطرح است» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن wait_type، duration، opcode، signal_duration هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل wait_info با ده مثال، خروجی نمونه و نکات Performance

8. wait_completed: ثبت پایان انتظارهای قابل اندازه‌گیری

این رویداد پایان یک انتظار را با مدت سپری‌شده ثبت می‌کند و برای محاسبه زمان واقعی انتظار در درخواست‌های هدف به کار می‌رود. در سناریوی «فرآیند پردازش شبانه که هر چند دقیقه متوقف می‌شود و باید مشخص شود توقف از I/O، Lock یا هماهنگی Workerها ناشی شده است» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن wait_type، duration، session_id، task_address هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل wait_completed با ده مثال، خروجی نمونه و نکات Performance

9. sort_warning: هشدارهای Sort و کمبود حافظه

این رویداد زمانی اهمیت پیدا می‌کند که عملیات مرتب‌سازی نتواند کاملاً در حافظه تخصیص‌یافته انجام شود یا شرایط هشدار مرتبط با Sort رخ دهد. در سناریوی «گزارش فروش با ORDER BY چندستونی که در حجم کم سریع است اما در پایان ماه tempdb را تحت فشار قرار می‌دهد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن sort_warning_type، dop، granted_memory_kb، used_memory_kb هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل sort_warning با ده مثال، خروجی نمونه و نکات Performance

10. hash_warning: هشدارهای Hash Join و Hash Aggregate

این رویداد وضعیت‌های هشدار در عملیات Hash را آشکار می‌کند؛ از جمله زمانی که ساختار Hash به حافظه بیشتری نیاز دارد یا به tempdb متکی می‌شود. در سناریوی «تجمیع داده‌های انبار با GROUP BY که پس از رشد جدول چند برابر کندتر شده و فایل‌های tempdb را درگیر می‌کند» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن hash_warning_type، granted_memory_kb، used_memory_kb، recursion_level هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل hash_warning با ده مثال، خروجی نمونه و نکات Performance

11. exchange_spill: Spill در Exchangeهای موازی

این رویداد Spill مرتبط با عملگرهای Exchange در طرح‌های موازی را گزارش می‌کند؛ جایی که انتقال و توزیع ردیف‌ها بین Workerها با فشار حافظه یا عدم توازن مواجه می‌شود. در سناریوی «پرس‌وجوی تحلیلی با درجه موازی‌سازی بالا که در زمان اوج مصرف، tempdb را پر کرده و سرعت سایر گزارش‌ها را کاهش می‌دهد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن node_id، thread_id، spill_level، pages_written هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل exchange_spill با ده مثال، خروجی نمونه و نکات Performance

12. spilling_report_to_memory_grant_feedback: گزارش Spill برای Memory Grant Feedback

این رویداد اطلاعاتی درباره Spillهایی فراهم می‌کند که می‌توانند در سازوکار Memory Grant Feedback مؤثر باشند و برای مشاهده چرخه یادگیری تخصیص حافظه مفید است. در سناریوی «گزارش پارامتری که با مقادیر کوچک و بزرگ اجرا می‌شود و Memory Grant آن بین کمبود شدید و مصرف بیش از حد نوسان دارد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن query_id، plan_id، requested_memory_kb، granted_memory_kb هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل spilling_report_to_memory_grant_feedback با ده مثال، خروجی نمونه و نکات Performance

13. blocked_process_report: گزارش فرآیندهای مسدودشده

این رویداد پس از عبور مدت Block از آستانه تنظیم‌شده، گزارشی XML از زنجیره مسدودکننده و مسدودشونده تولید می‌کند. در سناریوی «در سامانه حسابداری، ذخیره یک سند باعث توقف کاربران دیگر می‌شود اما هنگام بررسی دستی Block تمام شده است» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن blocked_process، database_id، duration، lock_mode هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل blocked_process_report با ده مثال، خروجی نمونه و نکات Performance

14. xml_deadlock_report: گزارش XML بن‌بست‌ها

این رویداد نمودار کامل Deadlock را به صورت XML ثبت می‌کند و دقیق‌ترین منبع برای شناسایی فرآیند قربانی، منابع درگیر و ترتیب قفل‌ها است. در سناریوی «دو تراکنش ثبت سفارش و به‌روزرسانی موجودی، جدول‌ها را با ترتیب متفاوت قفل می‌کنند و یکی از آن‌ها به‌طور دوره‌ای قربانی می‌شود» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن xml_report، database_id، victim_process_id، resource_list هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل xml_deadlock_report با ده مثال، خروجی نمونه و نکات Performance

15. error_reported: خطاهای گزارش‌شده توسط SQL Server

این رویداد خطاهایی را که موتور SQL Server گزارش می‌کند همراه با شماره، شدت، پیام و زمینه اجرا ثبت می‌کند. در سناریوی «یک API گاهی خطای Timeout یا تبدیل داده دریافت می‌کند اما لاگ برنامه اطلاعات کافی درباره خطای سمت پایگاه داده ندارد» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن error_number، severity، state، message هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل error_reported با ده مثال، خروجی نمونه و نکات Performance

16. attention: لغو درخواست یا قطع اجرای Query

این رویداد زمانی ثبت می‌شود که کلاینت اجرای درخواست را لغو کند یا Attention برای توقف Query به SQL Server برسد؛ Timeout برنامه یکی از سناریوهای رایج آن است. در سناریوی «کاربر روی دکمه جست‌وجو کلیک می‌کند، برنامه پس از ۳۰ ثانیه Timeout می‌دهد و Query در SQL Server متوقف می‌شود» این Event می‌تواند داده لازم برای جداسازی علت را فراهم کند. مهم‌ترین محورهای تحلیل آن duration، session_id، database_id، client_app_name هستند و باید با توجه به نسخه سرور از metadata تأیید شوند.

آموزش کامل attention با ده مثال، خروجی نمونه و نکات Performance

اصول Performance، امنیت و نگه‌داری Extended Events

• هر Session باید سؤال فنی، مالک، زمان شروع، زمان پایان و معیار موفقیت مشخص داشته باشد.
• Predicate را روی فیلدهای پشتیبانی‌شده و پس از بررسی metadata تعریف کنید؛ فیلتر اشتباه ممکن است Session را غیرقابل ایجاد کند.
• Actionهایی مانند sql_text و plan_handle را فقط زمانی ثبت کنید که در تحلیل استفاده می‌شوند و دسترسی به فایل را محدود نگه دارید.
• برای حجم پایدار، event_file با max_file_size و max_rollover_files مناسب‌تر از ring_buffer است.
• زمان UTC رویداد باید با لاگ برنامه، مانیتورینگ سیستم‌عامل و منطقه زمانی گزارش هماهنگ شود.
• پس از اصلاح، Session و روش اندازه‌گیری را ثابت نگه دارید تا مقایسه قبل و بعد معتبر باشد.
• فایل‌های قدیمی را آرشیو یا حذف کنید و از قرار گرفتن Target روی دیسک کم‌ظرفیت یا اشتراکی پرهیز کنید.
• در Queryهای حساس، Query Store، DMVها و Extended Events را مکمل یکدیگر بدانید نه جایگزین مطلق.

ده سؤال متداول درباره مجموعه رویدادهای کارایی

Extended Events چه تفاوتی با Profiler دارد؟

Extended Events معماری جدیدتر، رویدادهای بیشتر و کنترل دقیق‌تری بر فیلتر، Action و Target ارائه می‌دهد و برای پایش تولید گزینه استانداردتری است.

آیا فعال کردن یک Event همیشه سبک است؟

خیر، نرخ رخداد، Actionها، Predicate و Target تعیین‌کننده‌اند. رویدادهای طرح اجرا و پروفایل Thread می‌توانند پرهزینه باشند.

برای شروع کدام Event مناسب‌تر است؟

برای کندی درخواست برنامه معمولاً rpc_completed یا sql_batch_completed با فیلتر duration نقطه شروع خوبی است؛ سپس بر اساس یافته‌ها Event ریزتر اضافه می‌شود.

ring_buffer بهتر است یا event_file؟

ring_buffer برای آزمایش کوتاه و event_file برای نگه‌داری، حجم بیشتر و تحلیل تاریخی مناسب‌تر است.

چگونه نسخه سرور را در طراحی لحاظ کنیم؟

وجود Event و ستون‌های آن را از sys.dm_xe_objects و sys.dm_xe_object_columns همان سرور بررسی کنید.

آیا متن SQL باید همیشه ثبت شود؟

فقط زمانی که برای نسبت دادن رخداد به Query لازم است؛ چون می‌تواند سربار و ریسک افشای داده حساس ایجاد کند.

برای Block و Deadlock چه رویدادهایی انتخاب شوند؟

blocked_process_report برای Block طولانی و xml_deadlock_report برای چرخه Deadlock مناسب است؛ wait_info نیز زمینه انتظار را تکمیل می‌کند.

چگونه Spill حافظه را تحلیل کنیم؟

sort_warning، hash_warning، exchange_spill و رویدادهای مرتبط با Memory Grant را با طرح اجرا و تعداد واقعی ردیف‌ها ترکیب کنید.

چرا Attention رخ می‌دهد؟

لغو دستی، Timeout کلاینت، قطع ارتباط یا سیاست برنامه می‌تواند Attention ایجاد کند و باید با لاگ برنامه تطبیق داده شود.

آیا می‌توان این پایش را به تیم متخصص سپرد؟

بله، طراحی Session، Parser، داشبورد و سیاست نگه‌داری در پروژه‌های تجاری بهتر است بر اساس بار واقعی و SLA توسط متخصص SQL Server انجام شود.

سؤال‌های مصاحبه برای متخصص SQL Server

1. چگونه نرخ رخداد و سربار یک Extended Events Session را ارزیابی می‌کنید؟
2. چه زمانی Predicate روی duration کافی نیست و باید database_id یا client_app_name نیز اضافه شود؟
3. چگونه XML فایل XEL را به جدول تحلیلی تبدیل می‌کنید؟
4. تفاوت Block، Deadlock، Wait و Attention را در داده رویدادها توضیح دهید.
5. برای Query موازی دارای Spill چه ترکیبی از Eventها را پیشنهاد می‌کنید؟
6. چگونه Retention و امنیت فایل‌های Extended Events را طراحی می‌کنید؟

جمع‌بندی و مسیر مطالعه پیشنهادی

بهترین مسیر مطالعه از رویدادهای تکمیل درخواست آغاز می‌شود، سپس به Statementها، طرح اجرا، انتظارها، Spill، Block، Deadlock و خطا می‌رسد. هر مقاله زیرمجموعه مستقل است و مثال‌های آن برای همان Event طراحی شده‌اند. برای پیاده‌سازی واقعی، Session را کوچک نگه دارید، metadata نسخه را بررسی کنید، خروجی را با لاگ برنامه و Query Store همبسته سازید و پس از پایان تحلیل، Session موقت را حذف کنید.

1. مرحله 1: آموزش rpc_completed
2. مرحله 2: آموزش sql_batch_completed
3. مرحله 3: آموزش sql_statement_completed
4. مرحله 4: آموزش sp_statement_completed
5. مرحله 5: آموزش query_post_execution_showplan
6. مرحله 6: آموزش query_thread_profile
7. مرحله 7: آموزش wait_info
8. مرحله 8: آموزش wait_completed
9. مرحله 9: آموزش sort_warning
10. مرحله 10: آموزش hash_warning
11. مرحله 11: آموزش exchange_spill
12. مرحله 12: آموزش spilling_report_to_memory_grant_feedback
13. مرحله 13: آموزش blocked_process_report
14. مرحله 14: آموزش xml_deadlock_report
15. مرحله 15: آموزش error_reported
16. مرحله 16: آموزش attention

خدمات برنامه‌نویسی و پایگاه داده؛ ویژه Important Performance Events

برنامه‌نویسی در اصفهان

قبول سفارش‌های برنامه‌نویسی و پایگاه داده: 09131253620؛ ویژه Important Performance Events

انجام پروژه‌های برنامه‌نویسی، آموزش برنامه‌نویسی و آموزش پایگاه داده SQL Server با رویکرد حرفه‌ای و قابل توسعه. این نکته در پرونده فنی Important Performance Events با داده همان رویداد ارزیابی می‌شود.

مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی؛ ویژه Important Performance Events

از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژه‌های برنامه‌نویسی، پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری فعالیت می‌کنیم. این نکته در پرونده فنی Important Performance Events با داده همان رویداد ارزیابی می‌شود.

• دانلود پروژه‌های مجانی برنامه‌نویسی سی‌شارپ؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود پروژه‌های رایگان پایگاه داده SQL Server؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود پروژه‌های رایگان Microsoft Access؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود پروژه‌های UML و نمودارهای مهندسی نرم‌افزار؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود پروژه‌های ASP.NET Web Forms همراه مستندات؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود گزارش‌های کارآموزی رایگان؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود طرح‌های توجیهی و پروژه‌های کارآفرینی؛ با تمرکز اختصاصی بر Important Performance Events
• دانلود پروژه‌های Multimedia Builder همراه مستندات؛ با تمرکز اختصاصی بر Important Performance Events

برای سفارش پروژه‌های برنامه‌نویسی و پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید. این نکته در پرونده فنی Important Performance Events با داده همان رویداد ارزیابی می‌شود.

ایتا، واتساپ و تماس مستقیم: +989131253620 این نکته در پرونده فنی Important Performance Events با داده همان رویداد ارزیابی می‌شود.

تماس با ما