Чому статус "DbccFilesCompact" "Призупинено"?

Я запускаю файл SHRINK у файлі даних 600G.

Наразі статус повідомляється як "призупинено", а sys.dm_exec_requests.percent_completeдля DbccFilesCompactкомандних звітів він працює (але дуже повільно)

Чи є спосіб перевірити, чому його призупинено, і як зробити його більш плавним?

FYI - 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 управління некластеризованими індексами змінилося з механізму зберігання даних (моя команда) на процесор запитів. Це багато побічних ефектів, один з яких - швидкість, з якою стискання сторінок купи можна переміщувати за допомогою зменшення. Усі записи некластеризованого індексу містять зворотну посилання до запису даних, який вони індексують - у випадку купи це фізичне посилання на номер запису на певній сторінці даних. Коли сторінка даних у купі переміщується зі зменшенням, усі некластеризовані записи індексу, які мають зворотну посилання на записи на цій сторінці, повинні бути оновлені новим розташуванням сторінки. У 2000 році це було зроблено дуже ефективно самим двигуном зберігання даних. З 2005 року це потрібно зробити, зателефонувавши Процесору запитів для оновлення некластеризованих записів індексу. Це іноді в 100 разів повільніше, ніж у 2000 році.

2) Значення LOB поза рядками (фактичні типи даних LOB або дані про переповнення рядків) не містять зворотної посилання на запис даних або запис індексу, до складу якого вони входять. При переміщенні сторінки записів LOB всю таблицю або індекс, до якого вони входять, необхідно відсканувати, щоб з'ясувати, який запис даних / індекс вказує на них, щоб вони могли бути оновлені новим розташуванням. Це теж дуже, дуже повільно.

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

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

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 SP1, і один із способів я можу сказати про перебіг команди Shrink - виконанням sp_lock spid, і здебільшого я бачу, що він ставить замок у файл 1, а тоді, коли це зроблено, він розміщує заблокувати ідентифікатор файлу 2, і так далі, і таким чином я можу сказати, коли він працює над останнім ідентифікатором файлу, і це мій показник, який майже завершений.

Дякую,

Олексій Агілар

Я виявив, в чому проблема (в моєму випадку) і пропоную тут рішення, яке я використав.

Я нічого не використовував базу даних, а майстер був базою даних за замовчуванням на моєму сеансі, я перевірив, що використовуючи sp_who2. Потім я клацнув правою кнопкою миші на базі даних, вибрав "завдання", а потім "зменшити" і на "ок" діалогове вікно. Знову перевіривши програму sp_who2, статус "призупиняється" на кілька хвилин, після чого переривається, оскільки "не може бути отримано жодного ексклюзивного блокування". Вгадайте самі, але я впевнений, що саме діалог саме той, що викликає це.

Тому я вирішив перейти через командний рядок, використовуючи:

DBCC SHRINKDATABASE (myDataBase)

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