Восстановление индексов, БД теперь в 10 раз больше

13

У меня есть база данных SQL Server (2008 R2 SP1), которая была около 15 гигабайт. Оказывается, обслуживание не проводилось какое-то время, поэтому я создал план обслуживания, чтобы перестроить все индексы, они были очень фрагментированы.

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

Я очень сбит с толку и могу воспользоваться некоторыми рекомендациями, я вернул БД в разумный размер, для этого у нас нет места на диске.

Заранее спасибо!

Вот результаты обоих запросов:

log_reuse_wait_desc НИЧЕГО

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

Третий файл - это файл .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, а не free%, если бы это было согласованно.

Не переиндексируйте, а затем сокращайтесь, это просто трата времени! Смотрите мой ответ для получения дополнительной информации.

— JNK

1

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

— Эдвард Дортланд,

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 Гб (зависит также от скорости хранения), поэтому просто дайте ему поработать.

— Марсель Н.
источник

Да, это не будет форматировать, я добавлю это к вопросу, один момент.

@JeffBane: Можете ли вы добавить эту информацию в свой вопрос, в цитате? Я не могу разобрать, что там.

— Марсель Н.

1

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

— Эдвард Дортланд,

-1

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

Посмотрите, что select name, log_reuse_wait_desc from sys.databasesговорит вам. Если в столбце log_reuse_wait_desc указано, что LOG_BACKUPон не сможет освободить место, пока вы не сделаете резервную копию журнала транзакций.

— DPW
источник

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

— Мрденный