Сжать файл данных SQL Server, но не все сразу?
У меня есть файл базы данных, который в настоящее время составляет 150 ГБ, но используется только 75 ГБ - это потому, что я переместил все индексы (остальные 75 ГБ) в новый файл данных. Я хотел бы освободить хотя бы часть пространства из этого файла данных, но когда я пытаюсь сжать файл, он "выполняется" на неопределенный срок, в конечном итоге отменяется из-за прерывания сети или чего-то другого, находящегося вне моего контроля (после день бега). Даже если использовать функцию "сжать до определенного размера" и указать, что она просто урезает 10 МБ, то, кажется, никогда не вернется - она просто сидит, пока процесс не прерван.
Есть ли другой способ, которым я могу восстановить это пространство, хотя бы понемногу?
РЕДАКТИРОВАТЬ: Кто-то опубликовал ссылку, объясняющую, почему я не должен сокращать свою базу данных. Я понимаю, и я все равно хочу уменьшить это. На этом сервере больше места на диске, и база данных не будет снова расширяться в это неиспользуемое пространство в течение очень долгого времени - как я говорил ранее, я перенес индексы из файла данных, чтобы освободить это пространство, поэтому теперь он потрачен впустую,
3 ответа
Нет, используя DBCC SHRINKFILE ('filename', target_size) это правильный способ сделать это.
Если вы хотите сделать это "чанками", вы можете либо установить постепенно меньшие целевые размеры, либо просто позволить ему работать так долго, как вы можете, прежде чем его отменят.
Несколько комментариев:
- Установите разумный размер цели с некоторым запасом разрешенного свободного места. Может быть, 90 ГБ всего для 75 ГБ данных?
- Во время работы сжатия проверьте монитор активности, чтобы убедиться, что SPID не заблокирован. Если на странице в самом конце файла есть открытая транзакция, то shrink не сможет ее переместить, пока эта транзакция не будет зафиксирована или откатана.
- Спид действительно прогрессирует? (Номера CPU и IO меняются)
- Сжатие может иногда занимать очень и очень много времени, но оно должно сохранять свой прогресс (т.е. оно перемещается на 1 страницу за раз, а когда оно отменяется, все завершенные перемещения страницы уже выполнены)
- После отмены сокращения, попробуйте сделать
DBCC SHRINKFILE ('filename', TRUNCATEONLY), Он должен восстановить все пространство, которое уже освобождено в конце файла (см. Мой предыдущий пункт) - Если вы впадаете в отчаяние, попробуйте перезапустить SQL в однопользовательском режиме, чтобы вы знали, что в это время больше ничего не работает с БД (очевидно, это может быть невозможно на сервере prod)
- Как только вы сможете завершить сжатие, обязательно выполните полную переиндексацию базы данных, чтобы устранить фрагментацию, создаваемую сжатием. Это может вернуть часть пространства, которое вы только что освободили.
- Если вы все еще не можете получить сокращенную работу, ознакомьтесь с некоторыми обсуждениями этого SO вопроса. Очевидно, в некоторых ситуациях усадка может не прогрессировать.
Мы подошли к нескольким вариантам в нашей среде:
- Если вы можете использовать старые таблицы, создайте новые таблицы в новой файловой группе и задайте для нее базу данных по умолчанию. С течением времени отбрасывайте старые таблицы, пока предыдущая файловая группа не станет пустой. Тогда брось это.
- Если старые таблицы не могут быть выровнены, но содержат исторические данные, которые могут быть отключены в течение нескольких часов, создайте новую пустую таблицу, указывающую на новую файловую группу. Поменяйте местами таблицы и начните копировать строки из старой таблицы в новую в пакетном режиме. Это может привести к фрагментации, хотя.
- Выполните DBCC SHRINKFILE с опцией EMTPYFILE, и БД переместит все объекты в новый файл. Затем вы можете удалить старый файл. Это может занять много времени, хотя.
- Воссоздайте кластеризованный индекс (первичный ключ с DROP_EXISTING) всех таблиц в новую файловую группу. Это заблокирует стол, хотя.
Удачи
Если вы не хотите просто освобождать пространство (что вы конкретно отказались делать), но настаиваете на попытке уменьшить базу данных, ожидайте, что это займет очень очень много времени, и расширение вашего журнала транзакций должно примерно охватить любое пространство вы восстановили из базы данных. В качестве бонуса, следите за тем, как ваша производительность БД поднимается до минимума. Если Пол Рэндал не может вас убедить (Который JL прокомментировал, но я опубликую здесь: почему вы не должны сжимать ваши файлы данных, что сжатие - ужасная идея, я не уверен, что кто-то может. Если удача будет удалена из Сервер SQL (или, по крайней мере, его нужно изменить, чтобы он работал, как рекомендует Пол), в следующей редакции.