Я пытаюсь запустить dbcc shrinkfile кусками по 1 ГБ в базе данных, где 95% данных были заархивированы и удалены. Я с 235 ГБ файла, где 9 ГБ данных / индексов. Я хочу уменьшить это до 50 ГБ. Я знаю, что сжатие файлов базы данных - это плохо, это вызывает фрагментацию и т. Д. В рамках очистки / сжатия данных у нас также есть сценарий перестройки idnex.
Когда я запускаю сценарий dbcc shrinkfile для базы данных на собственной рабочей станции (четырехъядерный процессор, 12 ГБ ОЗУ, 2 диска SATA), сжатие занимает около 8-10 минут.
При выполнении идентичного кода для идентичной копии базы данных после очистки данных в нашем тестовом окружении (80+ ядер, 128 ГБ ОЗУ, SSD SAN) это занимает 70 минут. Отметим, что на момент запуска файла сжатия на этом сервере было мало активности. Он был запущен 4 раза с одинаковыми результатами.
Затем я выбрал другой подход - перенести оставшиеся 9 ГБ в другую файловую группу и физический файл. Запуск dbcc shrinkfile для пустого файла 230 ГБ, чтобы уменьшить его до 50 ГБ, на моей рабочей станции занимает <1 минуту.
При таком же подходе в среде тестирования это снова занимает более 70 минут.
Я сделал снимок ожидания до и после, согласно сценарию Брента Озара, во время 70-минутного прогона теста environemnt, и возвращенные типы ожидания показали, что ничего не о чем беспокоиться. Три верхние строки ниже:
Время второй выборки Длительность выборки в секундах wait_type Время ожидания (секунды) Число ожиданий в среднем мс за ожидание 2013-05-28 11: 24: 22,893 3600 WRITELOG 160,8 143066 1,1 2013-05-28 11: 24: 22,893 3600 CXPACKET 20,9 13915 1,5 2013-05-28 11: 24: 22,893 3600 PAGELATCH_EX 11,1 443038 0,0
Журнал событий Windows не показывает ничего необычного. Сейчас я начинаю царапать, почему на оборудовании ниндзя так много времени, по сравнению с моей автономной рабочей станцией.
sys.dm_os_latch_stats
@@versionна обоих