|
26.01.2024, 20:31 | #1 |
Участник
|
Trace parcer в D365
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 , чтобы подебаггить открытие формы? Спасибо за помощь! |
|
27.01.2024, 11:01 | #2 |
Участник
|
1) А вы открывайте дополнительную вкладку в браузере, и стартуйте/останавливайте трейспарсер оттуда. Тогда зависание на первой вкладке не помешает остановке.
2с) Можно в трейспарсере на закладке X++ или SQL в строке поиска написать что-то типа *SalesTable*, и переключаться между GUID. Сессия, в которой такой поиск что-нибудь найдёт с текстом "SalesTable" в названии метода или в теле SQL-выражения, с большой вероятностью ваша. Подебаггить можно. https://learn.microsoft.com/en-us/dy...ario-debugdiag |
|
|
За это сообщение автора поблагодарили: MorpheusX (1). |
27.01.2024, 15:50 | #3 |
Участник
|
Спасибо.
Да, две вкладки тоже открывала. 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 и также быстро вернуть после дебаггинга все обратно)? |
|
27.01.2024, 21:07 | #4 |
Участник
|
Трейспарсер на второй вкладке часто использую, никаких проблем с этим не было.
Если фильтр "*dirparty*" не находит ничего, может это из-за кеширования? Еще можно правой кнопкой на форме кликнуть, чтобы из контекстного меню узнать ее название, и дальше в парсере искать по названию формы на закладке x++. Абсолютно идентичный код необязательно, просто нужно понимать, что код на dev работает в этом режиме с базой данных uat. Если на dev в таблице есть новое поле, и во время отладки эта таблица используется, то может вывалиться ошибка. |
|
|
За это сообщение автора поблагодарили: Lankey (1). |
29.01.2024, 15:28 | #5 |
Moderator
|
Я бы еще посмотрел на список blocking statements в LCS. Скорее всего, зависание происходит из за блокировок в SQL. При этом если в X++ insert (или update) statement отвалился по таймауту, то этот отвалившийся statement в трассировку, если я правильно помню, не попадает.
|
|
30.01.2024, 17:15 | #6 |
Участник
|
Я сделала DBREINDEX на PreProd для DirPartyRelationships индекс по Partition, у которого fragmentation был 98% и создание новой записи стало мгновенно выполняться.
Только не ясно, что теперь делать, если PreProd - это копия prod и там все индексы микрософт поддерживает. Последний раз редактировалось Lankey; 30.01.2024 в 17:34. |
|
30.01.2024, 17:27 | #7 |
Участник
|
Кстати, зодно заметила, что на форме 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 Последний раз редактировалось Lankey; 30.01.2024 в 17:41. |
|
30.01.2024, 17:41 | #8 |
Moderator
|
Цитата:
Сообщение от 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 А по поводу индексов - я бы тупо написал небольшие скриптики для переиндексации нужных таблиц (через классы Connection и Statement) и выполнил бы их в PROD через вот этот механизм. |
|
|
За это сообщение автора поблагодарили: Logger (3), MorpheusX (1), Lankey (1). |
31.01.2024, 17:31 | #9 |
Участник
|
Извините, что снова к вам...
За ночь обновили базу в 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 , т.е уже с подставленными параметрами, то мгновенно выполняется. Что делать-то ? Последний раз редактировалось Lankey; 31.01.2024 в 17:45. |
|
31.01.2024, 18:39 | #10 |
Moderator
|
Вообще в 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 может вместо обычных миллисекунд думать эдак минуту-полторы. |
|
01.02.2024, 10:30 | #11 |
Moderator
|
Запросы, с виду, нормальные. Может стоит просто обновить статистику по таблицам из запроса (и таблицам из view DIRPARTYRELATIONSHIPSUNIONVIEW)?
|
|
01.02.2024, 12:16 | #12 |
Участник
|
В принципе reindex должен обновлять , но сделала на этих таблицах дополнительно update statistics <myTabless> with fullscan. Не помогло (
Спасибо за X++: ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE Нормально ли, что когда я выбираю из в sys.dm_exex_sql_text (<mysql_handle>) колонку TEXT , то есть, сам запрос, то выдается запрос с placeholders @P6 @P5 (как привела его на 2 поста выше) и тд, а не подставленными уже значениями (как в traceparcer) ? |
|
01.02.2024, 12:43 | #13 |
Moderator
|
Нормально. Чтобы выдавалось со значениями, надо в запрос forceliterals подставить. (Но это только как отладочное действие, в productive это нельзя просто так деплоить).
|
|
01.02.2024, 13:13 | #14 |
Moderator
|
Цитата:
Код: (@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 Таким образом можно будет попробовать заставить SQL исполнить запрос точно также как он его исполняет если он из ядра D365FO пришел. Последний раз редактировалось fed; 01.02.2024 в 13:38. |
|
Теги |
d365 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|