Работа с платформой 1С:Предприятие 7.7 в SQL-варианте на больших объемах данных (свыше 6 Гб) часто преподносит неприятные сюрпризы. Одной из наиболее критичных проблем является внезапное «зависание» процесса Тестирования и исправления (ТиИ) или режима Выгрузка данных. Рассмотрим подробно, почему это происходит, как диагностировать «замерший» процесс и какими методами можно вернуть базу в работоспособное состояние, минуя штатные, но не всегда эффективные инструменты конфигуратора.
Когда процесс тестирования или выгрузки останавливается, пользователю кажется, что программа «умерла». Однако в SQL-версии 1С 7.7 это часто означает выполнение очень тяжелого запроса или переполнение внутреннего буфера памяти. Первым делом нам необходимо понять, на каком именно объекте споткнулась система.
Проанализируем ситуацию с помощью специализированных утилит. Для мониторинга работы конфигуратора в реальном времени рекомендуется использовать плагины ConfStat или GetConfMessages (авторства Абадонны). Эти инструменты позволяют увидеть, какой конкретно документ или справочник обрабатывается в данный момент, даже если основной индикатор выполнения в 1С замер.
Если мы видим, что процесс стоит на этапе "Подготовка данных для восстановления объектов, данные о которых частично утеряны", это сигнализирует о том, что система сканирует все таблицы базы в поисках ссылок на несуществующие ID. На больших базах этот процесс может занимать десятки часов из-за особенностей индексации.
Одной из скрытых причин зависания является некорректная работа с реквизитами типа Строка неограниченной длины. В SQL-версии 7.7 такие данные хранятся в отдельной системной таблице 1SBLOB. Рассмотрим механизм возникновения ошибки:
ЗначениеВСтрокуВнутр().1SBLOB.Для решения этой проблемы попробуем найти проблемный документ. Если с помощью ConfStat удалось определить тип документа, на котором происходит затык, проанализируем его содержимое. Если документ содержит слишком много строк, которые сериализуются в реквизит шапки, единственным выходом будет разбиение документа на несколько более мелких. Например, вместо одного документа на 3000 строк создадим три документа по 1000 строк. Это уменьшит размер данных в реквизите типа строка и позволит платформе успешно обработать объект.
Важный технический нюанс, который мы должны проверить: в SQL-версии 1С 7.7 крайне желательно, чтобы реквизиты с типом Строка неограниченной длины или Текст находились в самом конце списка реквизитов объекта в конфигураторе. Если после них идут обычные реквизиты (числа, даты, ссылки), это может приводить к ошибкам позиционирования курсора SQL при чтении записи, что также вызывает ложные зависания при тестировании базы.
Многие опытные администраторы считают запуск штатного Тестирования и исправления на больших SQL-базах «моветоном», так как этот процесс непрозрачен и может сам повредить базу. Вместо этого разберем использование набора SQL-скриптов, известных как скрипты от Z1.
Эти скрипты позволяют выполнить проверку и исправление базы гораздо быстрее и безопаснее напрямую средствами SQL Server:
1SENTRY (проводки) и 1SOPER (операции), которые ссылаются на отсутствующие записи в 1SJOURN.Если проблема зависания связана с пересчетом бухгалтерских итогов, не обязательно использовать ТиИ. Рассмотрим более эффективный алгоритм:
Воспользуемся средствами SQL для очистки таблиц итогов. Для этого выполним команду очистки для таблиц 1SBKTTL (остатки) и 1SBKTTLC (обороты):
TRUNCATE TABLE 1SBKTTL;
TRUNCATE TABLE 1SBKTTLC;
После этого необходимо запустить 1С в монопольном режиме и через меню "Операции — Управление бухгалтерскими итогами" выполнить полный пересчет. Этот метод работает в разы быстрее, чем штатное исправление через конфигуратор, так как исключает лишние проверки и использует оптимизированные механизмы записи SQL.
Если ваша база превышает 6 Гб, стандартный режим Выгрузить данные может упасть из-за ограничения в 2 Гб на размер выходного файла. Выясним, как это лечится:
.zip. Это надежнее и быстрее. Режим выгрузки в .dat стоит использовать только для перехода с SQL на DBF или при изменении кодировки базы.Подведем итог: если ТиИ зависает, не спешите прерывать процесс сразу, подождите и воспользуйтесь ConfStat. Если подтверждено зависание на конкретном объекте — проверьте его на наличие сверхдлинных строк. В остальных случаях отдавайте предпочтение прямым SQL-запросам для восстановления целостности данных.