سلام دوستان

📉 Shrink در SQL Server به روایت یک فضای کار اشتراکی!

فرض کن یکی میره یه فضای کار اشتراکی 🏢
اوایل کارش کوچیکه، یه میز اشتراکی می‌گیره.
کم‌کم کارش می‌گیره 📈، میگه «نه، من یه اتاق می‌خوام» 🚪
اتاق رو می‌گیره، کارش راه می‌افته، همه چی خوبه 😌
فرداش چی؟
میگه «نه بابا، الان اتاق زیادیه»
اتاق رو پس میده، برمی‌گرده میز اشتراکی 😐
عصر دوباره کار زیاد میشه:
«بچه‌ها اتاق بدین!»
دوباره اتاق می‌گیره…
پس میده…
می‌گیره…
پس میده… 🤦‍♂️
حالا صاحب فضای کار اشتراکی کلافه نشده؟
دیوارها جابه‌جا نمی‌شن؟
نظم فضا به هم نمی‌ریزه؟ 😵
📌 Shrink توی SQL Server دقیقاً همینه!
دیتابیس رشد می‌کنه 📊
شما Shrink می‌کنی چون «فضا خالیه»
دوباره دیتا میاد، دوباره رشد می‌کنه
دوباره Shrink
نتیجه؟
Fragmentation شدید 🧩
فشار بی‌خودی به IO 💥
بدتر شدن Performance 🐌
📢 Shrink یعنی پس گرفتن فضا، نه مدیریت فضا!
Shrink برای شرایط خاصه:
بعد از حذف دائمی حجم عظیمی از دیتا
وقتی مطمئنی دیگه به اون فضا نیاز نداری
نه برای اینکه:
❌ هر هفته دیسک خالی ببینی
❌ یا وجدان DBA‌ت آروم بشه 😄

و این مساله هم برای فایل LDF صدق می کنه هم MDF.

بارها توی همه Job ها من Job برای Shrink دیدم و ایجاد Fragmentation بر روی LDF ها.


🎯 نتیجه:
به جای این همه «اتاق پس بده، اتاق بگیر»
یه فضای مناسب بگیر، درست استفاده کن،
و بگذار دیتابیس با آرامش رشد کنه
و برای کنترل LDF هم تهیه بکاپ منظم از Log ها به این مساله به شدت کمک می کنه.🧘‍♂️
hashtag#SQLServer hashtag#DBA hashtag#Shrink hashtag#Performance hashtag#DatabaseLife hashtag#طنز_فنی 😄

سلام دوستان

💼🌳 چالش همیشگی ما با درخت‌های سلسله‌مراتبی در SQL!

همیشه وقتی با ساختار درختی کار می‌کنیم، معمولاً از ریشه شروع می‌کنیم و تا برگ‌ها می‌رویم.

اما یه سؤال جالب پیش میاد:

❓ فرض کنید شما یه نقطه وسط درخت دارید و می‌خواید بفهمید این رکورد به کدوم ریشه یا مدیر اصلی وصل می‌شه؟

برای مثال: مشخصات یک کارمند را دارید و می‌خواید ببینید در چارت سازمانی، مسیرش تا مدیر ارشد کجاست.
اینجاست که باید برعکس فکر کنید: از پایین به بالا حرکت کنید، نه از بالا به پایین.
و نکته جالب: در کدنویسی و SQL، مدل بازگشتی فرقی نمی‌کنه، فقط جهت پیمایش عوض می‌شه 😎
🔹 ساختار جدول عمومی (می‌تونید تست کنید)

CREATE TABLE Table1
(
 Id UNIQUEIDENTIFIER PRIMARY KEY,
 Name NVARCHAR(100),
 ParentId UNIQUEIDENTIFIER NULL
);

Id → شناسه رکورد
ParentId → شناسه والد (NULL یعنی ریشه)
Name → نام رکورد

🔹 کوئری CTE برای پیدا کردن مسیر تا ریشه

DECLARE @InputId UNIQUEIDENTIFIER = 'YOUR_RECORD_ID_HERE';

WITH ReverseCTE AS
(
 -- شروع از رکورد مورد نظر
 SELECT Id, ParentId, Name, 0 AS Level
 FROM Table1
 WHERE Id = @InputId

 UNION ALL

 -- پیمایش به سمت والد
 SELECT p.Id, p.ParentId, p.Name, c.Level + 1
 FROM Table1 p
 INNER JOIN ReverseCTE c ON c.ParentId = p.Id
 WHERE c.ParentId IS NOT NULL
)
SELECT *
FROM ReverseCTE
ORDER BY Level DESC; -- ریشه بالای خروجی

اگر فقط ریشه براتون مهمه:

SELECT TOP 1 Id, Name
FROM ReverseCTE
ORDER BY Level DESC;

🔹 نکات حرفه‌ای 💡
برای هر عمق درختی جواب می‌ده
مناسب گزارش‌ها، داشبوردها و تحلیل سلسله‌مراتبی
می‌تونید مسیر رو به صورت رشته /Root/Parent/Child/... هم بسازید تا راحت نمایش بدید

🧠 تجربه شخصی:
وقتی شما از پایین شروع می‌کنید و مسیر تا ریشه رو پیدا می‌کنید، دید کامل‌تری نسبت به سلسله‌مراتب پیدا می‌کنید.
مثل اینه که بفهمید یک کارمند دقیقاً تحت چه مدیریتی و چه شاخه‌ای از سازمان قرار گرفته.

تا حالا Running Total تو SQL Server نوشتی و با خیال راحت رد شدی؟ 😌



📌 معمولاً برای Running Total یه چیزی شبیه این می‌نویسیم:

SUM(TotalDue) OVER (

  PARTITION BY CustomerID

  ORDER BY OrderDate

)

همه‌چیز هم ظاهراً درسته…

اما دقیقاً همین‌جا مشکل شروع میشه 😐

🔍 مشکل کجاست؟

وقتی داخل OVER فقط ORDER BY می‌نویسیم و چیز دیگه‌ای مشخص نمی‌کنیم،

خود SQL Server به‌صورت پیش‌فرض از این استفاده می‌کنه 👇

RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW

و این یعنی چی؟ 🤔

یعنی اگر تو ستون ORDER BY (مثلاً OrderDate) مقدار تکراری وجود داشته باشه:

اونقوت SQL Server تمام ردیف‌هایی که تاریخ یکسان دارن رو «یک ردیف منطقی» در نظر می‌گیره

و Running Total برای همه اون‌ها با هم محاسبه میشه

نتیجه؟

➕ جمع یه‌هو می‌پره

😵‍💫 چیزی که حس می‌کنیم غلطه، ولی در واقع «غیرمنتظره» است


❗️ نکته مهم:

1- SQL Server اشتباه نکرده

2- ما ناخواسته رفتار RANGE رو فعال کردیم


🚀 راه‌حل درست و حرفه‌ای:

اگه Running Total واقعی می‌خوای، یعنی ردیف‌به‌ردیف و بدون پرش،

باید صریح بنویسی:

SUM(TotalDue) OVER (

  PARTITION BY CustomerID

  ORDER BY OrderDate

  ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW

)

یا حتی کوتاه‌تر:

ROWS UNBOUNDED PRECEDING

✔️ محاسبه دقیق

✔️ بدون رفتار عجیب

✔️ بازدهی خیلی بهتر (In-Memory به‌جای TempDB)




🧠 جمع‌بندی

همیشه Defaultها دوست ما نیستن

استفاده از RANGE فقط وقتی خوبه که عمداً بخوای Tieها یکی حساب بشن

برای ۹۹٪ سناریوهای Running Total → ROWS رو همیشه صریح بنویس



یه خط کداضافه ، ولی کلی تفاوت تو نتیجه و Performance 🔥

#SQLServer #TSQL #DBA #Performance #WindowFunctions #RunningTotal #DatabaseTips

سلام دوستان

🚨 تا حالا شده بری Shrink File و با خودت بگی:
«اینا رو با یه SELECT نمیشه دید؟!» 🤔

خبر خوب برای DBAها و Backend Engineerها 🎉
بله… میشه! و حتی تمیزتر، سریع‌تر و قابل اتوماسیون 😎

🧠 مسئله چیه؟
تو SQL Server وقتی میری:
بخش Shrink Database
یا Shrink File

برای هر فایل اینا رو می‌بینی:
Total Size
Used Space
Free Space

اما این اطلاعات:
❌ اسکریپت‌پذیر نیست
❌ تو مانیتورینگ نمیاد
❌ تو گزارش DBA جایی نداره

🎯 سناریوی خیلی واقعی (احتمالاً الان داری باهاش دست‌وپنجه نرم می‌کنی 😅)
فرض کن:
روی یک سیستم تستی / Staging کار می‌کنی
می‌خوای روی یک دیتابیس خاص تغییرات سنگین بدی فضا کم آوردی 😬
اون دیتابیس هم ۱۰ تا Data File مختلف + یکی دوتا Log داره

حالا سوال مهم اینه 👇
👉 از کدوم فایل واقعاً می‌تونم فضا آزاد کنم؟
👉 کدوم فایل عملاً پره و Shrink روش جواب نمی‌ده؟

اینجاست که Shrink UI دیگه کافی نیست…
و یه SELECT حسابی نجاتت می‌ده 😏
✅ راه‌حل حرفه‌ای
با کوئری زیر، دقیقاً همون چیزی که UI نشون می‌ده رو می‌گیری
برای:

Data File 🗂
Log File 🧾

SELECT
 df.name,
 df.type_desc,
 df.physical_name,
 df.size / 128.0 AS TotalSizeMB,
 CASE 
 WHEN df.type = 1 
 THEN ls.used_log_space_in_bytes / 1024 / 1024 
 ELSE FILEPROPERTY(df.name, 'SpaceUsed') / 128.0
 END AS UsedSpaceMB,
 CASE 
 WHEN df.type = 1 
 THEN (df.size / 128.0) - (ls.used_log_space_in_bytes / 1024 / 1024)
 ELSE (df.size - FILEPROPERTY(df.name, 'SpaceUsed')) / 128.0
 END AS FreeSpaceMB
FROM sys.database_files df
OUTER APPLY sys.dm_db_log_space_usage ls;

💎 این کوئری دقیقاً کجاها می‌درخشه؟
✨ وقتی روی Test / QA / Staging فضا کم آوردی
✨ وقتی دیتابیس چندین فایل داره و تصمیم‌گیری سخته
✨ برای اینکه بدونی کدوم فایل ارزش Shrink داره
✨ قبل از Extend کردن دیسک (که همیشه هم در دسترس نیست 😐)
✨ توی Monitoring Dashboard
✨ برای Capacity Planning واقعی، نه حدسی

👥 این کد به درد کی می‌خوره؟
👨‍💻دوستان DBAها (Junior تا Senior)
👨‍💻همچنین Backend Engineerهایی که SQL Server دارن
🏢 تیم‌های DevOps و Infra
📊 برای داشبوردهای Monitoring

⚠️ یادآوری دوستانه DBA‌طور
🔴اول اینکه Free Space ≠ Space قابل Shrink
🔴و Shrink مُسکنه، نه درمان
🔴 اول علت رشد فایل رو بفهم، بعد تصمیم بگیر

hashtag#SQLServer hashtag#DBA hashtag#Monitoring hashtag#CapacityPlanning hashtag#TSQL hashtag#DevOps hashtag#DataEngineering 🚀

سلام دوستان عزیزم
امیدوارم حالتون عالی باشه
من بعد از بیش از یک ماه تازه الان موفق شدم وصل بشم
این کانال رو در بله هم ساختم
گروه مشابهدهم در بله ساختم که اگه شرایط دوباره تغییر کرد بتونیم اونجا ادامه بدیم

لینک کانال

https://ble.ir/join/A5jkHESCYB

لینک گروه

https://ble.ir/join/741aKHYbrA

سلام دوستان 👋

یه مدتیه دارم روی یه ایده کار می‌کنم و دوست دارم قبل از شروع، نظر شما رو بدونم.

قصدم اینه که یه سری وبینار کوتاه و کاربردی برگزار کنم؛ نه از اون مدل وبینارهایی که ۵۰ تا اسلاید نشون میدن و آخرش هم چیزی عاید آدم نمیشه!

بیشتر میخوام درباره چالش‌های واقعی سازمان‌ها صحبت کنیم. چیزهایی که توی پروژه‌ها و شرکت‌ها واقعاً باهاشون درگیریم:

قطعی سرویس‌ها
مشکلات Performance
Backup و Disaster Recovery
مانیتورینگ و پیشگیری از بحران
رشد دیتابیس‌ها و ظرفیت زیرساخت
امنیت و ریسک‌های پنهان

قبل از اینکه موضوع اولین وبینار رو مشخص کنم، دوست دارم از خودتون بشنوم:

❓ بزرگ‌ترین چالشی که الان توی SQL Server، دیتابیس یا زیرساخت داده سازمانتون دارید چیه؟

❓ اگر قرار باشه فقط یک مشکل رو توی ۶ ماه آینده حل کنید، اون مشکل چیه؟

لطفاً توی کامنت‌ها بنویسید. حتی اگر فکر می‌کنید موضوع خاصیه یا به درد بقیه نمی‌خوره.

همچنین توی نظرسنجی زیر هم شرکت کنید 👇

اگر دوست دارید یکی از چالش‌های واقعی سازمان شما (به صورت کاملاً ناشناس) توی یکی از وبینارها بررسی بشه، فقط بنویسید:
«علاقه‌مندم»
تا برای هماهنگی باهاتون در ارتباط باشم. 🙏

روزی از یک مرکز درمانی با من تماس گرفتند 📞

گفتند سیستم به شدت کند شده و عملاً کار پذیرش با مشکل مواجه شده است ⚠️

پشت هر کندی سیستم در مراکز درمانی، فقط چند ثانیه تأخیر نیست…

بیمار منتظر است 🧍‍♂️

پذیرش کلافه شده 😓

صف طولانی‌تر می‌شود ⏳

پزشک منتظر ثبت اطلاعات است 🩺

و فشار کاری لحظه به لحظه بیشتر می‌شود

به صورت آنلاین وارد سرور شدم و بررسی را شروع کردم 💻

اولین نکته این بود که SQL Server به نسخه جدید ارتقا پیدا کرده بود و Compatibility Level هم تغییر کرده بود. آن را به حالت قبلی برگرداندم 🔧

بعد سراغ منابع سرور رفتم

CPU به شدت درگیر بود 🔥

تنظیمات MAXDOP اصلاح شد و کمی وضعیت بهتر شد، اما مشکل اصلی هنوز باقی بود

در مرحله بعد Query Store را بررسی کردم و Queryهای پرمصرف را بر اساس CPU استخراج کردم 📊

نتیجه واضح بود

یک Query پرتکرار که ایندکس مناسب نداشت، بخش بزرگی از CPU را مصرف می‌کرد

ایندکس ایجاد شد ⚙️

چند دقیقه بعد، مصرف CPU به شکل محسوسی کاهش پیدا کرد 📉

و سیستم به حالت عادی برگشت ✅

کل این بحران-از صف‌های طولانی تا نارضایتی کاربران-در نهایت به نبود یک ایندکس مناسب ختم شد

و اینجاست که همیشه این جمله برایم پررنگ‌تر می‌شود:

مانیتورینگ پایگاه داده و حضور یک DBA فقط برای زمانی نیست که همه چیز خوب است…

ارزش واقعی آن زمانی مشخص می‌شود که سیستم در آستانه فروپاشی است 🚨

گاهی تفاوت بین یک روز عادی و یک بحران بزرگ، فقط یک ایندکس است 🎯

خیلی ازمن این سوال پرسیده میشه که میخوایم SQL Server رو شروع کنیم باید چیکار کنیم.
ببینید شما اول باید مشخص کنید در چه مسیری میخواین پیش برید
این چند مسیر در ادامه یادگیری SQL Server وجود داره.
1- فعالیت به عنوان DBA یا Database Administrator
2- فعالیت به عنوان T-SQL Developer
3- فعالیت به عنوان تحلیلگر داده و طراح گزارشات

خوب برای هر سه مسیر اولین و مهمترین چیز ، یادگیری T-SQL هست. هیچکدوم از این سه مسیر بدون یادگیری حرفه ای T-SQLمعنی ندارن.
برای T-SQL بهترین و کاملترین منبع ، کتاب T-SQL Fundamental آقای Itzik Ben-GAN هست . من هم همین کتاب رو به صورت کامل در مکتبخونه تدریس کردم که لینکش رو قرار میدم.

خوب حالا مسیر اول شما باید علاقمند باشین به دیباگ سرورها ، بتونید استرس خودتون رو کنترل کنید. علاقمند باشین به کارهای پیچیده و پرحجم. مطالعات عمیق روی حوزه های مختلف داشته باشین.
برای مسیر دوم باید همین مسیر T-SQL رو پیشرفته تر مطالعه کنید و به حوزه Performance Tuning هم سری بزنید. ( یک دوره هم دراین زمینه در مکتبخونه ضبط کردم)

برای حوزه سوم بعد از درک کامل T-SQL باید به سراغ مفاهیم BI برید و با داشبوردها کار کنید. با ETL ها کار کنید و با SSAS آشنا بشین.
بعد هم در ادامه برید سراغ پایتون و یادگیری ماشین برای تحلیل های عمیقتر.

برای حرفه ای شدن در هر حوزه حداقل یک سال زمان نیاز خواهید داشت
برای هر حوزه هم بازارکار خیلی خوبی در کشور وجود داره و به شدت بازار کار تشنه هست.
اینم لینک هر دو دوره .

https://maktabkhooneh.org/course/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-sql-server-performance-tuning-mk6185/?v=1
https://maktabkhooneh.org/course/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-sql-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-sql-server-mk1378/?v=1

سلام دوستان
📊 چرا با وجود صرف هزینه‌های زیاد برای ساخت گزارش‌ها، بسیاری از آن‌ها در عمل استفاده نمی‌شوند؟
در یکی از پروژه‌هایی که روی آن کار می‌کردم، کنار یکی از کاربران سازمان نشستم تا ببینم گزارش‌ها را چطور استفاده می‌کند.
اتفاق جالبی افتاد.
کاربر گزارش را باز کرد، چند ثانیه به آن نگاه کرد و بعد... فایل Excel شخصی خودش را باز کرد.
شروع کرد اطلاعات گزارش را یکی‌یکی وارد Excel کند و تحلیلش را آنجا ادامه داد.
همان لحظه یک سؤال در ذهنم شکل گرفت...
اگر سازمان‌ها برای طراحی گزارش‌ها زمان، انرژی و هزینه زیادی صرف می‌کنند، چرا بسیاری از کاربران در نهایت دوباره به Excel برمی‌گردند؟ 🤔
آیا مشکل از کیفیت گزارش‌هاست؟
یا گزارش‌ها بر اساس نیاز واقعی کاربران طراحی نمی‌شوند؟
یا شاید اصلاً مسئله چیز دیگری است...
من فعلاً قصد ندارم به این سؤال پاسخ بدهم.
دوست دارم از تجربه شما یاد بگیرم. 🌱
اگر در سازمانتان گزارش‌هایی وجود دارد که کمتر از آنچه انتظار می‌رفت مورد استفاده قرار می‌گیرند، به نظر شما مهم‌ترین دلیل چیست؟
👤 فرقی نمی‌کند مدیرعامل باشید، مدیر واحد، کارشناس، تحلیلگر داده، DBA یا توسعه‌دهنده BI.
تجربه شما می‌تواند به شناخت یک الگوی مشترک در سازمان‌ها کمک کند.
💬 مشتاقم نظرات و تجربه‌های واقعی شما را بخوانم.
━━━━━━━━━━━━━━
🔍 Organizational Patterns
من در حال مطالعه الگوهای مشترک در سازمان‌ها هستم؛ الگوهایی که بر نحوه تصمیم‌گیری، همکاری تیم‌ها و خلق ارزش اثر می‌گذارند.
اگر تجربه مشابهی دارید، خوشحال می‌شوم آن را در بخش نظرات با من و دیگران به اشتراک بگذارید.

🧩 Organizational Pattern #001

سلام
📊 چند روز پیش درباره این سؤال نوشتم که چرا بسیاری از گزارش‌ها و داشبوردهای سازمانی استفاده نمی‌شوند.
صادقانه بگویم، انتظار داشتم بیشتر درباره ابزارها، تکنولوژی یا نحوه طراحی گزارش صحبت شود.
اما چیزی که از دل گفتگوها بیرون آمد، برای خودم هم جالب بود.
تقریباً هرکسی از زاویه تجربه خودش به موضوع نگاه می‌کرد:
🔹 یکی می‌گفت باید کنار کاربر نشست و رفتار واقعی او را دید.
🔹 دیگری می‌گفت همیشه چنین فرصتی وجود ندارد و محدودیت‌های سازمانی را هم باید در نظر گرفت.
🔹 فردی روی آموزش کاربران و نقش Master Trainer تأکید داشت.
🔹 عده‌ای معتقد بودند مشکل اصلی، بلوغ پایین سازمان‌ها در استفاده از داده است.
نکته‌ای که برای من پررنگ شد این بود که ما معمولاً تصور می‌کنیم همه درباره یک مسئله صحبت می‌کنیم؛ در حالی که هرکدام از ما در حال توصیف بخشی از یک سیستم بزرگ‌تر هستیم.
شاید مسئله اصلی «گزارش» نباشد.
شاید مسئله، فاصله‌ای باشد که بین نگاه توسعه‌دهنده، مدیر، کاربر و تصمیم‌گیرنده وجود دارد.
هرکدام واقعیت را از زاویه خودش می‌بیند و اگر این زاویه‌ها به هم متصل نشوند، حتی بهترین نرم‌افزارها هم نمی‌توانند ارزش واقعی ایجاد کنند.
برای من، این گفتگو فقط درباره گزارش نبود؛ بلکه شروع یک سؤال بزرگ‌تر بود:

"❓ به نظر شما، بزرگ‌ترین شکاف بین تیم‌های فنی و کسب‌وکار در سازمان‌ها چیست؟ "

اگر تجربه‌ای دارید، خوشحال می‌شوم آن را بخوانم. احتمالاً پاسخ‌ها، مثل دفعه قبل، از خود سؤال ارزشمندتر خواهند بود.

🧩 Organizational Pattern #002

چند روز پیش روی یکی از دیتابیس‌ها با یک سناریوی جالب روبه‌رو شدم که شاید برای خیلی از 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 فقط یک علامت باشد و بعد از بررسی دقیق‌تر متوجه شوید ریشه اصلی مشکل جای دیگری بوده است؟

سلام دوستان عزیزم.

👨‍💻 یکی از سوال‌هایی که همیشه ازم می‌پرسن اینه که:
«توی مصاحبه فنی از افراد چی می‌پرسی؟» 🤔
پیرو چند پست قبلی که درباره مصاحبه نوشتم، بد نیست اینم بگم که من معمولا افراد رو از نظر سطح دانش به چهار دسته تقسیم می‌کنم:
🔹 کارآموز
🔹 مبتدی
🔹 متوسط
🔹 حرفه‌ای
و جالبه که نوع سوالاتم برای هر کدوم کاملا فرق می‌کنه.
مثلا اگر کسی بگه:
«من Senior هستم» 😎
راستش اولین چیزی که برام مهمه این نیست که چند تا Query از حفظ بلده یا چقدر سریع کد می‌نویسه.
اتفاقا خیلی از مصاحبه‌ها از همون دقیقه اول میگن:
"این مسئله رو حل کن، کدش رو بنویس."
این روش بد نیست... ولی من بیشتر دوست دارم قبل از اینکه حتی به کد برسیم، بفهمم اون آدم دیتابیس رو واقعا درک کرده یا فقط باهاش کار کرده.
مثلا ازش می‌پرسم:
🟢وقتی SQL Server Engine این Query رو اجرا میکنه چه رفتاری داره؟
🟢 اثری که این کد روی Performance میذاره چیه؟
🟢 اگر سیستم کند بشه، از کجا شروع می‌کنی مشکل رو پیدا کنی؟
🟢 وقتی یک نیاز از سمت کاربر میاد، چطور اون رو تبدیل به طراحی دیتابیس و پیاده‌سازی می‌کنی؟
🟢 اگر بین چند راه‌حل انتخاب داشته باشی، چرا یکی رو انتخاب می‌کنی؟
برای من طرز فکر آدم‌ها از خود جواب‌ها مهم‌تره.
اما وقتی طرف در سطح مبتدی یا متوسط باشه، طبیعتا انتظارم فرق می‌کنه.
اونجا بیشتر میرم سراغ مفاهیم پایه:
✅ این دستور دقیقا چه کاری انجام میده؟
✅ کجا باید ازش استفاده کرد؟
✅ تفاوتش با دستور مشابهش چیه؟
✅ اگر بخوای این مسئله رو حل کنی، اولین قدمت چیه؟
و یکی از سوال‌های مورد علاقه‌م همیشه اینه:
💡 «جذاب‌ترین چالشی که تا امروز حل کردی چی بوده؟»
نه برای اینکه جواب درست یا غلط داره...
برای اینکه از روی نحوه تعریف کردنش میشه فهمید:
چقدر عمیق فکر می‌کنه.
چطور مسئله رو تحلیل می‌کنه.
از چه ابزارهایی استفاده کرده.
و مهم‌تر از همه... آیا از حل کردن مسئله لذت می‌بره یا فقط دنبال بستن تیکت بوده؟ 😄
به نظر من، گاهی با همین چند سوال میشه شناختی از یک مهندس به دست آورد که شاید با یک ساعت کدنویسی هم به دست نیاد.
❓حالا دوست دارم نظر شما رو هم بدونم.
اگر شما مصاحبه‌کننده باشید، اولین سوالی که از یک Database Developer یا Data Engineer می‌پرسید چیه؟

سلام دوستان عزیزم

۵۰۰ دوره آموزشی مکتب‌خونه رایگان شد.

دوره آموزش پایگاه داده بنده نیز در لیست دوره ها قرار داره.

فراهم‌کردن دسترسی گسترده‌تر به آموزش باکیفیت، یکی از اهداف اصلی مکتب‌خونه است. در ادامه این مسیر، در طرح «ایرانِ ‌ماهر» ۵۰۰ دوره آموزشی تا ۸ شهریور رایگان شده است.

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

دوره‌های رایگان ایران ‌ماهر موضوعات متنوعی را پوشش می‌دهند؛ از برنامه‌نویسی، هوش مصنوعی و آی‌تی تا زبان، مدیریت، بازاریابی، مالی، حسابداری و مهارت‌های شغلی.

برای استفاده از این فرصت، از طریق لینک زیر دوره مورد نظرتان را انتخاب کنید و با وارد کردن کد IRANMAHER در مرحله پرداخت، آن را با تخفیف ۱۰۰٪ دریافت کنید.

اگر فکر می‌کنید این فرصت می‌تواند برای فرد دیگری هم مناسب باشد، این پست را با او به اشتراک بگذارید.

https://land.maktabkhooneh.org/iranmaher/?utm_source=linkedin&utm_medium=social&utm_campaign=iranmaher-linkedin-social-mk

یکی از چالش‌هایی که این روزها توی شرکت‌ها زیاد باهاش برخورد می‌کنم، مخصوصاً در حوزه BI، تعریف درست مسئله است.

گاهی می‌بینم سازمان اصلاً واحد یا نقش مشخصی برای این کار نداره و هر بخشی، از زاویه خودش، شروع می‌کنه به تعریف مسئله و ارائه راهکار.

اینجاست که کم‌کم داستان جالب میشه! 😄

چون همین موضوع می‌تونه باعث ایجاد تضاد منافع بین واحدهای مختلف، مخصوصاً کسب‌وکار و فناوری اطلاعات، بشه.

به نظرم قبل از اینکه بریم سراغ زیرساخت فنی، دیتابیس، ابزار BI یا انتخاب تکنولوژی، باید یک چیز دیگه رو درست کنیم:

زیرساخت کسب‌وکار.

یعنی اول مشخص کنیم:

🔹 چه کسی مسئله رو تعریف می‌کنه؟

🔹 چه کسی مالک مسئله است؟

🔹 نقش IT دقیقاً چیه؟

🔹 ارتباط بین واحد کسب‌وکار و IT چطور باید باشه؟

🔹 تصمیم‌گیری در مورد راهکار با چه کسیه؟

🔹 و اصلاً مسئله‌ای که داریم حل می‌کنیم، دقیقاً چیه؟



خیلی وقت‌ها مشکل اصلی سازمان کمبود تکنولوژی نیست.

مشکل اینه که چند نفر دارن یک مسئله رو، هر کدوم از زاویه خودشون، تعریف می‌کنن.



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

هدف اینه که جلوی این سایش‌ها رو قبل از اینکه تبدیل به یک مشکل جدی برای سازمان بشن بگیریم.

حالا کنجکاوم بدونم شما توی سازمان‌تون برای این موضوع چه راهکاری دارید؟

تعریف مسئله معمولاً دست چه کسیه؟ و وقتی بین کسب‌وکار و IT اختلافی پیش میاد، چطور حلش می‌کنید؟



و البته...



اگر چنین چالش‌هایی دارید و دنبال یک نفر می‌گردید که وسط این دعواها بایسته و مسئله رو جمع کنه، می‌تونید روی من حساب کنید! 😄

قول نمی‌دم همه از جلسه راضی بیان بیرون،

ولی قول می‌دم مسئله بالاخره صاحب پیدا کنه! 😂

اگر هم دوست دارید عکس «قبل از جلسه» رو بفرستید و «جنازه تحویل بگیرید»، اون مدل همکاری رو باید با تیمم بررسی کنم! 😂

ولی جدا از شوخی، بخش زیادی از کاری که انجام می‌دم دقیقاً همینجاست؛

جایی بین کسب‌وکار، IT، داده و آدم‌ها.

جایی که معمولاً مشکل، نبودن تکنولوژی نیست؛

مشکل اینه که هنوز معلوم نیست کی باید چه کاری رو انجام بده و اصلاً داریم چه مسئله‌ای رو حل می‌کنیم.

یکی از چیزهایی که توی بعضی تیم‌ها می‌بینم، بیشتر از اینکه شبیه تیم باشه، شبیه مسابقات انتخاباتیه! 😂
هنوز پروژه شروع نشده، ولی یارکشی شروع شده:
«تو با مایی؟»
«اون با اوناست.»
«پس اینو به اون نگو!»
«جلسه داریم؟ کی تو جلسه‌ست؟»
«فلانی هم هست؟ پس من نمیام!» 😐
گاهی اوقات یک تیم ۱۰ نفره داریم با ۴ تا جبهه!
هر جبهه هم یک رهبر داره، یک تحلیلگر داره، یک سخنگو داره و البته چند نفر هم هستن که هنوز نمی‌دونن دقیقاً عضو کدوم جبهه‌ان! 😂
بعد کم‌کم آثارش خودش رو نشون میده.
لجبازی شروع میشه.
تقصیرها میفته گردن همدیگه.
اطلاعات تبدیل میشه به سلاح جنگی.
جلسه‌ها به جای حل مسئله، میشه دادگاه.
ناهار خوردن هم میشه محل تجدید قوا! 😄
یه عده با هم میرن ناهار و درباره یه عده دیگه حرف می‌زنن.
یه عده دیگه هم همون موقع یه جای دیگه نشستن و دارن درباره گروه اول حرف می‌زنن!
و در نهایت، هیچ‌کس دیگه دقیقاً نمی‌دونه مشکل اصلی چی بوده.
فقط همه مطمئنن که:
«مشکل از اوناست!» 😂
اینجاست که به نظرم نقش یک مربی یا لیدر خیلی جدی میشه.
قرار نیست فقط KPI و تسک و خروجی تیم رو نگاه کنه.
باید بفهمه چه کسی با چه کسی مشکل داره، چرا مشکل داره و این اختلاف داره چه بلایی سر کار میاره.
چون اگر این داستان به موقع مدیریت نشه، یه اختلاف ساده بین دو نفر می‌تونه کل تیم رو تبدیل کنه به جنگ داخلی.
و بدتر از همه اینکه معمولاً وسط این جنگ، پروژه هم یه گوشه نشسته و داره با خودش میگه:
«بچه‌ها من فقط قرار بود تحویل داده بشم... چرا به خاطر من جنگ جهانی راه انداختید؟!» 😂
به نظرم یکی از نشونه‌های یک تیم سالم این نیست که همه با هم دوست صمیمی باشن.
اینکه بتونن با وجود اختلاف نظر، هنوز کنار هم کار کنن خیلی مهم‌تره.
شما توی تیم‌هاتون با این مدل یارکشی مواجه شدید؟ 😄

دو تا گل خوردی. 😐
نیمه اول تموم شده و تیم هم واقعاً افتضاح بازی کرده.
حالا وقتشه مربی بره وسط رختکن و شروع کنه:
«این چه وضع بازی کردنه؟!
اصلاً معلومه دارید چیکار می‌کنید؟!
این تیم با این وضع به هیچ جا نمی‌رسه!»
بعد هم چند تا بازیکن رو تحقیر کنه که روحیه‌شون هم کامل نابود بشه. 😑
جالبه که هنوز خیلی‌ها فکر می‌کنن این یعنی «رهبری مقتدر».
در حالی که خیلی وقت‌ها اسمش فقط تخلیه عصبانیت مدیریتیه! 😂
واقعیت اینه که تیم، فقط مجموعه‌ای از آدم‌ها نیست که کنار هم کار می‌کنن.
تیم یک رابطه‌ست.
گاهی مدیر از تیم چیزی می‌خواد و تیم بهش نمی‌ده.
گاهی تیم چیزی از مدیر می‌خواد و مدیر بهش نمی‌ده.
و دقیقاً از همین‌جا فاصله شروع میشه.
نه یک‌دفعه.
آروم‌آروم...
با یک جلسه که کسی حرف واقعی‌اش رو نمی‌زنه.
با یک تصمیم که فقط از بالا گرفته میشه.
با چند بار شنیدنِ «الان وقت این بحث‌ها نیست».
با مدیری که فقط خروجی می‌خواد، ولی هیچ‌وقت نمی‌پرسه:
«برای اینکه این خروجی رو بسازید، از من چی لازم دارید؟»
و بعد یک روز می‌بینیم تیم هست...
جلسه هست...
KPI هست...
گزارش هم هست...
ولی تیم بودن نیست.
به نظرم یکی از مهم‌ترین وظایف یک رهبر این نیست که وقتی تیم خراب کرد، بیشتر فشار بیاره.
این نیست که صدایش را بلندتر کند.
این نیست که دنبال مقصر بگردد.
وظیفه‌اش اینه که بفهمه:
«من برای بهتر شدن این تیم، خودم چه چیزی رو باید تغییر بدم؟»
گاهی اوقات موندن در همین وضعیت موجود، خیلی دردناک‌تر از تغییر کردنه.
و تیم‌های خوب دقیقاً همین‌جا خودشون رو نشون میدن.
ممکنه دو تا گل خورده باشن...
ولی برمی‌گردن توی زمین و میگن:
«خب... حالا بریم جبرانش کنیم.» 🔥
شاید فرق یک مدیر معمولی و یک رهبر واقعی همین باشه:
مدیر می‌پرسه:
«کی خراب کرد؟»
رهبر می‌پرسه:
«چطور دوباره برگردیم به بازی؟»
حالا یک سؤال جدی:
اگر تیم شما عملکرد خوبی نداره...
اولین چیزی که باید تغییر کنه چیه؟
آدم‌های تیم؟
یا مدل رهبری ما؟
بیاید ببینیم چند نفر جرأت دارن گزینه دوم رو انتخاب کنن. 👀

اگه برای پولدار شدن، اول باید پولدار باشی چی؟! 🤔😂
نه، اشتباه تایپی نکردم!
امروز از مربی عزیزم یک فیلم می‌دیدم که بحثش دقیقاً همین بود:
بودن، انجام دادن و داشتن.
ما معمولاً این‌طوری فکر می‌کنیم:
اول باید داشته باشم ➡️
بعد باهاش یک کاری انجام بدم ➡️
بعد به یک احساسی برسم.
مثلاً:
«اگه یه هواپیمای شخصی داشته باشم، می‌تونم هر وقت دلم خواست برم سفر و تفریح، اون‌وقت خیلی خوشحال و راضی می‌شم.» ✈️😎
یا:
«اگه پول بیشتری داشته باشم، خیالم راحت می‌شه و احساس ثروتمند بودن می‌کنم.» 💰
ولی یک سؤال جالب مطرح شد:
نکنه مسیر برعکس باشه؟ 🤔
یعنی اول اون چیزی که می‌خوای احساس کنی رو در خودت ایجاد کنی.
بعد بر اساس اون احساس، رفتار کنی.
و در نهایت، اون «داشتن» هم کم‌کم شکل بگیره.
مثلاً اگر می‌خوای ثروتمند باشی، از خودت بپرسی:
اگر واقعاً ثروتمند بودم،
چطور فکر می‌کردم؟
چطور تصمیم می‌گرفتم؟
چطور با آدم‌ها حرف می‌زدم؟
چطور ریسک می‌کردم؟
چطور فرصت‌ها رو می‌دیدم؟
حالا یک مثال بامزه‌تر:
فرض کنید یک سرمایه‌گذار اتفاقی به پست شما بخوره و بگه:
«من برای ایده‌ات سرمایه‌گذاری می‌کنم.» 😎💰
به نظرت از نوشته و رفتارت چه چیزی باید بگیره؟
حس غنی بودن؟
یا:
«داداش فقط یه سرمایه‌گذار پیدا بشه، زندگیم درست می‌شه!» 😂
شاید ما خیلی وقت‌ها منتظریم چیزی را داشته باشیم تا تبدیل به آدمی بشیم که می‌خوایم باشیم.
در حالی که شاید باید اول اون آدم بشیم تا بعضی از اون چیزها وارد زندگیمون بشن.
من خودم تجربه‌های مختلفی از این موضوع داشتم و جالب اینجاست که یکی دیگه از استادهای عزیزم هم سال‌ها قبل تقریباً همین مفهوم رو به شکل دیگه‌ای بهم گفته بود.
و راستش هر بار که تجربه‌اش کردم، بیشتر بهش فکر کردم.
شاید سؤال درست این نباشه که:
«چی می‌خوام داشته باشم؟»
بلکه این باشه:
«وقتی به چیزی که می‌خوام رسیدم، قرارِ چه آدمی باشم و چه حسی داشته باشم؟»
و بعد...
از همین امروز همون آدم باشم. 🎯
حالا کنجکاوم بدونم شما چی فکر می‌کنید؟ 👇
تا حالا شده اول «حس و حالِ داشتنِ یک چیز» رو در خودتون ایجاد کنید و بعد خود اون اتفاق بیفته؟
یا کلاً می‌گید:
«نه داداش، اول هواپیما رو بده، بعد درباره حسش صحبت می‌کنیم!» 😂✈️