Postچند روز پیش روی یکی از دیتابیس‌ها با یک سناریوی جالب روبه‌رو شدم که شاید برای خیلی از DBAها آشنا باشد.

چند روز پیش روی یکی از دیتابیس‌ها با یک سناریوی جالب روبه‌رو شدم که شاید برای خیلی از DBAها آشنا باشد. کاربران از کندی شدید سیستم شکایت داشتند. ⏱️ زمان اجرای بعضی Updateها به ۷ تا ۸ ثانیه رسیده بود. اولین چیزی که در Wait Stats جلب توجه می‌کرد، مقدار بالای LCK_M_U بود. اگر فقط به همین Wait نگاه کنیم، احتمالاً اولین حدس این است که مشکل از Locking، Isolation Level یا یک Query بد است. اما وقتی Blocking Chain را بررسی کردم، داستان چیز دیگری بود... تقریباً تمام Sessionها پشت یک Session Block شده بودند. و آن Session فقط یک Wait قابل توجه داشت: 🔴 WRITELOG همان‌جا مشخص شد که احتمالاً مشکل اصلی Lock نیست. مشکل این بود که Commit تراکنش‌ها دیر انجام می‌شد. در SQL Server، در حالت عادی (Full Durability)، زمانی که دستور COMMIT اجرا می‌شود، باید رکوردهای Transaction Log مربوط به آن تراکنش روی فایل Log (LDF) پایدار (Harden) شوند. تا زمانی که Commit کامل نشود، Lockهای آن تراکنش نیز آزاد نمی‌شوند. بنابراین اگر به هر دلیلی Flush شدن Transaction Log کند باشد: یک اینکه Commit دیرتر کامل می‌شود. دوم اینکه Lockها مدت بیشتری نگه داشته می‌شوند. سوم اینکه Sessionهای دیگر پشت آن منتظر می‌مانند. و نتیجه چیزی است که ما به شکل LCK_M_U و Blocking مشاهده می‌کنیم. برای اطمینان از فرضیه، روی Database گزینه Delayed Durability را در حالت ALLOWED فعال کردم. نتیجه واقعاً جالب بود. 🚀 زمان Updateها از حدود ۷ تا ۸ ثانیه به کمتر از ۱۰۰ میلی‌ثانیه رسید. تقریباً تمام Blockingها از بین رفتند. این تجربه دوباره یک نکته مهم را برایم یادآوری کرد: 💡 همیشه بزرگ‌ترین Wait الزاماً ریشه مشکل نیست. گاهی چیزی که می‌بینیم فقط اثر دومینویی یک Bottleneck دیگر است. در این سناریو، LCK_M_U علت نبود؛ پیامد بود. ریشه اصلی، WRITELOG بود که باعث می‌شد Commitها دیرتر کامل شوند و در نتیجه Lockها نیز دیرتر آزاد شوند. البته یک نکته مهم را هم نباید فراموش کرد. توجه : Delayed Durability یک راهکار بدون هزینه نیست. وقتی آن را فعال می‌کنید، SQL Server ممکن است بعضی Commitها را قبل از Flush شدن Log به دیسک به Application برگرداند. اگر قبل از Flush، Crash یا قطع برق اتفاق بیفتد، آخرین Transactionهای Commit شده اما هنوز Flush نشده ممکن است از بین بروند. به همین دلیل، این قابلیت باید با توجه به نیازهای کسب‌وکار و میزان ریسک قابل قبول استفاده شود؛ نه صرفاً برای کاهش Waitها. ❓برای شما هم پیش آمده که یک Wait مثل LCK_M_U فقط یک علامت باشد و بعد از بررسی دقیق‌تر متوجه شوید ریشه اصلی مشکل جای دیگری بوده است؟