← На главную

Ошибки вида «Превышен максимальный размер файла» или аварийное завершение работы платформы при пересчете итогов в 1С 7.7 — классический симптом разрастания файлов таблиц итогов регистров (файлы с префиксом RG). Рассмотрим подробно, почему происходит этот процесс и какими техническими методами можно остановить рост и восстановить работоспособность базы данных.

Причины роста файла итогов и технологические ограничения DBF

Выясним причину, почему опухает именно таблица итогов RG. В платформе 1С 7.7 механизм работы с регистрами накопления и партий построен следующим образом:

1. Перенос остатков при смене периода: При наступлении нового расчетного месяца платформа автоматически переносит все незакрытые остатки из прошлого месяца в новый. Если запись не закрылась в ноль, она будет дублироваться в каждом последующем периоде.
2. Рассинхронизация измерений: Главная причина постоянного роста таблицы итогов — несовпадение аналитики при приходе и расходе. Например, документ оприходования записывает движение с указанием конкретного документа поставки или контрагента, а документ списания оставляет эти измерения пустыми. В результате возникают две бесконечно тянущиеся записи: одна с плюсовым остатком, другая — с минусовым.
3. Ограничение движка CodeBase (2 Гб): Файловый формат .DBF в 32-битной платформе 1С 7.7 имеет жесткий физический предел размера одного файла в 2 147 483 647 байт (2 Гб). Это ограничение касается как файлов данных, так и их индексов .CDX. Никакие патчи не способны обойти это базовое ограничение в файловом режиме.

Вариант 1. Оптимизация структуры движений и исправление аналитики

Рассмотрим порядок действий по поиску и исправлению перекосов аналитики в движениях регистра (таблица RA):

1. Анализ измерений регистра: Проанализируем состав измерений регистра накопления (например, ПартииТоваров). Если такие измерения, как Контрагент, Поставка, Статус или Склад, не закрываются в ноль при расходе, они создают постоянный прирост записей.
2. Заполнение пропущенных измерений в движениях: С помощью прямого выполнения SQL-запросов или библиотек работы с DBF (например, через VFP OLEDB) найдем и исправим незаполненные реквизиты в движениях:
   1. Найдем все записи в RA, где не заполнен документ прихода (ПрихДокумент), и проставим нужные ссылки.
   2. Заполним пустые значения реквизита Склад в движениях списания.
   3. Заполним реквизит Поставщик на основании первичного документа поступления.
3. Удаление лишних измерений: Измеряемые разрезы, которые не критичны для получения оперативных остатков (например, дублирующие реквизиты контрагентов или статус), целесообразно перенести из измерений в реквизиты регистра. Это предотвратит дробление итоговых записей.

Вариант 2. Закрытие «хвостов» датой их возникновения

Типичная ошибка при попытке зафиксировать зависшие копеечные суммы или нулевое количество — проведение корректирующего документа текущей датой. Разберем, почему это не помогает уменьшить размер RG:

Если списать копейки текущим числом, все предыдущие месяцы (начиная с 2003 года и по сей день) так и останутся наполненными незакрытыми записями. Чтобы очистить итоги, списывать зависшие хвосты необходимо строго датой (периодом) их появления.

После проведения корректировок прошлыми периодами необходимо выполнить процедуру сжатия и очистки пустых итоговых записей. В файловом режиме для окончательного удаления помеченных записей из DBF требуется монопольная упаковка таблиц (процедура PACK).

Вариант 3. Перевод базы данных на MS SQL Server

Если у предприятия действительно сохраняются реальные физические остатки товаров по партиям многолетней давности и удалять историю нельзя, файловый режим исчерпывает свои возможности. В этом случае единственным стабильным решением является перевод базы 1С 7.7 на MS SQL Server.

Проанализируем ключевые настройки MS SQL Server, необходимые для корректной и быстрой работы базы 1С 7.7 с большими регистрами:

1. Настройка степени параллелизма: Чтобы избежать взаимных блокировок и подвисания тяжелых запросов к итогам, выставим параметр max degree of parallelism в значение 1:
   Скопировать код

   
   sp_configure 'show advanced options', 1;
   GO
   RECONFIGURE;
   GO
   sp_configure 'max degree of parallelism', 1;
   GO
   RECONFIGURE;
   GO
   

2. Параметры автороста файлов (Autogrowth): Зададим приращение размера файла базы данных и журнала транзакций в фиксированных мегабайтах (например, по 512 Мб), а не в процентах. Это предотвратит дефрагментацию диска при частых расширениях.
3. Модель восстановления (Recovery Model): Для снижения нагрузки на диск и предотвращения гигантского роста лога транзакций (файл .LDF) при выполнении пересчета итогов установим простую модель восстановления — Simple. При необходимости частых бэкапов можно использовать модель Full, но с регулярным сжатием и резервным копированием журнала транзакций.

После перевода базы на MS SQL Server пересчет итогов больших регистров будет выполняться существенно быстрее за счет оптимизатора T-SQL, а ограничение на размер файла 2 Гб перестанет блокировать работу пользователей.