При обновлении или штатном обслуживании информационных баз ЗКГУ 3.1 (Зарплата и кадры государственного учреждения) технические специалисты часто сталкиваются с ситуацией, когда процедура «Тестирование и исправление» (ТиИ) длится бесконечно долго или зависает на этапе проверки логической целостности. Особенно критично это проявляется, если индикатор выполнения переходит отметку в 100%, достигая 500% и более, а процесс останавливается на проверке регистров, связанных с учетом времени (табелей). Рассмотрим детально причины возникновения такой ситуации и разберем пошаговые алгоритмы её решения.
Проанализируем ситуацию: почему штатный механизм 1С может работать некорректно? В ЗКГУ 3.1 таблицы, отвечающие за учет рабочего времени, являются одними из самых объемных. Проверка логической целостности подразумевает перебор всех записей в регистрах накопления и сведений, а также проверку их связей со справочниками. Если в базе объемом около 7 Гб накопилось большое количество данных, и при этом присутствуют «битые ссылки» (объекты с пометкой Объект не найден), механизм проверки может войти в цикл или крайне медленно обрабатывать индексы.
Особое внимание уделим индикатору выполнения. Если вы видите значения выше 100%, это означает, что на этапе предварительного анализа платформа неверно оценила объем данных. Это часто случается в регистрах ДанныеТабельногоУчета или ЗначенияОперативныхПоказателейРасчетаЗарплаты. Наличие некорректных дат (например, пустых или экстремально больших) в этих регистрах заставляет ТиИ тратить колоссальное время на проверку каждой записи.
Одной из главных причин сбоев в ЗКГУ является наличие битых ссылок в справочнике ВидыОтпусков. Это происходит при некорректном переносе данных или удалении объектов, на которые остались ссылки в документах. Рассмотрим, как правильно настроить параметры ТиИ в этом случае.
Многие совершают ошибку, выбирая в настройках пункт «Очищать ссылки». Как отмечают специалисты, в конфигурациях линейки 3.1 это может привести к «кастрированию» базы. Очистка ссылки в старых документах начисления отпуска может безвозвратно испортить расчет среднего заработка за прошлые периоды.
Разберем алгоритм восстановления целостности:
GUID, который указан в битой ссылке.Если известно, из какой базы были перенесены данные, вызвавшие ошибку, мы можем воспользоваться более элегантным способом. Выясним GUID битого элемента. Это можно сделать программно или посмотрев текст ошибки. После этого воспользуемся стандартной обработкой ВыгрузкаЗагрузкаДанныхXML.
Проанализируем шаги:
Поскольку GUID объектов совпадут, битая ссылка автоматически превратится в полноценный объект справочника ВидыОтпусков, и необходимость в долгой очистке отпадет сама собой.
Если «Тестирование и исправление» запускается исключительно ради избавления от битых ссылок, мы можем обойти этот долгий процесс, используя специализированные обработки. Рассмотрим работу с обработкой «Поиск и замена дублей» или «Универсальный подбор и обработка объектов».
Посмотрим на пример логики действий:
Объект не найден...).ВидОтпуска.Этот метод значительно быстрее, чем полное ТиИ, так как он работает направленно с конкретными записями, а не сканирует всю базу целиком.
Если провести тестирование необходимо (например, это требование техподдержки перед обновлением), но процесс зависает на табелях, применим техническую хитрость с итогами. В ЗКГУ расчетные регистры содержат миллионы записей, и пересчет итогов во время ТиИ занимает 80% времени.
Выполним следующие шаги:
Для файловых баз объемом 7 Гб (что является близким к критическому пределу производительности) перед запуском внутреннего ТиИ обязательно нужно выполнить проверку утилитой chdbfl.exe. Она находится в каталоге bin установленной платформы 1С.
Проанализируем ситуацию: встроенное в конфигуратор тестирование проверяет логику (связи между таблицами), а chdbfl.exe проверяет физику (структуру самих файлов .1CD). Часто логическая проверка «спотыкается» именно на поврежденном индексе таблицы. Если утилита найдет и исправит физические ошибки, последующее ТиИ в конфигураторе может пройти без зависаний.
Стоит учитывать, что версия платформы 8.3.20.2076 имеет специфические особенности работы с памятью при выполнении длительных операций. Если база данных клиент-серверная, проанализируем нагрузку на процесс sqlservr.exe. Если процесс активно потребляет ресурсы диска и процессора, значит, ТиИ не зависло, а просто выполняет колоссальный объем работы. В этом случае стоит дождаться окончания или временно обновить платформу до ветки 8.3.22, где многие механизмы оптимизации запросов работают стабильнее.
Подводя итог, отметим: при возникновении проблем с битыми ссылками в ЗКГУ 3.1 лучше всего использовать точечные методы исправления данных (обработки замены или восстановление по GUID), а штатное тестирование запускать с отключенными итогами и в режиме создания объектов, а не их удаления.