مثالهای عملی
مثال 1: اجرای تعاملی sp_who2
در این سناریو هدف، دیدن نمای توسعهیافته و سریع Sessionها در SSMS است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC master.dbo.sp_who2;
| خروجی نمونه | تفسیر |
|---|
| SPID 57 | sleeping | app_user | WEB-02 | . | SalesDb | AWAITING COMMAND | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
این رویه مستندنشده است؛ از نتیجه آن برای تصمیم خودکار حساس استفاده نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: نمایش سطرهای Active
در این سناریو هدف، کاهش خروجی دستی به فعالیتهای جاری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC master.dbo.sp_who2 N'active';
| خروجی نمونه | تفسیر |
|---|
| SPID 63 | RUNNABLE | report_user | REPORT-01 | SELECT | CPUTime 18420 | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تعریف Active و ستونها قرارداد رسمی ندارند؛ DMV مرجع دقیقتر است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: بررسی یک SPID
در این سناریو هدف، تمرکز تعاملی روی Session هدف است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC master.dbo.sp_who2 57;
| خروجی نمونه | تفسیر |
|---|
| SPID 57 | SUSPENDED | app_user | WEB-02 | 64 | SalesDb | UPDATE | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
قبل از اقدام، SPID، Login، Host و Request را دوباره با DMV تأیید کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: ثبت خروجی در جدول موقت
در این سناریو هدف، امکان Sort و Filter روی Result Set رویه در یک بررسی موقت است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Who2
(
SPID int, [Status] varchar(255), [Login] varchar(255),
HostName varchar(255), BlkBy varchar(255), DBName varchar(255),
Command varchar(255), CPUTime int, DiskIO int,
LastBatch varchar(255), ProgramName varchar(255),
SPID2 int, REQUESTID int
);
INSERT INTO #Who2
EXEC master.dbo.sp_who2;
SELECT * FROM #Who2;
| خروجی نمونه | تفسیر |
|---|
| خروجی نسخه جاری در #Who2 ثبت میشود | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
نوع و طول ستونها را در نسخه مقصد تطبیق دهید؛ تغییر خروجی میتواند INSERT EXEC را بشکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: یافتن Blockedها با BlkBy
در این سناریو هدف، فیلتر رابط Blocking از قالب متنی BlkBy است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Who2
(
SPID int, [Status] varchar(255), [Login] varchar(255),
HostName varchar(255), BlkBy varchar(255), DBName varchar(255),
Command varchar(255), CPUTime int, DiskIO int,
LastBatch varchar(255), ProgramName varchar(255),
SPID2 int, REQUESTID int
);
INSERT INTO #Who2 EXEC master.dbo.sp_who2;
SELECT SPID, [Login], HostName, BlkBy, DBName, Command
FROM #Who2
WHERE TRY_CONVERT(int, NULLIF(LTRIM(RTRIM(BlkBy)), '.')) > 0;
| خروجی نمونه | تفسیر |
|---|
| 64 | app_user | WEB-03 | 57 | SalesDb | UPDATE | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
نقطه یا مقدار متنی در نسخهها ممکن است متفاوت باشد؛ DMV ستون عددی قابل اتکاتری دارد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: رتبهبندی CPUTime
در این سناریو هدف، مرتبسازی مصرف تجمعی گزارششده توسط sp_who2 است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Who2
(
SPID int, [Status] varchar(255), [Login] varchar(255), HostName varchar(255),
BlkBy varchar(255), DBName varchar(255), Command varchar(255), CPUTime int,
DiskIO int, LastBatch varchar(255), ProgramName varchar(255), SPID2 int, REQUESTID int
);
INSERT INTO #Who2 EXEC master.dbo.sp_who2;
SELECT TOP (10) SPID, [Login], ProgramName, CPUTime
FROM #Who2
ORDER BY CPUTime DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | report_user | ReportService | 94520 | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
CPUTime Session قدیمی با Request جاری یکسان نیست؛ dm_exec_requests را برای فعالیت لحظهای ببینید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: رتبهبندی DiskIO
در این سناریو هدف، یافتن Sessionهای دارای I/O تجمعی بالا در بررسی سریع است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Who2
(
SPID int, [Status] varchar(255), [Login] varchar(255), HostName varchar(255),
BlkBy varchar(255), DBName varchar(255), Command varchar(255), CPUTime int,
DiskIO int, LastBatch varchar(255), ProgramName varchar(255), SPID2 int, REQUESTID int
);
INSERT INTO #Who2 EXEC master.dbo.sp_who2;
SELECT TOP (10) SPID, [Login], DBName, DiskIO
FROM #Who2
ORDER BY DiskIO DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | report_user | Warehouse | 1250020 | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای تشخیص خواندن منطقی، فیزیکی و نوشتن از ستونهای جداگانه DMV استفاده کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: شمارش Sessionها به تفکیک Program
در این سناریو هدف، کشف Pool یا Application دارای Connection زیاد است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Who2
(
SPID int, [Status] varchar(255), [Login] varchar(255), HostName varchar(255),
BlkBy varchar(255), DBName varchar(255), Command varchar(255), CPUTime int,
DiskIO int, LastBatch varchar(255), ProgramName varchar(255), SPID2 int, REQUESTID int
);
INSERT INTO #Who2 EXEC master.dbo.sp_who2;
SELECT ProgramName, COUNT_BIG(*) AS session_count
FROM #Who2
GROUP BY ProgramName
ORDER BY session_count DESC;
| خروجی نمونه | تفسیر |
|---|
| OrderApi | 84 | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
ProgramName داده قابل جعل Client است؛ آن را تنها شاخص مالکیت ندانید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: اجتناب از مقایسه متنی LastBatch
در این سناریو هدف، جایگزینی LastBatch متنی sp_who2 با ستون datetime قابل محاسبه است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
login_name,
last_request_start_time,
last_request_end_time,
DATEDIFF(second, last_request_end_time, SYSDATETIME()) AS idle_seconds
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
AND last_request_end_time IS NOT NULL;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | 05:10:00 | 05:10:01 | 1259 | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تبدیل رشته تاریخ وابسته به Language و Format است؛ DMV خطای محلیسازی را حذف میکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: جایگزین مستند برای sp_who2
در این سناریو هدف، بازسازی قابلیتهای کاربردی با DMVهای مستند و ستونهای Typed است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id AS SPID,
COALESCE(r.status, s.status) AS status,
s.login_name,
s.host_name,
r.blocking_session_id,
DB_NAME(r.database_id) AS database_name,
r.command,
s.cpu_time,
s.reads + s.writes AS disk_io,
s.last_request_end_time,
s.program_name
FROM sys.dm_exec_sessions AS s
LEFT JOIN sys.dm_exec_requests AS r ON r.session_id = s.session_id
WHERE s.is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 57 | sleeping | app_user | WEB-02 | NULL | NULL | NULL | 945 | 1280 | 05:10 | OrderApi | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
این Query را میتوان مطابق نیاز نسخهبندی و تست کرد، برخلاف قرارداد داخلی sp_who2. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: sp_who2 (Undocumented) دقیقاً چه مسئلهای را در SQL Server حل میکند؟
رویه sp_who2 خروجی توسعهیافتهای شامل CPUTime، DiskIO، LastBatch و ProgramName میدهد، اما مستند رسمی و قرارداد پایداری ندارد. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با sp_who2 (Undocumented) چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. دامنه دید خروجی تابع مجوزهای کاربر برای مشاهده فعالیتهای سرور است. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از sp_who2 (Undocumented) چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ sp_who2 (Undocumented) به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت sp_who2 (Undocumented) با ابزار نزدیک آن چیست؟
sp_who2 برای عیبیابی تعاملی محبوب است، ولی sys.dm_exec_sessions و sys.dm_exec_requests جایگزین مستند و قابل اتکاتری هستند. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه sp_who2 (Undocumented) را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل sp_who2 (Undocumented) چیست؟
به دلیل Undocumented بودن، وابستگی برنامه یا گزارش دائمی به ترتیب ستونهای آن ریسک ارتقا ایجاد میکند. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از sp_who2 (Undocumented) روی Performance اثر میگذارد؟
اجرای موردی معمولاً سبک است؛ ذخیره خروجی آن با INSERT EXEC در سامانه تولیدی به علت تغییرپذیری Schema شکننده است. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از sp_who2 (Undocumented) چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: sp_who2 (Undocumented) در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. دامنه دید خروجی تابع مجوزهای کاربر برای مشاهده فعالیتهای سرور است. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.