Ax 2012 строит запрос с ошибкой в синтаксисе

[SRF]

Цитата:

Окончание индекса ведь строится по реальному физическому имени таблицы в базе данных TempDB. Если таблицы нет, то какое имя добавлять?

Так а реальное физическое имя то уже есть - и для построения имени индекса у АОСа есть вся информация - он же в селекте то пишет имя экземпляра, к которому обращается - а то что существует этот экземпляр физически или нет на БД это уже другой вопрос - если его нет, то в момент выполнения просто будет ошибка что такой то объект не существует. (для меня не очень логично делать доп. запрос на определение существует ли экземпляр только при построении индекса, когда вся информация у нас и так есть и мы можем сами построить имя со стороны АОСа).

Сейчас немного смущают следующие моменты
- в примере в запросе один ID, а на скринах ID таблички другой - запрос с одной инсталляции, скрины AOT с другой ?

- в коде мы выбираем только одно поле, в запросе присутствуют все поля - хотя индексы не кластерные, кеширование отключено, интересно почему выбираются все поля, мб потому что tempDB.

- не помогает ребут, те это меняется что-то в каких-то постоянных характеристиках системы, а не кеш\память и т.д. - так а на всех ли инсталляциях проявляется проблема, на разных АОСах, в пакетном режиме ?

- что в EV на АОСе ? Там эта ошибка есть, другие ?

- если снять трассировки SQL запросов (например через TraceParser) в этом функционале после исправления проблемы и просто в других местах системы - все ли запросы уходят с with ? (опять таки если несколько АОСов то попробовать снять трассировки на разных)

[Gibrid]

Цитата:

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

Сейчас немного смущают следующие моменты
- в примере в запросе один ID, а на скринах ID таблички другой - запрос с одной инсталляции, скрины AOT с другой ?

Да, ошибка с боевой базы, скрин с тестовой. Но там все идентично, за исключением ID.

Цитата:

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

- не помогает ребут, те это меняется что-то в каких-то постоянных характеристиках системы, а не кеш\память и т.д. - так а на всех ли инсталляциях проявляется проблема, на разных АОСах, в пакетном режиме ?

Вылезает проблема не так часто, раз в пол года может... Статистики еще не набралось. Единственное, в последний раз, когда появилась проблема ночью, чуть позже перезагрузился кластер со всеми аосами и скулем... После этого пакетник с этим запросом 1 раз отработал, а потом опять начал падать в ошибку.

Цитата:

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

- что в EV на АОСе ? Там эта ошибка есть, другие ?

Сразу не посмотрел, а сейчас почему-то не вижу на этом аосе события старше 1 дня. Не пойму почему.

[SRF]

Цитата:

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

Вылезает проблема не так часто, раз в пол года может... Статистики еще не набралось. Единственное, в последний раз, когда появилась проблема ночью, чуть позже перезагрузился кластер со всеми аосами и скулем... После этого пакетник с этим запросом 1 раз отработал, а потом опять начал падать в ошибку.

Сразу не посмотрел, а сейчас почему-то не вижу на этом аосе события старше 1 дня. Не пойму почему.

- это к админам, скорее всего могли настроить так хранение логов.
- в логах (batchlog) работы пакетника можно глянуть на каких АОСах были падения - разные там или не разные, но так скорее для статистики

- попробуйте поснимать трейсы своего процесса и посмотреть запрос на котором падает, трейсы можно снимать через счетчики windows - https://www.microsoft.com/en-us/down....aspx?id=27549, т.е. можете прямо пакетные задачи посмотреть - настраивать надо будет на всех АОСах где может выполняться пакетное задание. посмотрите на разных аосах\окружениях одни и те же запросы, одинаковые ли хинты там.

- еще про with - часть запросов без with - а там есть хинт top 1, что то подозрение возникает о том, что with появляется, если в запросе есть firstOnly - попробуйте поменять ваш запрос на count() и посмотреть будет ли with в запросе (понятно что это как закат солнца вручную, но как костыль возможно подойдет)

- насколько я понимаю билды у вас не последние, как MS в этом случае рекомендует - обновите ядро

- а что вы делаете с постоянными табличками - там тоже название индекса меняете или делаете синхронизацию\пересоздание индекса? помогает ли просто пересоздание индекса ?

[Gibrid]

Цитата:

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

- а что вы делаете с постоянными табличками - там тоже название индекса меняете или делаете синхронизацию\пересоздание индекса? помогает ли просто пересоздание индекса ?

Удаляю индекс. Создаю такой-же с другим именем.

[Logger]

Цитата:

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

Удаляю индекс. Создаю такой-же с другим именем.

а у вас не осталось бекапа базы модели с таким случаем ?
Есть ощущением что повреждается определение таблицы с одновременным затиранием кластерного и праймери индекса в шапке таблицы. Я такое встречал, но давно и редко бывало.

[Gibrid]

Цитата:

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

а у вас не осталось бекапа базы модели с таким случаем ?
Есть ощущением что повреждается определение таблицы с одновременным затиранием кластерного и праймери индекса в шапке таблицы. Я такое встречал, но давно и редко бывало.

Нет, бэкапа такого нет.
А какие могут быть причины этого? И как проверить, что это действительно оно в следующий раз?

[Gibrid]

Цитата:

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

- это к админам, скорее всего могли настроить так хранение логов.
- в логах (batchlog) работы пакетника можно глянуть на каких АОСах были падения - разные там или не разные, но так скорее для статистики

- попробуйте поснимать трейсы своего процесса и посмотреть запрос на котором падает, трейсы можно снимать через счетчики windows - https://www.microsoft.com/en-us/down....aspx?id=27549, т.е. можете прямо пакетные задачи посмотреть - настраивать надо будет на всех АОСах где может выполняться пакетное задание. посмотрите на разных аосах\окружениях одни и те же запросы, одинаковые ли хинты там.

- еще про with - часть запросов без with - а там есть хинт top 1, что то подозрение возникает о том, что with появляется, если в запросе есть firstOnly - попробуйте поменять ваш запрос на count() и посмотреть будет ли with в запросе (понятно что это как закат солнца вручную, но как костыль возможно подойдет)

- насколько я понимаю билды у вас не последние, как MS в этом случае рекомендует - обновите ядро

В общем жду повторения, собираю статистику...

[Logger]

Цитата:

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

В общем жду повторения, собираю статистику...

Столкнулись с той же проблемой.
На временной TempDb табличке.

Проблема появилась после того как в конфигурации аоса включили index hint.
Вероятно у вас также включены index hint, поэтому одной из рекомендаций было бы отключить их. (это 1-й бит в узле hint в конфигурации аоса в реестре. Дефолтное значение там "2")

Еще я заметил что помогает, если явно указать в запросе
index имя индекса
(но не index hint имя индекса)
видимо это добавляет сортировку но подавляет кривой index hint. Но проблему решает.

Вы как-нибудь решили для себя вопрос ?

[Gibrid]

Цитата:

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

- если снять трассировки SQL запросов (например через TraceParser) в этом функционале после исправления проблемы и просто в других местах системы - все ли запросы уходят с with ? (опять таки если несколько АОСов то попробовать снять трассировки на разных)

В нашем установщике нет пункта TraceParser. Его как-то перевели не так? .NET Business Connector есть, который судя по всему рядом должен быть https://learn.microsoft.com/en-us/pr...e-trace-parser

[Gibrid]

Цитата:

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

- если снять трассировки SQL запросов (например через TraceParser) в этом функционале после исправления проблемы и просто в других местах системы - все ли запросы уходят с with ? (опять таки если несколько АОСов то попробовать снять трассировки на разных)

Снял с того-же АОСа, где была ошибка. Запросы или без With, или с ним, но без дополнительных скобок.
К примеру:

SELECT TOP 1 T1.BATCHJOBCANCELED,
	T1.BATCHJOBENDED,
	T1.BATCHJOBERROR,
	T1.BATCHJOBID,
	T1.USERID,
	101090 
FROM BATCHJOBALERTS T1 WITH ( INDEX(I_2004BATCHJOBID)) 
WHERE ((BATCHJOBID=5639649525)