Процесс внесения изменений в конфигурацию 1С:Предприятие 7.7 часто превращается в испытание для системных администраторов и программистов, особенно на больших базах данных. Мы привыкли, что простое добавление реквизита может занять минуты, а удаление неиспользуемого вида документа — растянуться на долгие часы. В этой статье мы подробно проанализируем, что именно происходит «под капотом» платформы во время реструктуризации, почему возникают задержки и как можно оптимизировать этот процесс.
Рассмотрим базовый принцип, по которому 1С 7.7 работает с таблицами базы данных при изменении метаданных. В отличие от современных систем управления базами данных, которые часто используют быстрые команды изменения структуры, платформа 7.7 ведет себя консервативно. При изменении типа реквизита, добавлении или удалении объекта метаданных платформа практически никогда не использует команду ALTER TABLE в ее эффективном виде (особенно в SQL-версии).
Проанализируем стандартный алгоритм работы платформы:
INSERT INTO ... SELECT).Такой подход означает, что если ваша таблица проводок 1SENTRY или таблица движений регистров RA* весит десятки гигабайт, время реструктуризации будет прямо пропорционально объему этих данных. Фактически происходит полная перезапись всей таблицы и полная перестройка всех ее индексов.
Часто возникает вопрос: почему при удалении вида документа, которого гарантированно нет в базе, процесс поиска ссылок длится бесконечно? Разберем эту ситуацию подробнее. Платформа 1С 7.7 обладает определенной «паранойей» в вопросах целостности данных. При удалении любого типа объекта (справочника или документа) запускается глобальный поиск ссылок на него.
Основная проблема заключается в существовании реквизитов с типом «Неопределенный». В структуре таблиц SQL такой реквизит представлен полем типа CHAR(13), где первые 4 символа определяют тип объекта (ID типа метаданных), а остальные 9 — его уникальный идентификатор. Платформа обязана просканировать каждую таблицу в базе данных, где есть хотя бы одно поле типа «Неопределенный», чтобы убедиться, что в нем не встречается ID удаляемого типа. Этот поиск выполняется не эффективным групповым запросом, а последовательным перебором таблиц, что и порождает многочасовые ожидания.
Также стоит учитывать таблицу 1SCRDOC (таблица общих ссылок и подчиненных документов) и общие журналы 1SJOURN. Проверка наличия IDDOCDEF (идентификатора вида документа) в этих таблицах происходит всегда, независимо от реального наличия записей данного вида.
При изменении структуры регистров накопления (добавление измерений или ресурсов) основная нагрузка ложится на пересчет таблиц итогов (таблицы с префиксом RG). Выясним причину, почему это происходит так долго:
RG* полностью очищается.RA* за все периоды.Важно помнить, что при нормально закрытых регистрах время пересчета обычно линейно, но любая ошибка в логике движений может привести к тому, что штатный механизм пересчета просто зависнет.
В процессе реструктуризации в каталоге базы данных и в подкаталоге NEWSTRU создается служебный файл 1srecalc.cmd. Это текстовый документ, в котором платформа записывает команды на выполнение отложенных операций: пересчет итогов, поиск ссылок, пересчет граф отбора в журналах.
Важный нюанс: если вы понимаете, что платформа выполняет бессмысленную работу (например, ищет ссылки на удаленный пустой документ), технически можно прервать процесс, удалить файл 1srecalc.cmd и запустить систему. Словарь данных 1cv7.dd к этому моменту уже может быть обновлен. Однако это крайне рискованная операция. Если вы удалите файл перед необходимым пересчетом итогов регистров, вы получите пустые остатки в отчетах. Используйте этот метод только в тех случаях, когда вы четко понимаете структуру хранения данных (например, при удалении метаданных).
Для больших баз данных на SQL профессионалы часто используют метод «ручной» правки структуры, чтобы избежать многочасового простоя. Рассмотрим этот алгоритм по шагам:
1cv7.md) в пустой папке.1cv7.md и актуальный файл словаря данных 1cv7.dd (для SQL) или 1cv7.dds.
ALTER TABLE [ИмяТаблицы] ADD [ИмяРеквизита] [ТипДанных];
Эта операция выполняется практически мгновенно даже на миллионах записей.
1cv7.md и 1cv7.dd на подготовленные из пустой базы.После такой манипуляции платформа «считает», что реструктуризация уже прошла успешно, так как физическая структура таблиц теперь совпадает с описанием в словаре данных. Это позволяет избежать полного пересоздания таблиц и копирования данных.
Проанализируем ситуацию, когда изменения касаются только программного кода или форм, не затрагивая структуру хранения данных. В таких случаях реструктуризация вообще не требуется. Для динамического обновления кода без выгона пользователей рекомендуется использовать внешние компоненты, такие как turbomd.dll. Это позволяет подгружать изменения «на лету».
Если же необходимо добавить отбор в журнал документов, помните, что это приведет к обновлению таблицы 1SJOURN. Проанализируем колонки RF* в этой таблице — именно они отвечают за быстрые фильтры. Если база в формате DBF, добавление отбора часто вызывает полную переиндексацию, что может привести к порче файлов при больших объемах. В таких случаях иногда проще внести изменения в структуру DBF-файла сторонними утилитами и подсунуть обновленный словарь .dds.
Подводя итог, можно сказать, что понимание внутреннего устройства таблиц 1С 7.7 (таких как 1SJOURN, 1SCRDOC, RA/RG) позволяет не только прогнозировать время реструктуризации, но и обходить штатные ограничения платформы, экономя время при обслуживании крупных информационных систем.