у вас є вагомі причини для занепокоєння, оскільки БД скорочується на SQL Server часто "смокче". Пол Рендал, керівник системи зберігання даних у SQL 2005 року, заявив, що ShrinkDB написано дуже погано. Він знайде порожній простір, взявши дані в самому кінці і поставивши їх на самому початку, і продовжувати робити це, поки у нього не буде вільного місця в кінці файлів БД. Після цього він може звільнити простір від SQL Server і повернути його назад в ОС. Ви ефективно обертаєте файли бази даних, таким чином ви зазвичай бачите масову фрагментацію. Про його погляди ви можете прочитати у цій публікації блогу чи у цьому відео MCM Internals
Як і у всьому, ви дійсно повинні спочатку перевірити їх у своєму оточенні. Кращий спосіб зробити це - переміщення даних в іншу файлову групу. Ви можете зробити перебудову індексу в Інтернеті за допомогою кластерного індексу, а потім перевстановити в нову групу файлів. Тоді ви можете скинути старий і звільнити простір і майже не мати фрагментації. Зверніть увагу, що це займе приблизно 120% додаткового місця під час роботи над ним. Проблема в цьому полягає в тому, що вам потрібно навіть додаткове вільне місце, яке, схоже, у вас може бути. Це особливість підприємства.
Якщо вільний простір настільки великий, то вам, можливо, доведеться кусати кулю і повільно стискати БД невеликим шматочком за один раз, щоб уникнути тривалих запущених процесів. Зауважте, що ваші дані будуть сильно фрагментовані, і вам захочеться знову переробити все. Зауважте, що після перевстановлення всього, ви трохи надуваєте використаний простір і повернетесь до додаткового вільного місця. Дивіться поради Брента тут .
Що стосується того, скільки вільного місця для вас добре, питання про те, наскільки ви можете дозволити собі фрагментацію та активізацію росту файлів. Якщо IFI увімкнено, зростання файлів майже миттєве, але ви все одно отримуєте фрагментацію. Добре правило - виділити стільки місця, скільки, на вашу думку, потрібно, або стежити за ростом і періодично коригувати шматки, якщо вам доведеться. Це зменшує фізичну фрагментацію.
Також зростання файлів журналу набагато важливіше. Додаткові файли журналу можуть викликати фрагментацію VLF. Це робить ваш процес відновлення значно повільнішим і може впливати на контрольно-пропускний пункт / скорочення. Ось деякі ризики щодо продуктивності, які ви берете за допомогою фрагментованого журналу Виконайте DBCC LOGINFO();кожну базу даних. Постарайтеся зберегти число близько 50 вбік за Кіма Триппа, але якщо ви бачите сотні, у вас є проблеми з фрагментацією, що означає, що ваші файли журналів повинні зростати, щоб підтримувати операції. Хороший спосіб побачити, який має бути ваш файл журналу за Полом Рандалом, - це просто дати йому зростати протягом тижня і переробити. Це може бути хорошим моментом, можливо, ви можете викинути трохи більше вільного місця на всякий випадок. Переконайтесь, що ваші журнали не фрагментовані за допомогою DBCC LOGINFO (); знову ж таки, і якщо вони є, це означає, що вони багато зросли. Зменшити та повторно розгорнути файл журналу за допомогоюцей метод .