Защита от повреждения типа таблицы в Аксапте 2012 R3

[sukhanchik]

Цитата:

Сообщение от 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-а.
Исключения конечно случаются - куда ж без них.

[Raven Melancholic]

Цитата:

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

По-хорошему, после этого нужно бы остановить АОС DEV и выполнить коррекцию счетчиков RecId в табличках XREF* (иначе компиляция проекта с включенной галкой Перекрестные ссылки может привести к ошибкам), но честно признаюсь - я этого не делаю, ибо не хочется рестартовать АОС, а пока заявок на эту проблему не поступало

Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.

Странно конечно - зачем Аксе требуется создавать запись в Xref при открытии Table Browser (не встречал такого), но... ок, можно и этот момент исправить. Просто, к сожалению, табличку SystemSequences можно менять только при остановленном АОСе. И если вдруг обновление ссылок закончилось в "рабочее" время - то рестарт АОСа без предупреждения может напрячь...

[Logger]

Цитата:

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

Странно конечно - зачем Аксе требуется создавать запись в Xref при открытии Table Browser (не встречал такого), но...

Может из-за этого ?
Открыть в новом окне объект из кода

[sukhanchik]

Цитата:

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

Может из-за этого ?
Открыть в новом окне объект из кода

Конкретно этого кода не нашел на том приложении, на котором искал, но ... тут само действие хотя бы объяснимо - тут сама функция концептуально построена на генерации записей в XREFREFERENCES.
Но Table Browser тут точно ни при чем.

Попробую сначала решение со сбросом кэша...

Спасибо за версии!

[Logger]

Цитата:

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

Конкретно этого кода не нашел на том приложении, на котором искал

А чего его искать. Добавьте логирование с записью стека вызовов на вставке в xRef* таблички, пропуская это действие для юзера под которым крутится пакет. Оно все само найдет.

[sukhanchik]

Цитата:

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

А чего его искать. Добавьте логирование с записью стека вызовов на вставке в xRef* таблички, пропуская это действие для юзера под которым крутится пакет. Оно все само найдет.

Спасибо. Эта идея помогла решить другую задачу )).
Конкретно место всё-таки нашел и там (конкретно в моем случае) уже "по-правильному" исправлено

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.

Цитата:

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

Вместо рестарта аоса, можно попробовать дернуть \Classes\ReleaseUpdateBulkCopyDB\flushNextRecIdForTable

Цитата:

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

Может из-за этого ?
Открыть в новом окне объект из кода

В общем, нашел более простое решение. Суть в том, чтобы не сдвигать RecId ПОСЛЕ массовой вставки данных, а в том, чтобы изначально "обнулять" RecId (ДО построения перекрёстных ссылок)

Т.е. общая схема такая:

• Перед началом построения перекрестных ссылок останавливаем АОС (это вообще всегда полезно - прочистить память). Предполагаем, что с CIL проблем нет (он не развален и актуален для процедуры обновления ссылок)
• Очищаем XREF*-таблички (через TRUNCATE)
• Сдвигаем RecId по ним в табличке SystemSequences на "нулевое" значение. В роли "нулевого" значения я взял значение, которое устанавливает АХ для свежесозданной таблицы
• Стартуем АОС и начинаем строить перекрестные ссылки

В моём случае (когда я использую отдельное приложение для сборки ссылок) на целевом приложении ссылки уже строились несколько раз и RecId уже сдвинуты на достаточно приличное "расстояние" от "нулевого".

Т.о. после массового переноса данных - в целевом приложении - в SystemSequences будут следующие значения RecId гораздо больше, нежели они будут сгенерированы на промежуточном приложении. Как следствие - проблем не возникнет.

Да, это конечно всё заморочки... Но сделав их один раз, запихнув в скрипт и шедулер уже про них забываешь и получаешь результат не думая, какими усилиями он получается.

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.

Нашел барабашку. Оказывается в стандарте всё хорошо . Но если пользоваться всякими утилитками, привнесенными извне - то да, в них могут быть и такие сюрпризы, как построение перекрестных ссылок при просмотре обозревателя таблиц )). Я то этим не пользовался никогда - вот и не замечал проблем

[Logger]

Цитата:

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

Нашел барабашку.

Ха, у нас тоже на HK Framework проявлялось. Поэтому и нашел, когда занялся оптимизацией.

[Logger]

Цитата:

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

А 12-13 часов сбора перекрестных ссылок - это последствия виртуализации сервера БД А если на нём еще и Windows Server 2016 (вместо Windows Server 2012 R2) стоит - то... это тоже еще влияет.

У нас ссылки собираются 8 часов в одном потоке (сервер БД невиртуализирован), но я нашел обходной путь в виде построения их на копии с последующим переносом XREF*-табличек средствами SQL на нужную БД.

Интересно. Не знал про такой выигрыш от 2012-й винды по сравнению с 2016-й. Мы как-то сразу с 2008-й на 2016-ю перескочили, а затем на 2019.

А что скажете про 2019-ю ?
У меня, по ощущениям, она шустрее 2016-й - просто если оценивать отзывчивость интерфейса аксапты, когда клиента аксапты открываешь на сервере с 2019-й и там же служба аоса хостится. Но вот при сборе перекрестных ссылок не заметил разницы. Возможно, все оптимизации и ускорения 2019-й винды съела виртуализация SQL.

[sukhanchik]

Цитата:

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

Интересно. Не знал про такой выигрыш от 2012-й винды по сравнению с 2016-й. Мы как-то сразу с 2008-й на 2016-ю перескочили, а затем на 2019.

А что скажете про 2019-ю ?
У меня, по ощущениям, она шустрее 2016-й - просто если оценивать отзывчивость интерфейса аксапты, когда клиента аксапты открываешь на сервере с 2019-й и там же служба аоса хостится. Но вот при сборе перекрестных ссылок не заметил разницы. Возможно, все оптимизации и ускорения 2019-й винды съела виртуализация SQL.

Ничего не скажу - не экспериментировал. Про 2012R2 тоже не знал - коллеги подсказали, а я проверил на тестовом стенде. Но тут вопрос не в скорости самой винды как таковой, а в оптимизации обращения к дискам (и прочим ресурсам операционной системы) от SQL Server. Т.е. SQL Server обращается к виндовым библиотечкам и в случае 2012R2 эти обращения происходят шустрее (для SQL 2016), нежели для винды 2016