چند روز پیش مشغول مانیتورینگ یکی از مراکز بودم ،‌ دیدم که بیش از ۵۰۰ تا Deadlock روی دیتابیس رخ داده ! اون هم تو یک بازه کم. اصلا یک چیز عجیب غریبی بود.
رفتم کدها رو بررسی کردم دیدم Deadlock بین یک Select و Insert روی همون جدول داره رخ میده. Select داشت کل جدول رو Scan می کرد و Insert هم با شرایط خاصی نیاز داشت درج بشه که سبب Deadlock شده بود.
فیلدهای شرط Select رو بررسی کردم دیدم که یک فیلد از نوع nvarchar max هست.

(خداوکیلی Developer های عزیز اگه از این دیتاتایپ مثل نقل و نبات استفاده می کنید،‌برای حفظ جونتون هم که شده نزدیک یک DBA نشید. از ما گفتن بود 😁 )

مورد داشتم روی فیلد عددی هم Nvarchar max گذاشته شده.
در این فقره نوع Data type و طول فیلدها خساست از اخلاقهای بسیار نیکو پسندیده است.
خلاصه با تیم توسعه صحبت کردیم بچه ها زحمت کشیدن طول فیلد رو اصلاح کردن و من تونستم روی فیلدهای مورد نظر ایندکس بذارم.
بعد از قراردادن ایندکس کلا مشکل Deadlock عزیزمون حل شد و دیگه اون چالش رخ نداد.
البته این نکته رو هم در نظر بگیرید که جدول مذکور کلا ایندکسی نداشت.
من جداولی رو دیدم که خودش به دلیل تعدد ایندکس (بالای ۱۵ تا ایندکس. ماشالله دست و دل بازم بودن عزیزان 😅 ) باعث ایجاد Deadlock میشده.
اینطور نباشد که برید از فردا جداول مورد نظر رو غرق در ایندکس کنید بعد صدتاجای دیگه بترکه خلاصه مارو مورد عنایت قرار بدین. من در این فقره هیچگونه مسئولیتی قبول نمی کنم. 🙃
باشد که دیتابیسی عاری از هرگونه Deadlock داشته باشید.


#Deadlock
#DBA_Tips

شاید شما هم از دوستان DBA زیاد کلمه Statistics رو شنیدین؟ یا مثلا بگن Stat هاشو Update کردم درست شد و جملاتی از این قبیل.
حالا بریم ببینیم این جذاب لعنتی چیه که تمام رفتار Optimizer بر مبنای اون رقم میخوره.
فرض کنید Optimizer واحد مدیریت شرکت شماست.
و Statistics ها هم بخش آمار و تولید دیتای شما هستند که به شما دیتا میدن تا تصمیم گیری کنید.
خوب تا اینجاش که بنظر جذاب میاد.
آماااا. کجا دعواها شروع میشه.
اونجا که شما به عنوان مدیر میاین سرکار ، فرض کنید یک ذره پاداش کارمندان عقب افتاده(البته این اتفاق در یک کشور ثانی در دنیای موازی رخ میده شما مخاطب نیستید 😉 ) واحد آمار با شما لج می کنه و به شما دیتای غلط می ده. مثلا آمار اشتباهی از فروش محصولات میده. آمار اشتباهی از تعداد ثبت درخواست ها و بازدید سایت میده. شما هم شاد و خندان براساس آمارها میاین منابع تخصیص میدین برای توسعه کار(SQL Server میاد منابع RAm, CPU , IO رو پیش بینی میکنه و تخصیص میده برای اجرای کد) بعد با یک ژست مدیرعاملی خفن که مثلا ما خیلی باحالیم میاین دستور میدین به واحدهای مختلف که با این بودجه برید اینکارهارو انجام بدین(Optimizer پلن رو تهیه می کنه و میده به Execution Engine میگه داداش برو اینو اجرا کن) حالا این واحدهای از خدا بیخبر هم میرن بودجه رو میگیرن و سعی می کنن کارو دربیارن. اگه بودجه اضافی باشه که اون وسط یک حالی هم خودشون میکنن( البته SQL Server حلال خوره و میاد میگه داداش از این همه منابع من خداوکیلی اینقدرشو استفاده کردم مابقیش رو پس آوردم. البته جسارت نباشه ها بد برداشت نکنید، از جنبه فان نگاه کنید 😁 ) اگه بودجه کم بیاد که مجبورن با همون بودجه کم ، کارو دربیارن ولی زمان بیشتری رو صرف کنن( دقیقا همین اتفاق این سمت هم میافته)
حالا چی میشه؟
آفرین اینجوری میشه که کدها ومنابع شما به فنا میره.
حالا اگه واحد آمار پاداششو گرفته باشه و شنگول باشه و آمار درستی بده. چه اتفاقی میافته؟ دقیقااا. بودجه بندی مناسب ، تخصیص منابع درست و درنهایت تخمین دقیق زمان اجرا بدون هیچگونه هدررفت منابع.
سعی کردم این مطلب رو با شوخی تلفیق کنم که درکش ساده باشه.
در پستهای بعدی تلاش می کنم بیشتر این مبحث رو باز کنم و بیشتر شمارو با رفتار درونی SQL Server آشناکنم.

پرسرعت و شاد باشین 😊



Telegram discussion Group :https://t.me/+-JqFG0ceU7JlNDA0

#Statistics
#DBA
#SQLServer_Internals

@Hamidreza_Sadeghian

خوب بریم برای یک چالش ذهنی جذاب دیگه.
در روایات آمده :
(( ای کسانی که ایمان آورده اید( منظور کسانی هست که به SQL Server ایمان آوردند) مبادا در نوع کدنویسی به صورت Row Based فکر کنید ، که همانا شما از کافران هستید)) 😉

حالا بریم برای روایت فوق .
بذارید با یک داستان جذاب شروع کنم. در یکی از پروژه هایی که کند بودیم و داشتیم در خصوص سناریوها صحبت می کردیم ، اینجوری پروژه شرح داده شد که ما یک سری محتویات XML در یک جدول داریم و باید اونها رو ردیف به ردیف خونده و یکسری عملیات روش انجام بدیم و درج کنیم. خوب به این عبارت ردیف به ردیف 🤬 🤬
دقت کنید.
بهش گفتم گل من ،‌چرا ردیف به ردیف اخه؟ تو که برای هر ردیف داری یک کاری انجام میدی گفت بله.
گفتم بعد در یک سری جدول هم درج می کنی گفت بله.
گفتم خوب مبارکه. همون اول بسم الله به جای اینکه یک ردیف رو سلکت کنی و بریزی داخل یک Temp ، بیا مثلا ۱۰۰۰ رکورد رو انتخاب کن بریز داخل Temp.
به جای اینکه اون عملیات رو برای یک ردیف انجام بدی بیا مثلا برای ۱۰۰۰ تا انجام بده چی میشه؟ گفت اخه من میخوام این عملیات روی تک تک رکوردها انجام بشه.
گفتم ببین دیگه اومدی و نسازیا. آقا به توچه SQL Server چطوری میاد اون کارو برای ۱۰۰۰ تا انجام میده.
تو بهش بگو برادر من عزیز من ، من ۱۰۰۰ تا ردیف XML دارم و قراره این اتفاقات روش بیافته. حالا دیگه این عزیزدل چطوری میره و برای تک تک اون ردیفها اینکارو انجام میده به من و توچه ربطی داره؟ برو به زندگیت برس اینقدر دخالت نکن. ول کن اخه. 😁
و همین امر سبب میشه یک فرآیندی که ساعتها زمان میبره به کمتر از چند دقیقه کاهش پیدا کنه. مورد داشتیم چنین عملیاتی ۷۲ ساعت برای پردازش ۳۰۰ هزار رکورد زمان میگرفت و با چنین تغییر تفکری زمانش به ۲ دقیقه کاهش پیدا کرد.

حالا بازم برید تفکر Set Based رو از داخل کدهاتون حذف کنید. بازهم هی بیاید بگید باید ردیف به ردیف 🤬 🤬 اینکارو انجام بدیم. باز هم برید داخل کدهاتون دوجین Cursor , While بذارید.

ایمان بیاورید و دست از اعتقادات خرافه بردارید.

اگر خواستید ما هم میتوانیم در ایمان آوردن شما بهتون کمک کنیم. 😅

اینم راه ارتباطی دعانویسمون :😂
@Hamidreza_Sadeghian


#set_Based
#Row_Based
#TSQL

میخوام در حوزه Tuning شمارو با یک مفهومی به نام Good Enough (بسه دیگه من خوبم 😅 ) آشنا کنم.
فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم.
دمتون هم گرم.
حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 )
هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم.
میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم.
محمد :‌ تو روی این کده کار کردی؟
حمیدرضا : خوب اره.
محمد : چقدر وقت گذاشتی؟
حمیدرضا :‌راستش دو روز اشک منو دراورد تا اصلاحش کردم.
محمد :‌ آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره.
😤 😤 😡
اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه.

عزیزان دل،

اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه.
دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید.
یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه.
اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ،‌ میزان لودی که ایجاد می کنه و اهمیت دار بودن اون.
کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 )
این مهم رو در نظر بگیرید خدایی.
چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست.
الزاما تغییر در خیلی از ساختار مناسب نیست.
خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه.

خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 )

@Hamidreza_Sadeghian

#GoodEnough
#PerformanceTuning
#DBA

سلام خدمت دوستان عزیز.
امیدارم حالتون عالی عالی عالی باشه
من با همکاری سایت مکتب خونه دوره آموزشی T-SQL Querying رو طراحی کردیم.
این دوره از پایه بوده و هیچ پیش نیازی رو نمیخواد.
مباحث زیادی در این دوره مطرح شده و با تمرین های مختلف و منتورینگ سعی بر این شده که افرادی که د راین دوره هستند به این مباحث مسلط بشن.
همچنین هزینه این دوره نسبت به مابقی دوره ها بسیار کمتر بوده که همه افراد بتونن ازش استفاده کنند.
از لینک زیر میتونید سرفصلهای آموزشی رو ببینید. و در صورت تمایل نسبت به ثبت نام د راین دوره اقدام کنید.

با کد زیر ۵۰ درصد تخفیف دریافت خواهید کرد:

نکته ای که هست اینه که کد تخفیف فقط برای ۲۰ نفر در نظر گرفته شده است.

کد تخفیف :‌COUPON-eb99d
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&affiliate_code=y7p0k0

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

تا حالا شده از خودتون بپرسید:
"چقدر می‌تونیم با یه دیتابیس بهینه و مدیریت‌شده، به رشد کسب‌وکارمون سرعت بدیم؟" 🤔

من اینجا هستم تا بهتون بگم که نه تنها می‌شه، بلکه خیلی راحت‌تر از چیزی که فکر می‌کنید! 🎯
چند وقتی هست که تصمیم گرفتم به جای فعالیت در قالب شخصیت حقیقی ، خدماتم رو تو قالب یک شرکت رسمی ارائه بدم و حالا یه فرصت ویژه برای شرکت‌های نرم‌افزاری دارم:

✨ رایگان دیتابیس شما رو Tune می‌کنم!
✨ مسئولیت نگهداری دیتابیس مشتریان شما رو به عهده می‌گیرم!
✨ یه همکاری برد-برد که هم خیال شما راحت باشه، هم درآمد بیشتری کسب کنید!

اگر براتون جذاب شد یا دوست دارید بیشتر در موردش بدونید، خوشحال می‌شم با هم صحبت کنیم. بیاید ببینیم چطور می‌تونیم یه تیم قوی برای دیتابیس بسازیم و کسب‌وکار شما رو به سطح بالاتری ببریم. 💪😊

منتظر پیام‌هاتون هستم! 📩

شاد باشین و شکرگزار

@Hamidreza_Sadeghian

امروز یک Disaster پدرمادر داری خوردیم که نگو. اصلا جیگرمون حال اومد 😂 😂 (شما بخونید ......)
حالا از کل داستان بگذرم یک خطای مسخره خوردم که تا به حال ندیده بودم. مجبور بودم وضعیت Node هارو تغییر بدم هرکاری میکردم بهم خطا میداد فایل Sqlconf.dll رو پیدا نمیکنم. خلاصه ماهم دست به کمر شدیم که بزنیم کسی که دست به فایلهای SQL Server زده رو شتک کنیم 🙃
رفتم روی نود دوم دیدم در مسیر
program files\microsoft sql server\ 160\sql2022\ setup boostrap
پوشه های زیر مجموعه اش نیست.
در یک حرکت انتحاری از سرور دوم این فایلها رو کپی کردم چون نسخ هر دو سرور یکی بود،‌ و این حرکت ژانگولری باعث شد مشکل حل بشه و دوست خوبمون عین آدم به درخواستهای ما پاسخ بده.
تازه ما مثلا DBA هستیم اوضاعمون اینه. 😂 قشنگ شیرین دو ساعت Downtime داشتیم. وای به حال مجموعه ای که DBA هم نداره.
فکر کنم شب به شب برای سرورهاتون اسپند دود می کنید که چشم نخورن.
خدایی هردعایی گرفتین به ماهم بدین تک خور نباشین . 😂
ولی اگر دعا نگرفتین ما میتونیم کنارتون باشیم

خوب در ادامه Disaster قبلی که گفتم ،‌ یکی از چالش ها سر یک کدی بود که نامرد قرار نبود با تعداد بالا در زمان خیلی کم اجرا بشه. اصلا کده مرض داشت انگار تصمیم گرفته بود مارو صاف کنه 😂 . ماهم در حال بررسی زیرساخت و مسائل دیگه بودیم از قضا من متوجه شدم که این نامرد بی ..... بی ..... شروع کرده بود CPU رو کامل درگیر کرده بود به طوریکه حتی HA هم Failed میشد و کلا حتی به سرور هم ریموت نمیتونستیم بزنیم.
کلا کارش با یک Index حل شد 😅
اصلا یک چیز عجیب غریبی بودااا.
اینجاست که Tuning میگن باید ببینید دنبال حل یک کدی هستید که چند بار یا یک بار داره دریک بازه طولانی اجرا میشه یا کدی که در یک بازه مثلا ۲ ساعته ۱۰۰ هزارمرتبه داره اجرا میشه مسلمه دومی شمارو حسابی به چالش میکشه و اشکتون رو درمیاره.
بحث Performance Tuning باخوندن یک مقاله و دوتا مقاله حل نمیشه. شانسی هم نیست که کیلویی ایندکس بذارید.
باید بررسی کنید
مانیتورینگ داشته باشید
و از همه مهمتر در لحظه مناسب اقدام مناسب انجام بدین.

ولی اسپند دود کردن هم شاید برای شما جواب بده 😂

خوب دوستان عزیز یک Disaster دارم براتون داغ داغ، همین الان از تنور درومده 😅

داستان از این قراره که Log backup های چند سری Failed شده بوده و همچنین فایل Log هم با سرعت عجیب غریبی رشد کرده بود به حدی که باعث شده بود کل دیسک پر بشه و همین امر سبب شده بود دیتابیس نیز از HA خارج بشه و اونجاهم Not sync بود. خوب در اولین تلاش سعی کردیم فضای دیسک رو خالی کنیم شاید اون Log هایی که وضعیتشون مشخص نبود درست بشه و شروع کنه ادامه مسیر رو رفتن که خوب اتفاقی نیافتاد.

در قدم بعدی دیتابیس مذکور از HA خارج شد و ازش یک Log Backup گرفتیم و لاگ رو Shrink کردیم که اون فضای عجیب غریب رو آزاد کنه و مجدد به HA اضافه اش کردیم.

خداروشکر اتفاق عجیب غریبی نبود و خیلی سریع حل شد.

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

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

پس تا دیر نشده راهکارهای مراقبت از دیتابیس رو برای خودتون داشته باشین.



سوالی هم در این زمینه داشتین منو تیمم در کنارتون هستیم.

شاد باشین و بدور از هرگونه Disaster



#Disaster_Recovery

#HA

#LogBackup

دوستان عزیزم سلام
امیدوارم حالتون عالی عالی باشه
بانک مرکزی نیازمند یک نیروی متوسط DBA هست
ظاهرا پرداختیشون بین ۴۰-۴۵ هست. دفترشون سمت میرداماده ودورکاری هم ندارن.
اگه تمایل داشتید رزومه هاتون رو برای ایشون در لینکدین ارسال کنید.

https://www.linkedin.com/in/shahriar-nourhejabi-263521102/

سلام خدمت دوستان عزیزم .
امیدوارم عالی عالی باشین
در این ویدئو در خصوص دستور Group by with cube توضیح میدم.

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

میخوام از تجربه جابجاکردن ۴ ترابایت دیتا بین دوتا دیتابیس صحبت کنم.
این حجم از دیتا باید توسط Insert به دیتابیس دوم منتقل میشد به خاطر اینکه همه دیتا نبود و دیتابیس دوم هم خالی نبود. یعنی یک فرآیند آرشیو کردن اطلاعات بود.
سناریوی اول : منتقل کردن داده ها با دستور Insert select که بسیار پرهزینه بود و در یک بازه یک روزه نهایتا یک میلیون رکورد جابجا شد درصورتی که بیش از ۱۰۰ میلیون رکورد داشتیم!
سناریوی دوم : استفاده از DBATools و منتقل کردن داده ها بواسطه Bulk insert .
سرعت درج داده ها حدودا ۱۰۰۰ رکورد در ثانیه بود که با حذف ایندکس های جدول اصلی این سرعت درج تقریبا ۳ برابر شد.
صد میلیون رکورد از یک جدول ( که همش هم فایل بود در قالب فیلدهای NVarchar) به مدت ۱۲ ساعت جابجا شد که حدودا ۱۰۰ گیگابایت بود .
۵ میلیون رکورد که حدودا ۱ ترابایت بود بود حدود ۲۴ ساعت زمان برد منتقل بشه.
۴ میلیون رکورد هم که حدودا ۳ ترابایت بود توی ۳۰ ساعت منتقل شد.
تمامی این جداول هم شامل فیلدهای nvarchar و فایل هست.
نکاتی که رعایت کردم :
قراردادن Recovery Model دیتابیس روی Bulk Logged.
اضافه کردن فضای مناسب به فایل دیتا برای اینکه از رشد فایل هنگام درج
جلوگیری کنم.
حذف ایندکس ها (در یک جدول حذف PK که باعث شد ۸ رکورد درثانیه به ۳۲ رکورد در ثانیه برسه)

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

سناریوی سومی هم بود که استفاده از SSIS بود که بهش دسترسی نداشتیم.
اگه با سناریوی اول پیش میرفتیم پیش بینی این بود که تا بعد از سال باید دیتا منتقل می شد . 😅

عالی باشین
#ETL
@Hamidreza_Sadeghian

قبل از اینکه مایکروسافت بیادTDE رو اضافه کنه ،‌ یکی از اساسی ترین چالش های ما این بود که در لایه دیتابیس کلی امنیت رو بهش میرسیدیم ، بعد یکی از راه می رسید سرویس رو استاپ میکرد فایلهای دیتابیس رو جابجا میکرد و بدون هیچ مشکلی به همه چیز دسترسی داشت !! 😐 همیشه جلوی Oracle کارها عرق شرم برپیشونی ما نقش می بست. 😁
بعد مایکروسافت زحمت کشید اومد مارو از این خجالت زدگی رها کرد و Encryption‌رو اضافه کرد. باعث شد که با فعال سازی Encryption بر روی دیتابیس ،‌حداقل اگه کسی تونست به هر علتی سرویس رو متوقف کنه یا دیتابیس رو به حالت Offline ببره و فایلهارو جابجا کنه ،‌دیگه نتونه فایلش رو باز کنه تا زمانی که به Master Key دسترسی داشته باشه.
یکی از اتفاقاتی که میبینم در همه سیستم ها وجود داره و باز هم همین چالش هست و هرکسی به فایلهای MDF , LDF دسترسی داشته باشه عملا به کل دیتابیس شما دسترسی کامل داره.
اگه TDE رو فعال نکردین یک کپی از فایلهای MDF ,LDF شما برای دسترسی به همه زندگی شما کفایت می کنه 😅
باشد که رستگار شویم. 😬

یکی از سوالات و ابهاماتی که دیدم خیلی وقتها رخ میده ، در خصوص شخص شخیص Transaction Log هست. ! 😂
خدا نکنه روزی سایه شون رو از سر دیتابیس بردارن ،‌همون لحظه است که دیتابیس یک سکته بندری(suspect) میزنه و سایه شوم خرابی داده ها روی سر دیتابیس شما هوار میشه. 😐
اسم این بنده خدا خیلی گمراه کننده است. ما خیلی جاها فکر می کنیم Log یک چیز بدرد نخوره که میشه خیلی راحت پاکش کرد. 🤦‍♂️
ولی این فایل ماهیتش فرق می کنه.
داستان از این قراره که این دوست عزیز کنار ماست تا همه عملیات های تغییرات داده ای رو درون خودش ثبت کنه و به محض اینکه مطمئن شد همه دستورات با موفقیت به اتمام رسیده تازه بیاد اعمال کنه بر روی داده اصلی. چرا؟؟؟؟؟؟؟ چون که ما وابسته نیستیم. 🙃 ( اها هیچی ،‌این به اینجا ربط نداشت. 😬 ) چون میخواد مطمئن بشه وسط کار اگه یک دفعه سرور ترکید دیتاها به لقالله نپیوندن.
دوستان ، عزیزان ،‌اگه این فایل رشد کرده باهاش مهربون باشید . یک دست نوازش ( Log Backup‌) به سرش بکشید آروم میشه . نزنید این فایل رو پاک کنید بعد بگید موقع ساخت دیتابیس خودش میسازه هاااا. از این خبرا همیشه نیستااا.
یک دفعه دیدین یک تراکنش باز داخلش هست که اخ اخ این فایل ساخته نمیشه و دیتابیستون داستان براش ایجاد میشه.
خلاصه از ما گفتن بود.

اینم یک توضیح خیلی ساده از Deadlock
https://www.linkedin.com/feed/update/urn:li:activity:7292994150621147138/?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A%28V2%2Curn%3Ali%3Aactivity%3A7292994150621147138%29

اینم یک توضی ساده در خصوص Wait , Block
https://www.linkedin.com/posts/hamidrezasadeghian_%D9%82%D8%AF%DB%8C%D9%85%D8%A7-%DB%8C%D8%A7%D8%AF%D8%AA%D9%88%D9%86%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%87%D8%B1%DA%86%DB%8C%D8%B2%DB%8C-%D8%A8%D8%A7%DB%8C%D8%AF-%DB%8C%DA%A9-%D8%B2%D9%86%D8%A8%DB%8C%D9%84-%D9%85%DB%8C%D8%B0%D8%A7%D8%B4%D8%AA%DB%8C%D9%85-activity-7293204301697486848-NZWx?utm_source=share&utm_medium=member_desktop&rcm=ACoAADbGkRwBgqyqPtvavkpCR8qVsDP8LlyyDro

ما یک تنظیماتی در SQL Server داریم به نام Cost Threshold For Parallelism . مثل این عکسه. اگه ماشین توی سرپایینی باشه و روشن نشه خودمون تکی احتمالا یک هل میدیم و ماشین روشن میشه.(یعنی هزینه کد ما به این عدد نرسیده و روی Single Thread اجرا میشه)
حالا وقتی تو گل گیر کردیم یا سربالاییه یا جاییه که خلاصه یک نفری نمیشه هلش داد، هرکی رد بشه خفتش میکنیم داداش یک هل بدی روشن میشه مثل عکس پایینی( یعنی هزینه کدت بیشتر از این عددیه که تنظیم شده و SQL Server کدت رو میاد به صورت پارالل اجرا میکنه و بار کدت روبین Core های مختلف تقسیم می کنه)
خوب حالا حتما میگین ایول، ماهرچی پایین تر بذاریم که بهتره از همه ظرفیت CPU استفاده می کنیم.
نه دیگه این مدلی نیست. وقتی کد شما کم هزینه است اگه بیاین اینکارو بکنید خودش میتونه چالش کندی ایجاد کنه . چون همین تقسیم بار بین چند CORE و دوباره جمع آوری اون اطلاعات هزینه بره.
خوب چطوری به عدد درست برسیم؟
پیش فرض خود مایکروسافت عدد ۵ که عدد پایینیه. در حالت کلی این رو روی ۲۵-۳۵ تنظیم میکنند.
ولی درستش اینه که یک مدت کدها مانیتور بشن و بعد میانگین هزینه این کدها در نظر گرفته بشه.

من هرجا که به عنوان مشاور میرم ، اولین چیزی که بهش دقت می کنم تعداد دسترسی های Admin به دیتابیس هست. مثلا یک سرور هست که خوب روش نرم افزارهای مختلف وجود داره. فرض کنید از ۳۰ تا شرکت مختلف . بعد هر شرکتی برای کارش یک دسترسی Sysadmin گرفته.
من نمیدونم چرا باید برای کار روی دیتابیس خودشون دسترسی Sysadmin داشته باشن؟
یعنی روی یک سرور دیدم که ۳۲ تا لاگین sysadmin وجود داره.
خلاصه یک سفره ای پهنه و نون و دیتابیسی هست دور هم میزنن دیگه 😁
همه به همدیگه اعتماد دارن و کسی نمیاد بزنه یک دیتابیس دیگه رو بترکونه یا مشکلی براش ایجاد کنه.
شخصا تا زمانی که تمام دسترسی های ادمین به دیتابیس رو قطع نکنم و فقط خودم دسترسی داشته باشم هیچوقت هیچ مسئولیتی قبول نمیکنم.
شما هم یک سری به لیست ادمین های SQL Server تون بزنید ببینید چه خبره. 😉

میشه وقتی صحبت کندی نرم افزار یا بانک اطلاعاتی میشه ، از گوشه و کنار صداهایی به گوش میاد هی رفیق ایندکس بذار. 😂
مورد داشتیم روی یک جدولی ۴۵ تا ایندکس بوده و باز هم SQL Server توی اجرای کدها Missing Index پیشنهاد میداده. اخه مگه داریم؟ اینقدر یک RDBMS طماع میشه؟
چقدر دیگه باید ایندکس بریزیم توی حلقت تا آروم بگیگیری؟ 😁
حالا داستان اینجاست .
فرض کنید به حول و قوه الهی خدا اینقدر بهتون پول داده که شما یک کلکسیون از ماشین های لوکس رو خریداری کردین و مثلا یک پارکینگی دارید که ۵۰ تا ماشین سوپرلوکس توش پارکه. حالا قصد دارید برید توی بلوار اندرزگو دور دور 😁 (خدایی نکنید اینکارو کلی ترافیک ایجاد میشه 😅 )
اینجاست که هنگ میکنید. نمیدونید کدوم ماشین رو انتخاب کنید( انشالله به حق پنج تن همه تون دچار چنین چگونگی بشین والله)
دقیقا SQL Server هم چنین حالی داره. وقتی دوجین ایندکس میریزین توی جدول ، موقعی که پلن داره طراحی میشه و میخواد انتخاب کنه که کدوم ایندکس مناسبه،‌گیر میکنه که الان کدوم ایندکس رو انتخاب کنم و همچنین میتونه حتی منجر به انتخاب اشتباه بشه. ( مثلا شما هنگ کنید با ماشین آفرودی برید توی بلوار دور دور. نکنید اینکارهارو خدایی 😉 )
این یک بخش داستانه.
حالا شما شروع می کنید میخواهید داده وارد جدولتون کنید یا داده هاتون رو تغییر بدین. ( فرض کنید تصمیم دارین ماشین هاتون رو Tune کنید یا اینکه به شکل و ظاهرش برسید یا مثلا سرامیک کنید.)
هر فیلدی که تغییر می کنه ، اون تغییر باید در تمام ایندکس هایی که اون فیلد دراون حضور داره اعمال بشه .( نمیشه که یک ماشین رو سرامیک کنید یکی رو نه . اون ماشینم دلش میخواد دیگه 😁 )
این باعث میشه حجم زیادی کار صورت بگیره. تمام منابع شما درگیر میشن تا این عملیات بروز رسانی انجام بشه.( تمام ماشین های شما درگیر میشن تا سرامیک بشن و دیگه وقتی برای دور دور ندارین مجبورین با خط ۱۱ تشریف ببرین 😁 )
و حالا احتمالا میتونید حدس بزنید چه حجمی از انتظارها برای اجرای کدهای دیگه پشت در هستند تا این منابع آزاد بشن و برن اجرا بشن( افراد خانواده شما هم همشون منتظر هستن تا اینکار سرامیک ماشین ها به اتمام برسه و هرکسی یک ماشینی رو بزنه توی گوشش و بره به کارش برسه)
احتمالا میتونید بعدش حدس بزنید چه چالش هایی رخ میده؟ سیستم گیر میکنه. کند میشه و شاخص F/S (فحش برثانیه) افزایش پیدا می کنه 😂

حالا حتما سوالتون اینکه چیکارش کنیم؟
هیچی در پستهای بعدی اشاراتی بهش خواهم کرد.
تا پست بعد به ماشینهاتون برسید به ماهم بدید باهاش دور بزنیم 😁

پ.ن : اگه فکر میکنید در این زمینه میتونیم کمکتون کنیم به من پیام بدین

میشه یکی از چالشهایی که در زندگی هست ، تغییر محل زندگیه. وقتی مثلا چندسالی در یک شهر یا محلی زندگی میکنی همه نیازهاتو میدونی از کجا باید تامین کنی ، کیفیت ها دستت میاد و...
وقتی که یک دفعه تصمیم میگیریم که به یک شهر یا یک منطقه دیگه بریم چند وقتی طول میکشه تا دوباره با اون شرایط بسازیم و این میتونه خیلی اختلال ایجاد کنه در زندگی ما و خیلی از فرآيندها رو کند کنه.
توی SQL Server هم Compatibility Level هر دیتابیس دقیقا چنین چیزیه. وقتی که یک دیتابیس با یک Compatibility Level شروع به کار می کنه همه ساخت پلن ها و نحوه اجرای کدها ،‌نحوه بروزرسانی Statistics ها و... برمیگرده به اون و با اون Compatibility Level کار می کنه.
حالا اگه یک دفعه وسط کار شما بیاین این عدد رو تغییر بدین و ارتقاش بدین( مثل این هست که مثلا فرض کنید تا الان توی یک منطقه ای زندگی می کردین که هزینه های زندگی به نسبت مناسبتر بوده یک دفعه میرین به یک میرین به یک منطقه گرون و هزینه ها واقعا دیوونتون می کنه) درسته که کیفیت همه چیز بهتر میشه ، ولی چون ساختار دیتابیس هنوز با این فرآيند جدید آشنا نیست باعث میشه کندی های عجیب غریبی ببینید.
دیروز با یک عزیزی صحبت می کردم ،‌میگفت در یک سیستم معروف کندی رخ داده بود و پشتیبان نرم افزار گفته که باید این رو ارتقا بدی و ارتقا دادن همانا و کندیه چند برابر شدن همانا. ( یک دفعه نمیشه از دنده یک بزنی دنده ۵ که داداش ماشین خاموش میکنه 😁 )
حالا خوب راهش چیه؟ چون این دیتابیس مثلابا نسخه ۲۰۰۸ توسعه داده شده تا ابد باید همون بمونه؟
آها سوال بسیار درستی پرسیدین. باید بگم که خیر.
راهش این هست که شما وقتی SQL Server رو بروز میکنی و نسخه جدید نصب میکنی یک مدتی باید روی دیتابیست Query Store رو فعال کنی و با همون رفتار قدیم ،‌دیتابیست کار کنه. بعد از اینکه مطمئن شدی با همه جای اصلی نرم افزار کار کردی میتونی بیای Compatibility Level رو ارتقا بدی. حالا یک سری کندی پیش میاد احتمالا ، که با Query Store و Force Plan میتونی حلش کنی. بعد سر فرصت باید بری همون کدها رو یک شخمی بزنی و اگه نیاز به بازنویسی داره بازنویسیش کنی.