Проверка целостности

[coja]

Спецы подскажите!
Такая ситуация:
Была осуществлена сборка базы с новыми модификациями, вроде все данные на месте никаких ошибок при компиляции нет, решили для достоверности запустить:
Основное\Проверка целостности копмании.
Размер базы 1,5 Гб.
Проверка шла 3 суток и не завершилась, я её прервал и решил её делать помодульно.
Зависание проверки происходит на модуле Управление Запасами, пhичем что бы я не проверял: журналы, проводки, настройки... проверка не завершается по 3 суток.

Вопрос:
Можно ли прервать проверку насильно ,без потери данных?
Почему проверка не завершается при таком малом объёме базы(процесс не висячий, производительность АОС и SQL не падает, даже пользователи в ней работают без особых неудобств)?
Где посмотреть логи-чтоль или хоть какой-нибудь намек на поиск причин такого поведения?

Всем заранее спасибо за ответы!!!

coja@yandex.ru

[Maxim Gorbunov]

Цитата:

Изначально опубликовано coja
Можно ли прервать проверку насильно ,без потери данных?

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

Цитата:

Изначально опубликовано coja
Почему проверка не завершается при таком малом объёме базы(процесс не висячий, производительность АОС и SQL не падает, даже пользователи в ней работают без особых неудобств)?
Где посмотреть логи-чтоль или хоть какой-нибудь намек на поиск причин такого поведения?

К сожалению, нормального лога проверка не делает. Все, что есть - сообщения инфолога. Чтобы их посмотреть, нажмите Ctrl+Break. После этого появится сообщение о том, действительно ли Вы хотите прервать операцию. Нажимайте Нет+Shift, чтобы запустился Axapta Debugger. В нем можно посмотреть состояние Infolog'а на текущий момент. В принципе, Вас будет интересовать даже не столько инфолог, сколько метод, который не завершается в течение такого длительного времени.

[ToRo]

Мы тоже столкнулись с подобной проблемой при проверке и корректировки запасов в наличии.
Конкретно в этом механизме обнаружилась интересная бага, которая долго работает вроде над построением прогресс-бара.
При большом количестве номенклатуры время проверки-корректировки близилось к бесконечности.
Мы это дело поправили. Что точно там было и где - я уже не вспомню, т.к. не разработчик, и давно это было .

[coja]

Попробовал по совету сделать:
Нажал Ctrl+Break, появилось окно, типа прервать операцию или нет, жму Shift+Нет и блин,ничё не происходит, то есть проверка продолжается дальше.

[ToRo]

Цитата:

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

Насколько я знаю - это серверная процедура - ее просто так не прекратить с клиента.
Хотя я не уверен - могу ошибаться.
Попробуйте разобраться с программистом.

[coja]

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

[gl00mie]

Цитата:

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

Мы тоже столкнулись с подобной проблемой при проверке и корректировки запасов в наличии. Конкретно в этом механизме обнаружилась интересная бага, которая долго работает вроде над построением прогресс-бара.
При большом количестве номенклатуры время проверки-корректировки близилось к бесконечности.

Недавно читал блоги и наткнулся на описание подобной проблемы, правда, симптомы там были немного другие: тоже длительное время отрабатывала проверка целостности на запасах, в результате чего винда ругалась на отсутствие winsta.dll По ссылкам обнаружил описание и решение проблемы. Оно относится к декабрю 2005 и якобы упоминается в запросе #8379426 (Support Request Incident), но на случай, если кто-то столкнется или если ссылка похерится, приведу описание здесь в вольном переводе.

D. Higi
Среда, 21 дек 2005 00:02:13 -0800
См. существующий запрос в техподдержку #8379426

ДЕЙСТВИЕ:
Запущенная проверка целостности длится слишком долго (до нескольких дней).

РЕЗУЛЬТАТ:
Система будет заблокирована на это время.

ПРИЧИНА:
Проблема кроется в методе SysConsistencyCheck.kernelCheckRecords(), где после выполнения pack/unpack над объектом Query теряется отношение (relation) [между таблицами]. После этого все записи InventTable будут объединены (joined) со всеми записями InventTxt.
При динамическом создании запроса методы SysQuery::countLoops() и SysQuery::countTotal() расчитывают неверное количество записей. Это происходит из-за потери отношений (relations) между таблицами в методе SysQuery::countPrim(). Такого не происходит в случае статических запросов.
Запуск проверки целостности на запасах номенклатуры в наличии может занять слишком длительное время или даже привести к критической ошибке в Microsoft Axapta из-за того, что totalCount в градуснике (Progress) диалогового окна неправильно вычисляется в методе SysQuery::countTotal().

РЕШЕНИЕ:
В Classes\SysQuery была добавлена установка свойства QueryBuildDataSource.Relations в true вместо следующей последовательности вызовов:
DictRelation.loadTableRelation(tableId),
QueryBuildDataSource.addRelation(DictRelation);
Результат действия этих двух вызовов - создание отношения (relation) с указанной таблицей. Такое же поведение реализовано и на уровне ядра.

Код до изменений (\Classes\SysQuery):

public static Query addTableRelation(Query query, tableId tableId)
{
    Query retQuery = new Query(query.pack());
    QueryBuildDataSource qbds1;
    QueryBuildDataSource qbds2;
    DictRelation dr;

    qbds1 = retQuery.dataSourceNo(1);
    qbds2 = qbds1.addDataSource(tableId);

    dr = new DictRelation(tableId);
    dr.loadTableRelation(qbds1.table());

    qbds2.addRelation(dr);

    return retQuery;
}

Код после изменений (\Classes\SysQuery):

public static Query addTableRelation(Query query, tableId tableId)
{
    Query retQuery = new Query(query.pack());
    QueryBuildDataSource qbds1;
    QueryBuildDataSource qbds2;

    qbds1 = retQuery.dataSourceNo(1);
    qbds2 = qbds1.addDataSource(tableId);

    qbds2.relations(true);

    return retQuery;
}