Внесение структурных изменений в очень большие таблицы в онлайн-среде

Question

Итак, вот с чем я столкнулся.

Проблема

• Большая таблица с ~ 230 000 000 строк.
• Мы хотим изменить индекс кластеризации и первичный ключ этой таблицы на простое поле идентификатора bigint.В таблицу добавлено еще одно пустое поле для использования в будущем.
• Существующая таблица имеет составной ключ.Ради аргумента, скажем, это 2 Bigint's.Первый может иметь 1 или 10000 «детей» во второй части ключа.

Требования

• Минимальное время простоя, как предпочтительновремя, необходимое для запуска SP_Rename.
• Существующие строки могут измениться во время копирования данных.Обновления должны быть отражены в новой таблице.

Идеи

1. Установить триггер на существующей таблице, чтобы обновить строку в новой таблице, если онауже существует там.
2. Итерация по исходной таблице, копирование данных в новую таблицу ~ 10000 за раз.Может быть 2000 из первой части старого ключа.
3. Когда копирование будет завершено, переименуйте старую таблицу в «ExistingTableOld», а новую - из «NewTable» в «ExistingTable».Это должно позволить хранимым процессам продолжать работу без вмешательства

Есть ли в плане какие-либо явные упущения или лучшие практики, которые я игнорирую?

Answer 1

Мой опыт внесения больших изменений в схему заключается в том, что большие изменения лучше всего выполнять во время технического обслуживания - ночью / в выходные дни - когда пользователи загружаются из системы.Так же, как работает dbcc checkdb с опцией восстановления.Затем, когда дела пойдут на юг, у вас есть возможность откатиться до полной резервной копии, которую вы предварительно сделали непосредственно перед началом обновления.

Элемент № 3 в вашем списке: Переименование старого/ новые таблицы.Возможно, вы захотите перекомпилировать хранимые процедуры / представления.Мой опыт показывает, что планы выполнения связаны с идентификаторами объектов, а не с именами объектов.

Рассмотрим таблицу dbo.foo: если она переименована в dbo.foo_old, любые хранимые процедуры или пользовательские функции не обязательноошибка, пока зависимый объект не будет перекомпилирован и его план выполнения не восстановлен.Кэшированные планы выполнения продолжают отлично работать.

sp_recompile - ваш друг.

Answer 2

Сложная проблема.Ваш план звучит хорошо, но я не совсем уверен, что вам действительно нужно пакетировать запрос, если вы выполняете его на уровне изоляции транзакции READ UNCOMMITTED, чтобы остановить генерацию блокировок.