← На главную

Свертка старых периодов («обрезка» базы данных) в платформе 1С:Предприятие 7.7 — это классическая, но весьма трудоемкая задача. Часто администраторы и разработчики сталкиваются с ситуацией, когда штатный документ ввода остатков, содержащий десятки тысяч строк номенклатуры и партий, «подвисает» на этапе проведения. Процесс может длиться часами или даже сутками, создавая иллюзию бесконечного зависания системы. В этой статье мы подробно разберем технические причины такого поведения СУБД, рассмотрим строгие физические ограничения формата DBF и предложим пошаговые методики оптимизации процесса свертки.

Причина 1. Физическое ограничение поля LINENO в формате DBF (Опасность превышения 9999 строк)

Многие начинающие специалисты пытаются выгрузить все остатки по складу в один единственный документ, например ВводОстатковТМЦ, содержащий 20 000, 50 000 или даже 100 000 строк. В файловой версии базы данных (DBF) это действие гарантированно приведет к скрытому повреждению структуры данных.

Давайте проанализируем физическую структуру таблиц базы данных 1С 7.7. Информация о табличных частях документов хранится в файлах с маской имени DT*.dbf (где вместо звездочки указан внутренний идентификатор объекта метаданных). В любой такой таблице поле номера строки называется LINENO. На уровне платформы это поле жестко определено как числовое с длиной 4 символа и точностью 0 (в терминах СУБД это формат N 4.0).

Это накладывает жесткое ограничение на максимальное числовое значение, которое может быть записано в физический файл. Максимальное число, помещающееся в четырехразрядное поле, — это 9 999. Если ваш документ содержит больше строк, в оперативной памяти платформа продолжит корректно обрабатывать индексы, но при записи транзакции на диск начнутся критические аномалии:

1. Номера строк свыше 9999 запишутся в файл DT*.dbf либо как нулевые значения, либо заполнятся символами звездочек (в DBF-редакторах это выглядит как ****).
2. При первой же попытке выполнить штатную процедуру «Тестирование и исправление» (ТиИ) в Конфигураторе система выдаст критическую ошибку: «Поле LINENO. Неверное содержимое поля Numeric». Утилита попытается принудительно перенумеровать строки, что нарушит внутреннюю логику подчинения и связей документов.
3. Если в будущем эту файловую базу потребуется перевести на SQL-версию (MS SQL Server), **процесс конвертации полностью заблокируется**. СУБД строго контролирует уникальность первичных ключей, строящихся по связке полей (IDDOC, LINENO). Повторяющиеся нулевые значения или некорректные символы вызовут ошибку дублирования индексов.

Таким образом, создание документов ввода остатков объемом более 9 999 строк категорически запрещено архитектурой платформы 1С 7.7.

Причина 2. Экспоненциальное замедление транзакций при проведении крупных документов

Зависимость времени проведения одного документа от количества строк в 1С 7.7 является **нелинейной (экспоненциальной)**. Проанализируем, почему документ на 10 000 строк проводится в десятки раз дольше, чем десять документов по 1 000 строк.

При проведении документа платформа инициирует транзакцию, в рамках которой выполняются следующие ресурсоемкие операции:

• Блокировка таблиц регистров для предотвращения параллельной записи другими пользователями.
• Выполнение временного расчета остатков по регистрам «на лету» для контроля отрицательных остатков по каждой строке.
• Запись новых движений в файлы движений регистров (таблицы RA*.dbf) и обновление таблиц итогов (RG*.dbf).

Чем больше строк обрабатывается в рамках одной транзакции, тем сильнее разрастаются временные индексы в оперативной памяти и тем медленнее операционная система производит дисковые операции записи-чтения в DBF-файлы. Более того, при работе с СУБД DBF отсутствует полноценное кэширование транзакций на уровне сервера (как в MS SQL), что приводит к лавинообразному росту нагрузки на дисковую подсистему.

Решение 1. Разбиение документов на оптимальные пакеты по 1000–3000 строк

Опираясь на практический опыт администраторов, наиболее эффективным решением является разбиение общего объема остатков на несколько документов меньшего размера. Оптимальный «золотой стандарт» для одного документа ввода остатков составляет **от 1 000 до 3 000 строк**.

Разберем, как правильно организовать это разделение:

1. Разделение по складам и местам хранения. Не пытайтесь объединить остатки разных складов в один документ. Сделайте отдельные документы для каждого склада. Это существенно упростит последующую сверку данных.
2. Разделение по группам товаров или свойствам. Группируйте номенклатуру по товарным категориям. Например, автозапчасти можно разделить по брендам или типам деталей.
3. Строгий лимит на количество строк. При написании обработки выгрузки/загрузки остатков обязательно внедрите счетчик строк. Как только счетчик достигает отметки, например, 2 000 строк, обработка должна программно записать текущий документ, создать новый документ ВводОстатковТМЦ и продолжить заполнение в нем.

Практика показывает, что 100 документов по 1 000 строк проведутся суммарно за 10–15 минут, в то время как один огромный документ на 100 000 строк гарантированно зависнет на 14 и более часов или вызовет аварийное завершение работы платформы.

Решение 2. Сверхбыстрое проведение через временный перенос Точки Актуальности (ТА)

Основная причина медленной записи движений при проведении документов ввода остатков «задним числом» — необходимость пересчета итогов регистров вперед во времени. Если реальная рабочая Точка Актуальности (ТА) базы находится на текущем дне (например, 2026 год), а вы вводите остатки на дату свертки 5 лет назад (например, 2021 год), система вынуждена последовательно пересчитать и переписать итоги во всех последующих периодах (месяцах) между 2021 и 2026 годами.

Чтобы избежать этой бесполезной и тяжелой вычислительной работы, выполните следующие шаги:

1. Убедитесь, что в базе нет активных пользователей. Переведите базу в монопольный режим.
2. Перенесите Точку Актуальности (ТА) назад во времени — установите ее ровно на дату, предшествующую дате ввода остатков (например, на конец дня перед началом нового учетного периода). Это можно сделать в режиме «Монитор пользователей» (пункт меню «Управление точкой актуальности»).
3. Запустите проведение ваших подготовленных документов ввода остатков (разбитых по 1 000 – 3 000 строк). Поскольку ТА находится рядом с датой документов, проведение выполнится практически мгновенно, так как платформе не придется пересчитывать итоги за будущие годы.
4. После успешного проведения всех документов ввода остатков перенесите ТА обратно на текущую рабочую дату. При переносе ТА вперед выберите режим «Без перепроведения документов» (или снимите флаг «Совмещать проведение с переносом ТА»), чтобы система просто зафиксировала новые итоги на текущую дату, не пытаясь повторно перепроводить старые документы.

Решение 3. Метод «хирургической» свертки (создание чистой базы)

Если база данных сильно перегружена историческими данными, стандартная процедура удаления старых документов через пометку на удаление и непосредственное удаление объектов может занять дни и вызвать критический рост индексов. В таких случаях гораздо эффективнее применить метод «хирургического» переноса данных в чистую базу:

1. Создайте резервную копию вашей рабочей информационной базы.
2. Сделайте копию структуры метаданных (файл 1Cv7.MD) и конфигурационных файлов, чтобы создать абсолютно новую, пустую базу данных.
3. С помощью специализированных обработок выгрузки-загрузки данных (например, стандартной обработки XML-обмена или правил переноса) перенесите из старой базы в новую только справочники (номенклатуру, контрагентов, договоры, склады и т.д.). Историю документов переносить не нужно.
4. В старой базе запустите обработку, которая соберет чистые остатки по регистрам на дату свертки и выгрузит их во внешний текстовый файл или таблицу DBF.
5. В новой пустой базе запустите обработку загрузки, которая прочитает этот файл и создаст пакеты документов ВводОстатковТМЦ (лимитированные по 2 000 строк на документ).
6. Проведите эти документы в новой базе. Так как в ней нет истории транзакций и лишних движений, проведение пройдет за считанные минуты.

Этот подход не только решает проблему скорости проведения, но и позволяет кардинально уменьшить физический размер файлов базы данных (иногда в 5–10 раз), полностью очистить базу от накопившегося за годы работы «мусора» и битых ссылок.

Опасный путь: Изменение периодичности хранения остатков (период в 5 дней)

В процессе обсуждения оптимизации производительности часто возникает предложение изменить периодичность сохранения итогов регистров в Конфигураторе (например, установить шаг хранения остатков не в 1 месяц, а в 5 дней). На первый взгляд, это должно ускорить расчет остатков на произвольную дату за счет уменьшения интервала вычислений.

Однако для файловых баз DBF этот шаг несет в себе **огромные скрытые риски**. Давайте разберем, почему этого делать не стоит:

• При уменьшении периода с 1 месяца до 5 дней количество записей в таблицах хранения итогов (файлы RG*.dbf) увеличится примерно в 6 раз.
• В операционной системе и самом формате DBF существует жесткое ограничение на максимальный размер одного физического файла — **2 ГБ**.
• Если у вас большой ассортимент товаров (например, автозапчасти с активной номенклатурой от 30 000 до 50 000 позиций), файлы итогов регистров RG*.dbf из-за пятидневной детализации мгновенно перешагнут двухгигабайтный порог.
• Как только размер файла достигнет 2 ГБ, база данных необратимо заблокируется с критическими ошибками записи (такими как Error -120 или Error -100), и восстановить ее работоспособность стандартными методами будет невозможно.

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