TSQL, обновляющий большую таблицу с другой из TEMPDB, вызывает огромный рост

У меня есть собственный инструмент импорта, который массово вставляет данные в темп (421776 строк). После этого инструмент вставляет неизвестные строки в целевую таблицу и обновляет существующие строки на основе хеш-ключа (комбинации двух столбцов). Целевая БД имеет почти такое же количество строк. Запрос на обновление выглядит примерно так (примерно на 20 столбцов обновления меньше)

  update targetTable set 
        theDB.dbo.targetTable.code=temp.code,
        theDB.dbo.targetTable.name=temp.name,
  from [tempDB].[dbo].[targettable] as temp 
  where theDB.dbo.targetTable.hash=temp.hash COLLATE SQL_Latin1_General_CP1_CI_AS

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

Просто примечание для тех, кто сталкивается с проблемами tempdb. Хорошо читать http://bradmcgehee.com/wp-content/uploads/presentations/Optimizing_tempdb_Performance_chicago.pdf


database import tsql tempdb
person Casper Broeren    schedule 03.05.2011    source источник
comment
Что растет до 21 Гб? Файл данных или файл журнала? Как выглядит план запроса? Используете ли вы изоляцию моментальных снимков на theDB?   -  person Martin Smith    schedule 03.05.2011
comment
tempdb растет на 21db. План запроса я сейчас исследую. Также я пытаюсь отключить изоляцию моментальных снимков для the theDB, так как весь процесс похож на «запустил и забыл». Спасибо!   -  person Casper Broeren    schedule 04.05.2011
comment
План запроса не показывает каких-либо аномальных планов или подсказок по оптимизации. Что-нибудь, что мне нужно проверить? Кроме того, переписанный оператор обновления с соединением a where in не имеет хороших улучшений.   -  person Casper Broeren    schedule 04.05.2011

Ответы (3)


arrow_upward
0
arrow_downward

Похоже, вы явно используете tempdb с данными, которые вы туда поместили. Есть ли причина использовать tempdb, как если бы это была ваша собственная база данных?

Причина, по которой tempdb растет, заключается в том, что вы явно помещаете туда данные. 420 тыс. строк не кажутся тяжелыми, но лучше оставить их в пределах собственной пользовательской базы данных.

Предложите изменить свою бизнес-логику, чтобы перейти от [tempDB].[dbo].[targettable] к чему-то в вашей собственной пользовательской базе данных.

person p.campbell    schedule 03.05.2011
comment
Причина для tempdb заключается в том, что нам нужно было вставить данные в облегченную таблицу, которую всегда можно удалить или отозвать. Фактические данные, которые являются новыми или обновленными, помещаются в фактическую таблицу базы данных. После завершения импорта база данных tempdb снова сжимается. Мы не можем делать такие вещи с целевой базой данных (или без снижения производительности). - person Casper Broeren; 03.05.2011

arrow_upward
0
arrow_downward

Вы можете временно изменить ведение журнала транзакций с полного или массового на простое. Это предотвратит ведение журнала для отката.

person chuchu    schedule 03.05.2011
comment
ОП говорит о tempdb. Даже если предположить, что они говорят о журналах, а не о файле данных, который всегда находится в простой модели восстановления. - person Martin Smith; 03.05.2011
comment
Это правильно. Временная и целевая базы данных имеют простые планы резервного копирования. - person Casper Broeren; 03.05.2011

arrow_upward
0
arrow_downward

Является ли это декартовым произведением, когда нет явного соединения?

person Tim    schedule 03.05.2011
comment
№ update targetTable set ... from [tempDB].[dbo].[targettable] as temp where theDB.dbo.targetTable.hash=temp.hash COLLATE SQL_Latin1_General_CP1_CI_AS совпадает с inner join on theDB.dbo.targetTable.hash=temp.hash COLLATE ... - person Martin Smith; 03.05.2011