Задача 101.51722

Задача :101.51722

Краткое описание :
Зависание при объединении МОЛ (долгая обработка таблицы MnAnal)
Описание :
Объединение МОЛ
Что измененно :

Замечена следующая проблема: запускается объединение 2 МОЛ в одного. 96% прогресса проходят нормально и довольно быстро, далее начинается обработка таблицы MnAnal, которая не заканчивается, переходя в зависание.

При формировании смартлога:
При первом запуске через некоторое время база зависла и вылетела.
При повторном запуске было предложено продолжить объединение МОЛ, оно шло дольше обычного - около 3 часов, дальше пошла обработка
таблицы MnAnal, приложение зависло и логи перестали формироваться.
----------------------------
на последних патчах (Атлантис 5.4.42) "Объединение МОЛ" оста-
новился на табличке repmove. в профайлере (ms sql 2008 r2) идут
exec NT000000000000000000000000194H 0x8001000000000AB0
exec ML0000000000000000000000000YIX 0x8001000000000001
в первой строчке - перебор нреков (вторая - не меняется)
сама табличка - пустая (0 записей).

Точно такая же ситуация возникает при использовании "Объединение каталога АТД":
та же табличка - такое же зависание Галактики.


1. на старых патчах vip 5.4.40.1, дата - 10/01/2012 (извини, что нашел) объединение каталога АТД прошло быстро
Протокол по времени объединения каталога АТД.
----------------------T---------------------T---------------¬
¦ Объединяемый ¦ Объединяющий ¦ Время ¦
¦ ¦ ¦ объединения ¦
+---------------------+---------------------+---------------+
¦ 8 Марта ул ¦ 8 Марта ул ¦ 00:00:37:48 ¦
+---------------------+---------------------+---------------+
¦ Общее время объединения для ¦
¦ 8 Марта ул 00:00:37:48 ¦
+-----------------------------------------------------------+
¦ Общее время объединения 00:00:37:48 ¦
L------------------------------------------------------------
2. На той же базе и тех же данных при vip 5.4.42 - 12/03/2013 галактика задумалась на 4.5 часа (потом была снесена)
в профайлере SQL по очереди выполнялись процедуры:

create proc [dbo].[ML0000000000000000000000000YIX](@P0 BINARY(8)) AS
SELECT T_0.F$NREC,T_0.Sys#UL,T_0.F$WOBJ,T_0.F$WKAU#1#,T_0.F$WKAU#2#,T_0.F$WKAU#3#,T_0.F$WKAU#4#,T_0.F$WKAU#5#,T_0.F$WKAU#6#,T_0.F$WKAU#7#,T_0.F$WKAU#8#,T_0.F$WKAU#9#
FROM T$SALDTUNE T_0 WHERE T_0.F$NREC=@P0 OPTION(FAST 10) return 0
GO

и

create proc [dbo].[NT0000000000000000000000001E6R](@P0 BINARY(8))
AS SELECT T_0.F$NREC,T_0.Sys#UL,T_0.F$CSALDTUNE,T_0.F$COBJ,T_0.F$CKAU#1#,T_0.F$CKAU#2#,T_0.F$CKAU#3#,T_0.F$CKAU#4#,
T_0.F$CKAU#5#,T_0.F$CKAU#6#,T_0.F$CKAU#7#,T_0.F$CKAU#8#,T_0.F$CKAU#9#
FROM T$SPECMTR T_0 WITH (INDEX=T$SPECMTR0) WHERE (T_0.F$NREC>@P0) ORDER BY T_0.F$NREC OPTION(FAST 10) return 0
GO

протекта, журнализации нет, checjsql - выполнен

3. На ночь было запущено объединение МОЛ с использованием SmartTimeProtocols
за 17 часов собралось порядка 200 гигов логов. Потом выполнение снесли.
процедурки повторились из вчерашнего поста.


4. у клиента аналогичная п.п. 3 процедура не проходит за 60 часов.
5. Прогнал объединение МОЛ на старых патчах
Протокол по времени объединения МОЛ
----------------------T---------------------T---------------¬
¦ Объединяемый ¦ Объединяющий ¦ Время ¦
¦ ¦ ¦ объединения ¦
+---------------------+---------------------+---------------+
¦ Абрамов Анатолий ¦ Абрамов Анатолий ¦ 00:02:11:27 ¦
¦ Алексеевич ¦ Алексеевич ¦ ¦
+---------------------+---------------------+---------------+
¦ Общее время объединения для ¦
¦ Абрамов Анатолий Алексеевич 00:02:11:27 ¦
+-----------------------------------------------------------+
¦ Общее время объединения 00:02:11:27 ¦
L------------------------------------------------------------
Как измененно :

Исправлена ошибка программирования

Название продукта Название компонента Тип Последняя версия Дата выхода
C_JOINC_JOINRES9.1.007.0
C_JOINC_JOINRES9.1.7.0