Изменение коллекции XML-схем - огромный удар по производительности

Question

Я вижу огромный скачок производительности в нашем корпоративном приложении при изменении коллекции XML-схем для данного столбца в большой таблице. Проще говоря, мы делаем что-то вроде этого:

ALTER TABLE HugeTable ALTER COLUMN CustomFields XML 

(примечание: CustomFields ранее был привязан к XML (CustomFieldsSchemaCollection, но, конечно, нам нужно изменить эту XML-схему, поэтому нам нужен этот оператор, чтобы эту схему можно было изменить)

И затем, после изменения CustomFieldSchemaCollection, мы делаем это:

ALTER TABLE HugeTable ALTER COLUMN CustomFields XML(CustomFieldSchemaCollection)

Первое утверждение занимает 8 минут, а второе - 10 минут.

Мы обнаружили, что можем немного оптимизировать первый оператор (повышение производительности на 50%), используя следующее:

ALTER TABLE HugeTable ALTER COLUMN CustomFields nvarchar(max)

В результате первое утверждение занимает 4 минуты, а второе - 10 (то есть 14 минут вместо 18).

Суть вопроса в том ... Есть ли способ сделать эту «повторную привязку схемы XML» (или как там ее называют) таким образом, чтобы избежать абсолютно ненужной и избыточной проверки SQL Server каждого значения в столбце? (Примечание: да, мы можем с уверенностью предположить, что существующие данные XML в этой таблице будут соответствовать новой коллекции XML-схем.)

Спасибо всем, кто может помочь!

Answer 1

Если время действительно является большой проблемой (что при однократном обновлении не должно иметь большого значения), можете ли вы просто удалить базовые данные, выполнить повторную привязку к новой схеме, а затем выполнить массовую вставку, поворачивая все выдает идентификационную вставку и т.д ...?

Или для супершагового сценария напишите скрипт, который выполняет следующие действия в виде пакетов:

1. Измените таблицу и добавьте новый столбец XML с новой схемой
   связывание
2. Установить новые данные столбца = новые старые данные столбца
3. Оставьте старый столбец.
4. Переименуйте новый столбец в старое имя столбца.
5. При необходимости измените ординальность (другая тема ... И если не написаны все ваши потребляющие запросы) безопасно указав имена столбцов вместо того, чтобы полагаться на
   базовая ординальность)