Trace parcer в D365

[Lankey]

D365

На sandbox пользователь открывает форму global address book и пытается создать новую запись
В этот момент повисает система


Я новичок в 365. Чтобы понять причину пытаюсь воспользоваться Trace parcer
В одном и том же окне браузера открываю GAB и запускаю там же Help-> Trace parcer
Но:
1) Пока процесс не закончится я не могу остановить trace parcer
2) Когда по таймату выпаает ошибка , то только тогда могу сохранить его, но
a) лог занимает 200 МБ
b) почему-то в логах нет таблиц, что используются формой, хотя сообщение об ошибке появляется на экране, что не удалось выбрать запись в DirPartyRelationship
c) В Trace parcer , когда импортирую trace, то вверху экрана есть dropdown "select Grouping" . Там в колонке username вместо имени выпадают GUIDs. Как понять, какую запись нужно выбрать(какая относится к моему процессу)?

Eще небольшой вопрос - могу ли я через VS на devbox подключиться к sandbox , чтобы подебаггить открытие формы?


Спасибо за помощь!

[Stitch_MS]

1) А вы открывайте дополнительную вкладку в браузере, и стартуйте/останавливайте трейспарсер оттуда. Тогда зависание на первой вкладке не помешает остановке.

2с) Можно в трейспарсере на закладке X++ или SQL в строке поиска написать что-то типа *SalesTable*, и переключаться между GUID. Сессия, в которой такой поиск что-нибудь найдёт с текстом "SalesTable" в названии метода или в теле SQL-выражения, с большой вероятностью ваша.

Подебаггить можно. https://learn.microsoft.com/en-us/dy...ario-debugdiag

[Lankey]

Спасибо.
Да, две вкладки тоже открывала. Trace лог оказался в более чем 10 раз меньше, чем когда в окне, где подвисает форма. Поэтому была не уверена, что это правильный подход. У вас так работает?

Когда фильтрую по таблице, то ненахожу dirParty* записей вообще(пункт (b) выше), поэтому и вопрос как найти User Name (GUID), что соответсвует моей сессии.

Спасибо за ссылку на то, как дебагить UAT из-под DEV.
"Make sure that the version of the code and binaries in the DevTest environment exactly match the version in the UAT environment" - шикарно MS придумал Как может код быть он таким же, если на DEV разработка проводится? Может, я просто не знаю, как быстро временно восстановить копию UAT на DEV и также быстро вернуть после дебаггинга все обратно)?

[Stitch_MS]

Трейспарсер на второй вкладке часто использую, никаких проблем с этим не было.

Если фильтр "*dirparty*" не находит ничего, может это из-за кеширования? Еще можно правой кнопкой на форме кликнуть, чтобы из контекстного меню узнать ее название, и дальше в парсере искать по названию формы на закладке x++.

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

[fed]

Я бы еще посмотрел на список blocking statements в LCS. Скорее всего, зависание происходит из за блокировок в SQL. При этом если в X++ insert (или update) statement отвалился по таймауту, то этот отвалившийся statement в трассировку, если я правильно помню, не попадает.

[Lankey]

Я сделала DBREINDEX на PreProd для DirPartyRelationships индекс по Partition, у которого fragmentation был 98% и создание новой записи стало мгновенно выполняться.

Только не ясно, что теперь делать, если PreProd - это копия prod и там все индексы микрософт поддерживает.

[Lankey]

Кстати, зодно заметила, что на форме DirPartyTable, если посмотреть используемый запрос (Form info->show hidden elements), то там в (стандартном, форма не модифицирована) запросе есть
DirPartyTable.INVALID FIELD = DirNAmeAffix.RecId
и
DirPartyTable.INVALID FIELD = DirNameSequence.RecId
Но ошибок никаких не выдается.
То есть, будто база не синхнонизирована.
У вас тоже так?


Installed product version 10.0.37
Platform version Update61

[fed]

Цитата:

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

Кстати, зодно заметила, что на форме DirPartyTable, если посмотреть используемый запрос (Form info->show hidden elements), то там в (стандартном, форма не модифицирована) запросе есть
DirPartyTable.INVALID FIELD = DirNAmeAffix.RecId
и
DirPartyTable.INVALID FIELD = DirNameSequence.RecId
То есть, будто база не синхнонизирована.
У вас тоже так?


Installed product version 10.0.37
Platform version Update61

У меня в 10.0.38 точно также и мне кажется что это только потому, что Form information не умеет толком с наследованием таблиц работать и не показывает поля из дочерних таблиц (хотя по ним как раз есть какие-то условия для joinов)
А по поводу индексов - я бы тупо написал небольшие скриптики для переиндексации нужных таблиц (через классы Connection и Statement) и выполнил бы их в PROD через вот этот механизм.

[Lankey]

Извините, что снова к вам...
За ночь обновили базу в PrePROD новой версией с PROD. Заново прогнала reindex, чтобы убедиться, что точно дело в индексах (вчера, как только переиндексировала, то сразу стала форма открываться) и .... никакого эффекта. Создание новой записи в GAB (кнопка "New") висит снова по полчаса. За эти полчаса два раза появляется сообщение, что предлагает продолжать ждать. И в конце концов вываливается сообщение,что запись в DirPartyRelationship не может быть выбрана
В LCS посмотрела, нет блокировок (и заодно в dbo.sysprocesses перепроверила. Там тоже нет блокировок. Зато у моего процесса заметила lastwaittype = SOS_SCHEDULER_YIELD)
На SQL сервере ничего больше нет, только "мой" запрос и у него ... logical reads = 1 366 710 036 и растет. Ну то есть, просто умопомрачительно много, хотя все индексы переделала в используемых таблицах. Может быть, что кэш старый и обновленные индексы не влияют на исполнение запроса?
DROPCLEANBUFFERS не могу прогнать(прав нет) , как и FREEPROCCACHE(plan_handle) для конкретного плана. Хотя, надо сказать, что у плана creation_time свежий, то есть, он создан уже после индексации создан. План этот содержит placeholders, т.е параметры с @
Если запускаю через sql server management studio запрос, отловленый traceParcer , т.е уже с подставленными параметрами, то мгновенно выполняется.

Что делать-то ?

[fed]

Вообще в Azure SQL DBCC Freeproccache() не работает. Надо пользоваться синтаксисом

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE <plan_handle>

или просто

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE

Прав для этого в тестовых инстанцах должно хватать (только что проверил).
Еще есть вариант, что у вас там самооптимизатор SQL Server ухитрился сам себе прописать plan guide. (Я, правда, такого никогда не видел, но как гипотеза). Так что если чистка кэша не поможет, ищите список plan guide и нету ли там вашего запроса.
Еще любопытно, а как, собственно, этот висящий запрос выглядит ? Я сталкивался с тем, что если у вас в форме определены saved views, то генератор запросов сходит с ума и добавляет в запрос многократно продублированные копии какой-то таблицы и десятки (если не сотни) каких-то достаточно странных range. Если такое случилось, SQL может вместо обычных миллисекунд думать эдак минуту-полторы.

[Lankey]

(@P1 bigint,@P2 bigint,@P3 int,@P4 int,@P5 int,@P6 int,@P7 int,@P8 int)
SELECT T1.CHILDPARTY,T1.LEGALENTITYDATAAREAID,T1.PARENTPARTY,T1.RELATIONSHIPTYPEID,
T1.VALIDFROM,T1.VALIDFROMTZID,T1.VALIDTO,T1.VALIDTOTZID,T1.SCHEMAVERSION,T1.RECVERSION,
T1.PARTITION,T1.RECID,T2.CHILDPARENTNAME,T2.CHILDPARTYTYPE,T2.DESCRIPTION,
T2.ISSYMMETRIC,T2.PARENTCHILDNAME,T2.PARENTPARTYTYPE,T2.RELATIONSHIPTYPEID,T2.SYSTEMTYPE,
T2.RECVERSION,T2.PARTITION,T2.RECID,T3.NAME,T3.RECVERSION,T3.RECID,T3.INSTANCERELATIONTYPE,T4.NAME,T4.RECVERSION,T4.RECID,
T4.INSTANCERELATIONTYPE 

FROM DIRPARTYRELATIONSHIP T1 CROSS JOIN DIRRELATIONSHIPTYPETABLE T2 

LEFT OUTER JOIN DIRPARTYTABLE T3 
ON ((T3.PARTITION=5637144576) AND (T1.CHILDPARTY=T3.RECID)) 

LEFT OUTER JOIN DIRPARTYTABLE T4 
ON ((T4.PARTITION=5637144576) AND (T1.PARENTPARTY=T4.RECID)) 
WHERE ((T1.PARTITION=5637144576) AND ((T1.PARENTPARTY=@P1) OR (T1.CHILDPARTY=@P2))) 
AND ((T2.PARTITION=5637144576) AND (((T2.SYSTEMTYPE<@P3) OR (T2.SYSTEMTYPE>@P4)) 
AND (T1.RELATIONSHIPTYPEID=T2.RELATIONSHIPTYPEID))) 

AND 
(EXISTS (SELECT 'x' FROM DIRPARTYRELATIONSHIPSUNIONVIEW T5 
WHERE ((T5.PARTITION=5637144576) 
AND (((T5.SYSTEMTYPE<@P5) OR (T5.SYSTEMTYPE>@P6)) AND (T1.CHILDPARTY=T5.OTHERPARTY))))) 
AND 

(EXISTS (SELECT 'x' FROM DIRPARTYRELATIONSHIPSUNIONVIEW T6 
WHERE ((T6.PARTITION=5637144576) AND (((T6.SYSTEMTYPE<@P7) OR (T6.SYSTEMTYPE>@P8)) AND (T1.PARENTPARTY=T6.OTHERPARTY))))) 
ORDER BY T1.VALIDFROM DESC OPTION(FAST 8)

В dirPartyTable 84024 записи
В dirPartyRelationship 284046 записи
В dirRelationshipTypeTable 42 записи

В трейспарсере то же самое, но с подставленными значениями

[Lankey]

SELECT T1.CHILDPARTY,
	T1.LEGALENTITYDATAAREAID,
	T1.PARENTPARTY,
	T1.RELATIONSHIPTYPEID,
	T1.VALIDFROM,
	T1.VALIDFROMTZID,
	T1.VALIDTO,
	T1.VALIDTOTZID,
	T1.SCHEMAVERSION,
	T1.RECVERSION,
	T1.PARTITION,
	T1.RECID,
	T2.CHILDPARENTNAME,
	T2.CHILDPARTYTYPE,
	T2.DESCRIPTION,
	T2.ISSYMMETRIC,
	T2.PARENTCHILDNAME,
	T2.PARENTPARTYTYPE,
	T2.RELATIONSHIPTYPEID,
	T2.SYSTEMTYPE,
	T2.RECVERSION,
	T2.PARTITION,
	T2.RECID,
	T3.NAME,
	T3.RECVERSION,
	T3.RECID,
	T3.INSTANCERELATIONTYPE,
	T4.NAME,
	T4.RECVERSION,
	T4.RECID,
	T4.INSTANCERELATIONTYPE 
FROM DIRPARTYRELATIONSHIP T1 CROSS 
JOIN DIRRELATIONSHIPTYPETABLE T2 LEFT 
OUTER 
JOIN DIRPARTYTABLE T3 ON ((T3.PARTITION=5637144576) 
	AND (T1.CHILDPARTY=T3.RECID)) LEFT 
OUTER 
JOIN DIRPARTYTABLE T4 ON ((T4.PARTITION=5637144576) 
	AND (T1.PARENTPARTY=T4.RECID)) 
WHERE ((T1.PARTITION=5637144576) 
	AND ((T1.PARENTPARTY=0) 
	OR (T1.CHILDPARTY=0))) 
	AND ((T2.PARTITION=5637144576) 
	AND (((T2.SYSTEMTYPE<29) 
	OR (T2.SYSTEMTYPE>40)) 
	AND (T1.RELATIONSHIPTYPEID=T2.RELATIONSHIPTYPEID))) 
	AND (
EXISTS (
SELECT 'X' 
FROM DIRPARTYRELATIONSHIPSUNIONVIEW T5 
WHERE ((T5.PARTITION=5637144576) 
	AND (((T5.SYSTEMTYPE<29) 
	OR (T5.SYSTEMTYPE>40)) 
	AND (T1.CHILDPARTY=T5.OTHERPARTY))))) 
	AND (
EXISTS (
SELECT 'X' 
FROM DIRPARTYRELATIONSHIPSUNIONVIEW T6 
WHERE ((T6.PARTITION=5637144576) 
	AND (((T6.SYSTEMTYPE<29) 
	OR (T6.SYSTEMTYPE>40)) 
	AND (T1.PARENTPARTY=T6.OTHERPARTY))))) 
	ORDER BY T1.VALIDFROM DESC OPTION(FAST 9)

Это из трейспарсера. В SQL Server Management Studio возвращает тут же 0 записей.

[Lankey]

( а из формы GlobalAddressBook->New около 30 минут висит, а потом выдается сообщение, что запись в DirPartyRelationship не может быть выбрана )

[fed]

Запросы, с виду, нормальные. Может стоит просто обновить статистику по таблицам из запроса (и таблицам из view DIRPARTYRELATIONSHIPSUNIONVIEW)?

[Lankey]

В принципе reindex должен обновлять , но сделала на этих таблицах дополнительно update statistics <myTabless> with fullscan. Не помогло (
Спасибо за

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE

Не знала. Да, прав хватает , чтобы запустить

Нормально ли, что когда я выбираю из в sys.dm_exex_sql_text (<mysql_handle>) колонку TEXT , то есть, сам запрос, то выдается запрос с placeholders @P6 @P5 (как привела его на 2 поста выше) и тд, а не подставленными уже значениями (как в traceparcer) ?

[fed]

Цитата:

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

Нормально ли, что когда я выбираю из в sys.dm_exex_sql_text (<mysql_handle>) колонку TEXT , то есть, сам запрос, то выдается запрос с placeholders @P6 @P5 (как привела его на 2 поста выше) и тд, а не подставленными уже значениями (как в traceparcer) ?

Нормально. Чтобы выдавалось со значениями, надо в запрос forceliterals подставить. (Но это только как отладочное действие, в productive это нельзя просто так деплоить).

[fed]

Цитата:

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

Нормально ли, что когда я выбираю из в sys.dm_exex_sql_text (<mysql_handle>) колонку TEXT , то есть, сам запрос, то выдается запрос с placeholders @P6 @P5 (как привела его на 2 поста выше) и тд, а не подставленными уже значениями (как в traceparcer) ?

Вообще взять исходный запрос с placeholders, заменить

(@P1 bigint,@P2 bigint,@P3 int,@P4 int,@P5 int,@P6 int,@P7 int,@P8 int)

на

DECLARE @P1 bigint,@P2 bigint,@P3 int,@P4 int,@P5 int,@P6 int,@P7 int,@P8 int

Потом ниже поставить серию присвоений типа

SET @P1=0
SET @P2=1
..
SET @P8=40

А потом текст запроса с placehodlers.
Таким образом можно будет попробовать заставить SQL исполнить запрос точно также как он его исполняет если он из ядра D365FO пришел.