Восстановление индексов, БД теперь в 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
источник
Необходимость сделать резервную копию журнала транзакций никогда не приведет к тому, что страницы не будут освобождены.
Мрденный