Как ускорить процесс реструктуризации при добавлении нового журнала или документа в 1С 7.7?

← На главную

При работе с крупными базами данных на платформе 1С:Предприятие 7.7 администраторы и разработчики часто сталкиваются с проблемой: любое изменение структуры, связанное с журналами документов, приводит к многочасовому ожиданию. Обновление конфигурации может занимать 2 часа и более, что критично для работающего бизнеса. Разберем подробно причины такого поведения системы и рассмотрим эффективные методы ускорения этого процесса для SQL и DBF версий.

Понимаем причину задержки: роль таблицы 1SJOURN

Прежде чем приступать к оптимизации, проанализируем, что происходит "под капотом" системы. В архитектуре 1С 7.7 все заголовки всех документов (независимо от их вида) хранятся в одной единственной таблице — 1SJOURN. Когда мы добавляем новый журнал или новый вид документа, система инициирует перестройку этой таблицы.

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

Решение 1: Метод «фиктивной» реструктуризации для SQL-версий

Если вы используете SQL-версию базы данных, можно обмануть Конфигуратор, выполнив тяжелые операции вручную на стороне SQL-сервера. Рассмотрим этот алгоритм по шагам:

Подготовка шаблона: Создадим пустую базу с идентичной конфигурацией. Добавим в нее нужный журнал или документ и выполним сохранение.
Получение файлов: Из этой пустой базы возьмем обновленные файлы 1Cv7.md и 1Cv7.dd (или 1Cv7.dds для SQL). В файле .dd (текстовый файл описания структуры) найдем определения новых индексов, которые 1С планирует создать в таблице 1SJOURN.
Ручное создание индексов: Используя SQL Server Management Studio (SSMS), выполним SQL-запрос на добавление необходимых индексов в рабочую базу. Пример структуры запроса для создания индекса по новому журналу может выглядеть так:
```
CREATE INDEX [JOURNAL_NEW_IDX] ON [dbo].[1SJOURN] ([IDJOURNAL], [DATE_TIME_IDDOC])
WITH (ONLINE = ON, FILLFACTOR = 90);
```
Использование параметра ONLINE = ON (если позволяет редакция SQL Server) позволит пользователям продолжать работу во время построения индекса.
Подмена словаря: После того как индексы созданы вручную, мы просто заменяем старые файлы 1Cv7.md и 1Cv7.dd в папке рабочей базы на новые. Конфигуратор при следующем запуске увидит, что структура в SQL соответствует описанию в .dd, и не будет запускать длительный процесс пересоздания таблиц.

Решение 2: Оптимизация через RAM-диск для DBF-версий

Для файловых (DBF) баз данных основным ограничением является скорость дисковых операций ввода-вывода. При реструктуризации 1С создает папку NEW_STRU, куда копирует данные. Проанализируем, как это ускорить:

Использование виртуального диска: Установим специализированное ПО для создания RAM-диска (диск в оперативной памяти). Перенесем временные файлы системы (TEMP/TMP) и, если объем памяти позволяет, копию всей базы на этот диск. Скорость работы с памятью в десятки раз выше, чем с любым SSD.
Отключение антивируса: Это критически важный момент. При создании тысяч временных файлов .cdx антивирусное ПО сканирует каждый из них "на лету", увеличивая время обновления в 3–5 раз. Обязательно добавим папку базы и папку NEW_STRU в исключения перед началом процесса.

Решение 3: Прямая правка IDJOURNAL (Продвинутый уровень)

Рассмотрим ситуацию, описанную в сообщении 3 форума. Журнал в 1С 7.7 — это, по сути, фильтр по полю IDJOURNAL. Если вы понимаете структуру хранения, можно действовать следующим образом:

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


UPDATE [dbo].[1SJOURN]
SET [IDJOURNAL] = 'НовоеЗначение'
WHERE [IDDOCDEF] = 'ИД_Вашего_Типа_Документа';

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

Решение 4: Предварительная очистка и свертка

Проанализируем состояние базы перед обновлением. Длительность процесса напрямую зависит от количества строк в 1SJOURN. Если в базе хранятся документы за последние 10–15 лет, которые уже не нужны в оперативном доступе, стоит выполнить следующие действия:

Физическое удаление объектов: Удалим документы, помеченные на удаление. В 1С 7.7 они продолжают занимать место в таблице журналов до момента окончательного удаления.
Свертка базы: Перенесем остатки на начало текущего года, а старые документы удалим или перенесем в архивную базу. Это радикально сократит размер 1SJOURN и ускорит любые будущие обновления.

Важные нюансы: Общие реквизиты и Графы отбора

Выясним причину, почему иногда даже добавление одного маленького поля вызывает коллапс. Проанализируем настройки реквизитов:

Общие реквизиты: Если при создании нового документа или журнала вы добавляете "Общий реквизит" и включаете у него флаги "Сортировка" или "Отбор", это заставляет 1С перестраивать индекс всей таблицы 1SJOURN, добавляя туда новую колонку.

Графы отбора: Для ускорения работы журналов лучше использовать "Графы отбора" вместо общих реквизитов там, где это возможно. Добавление графы отбора технически проще отрабатывается системой, а при ручном подходе (Solution 1) добавление индекса по графе отбора в SQL занимает считанные минуты даже на миллионах записей.

Итоги и рекомендации

Для минимизации времени простоя рабочей базы рекомендуется всегда проводить "репетицию" на тестовой копии. Это позволит:

Замерить точное время штатной реструктуризации.
Получить эталонные файлы MD и DD для реализации метода ручной подмены.
Убедиться, что в 1SJOURN нет битых ссылок, которые могут прервать процесс на середине.

Помните, что любые прямые манипуляции с SQL-таблицами и файлами конфигурации требуют обязательного создания резервной копии базы данных перед началом работ.