AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.09.2013, 17:35   #1  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Зависание пересчета склада на обновлении главной книги.
Всем доброго времени суток!

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)

Ни кто с подобной картиной не сталкивался?
__________________
Axapta 3.0 SP6
Старый 26.09.2013, 18:17   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,909 / 5730 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Замечу лишь, что судя по тексту ждущего запроса, никакого отношения к разноске в ГК ситуация не имеет. На момент начала разноски в ГК все операции с inventCostList уже должны быть завершены.

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

Попробуйте исполнять следующий запрос:
X++:
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 не нулевое - значит этот запрос заблокироваи ждет другой сессии.
За это сообщение автора поблагодарили: Ace of Database (5).
Старый 30.09.2013, 19:20   #3  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от fed Посмотреть сообщение
Замечу лишь, что судя по тексту ждущего запроса, никакого отношения к разноске в ГК ситуация не имеет. На момент начала разноски в ГК все операции с inventCostList уже должны быть завершены.

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

Попробуйте исполнять следующий запрос:
X++:
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 не наблюдал и в мониторинге.
__________________
Axapta 3.0 SP6
Старый 01.10.2013, 15:06   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,909 / 5730 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Единственное что могу предположить - что у одной из сессий случилась эскалация блокировок до уровня таблицы и эта сессия всех заблокировала. Вариант крайне маловероятный на самом деле. Еще есть шансы, что каким-то образом эта сессия повисла на одном из клиентов многопользовательского закрытия, но AOS продолжает держать открытую ей транзакцию. Вариант более реальный - но как с ним бороться - не понятно. Единственное что можно предложить - переустановка винды, Аксапты и тп на тех батч-серверах, на которых вы закрытие исполняете. Хотя в общем - вариант глубоко тупиковый...
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axforum blogs: Распределение затрат между счетами главной книги и/или финансовыми аналитиками Blog bot DAX Blogs 0 01.10.2011 12:12
Не совпадают складские проводки и проводки главной книги Favor82 DAX: Функционал 2 13.07.2011 21:32
Маркировка по результатам пересчета склада Starling DAX: Функционал 15 01.12.2009 11:24
В обновлении книги покупок галка Полная проверка засерена.. MironovI DAX: Функционал 6 21.06.2005 18:14
Связь склада и счета главной книги Yury DAX: Функционал 7 08.02.2004 16:06

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 05:35.