سلام خدمت دوستان عزیزم
امیدوارم حالتون عالی عالی باشه
داشتم سیستمها رو مانیتور می کردم ، دیدم که بعضی از Index ها Fragment بالایی دارند. با اینکه من جاب Index Maintenance هم دارم. اول رفتم جاب رو دیدم که ببینم نکنه اجرا نشده ، دیدم خیر داره اجرا میشه.
اومدم دستی ایندکس رو Rebuild کردم و وضعیتشو مانیتور کردم . دیدم که به شدت داره Fragment ایجاد میشه و توی 10 دقیقه دوباره 30 درصد Fragment ایجاد شد.
ساختار ایندکس رو بررسی کردم دیدم داخل کلید ایندکس یک فیلد داریم که از نوع Nvarchar هست و مدام این فیلد داره مقدارش Update میشه. با توجه به اینکه از نوع Nvarchar هست پس بسته به دیتایی که داره حجم اشغال میکنه. مقادیر رو بررسی کردم دیدم طول رشته هایی که داخلش بروز میشه متفاوت هست.
کاری که کردم این بود که مقدار Fill factor رو از 95 به 70 تغییر دادم و الان بعد از 24 ساعت تازه 20 درصد Fragment ایجاد شده است.
برای اینکه این مشکل اصولی حل بشه باید ساختار این فیلد عوض بشه که یا طولش ثابت بشه یا اینکه مدل ذخیره سازیش عوض بشه.
ولی در حال حاضر نیز با کاهش Fill Factor این مساله حل شد.
امیدوارم این نکته براتون مفید بوده باشه.
شاد باشین و شکرگزار
حمیدرضا صادقیان
@Hamidreza_Sadeghian
#Fillfactor #Fragment #Index #PerformanceTuning
امیدوارم حالتون عالی عالی باشه
داشتم سیستمها رو مانیتور می کردم ، دیدم که بعضی از Index ها Fragment بالایی دارند. با اینکه من جاب Index Maintenance هم دارم. اول رفتم جاب رو دیدم که ببینم نکنه اجرا نشده ، دیدم خیر داره اجرا میشه.
اومدم دستی ایندکس رو Rebuild کردم و وضعیتشو مانیتور کردم . دیدم که به شدت داره Fragment ایجاد میشه و توی 10 دقیقه دوباره 30 درصد Fragment ایجاد شد.
ساختار ایندکس رو بررسی کردم دیدم داخل کلید ایندکس یک فیلد داریم که از نوع Nvarchar هست و مدام این فیلد داره مقدارش Update میشه. با توجه به اینکه از نوع Nvarchar هست پس بسته به دیتایی که داره حجم اشغال میکنه. مقادیر رو بررسی کردم دیدم طول رشته هایی که داخلش بروز میشه متفاوت هست.
کاری که کردم این بود که مقدار Fill factor رو از 95 به 70 تغییر دادم و الان بعد از 24 ساعت تازه 20 درصد Fragment ایجاد شده است.
برای اینکه این مشکل اصولی حل بشه باید ساختار این فیلد عوض بشه که یا طولش ثابت بشه یا اینکه مدل ذخیره سازیش عوض بشه.
ولی در حال حاضر نیز با کاهش Fill Factor این مساله حل شد.
امیدوارم این نکته براتون مفید بوده باشه.
شاد باشین و شکرگزار
حمیدرضا صادقیان
@Hamidreza_Sadeghian
#Fillfactor #Fragment #Index #PerformanceTuning
👍81❤12👎2👏1
سلام خدمت دوستان عزیزم
امیدوارم که عالی عالی باشین
امروز در یک مرکز دانشگاهی که مدیریت دیتابیس هاشو به عهده دارم ،یک کندی روی یکی از گزارشات رخ داده بود. حجم دیتابیس در این مرکز ۲ ترابایته و یک دیتابیس جداگانه هم برای فایل داریم که اونم ۲ ترابایته.
من کد فوق رو گرفتم و اول کار اومدم Estimated Plan اونو بررسی کردم دیدم Estimate row number ها رو اکثرا ۱ زده. ولی وقتی کد رو اجرا می کنی بیش از ۲۰ دقیقه طول می کشه.
کد رو اجرا کردم ولی Live execution planرو هم فعال کردم ببینم چالشش کجاست. دیدم دقیقا همون ایندکس هایی که Estimate row اون رو ۱ زده بود داره کلی رکورد رو میخونه. رفتم statistics اونو بررسی کردم و با Fullscan اونو آپدیت کردم.
با اینکار کد فوق زیر یک ثانیه اجرا شد و کلا مشکل حل شد. (البته پلن جدا برای بروزرسانی Statistics ها داریم به دلایلی اجرا نشده بود و باعث این اتفاق شده بود)
یک توضیح مختصر میخوام در خصوص Statistics ها بدم.
در واقع نحوه توزیع داده ها و همچنین Density داده ها رو براساس فیلد مورد نظر داره نشون میده. زمانی که یک Plan قراره ساخته بشه براساس فیلدهایی که در شرط ها شرکت کرده میاد Statistics مربوط به اون فیلدها رو انتخاب میکنه و توزیع داده ها و میزان داده هایی که قراره باهاش ارتباط برقرار کنه رو استخراج می کنه و براساس اون میاد پلن میچینه. حالا اگه این جدول بروز نباشه و آمارو ارقامش دقیق نباشه عملا باعث کندی عجیب و غریبی میشه.
مثل یک مدیری هست که در شرکت قراره نقشه راه شرکت رو بکشه و کسی که داره بهش اطلاعات میده بیاد بهش اطلاعات غلط بده. مسلما مدیر مسیری که انتخاب میکنه خیلی پرهزینه تر و پر از اشکال خواهدبود. ولی اگر اطلاعات دقیقی رو دریافت کنه یک مسیر درست رو میتونه انتخاب کنه که هزینه بسیار کمی داشته باشه و راحتتر به هدفشون برسه.
شاد باشین و شکرگزار
حمیدرضا صادقیان
@hamidreza_Sadeghian
#statistics
#ExecutionPlan
#PerformanceTuning
امیدوارم که عالی عالی باشین
امروز در یک مرکز دانشگاهی که مدیریت دیتابیس هاشو به عهده دارم ،یک کندی روی یکی از گزارشات رخ داده بود. حجم دیتابیس در این مرکز ۲ ترابایته و یک دیتابیس جداگانه هم برای فایل داریم که اونم ۲ ترابایته.
من کد فوق رو گرفتم و اول کار اومدم Estimated Plan اونو بررسی کردم دیدم Estimate row number ها رو اکثرا ۱ زده. ولی وقتی کد رو اجرا می کنی بیش از ۲۰ دقیقه طول می کشه.
کد رو اجرا کردم ولی Live execution planرو هم فعال کردم ببینم چالشش کجاست. دیدم دقیقا همون ایندکس هایی که Estimate row اون رو ۱ زده بود داره کلی رکورد رو میخونه. رفتم statistics اونو بررسی کردم و با Fullscan اونو آپدیت کردم.
با اینکار کد فوق زیر یک ثانیه اجرا شد و کلا مشکل حل شد. (البته پلن جدا برای بروزرسانی Statistics ها داریم به دلایلی اجرا نشده بود و باعث این اتفاق شده بود)
یک توضیح مختصر میخوام در خصوص Statistics ها بدم.
در واقع نحوه توزیع داده ها و همچنین Density داده ها رو براساس فیلد مورد نظر داره نشون میده. زمانی که یک Plan قراره ساخته بشه براساس فیلدهایی که در شرط ها شرکت کرده میاد Statistics مربوط به اون فیلدها رو انتخاب میکنه و توزیع داده ها و میزان داده هایی که قراره باهاش ارتباط برقرار کنه رو استخراج می کنه و براساس اون میاد پلن میچینه. حالا اگه این جدول بروز نباشه و آمارو ارقامش دقیق نباشه عملا باعث کندی عجیب و غریبی میشه.
مثل یک مدیری هست که در شرکت قراره نقشه راه شرکت رو بکشه و کسی که داره بهش اطلاعات میده بیاد بهش اطلاعات غلط بده. مسلما مدیر مسیری که انتخاب میکنه خیلی پرهزینه تر و پر از اشکال خواهدبود. ولی اگر اطلاعات دقیقی رو دریافت کنه یک مسیر درست رو میتونه انتخاب کنه که هزینه بسیار کمی داشته باشه و راحتتر به هدفشون برسه.
شاد باشین و شکرگزار
حمیدرضا صادقیان
@hamidreza_Sadeghian
#statistics
#ExecutionPlan
#PerformanceTuning
👍36❤6👏3
میخوام در حوزه Tuning شمارو با یک مفهومی به نام Good Enough (بسه دیگه من خوبم 😅 ) آشنا کنم.
فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم.
دمتون هم گرم.
حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 )
هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم.
میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم.
محمد : تو روی این کده کار کردی؟
حمیدرضا : خوب اره.
محمد : چقدر وقت گذاشتی؟
حمیدرضا :راستش دو روز اشک منو دراورد تا اصلاحش کردم.
محمد : آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره.
😤 😤 😡
اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه.
عزیزان دل،
اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه.
دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید.
یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه.
اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ، میزان لودی که ایجاد می کنه و اهمیت دار بودن اون.
کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 )
این مهم رو در نظر بگیرید خدایی.
چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست.
الزاما تغییر در خیلی از ساختار مناسب نیست.
خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه.
خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 )
@Hamidreza_Sadeghian
#GoodEnough
#PerformanceTuning
#DBA
فرض کنید میخواین یک خودی نشون بدین و بگین که ما خیلی خفنیم و کلاس رفتیم و کلی کتاب خوندیم حالا باید بگیم فلان کار رو کردیم.
دمتون هم گرم.
حالا میرید یک کدی پیدا می کنید که مثلا ۴ ساعت زمان میبره کلی تلاش می کنید مثلا زمانش میرسه به ۱ دقیقه. (بابا ایول چقدر شما خفنید اخه 😁 👏 )
هی منتظر میشین یکی بیاد ازتون تشکر کنه بگه دمت گرم حمیدرضا سیستممون خیلی دیگه سریع کار میکنه مثل بنز داره جواب میده. یک روز، دو روز ،سه روز صبر می کنیم بعد وقتی که میبینم نه مثل اینکه هیچ خبری نیست با کوله باری از 🤬 🤬 راهی اطلاع رسانی به شرکت میشیم.
میریم شروع می کنیم به تیم توسعه میگیم ببین محمد من یک کار خفن کردم این کد رو زمانش رو اینقدر تغییر دادم.
محمد : تو روی این کده کار کردی؟
حمیدرضا : خوب اره.
محمد : چقدر وقت گذاشتی؟
حمیدرضا :راستش دو روز اشک منو دراورد تا اصلاحش کردم.
محمد : آفرین خسته نباشید این یک گزارشی هست که هر ۴ ماه یک بار واحد X میگیره و خیلی هم زمانش براش اهمیتی نداره.
😤 😤 😡
اینجاست که انگار آب یخ روی شما ریختن. حالا تو این وسط دوجین هم ایندکس ایجاد کردین که باعث شده صدتا کد اساسی بره تو دیوار که این کد درست کار کنه.
عزیزان دل،
اول باید ببینید چه کدی داره چه باری میذاره و چند وقت یکبار داره بار ایجاد می کنه.
دوم اینکه تا چقدر باید پیش بریم روی تیونینگ کد که خوب باشه. یک کدی اگه توی یک دقیقه هم جواب بده اکیه نیازی نیست زیادی باهاش سرو کله بزنید و دوجین ایندکس بهش اضافه کنید.
یک کدی هم ۵۰ میلی ثانیه زمان میبره باید برسونیدش مثلا به ۲۰ میلی ثانیه.
اینکه روی چه کدی و چقدر کار کنیم تا کجا پیش بریم و سعی کنیم بهینه اش کنیم برمیگرده به تعداد دفعات اجرا ، میزان لودی که ایجاد می کنه و اهمیت دار بودن اون.
کدی که قراره هر یک ماه یکبار یک گزارش بگیره این شاید به اندازه کدی که روزی ۱۰۰۰ مرتبه اجرا میشه با اهمیت نباشه(هرچند ممکنه اون ماهی یک بار برای مدیر مربوطه باشه.که اونو میشه زمانش رو یک مقداری بهینه تر کرد تا اخراج نشیم 😂 )
این مهم رو در نظر بگیرید خدایی.
چون Tuning هزینه داره. الزاما ایجاد هر ایندکسی مناسب نیست.
الزاما تغییر در خیلی از ساختار مناسب نیست.
خیلی از رفتارها مناسب نیست و واقعا باید یک سبک و سنگین بین مزایا و معایبش اتفاق بیافته و بعد انجام بشه.
خدایی چقدر ما DBA ها خفن هستیم که حواسمون به همه چیز هست مثل ... (برای خودمون نوشابه پوست بکنیم 😅 )
@Hamidreza_Sadeghian
#GoodEnough
#PerformanceTuning
#DBA
👍27👌5❤3😁2👏1