مسئله‌ای که این دستور حل می‌کند

وقتی یک نشست Extended Events فقط در حد تعریف باقی نماند و قرار باشد در چرخه استقرار، عیب‌یابی و نگهداری استفاده شود، شناخت دقیق CREATE EVENT SESSION ضروری است. این مقاله مسئله عملی «نقطه آغاز طراحی مانیتورینگ کم‌هزینه است؛ کیفیت نام‌گذاری، انتخاب رویداد و محدودکردن داده از همین مرحله تعیین می‌شود.» را از دید SQL Server بررسی می‌کند و تفاوت Metadata با وضعیت Runtime را روشن نگه می‌دارد.

پیش‌نیاز مطالعه، آشنایی پایه با Event، Action، Predicate و Target است. در پایان می‌توانید Syntax را درست بنویسید، نتیجه را از Catalog یا DMV کنترل کنید، خطاهای رایج را پیش از اجرا تشخیص دهید و اثر Performance را متناسب با creation بسنجید.

برای دیدن جایگاه این دستور در کل چرخه، راهنمای جامع دستورات Extended Events را نیز در دسترس داشته باشید؛ این صفحه روی جزئیات مستقل همین Topic تمرکز می‌کند.

دسترسی سریع

1. تعریف و جایگاه
2. نحو و اجزا
3. ده مثال عملی
4. کارایی و خطاها
5. پرسش‌های تکمیلی

تعریف و جایگاه فنی

این دستور تعریف اولیه یک نشست Extended Events را در سطح Server یا Database می‌سازد و رویدادها، Actionها، Predicateها، Targetها و گزینه‌های حافظه را در یک واحد قابل مدیریت کنار هم قرار می‌دهد.

نقطه آغاز طراحی مانیتورینگ کم‌هزینه است؛ کیفیت نام‌گذاری، انتخاب رویداد و محدودکردن داده از همین مرحله تعیین می‌شود.

در معماری Extended Events، این Topic در گروه «creation» قرار می‌گیرد. تصمیم درباره Scope، وضعیت Session و مقصد داده باید قبل از اجرا روشن باشد؛ زیرا موفقیت DDL لزوماً به معنی دریافت داده قابل استفاده نیست.

Syntax، پارامترها و رفتار خروجی

Syntax استاندارد

CREATE EVENT SESSION [SessionName]
ON SERVER
ADD EVENT package.event_name
ADD TARGET package.target_name
WITH (STARTUP_STATE = OFF);

پارامترها و اجزای اثرگذار

• SessionName نام یکتای نشست در Scope انتخاب‌شده است.
• ON SERVER یا ON DATABASE محدوده مالکیت و DMVهای قابل استفاده را مشخص می‌کند.
• ADD EVENT رویداد و در صورت نیاز Action و Predicate را معرفی می‌کند.
• ADD TARGET محل نگهداری یا مصرف داده را تعیین می‌کند.
• WITH گزینه‌هایی مانند MAX_MEMORY، EVENT_RETENTION_MODE و STARTUP_STATE را کنترل می‌کند.

Return Type، NULL و سازگاری

خروجی جدولی برنمی‌گرداند؛ در صورت موفقیت Metadata نشست ثبت می‌شود و برای جمع‌آوری باید جداگانه Start شود.

این یک دستور DDL یا عبارت کنترلی است و Return Type تابعی ندارد؛ بنابراین رفتار NULL فقط در Predicateها، SET valueها یا Queryهای کنترلی اطراف آن مطرح می‌شود. Scopeهای Server و Database، نام DMVها و دسترسی‌های لازم می‌توانند بین نسخه‌ها و سرویس‌های Azure تفاوت داشته باشند؛ قبل از انتقال اسکریپت، مستندات نسخه مقصد و sys.dm_xe_objects همان Instance را کنترل کنید.

منطق اجرا و نکات فنی

مثال‌های عملی از ساده تا پیشرفته

مثال 1: ساخت نشست حداقلی

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

CREATE EVENT SESSION [XE_Minimal] ON SERVER
ADD EVENT sqlserver.error_reported;
GO

این مثال روی جنبه «ساخت نشست حداقلی» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 2: ساخت Idempotent

سناریو: در این مرحله هدف، ساخت Idempotent برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'XE_Article_Demo')
    DROP EVENT SESSION [XE_Article_Demo] ON SERVER;
GO
CREATE EVENT SESSION [XE_Article_Demo] ON SERVER
ADD EVENT sqlserver.error_reported
(
    ACTION(sqlserver.sql_text, sqlserver.session_id)
    WHERE (severity >= 16)
)
ADD TARGET package0.ring_buffer
WITH (MAX_MEMORY = 4 MB, STARTUP_STATE = OFF);
GO

این مثال روی جنبه «ساخت Idempotent» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 3: افزودن Predicate شدت خطا

سناریو: در این مرحله هدف، افزودن Predicate شدت خطا برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

CREATE EVENT SESSION [XE_Severity] ON SERVER
ADD EVENT sqlserver.error_reported
(
    ACTION(sqlserver.sql_text, sqlserver.session_id)
    WHERE (severity >= 16)
);
GO

این مثال روی جنبه «افزودن Predicate شدت خطا» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 4: ثبت Queryهای کند

سناریو: در این مرحله هدف، ثبت Queryهای کند برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

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

این مثال روی جنبه «ثبت Queryهای کند» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 5: تنظیم حافظه و Retention

سناریو: در این مرحله هدف، تنظیم حافظه و Retention برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

CREATE EVENT SESSION [XE_Configured] ON SERVER
ADD EVENT sqlserver.rpc_completed
WITH
(
    MAX_MEMORY = 8 MB,
    EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY = 5 SECONDS
);
GO

این مثال روی جنبه «تنظیم حافظه و Retention» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 6: نشست Database-scoped

سناریو: در این مرحله هدف، نشست Database-scoped برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

CREATE EVENT SESSION [XE_DbScope] ON DATABASE
ADD EVENT sqlserver.sql_statement_completed;
GO

این مثال روی جنبه «نشست Database-scoped» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 7: کنترل Metadata بعد از ساخت

سناریو: در این مرحله هدف، کنترل Metadata بعد از ساخت برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

SELECT s.name, s.event_retention_mode_desc, s.startup_state
FROM sys.server_event_sessions AS s
WHERE s.name = N'XE_Article_Demo';

این مثال روی جنبه «کنترل Metadata بعد از ساخت» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 8: ساخت برای Deadlock

سناریو: در این مرحله هدف، ساخت برای Deadlock برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

CREATE EVENT SESSION [XE_Deadlock] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.event_file
(SET filename = N'C:\XE\Deadlock.xel');
GO

این مثال روی جنبه «ساخت برای Deadlock» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 9: روش اشتباه و نسخه اصلاح‌شده

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

-- اشتباه: ثبت همه statementها بدون فیلتر در محیط پرترافیک
-- CREATE EVENT SESSION [XE_TooMuch] ON SERVER
-- ADD EVENT sqlserver.sql_statement_completed;

CREATE EVENT SESSION [XE_Filtered] ON SERVER
ADD EVENT sqlserver.sql_statement_completed
(
    WHERE (database_id = 5 AND duration > 1000000)
);
GO

این مثال روی جنبه «روش اشتباه و نسخه اصلاح‌شده» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

مثال 10: طراحی کم‌هزینه برای Production

سناریو: در این مرحله هدف، طراحی کم‌هزینه برای Production برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.

CREATE EVENT SESSION [XE_ProdErrors] ON SERVER
ADD EVENT sqlserver.error_reported
(
    ACTION(sqlserver.client_app_name, sqlserver.session_id)
    WHERE (severity >= 18)
)
ADD TARGET package0.event_file
(
    SET filename = N'C:\XE\ProdErrors.xel',
        max_file_size = 64,
        max_rollover_files = 4
)
WITH (MAX_MEMORY = 4 MB, TRACK_CAUSALITY = OFF);
GO

این مثال روی جنبه «طراحی کم‌هزینه برای Production» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.

کاربردهای واقعی در پروژه

ساخت نشست اختصاصی برای ردیابی Deadlock، Queryهای کند، خطاهای Severity بالا یا تغییرات امنیتی در محیط عملیاتی.

در پروژه سازمانی بهتر است اجرای CREATE EVENT SESSION بخشی از Runbook باشد: مالک Session، زمان شروع و پایان، مسیر داده، سقف نگهداری و Query کنترل بعد از اجرا ثبت شود. این ساختار به تیم DBA و توسعه اجازه می‌دهد تغییر را از یک اقدام دستی به فرآیند قابل حسابرسی تبدیل کنند.

برای محیط‌های پرترافیک، ابتدا نشست را در بار مشابه Production آزمایش کنید. مقدار Event تولیدشده، حجم فایل، رخدادهای Drop و زمان Parse باید با هدف مانیتورینگ مقایسه شوند؛ تنها مشاهده چند Event موفق معیار کافی نیست.

هشدار مهم

ساخت نشست بدون Predicate روی رویدادهای پرتکرار می‌تواند حجم داده و I/O هدف را به‌سرعت بالا ببرد.

دستور را ابتدا در محیط آزمایشی اجرا کنید و برای نشست‌های امنیتی، Audit یا system_health از تغییر بدون تأیید مالک سرویس پرهیز کنید.

اشتباهات رایج و روش اصلاح

• اجرای CREATE EVENT SESSION با Scope اشتباه؛ راه اصلاح: محل ایجاد Session را از Catalog متناظر پیدا کنید و ON SERVER یا ON DATABASE را همان‌جا به کار ببرید.
• اتکا به پیام Commands completed successfully؛ راه اصلاح: نتیجه را با Catalog و در صورت نیاز DMV Runtime تأیید کنید.
• استفاده از نام Package یا Object ناقص؛ راه اصلاح: نام رسمی را از sys.dm_xe_objects استخراج کنید.
• نادیده‌گرفتن مصرف Target و فایل؛ راه اصلاح: ظرفیت، Rollover و سیاست پاک‌سازی را قبل از اجرا تعیین کنید.
• تغییر مستقیم در Production بدون Script بازگشت؛ راه اصلاح: نسخه قبل و بعد DDL را در کنترل نسخه ثبت کنید.

Performance Considerations

هزینه اصلی به Event، Action، Predicate و Target وابسته است؛ طراحی کمینه و اندازه‌گیری Drop/Dispatch مهم‌تر از تعداد خطوط DDL است.

Extended Events نسبت به بسیاری از روش‌های قدیمی سبک‌تر است، اما بدون طراحی درست بی‌هزینه نیست. Actionهای Context، Eventهای بسیار پرتکرار، Predicate ضعیف، Target حافظه‌ای بزرگ یا فایل با Rollover نامناسب می‌توانند CPU، حافظه، I/O و زمان تحلیل را افزایش دهند.

برای سنجش واقعی، شمارنده‌های sys.dm_xe_sessions، اندازه target_data، نرخ رشد xel و زمان Queryهای Parser را در یک بازه ثابت ثبت کنید. مقایسه قبل و بعد از تغییر بهتر از اتکا به حدس یا توصیه عمومی است.

Best Practices

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

1. Session را با نام و هدف قابل جست‌وجو تعریف کنید.
2. Scope و Permission را پیش از DDL کنترل کنید.
3. برای Eventهای پرتکرار Predicate دقیق بنویسید.
4. پس از هر تغییر Catalog و Runtime را جداگانه اعتبارسنجی کنید.
5. اسکریپت توقف، حذف یا بازگشت را کنار اسکریپت اصلی نگه دارید.
6. ظرفیت Target و عمر داده را به Runbook اضافه کنید.

مزایا، محدودیت‌ها و زمان نامناسب استفاده

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

آیا این دستور داده‌ای برمی‌گرداند؟

خروجی جدولی برنمی‌گرداند؛ در صورت موفقیت Metadata نشست ثبت می‌شود و برای جمع‌آوری باید جداگانه Start شود.

چطور بفهمیم تغییر در Catalog ثبت شده است؟

برای Scope سطح Server از sys.server_event_sessions و Viewهای وابسته استفاده کنید؛ برای Session فعال، sys.dm_xe_sessions و sys.dm_xe_session_targets را نیز بررسی کنید.

آیا می‌توان آن را در Transaction برنامه کاربردی قرار داد؟

DDLهای Extended Events را بهتر است در اسکریپت مدیریت مستقل، با TRY/CATCH و کنترل وضعیت اجرا کنید؛ رفتار Transaction را در نسخه مقصد آزمایش کنید و به Rollback منطقی متکی باشید.

تفاوت ON SERVER و ON DATABASE چیست؟

Scope مالکیت، Permission، Catalog و DMVها را تغییر می‌دهد. اسکریپت نباید این دو را بدون بررسی سرویس مقصد جایگزین یکدیگر کند.

چرا Session در Catalog هست ولی داده ندارد؟

ممکن است Start نشده باشد، Predicate هیچ Eventی را عبور نداده باشد، Target باز نشده باشد یا مسیر فایل/مجوز مشکل داشته باشد.

برای اتوماسیون چه کنترل‌هایی لازم است؟

وجود Session، وضعیت Runtime، وجود Event/Target، Permission، مسیر فایل، نتیجه DDL و Query اعتبارسنجی بعد از اجرا را ثبت کنید.

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

در یک مصاحبه چگونه نقش CREATE EVENT SESSION را توضیح می‌دهید؟

با تفکیک نقش آن در creation، اثر روی Metadata/Runtime و نیاز به کنترل Scope پاسخ دهید.

چرا Predicate روی Performance مهم است؟

زیرا رویداد نامرتبط را پیش از Dispatch حذف می‌کند و حجم Target و Parse را کاهش می‌دهد.

چه تفاوتی میان Catalog و DMV Runtime وجود دارد؟

Catalog تعریف پایدار را نگه می‌دارد؛ DMV Runtime فقط وضعیت نشست فعال و Targetهای باز را نشان می‌دهد.

چطور یک تغییر Extended Events را قابل بازگشت می‌کنید؟

DDL فعلی را ثبت، تغییر را کوچک، Query کنترل را مشخص و Script معکوس یا Recreate را آماده می‌کنید.

چه زمانی event_file را به ring_buffer ترجیح می‌دهید؟

وقتی دوام، حجم بیشتر، تحلیل بعدی و مدیریت Rollover مهم است؛ ring_buffer برای مشاهده کوتاه و محدود مناسب‌تر است.

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

1. هدف مانیتورینگ و Scope را ثبت کنید.
2. وجود پیش‌نیازهای CREATE EVENT SESSION را کنترل کنید.
3. DDL را با نام Session آزمایشی اجرا کنید.
4. Catalog و Runtime را جداگانه Query بگیرید.
5. حجم Target و رخداد Drop را بسنجید.
6. اسکریپت بازگشت را ذخیره کنید.
7. زمان و مالک تغییر را در Runbook ثبت کنید.

جمع‌بندی تصمیم‌محور

CREATE EVENT SESSION زمانی انتخاب درستی است که نقش آن در چرخه Session روشن، پیش‌نیازهای Scope و Permission کنترل و نتیجه با Viewهای Metadata و Runtime تأیید شود. برای این دستور، توصیه محوری چنین است: ابتدا هدف تشخیصی را بنویسید، فقط ستون‌های لازم را جمع کنید، نام Target را صریح تعیین کنید و راه حذف یا توقف نشست را نیز در اسکریپت استقرار بگنجانید.

قدم بعدی، مرور نقشه کامل دستورات Extended Events و سپس آزمایش Queryهای همین مقاله روی یک Session غیرحیاتی است.

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

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

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

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