آموزش عبارت DROP EVENT در Extended Events
مسئلهای که این دستور حل میکند
وقتی یک نشست Extended Events فقط در حد تعریف باقی نماند و قرار باشد در چرخه استقرار، عیبیابی و نگهداری استفاده شود، شناخت دقیق DROP EVENT ضروری است. این مقاله مسئله عملی «برای کاهش نویز، حذف جمعآوری موقت یا بازگشت از یک تغییر پرهزینه مناسب است.» را از دید SQL Server بررسی میکند و تفاوت Metadata با وضعیت Runtime را روشن نگه میدارد.
پیشنیاز مطالعه، آشنایی پایه با Event، Action، Predicate و Target است. در پایان میتوانید Syntax را درست بنویسید، نتیجه را از Catalog یا DMV کنترل کنید، خطاهای رایج را پیش از اجرا تشخیص دهید و اثر Performance را متناسب با event-drop بسنجید.
برای دیدن جایگاه این دستور در کل چرخه، راهنمای جامع دستورات Extended Events را نیز در دسترس داشته باشید؛ این صفحه روی جزئیات مستقل همین Topic تمرکز میکند.
تعریف و جایگاه فنی
DROP EVENT یک Event را از نشست موجود حذف میکند، بدون آنکه کل Session یا Targetهای دیگر از بین بروند.
برای کاهش نویز، حذف جمعآوری موقت یا بازگشت از یک تغییر پرهزینه مناسب است.
در معماری Extended Events، این Topic در گروه «event-drop» قرار میگیرد. تصمیم درباره Scope، وضعیت Session و مقصد داده باید قبل از اجرا روشن باشد؛ زیرا موفقیت DDL لزوماً به معنی دریافت داده قابل استفاده نیست.
این نقشه نشان میدهد DROP EVENT چگونه با Scope، Metadata، Event/Target و کنترل عملیاتی مرتبط میشود؛ برچسبها مخصوص همین دستور انتخاب شدهاند.
Syntax، پارامترها و رفتار خروجی
Syntax استاندارد
ALTER EVENT SESSION [SessionName]
ON SERVER
DROP EVENT sqlserver.sql_statement_completed;
پارامترها و اجزای اثرگذار
- SessionName باید حاوی Event موردنظر باشد.
- نام Event باید با Package کامل نوشته شود.
- Scope دستور با Scope نشست یکسان است.
Return Type، NULL و سازگاری
Result Set ندارد؛ Metadata نشست اصلاح میشود و Event دیگر پس از اعمال تغییر جمعآوری نمیشود.
این یک دستور DDL یا عبارت کنترلی است و Return Type تابعی ندارد؛ بنابراین رفتار NULL فقط در Predicateها، SET valueها یا Queryهای کنترلی اطراف آن مطرح میشود. Scopeهای Server و Database، نام DMVها و دسترسیهای لازم میتوانند بین نسخهها و سرویسهای Azure تفاوت داشته باشند؛ قبل از انتقال اسکریپت، مستندات نسخه مقصد و sys.dm_xe_objects همان Instance را کنترل کنید.
منطق اجرا و نکات فنی
مرز Metadata و Runtime
DROP EVENT روی یکی از دو لایه تعریف یا اجرا اثر میگذارد. Catalog مانند sys.server_event_sessions وضعیت تعریفشده را نگه میدارد، در حالی که sys.dm_xe_sessions فقط نشستهای فعال را نشان میدهد.
کنترل هر دو لایه مانع برداشت اشتباه از موفقیت عملیات میشود.
وابستگی به Scope و Permission
ON SERVER معمولاً به مجوزهای سطح Server نیاز دارد و نام Objectها در sys.server_event_* دیده میشود. برای ON DATABASE باید Catalog و Permission متناظر همان Database را به کار برد.
اسکریپت قابلانتقال باید Scope را بهعنوان یک تصمیم صریح نگه دارد، نه یک مقدار ضمنی.
طراحی قابل بازگشت
برای DROP EVENT همواره یک مسیر Rollback یا Recreate تعریف کنید. تغییرهای Extended Events اغلب در زمان Incident انجام میشوند و نبود اسکریپت بازگشت میتواند پوشش تشخیصی را ناقص کند.
- ثبت DDL فعلی
- کنترل وجود Object
- اعمال تغییر کوچک
- اعتبارسنجی Target و Runtime
جریان دوم ترتیب بررسی پیشنیاز، اجرای DROP EVENT، ثبت Metadata و اعتبارسنجی خروجی را نمایش میدهد؛ Badgeها نقاط کنترل هزینه و Dispatch هستند.
مثالهای عملی از ساده تا پیشرفته
مثال 1: حذف error_reported
سناریو: در این مرحله هدف، حذف error_reported برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
DROP EVENT sqlserver.error_reported;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «حذف error_reported» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 2: حذف rpc_completed
سناریو: در این مرحله هدف، حذف rpc_completed برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
DROP EVENT sqlserver.rpc_completed;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «حذف rpc_completed» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 3: کنترل وجود پیش از حذف
سناریو: در این مرحله هدف، کنترل وجود پیش از حذف برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
IF EXISTS
(
SELECT 1
FROM sys.server_event_session_events e
JOIN sys.server_event_sessions s ON s.event_session_id=e.event_session_id
WHERE s.name=N'XE_Article_Demo' AND e.name=N'attention'
)
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER DROP EVENT sqlserver.attention;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «کنترل وجود پیش از حذف» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 4: توقف، حذف و شروع مجدد
سناریو: در این مرحله هدف، توقف، حذف و شروع مجدد برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER STATE=STOP;
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER DROP EVENT sqlserver.error_reported;
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER STATE=START;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «توقف، حذف و شروع مجدد» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 5: فهرست Eventهای فعلی
سناریو: در این مرحله هدف، فهرست Eventهای فعلی برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
SELECT e.package, e.name
FROM sys.server_event_session_events e
JOIN sys.server_event_sessions s ON s.event_session_id=e.event_session_id
WHERE s.name=N'XE_Article_Demo'
ORDER BY e.package, e.name;
| شاخص | خروجی نمونه |
|---|
| ستون نمونه | مقدار مورد انتظار |
| name | XE_Article_Demo یا ردیفهای مرتبط |
این مثال روی جنبه «فهرست Eventهای فعلی» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 6: حذف Event تکراری از طراحی
سناریو: در این مرحله هدف، حذف Event تکراری از طراحی برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
-- پس از تأیید اینکه rpc_completed پوشش کافی میدهد:
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
DROP EVENT sqlserver.sql_batch_completed;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «حذف Event تکراری از طراحی» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 7: بازگشت تغییر
سناریو: در این مرحله هدف، بازگشت تغییر برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
ADD EVENT sqlserver.error_reported
(ACTION(sqlserver.sql_text) WHERE (severity >= 16));
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «بازگشت تغییر» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 8: کاهش نویز statement
سناریو: در این مرحله هدف، کاهش نویز statement برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
DROP EVENT sqlserver.sql_statement_starting;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «کاهش نویز statement» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 9: روش اشتباه و اصلاح
سناریو: در این مرحله هدف، روش اشتباه و اصلاح برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
-- اشتباه: نام کوتاه و بدون Package
-- ALTER EVENT SESSION [XE_Article_Demo] ON SERVER DROP EVENT error_reported;
ALTER EVENT SESSION [XE_Article_Demo] ON SERVER
DROP EVENT sqlserver.error_reported;
GO
| شاخص | خروجی نمونه |
|---|
| وضعیت | موفق در صورت وجود پیشنیازها |
| کنترل پیشنهادی | Catalog یا DMV مرتبط با همان سناریو |
این مثال روی جنبه «روش اشتباه و اصلاح» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
مثال 10: اندازهگیری اثر حذف
سناریو: در این مرحله هدف، اندازهگیری اثر حذف برای Session نمونه است. Query عمداً کامل نوشته شده تا بتوان آن را در محیط آزمایشی اجرا یا با نام واقعی جایگزین کرد.
SELECT s.name, t.target_name, DATALENGTH(t.target_data) AS TargetBytes
FROM sys.dm_xe_sessions s
JOIN sys.dm_xe_session_targets t ON t.event_session_address=s.address
WHERE s.name=N'XE_Article_Demo';
| شاخص | خروجی نمونه |
|---|
| ستون نمونه | مقدار مورد انتظار |
| name | XE_Article_Demo یا ردیفهای مرتبط |
این مثال روی جنبه «اندازهگیری اثر حذف» تمرکز دارد. در محیط واقعی نام Session، مسیر فایل، Scope و سطح دسترسی را با استاندارد استقرار خود هماهنگ کنید.
کاربردهای واقعی در پروژه
حذف موقت statement_completed پس از پایان Tuning یا کنارگذاشتن Eventی که داده تکراری با rpc_completed تولید میکند.
در پروژه سازمانی بهتر است اجرای DROP EVENT بخشی از Runbook باشد: مالک Session، زمان شروع و پایان، مسیر داده، سقف نگهداری و Query کنترل بعد از اجرا ثبت شود. این ساختار به تیم DBA و توسعه اجازه میدهد تغییر را از یک اقدام دستی به فرآیند قابل حسابرسی تبدیل کنند.
برای محیطهای پرترافیک، ابتدا نشست را در بار مشابه Production آزمایش کنید. مقدار Event تولیدشده، حجم فایل، رخدادهای Drop و زمان Parse باید با هدف مانیتورینگ مقایسه شوند؛ تنها مشاهده چند Event موفق معیار کافی نیست.
هشدار مهم
حذف Event اشتباه میتواند پوشش تشخیصی مهمی را از بین ببرد؛ پیش از اجرا وابستگی Dashboard یا Parserها را بررسی کنید.
دستور را ابتدا در محیط آزمایشی اجرا کنید و برای نشستهای امنیتی، Audit یا system_health از تغییر بدون تأیید مالک سرویس پرهیز کنید.
اشتباهات رایج و روش اصلاح
- اجرای DROP EVENT با Scope اشتباه؛ راه اصلاح: محل ایجاد Session را از Catalog متناظر پیدا کنید و ON SERVER یا ON DATABASE را همانجا به کار ببرید.
- اتکا به پیام Commands completed successfully؛ راه اصلاح: نتیجه را با Catalog و در صورت نیاز DMV Runtime تأیید کنید.
- استفاده از نام Package یا Object ناقص؛ راه اصلاح: نام رسمی را از sys.dm_xe_objects استخراج کنید.
- نادیدهگرفتن مصرف Target و فایل؛ راه اصلاح: ظرفیت، Rollover و سیاست پاکسازی را قبل از اجرا تعیین کنید.
- تغییر مستقیم در Production بدون Script بازگشت؛ راه اصلاح: نسخه قبل و بعد DDL را در کنترل نسخه ثبت کنید.
کاهش Eventهای پرتکرار معمولاً حجم Target و زمان Parsing را کم میکند، اما باید پوشش مسئله اصلی حفظ شود.
Extended Events نسبت به بسیاری از روشهای قدیمی سبکتر است، اما بدون طراحی درست بیهزینه نیست. Actionهای Context، Eventهای بسیار پرتکرار، Predicate ضعیف، Target حافظهای بزرگ یا فایل با Rollover نامناسب میتوانند CPU، حافظه، I/O و زمان تحلیل را افزایش دهند.
برای سنجش واقعی، شمارندههای sys.dm_xe_sessions، اندازه target_data، نرخ رشد xel و زمان Queryهای Parser را در یک بازه ثابت ثبت کنید. مقایسه قبل و بعد از تغییر بهتر از اتکا به حدس یا توصیه عمومی است.
Best Practices
ابتدا توقف کوتاه، ثبت وضعیت فعلی و کنترل وجود Event را انجام دهید؛ پس از حذف نرخ Eventهای باقیمانده را ارزیابی کنید.
- Session را با نام و هدف قابل جستوجو تعریف کنید.
- Scope و Permission را پیش از DDL کنترل کنید.
- برای Eventهای پرتکرار Predicate دقیق بنویسید.
- پس از هر تغییر Catalog و Runtime را جداگانه اعتبارسنجی کنید.
- اسکریپت توقف، حذف یا بازگشت را کنار اسکریپت اصلی نگه دارید.
- ظرفیت Target و عمر داده را به Runbook اضافه کنید.
ماتریس تصمیم پایانی برای DROP EVENT تعادل میان پوشش تشخیصی، Overhead، قابلیت بازگشت و مسیر درست اجرا را بهصورت مقایسهای نشان میدهد.
مزایا، محدودیتها و زمان نامناسب استفاده
| بعد تصمیم | ارزیابی اختصاصی |
|---|
| مزیت اصلی | برای کاهش نویز، حذف جمعآوری موقت یا بازگشت از یک تغییر پرهزینه مناسب است. |
| محدودیت | حذف Event اشتباه میتواند پوشش تشخیصی مهمی را از بین ببرد؛ پیش از اجرا وابستگی Dashboard یا Parserها را بررسی کنید. |
| زمان مناسب | حذف موقت statement_completed پس از پایان Tuning یا کنارگذاشتن Eventی که داده تکراری با rpc_completed تولید میکند. |
| زمان نامناسب | وقتی هدف تشخیصی، Scope یا برنامه نگهداری داده مشخص نیست؛ در این وضعیت ابتدا طراحی Session را کامل کنید. |
سؤالات متداول
آیا این دستور دادهای برمیگرداند؟
Result Set ندارد؛ Metadata نشست اصلاح میشود و Event دیگر پس از اعمال تغییر جمعآوری نمیشود.
چطور بفهمیم تغییر در 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 اعتبارسنجی بعد از اجرا را ثبت کنید.
سؤالات مصاحبه
در یک مصاحبه چگونه نقش DROP EVENT را توضیح میدهید؟
با تفکیک نقش آن در event-drop، اثر روی 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 برای مشاهده کوتاه و محدود مناسبتر است.
چکلیست نهایی
- هدف مانیتورینگ و Scope را ثبت کنید.
- وجود پیشنیازهای DROP EVENT را کنترل کنید.
- DDL را با نام Session آزمایشی اجرا کنید.
- Catalog و Runtime را جداگانه Query بگیرید.
- حجم Target و رخداد Drop را بسنجید.
- اسکریپت بازگشت را ذخیره کنید.
- زمان و مالک تغییر را در Runbook ثبت کنید.
جمعبندی تصمیممحور
DROP EVENT زمانی انتخاب درستی است که نقش آن در چرخه Session روشن، پیشنیازهای Scope و Permission کنترل و نتیجه با Viewهای Metadata و Runtime تأیید شود. برای این دستور، توصیه محوری چنین است: ابتدا توقف کوتاه، ثبت وضعیت فعلی و کنترل وجود Event را انجام دهید؛ پس از حذف نرخ Eventهای باقیمانده را ارزیابی کنید.
قدم بعدی، مرور نقشه کامل دستورات Extended Events و سپس آزمایش Queryهای همین مقاله روی یک Session غیرحیاتی است.
خدمات برنامهنویسی و پایگاه داده
قبول سفارشهای برنامهنویسی و پایگاه داده در اصفهان با شماره 09131253620؛ مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی تاکنون.
انجام پروژه، آموزش برنامهنویسی و آموزش پایگاه داده SQL Server برای دانشجویان، برنامهنویسان و سازمانها انجام میشود. برای سفارش پروژه از ایتا، واتساپ یا تماس مستقیم استفاده کنید.