SQL 2012: зависают запросы в SSIS

Дэр Пароль
Дата: 22.01.2013 11:36:59
Glory
Дэр Пароль
А ночью может висеть в состоянии RUNNING несколько часов.

Вы refresh то нажимаете ?
Или может не тот коннект смотрите ?


Вроде практики хватает, чтобы понять, что я смотрю :)
Glory
Дата: 22.01.2013 11:38:31
Дэр Пароль
Вроде практики хватает, чтобы понять, что я смотрю :)

И как RUNNING запрос может быть зависшим ?
Дэр Пароль
Дата: 22.01.2013 11:48:55
Glory,

скажем так - нет видимых причин, чтобы так долго выполнялся запрос. Я не понимаю, что в это время происходит, и почему. Поэтому и задал вопрос на форуме - в какую сторону копать.
Glory
Дата: 22.01.2013 11:52:36
Дэр Пароль
скажем так - нет видимых причин, чтобы так долго выполнялся запрос.

Возможно вы не увидели эти причины.
Например то, что запрос распараллелен и одна из нитей блокирована.
Или что запрос распределенный и блокирован на линкованном сервере.
И тп
Критик
Дата: 22.01.2013 12:10:59
Необновленная статистика и в результате кривые планы запросов?

У нас было такое, когда имелась весьма большая таблица, старая статистика говорила, что данных за [дата1, дата2] нет, а они уже были, и их было много, миллионы строк. В результате формировался план с LOOP-соединением вместо HASH. И расчет шел 5-8 часов вместо часа.
Дэр Пароль
Дата: 22.01.2013 12:30:39
Критик,

спасибо, но мы после переноса все индексы перестроили, статистику обновили. Попробуем еще раз везде пройтись заново.

У меня лично складывается мнение, что это либо SSIS себя так ведет, либо какой-то баг на системном уровне. Причем наиболее явно он проявляется при установке Desktop Experience для Win Server.
LogrusAS
Дата: 22.01.2013 13:21:33
В свое время, при написании программы на C# для некоторых запросов и при некоторых обстоятельствах обнаружил резкое ухудшение производительности по сравнению с выполнением такого же запроса в студии.
Зависело от погоды на Марсе. Обновление статистик, полная и избирательная реиндексация не помогали.

Причем именно поведение похожее на описанное.
Обычный SELECT с одним JOIN по первичному кластерному ключу.
Google прояснил, что проблема в драйвере ADO.
И в результате поиска рекомендаций, наблюдения за студией и т.д. выяснилось, что при подключении через ADO.NET рекомендуется также включить следующие параметры:
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON 
SET ANSI_NULL_DFLT_ON ON
SET ANSI_WARNINGS ON
SET ANSI_PADDING ON
SET ANSI_NULLS ON
SET CONCAT_NULL_YIELDS_NULL ON

Мне помогло.
Но не уверен, что SSIS не делает того же. Давно от него отказался по ряду причин.

Второе, что также многократно обсуждалось на форуме "OLAP и DWH" - не использовать подключения ADO.NET, а использовать OleDB. В нем не проявляется таких глюков.

Кроме того после миграции на 2012 нашего SSAS сервера возникла еще одна странная проблема.
Часть данных из SSAS пользователи получали через процедуру генерирующую MDX запрос и отправляющую его прилинкованому SSAS серверу. Начиная с 2005 это работало без проблем. В 2012 в случае если сервер был не локальный, то с вероятностью 50/50 запрос не выполнялся, с объяснениями о нехватке прав на SSAS куб. Причем даже для пользователя с неограниченными правами. Решили сначала установкой рядом с SSAS SQL сервера, единственной задачей которого было - быть локальным. Потом, после проблем с накаткой SP1 вообще откатились обратно на 2008 R2.


Так что мест, где могут быть проблемы много. Попробуйте проверить те что я назвал.
Дэр Пароль
Дата: 22.01.2013 13:57:39
LogrusAS,

спасибо, в своих SSIS-пакетах мы используем Native OLE DB.

Насчет проблем на 2012 - мы уже уткнулись в одну, связанную с массовой рассылкой отчетов на SSRS, которая работала без проблем на 2005. Из-за того, что невозможно изменить таймаут для рассылки при соединении с доменным почтовым сервером, пришлось городить конструкцию с локальным SMPT-сервером, ему подсовывать отчеты, которые в дальнейшем отправлялись уже на домен.

Но вот эти зависания ночью реально не дают нам спать...Каждое утро лотерея - прогрузились данные или опять они в состоянии RUNNING :)
Критик
Дата: 22.01.2013 14:34:00
LogrusAS, SET`ы также влияют на план.

Дэр Пароль, если у вас такое часто, то снимайте планы при успешной отработке и при неудаче. Сравнивайте.
Дэр Пароль
Дата: 28.06.2013 11:43:09
Причина оказалась в битом кабеле к дисковой библиотеке - это уже инженеры в логах оборудования откопали. Заменили, и теперь все работает как по-маслу :)