Перебудовуючи індекси, тепер БД розміром 10x

13

У мене база даних SQL Server (2008 R2 SP1), яка становила близько 15 концертів. Виявляється, технічне обслуговування не працювало деякий час, тому я створив план технічного обслуговування, щоб відновити всі індекси, вони були дуже фрагментарними.

Робота закінчена, і фрагментація пішла, але зараз база даних перевищує 120 концертів! Я розумію, що він би використовував додатковий простір для всіх перебудов, але тепер, коли робота виконана, я б подумав, що весь цей простір був би вільним простором, але вільний простір показує лише 3 концерти, тому використовується 117 гігів навіть якщо робота з відновлення індексу закінчена.

Я дуже розгублений і можу скористатись деякими рекомендаціями. У мене є повернення db до розумного розміру, у нас немає місця на диску для цього.

Спасибі заздалегідь!

Ось результати обох опублікованих запитів:

log_reuse_wait_desc НІЧОГО

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

3-й файл - це .ndf-файл, який показує лише 3688 у невикористаному просторі, але 111289 використовується для близько 15 гігів даних.

sql-server sql-server-2008 sql-server-2008-r2

— AS2012
джерело

15

Тим часом я лише з’ясував це, тотальна відрижка мозку. Я вказав, що я вважав коефіцієнтом заповнення 90 у роботі по відновленню, але це написано як "змінити відсоток вільного простору на", тому, використовуючи значення 90 там, я фактично використовував коефіцієнт заповнення 10 !! DOH. Недарма воно виросло в 10 разів на велике. Я збираюся відновити з правильним коефіцієнтом заповнення, потім зменшую. Дякуємо всім за вклад.

— AS2012
джерело

1

Цей майстер просто жахливий.

— usr

Я знаю, я так звик до командного рядка, де ви вказали FILL_FACTOR, а не вільний%, хоч би, щоб він був послідовним.

Не перевстановлюйтесь, а потім не скорочуйтесь, це просто марна трата часу! Дивіться мою відповідь для отримання додаткової інформації.

— JNK

1

JNK Я знаю, що ти маєш на увазі, не зменшуйся після відновлення, оскільки це знову роздробить все. Однак у цьому конкретному сценарії, коли Джефф випадково додав 90% вільного місця на кожну сторінку, я не бачу іншого способу повернути простір, а потім: відновити за допомогою fillfactor 90, зменшити файл, однак вам доведеться зробити ще одну перебудову з наповнювачем на 90% знову. Або був би інший спосіб повернути простір назад. (Ну , може бути , нова група файлів , а потім відновити з падінням на нову файлову групу , але це не працює для всіх)

— Едвард Dortland

2

Перебудова індексів спричиняє зайвий простір у БД. Це природний побічний продукт процесу реіндексації - сервер будує нову, сподіванусь, суміжну версію індексу поряд із поточною версією, після чого завершує видалення поточної версії після її завершення.

Скорочення після повторного деіндексації безглуздо!

Ви просто перефрагментуйте індекс! Зменшення видаляє вільний простір шляхом перерозподілу даних всередині БД.

Ось приємна стаття Пола Рандала, який, працюючи в Microsoft, відповідав за DBCCкод, включаючи скорочення, про те, чому ви не повинні зменшуватися.

— JNK
джерело

0

Ви мали використовувати варіант відновлення SORT_IN_TEMPDB=ON.

У вашому випадку фактичні файли (файли) даних, де знаходяться розглянуті таблиці, використовувались для сортування індексів. Значна частина цього 120 ГБ місця все ще не використовується, і вона заповнюватиметься даними сторінки, коли це буде потрібно.

Ви можете побачити статус використаного / вільного простору за допомогою цього запиту (взято звідси ):

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

Щоб скоротити певний файл бази даних (дані або журнал), ви можете ознайомитись тут з деякою інформацією . Попередження перед цим звільнення невикористаного простору займає досить багато часу для баз даних 100+ Gb (залежить також від швидкості зберігання), тому просто дайте йому працювати.

— Марсель Н.
джерело

Так, це звичайний формат, я додам його до питання, одну мить.

@JeffBane: Чи можете ви додати цю інформацію до свого питання у цитаті? Я не можу зрозуміти, що там є.

— Марсель Н.

1

Під час перебудови індексу вам потрібно буде вдвічі більше місця індексу + 20% для сортування. Тож загалом для відновлення кожного індексу у вашому DB вам потрібно лише 120% вашого найбільшого індексу у вашій БД. Якщо ви використовуєте SORT_IN_TEMPDB, ви набираєте лише 20%, у вашому файлі даних все одно потрібен додатковий 100%. Крім того, використання сортування в tempdb різко збільшує завантаження вводу-виводу, оскільки замість того, щоб індекс записати один раз у файл даних, ви одноразово записуєте його до tempdb, а потім записуєте його у файл даних. Тож це не завжди ідеально.

— Едвард Дортленд

-1

Без будь-яких інших деталей я підозрюю, що вам потрібно зробити резервну копію журналу транзакцій, перш ніж ви зможете повернути її простір.

Подивіться, що select name, log_reuse_wait_desc from sys.databasesвам каже. Якщо стовпець log_reuse_wait_desc говорить, LOG_BACKUPто він не може повернути пробіл, доки ви не зробите резервну копію журналу tran.

— dpw
джерело

Необхідність робити резервну копію журналу транзакцій ніколи не призведе до виходу сторінок.

— mrdenny