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

[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 не наблюдал и в мониторинге.