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

[sukhanchik]

Добрый день!
А в каких случаях происходит "порча" таблиц?
Я пока обнаружил только одно событие (правда, с 99% гарантией) - это построение в пакете перекрестных ссылок. Т.е. если:
- во время построения - программировать
- после построения - программировать.
То высока вероятность, что что-то испортится. Понимания пока правда нет, по какому принципу выбирается объект для "порчи".
Однако этот сценарий замечательно лечится:
- исключением программирования при построении перекрестных ссылок (их можно строить на копии приложения)
- рестартом АОСа после завершения построения ссылок (что в общем-то всегда полезно после выполнения крупного пакетника). На копии - вопрос рестарта вообще не стоит.

В начало и завершение построения ссылок легко можно встроить оповещения при необходимости.

[Logger]

Цитата:

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

Однако этот сценарий замечательно лечится:

Это преувеличение.
Он не замечательно лечится. По моим ощущениям, сильно снижается вероятность проблемы, но совсем она не пропадает. Возможно есть еще какие-то сценарии при которых воспроизводится глюк.

Ну и, в общем-то, зачем workaround, за применением которого нужно постоянно следить, следить за рестартами аоса, итп набором ограничений (причем гарантий опять же нет), если возможен более гарантированный способ закрыть лазейку на уровне SQL.


P.S.
Мне показалось, что еще бывает при глобальной компиляции. Но специально я не выяснял.

Еще пару раз видел похожий глюк - затерлись Primary и Cluster индексы на куче табличке при работе AxBuild и параллельном старте аоса. Это немного из другой серии, но похоже.

[sukhanchik]

Цитата:

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

Это преувеличение.
Он не замечательно лечится. По моим ощущениям, сильно снижается вероятность проблемы, но совсем она не пропадает. Возможно есть еще какие-то сценарии при которых воспроизводится глюк.

Ну и, в общем-то, зачем workaround, за применением которого нужно постоянно следить, следить за рестартами аоса, итп набором ограничений (причем гарантий опять же нет), если возможен более гарантированный способ закрыть лазейку на уровне SQL.


P.S.
Мне показалось, что еще бывает при глобальной компиляции. Но специально я не выяснял.

Еще пару раз видел похожий глюк - затерлись Primary и Cluster индексы на куче табличке при работе AxBuild и параллельном старте аоса. Это немного из другой серии, но похоже.

Про глобальную компиляцию соглашусь, т.к. построение перекрестных ссылок суть есть глобальная компиляция + запись данных в XREF*-таблички.
Не... решение понятное, логичное и т.д.

Однако я со своей стороны перестал наблюдать эту проблему иными действиями:
1. Любая глобальная компиляция "обрамляется" рестартами АОСа - до начала, чтобы сбросить весь кэш. И по окончанию, чтобы "прочистить" память. Просто так обычно компиляция не запускается (всё же не на 5 минут) - поэтому лишний рестарт никому не мешает. Опять-таки - любые запуски регламентных операций делаются в скриптах, поэтому +/- одно действие в скрипте никому не мешает (да и время рестарта АОСа несопоставимо с временем глобальной компиляции / построением перекрестных ссылок)

2. Крайне желательно после построения перекрестных ссылок / глобальной компиляции рестартовать все АОСы (если их было несколько). Опять-таки - на рабочей БД ссылки необязательно строить - их туда можно переносить средствами SQL с отдельной среды, приложение которой является полной копией рабочей.

3. Вообще полезно взять за правило рестартовать АОС раз в сутки на DEV-приложении. Во-первых сбрасывается кэш (поля кто-то добавил и т.д.), во-вторых все разработчики с утра зайдут в заведомо "свежее" приложение.

4. С п.3 можно увязать ежедневную сборку CIL на DEV-приложении (заодно все отчучаются оставлять на ночь ошибки компиляции). Это крайне полезно, т.к. в AX2012 полно объектов, требующих актуального CIL-а. При этом следует обратить внимание, как происходит сборка CIL - в память набирается список классов, т.о. после сборки CIL-а для целей высвобождения памяти лучше сделать рестарт АОСа. А до сборки - рестарт нужен для сброса кэша (отлично увязывается с п.3)

5. Ну и конечно нужно забыть о правках на рабочей базе. Максимум - формы / дизайны SSRS-отчетов.

6. Перекрестные ссылки желательно строить на том приложении, на котором:
- никто не работает
- АОС которого не жалко рестартануть по завершению построения ссылок
А перенести данные ссылок легко можно средствами SQL

В общем - при таком подходе проблема "порчи" таблиц исчезает. Учитывая, что сей подход в целом вынужден применяться в связи с особенностью AX2012 - то в общем-то получается и специального решения проблемы не нужно.