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