DBCC SHRINKDATABASE (Transact-SQL)

Область применения:SQL ServerБаза данных SQL AzureУправляемый экземпляр SQL AzureAzure Synapse AnalyticsБаза данных SQL в Microsoft Fabric

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

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

Соглашения о синтаксисе Transact-SQL

Синтаксис

Синтаксис для SQL Server:

DBCC SHRINKDATABASE
( database_name | database_id | 0
     [ , target_percent ]
     [ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH
    {
         [ WAIT_AT_LOW_PRIORITY
            [ (
                  <wait_at_low_priority_option_list>
             ) ]
         ]
         [ , NO_INFOMSGS ]
    }
]

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list>
      , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
  ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Синтаксис Для Azure Synapse Analytics:

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

Аргументы

{ database_name | database_id | 0 }

Название или идентификатор базы данных для уменьшения. Значение 0 указывает текущую базу данных.

целевой процент

Процент свободного пространства, оставленного в файле базы данных после завершения операции уменьшения.

Если указать target_percent с TRUNCATEONLY, операция уменьшения может не освободить свободное место в конце файла.

NOTRUNCATE

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

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

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

УСЕЧЬ ТОЛЬКО

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

Если указать target_percent с TRUNCATEONLY, операция уменьшения может не освободить свободное место в конце файла.

С NO_INFOMSGS

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

WAIT_AT_LOW_PRIORITY с операциями сжатия

Применяется к: SQL Server 2022 (16.x) и более поздним версиям, База данных SQL Azure, Управляемый экземпляр SQL Azure, SQL базе данных в Microsoft Fabric

Функция ожидания при низком приоритете снижает борьбу за блокировку во время операции уменьшения. Дополнительные сведения см. в разделе Основные сведения о проблемах параллелизма в DBCC SHRINKDATABASE.

Эта функция похожа на WAIT_AT_LOW_PRIORITY с операциями индексирования в режиме "в сети", с некоторыми различиями.

  • Вы не можете указать ABORT_AFTER_WAIT опцию NONE.
  • Ты не можешь настроить эту MAX_DURATION опцию. Тайм-аут блокировки низкого приоритета для операции по уменьшению всегда составляет одну минуту.

ОЖИДАНИЕ_С_НИЗКИМ_ПРИОРИТЕТОМ

Когда команда уменьшения выполняется в WAIT_AT_LOW_PRIORITY режиме, запросы, требующие блокировки стабильности схемы (Sch-S) на страницах Index Allocation Map (IAM ), не блокируются операцией уменьшения. Однако операция уменьшения может быть заблокирована блокировкой Sch-S на странице IAM. Shrink продолжает выполняться только тогда, когда сможет получить блокировку изменения схемы (Sch-M) на необходимой IAM-странице.

Если операция уменьшения в WAIT_AT_LOW_PRIORITY режиме не может получить этот блокировку из-за длительного запроса, удерживающего Sch-S блокировку, операция уменьшения времени заканчивается с ошибкой 49516, например: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ SELF | БЛОКИРОВЩИКИ ] }

  • SELF

    SELF — параметр по умолчанию. Выйдите из операции уменьшения базы данных, выполняемой в данный момент, не предпринимая дальнейших действий.

  • BLOCKERS

    Остановить все пользовательские транзакции, в данный момент блокирующие операцию сжатия файла, чтобы можно было продолжить данную операцию. Для этой BLOCKERS опции требуется, чтобы у входа ALTER ANY CONNECTION был доступ к OR KILL DATABASE CONNECTION .

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

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

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

Примечание.

ядро СУБД не отображает строки для файлов, которые не уменьшаются.

Замечания

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

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

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

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

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

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

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

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

В SQL-пулах Azure Synapse избегайте запуска команды уменьшения, так как это операция, требующая интенсивного ввода-вывода, которая может отключить ваш выделенный SQL-пул (ранее SQL DW). Эта команда также влияет на стоимость снимков вашего хранилища данных.

Известные проблемы

Применяется к: SQL Server, Azure SQL SQL Database, Управляемый экземпляр SQL Azure, Azure Synapse Analytics — выделенный SQL-пул

  • В SQL Server 2022 (16.x) и более ранних версиях страницы, используемые типами столбцов LOB (varbinary(max), varchar(max) и nvarchar(max)) в сжатых сегментах columnstore, нельзя перемещать по DBCC SHRINKDATABASE и DBCC SHRINKFILE. Дополнительные сведения см. в статье "Новые возможности индексов columnstore".

Как работает DBCC SHRINKDATABASE

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

Предположим, что у вас есть два лог-файла и один файл данных в базе данных под названием mydb. Каждый файл данных и журнала имеет размер 10 МБ, а файл данных содержит 6 МБ данных. Ядро СУБД вычисляет целевой размер для каждого файла. Это значение — целевой размер файла после уменьшения. Когда вы задаёте DBCC SHRINKDATABASE с помощью target_percent, ядро СУБД вычисляет размер цели как target_percent свободного пространства в файле после уменьшения.

Например, если указать target_percent 25 для сжатияmydb, ядро СУБД вычисляет целевой размер файла данных размером 8 МБ (6 МБ данных плюс 2 МБ свободного места). Таким образом, ядро СУБД перемещает все данные из файла данных за последние 2 МБ в любое свободное место в первом 8 МБ файла данных, а затем сжимает файл.

Предположим, что файл mydb данных содержит 7 МБ данных. При задании значения 30 для target_percent можно сжать этот файл данных до 30 %. Однако указание target_percent 40 не сжимает файл данных, так как в текущем общем размере файла данных не удается создать достаточно свободного места.

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

Для файлов журнала ядро СУБД используетtarget_percent, чтобы вычислить целевой размер всего журнала. Вот почему target_percent — это количество свободного пространства в журнале после операции сжатия. Целевой размер всего журнала затем пересчитывается в целевой размер каждого файла журнала.

DBCC SHRINKDATABASE пытается немедленно уменьшить размер каждого физического журнала до целевого размера. Если ни одна часть логического журнала не остаётся в виртуальных логах сверх целевого размера файла, DBCC SHRINKDATABASE файл успешно урезает и заканчивается без сообщений. Однако если часть логического журнала остается в виртуальных журналах за пределами целевого размера, ядро СУБД освобождает максимальное пространство, а затем выдает информационное сообщение. В сообщении описываются действия по переносу логического лога из виртуальных логов в конце файла. После выполнения действий используйте DBCC SHRINKDATABASE для освобождения оставшегося пространства.

Вы можете уменьшить файл журнала только до границы виртуального файла журнала. Вот почему уменьшить файл журнала до размера, меньшего размера виртуального файла журнала, невозможно. ядро СУБД динамически выбирает размер виртуального файла журнала при создании или расширении файлов журналов.

Общие сведения о проблемах параллелизма с DBCC SHRINKDATABASE

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

Например, пользовательский запрос может получить блокировку стабильности схемы (Sch-S) на странице Index Allocation Map (IAM) и хранить её до завершения. При попытке восстановить пространство при обычном использовании операции по уменьшению базы данных и уменьшению файлов требуют блокировки изменения схемы приSch-M перемещении или удалении страниц IAM, блокируя блокировки Sch-S , необходимые для пользовательских запросов. В результате длительные запросы могут блокировать операцию уменьшения. Такое поведение также означает, что любой новый запрос, требующий Sch-S блокировки на странице IAM, может стоять в очереди за операцией уменьшения, что ещё больше усугубляет проблему параллелизма.

Введённая в SQL Server 2022 (16.x), функция ожидания при низком приоритете для операций уменьшения решает эту проблему, принимая блокировку изменения схемы на страницах IAM в WAIT_AT_LOW_PRIORITY режиме. Дополнительные сведения см. на странице WAIT_AT_LOW_PRIORITY с операциями сжатия.

Для получения дополнительной информации о Sch-S блокировках Sch-M и блокировках см. руководство по блокировке транзакций и версионированию строков.

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

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

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

  • Большинство баз данных требуют некоторого свободного пространства для повседневных операций. Если вы многократно уменьшаете файл базы данных и заметите, что размер базы данных снова увеличивается, это увеличение указывает на то, что обычные операции требуют свободного пространства. В таких случаях повторное уменьшение файла базы данных контрпродуктивно. Рост файла, необходимый для выделения нового пространства после уменьшения, может снизить производительность.

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

  • Если у вас нет конкретного требования, не устанавливайте опцию базы данных AUTO_SHRINK в значение ON.

  • Если нужно уменьшить файлы данных большой базы данных, рассмотрите возможность использования скрипта ShrinkDriver PowerShell. Скрипт автоматизирует и упрощает процесс уменьшения, превращая его в одну наблюдаемую и вособновляемую операцию. Скрипт сжимает несколько файлов параллельно, повторяет попытки при прерывании и выводит подробные отчёты о состоянии по мере запуска.

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

Транзакция, запущенная под уровнем изоляции с управлением версиями строк, может блокировать операции сжатия. Например, вы запускаетесь DBCC SHRINKDATABASE , пока идёт большая операция удаления под уровнем изоляции на основе версионизации строки. В этом случае операция уменьшения ждёт завершения операции удаления, прежде чем уменьшить файлы. Когда операция сжатия ожидает, 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 столбцы OR first_snapshot_sequence_num в sys.dm_tran_active_snapshot_database_transactions динамичном режиме управления содержат значение 15. transaction_sequence_num Столбец first_snapshot_sequence_num в представлении может содержать число, которое меньше последней транзакции, завершенной операцией сжатия (109). В этом случае операция сжатия ожидает завершения этих транзакций.

Чтобы решить проблему, можно сделать одно из следующих способов:

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

Разрешения

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

Примеры

Примеры кода в этой статье используют базу данных образца AdventureWorks2025 или AdventureWorksDW2025, которую можно скачать с домашней страницы образцов и проектов сообщества Microsoft SQL Server и.

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

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

DBCC SHRINKDATABASE (UserDB, 10);
GO

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

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

DBCC SHRINKDATABASE (AdventureWorks2025, TRUNCATEONLY);

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

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

Д. Уменьшить базу данных с помощью WAIT_AT_LOW_PRIORITY

В указанном ниже примере выполняется попытка уменьшить размер файлов данных и журнала в базе данных AdventureWorks2025 с целью освободить 20 % ее пространства. Если блокировка не может быть получена в течение одной минуты, операция сжатия прерывается.

DBCC SHRINKDATABASE ([AdventureWorks2025], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Связанный контент

  • Last updated on