Во-первых, если вы можете избежать сокращения базы данных производства, тогда сделайте это. Покупка дополнительного дискового хранилища практически всегда является более практичным решением в долгосрочной перспективе.
Существует причина, по которой ваши данные базы данных/файлы журнала выросли до их текущего размера, и если вы не очистили данные из своей базы данных, то очень вероятно (если не определенность), что ваша база данных будет расти до текущего размера еще раз, после усадки.
Учитывая это, вы должны посмотреть, как определить причину роста базы данных.
И наконец, если вы абсолютно должны сжать свою базу данных, выберите время, чтобы сделать это с умом, то есть выполнить это обслуживание в то время, когда ваша живая система обычно испытывает более низкую рабочую нагрузку. Сокращение файлов данных приводит к значительному объему дискового ввода-вывода, особенно если страницы данных должны быть реорганизованы.
Затем определите, какие файлы данных или файлы журналов содержат наибольшее свободное пространство и нацеливают их на сжатие отдельно. Нет смысла выполнять упражнение с уменьшением ширины базы данных, если, например, это только файл журнала, на котором имеется значительное количество свободного места.
Для этого обратитесь к документации для команды DBCC SHRINKFILE.
Полезная информация:
Indentify количество свободного пространства в базе данных в целом:
EXEC sp_spaceused
Определить количество свободного пространства журнала:
DBCC SQLPERF('logspace')
Определить количество свободного места на каждый файл данных/журнала:
SELECT
name AS 'File Name' ,
physical_name AS 'Physical Name',
size/128 AS 'Total Size in MB',
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS 'Available Space In MB',
*
FROM sys.database_files;