Зависание пересчета склада на обновлении главной книги.

[kostass]

Всем доброго времени суток!

AX 3.0 SP6. Есть проблемы с огромной себестоимостью по некоторым номенклатурам. Поэтому занимаемся новым пересчетом и закрытием склада за два года. Делаем это в тестовой базе, что бы понять решит ли данное действие эту проблему или нет.
Периодически возникает ситуация, когда зависает пересчет склада при обновлении главной книги. В мониторе активности на сиквеле наблюдаю, что один из сеансов по пересчету заблокирован не существующим сеансом. Причем, все сеансы на сиквеле начинаются с идентификатора 51, а этот имеет идентификатор 21, и его нет в мониторинге.
Сеансы пересчета будут висеть заблокированные, пока их не завершишь. После этого делаю отмену пересчета. Запускаю его снова, и он пересчитывает нормально.

Запрос у заблокированного сеанса из мониторинга:
(@P1 varchar(1000),@P2 varchar(1000),@P3 int,@P4 int,@P5 varchar(1000),@P6 int,@P7 int)INSERT INTO INVENTCOSTLIST (ITEMID,VOUCHER,COSTNUM,NUMOFITERATION,DATAAREAID,RECVERSION,RECID) VALUES (@P1,@P2,@P3,@P4,@P5,@P6,@P7)

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

[fed]

Замечу лишь, что судя по тексту ждущего запроса, никакого отношения к разноске в ГК ситуация не имеет. На момент начала разноски в ГК все операции с inventCostList уже должны быть завершены.

Проблема в том, что многие операции во всяких мониторах (например тот же DBCC INPUTBUFFER), показывают не ждущий запрос, а последний скомпилированный.

Попробуйте исполнять следующий запрос:

select r.session_id,r.status,
 SUBSTRING(st.text, (r.statement_start_offset/2)+1, 
        ((CASE r.statement_end_offset
          WHEN -1 THEN DATALENGTH(st.text)
         ELSE r.statement_end_offset
         END - r.statement_start_offset)/2) + 1) AS statement_text,
r.blocking_session_id,r.wait_type,r.wait_resource,r.wait_time,DB_NAME(r.database_id),r.cpu_time,r.logical_reads,r.reads,r.writes,r.start_time,r.sql_handle,r.plan_handle
from sys.dm_exec_requests  r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
where sql_handle is not null

В поле statement_text показывается настоящий текст исполняемого запроса; Если Blocking_session_id не нулевое - значит этот запрос заблокироваи ждет другой сессии.

[kostass]

Цитата:

Сообщение от fed

Замечу лишь, что судя по тексту ждущего запроса, никакого отношения к разноске в ГК ситуация не имеет. На момент начала разноски в ГК все операции с inventCostList уже должны быть завершены.

Проблема в том, что многие операции во всяких мониторах (например тот же DBCC INPUTBUFFER), показывают не ждущий запрос, а последний скомпилированный.

Попробуйте исполнять следующий запрос:

select r.session_id,r.status,
 SUBSTRING(st.text, (r.statement_start_offset/2)+1, 
        ((CASE r.statement_end_offset
          WHEN -1 THEN DATALENGTH(st.text)
         ELSE r.statement_end_offset
         END - r.statement_start_offset)/2) + 1) AS statement_text,
r.blocking_session_id,r.wait_type,r.wait_resource,r.wait_time,DB_NAME(r.database_id),r.cpu_time,r.logical_reads,r.reads,r.writes,r.start_time,r.sql_handle,r.plan_handle
from sys.dm_exec_requests  r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
where sql_handle is not null

В поле statement_text показывается настоящий текст исполняемого запроса; Если Blocking_session_id не нулевое - значит этот запрос заблокироваи ждет другой сессии.

Сегодня два раза наблюдал описанную ранее картину.
Вот, что выдает запрос:

session_id	status	statement_text														blocking_session_id	wait_type	wait_resource	wait_time	(Отсутствует имя столбца)	cpu_time	logical_reads	reads	writes	start_time	

sql_handle	plan_handle

68	suspended	INSERT INTO INVENTCOSTLIST (ITEMID,VOUCHER,COSTNUM,NUMOFITERATION,DATAAREAID,RECVERSION,RECID) VALUES (@P1,@P2,@P3,@P4,@P5,@P6,@P7)	13	LCK_M_IX	OBJECT: 11:1125539739:0 	78987	AXDB_test	0	0	0	0	2013-09-30 16:32:57.647	

0x02000000D6868835182D5B82B421A4BF3A77EF48E26F642E	0x06000B00D686883540218200040000000000000000000000
80	suspended	INSERT INTO INVENTCOSTLIST (ITEMID,VOUCHER,COSTNUM,NUMOFITERATION,DATAAREAID,RECVERSION,RECID) VALUES (@P1,@P2,@P3,@P4,@P5,@P6,@P7)	68	LCK_M_IX	OBJECT: 11:1125539739:0 	78861	AXDB_test	0	0	0	0	2013-09-30 16:32:57.773	

0x02000000D6868835182D5B82B421A4BF3A77EF48E26F642E	0x06000B00D686883540218200040000000000000000000000
81	suspended	SELECT A.ITEMID,A.VOUCHER,A.COSTNUM,A.NUMOFITERATION,A.RECVERSION,A.RECID FROM INVENTCOSTLIST A WITH( INDEX(I_1695COSTNUMIDX), UPDLOCK) WHERE ((DATAAREAID=@P1) AND ((VOUCHER=@P2) AND (COSTNUM=@P3))) OPTION(FAST 1)	68	LCK_M_IX	OBJECT: 11:1125539739:0 	77732	AXDB_test	0	

0	0	0	2013-09-30 16:32:58.910	0x02000000BE55883239FC01452D76FC6F396CD22FCF7342B0	0x06000B00BE55883240618EB5010000000000000000000000

Сессии 13 не наблюдал и в мониторинге.

[fed]

Единственное что могу предположить - что у одной из сессий случилась эскалация блокировок до уровня таблицы и эта сессия всех заблокировала. Вариант крайне маловероятный на самом деле. Еще есть шансы, что каким-то образом эта сессия повисла на одном из клиентов многопользовательского закрытия, но AOS продолжает держать открытую ей транзакцию. Вариант более реальный - но как с ним бороться - не понятно. Единственное что можно предложить - переустановка винды, Аксапты и тп на тех батч-серверах, на которых вы закрытие исполняете. Хотя в общем - вариант глубоко тупиковый...