Рано или поздно любой администратор или программист, обслуживающий исторические базы на платформе 1С:Предприятие 7.7, сталкивается с необходимостью их свертки. Особую остроту эта проблема приобретает в конфигурации «Торговля и Склад» (ТиС) ред. 9.2, работающей в файловом режиме (DBF). Объем базы в 2 Гб для современных систем кажется незначительным, но для СУБД формата DBF движка CodeBase это критический порог, за которым начинаются серьезные технические сбои, замедление работы транзакций и многочасовая переиндексация.
В этой статье мы подробно рассмотрим, почему файловая база 1С 7.7 объемом 2 Гб требует незамедлительного вмешательства, проанализируем лучшие инструменты для свертки, разберем по шагам различные методики и выясним, как обойти основные подводные камни этого процесса.
---
Выясним причину, почему при объеме базы около 2 Гб пользователи начинают жаловаться на регулярные вылеты программы, а переиндексация на дисках HDD занимает до получаса и более. Дело в архитектурных ограничениях СУБД DBF и самой платформы 1С 7.7:
RA*.DBF), итогов регистров (RG*.DBF), общий журнал документов (1SJOURN.DBF) и таблица длинных строк/сообщений (1SBLOB.DBF). Приближение любого из этих файлов к отметке 2 Гб гарантированно вызывает неустранимые ошибки СУБД (например, "Codebase Error")..CDX может превышать объем самих данных. На медленных дисках HDD перестроение этих индексов занимает колоссальное время.---
Проанализируем наиболее надежный метод свертки запущенных и сильно переписанных баз. Вместо того чтобы запускать долгое и ресурсоемкое удаление документов в старой рабочей базе, мы перенесем справочники и актуальные остатки в абсолютно чистую информационную базу. Для этого отлично подходит специализированный комплекс «Свертка ИБ 7.7 Оперативный учет» (публикация на Инфостарт № 63400).
Рассмотрим этот процесс по шагам:
Создадим пустую папку для новой информационной базы. Скопируем туда из старой базы только файл конфигурации 1Cv7.MD, файл со списком пользователей Users\usrfiles.lst (и саму папку Users при наличии индивидуальных настроек) и файлы словаря данных 1Cv7.DD. Запустим новую базу в режиме Конфигуратора, чтобы система создала пустые таблицы DBF.
Запустим обработку свертки в старой базе. Данный инструмент позволяет:
В новой чистой базе запустим принимающую часть обработки. Она загрузит справочники и автоматически создаст специальные документы ввода остатков на дату свертки. Все движения по регистрам будут сформированы «красиво» и без накопленных исторических ошибок в структуре регистров.
Преимущества метода:
---
Если по каким-то причинам перенос в чистую базу нежелателен (например, в старой базе заведены сложные индивидуальные права, настроены специфические обработки во внешней папке или используются нетиповые объекты), можно выполнить свертку прямо «на месте». Для этого часто применяется «Свертка остатков ТиС 9.хх» (публикация на Инфостарт № 87199).
При использовании данного метода мы неизбежно столкнемся с технической особенностью платформы 1С 7.7. Разберем ее подробнее.
При формировании большого количества документов ввода остатков (по каждой фирме, складу, контрагенту, договору) обработка часто падает с системной ошибкой: «Номер не уникальный!».
Как решить эту проблему?
Перед запуском свертки обязательно измените рабочую дату в системе 1С на последний день сворачиваемого периода (например, 31.12.2020). Сделать это можно через меню «Сервис» — «Параметры» — «Рабочая дата» или программно в коде обработки:
// Пример программной установки рабочей даты в обработке
РабочаяДата(Контекст, '31.12.2020');
Установка даты на конец года позволяет обработке корректно генерировать новые номера документов ввода остатков в пределах выбранного года, не пересекаясь с нумерацией будущих или прошлых периодов. После успешной генерации документов остатков рабочую дату можно вернуть в исходное состояние.
---
Для опытных администраторов существует радикальный и очень быстрый способ ручной очистки, когда конфигурация практически типовая, а справочники необходимо сохранить в первозданном виде без долгого переноса.
Рассмотрим алгоритм действий:
DT*.DBF и DT*.CDX (табличные части документов);DH*.DBF и DH*.CDX (шапки документов);RA*.DBF и RA*.CDX (движения регистров);RG*.DBF и RG*.CDX (итоги регистров);1SJOURN.DBF и 1SJOURN.CDX (журнал документов).SC*.DBF) и файлы системных таблиц конфигурации.
---
Специфика оперативного учета в ТиС накладывает ряд ограничений, о которых необходимо знать заранее, чтобы не получить некорректно работающую систему после свертки.
Если граница последовательности находится глубоко в прошлом (например, в 2015 году), это означает, что в базе некорректно рассчитывалась себестоимость товаров, а партионный учет (FIFO/LIFO) фактически не велся или велся с грубыми ошибками (допускались минусовые остатки, пересортица).
При попытке запустить стандартную свертку система не сможет сопоставить партии списания. В итоге на остатках образуется «мусор», а документы поступления прошлых лет, которые выступают в роли партий, не смогут удалиться, так как на них будут ссылаться незакрытые остатки товаров.
Решение: Перед сверткой необходимо восстановить ГП хотя бы за последний год или воспользоваться обработкой, которая сворачивает регистр Партий «по факту», схлопывая все зависшие отрицательные и положительные остатки партий по методу средней стоимости.
В ТиС очень часто раздуваются регистры учета НДС (например, Регистр.НДС или книги покупок/продаж), которые менеджеры и бухгалтеры забывают закрывать регламентными документами. В итоге таблицы итогов этих регистров разрастаются до сотен мегабайт. Перед проведением свертки обязательно проанализируйте остатки по этим регистрам и закройте их «в ноль» с помощью ручных корректировок.
---
Если вы решили очищать базу непосредственно на месте, стандартное удаление документов через встроенный язык 1С может затянуться на сутки из-за постоянного контроля ссылочной целостности. Рассмотрим профессиональные приемы ускорения этого процесса.
С помощью внешних компонент (таких как 1С++ или ToySQL) мы можем обращаться к файлам базы напрямую в обход объектной модели платформы. Пометка документов на удаление в таблице 1SJOURN выполняется мгновенно с помощью простого запроса:
// Пример использования прямых запросов для пометки на удаление документов до даты свертки
Запрос = СоздатьОбъект("ODBCRecordset");
ТекстЗапроса = "
|UPDATE _1SJOURN
|SET CLOSED = 4 -- устанавливаем признак пометки на удаление
|WHERE DATE_TIME_IDDOC < '20210101';
|";
Запрос.Выполнить(ТекстЗапроса);
Это позволяет сократить время пометки сотен тысяч документов с нескольких часов до нескольких секунд.
После того как документы помечены на удаление и удалены программно в монопольном режиме, размер файлов базы данных на диске не изменится ни на один байт! Чтобы освободить место, необходимо физически переписать файлы DBF без удаленных строк.
Для этого запустите базу в режиме Конфигуратора, выберите пункт меню «Администрирование» — «Тестирование и исправление ИБ», установите флажок «Упаковка таблиц книг» (или воспользуйтесь утилитой «Тестирование и исправление» с обязательным выбором пункта очистки неиспользуемых записей) и запустите процесс. Только после этого файлы на диске реально уменьшатся в объеме.
---
Подводя итоги нашего анализа, сформулируем краткие рекомендации по выбору оптимального пути свертки: