Перш за все: скільки даних у таблиці? Кількість рядків та розмір таблиці?
По-друге: Чи можете ви створити резервну копію та відновити цю таблицю на тестовому сервері та запустити оператор alter, щоб побачити вплив (якщо припустити, що це неможливо з-за того, що таблиця занадто велика, щоб вміститись у невиробничу систему)? Я завжди вважаю, що тестування в моєму середовищі є більш точним, ніж поради з інтербетів, оскільки є кілька факторів, які можуть вплинути на результат, які можуть бути не надані в питанні просто через те, що не знаю, що ці фактори можуть вплинути на результат.
По-третє: збільшення розміру поля змінної довжини - це (припускаючи, що ви не перевищуєте обмеження 8060 байт) - проста операція з метаданими, оскільки жодні фактичні дані не зміняться для такої операції. Але, з іншого боку, зменшення розміру поля змінної довжини, навіть до чогось, що більш ніж очевидно спрацює, не є простою зміною метаданих, оскільки SQL Server не знає, перш ніж сканувати всі рядки , що нещодавно вимаганий розмір дійсний.
Отже: так, це заблокує стіл на певний проміжок часу . Скільки часу? Ну ось тест, який я щойно зробив:
Я мав, з деяких інших тестувань, таблицю з одним INT NOT NULLполем і 1 мільйон рядків. Я скопіював її в нову таблицю, щоб зробити цей тест через:
SELECT *, CONVERT(NVARCHAR(MAX), NEWID()) AS [StringField]
INTO dbo.ResizeTest
FROM dbo.ClusteredUnique;
Таким чином я починав з аналогічного сценарію наявності MAXполя (я щойно зрозумів, що ти є VARCHARі я використовую NVARCHAR, але це не повинно змінювати поведінку, яку я бачу), яку я міг би змінити 500. І в ньому є дані, які легко вміщаються в межах 500 символів. На це пішло кілька хвилин.
Я тоді побіг:
ALTER TABLE dbo.ResizeTest ALTER COLUMN [StringField] NVARCHAR(500) NULL;
І це зайняло трохи більше 11 хвилин.
Я просто повторно провела тест, на цей раз опустивши [ResizeTest]стіл і змінивши обидва NVARCHARs на справедливі VARCHAR, просто щоб бути впевненим, що я порівнюю яблука з чимось, що принаймні схоже на яблуко ;-).
Початкове створення таблиці зайняло 20 секунд, а ALTER TABLEзаняття - 2 хвилини.
Отже, з точки зору оцінки простоїв, це дуже важко зробити, оскільки це базується на швидкості введення / виводу диска, незалежно від того, чи потрібно проводити будь-які операції автоматичного зростання в файлі даних та / або в журналі транзакцій тощо. це, мабуть, значна частина, чому мій перший тест потребував 11 хвилин на зміну, а на другий, навіть не VARCHARмаючи половини розміру NVARCHARданих, знадобилося всього 2 хвилини (тобто файли були попередньо вирощені в цей момент). Але все-таки слід пам’ятати, що мій тест працює на моєму ноутбуці, який не є найшвидшим диском, але це також було всього 1 мільйон рядків з 2 невеликих стовпців (22 байти в ряд).
А оскільки ви запитали, що це зробить на сторінках даних, ось ваша відповідь. Я робив sp_spaceusedпісля створення таблиці, після того, як робив ALTER COLUMNі після цього робив ALTER TABLE dbo.ResizeTest REBUILD;. Результати (наступні номери засновані на другому тесті з використанням VARCHAR, а не на першому тесті з використанням NVARCHAR):
After initial table creation: 526,344 KB
After ALTER COLUMN VARCHAR(500): 1,031,688 KB <--- !! Yikes!!
After ALTER REBUILD: 526,472 KB
Якщо ви стурбовані необхідністю зберегти операцію якомога коротше, перегляньте статтю, яку я писав про те, щоб зробити саме це: " Реструктуруйте 100 мільйонів рядів (або більше) таблиць за секунди. SRSLY! (необхідна безкоштовна реєстрація).
ALTERредагував кожний стовпчик послідовно - кожна дія займала менше секунди. На той час, коли вони були зроблені, таблиця збільшилась удвічі в розмірі, але як тільки я зробилаREBUILDоперацію (що також було другою секундою), таблиця повернулася до свого початкового розміру.