Почему статус «DbccFilesCompact» имеет статус «Приостановлено»?

Я использую файл SHRINK для файла данных 600G.

В настоящее время статус отображается как «приостановленный», а sys.dm_exec_requests.percent_completeдля DbccFilesCompactкомандных отчетов он работает (но очень медленно).

Есть ли способ проверить, почему он приостановлен и как сделать его более плавным?

К вашему сведению - SQL-запрос для проверки статуса

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

Нет, вы не можете проверить, почему он работает медленно, но я могу дать вам несколько советов:

1) В SQL 2005 управление некластеризованными индексами изменилось с Storage Engine (моя команда) на Query Processor. Это имеет много побочных эффектов, одним из которых является скорость, с которой страницы данных кучи могут перемещаться путем сжатия. Все записи некластеризованного индекса содержат обратную ссылку на запись данных, которую они индексируют - в случае кучи это физическая ссылка на номер записи на конкретной странице данных. Когда страница данных кучи перемещается с помощью сжатия, все записи некластеризованного индекса, которые имеют обратную ссылку на записи на этой странице, должны обновляться в соответствии с новым местоположением страницы. В 2000 году это было сделано очень эффективно самим механизмом хранения. В 2005 году это необходимо сделать, вызвав обработчик запросов для обновления записей некластеризованного индекса. Это иногда до 100 раз медленнее, чем в 2000 году.

2) Значения внеблоковых больших объектов (либо фактические типы данных больших объектов, либо данные переполнения строк) не содержат обратной ссылки на данные или индексную запись, частью которой они являются. При перемещении страницы записей больших объектов вся таблица или индекс, частью которых они являются, должны быть отсканированы, чтобы выяснить, какие записи данных / индекса указывают на них, чтобы их можно было обновлять с новым местоположением. Это тоже очень, очень медленно.

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

4) Возможно, вы включили изоляцию моментальных снимков, и shrink не может перемещать страницы со ссылками на хранилище версий, пока не завершены транзакции, требующие этих более старых версий.

5) Ваша подсистема ввода / вывода может быть недостаточно мощной. Длина очереди диска выше, чем младшие однозначные цифры, означает, что ваша узкая подсистема ввода / вывода.

Любые или все из них могут способствовать медленному времени усадки.

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

Надеюсь это поможет!

Вы можете запустить этот скрипт, чтобы проверить процент выполнения!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

Я сжимаю базу данных в SQL Server 2008 с пакетом обновления 1 (SP1), и я могу сказать, что выполнение команды Shrink выполняется путем выполнения sp_lock spid, и по большей части я вижу, что он устанавливает блокировку для файла 1, а затем, когда это делается, помещает заблокировать файл с идентификатором 2 и так далее, и таким образом я могу сказать, когда он работает с последним идентификатором файла, и это мое указание, которое почти завершено.

Спасибо,

Алекс Агилар

Я обнаружил, в чем была проблема (в моем случае), и я предлагаю здесь решение, которое я использовал.

У меня ничего не было, используя базу данных, и master был базой данных по умолчанию в моем сеансе, я проверил это с помощью sp_who2. Затем я щелкнул правой кнопкой мыши по базе данных, выбрал «задачи», а затем «сжать» и «ок» диалоговое окно. Повторная проверка с sp_who2, статус «приостанавливается» на несколько минут и после этого прерывается, потому что «исключительная блокировка не может быть получена». Угадайте себя, но я уверен, что именно диалог является тем, который вызывает это.

Поэтому я решил пройти через командную строку, используя:

DBCC SHRINKDATABASE (myDataBase)

(Ведьма везде задокументирована), Тогда сокращение заняло всего несколько секунд.