از زمان ظهور دیسکهای SSD و تحت تست قرار گرفتن در حوزه SQL Server این مطلب شایع شده که نگران Fragmentation ایندکسها روی دیسک SSD نباشیم زیرا به بازده کلی SQL Server لطمه ای نمیزند.
این قضاوت احتمالا از اندازه گیری "فقط" سرعت اجرای دستورات حاصل شده است اما در این پست سه نکته فنی از نظر شما میگذرد که در خصوص دیسکهای SSD باید دانست:
1- تمام دیسکها حتی SSD دارای توان محدودی از لحاظ IOPS یا همان "تعداد انجام درخواست در ثانیه" هستند. زمانی که جداول شما دارای Fragmentation یا ناپیوستگی باشند، تعداد IOهای به مراتب بیشتری انجام میشود اما چون دیسک SSD عمل مکانیکی انجام نمیدهد، سرعت این IOهای اضافی هم بالا است و افت بازده به چشم نمیخورد. پس نگرانی Fragmentation کجاست؟
چنانچه دیسک SSD شما فرضا توان انجام 7000 درخواست در ثانیه را دارد، انجام IO اضافی باعث میشود به این سقف نزدیک شوید. چنانچه حجم اطلاعات یا تعداد کاربران زیاد باشد، تعداد درخواستهای دیسک ممکن است از 7000 تجاوز نماید که چنین وضعیتی را اصطلاحا اشباع یا Saturation میگویند. با پر شدن سقف دیسک، صف ایجاد میگردد و افت سرعت آغاز خواهد شد.
2- در وبینار اخیر اشاره کردیم که پر بودن Pageهای اطلاعات باعث میشود هنگام Page Split میزان لاگ بسیار بیشتری تولید گردد. دیسکهای SSD از این قائده مستثنی نیستند و اگر Rebuild و FillFactor مناسب نداشته باشیم، با رشد بی رویه لاگ فایل و IOهای اضافی روی لاگ روبرو خواهیم شد.
3- از تست ها اینطور بر می آید که Fragmentation باعث میگردد IO در Chunkهای کوچکتری انجام شود حال آنکه در جداول منظم، Chunkها تا چند برابر بزرگترند و یک عمل IO حجم بیشتری خواندن/نوشتن انجام میدهد.
