گاهی وقتا برای فهمیدن پشت‌صحنه‌ی واقعی SQL Server باید یه ذره چراغ‌قوه‌ی مخفی روشن کنیم 😎🔦

یکی از چیزهایی که همیشه کمکم کرده بفهمم دقیقاً اون زیر چه خبره، همین دستور معروفه:



dbcc traceon(3004,3604,-1)



این دستور باعث میشه جزییات کامل عملیات Backup و Restore رو ببینی؛

جزییاتی که SQL Server معمولاً ساکت و بی‌صدا انجامشون میده ولی ما می‌خوایم بدونیم دقیقاً در حال رخ دادن چیه ⚙️👀

نکته‌ی جالبش اینه که تو این جزییات دقیقاً مشخص می‌کنه:



✔️بکاپ یا ریستور با چه پارامترهایی داره انجام میشه،

✔️کدوم مرحله بیشترین زمان رو می‌بلعه،

✔️و چطور می‌تونی کل فرآیند رو بهینه‌تر کنی ⏱️🚀



وقتی فعالش می‌کنی، انگار وارد اتاق کنترل موتور SQL Server شدی و داری قدم‌به‌قدم همه‌چیز رو لایو نگاه می‌کنی 🔍💡

و اما نکته‌ی مهم برای کسایی که تازه با این Trace Flagها آشنا می‌شن:



✔️Trace Flag 3004: مسئول نوشتن لاگ عملیات Backup/Restore هست.

✔️Trace Flag 3604: به SQL Server میگه همین لاگ‌ها رو مستقیم داخل نتیجه‌ی همون کوئری نشون بده.

یعنی دقیقاً همان لحظه همونجا می‌بینی چه اتفاقی داره میفته 😍📜

برای من این چیزا فقط یه دستور نیستن؛

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



#SQLServer #DBA #TraceFlag #BackupRestore #PerformanceTuning #DatabaseInternals #Monitoring #MicrosoftSQLServer #DataEngineering

سلام دوستان

🚨 تا حالا شده بری 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 🚀