مقدمه: مدیریت چرخه عمر Extended Events

Extended Events فقط مجموعه‌ای از Eventهای قابل ثبت نیست؛ یک مدل مدیریتی کامل دارد که از ساخت Session شروع می‌شود، با افزودن Event و Target شکل می‌گیرد، در زمان مناسب Start یا Stop می‌شود و در پایان می‌تواند تغییر یا حذف شود. تسلط بر DDL این چرخه، تفاوت میان یک نشست آزمایشی و سامانه مانیتورینگ قابل اتکا را ایجاد می‌کند.

این راهنما برای DBAها، توسعه‌دهندگان پایگاه داده و کارشناسان پشتیبانی نوشته شده است. پیش‌نیاز آن آشنایی مقدماتی با Query، Permission و مفاهیم Event، Action، Predicate و Target است. پس از مطالعه می‌توانید فرمان‌های اصلی را دسته‌بندی کنید، ترتیب امن استقرار را بشناسید و برای هر Topic به مقاله مستقل و عمیق آن بروید.

تمرکز مقاله بر SQL Server و نشست‌های Server-scoped است، اما در هر مرحله به تفاوت Scope اشاره می‌شود. مثال‌ها طوری طراحی شده‌اند که هم برای آزمایش محلی و هم برای تبدیل به Runbook سازمانی مناسب باشند.

دسترسی سریع

1. تعریف مجموعه
2. دسته‌بندی فرمان‌ها
3. جدول مقایسه
4. مثال‌های ترکیبی
5. سناریوهای واقعی
6. FAQ و چک‌لیست

تعریف مجموعه و جایگاه آن در مانیتورینگ

دستورات Extended Events رابط DDL میان هدف تشخیصی و موتور جمع‌آوری رویداد هستند. Session یک Container منطقی است؛ Event تعیین می‌کند چه رخدادی ثبت شود، Action زمینه اضافه می‌کند، Predicate داده نامرتبط را حذف می‌کند و Target مقصد مصرف یا نگهداری را می‌سازد.

فرمان‌ها را می‌توان در چهار خانواده دید: ایجاد و حذف Session، تغییر اجزای Session، مدیریت مقصدها و کنترل وضعیت Runtime. این تفکیک کمک می‌کند Scriptهای استقرار به‌جای مجموعه‌ای از دستورات پراکنده، یک چرخه عمر روشن داشته باشند.

اصل مهم این است که Catalog و Runtime یک چیز نیستند. CREATE یا ALTER تعریف را تغییر می‌دهد؛ STATE = START و STATE = STOP اجرای آن تعریف را مدیریت می‌کنند. کنترل موفقیت باید در هر دو لایه انجام شود.

دسته‌بندی فرمان‌ها و مسیر مطالعه

ابتدا فرمان‌های چرخه عمر را بشناسید، سپس سراغ اجزای Event/Target بروید و در پایان کنترل State را تمرین کنید. کارت‌های زیر هر Topic را فقط یک بار و با نقش تصمیم‌محور معرفی می‌کنند.

جدول مقایسه فرمان‌ها

مثال‌های ترکیبی چرخه کامل

سناریوی 1: ساخت نشست خطاهای مهم

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «ساخت نشست خطاهای مهم» باید بعد از کنترل Permission و مسیر Target اجرا شود.

IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name=N'XE_CriticalErrors')
    DROP EVENT SESSION [XE_CriticalErrors] ON SERVER;
GO
CREATE EVENT SESSION [XE_CriticalErrors] ON SERVER
ADD EVENT sqlserver.error_reported
(ACTION(sqlserver.sql_text, sqlserver.session_id) WHERE (severity >= 18))
ADD TARGET package0.event_file
(SET filename=N'D:\SqlData\XE\CriticalErrors.xel', max_file_size=64, max_rollover_files=4);
GO

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوی 2: افزودن RPCهای پرهزینه

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «افزودن RPCهای پرهزینه» باید بعد از کنترل Permission و مسیر Target اجرا شود.

ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER
ADD EVENT sqlserver.rpc_completed
(ACTION(sqlserver.database_id) WHERE (cpu_time > 500000));
GO

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوی 3: جایگزینی Target حافظه‌ای با فایل

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «جایگزینی Target حافظه‌ای با فایل» باید بعد از کنترل Permission و مسیر Target اجرا شود.

ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER STATE=STOP;
ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER DROP TARGET package0.ring_buffer;
ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER
ADD TARGET package0.event_file (SET filename=N'D:\SqlData\XE\CriticalErrors.xel');
GO

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوی 4: شروع و کنترل Runtime

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «شروع و کنترل Runtime» باید بعد از کنترل Permission و مسیر Target اجرا شود.

ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER STATE=START;
GO
SELECT s.name, t.target_name, s.dropped_event_count
FROM sys.dm_xe_sessions s
LEFT JOIN sys.dm_xe_session_targets t ON t.event_session_address=s.address
WHERE s.name=N'XE_CriticalErrors';

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوی 5: توقف و خواندن فایل

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «توقف و خواندن فایل» باید بعد از کنترل Permission و مسیر Target اجرا شود.

ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER STATE=STOP;
GO
SELECT object_name, timestamp_utc, event_data
FROM sys.fn_xe_file_target_read_file(N'D:\SqlData\XE\CriticalErrors*.xel',NULL,NULL,NULL);

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوی 6: حذف کنترل‌شده نشست

این سناریو چند فرمان را در یک هدف عملی ترکیب می‌کند تا رابطه میان طراحی، Runtime و نگهداری داده روشن شود. مرحله «حذف کنترل‌شده نشست» باید بعد از کنترل Permission و مسیر Target اجرا شود.

IF EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name=N'XE_CriticalErrors')
    ALTER EVENT SESSION [XE_CriticalErrors] ON SERVER STATE=STOP;
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name=N'XE_CriticalErrors')
    DROP EVENT SESSION [XE_CriticalErrors] ON SERVER;
GO

نکته فنی: هر مرحله را جداگانه اعتبارسنجی کنید؛ اجرای یک Batch طولانی بدون نقاط کنترل، تشخیص محل خطا و بازگشت را دشوار می‌کند.

سناریوهای واقعی و Runbook عملیاتی

در عیب‌یابی Incident، معمولاً یک Session موقت با Eventهای محدود و event_file ساخته می‌شود، درست پیش از بازتولید خطا Start می‌گردد و بلافاصله پس از جمع‌آوری کافی Stop می‌شود. بعد از استخراج داده، Session حذف و فایل طبق سیاست نگهداری آرشیو یا پاک‌سازی می‌شود.

در مانیتورینگ دائمی، Session باید نام پایدار، STARTUP_STATE مشخص، Target با Rollover کنترل‌شده و Alert روی رشد فایل یا dropped events داشته باشد. تغییر Event یا Target نیز باید از مسیر ALTER و با Script بازگشت انجام شود.

برای تیم توسعه، Sessionهای کوتاه‌عمر می‌توانند روی Queryهای کند، Attention یا خطاهای خاص تمرکز کنند. در این حالت Predicate بر database_id، client_app_name یا duration از جمع‌آوری داده غیرمرتبط جلوگیری می‌کند.

هشدار طراحی

هیچ Event Session را فقط به‌دلیل سبک‌بودن فناوری بدون بودجه Performance ایجاد نکنید. Action، Predicate، Frequency و Target تعیین می‌کنند هزینه واقعی چقدر است.

نشست‌های system_health یا Audit حیاتی را بدون برنامه جایگزین، تأیید مالک و نسخه بازگشت حذف یا متوقف نکنید.

اشتباهات رایج

• ساخت Session بدون Start و نتیجه‌گیری اینکه Eventها کار نمی‌کنند؛ Catalog و Runtime را جداگانه کنترل کنید.
• افزودن Event پرتکرار بدون Predicate؛ ابتدا Frequency و Payload را اندازه بگیرید.
• استفاده از ring_buffer برای حجم زیاد و انتظار نگهداری بلندمدت؛ برای دوام از event_file با Rollover استفاده کنید.
• حذف Target و تصور پاک‌شدن فایل‌های قبلی؛ چرخه عمر Metadata با فایل مستقل است.
• تغییر هم‌زمان چند جزء بدون Checkpoint؛ ALTERها را کوچک و قابل بازگشت بنویسید.
• شروع خودکار نشست بدون کنترل Permission مسیر فایل؛ Service Account را پیش از Production آزمایش کنید.

Performance Considerations

هزینه Extended Events تابع حجم Event، اندازه Payload، Actionهای Context، پیچیدگی Predicate و Target است. یک Session با یک Event پرتکرار و sql_text می‌تواند از چند Session کم‌حجم سنگین‌تر باشد؛ بنابراین تعداد Session معیار مناسبی نیست.

برای Tuning، نرخ Event در دقیقه، dropped_event_count، total_buffer_size، حجم xel و زمان خواندن فایل را در بازه ثابت ثبت کنید. Predicate باید در Source اجرا شود و تا حد امکان از مقایسه‌های ساده و Selective استفاده کند.

event_file معمولاً انتخاب پایدار برای تحلیل بعدی است، اما مسیر، اندازه فایل و Rollover باید مدیریت شود. ring_buffer برای مشاهده کوتاه مناسب است و داده آن با محدودیت حافظه یا Restart از دست می‌رود.

Best Practices

1. هدف تشخیصی و معیار پایان را قبل از CREATE بنویسید.
2. نام Session را با محیط، سامانه و سناریو قابل جست‌وجو کنید.
3. Event و Action را حداقلی نگه دارید و Predicate را زود اعمال کنید.
4. برای Target فایل، Permission، ظرفیت و Rollover را تست کنید.
5. پس از Start، Catalog و DMV Runtime را کنترل کنید.
6. تغییرها را با ALTER کوچک و Script بازگشت اعمال کنید.
7. پس از Incident، داده و Session را طبق Retention پاک‌سازی کنید.

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

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

Extended Events معماری رویدادمحور، Payload انتخابی، Predicate و Targetهای انعطاف‌پذیر دارد و ابزار اصلی مانیتورینگ مدرن SQL Server محسوب می‌شود.

آیا CREATE به‌تنهایی جمع‌آوری را شروع می‌کند؟

خیر، مگر Start جداگانه اجرا شود یا STARTUP_STATE در زمان راه‌اندازی سرویس فعال گردد.

بهترین Target برای Production چیست؟

برای دوام و حجم متوسط تا بالا، event_file معمولاً مناسب است؛ انتخاب نهایی به نرخ Event، ابزار تحلیل و سیاست نگهداری بستگی دارد.

چرا Eventها Drop می‌شوند؟

کمبود Buffer، Event بزرگ، Dispatch کند یا Target پرهزینه می‌تواند باعث Drop شود. شمارنده‌های Runtime و تنظیمات Session را بررسی کنید.

آیا ALTER همیشه بدون Stop ممکن است؟

همه تغییرها رفتار یکسان ندارند. برای تغییر ساختاری مهم، Stop کنترل‌شده و آزمایش نسخه مقصد امن‌تر است.

فایل xel چگونه خوانده می‌شود؟

از sys.fn_xe_file_target_read_file و تبدیل event_data به XML برای استخراج فیلدها استفاده می‌شود.

Predicate را کجا تعریف می‌کنیم؟

در بلوک Event و با WHERE؛ Predicate قبل از ارسال Event به Target داده نامرتبط را حذف می‌کند.

آیا حذف Session فایل‌های xel را پاک می‌کند؟

خیر، Metadata و فایل چرخه عمر جدا دارند و فایل باید با سیاست نگهداری مدیریت شود.

چطور Session فعال را پیدا کنیم؟

sys.dm_xe_sessions برای Runtime و sys.server_event_sessions برای تعریف‌های سطح Server استفاده می‌شود.

چه Permissionی لازم است؟

به Scope و نسخه وابسته است؛ برای عملیات سطح Server مجوزهای مربوط به مدیریت Event Session و برای مشاهده برخی DMVها مجوزهای View Server State/Performance مطرح است.

سؤالات مصاحبه

چرخه عمر کامل یک Event Session را توضیح دهید.

طراحی، CREATE، افزودن Event/Target، START، مشاهده و تحلیل، ALTER، STOP و در صورت پایان عمر DROP را با کنترل Catalog/Runtime توضیح دهید.

چگونه Overhead یک Session را کاهش می‌دهید؟

Event کمینه، Action ضروری، Predicate Selective، Target مناسب و اندازه‌گیری dropped events و حجم فایل.

چرا Catalog و Runtime را جدا بررسی می‌کنیم؟

تعریف ممکن است وجود داشته باشد اما فعال نباشد؛ یا Target Runtime به‌دلیل خطای مسیر باز نشده باشد.

ring_buffer چه محدودیتی دارد؟

حافظه محدود، دوام کم و دشواری تحلیل حجم زیاد؛ برای مشاهده کوتاه مناسب است.

چطور استقرار را Idempotent می‌کنید؟

با کنترل EXISTS/NOT EXISTS، نام ثابت، Script بازگشت و Queryهای اعتبارسنجی پس از هر مرحله.

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

1. Scope و Permission را مشخص کنید.
2. هدف، Event، Action و Predicate را ثبت کنید.
3. Target و ظرفیت نگهداری را انتخاب کنید.
4. Session را در محیط آزمایشی بسازید.
5. Start و Query کنترل Runtime را اجرا کنید.
6. نرخ Event و Drop را اندازه بگیرید.
7. Runbook Stop، Alter و Drop را آماده کنید.
8. داده تاریخی و فایل‌ها را طبق Retention مدیریت کنید.

جمع‌بندی و مسیر بعدی

دستورات Extended Events زمانی ارزش واقعی دارند که به‌عنوان یک چرخه منسجم طراحی شوند: CREATE برای تعریف، ADD/DROP برای تنظیم اجزا، START/STOP برای Runtime و ALTER/DROP برای نگهداری و پایان عمر. معیار موفقیت، داده قابل تحلیل با هزینه کنترل‌شده است؛ نه صرفاً اجرای بدون خطای DDL.

برای ادامه، مقاله دستور موردنیاز را از فهرست زیر انتخاب کنید و مثال‌های مستقل آن را روی Session آزمایشی اجرا نمایید.

• آموزش CREATE EVENT SESSION
• آموزش ALTER EVENT SESSION
• آموزش DROP EVENT SESSION
• آموزش ADD EVENT
• آموزش DROP EVENT
• آموزش ADD TARGET
• آموزش DROP TARGET
• آموزش STATE = START
• آموزش STATE = STOP

خدمات برنامه‌نویسی و پایگاه داده

قبول سفارش‌های برنامه‌نویسی و پایگاه داده در اصفهان با شماره 09131253620؛ مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی تاکنون.

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

• دانلود پروژه‌های رایگان C#
• دانلود پروژه‌های رایگان SQL Server
• دانلود پروژه‌های رایگان Microsoft Access
• دانلود پروژه‌های رایگان UML
• دانلود پروژه‌های ASP.NET Web Forms
• گزارش‌های کارآموزی
• طرح‌های توجیهی و کارآفرینی
• پروژه‌های Multimedia Builder
• تماس مستقیم: 09131253620
• تماس با ما