Назад | Перейти на главную страницу

Сжимать файл данных SQL Server, но не все сразу?

У меня есть файл базы данных размером 150 ГБ, но используется только 75 ГБ - это потому, что я переместил все индексы (остальные 75 ГБ) в новый файл данных. Я хотел бы освободить хотя бы часть пространства из этого файла данных, но когда я пытаюсь сжать файл, он «Выполняется» на неопределенное время, в конечном итоге отменяется из-за прерывания сети или чего-то еще вне моего контроля (после день бега). Даже использование функции «уменьшить до определенного размера» и указание, что он просто обрезал 10 МБ, кажется, никогда не вернет - он просто сидит, пока процесс не будет прерван.

Есть ли другой способ вернуть себе это пространство, хотя бы понемногу?

РЕДАКТИРОВАТЬ: Кто-то опубликовал ссылку, объясняющую, почему я не должен сжимать свою базу данных. Я понимаю и все равно хочу его уменьшить. Дисковое пространство на этом сервере ограничено, и база данных не будет расширяться снова в это неиспользуемое пространство в течение очень долгого времени - как я уже говорил ранее, я перенес индексы из файла данных, чтобы освободить это пространство, поэтому теперь оно потрачено впустую .

Нет, используя DBCC SHRINKFILE ('filename', target_size) это правильный способ сделать это.

Если вы хотите сделать это «кусками», вы можете либо установить постепенно уменьшающиеся целевые размеры, либо просто позволить ему работать столько, сколько сможете, прежде чем оно будет отменено.

Несколько комментариев:

  • Установите разумный целевой размер с некоторым запасом разрешенного свободного места. Может быть, всего 90 ГБ для 75 ГБ данных?
  • Во время сжатия проверьте монитор активности, чтобы убедиться, что SPID не заблокирован. Если на странице в самом конце файла есть открытая транзакция, shrink не сможет переместить ее, пока эта транзакция не будет зафиксирована или не будет отменена.
  • Действительно ли Spid прогрессирует? (Номера CPU и IO меняются)
  • Усадка иногда может длиться очень и очень долго, но она должна сохранить прогресс (это означает, что он перемещается по одной странице за раз, и когда он отменяется, все завершенные перемещения страниц уже выполнены)
  • После отмены усадки попробуйте выполнить DBCC SHRINKFILE ('filename', TRUNCATEONLY). Он должен восстановить все пространство, которое уже было освобождено в конце файла (см. Мой предыдущий пункт)
  • Если вы в отчаянии, попробуйте перезапустить SQL в однопользовательском режиме, чтобы вы знали, что в то время ничего не работает с db (очевидно, это может быть невозможно на prod-сервере)
  • Как только вы сможете завершить сжатие, обязательно выполните полное переиндексирование базы данных, чтобы устранить фрагментацию, которую создает сжатие. Это может вернуть часть только что освобожденного пространства.
  • Если вы по-прежнему не можете заставить термоусадочную трубку работать, ознакомьтесь с некоторыми обсуждениями на этот ТАК вопрос. Очевидно, существуют ситуации, когда усадка может не продвигаться.

В нашей среде мы подошли к нескольким вариантам:

  1. Если старые таблицы могут быть изменены, создайте новые таблицы в совершенно новой файловой группе и установите для нее базу данных по умолчанию. Со временем отбрасывайте старые таблицы, пока предыдущая файловая группа не станет пустой. Тогда брось это.
  2. Если старые таблицы не могут быть изменены, но содержат исторические данные, которые могут быть отключены в течение нескольких часов, создайте новую пустую таблицу, указывающую на новую файловую группу. Поменяйте местами таблицы и начните копировать строки из старой таблицы в новую в пакетном режиме. Однако это может вызвать фрагментацию.
  3. Выполните DBCC SHRINKFILE с опцией EMTPYFILE, и БД переместит все объекты в новый файл. Затем вы можете сбросить старый файл. Однако это может занять много времени.
  4. Повторно создайте кластерный индекс (первичный ключ с DROP_EXISTING) всех таблиц в новую файловую группу. Однако это заблокирует таблицу.

Удачи

Если вы не хотите просто освобождать пространство (что вы специально отказались делать), но настаиваете на попытке сжать базу данных, ожидайте, что это займет очень-очень много времени, и расширение вашего журнала транзакций должно охватывать практически любое пространство вы восстановили из базы данных. В качестве бонуса вы можете наблюдать за тем, как производительность вашей БД после этого повышается. Если Пол Рэндал не может вас убедить (что комментировал JL, но я сделаю репост здесь:Почему не следует сжимать файлы данных что сокращение - ужасная идея, я не уверен, что кто-то сможет. Если повезет, сжатие будет удалено с SQL-сервера (или, по крайней мере, изменено, чтобы оно работало так, как рекомендует Пол) в следующей версии.