سلام خدمت دوستان عزیزم
امیدوارم که عالی عالی باشین

میخوام در این پست اشاره ای کنم به اینکه اساسا DBA چیست؟ (ببخشید کیست). 😁

بیاین اینجوری نگاه کنید که یک DBA مثل یک کارآگاه می مونه.

حالا چرا کارآگاه؟

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

حالا بریم یک مثال واقعی براتون بزنم

چند روز پیش بکاپ هارو بررسی میکردم و میدیدم که حجمش خیلی عجیب غریب داره میره بالا. مثلا توی یک روز دیدم ۶۰ گیگابایت بکاپ Diff ما شده در صورتی که شب قبلش ما Full backup داشتیم. توی این چند روز من جداول رو نگاه میکردم ،‌اول شک کردم به حجم داده های جداول شاید یک دفعه زیاد شده. بعد از این رشد عجیب غریب نگاه کردم دیدم داده ها تغییر محسوسی نداشتن ولی حجم بکاپ این دفعه ۱۵ گیگابایت باز بهش اضافه شده. به فایل LOG شک کردم و اونو بررسی کردم دیدم بله یک دفعه حجمش شده ۲۰۰ گیگابایت. رفتم سراغ دلیل این مساله.

اول Log backupها رو بررسی کردم دیدم همش درسته.

بعد رفتم دستور زیر رو اجرا کردم



Select Name , Log_reuse_wait_desc from sys.databases



دراین کد بیان میکنه که Log File شما Wait چه مساله ای هست که رشد می کنه. دیدم که در این فیلد نوشته Replication. ماهم که Replication نداشتیم ولی CDC رو راه اندازی کرده بودم.

جاب CDC رو بررسی کردم دیدم که Stop شده و به دلیل اینکه Alarm ها خیلی زیاد بوده در لاگ من گم شده و ندیدمش. اونو Start کردم و این حجم Used فایل LDF کاهش پیدا کرد. به دلیل اینکه فایل LDF من Fragment هم شده بود اومدم فایل LDF رو Shrink کردم و حجمش رو کاهش دادم روی ۲۰ گیگابایت و Fragment اون هم مرتفع شد( به دلیل اینکه قبلا هم روی این حجم تنظیمش کرده بودم)

یکی از دلایل Fragment بودن فایل LDF تعداد بالای VLF هاست. و این VLF ها به ازای هرمرتبه ای که یک Grow در فایل LDF رخ میده اضافه میشن.

این دفعه که Full backup گرفتم حجمش تقریبا ۲۰ گیگابایت کاهش پیدا کرد و به عدد نرمال قبلی رسیدم.



کسی که DBA هست مرتبا باید همه این موارد رو به صورت روزانه چک کنه و کنترل کنه. حتما باید سیستم مانیتورینگ باشه. حتما باید سیستم Alarming داشته باشین.

و حتما باید Error log ها رو مدیریت کنید که یک دفعه مثل من حجم Error های بدون استفاده باعث نشه که چنین خطاهای مهمی رو نبینین.



شاد باشین و شکرگزار
حمیدرضا صادقیان
@hamidreza_Sadeghian

#DBA

#Monitoring

#Database_Backup

گاهی وقتا برای فهمیدن پشت‌صحنه‌ی واقعی 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 🚀