SQL Server не используется, но зарезервировано табличное пространство
У меня есть базы данных ms sql, которые становятся очень большими. При осмотре я обнаружил, что в некоторых таблицах есть много неиспользуемого места. Я не выполняю много операций физического удаления, поэтому не думаю, что это просто удаленные записи. DBCC SHRINK не уменьшает размер файла. Но если я перенесу таблицу в новую пустую базу данных, размер уменьшится примерно на 80%. Вместо 7 ГБ, которые у меня есть в этой таблице в текущей базе данных, я получаю около 1,5 ГБ в новой базе данных. Как будто sql-сервер выделяет слишком много памяти. Кто-нибудь сталкивался с этим раньше? Я хотел бы иметь возможность уменьшить таблицу, удалив неиспользуемое выделенное пространство, без необходимости создавать целую новую базу данных.
Дополнительная информация:
Использована модель полного восстановления. Попробую перестроить индексы, думаю, давно прошло. ldf ежедневно сжимаются с использованием какой-то дурацкой хранимой процедуры, которая их усекает.
Это уместно? Статья в КБ 924027 - SQL Server значительно увеличивает неиспользуемое пространство для некоторых таблиц
Взгляните на эту статью базы знаний и посмотрите, применима ли она: support.microsoft.com/kb/913399
вы пробовали перестроить индекс?
Ответы 6
В опциях вы можете указать, на сколько хотите вырасти. По умолчанию я считаю, что это 10%, поэтому, учитывая базу данных 200 МБ, когда вы заполняете свою последнюю страницу, она выделяет еще 20 МБ пространства страницы. При 7 ГБ будет выделено 700 МБ.
Я не знаю точно, где вы можете изменить его после создания базы данных, но я знаю, что она есть, когда вы создаете базу данных. небольшая работа с Google, скорее всего, откроет вам ответ.
ПРИМЕЧАНИЕ: мой ответ заключается не в том, как это исправить, а в том, как предотвратить / объяснить, почему вы можете увидеть все это нераспределенное пространство.
Я обнаружил, что если вы не позаботитесь о резервном копировании файла журнала переходов (LDF), вы получите что-то вроде этого поведения. Я не могу не подчеркнуть важность наличия хорошей резервной «гигиены». Это не только спасет ваш бекон, если что-то пойдет не так, но я также помогу поддерживать хорошую и надежную базу данных.
Согласны, никогда не забывайте делать резервные копии журналов транзакций, а также резервных копий базы данных. Журнал будет расти, пока не съест весь ваш жесткий диск.
I don't do many physical deletes
насчет обновлений таблицы, каков уровень фрагментации. запустите DBCC SHOWCONTIG, затем перестройте индекс, если он сильно фрагментирован. После этого сделайте РЕЗЕРВНОЕ КОПИРОВАНИЕ ЖУРНАЛА С TRUNCATE_ONLY, за которым следует команда SHRINK.
Это сработало для меня в прошлом
USE [DBNAME]
GO
DBCC SHRINKFILE (N'FILENAME' , 0, TRUNCATEONLY)
GO
Однажды у меня была аналогичная проблема, и я считаю, что обнаружил, что переиндексирование / сжатие не восстанавливает все неиспользуемое пространство, если для данной таблицы не было кластерного индекса.
Возможно, таблица была построена с включенным заполнением для индекса. Причина, по которой люди создают индекс с заполнением, состоит в том, чтобы предотвратить разделение страниц.
Щелкните правой кнопкой мыши таблицу в диспетчере SQL и выберите ТАБЛИЦА СКРИПТА. Тогда посмотрите, есть ли PAD_INDEX=OFF. Если используется PAD_INDEX, вероятно, там таблица занимает место.
Абсолютно БЕЗ ВОПРОСА в использовании модели полного восстановления, если все, что вы делаете с LDF, - это их усечение! Правильный способ уменьшить их размер - сделать резервную копию файлов журнала, после чего они автоматически уменьшатся. Кто-то, кто понимает цепочки журналов и правильную стратегию резервного копирования, отчаянно нужен, чтобы вмешаться и помочь вам разобраться в этом. Что-то меньшее ставит вас на страшный риск потери данных.