Проблемы с производительностью при поиске

я столкнулся с ужасной проблемой с пакетами SSIS. В моих пакетах у меня есть один поиск, и у меня есть такое условие

OLEDB Source содержит около 400 000 записей, а таблица поиска содержит около 1 200 000 записей. Обе таблицы могут расти, но та, которая исходит из источника OLEDB, будет иметь максимум около 900 000. Обе таблицы имеют около 40-50 столбцов для поиска.

There are 51528912896 bytes of physical memory with 32689860608 bytes free. There are 4294836224 bytes of virtual memory with 249348096 bytes free. The paging file has 120246493184 bytes with 109932904448 bytes free.

есть ли эффективное решение для этого?


ssis lookup
person Zerotoinfinity    schedule 05.11.2012    source источник
comment
Какой режим кэширования вы используете?   -  person rvphx    schedule 06.11.2012
comment
Полный кеш. Я пробовал и с частичным кешем, но он перестал отвечать после 12 456 записей.   -  person Zerotoinfinity    schedule 06.11.2012
comment
Частичный кеш не принесет никакой пользы, если он не работает с полным кешем. К сожалению, нет обходных путей для поиска. Вы либо получаете производительность, либо нет. Значение (назначение), которое вы ищете, это индекс или что-то еще?   -  person rvphx    schedule 06.11.2012
comment
Вам действительно нужно 40-50 столбцов в этом поиске? В режиме частичного кэширования сколько памяти вы выделили для него.   -  person billinkc    schedule 06.11.2012
comment
Да, это требование бизнеса. Я не знаю, как выделить память для ssis или SQL... но я знаю, что это 48-гигабайтный сервер с 8-гигабайтной оперативной памятью.   -  person Zerotoinfinity    schedule 06.11.2012
comment
Прочтите эту статью, которая может помочь вам sqlblog.com/blogs/jamie_thomson/archive/2010/03/18/   -  person praveen    schedule 06.11.2012
comment
Если и источник, и таблица поиска находятся в одной базе данных. Мы можем использовать объединения, чтобы все операции поиска выполнялись на стороне сервера.   -  person Gowdhaman008    schedule 06.11.2012

Ответы (1)


arrow_upward
1
arrow_downward

В этом масштабе я бы рассмотрел возможность использования преобразования Merge Join вместо Lookup. Упорядочите по своим ключам в исходном коде SQL OLE DB и определите сортировку вручную (ссылка http://www.ssistalk.com/2009/09/17/ssis-avoiding-the-sort-components/ ). Хотя эта схема медленнее, чем поиск в кэше, она имеет тенденцию лучше масштабироваться с точки зрения использования памяти.

person Mike Honey    schedule 05.11.2012