Лучший способ обновить схему таблиц для огромных таблиц (SQL Server) - PullRequest
4 голосов
/ 11 декабря 2008

У меня есть несколько огромных таблиц в производственной БД SQL 2005, которые нуждаются в обновлении схемы. В основном это добавление столбцов со значениями по умолчанию и некоторые изменения типа столбцов, которые требуют некоторого простого преобразования. Все это можно сделать с помощью простого «SELECT INTO», где целью является таблица с новой схемой.

Наши тесты пока показывают, что даже эта простая операция, выполненная полностью внутри сервера (без извлечения или передачи каких-либо данных), может занять часы, если не дни, для таблицы с миллионами строк.

Есть ли лучшая стратегия обновления для таких таблиц?

edit 1: Мы все еще экспериментируем без окончательного заключения. Что произойдет, если одно из моих преобразований в новую таблицу будет включать слияние каждых пяти строк в одну. Существует некоторый код, который должен выполняться при каждом преобразовании. Наивысшая производительность, которую мы могли получить при этом, позволила нам получить скорость, которая займет не менее нескольких дней для преобразования таблицы 30M строк

Будет ли в этом случае использование SQLCLR (преобразование кода выполняется внутри сервера) значительно увеличить скорость?

Ответы [ 5 ]

3 голосов
/ 11 декабря 2008

Вы пытались использовать alter table вместо перемещения данных в новую таблицу? Почему бы вы не использовали Select в? Просто измените свою текущую структуру.

3 голосов
/ 11 декабря 2008

У нас похожая проблема, и я обнаружил, что самый быстрый способ сделать это - экспортировать данные в файлы с разделителями (кусками - в зависимости от размера строк - в нашем случае каждый файл имеет 500 000 строк) Выполните любые преобразования во время экспорта, удалите и заново создайте таблицу с новой схемой, а затем выполните импорт bcp из файлов.

Использование таблицы 30 миллионов строк заняло пару часов, тогда как изменение таблицы заняло более 30 часов.

3 голосов
/ 11 декабря 2008

Применяете ли вы индексы сразу или на втором этапе? Должен идти намного быстрее без индексации во время сборки.

0 голосов
/ 11 декабря 2008

У меня похожая проблема звучания, которая встречается довольно часто.

Наша база данных кэширует результаты удаленной хранимой процедуры, которая иногда расширяется новыми полями.

Эта таблица содержит миллионы строк (а теперь и до 80 полей) с парой индексов и с таблицами #temp и т. Д. (Даже используя bcp для временных файлов); Я использую опцию выбора в новой таблице:

  • создать новую таблицу с новой структурой
  • сделать выбор в эту таблицу
  • бросить оригинал
  • переименовать новую таблицу в имя старой
0 голосов
/ 11 декабря 2008

Добавьте столбец с разрешением null, затем выполните обновление до значения по умолчанию вручную, а затем измените таблицу, чтобы добавить значение по умолчанию. Таким образом, вы можете контролировать обновления и делать их небольшими порциями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...