Поделиться через

DBCC SHRINKDATABASE (Transact-SQL)

  • Статья

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

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

Примечание.

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

Соглашения о синтаксисе 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

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

NOTRUNCATE

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

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

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

TRUNCATEONLY

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

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

WITH NO_INFOMSGS

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

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

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

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

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

  • Нельзя задать значение NONE для параметра ABORT_AFTER_WAIT.

WAIT_AT_LOW_PRIORITY

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

Если новая операция сжатия в WAIT_AT_LOW_PRIORITY режиме не может получить блокировку из-за длительного запроса, операция сжатия в конечном итоге будет истекать через 1 минуту по умолчанию и завершится без ошибки. Это произойдет, если операция сжатия не может получить блокировку Sch-M из-за параллельных запросов или запросов, содержащих блокировки Sch-S. По истечении времени ожидания в журнал ошибок SQL Server будет отправлено сообщение об ошибке 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. На этом этапе можно просто повторить операцию сжатия в WAIT_AT_LOW_PRIORITY режиме, зная, что не будет влияния на приложение.

ABORT_AFTER_WAIT = [ SELF | BLOCKERS ]

  • SELF

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

  • BLOCKERS

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

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

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

Имя столбца Description
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

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

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

При указании WAIT_AT_LOW_PRIORITY запрос блокировки sch-M операции сжатия будет ждать с низким приоритетом при выполнении команды в течение 1 минуты. Если операция заблокирована в течение длительности, будет выполнено указанное ABORT_AFTER_WAIT действие.

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

Операции сжатия баз данных и файлов в настоящее время находятся в предварительной версии для База данных SQL Azure гипермасштабирования. Дополнительные сведения о предварительной версии см. в разделе "Сжатие" для База данных SQL Azure гипермасштабирования.

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

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

  • В настоящее время столбцы с использованием бизнес-типов данных (varbinary(max), varchar(max)и nvarchar(max)) в сжатых сегментах columnstore не затрагиваются DBCC SHRINKDATABASE иDBCC SHRINKFILE.

Как работает 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), пока не завершат свои операции. При попытке освободить место во время регулярного использования операции сжатия базы данных и сжатия файлов в настоящее время требуют блокировки изменения схемы (Sch-M) при перемещении или удалении страниц карты распределения индекса (IAM), блокируя блокировки Sch-S, необходимые для пользовательских запросов. В результате длительные запросы блокируют операцию сжатия до завершения выполнения запросов. Это означает, что все новые запросы, требующие блокировок Sch-S, также помещаются в очередь за операцией сжатия в ожидании, и кроме этого, они будут заблокированы, что еще больше усугубит эту проблему параллелизма. Это может значительно повлиять на производительность запросов приложений, а также вызвать трудности при выполнении необходимого обслуживания для сжатия файлов базы данных. Представленная в SQL Server 2022 (16.x), функция сжатия с низким приоритетом (WLP) решает эту проблему, принимая блокировку изменения схемы в WAIT_AT_LOW_PRIORITY режиме. Дополнительные сведения см. на странице WAIT_AT_LOW_PRIORITY с операциями сжатия.

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

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

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

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

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

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

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

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

Разрешения

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

Примеры

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

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

DBCC SHRINKDATABASE (UserDB, 10);
GO

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

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

DBCC SHRINKDATABASE (AdventureWorks2022, TRUNCATEONLY);

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

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

D. Сжатие базы данных с помощью WAIT_AT_LOW_PRIORITY

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

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

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