سلام وعرض ادب خدمت دوستان عزيزم
اميدوارم حالتون خوب و خوش باشه و اول هفته خوبي رو آغاز كرده باشين.
يكي از مسائلي كه براي هر DBA و كسي كه مسئول نگهداري ديتابيس ها است ، اين هست كه بدونه روزانه چه مواردي رو بايد كنترل كنه و عملا نياز به يك چك ليست داره. در اين فايلي كه خدمتتون ارسال كردم، مواردي كه يك DBA بايد بدونه و رعايت كنه و كنترل كنه ليست شده است. اين فايل رو سعي ميكنم تكميلترش كنم و نسخه هاي بعدي رو نيز خدمت شما ارسال كنم.
اگر موردي يا سوالي در خصوص مطالب فايل داشتيد با من در ميان بگذاريد.
ارادتمند شما
حميدرضا صادقيان
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #DBA_CheckList #SQLServerCheckList #CheckList #صادقيان
اميدوارم حالتون خوب و خوش باشه و اول هفته خوبي رو آغاز كرده باشين.
يكي از مسائلي كه براي هر DBA و كسي كه مسئول نگهداري ديتابيس ها است ، اين هست كه بدونه روزانه چه مواردي رو بايد كنترل كنه و عملا نياز به يك چك ليست داره. در اين فايلي كه خدمتتون ارسال كردم، مواردي كه يك DBA بايد بدونه و رعايت كنه و كنترل كنه ليست شده است. اين فايل رو سعي ميكنم تكميلترش كنم و نسخه هاي بعدي رو نيز خدمت شما ارسال كنم.
اگر موردي يا سوالي در خصوص مطالب فايل داشتيد با من در ميان بگذاريد.
ارادتمند شما
حميدرضا صادقيان
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #DBA_CheckList #SQLServerCheckList #CheckList #صادقيان
سلام و عرض ادب خدمت دوستان عزیزم
امیدوارم حالتون خوب باشه
یک مقاله ای امروز داشتم مطالعه میکردم از Itzik Ben-Gan در خصوص رفتار SQL Server برای Log buffer Flush . پیشنهاد میکنم حتما این مقاله رو مطالعه کنید و اگر سوالی داشتید در این خصوص ، من در خدمتتون هستم.
شاد و خوش باشید
ارادتمند
حمیدرضا صادقیان
https://sqlperformance.com/2018/11/sql-performance/understanding-log-buffer-flushes
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #Log_Buffer_Flush #LOGBuffer #صادقيان
امیدوارم حالتون خوب باشه
یک مقاله ای امروز داشتم مطالعه میکردم از Itzik Ben-Gan در خصوص رفتار SQL Server برای Log buffer Flush . پیشنهاد میکنم حتما این مقاله رو مطالعه کنید و اگر سوالی داشتید در این خصوص ، من در خدمتتون هستم.
شاد و خوش باشید
ارادتمند
حمیدرضا صادقیان
https://sqlperformance.com/2018/11/sql-performance/understanding-log-buffer-flushes
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #Log_Buffer_Flush #LOGBuffer #صادقيان
SQLPerformance.com
Understanding log buffer flushes - SQLPerformance.com
Itzik Ben-Gan explains log buffer flushes and shows how to use them to help balance performance, transaction size, and durability.
سلام و عرض ادب خدمت دوستان عزیزم
امیدوارم حال همه شما خوب و خوش باشه .
یکی از موارد مهمی که برای اکثر شرکتهای نرم افزاری پیش میاد ، نحوه بروز رسانی دیتابیس های مشتری ، پیدا کردن تفاوت های بین دیتابیس های مشتری ، نحوه توسعه Database ، و این دست موارد هست.
در این پست میخواهم در خصوص Database Project به شما توضیح بدم.
این ابزار ابتدا توسط مجموعه SSDT Tools توسط مایکروسافت در نسخه 2013 ارائه می شد و از نسخه 2015 به بعد به صورت Builtin درون خود Project های VS قرار داره. وقتی شما در VS از منوی File-new رو انتخاب می کنید یک گزینه ای به نام SQL Server projects داره که داخلش Database Project قرار داره.
حالا چه مزایایی داره؟
1- توسعه دیتابیس بسیار سریع
2- امکان Refactor کردن آبجکت های دیتابیس ، تغییر نام ، و... و اعمال در تمام آبجکتهای وابسته بدون اینکه نگران باشید جایی شاید ممکنه تغییرات شما اعمال نشده باشه.
3- امکان نوشتن Unit Test برای SP,View,Function
4- دارای Intellisense بسیار قدرتمند
5- امکان Compare کردن دیتابیس با دیتابیس محیط Production و بدست آوردن اختلافات بین دو دیتابیس
6- قابلیت اضافه شدن بسیار راحت به TFS
7- امکان Publish کردن دیتابیس و طراحی Automation build
8- امکان Publish بر روی محیط تست و اجرای تست ها بر روی محیط Test و در صورت درست بودن آن ، Publish بر روی محیط عملیاتی
9- اضافه کردن دیتابیس با استفاده از Import دیتابیس فعلی
و ایضا تمام قابلیتهایی که محصولات Red gate در اختیار شما قرار میدن به راحتی با Database Project و در یک مجموعه دراختیار خواهید داشت
نحوه کار با آن بسیار راحت هست و شما دیگه از سردرگمی در خصوص توسعه دیتابیس رهایی پیدا خواهید کرد.
سعی میکنم در پست بعدی یک فیلم از نحوه کار با این ابزار رو برای شما عزیزان فراهم کنم.
ارادتمند شما
حمیدرضا صادقیان
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #Database_Project #Manage_Database #Database_Compare #Compare #publish #publish_Database #صادقيان #AutomationDeploy #DevOps
امیدوارم حال همه شما خوب و خوش باشه .
یکی از موارد مهمی که برای اکثر شرکتهای نرم افزاری پیش میاد ، نحوه بروز رسانی دیتابیس های مشتری ، پیدا کردن تفاوت های بین دیتابیس های مشتری ، نحوه توسعه Database ، و این دست موارد هست.
در این پست میخواهم در خصوص Database Project به شما توضیح بدم.
این ابزار ابتدا توسط مجموعه SSDT Tools توسط مایکروسافت در نسخه 2013 ارائه می شد و از نسخه 2015 به بعد به صورت Builtin درون خود Project های VS قرار داره. وقتی شما در VS از منوی File-new رو انتخاب می کنید یک گزینه ای به نام SQL Server projects داره که داخلش Database Project قرار داره.
حالا چه مزایایی داره؟
1- توسعه دیتابیس بسیار سریع
2- امکان Refactor کردن آبجکت های دیتابیس ، تغییر نام ، و... و اعمال در تمام آبجکتهای وابسته بدون اینکه نگران باشید جایی شاید ممکنه تغییرات شما اعمال نشده باشه.
3- امکان نوشتن Unit Test برای SP,View,Function
4- دارای Intellisense بسیار قدرتمند
5- امکان Compare کردن دیتابیس با دیتابیس محیط Production و بدست آوردن اختلافات بین دو دیتابیس
6- قابلیت اضافه شدن بسیار راحت به TFS
7- امکان Publish کردن دیتابیس و طراحی Automation build
8- امکان Publish بر روی محیط تست و اجرای تست ها بر روی محیط Test و در صورت درست بودن آن ، Publish بر روی محیط عملیاتی
9- اضافه کردن دیتابیس با استفاده از Import دیتابیس فعلی
و ایضا تمام قابلیتهایی که محصولات Red gate در اختیار شما قرار میدن به راحتی با Database Project و در یک مجموعه دراختیار خواهید داشت
نحوه کار با آن بسیار راحت هست و شما دیگه از سردرگمی در خصوص توسعه دیتابیس رهایی پیدا خواهید کرد.
سعی میکنم در پست بعدی یک فیلم از نحوه کار با این ابزار رو برای شما عزیزان فراهم کنم.
ارادتمند شما
حمیدرضا صادقیان
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server
#DBA #Database_Project #Manage_Database #Database_Compare #Compare #publish #publish_Database #صادقيان #AutomationDeploy #DevOps
سلام دوستان عزیزم
امیدوارم حالتون عالی عالی باشه
چند روز پیش درگیر بروز رسانی یک سری Package های SSIS بودیم که از نسخه ۲۰۱۲ به نسخه ۲۰۲۲ منتقل کنیم.
موقع Deploy مدام به ایرادات مختلف مخصوصا Dll های مربوط به Package ها برخورد میکردیم.
بعد از کلی بررسی ها ، متوجه شدم که در Package ها Target Server به ۲۰۲۲ تغییر نکرده بود و همین باعث ایجاد کلی خطا شده بود. این خطاها هم اغلب در هنگامم اجرای Job رخ میداد. دلیلش هم واضحه. Package های SSIS وقتی که JOB میشن توسط فایل DTExec اجرا میشن و یکی از مواردی که توسط این فایل چک میشه بحث Target Server هست که باتوجه به اون بیاد DLL های مربوط به اون رو لود کنه و همین قضیه باعث میشد مرتبا جاب های ما Failed بشن. با تغییر این موضوع ، جابها با موفقیت اجرا شدند.
گفتم این مورد روباهاتون به اشتراک بذارم.
شاد باشین و شکرگزار
ارادتمند
حمیدرضا صادقیان
Hello dear friends,
I hope you're all doing exceptionally well. A few days ago, we were involved in updating a series of SSIS packages from version 2012 to version 2022. During the deployment, we consistently encountered various issues, especially related to the DLLs associated with the packages.
After thorough investigations, I realized that the Target Server in the packages had not been changed to 2022. This oversight caused a multitude of errors, most of which occurred during the execution of jobs. The reason is clear: SSIS packages, when executed by the DTExec file during a job, undergo a check related to the Target Server. Based on this, the corresponding DLLs are loaded. This situation repeatedly led to the failure of our jobs.
By addressing this issue and changing the Target Server, the jobs were successfully executed. I thought it would be beneficial to share this experience with you.
Stay joyful and grateful.
Best regards,
Hamidreza Sadeghian
Telegram Channel : @SQL_Server
#SSIS
#DBA
#SQLServer
#Administration
#ETL
#job
امیدوارم حالتون عالی عالی باشه
چند روز پیش درگیر بروز رسانی یک سری Package های SSIS بودیم که از نسخه ۲۰۱۲ به نسخه ۲۰۲۲ منتقل کنیم.
موقع Deploy مدام به ایرادات مختلف مخصوصا Dll های مربوط به Package ها برخورد میکردیم.
بعد از کلی بررسی ها ، متوجه شدم که در Package ها Target Server به ۲۰۲۲ تغییر نکرده بود و همین باعث ایجاد کلی خطا شده بود. این خطاها هم اغلب در هنگامم اجرای Job رخ میداد. دلیلش هم واضحه. Package های SSIS وقتی که JOB میشن توسط فایل DTExec اجرا میشن و یکی از مواردی که توسط این فایل چک میشه بحث Target Server هست که باتوجه به اون بیاد DLL های مربوط به اون رو لود کنه و همین قضیه باعث میشد مرتبا جاب های ما Failed بشن. با تغییر این موضوع ، جابها با موفقیت اجرا شدند.
گفتم این مورد روباهاتون به اشتراک بذارم.
شاد باشین و شکرگزار
ارادتمند
حمیدرضا صادقیان
Hello dear friends,
I hope you're all doing exceptionally well. A few days ago, we were involved in updating a series of SSIS packages from version 2012 to version 2022. During the deployment, we consistently encountered various issues, especially related to the DLLs associated with the packages.
After thorough investigations, I realized that the Target Server in the packages had not been changed to 2022. This oversight caused a multitude of errors, most of which occurred during the execution of jobs. The reason is clear: SSIS packages, when executed by the DTExec file during a job, undergo a check related to the Target Server. Based on this, the corresponding DLLs are loaded. This situation repeatedly led to the failure of our jobs.
By addressing this issue and changing the Target Server, the jobs were successfully executed. I thought it would be beneficial to share this experience with you.
Stay joyful and grateful.
Best regards,
Hamidreza Sadeghian
Telegram Channel : @SQL_Server
#SSIS
#DBA
#SQLServer
#Administration
#ETL
#job
👍43❤8😍2👎1👏1
سلام خدمت دوستان عزیزم
امیدوارم که عالی عالی باشین
میخوام در این پست اشاره ای کنم به اینکه اساسا 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
امیدوارم که عالی عالی باشین
میخوام در این پست اشاره ای کنم به اینکه اساسا 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
👍43❤4🤔1🤣1
چند روز پیش مشغول مانیتورینگ یکی از مراکز بودم ، دیدم که بیش از ۵۰۰ تا Deadlock روی دیتابیس رخ داده ! اون هم تو یک بازه کم. اصلا یک چیز عجیب غریبی بود.
رفتم کدها رو بررسی کردم دیدم Deadlock بین یک Select و Insert روی همون جدول داره رخ میده. Select داشت کل جدول رو Scan می کرد و Insert هم با شرایط خاصی نیاز داشت درج بشه که سبب Deadlock شده بود.
فیلدهای شرط Select رو بررسی کردم دیدم که یک فیلد از نوع nvarchar max هست.
(خداوکیلی Developer های عزیز اگه از این دیتاتایپ مثل نقل و نبات استفاده می کنید،برای حفظ جونتون هم که شده نزدیک یک DBA نشید. از ما گفتن بود 😁 )
مورد داشتم روی فیلد عددی هم Nvarchar max گذاشته شده.
در این فقره نوع Data type و طول فیلدها خساست از اخلاقهای بسیار نیکو پسندیده است.
خلاصه با تیم توسعه صحبت کردیم بچه ها زحمت کشیدن طول فیلد رو اصلاح کردن و من تونستم روی فیلدهای مورد نظر ایندکس بذارم.
بعد از قراردادن ایندکس کلا مشکل Deadlock عزیزمون حل شد و دیگه اون چالش رخ نداد.
البته این نکته رو هم در نظر بگیرید که جدول مذکور کلا ایندکسی نداشت.
من جداولی رو دیدم که خودش به دلیل تعدد ایندکس (بالای ۱۵ تا ایندکس. ماشالله دست و دل بازم بودن عزیزان 😅 ) باعث ایجاد Deadlock میشده.
اینطور نباشد که برید از فردا جداول مورد نظر رو غرق در ایندکس کنید بعد صدتاجای دیگه بترکه خلاصه مارو مورد عنایت قرار بدین. من در این فقره هیچگونه مسئولیتی قبول نمی کنم. 🙃
باشد که دیتابیسی عاری از هرگونه Deadlock داشته باشید.
#Deadlock
#DBA_Tips
رفتم کدها رو بررسی کردم دیدم Deadlock بین یک Select و Insert روی همون جدول داره رخ میده. Select داشت کل جدول رو Scan می کرد و Insert هم با شرایط خاصی نیاز داشت درج بشه که سبب Deadlock شده بود.
فیلدهای شرط Select رو بررسی کردم دیدم که یک فیلد از نوع nvarchar max هست.
(خداوکیلی Developer های عزیز اگه از این دیتاتایپ مثل نقل و نبات استفاده می کنید،برای حفظ جونتون هم که شده نزدیک یک DBA نشید. از ما گفتن بود 😁 )
مورد داشتم روی فیلد عددی هم Nvarchar max گذاشته شده.
در این فقره نوع Data type و طول فیلدها خساست از اخلاقهای بسیار نیکو پسندیده است.
خلاصه با تیم توسعه صحبت کردیم بچه ها زحمت کشیدن طول فیلد رو اصلاح کردن و من تونستم روی فیلدهای مورد نظر ایندکس بذارم.
بعد از قراردادن ایندکس کلا مشکل Deadlock عزیزمون حل شد و دیگه اون چالش رخ نداد.
البته این نکته رو هم در نظر بگیرید که جدول مذکور کلا ایندکسی نداشت.
من جداولی رو دیدم که خودش به دلیل تعدد ایندکس (بالای ۱۵ تا ایندکس. ماشالله دست و دل بازم بودن عزیزان 😅 ) باعث ایجاد Deadlock میشده.
اینطور نباشد که برید از فردا جداول مورد نظر رو غرق در ایندکس کنید بعد صدتاجای دیگه بترکه خلاصه مارو مورد عنایت قرار بدین. من در این فقره هیچگونه مسئولیتی قبول نمی کنم. 🙃
باشد که دیتابیسی عاری از هرگونه Deadlock داشته باشید.
#Deadlock
#DBA_Tips
👍44❤11👏3😁3💯1
شاید شما هم از دوستان DBA زیاد کلمه Statistics رو شنیدین؟ یا مثلا بگن Stat هاشو Update کردم درست شد و جملاتی از این قبیل.
حالا بریم ببینیم این جذاب لعنتی چیه که تمام رفتار Optimizer بر مبنای اون رقم میخوره.
فرض کنید Optimizer واحد مدیریت شرکت شماست.
و Statistics ها هم بخش آمار و تولید دیتای شما هستند که به شما دیتا میدن تا تصمیم گیری کنید.
خوب تا اینجاش که بنظر جذاب میاد.
آماااا. کجا دعواها شروع میشه.
اونجا که شما به عنوان مدیر میاین سرکار ، فرض کنید یک ذره پاداش کارمندان عقب افتاده(البته این اتفاق در یک کشور ثانی در دنیای موازی رخ میده شما مخاطب نیستید 😉 ) واحد آمار با شما لج می کنه و به شما دیتای غلط می ده. مثلا آمار اشتباهی از فروش محصولات میده. آمار اشتباهی از تعداد ثبت درخواست ها و بازدید سایت میده. شما هم شاد و خندان براساس آمارها میاین منابع تخصیص میدین برای توسعه کار(SQL Server میاد منابع RAm, CPU , IO رو پیش بینی میکنه و تخصیص میده برای اجرای کد) بعد با یک ژست مدیرعاملی خفن که مثلا ما خیلی باحالیم میاین دستور میدین به واحدهای مختلف که با این بودجه برید اینکارهارو انجام بدین(Optimizer پلن رو تهیه می کنه و میده به Execution Engine میگه داداش برو اینو اجرا کن) حالا این واحدهای از خدا بیخبر هم میرن بودجه رو میگیرن و سعی می کنن کارو دربیارن. اگه بودجه اضافی باشه که اون وسط یک حالی هم خودشون میکنن( البته SQL Server حلال خوره و میاد میگه داداش از این همه منابع من خداوکیلی اینقدرشو استفاده کردم مابقیش رو پس آوردم. البته جسارت نباشه ها بد برداشت نکنید، از جنبه فان نگاه کنید 😁 ) اگه بودجه کم بیاد که مجبورن با همون بودجه کم ، کارو دربیارن ولی زمان بیشتری رو صرف کنن( دقیقا همین اتفاق این سمت هم میافته)
حالا چی میشه؟
آفرین اینجوری میشه که کدها ومنابع شما به فنا میره.
حالا اگه واحد آمار پاداششو گرفته باشه و شنگول باشه و آمار درستی بده. چه اتفاقی میافته؟ دقیقااا. بودجه بندی مناسب ، تخصیص منابع درست و درنهایت تخمین دقیق زمان اجرا بدون هیچگونه هدررفت منابع.
سعی کردم این مطلب رو با شوخی تلفیق کنم که درکش ساده باشه.
در پستهای بعدی تلاش می کنم بیشتر این مبحث رو باز کنم و بیشتر شمارو با رفتار درونی SQL Server آشناکنم.
پرسرعت و شاد باشین 😊
Telegram discussion Group :https://xn--r1a.website/+-JqFG0ceU7JlNDA0
#Statistics
#DBA
#SQLServer_Internals
@Hamidreza_Sadeghian
حالا بریم ببینیم این جذاب لعنتی چیه که تمام رفتار Optimizer بر مبنای اون رقم میخوره.
فرض کنید Optimizer واحد مدیریت شرکت شماست.
و Statistics ها هم بخش آمار و تولید دیتای شما هستند که به شما دیتا میدن تا تصمیم گیری کنید.
خوب تا اینجاش که بنظر جذاب میاد.
آماااا. کجا دعواها شروع میشه.
اونجا که شما به عنوان مدیر میاین سرکار ، فرض کنید یک ذره پاداش کارمندان عقب افتاده(البته این اتفاق در یک کشور ثانی در دنیای موازی رخ میده شما مخاطب نیستید 😉 ) واحد آمار با شما لج می کنه و به شما دیتای غلط می ده. مثلا آمار اشتباهی از فروش محصولات میده. آمار اشتباهی از تعداد ثبت درخواست ها و بازدید سایت میده. شما هم شاد و خندان براساس آمارها میاین منابع تخصیص میدین برای توسعه کار(SQL Server میاد منابع RAm, CPU , IO رو پیش بینی میکنه و تخصیص میده برای اجرای کد) بعد با یک ژست مدیرعاملی خفن که مثلا ما خیلی باحالیم میاین دستور میدین به واحدهای مختلف که با این بودجه برید اینکارهارو انجام بدین(Optimizer پلن رو تهیه می کنه و میده به Execution Engine میگه داداش برو اینو اجرا کن) حالا این واحدهای از خدا بیخبر هم میرن بودجه رو میگیرن و سعی می کنن کارو دربیارن. اگه بودجه اضافی باشه که اون وسط یک حالی هم خودشون میکنن( البته SQL Server حلال خوره و میاد میگه داداش از این همه منابع من خداوکیلی اینقدرشو استفاده کردم مابقیش رو پس آوردم. البته جسارت نباشه ها بد برداشت نکنید، از جنبه فان نگاه کنید 😁 ) اگه بودجه کم بیاد که مجبورن با همون بودجه کم ، کارو دربیارن ولی زمان بیشتری رو صرف کنن( دقیقا همین اتفاق این سمت هم میافته)
حالا چی میشه؟
آفرین اینجوری میشه که کدها ومنابع شما به فنا میره.
حالا اگه واحد آمار پاداششو گرفته باشه و شنگول باشه و آمار درستی بده. چه اتفاقی میافته؟ دقیقااا. بودجه بندی مناسب ، تخصیص منابع درست و درنهایت تخمین دقیق زمان اجرا بدون هیچگونه هدررفت منابع.
سعی کردم این مطلب رو با شوخی تلفیق کنم که درکش ساده باشه.
در پستهای بعدی تلاش می کنم بیشتر این مبحث رو باز کنم و بیشتر شمارو با رفتار درونی SQL Server آشناکنم.
پرسرعت و شاد باشین 😊
Telegram discussion Group :https://xn--r1a.website/+-JqFG0ceU7JlNDA0
#Statistics
#DBA
#SQLServer_Internals
@Hamidreza_Sadeghian
Telegram
SQL Server
ُSQL Server Discussion Group (Farsi)
Juniors of SQL Server Group : PM to @Hamidreza_Sadeghian
Juniors of SQL Server Group : PM to @Hamidreza_Sadeghian
👍29❤4🤔2🤨1
میخوام در حوزه Tuning شمارو با یک مفهومی به نام Good Enough (بسه دیگه من خوبم 😅 ) آشنا کنم.
فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم.
دمتون هم گرم.
حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 )
هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم.
میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم.
محمد : تو روی این کده کار کردی؟
حمیدرضا : خوب اره.
محمد : چقدر وقت گذاشتی؟
حمیدرضا :راستش دو روز اشک منو دراورد تا اصلاحش کردم.
محمد : آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره.
😤 😤 😡
اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه.
عزیزان دل،
اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه.
دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید.
یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه.
اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ، میزان لودی که ایجاد می کنه و اهمیت دار بودن اون.
کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 )
این مهم رو در نظر بگیرید خدایی.
چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست.
الزاما تغییر در خیلی از ساختار مناسب نیست.
خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه.
خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 )
@Hamidreza_Sadeghian
#GoodEnough
#PerformanceTuning
#DBA
فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم.
دمتون هم گرم.
حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 )
هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم.
میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم.
محمد : تو روی این کده کار کردی؟
حمیدرضا : خوب اره.
محمد : چقدر وقت گذاشتی؟
حمیدرضا :راستش دو روز اشک منو دراورد تا اصلاحش کردم.
محمد : آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره.
😤 😤 😡
اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه.
عزیزان دل،
اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه.
دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید.
یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه.
اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ، میزان لودی که ایجاد می کنه و اهمیت دار بودن اون.
کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 )
این مهم رو در نظر بگیرید خدایی.
چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست.
الزاما تغییر در خیلی از ساختار مناسب نیست.
خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه.
خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 )
@Hamidreza_Sadeghian
#GoodEnough
#PerformanceTuning
#DBA
👍27👌5❤3😁2👏1
سلام
✍️ امروز یکی از دوستانم با مشکلی در SQL Server Always On Availability Group روبهرو شد.
بین دو سرور، کلاستر راهاندازی شده بود و حتی در سرویس SQL Server هم تیک مربوط به کلاستر خورده بود، اما هنگام ایجاد Availability Group خطای عجیبی نمایش داده میشد.
🔎 مراحل بررسی که انجام دادم:
1️⃣ اول از همه مطمئن شدم که سرویس کلاستر در حال اجراست.
2️⃣ بعد وضعیت نودها رو بررسی کردم تا هر دو در حالت Up باشند.
3️⃣ وجود File Share Witness رو هم چک کردم (اگر نباشه این خطا رو ایجاد نمیکنه، ولی بودنش همیشه بهتره).
4️⃣ در نهایت داخل SQL Server این کوئری رو اجرا کردم:
SELECT * FROM sys.dm_hadr_cluster
اینجا مشخص شد که برای سرویس، هیچ کلاستری تعریف نشده!
✅ راهحل ساده بود:
یکبار قابلیت Always On Availability Group رو از داخل SQL Server Configuration Manager غیرفعال و دوباره فعال کردم. مشکل برطرف شد.
💡 گفتم این تجربه رو اینجا هم به اشتراک بذارم، شاید به کارتون بیاد.
#Alwayson #Availability_Group #HA #DBA
✍️ امروز یکی از دوستانم با مشکلی در SQL Server Always On Availability Group روبهرو شد.
بین دو سرور، کلاستر راهاندازی شده بود و حتی در سرویس SQL Server هم تیک مربوط به کلاستر خورده بود، اما هنگام ایجاد Availability Group خطای عجیبی نمایش داده میشد.
🔎 مراحل بررسی که انجام دادم:
1️⃣ اول از همه مطمئن شدم که سرویس کلاستر در حال اجراست.
2️⃣ بعد وضعیت نودها رو بررسی کردم تا هر دو در حالت Up باشند.
3️⃣ وجود File Share Witness رو هم چک کردم (اگر نباشه این خطا رو ایجاد نمیکنه، ولی بودنش همیشه بهتره).
4️⃣ در نهایت داخل SQL Server این کوئری رو اجرا کردم:
SELECT * FROM sys.dm_hadr_cluster
اینجا مشخص شد که برای سرویس، هیچ کلاستری تعریف نشده!
✅ راهحل ساده بود:
یکبار قابلیت Always On Availability Group رو از داخل SQL Server Configuration Manager غیرفعال و دوباره فعال کردم. مشکل برطرف شد.
💡 گفتم این تجربه رو اینجا هم به اشتراک بذارم، شاید به کارتون بیاد.
#Alwayson #Availability_Group #HA #DBA
❤27👍12👌2
سلام
💔 داستان Shrink در SQL Server 😅
ببینید رفقا، این عملیات Shrink کردن فایلهای Data عین روابط عاشقانهی پر فراز و نشیبِیه! 😎
یه روز SQL Server میگه:
"دیگه بهت نیاز ندارم 😤"
و فایل Data رو کوچیک میکنه (کات میکنن خلاصه 💔)
بعد صبح روز بعد دوباره میاد:
"ببین من یه چیزی گفتم... 😅 بیا دوباره با هم باشیم!"
و دوباره فضا میگیره 😬
شب دوباره job shrink اجرا میشه 😑
صبح دوباره SQL Server میاد میگه «برگرد پیشم!»
و این چرخه تا ابد ادامه داره... 😭
📣 بابا ولش کنین دیگه! Shrink نکنید، بذارید رابطهش آروم بگیره 😂
#SQLServer #DBA #ShrinkDrama #DatabaseHumor #ITLife #DBALife
💔 داستان Shrink در SQL Server 😅
ببینید رفقا، این عملیات Shrink کردن فایلهای Data عین روابط عاشقانهی پر فراز و نشیبِیه! 😎
یه روز SQL Server میگه:
"دیگه بهت نیاز ندارم 😤"
و فایل Data رو کوچیک میکنه (کات میکنن خلاصه 💔)
بعد صبح روز بعد دوباره میاد:
"ببین من یه چیزی گفتم... 😅 بیا دوباره با هم باشیم!"
و دوباره فضا میگیره 😬
شب دوباره job shrink اجرا میشه 😑
صبح دوباره SQL Server میاد میگه «برگرد پیشم!»
و این چرخه تا ابد ادامه داره... 😭
📣 بابا ولش کنین دیگه! Shrink نکنید، بذارید رابطهش آروم بگیره 😂
#SQLServer #DBA #ShrinkDrama #DatabaseHumor #ITLife #DBALife
😁13🤣9❤8👍6
گاهی وقتا برای فهمیدن پشتصحنهی واقعی 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
یکی از چیزهایی که همیشه کمکم کرده بفهمم دقیقاً اون زیر چه خبره، همین دستور معروفه:
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
👏15❤8👌2👍1
سلام دوستان
🔍 یک چالش جالب در SQL Server که میتونست یک مجموعه رو زمینگیر کنه!
چند وقت پیش در یکی از مجموعهها با یک مشکل عجیب مواجه بودن 👀
سیستم از یک تعداد کاربر مشخص به بعد خطا میداد و اجازه نمیداد اتصال جدیدی به دیتابیس برقرار بشه.
🔎 بعد از دیدن خطا، اولین چیزی که به ذهنم رسید این بود:
احتمالاً تنظیمات user connections دستکاری شده.
مشکل اینجا بود که حتی اتصال عادی هم به دیتابیس برقرار نمیشد!
با کلی داستان و از طریق sqlcmd تونستم مستقیم به Engine وصل بشم 💪
📌 با بررسی تنظیمات:
'sp_configure 'user connections
مشخص شد مقدار روی 100 ست شده 😐
🔧 راهحل ساده ولی حیاتی بود:
مقدار user connections رو روی 0 گذاشتم
عدد 0 یعنی:
👉 SQL Server خودش مدیریت میکنه (تا حدود 32767 اتصال همزمان)
بعد از اعمال تغییر، مجبور شدیم یک بار سرویس SQL Server رو ریست کنیم 🔄
و… مشکل بهطور کامل حل شد ✅
✨ نکته جالبتر؟
کاربران میگفتن حتی سرعت سیستم هم بهتر شده!
احتمالاً سیستم مدام سعی میکرد اتصال بگیره، خطا میخورد و منتظر میموند تا دوباره تلاش کنه ⏳
🧠 جمعبندی مهم:
هر عددی که در SQL Server میبینید، معمولاً پشتش یک منطق و سناریو وجود داره.
این تنظیمات رو:
❌ با حدس
❌ با سلیقه
❌ یا «ببینیم با کدوم عدد حال میکنیم»
نباید تغییر داد!
⚠️ یک عدد اشتباه، خیلی راحت میتونه کل یک شرکت رو دچار اختلال کنه.
کمی دقت بیشتر در این جزئیات، هزینههای خیلی بزرگی رو کم میکنه.
#SQLServer #DBA #Performance #Troubleshooting #Database #Production #Experience
🔍 یک چالش جالب در SQL Server که میتونست یک مجموعه رو زمینگیر کنه!
چند وقت پیش در یکی از مجموعهها با یک مشکل عجیب مواجه بودن 👀
سیستم از یک تعداد کاربر مشخص به بعد خطا میداد و اجازه نمیداد اتصال جدیدی به دیتابیس برقرار بشه.
🔎 بعد از دیدن خطا، اولین چیزی که به ذهنم رسید این بود:
احتمالاً تنظیمات user connections دستکاری شده.
مشکل اینجا بود که حتی اتصال عادی هم به دیتابیس برقرار نمیشد!
با کلی داستان و از طریق sqlcmd تونستم مستقیم به Engine وصل بشم 💪
📌 با بررسی تنظیمات:
'sp_configure 'user connections
مشخص شد مقدار روی 100 ست شده 😐
🔧 راهحل ساده ولی حیاتی بود:
مقدار user connections رو روی 0 گذاشتم
عدد 0 یعنی:
👉 SQL Server خودش مدیریت میکنه (تا حدود 32767 اتصال همزمان)
بعد از اعمال تغییر، مجبور شدیم یک بار سرویس SQL Server رو ریست کنیم 🔄
و… مشکل بهطور کامل حل شد ✅
✨ نکته جالبتر؟
کاربران میگفتن حتی سرعت سیستم هم بهتر شده!
احتمالاً سیستم مدام سعی میکرد اتصال بگیره، خطا میخورد و منتظر میموند تا دوباره تلاش کنه ⏳
🧠 جمعبندی مهم:
هر عددی که در SQL Server میبینید، معمولاً پشتش یک منطق و سناریو وجود داره.
این تنظیمات رو:
❌ با حدس
❌ با سلیقه
❌ یا «ببینیم با کدوم عدد حال میکنیم»
نباید تغییر داد!
⚠️ یک عدد اشتباه، خیلی راحت میتونه کل یک شرکت رو دچار اختلال کنه.
کمی دقت بیشتر در این جزئیات، هزینههای خیلی بزرگی رو کم میکنه.
#SQLServer #DBA #Performance #Troubleshooting #Database #Production #Experience
❤22👍7👌2
سلام دوستان
📉 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#طنز_فنی 😄
📉 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#طنز_فنی 😄
👍16👌6🙏2🤨2❤1
تا حالا Running Total تو SQL Server نوشتی و با خیال راحت رد شدی؟ 😌
📌 معمولاً برای Running Total یه چیزی شبیه این مینویسیم:
همهچیز هم ظاهراً درسته…
اما دقیقاً همینجا مشکل شروع میشه 😐
🔍 مشکل کجاست؟
وقتی داخل OVER فقط ORDER BY مینویسیم و چیز دیگهای مشخص نمیکنیم،
خود SQL Server بهصورت پیشفرض از این استفاده میکنه 👇
و این یعنی چی؟ 🤔
یعنی اگر تو ستون ORDER BY (مثلاً OrderDate) مقدار تکراری وجود داشته باشه:
اونقوت SQL Server تمام ردیفهایی که تاریخ یکسان دارن رو «یک ردیف منطقی» در نظر میگیره
و Running Total برای همه اونها با هم محاسبه میشه
نتیجه؟
➕ جمع یههو میپره
😵💫 چیزی که حس میکنیم غلطه، ولی در واقع «غیرمنتظره» است
❗️ نکته مهم:
1- SQL Server اشتباه نکرده
2- ما ناخواسته رفتار RANGE رو فعال کردیم
🚀 راهحل درست و حرفهای:
اگه Running Total واقعی میخوای، یعنی ردیفبهردیف و بدون پرش،
باید صریح بنویسی:
یا حتی کوتاهتر:
✔️ محاسبه دقیق
✔️ بدون رفتار عجیب
✔️ بازدهی خیلی بهتر (In-Memory بهجای TempDB)
🧠 جمعبندی
همیشه Defaultها دوست ما نیستن
استفاده از RANGE فقط وقتی خوبه که عمداً بخوای Tieها یکی حساب بشن
برای ۹۹٪ سناریوهای Running Total → ROWS رو همیشه صریح بنویس
یه خط کداضافه ، ولی کلی تفاوت تو نتیجه و Performance 🔥
#SQLServer #TSQL #DBA #Performance #WindowFunctions #RunningTotal #DatabaseTips
📌 معمولاً برای 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
👍14❤8🔥2
سلام دوستان
🚨 تا حالا شده بری 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 🧾
💎 این کوئری دقیقاً کجاها میدرخشه؟
✨ وقتی روی 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 🚀
🚨 تا حالا شده بری 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 🚀
❤19👍1