Не удается освободить нераспределенное пространство в SQL Server 2005

Question

У меня очень большая база данных (40 гигабайт), и я выполнил процедуру

sp_space_used 

и обнаружил, что есть 10 гигабайт нераспределенного пространства. Очевидно, что это много, и файл .mdf занимает большую часть диска. Я смотрел в бега

DBCC SHRINKDATABASE (db, TRUNCATEONLY);

Нужно ли мне сжимать журнал транзакций, или shrinkdatabase позаботится об этом? Каковы негативные последствия запуска этой процедуры? Могу ли я запустить это, пока база данных используется? Я попытался запустить команду shrinkdatabase, но все еще осталось много нераспределенного пространства.

database_size   unallocated space
49575.06 MB   8393.49 MB

reserved       data        index_size   unused
42170328 KB 22704672 KB 19099160 KB  366496 KB

ПРИМЕЧАНИЕ: база данных имеет простую модель восстановления, так что я думаю, мне вообще не нужно делать резервную копию журнала.

В чем разница между бегом

DBCC SHRINKFILE (datafile, TRUNCATEONLY)

до

DBCC SHRINKDATABSE (db, TRUNCATEONLY)?

Answer 1

Самый быстрый способ очистить пространство журнала транзакций (хотя после ПОЛНОГО резервного копирования) - установить простой режим, подождать минуту или две, а затем сжать журнал транзакций. Это сократит его до 1 МБ. Затем снова включите его в режим FULL вместо SIMPLE.

Answer 2

Команда sp_spaceused также включает в себя свободное место в файле журнала. Хотя ваша модель журнала базы данных проста, SQL использует ваш файл журнала для отслеживания транзакций, и файл журнала увеличивается и не уменьшается до тех пор, пока вы не запустите резервное копирование. Я знаю, что вы упомянули, что mdf-файл занимает большую часть диска, но проверяли ли вы размер вашего ldf-файла? Вы также проверили фрагментацию кластерных индексов?

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

use [db_name]
backup log [db_name] with truncate_only
dbcc shrinkfile ([db_log_filename], 1)

Этот оператор не запустит фактическое резервное копирование, он просто урежет журнал и позволит shrinkfile удалить свободное место, которое использует файл журнала. Если вы планируете запустить его в производство, я бы порекомендовал вам сделать это в непиковое время. Хотя это не займет много времени. Это влияет только на размер файла журнала.

Надеюсь, это поможет, и понятно, почему я бы порекомендовал вам также проверить файл журнала.

Answer 3

Я использовал DBCC SHRINKDATABASE (db, %);, указав целевой процент, который, казалось, решил мою проблему.

Answer 4

Прежде чем делать какие-либо структурные изменения в вашей базе данных, сделайте FULL Database Backup.

Если, как вы говорите, большая часть нераспределенного пространства находится в вашем файле данных SQL Server (.mdf), вам следует использовать DBCC SHRINKFILE , а не DBCC SHRINKDATABASE.

Так, например:

USE UserDB;
GO
DBCC SHRINKFILE (LogicalDataFileName, target_sizeInMB );
GO

Дополнительно рассмотрите возможность использования опции TRUNCATEONLY , чтобы освободить доступное пространство только в конце файла данных. Это менее ресурсоемкий вариант, но он не может освободить столько места. Имейте в виду, target_size игнорируется, если указано с TRUNCATEONLY.

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

В свете ваших правок:

DBCC SHRINKDATABASE попытается сжать все файлы в вашей базе данных, то есть файлы данных и журналов.

DBCC SHIRNKFILE, с другой стороны, обеспечивает более высокий уровень контроля в том, что он применяется к конкретному файлу.