DBCC SHRINKDATABASE (Transact-SQL)

Применимо к: даSQL Server (все поддерживаемые версии) ДаБаза данных SQL Azure ДаУправляемый экземпляр SQL Azure даAzure Synapse Analytics

Сокращает размер файлов данных и файлов журнала в указанной базе данных.

Значок ссылки на раздел Синтаксические обозначения в Transact-SQL

Синтаксис

DBCC SHRINKDATABASE   
( database_name | database_id | 0   
     [ , target_percent ]   
     [ , { NOTRUNCATE | TRUNCATEONLY } ]   
)  
[ WITH NO_INFOMSGS ]  
-- Azure Synapse Analytics

DBCC SHRINKDATABASE   
( database_name   
     [ , target_percent ]   
)  
[ WITH NO_INFOMSGS ]

Примечание

Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.

Аргументы

имя_бд | ид_бд | 0
Имя или идентификатор базы данных, которая должна быть сжата. Если указано значение 0, используется текущая база данных.

целевой_процент
Процент свободного пространства, которое должно остаться в базе данных после сжатия.

NOTRUNCATE
Перемещает назначенные страницы с конца файла в неназначенные страницы в начале файла. Это действие сжимает данные в файле. Целевой_процент является необязательным. Azure Synapse Analytics не поддерживает этот параметр.

Свободное место в конце файла не возвращается операционной системе, и физический размер файла не изменяется. Таким образом, база данных физически не уменьшается при указании NOTRUNCATE.

Аргумент NOTRUNCATE применим только к файлам данных. NOTRUNCATE не влияет на файл журнала.

TRUNCATEONLY
Освобождает все свободное пространство в конце файла и возвращает его операционной системе. Не перемещает какие-либо страницы в файле. Файл данных сжимается только до последнего назначенного экстента. Аргумент целевой_процент не учитывается, если указан аргумент TRUNCATEONLY. Azure Synapse Analytics не поддерживает этот параметр.

Аргумент TRUNCATEONLY оказывает влияние на файл журнала. Для усечения только файла данных используйте инструкцию DBCC SHRINKFILE.

WITH NO_INFOMSGS
Подавляет все информационные сообщения со степенями серьезности от 0 до 10.

Результирующие наборы

В следующей таблице отображены столбцы результирующего набора.

Имя столбца Описание
DbId Идентификатор базы данных, файл которой компонент Компонент Database Engine пытался сжать.
FileId Идентификатор файла, который компонент Компонент Database Engine пытался сжать.
CurrentSize Количество 8-килобайтных страниц, занятых файлом в настоящее время.
MinimumSize Минимальное количество 8-килобайтных страниц, которое может занимать файл. Это значение соответствует минимальному размеру или размеру файла, указанному при создании.
UsedPages Количество 8-килобайтных страниц, используемых файлом в настоящее время.
EstimatedPages Количество 8-килобайтных страниц, до которого можно было бы сжать файл по оценке компонента Компонент Database Engine.

Примечание

Компонент Компонент Database Engine не отображает строки для файлов, размер которых не был сокращен.

Remarks

Примечание

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

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

Чтобы просмотреть количество свободного (нераспределенного) пространства в базе данных, выполните процедуру sp_spaceused.

Операции DBCC SHRINKDATABASE могут быть остановлены на любом этапе процесса, при этом вся выполненная работа сохраняется.

Размер базы данных нельзя сделать меньше минимального настроенного размера базы данных. Минимальный размер указывается при создании базы данных. Также минимальный размер может быть последним размером, явно установленным в операции изменения размера файла. Такие операции, как DBCC SHRINKFILE или ALTER DATABASE, — примеры операций, изменяющих размер файла.

Предположим, что база данных была создана с размером 10 МБ. Затем она увеличивается до 100 МБ. Наименьший размер базы данных, до которого ее можно сжать, — 10 МБ, даже если все данные в базе данных будут удалены.

При выполнении команды DBCC SHRINKDATABASE укажите параметр NOTRUNCATE или TRUNCATEONLY. Если этого не сделать, результат будет таким же, как если бы вы выполнили операцию DBCC SHRINKDATABASE с аргументом NOTRUNCATE и последующим запуском операции DBCC SHRINKDATABASE с аргументом TRUNCATEONLY.

База данных не обязана находиться в однопользовательском режиме. Другие пользователи могут работать в базе данных (в том числе системной) при ее сжатии.

Невозможно сжать базу данных во время создания ее резервной копии. И наоборот, невозможно создать резервную копию базы данных во время операции сжатия.

Работа команды DBCC SHRINKDATABASE

Инструкция DBCC SHRINKDATABASE сжимает файлы данных по одному, а файлы журнала так, как будто все они представляют один непрерывный пул журнала. Сжатие файлов всегда ведется с конца.

Предположим, имеется несколько файлов журнала, файл данных и база данных с именем mydb. Каждый файл данных и журнала имеет размер 10 МБ, а файл данных содержит 6 МБ данных. Компонент Компонент Database Engine вычисляет целевой размер каждого файла. Это размер, до которого файл должен быть сжат. Если инструкция DBCC SHRINKDATABASE указана с аргументом целевой_процент, то компонент Компонент Database Engine вычисляет целевой размер таким образом, чтобы в файле после сжатия был целевой_процент свободного пространства.

Например, если указать целевой_процент со значением 25 для сжатия базы данных mydb, компонент Компонент Database Engine рассчитает целевой размер для файла, равный 8 МБ (6 МБ данных и 2 МБ свободного пространства). Поэтому компонент Компонент Database Engine перемещает все данные из последних 2 МБ файла данных в любое свободное пространство в первых 8 МБ файла данных, а затем сжимает файл.

Предположим, что файл данных базы данных mydb содержит 7 МБ данных. При задании значения 30 для аргумента целевой_процент можно сжать этот файл данных до 30 %. Но задание значения 40 для целевой_процент не позволит сжать файл данных, так как Компонент Database Engine не может уменьшить файл до размера, меньшего, чем занимают данные сейчас.

Эту ситуацию можно представить и другим способом: 40 процентов желаемого свободного пространства + 70 процентов от полного файла данных (7 МБ из 10 МБ) больше, чем 100 процентов. Любой целевой_процент больше 30 не приведет к сжатию файла данных. Сжатия не будет, поскольку сумма освобождаемого процента и текущего процента, занятого в файле данных, превышает 100 процентов.

Для файлов журнала Компонент Database Engine вычисляет целевой размер всего журнала на основе аргумента целевой_процент. Вот почему целевой_процент — это объем свободного места в журнале после операции сжатия. Целевой размер всего журнала затем пересчитывается в целевой размер каждого файла журнала.

Инструкция DBCC SHRINKDATABASE пытается немедленно сжать каждый физический файл журнала до его целевого размера. Предположим, что в виртуальных файлах журнала нет частей логического журнала за пределами целевого размера файла журнала. Тогда файл будет успешно усечен, и инструкция DBCC SHRINKDATABASE завершится без сообщений. Однако если какая-то часть логического журнала хранится в виртуальных журналах за пределами заданного размера, то компонент Компонент Database Engine освобождает как можно больше места, а затем выдает информационное сообщение. Сообщение описывает действия, которые необходимо предпринять, чтобы переместить логический журнал из виртуальных журналов в конец файла. После выполнения всех действий инструкция DBCC SHRINKDATABASE может быть использована для освобождения оставшегося пространства.

Файл журнала может быть сжат только до границы виртуального файла журнала. Именно поэтому сжатие файла журнала до размера, меньшего, чем размер виртуального файла журнала, может оказаться невозможным. Это также может быть невозможно, даже если он не используется. Размер виртуального файла журнала динамически выбирается компонентом Компонент Database Engine при создании или расширении файлов журнала.

Рекомендации

Обратите внимание на следующие сведения при планировании сжатия базы данных.

  • Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей неиспользуемое пространство, например после усечения таблицы или удаления таблицы.
  • Большинству баз данных требуется некоторое свободное пространство для выполнения обычных ежедневных операций. Можно сжать базу данных несколько раз и заметить, что она снова увеличивается в размерах. Такой рост указывает, что сжатое пространство необходимо для выполнения обычных операций. В таких случаях повторное сжатие базы данных бессмысленно.
  • Операция сжатия не исключает фрагментацию индексов в базе данных и даже, наоборот, приводит к усилению фрагментации. Это еще одна причина, по которой не стоит выполнять регулярное сжатие базы данных.
  • Не следует устанавливать параметр базы данных AUTO_SHRINK равным ON без достаточных на то оснований.

Устранение неполадок

Операции сжатия могут быть блокированы транзакцией, запущенной с уровнем изоляции, основанным на управлении версиями строк. Например, если выполняется масштабная операция удаления под уровнем изоляции с управлением версиями строк, когда запускается инструкция DBCC SHRINK DATABASE. Когда это происходит, операция сжатия будет ожидать, пока завершится операция удаления, прежде чем приступить к сжатию файлов. При возникновении такого ожидания для операций DBCC SHRINKFILE и DBCC SHRINKDATABASE выводится информационное сообщение (5202 для SHRINKDATABASE и 5203 для SHRINKFILE). Это сообщение выводится в журнал ошибок SQL Server каждые пять минут в течение первого часа, а затем каждый последующий час. Например, журнал ошибок содержит следующее сообщение об ошибке:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot   
transaction with timestamp 15 and other snapshot transactions linked to   
timestamp 15 or with timestamps older than 109 to finish.  

Эта ошибка означает, что транзакции моментальных снимков с отметками времени старше 109 заблокируют операцию сжатия. Такая транзакция — последняя транзакция, завершаемая операцией сжатия. Это также показывает, что столбцы transaction_sequence_num или first_snapshot_sequence_num в динамическом административном представлении sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) содержат значение 15. Столбцы transaction_sequence_num или first_snapshot_sequence_num в представлении содержат меньшее число, чем последняя транзакция, выполненная операцией сжатия (109). В этом случае операция сжатия будет ждать завершения этих транзакций.

Разрешить эту проблему можно одним из следующих способов.

  • Прервите выполнение транзакции, которая блокирует операцию сжатия.
  • Прервите операцию сжатия. Вся завершенная работа будет сохранена.
  • Пока операция сжатия ожидает завершения блокирующей транзакции, ничего делать не нужно.

Разрешения

Необходимо быть членом предопределенной роли сервера sysadmin или предопределенной роли базы данных db_owner .

Примеры

A. Сжатие базы данных и определение количества свободного пространства в процентах

В следующем примере уменьшается размер файлов данных и журнала в пользовательской базе данных UserDB с целью освободить 10 процентов свободного пространства в базе данных.

DBCC SHRINKDATABASE (UserDB, 10);  
GO  

Б. Усечение базы данных

В следующем примере файлы данных и журнала в образце базы данных AdventureWorks сжимаются до последнего выделенного экстента.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);  

В. Сжатие базы данных Azure Synapse Analytics

DBCC SHRINKDATABASE (database_A);
DBCC SHRINKDATABASE (database_B, 10); 

См. также раздел

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Сжатие базы данных