Я использую файл SHRINK для файла данных 600 ГБ.
В настоящее время статус отображается как «приостановлено» и 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 году это было очень эффективно сделано самим Storage Engine. Начиная с 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 и так далее, и таким образом я могу сказать, когда он работает с последним идентификатором файла, и это мое указание, что оно почти завершено.
Спасибо,
Алекс Агилар
Я обнаружил, в чем была проблема (в моем случае), и предлагаю здесь решение, которое использовал.
У меня ничего не было с базой данных, и master была базой данных по умолчанию в моем сеансе, я проверил это с помощью sp_who2. Затем я щелкнул правой кнопкой мыши по базе данных, выбрал «задачи», затем «сжать» и на «ОК» диалоговое окно. После повторной проверки с помощью sp_who2 статус будет «приостановлен» на несколько минут, а затем отменен, поскольку «монопольная блокировка невозможна». Угадайте сами, но я уверен, что причиной этого является сам диалог.
Поэтому я решил использовать командную строку, используя:
DBCC SHRINKDATABASE (myDataBase)
(Ведьма везде документирована) Тогда усадка заняла буквально несколько секунд.