مثالهای عملی
مثال 1: اجرای پایه sp_lock
در این سناریو هدف، مشاهده خروجی قدیمی قفلهای جاری برای آشنایی و سازگاری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC sys.sp_lock;
| خروجی نمونه | تفسیر |
|---|
| spid 57 | dbid 7 | ObjId 901578250 | KEY | X | GRANT | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای توسعه جدید از sys.dm_tran_locks استفاده کنید چون sp_lock Deprecated است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: فیلتر قفلهای یک SPID
در این سناریو هدف، کاهش خروجی رویه به Session هدف است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC sys.sp_lock @spid1 = 57;
| خروجی نمونه | تفسیر |
|---|
| 57 | 7 | 901578250 | 2 | KEY | hash | X | GRANT | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
SPID را پیش از اجرا از dm_exec_sessions تأیید کنید تا داده نشست دیگری تفسیر نشود. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: مقایسه دو SPID
در این سناریو هدف، دیدن قفلهای Blocker و Blocked در یک خروجی قدیمی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
EXEC sys.sp_lock @spid1 = 57, @spid2 = 64;
| خروجی نمونه | تفسیر |
|---|
| ردیفهای Lock دو Session برای مقایسه کنار هم برمیگردد | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
رابطه Blocker را sp_lock بهتنهایی قطعی نمیکند؛ dm_exec_requests و waiting_tasks را نیز ببینید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: ثبت موقت خروجی sp_lock
در این سناریو هدف، قابل Query کردن Result Set در مهاجرت یک ابزار قدیمی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Locks
(
spid int, dbid int, ObjId int, IndId int,
[Type] char(4), Resource nvarchar(255),
Mode varchar(8), [Status] varchar(5)
);
INSERT INTO #Locks
EXEC sys.sp_lock;
SELECT * FROM #Locks;
| خروجی نمونه | تفسیر |
|---|
| خروجی نسخه جاری در #Locks ذخیره میشود | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Schema رویه تضمین آینده ندارد و جدول موقت را باید روی نسخه واقعی آزمایش کرد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: افزودن نام پایگاه داده
در این سناریو هدف، ترجمه DBID به نام قابل خواندن است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Locks
(
spid int, dbid int, ObjId int, IndId int,
[Type] char(4), Resource nvarchar(255), Mode varchar(8), [Status] varchar(5)
);
INSERT INTO #Locks EXEC sys.sp_lock;
SELECT spid, DB_NAME(dbid) AS database_name, [Type], Mode, [Status]
FROM #Locks;
| خروجی نمونه | تفسیر |
|---|
| 57 | SalesDb | KEY | X | GRANT | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
DB_NAME ممکن است به علت مجوز یا حذف Database مقدار NULL بدهد؛ آن را با نام جاری جایگزین نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: تفسیر ObjId در محدوده Database
در این سناریو هدف، نگاشت ObjId وقتی واقعاً شیء پایگاه داده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Locks
(
spid int, dbid int, ObjId int, IndId int,
[Type] char(4), Resource nvarchar(255), Mode varchar(8), [Status] varchar(5)
);
INSERT INTO #Locks EXEC sys.sp_lock;
SELECT DISTINCT
spid,
DB_NAME(dbid) AS database_name,
OBJECT_NAME(ObjId, dbid) AS object_name,
Mode,
[Status]
FROM #Locks
WHERE ObjId > 0;
| خروجی نمونه | تفسیر |
|---|
| 57 | SalesDb | Orders | IX | GRANT | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای KEY و PAGE ممکن است جزئیات Resource و HOBT لازم باشد؛ OBJECT_NAME همیشه پاسخ کامل نیست. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: فیلتر قفلهای Waiting
در این سناریو هدف، جداکردن درخواستهای اعطانشده در قالب رویه قدیمی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Locks
(
spid int, dbid int, ObjId int, IndId int,
[Type] char(4), Resource nvarchar(255), Mode varchar(8), [Status] varchar(5)
);
INSERT INTO #Locks EXEC sys.sp_lock;
SELECT *
FROM #Locks
WHERE [Status] = 'WAIT';
| خروجی نمونه | تفسیر |
|---|
| 64 | 7 | 901578250 | 2 | KEY | hash | X | WAIT | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای مدت انتظار و Blocker به dm_os_waiting_tasks متصل شوید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: گروهبندی Modeهای قفل
در این سناریو هدف، خلاصهسازی داده قدیمی برای شناخت الگوی Lock است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
CREATE TABLE #Locks
(
spid int, dbid int, ObjId int, IndId int,
[Type] char(4), Resource nvarchar(255), Mode varchar(8), [Status] varchar(5)
);
INSERT INTO #Locks EXEC sys.sp_lock;
SELECT [Type], Mode, [Status], COUNT_BIG(*) AS lock_count
FROM #Locks
GROUP BY [Type], Mode, [Status]
ORDER BY lock_count DESC;
| خروجی نمونه | تفسیر |
|---|
| KEY | S | GRANT | 184 | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تعداد بالا لزوماً بد نیست؛ زمان تراکنش و Waitهای واقعی معیار اثر هستند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: همارز مدرن با dm_tran_locks
در این سناریو هدف، نشان دادن نگاشت مفهومی ستونهای sp_lock به DMV مستند است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
request_session_id AS spid,
resource_database_id AS dbid,
resource_type,
resource_description,
request_mode,
request_status
FROM sys.dm_tran_locks
WHERE request_session_id = 57;
| خروجی نمونه | تفسیر |
|---|
| 57 | 7 | KEY | hash | X | GRANT | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مالک قفل و associated_entity_id در DMV امکان تحلیل دقیقتری نسبت به خروجی قدیمی میدهد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: Query مهاجرتی هدفمند و کمهزینه
در این سناریو هدف، جایگزینی پایدار برای Polling ابزار مبتنی بر sp_lock است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
DECLARE @SessionId smallint = 57;
DECLARE @DatabaseId int = DB_ID();
SELECT
request_session_id,
resource_type,
request_mode,
request_status,
resource_associated_entity_id
FROM sys.dm_tran_locks
WHERE request_session_id = @SessionId
AND resource_database_id = @DatabaseId;
| خروجی نمونه | تفسیر |
|---|
| 57 | KEY | X | GRANT | 720575940... | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
فیلتر Database و Session پیش از ذخیرهسازی، حجم و هزینه مانیتورینگ را کنترل میکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: sp_lock (Deprecated) دقیقاً چه مسئلهای را در SQL Server حل میکند؟
رویه sp_lock اطلاعات قفلهای جاری را به شکل قدیمی نمایش میدهد. این قابلیت Deprecated است و برای توسعه جدید باید به sys.dm_tran_locks مهاجرت کرد. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با sp_lock (Deprecated) چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. دیدن قفلهای همه Sessionها به مجوزهای پایش وضعیت سرور وابسته است. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از sp_lock (Deprecated) چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ sp_lock (Deprecated) به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت sp_lock (Deprecated) با ابزار نزدیک آن چیست؟
sys.dm_tran_locks منبع، مالک، حالت درخواست و وضعیت را با جزئیات و نامگذاری مدرن فراهم میکند؛ sp_lock صرفاً برای سازگاری قدیمی مناسب است. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه sp_lock (Deprecated) را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل sp_lock (Deprecated) چیست؟
ObjId برای همه انواع منابع معنا ندارد و تفسیر مستقیم آن بدون Type و DBID میتواند شیء اشتباه نشان دهد. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از sp_lock (Deprecated) روی Performance اثر میگذارد؟
به جای Polling مداوم sp_lock، Query هدفمند روی DMV جدید و ثبت دورهای با فاصله منطقی بسازید. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از sp_lock (Deprecated) چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: sp_lock (Deprecated) در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. دیدن قفلهای همه Sessionها به مجوزهای پایش وضعیت سرور وابسته است. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.