Додавання стовпців до виробничих таблиць

Який найкращий спосіб додати стовпці до великих виробничих таблиць на SQL Server 2008 R2? Згідно з книгами Microsoft в Інтернеті:

Зміни, зазначені в ALTER TABLE, вводяться негайно. Якщо для змін потрібні зміни рядків у таблиці, ALTER TABLE оновлює рядки. ALTER TABLE отримує блокування модифікації схеми на столі, щоб переконатися, що під час зміни немає інших посилань на посилання навіть на метадані для таблиці, за винятком онлайнових операцій з індексом, які потребують дуже короткого блокування SCH-M в кінці.

(http://msdn.microsoft.com/en-us/library/ms190273.aspx)

На великому столі з мільйонами рядків це може зайняти деякий час. Є вихід з експлуатації єдиним варіантом? Який найкращий спосіб вирішити подібну ситуацію?

"Це залежить"

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

Наприклад, додавання int або char вимагає фізичних рухів рядків. Додавання змінного варшара без типових налаштувань не повинно (якщо тільки растровий файл NULL не потрібно розширювати)

Вам потрібно спробувати його на відновленій копії виробництва, щоб отримати оцінку

Створення нової таблиці, копіювання, перейменування може зайняти більше часу, якщо вам доведеться повторно додавати індекси та ключі в таблиці мільярдів рядків.

Я змінив мільярдні таблиці рядків, які потребували декількох секунд, щоб додати нульовий стовпець.

Я сказав, щоб спершу взяти резервну копію?

Якщо стовпець NULLable, вплив повинен бути незначним. Якщо стовпець не може бути NULL і значення потрібно встановити, то воно може бути зовсім іншим. Що я б робив у цьому випадку, це замість того, щоб додавати ненулеві обмеження та обмеження за замовчуванням в один кадр, ефективно додаючи дані до кожного рядка:

• додайте стовпчик як NULLable - у більшості випадків має бути швидким
• оновити значення за замовчуванням
  • Ви можете це зробити партіями, якщо це необхідно
  • Ви також можете використовувати це для застосування умовної логіки, де деякі рядки можуть не отримати за замовчуванням
• додати ненульові / за замовчуванням обмеження
  • це буде швидше, коли жодна з даних не буде NULL, але все ж повинна бути вимірюваною

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

Чи вважали ви:

1. Створення нової таблиці, яка включає зміни у визначенні таблиці.
2. Вставлення в нове визначення таблиці, вибране з вихідної таблиці.
3. Перейменування оригінальної таблиці на _orig, а потім перейменування нової таблиці у вихідну назву таблиці.

Недоліком тут є те, що вам потрібно мати достатньо місця в базі даних, щоб зробити цю зміну. Ви все ще можете вимагати блокування читання на столі, щоб запобігти будь-якому брудному читанню.

Однак ви мінімізуєте вплив на кінцевих користувачів, якщо є можливість або потреба одночасно отримати доступ до оригінальної таблиці. Він також повинен мінімізувати тривалість блокування.