|
08.05.2024, 22:12 | #1 |
Administrator
|
Цитата:
Сообщение от Logger
Сегодня триггер ночью отработал на сборе перекрестных ссылок. Причем поймал проблему не после завершения сбора, а в середине процесса.
Похоже проблема носит вероятностный характер и вам просто везло. Правда у нас сбор ссылок распараллелен в примерно 10 потоков (чтобы собирал за 3 часа, а не за 12-13). Возможно это тоже влияет на воспроизводимость бага. Но я тут склонен грешить на многопоточку. Дело в том, что этот глюк 100% появляется, когда в память кэшируется "то, что не надо". А потоки, когда работают параллельно... наверняка же работают в одном АОСе и имеют общий кэш. А 12-13 часов сбора перекрестных ссылок - это последствия виртуализации сервера БД А если на нём еще и Windows Server 2016 (вместо Windows Server 2012 R2) стоит - то... это тоже еще влияет. У нас ссылки собираются 8 часов в одном потоке (сервер БД невиртуализирован), но я нашел обходной путь в виде построения их на копии с последующим переносом XREF*-табличек средствами SQL на нужную БД. Т.е. выполняются такие шаги: 1. Копируется приложение + БД DEV -> DEVCopy 2. Делается сборка полного CIL на DEVCopy. 3. Если сборка CIL прошла неуспешно - процесс завершается. Тут уже требуется вмешательство человека 4. Запускается (на AOS-сервере) клиент АХ с параметром xrefall (см класс SysStartupCmdXReference). Этот клиент ставит построение ссылок в пакет, а сам лишь мониторит завершение этого пакета. 5. По завершению работы этого клиента (а он завершится тогда, когда завершится пакетник) рестартуется АОС DEVCopy (для профилактики; для целей перекрестных ссылок этого делать не требуется) 6. Переливаются XREF* таблички из БД DEVCopy в БД DEV По-хорошему, после этого нужно бы остановить АОС DEV и выполнить коррекцию счетчиков RecId в табличках XREF* (иначе компиляция проекта с включенной галкой Перекрестные ссылки может привести к ошибкам), но честно признаюсь - я этого не делаю, ибо не хочется рестартовать АОС, а пока заявок на эту проблему не поступало Все описанные действия выполняются в скрипте Powershell и поставлены в шедулер (скрипт срабатывает по расписанию). Этот же скрипт (но с другими параметрами приложения) отрабатывает для PROD-приложения после релиза (но там без копирования в БД-копию; плюс скрипт я запускаю вручную при условии успешности релиза). Ну и... административно со временем все привыкли к 22:00 (время рестарта АОСа DEV для сборки CIL + снятия копии для построения перекрестных ссылок) не оставлять ошибок компиляции на DEV-приложении для автоматического рестарта АОСа со сборкой полного CIL-а. Исключения конечно случаются - куда ж без них.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 08.05.2024 в 22:16. |
|
|
За это сообщение автора поблагодарили: Logger (15). |
09.05.2024, 07:40 | #2 |
Участник
|
Цитата:
Сообщение от sukhanchik
По-хорошему, после этого нужно бы остановить АОС DEV и выполнить коррекцию счетчиков RecId в табличках XREF* (иначе компиляция проекта с включенной галкой Перекрестные ссылки может привести к ошибкам), но честно признаюсь - я этого не делаю, ибо не хочется рестартовать АОС, а пока заявок на эту проблему не поступало
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser. |
|
|
За это сообщение автора поблагодарили: sukhanchik (3). |
09.05.2024, 21:58 | #3 |
Administrator
|
Странно конечно - зачем Аксе требуется создавать запись в Xref при открытии Table Browser (не встречал такого), но... ок, можно и этот момент исправить. Просто, к сожалению, табличку SystemSequences можно менять только при остановленном АОСе. И если вдруг обновление ссылок закончилось в "рабочее" время - то рестарт АОСа без предупреждения может напрячь...
__________________
Возможно сделать все. Вопрос времени |
|
14.05.2024, 00:06 | #4 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: sukhanchik (3). |
14.05.2024, 07:19 | #5 |
Administrator
|
Цитата:
Сообщение от Logger
Может из-за этого ?
Открыть в новом окне объект из кода Но Table Browser тут точно ни при чем. Попробую сначала решение со сбросом кэша... Спасибо за версии!
__________________
Возможно сделать все. Вопрос времени |
|
14.05.2024, 07:52 | #6 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
14.05.2024, 08:52 | #7 |
Administrator
|
Цитата:
Конкретно место всё-таки нашел и там (конкретно в моем случае) уже "по-правильному" исправлено
__________________
Возможно сделать все. Вопрос времени |
|
15.05.2024, 08:06 | #8 |
Administrator
|
Цитата:
Цитата:
Цитата:
Сообщение от Logger
Может из-за этого ?
Открыть в новом окне объект из кода Т.е. общая схема такая:
В моём случае (когда я использую отдельное приложение для сборки ссылок) на целевом приложении ссылки уже строились несколько раз и RecId уже сдвинуты на достаточно приличное "расстояние" от "нулевого". Т.о. после массового переноса данных - в целевом приложении - в SystemSequences будут следующие значения RecId гораздо больше, нежели они будут сгенерированы на промежуточном приложении. Как следствие - проблем не возникнет. Да, это конечно всё заморочки... Но сделав их один раз, запихнув в скрипт и шедулер уже про них забываешь и получаешь результат не думая, какими усилиями он получается.
__________________
Возможно сделать все. Вопрос времени |
|
14.05.2024, 08:50 | #9 |
Administrator
|
Цитата:
__________________
Возможно сделать все. Вопрос времени |
|
14.05.2024, 09:15 | #10 |
Участник
|
|
|
14.05.2024, 08:24 | #11 |
Участник
|
Цитата:
Сообщение от sukhanchik
А 12-13 часов сбора перекрестных ссылок - это последствия виртуализации сервера БД А если на нём еще и Windows Server 2016 (вместо Windows Server 2012 R2) стоит - то... это тоже еще влияет.
У нас ссылки собираются 8 часов в одном потоке (сервер БД невиртуализирован), но я нашел обходной путь в виде построения их на копии с последующим переносом XREF*-табличек средствами SQL на нужную БД. А что скажете про 2019-ю ? У меня, по ощущениям, она шустрее 2016-й - просто если оценивать отзывчивость интерфейса аксапты, когда клиента аксапты открываешь на сервере с 2019-й и там же служба аоса хостится. Но вот при сборе перекрестных ссылок не заметил разницы. Возможно, все оптимизации и ускорения 2019-й винды съела виртуализация SQL. |
|
14.05.2024, 08:43 | #12 |
Administrator
|
Цитата:
Сообщение от Logger
Интересно. Не знал про такой выигрыш от 2012-й винды по сравнению с 2016-й. Мы как-то сразу с 2008-й на 2016-ю перескочили, а затем на 2019.
А что скажете про 2019-ю ? У меня, по ощущениям, она шустрее 2016-й - просто если оценивать отзывчивость интерфейса аксапты, когда клиента аксапты открываешь на сервере с 2019-й и там же служба аоса хостится. Но вот при сборе перекрестных ссылок не заметил разницы. Возможно, все оптимизации и ускорения 2019-й винды съела виртуализация SQL.
__________________
Возможно сделать все. Вопрос времени |
|
Теги |
ax2012, ax2012r2, ax2012r3, map, modelelementdata, table, view |
|
|