Набор обновлений для 20+ миллионов строк?

Question

У меня есть таблица для каждого месяца в году, и в этой таблице (среди прочего) 25 столбцов для пользовательских данных. Только первые 8 столбцов данных индексируются, и мы вставляем данные в столбец 21, которые теперь хотят выполнять подстановочный поиск. Я не могу создать индекс для столбца 21, так как приложение не будет разрешать поиск по шаблону ни на чем, кроме первых 8 столбцов данных в их графическом интерфейсе.

Я попытался запустить следующее, но он был исчерпан, когда журнал транзакций был заполнен, с тех пор он изменил его на неограниченный рост, поскольку он был установлен на максимальный размер 134 ГБ.

UPDATE CentralContact.dbo.Spd_month_1 
SET p1_value = p21_value 
WHERE dbs_id ='190' 

Есть ли более быстрый способ сделать это, поскольку каждая таблица содержит более 20 миллионов записей?

Answer 1

Простейший способ сделать то, что вы хотите, вероятно, использовать виды. Во-первых, переименовать таблицу, а затем создать представление для munge столбцов:

sp_rename 'CentralContact.dbo.Spd_month_1 ', '_Spd_month_1' 

create view Spd_month_1 as 
    select p_col21 as p_col1, . . . 
    from _Spd_month_1; 

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

Проблема с вашим обновлением заключается в том, что каждая строка изменяется, поэтому каждая строка регистрируется. Это справедливо даже при минимальной возможности ведения журнала SQL Server. Один из способов решения этой проблемы - скопировать таблицу в другое место, усечь ее и снова вставить данные. Однако с 134 Гбайтами я попытался бы свести к минимуму любые операции перемещения данных.

Answer 2

Что вы, вероятно, захотите использовать, это чайник (или «ложка») из Пентахо. Проверьте это here.

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

Одна из вещей, которые она делает, - это массовое обновление. Вы можете выбрать весь набор записей, который будет обновлен, а затем передать его 1000 записей каждые несколько секунд, чтобы он обновил и зафиксировал. Таким образом, он не бесконечно блокирует стол.

Я использую это все время и никогда не советую использовать что-либо кроме этого метода при больших обновлениях в таблицах с интенсивным трафиком/большой нагрузкой.

Answer 3

20 миллионов строк не много строк, даже если вы работаете на ноутбуке. У меня есть тестовые таблицы с парой ста миллионов строк на моем Lenovo x1 (SSD + 8 ГБ ОЗУ). У моих серверов есть таблицы (не секционированные) с несколькими миллиардами строк.

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

1. Резервное копирование журнала транзакций, чтобы освободить место из всех предыдущих совершенных транзакций. Если вы еще этого не сделали, это, вероятно, самое лучшее, что нужно сделать сейчас. Просмотрите книги SQL Server онлайн для получения подробной информации о том, как это сделать. В 134 ГБ это довольно большой тэг, и если он автогрузится с момента создания, у вас, вероятно, слишком много виртуальных файлов журналов и много физической фрагментации - оба могут оказать значительное негативное влияние на производительность (если вы работаете на SSD, тогда физическая фрагментация ОК).Кроме того, каждый автошоу становится все хуже, потому что пространство Tlog должно быть инициализировано перед использованием, чтобы вы инициализировали большие и большие куски. Сильное рассмотрение вытирания tlog и воссоздание «разумного» размера с нуля, когда вы получаете окно обслуживания.

2. Переключить обновление на несколько небольших транзакций. Это может быть или не быть легким в зависимости от остальной части схемы. Если есть столбец с каким-то монотонным значением (например, отметка времени, дата, идентификатор, идентификатор и т. Д.), Вы можете легко обновлять диапазоны за раз. Также полезно иметь столбец с небольшим количеством уникальных значений. Просто будьте осторожны, вы не добавляете или не добавляете новые значения, пока вы делаете изменения. Если вы не работаете 24x7, блокировка БД в однопользовательском режиме для обновления и проверки - это самое простое, хотя и тяжелое решение.