В кругах специалистов, до сих пор обслуживающих классические базы данных на платформе 1С:Предприятие 7.7, бытует старый миф. Согласно ему, индексный файл журнала документов 1sjourn.cdx обязательно должен быть примерно в полтора раза больше, чем связанный с ним файл таблицы данных 1sjourn.dbf. Если же индекс оказывается меньше таблицы, это якобы свидетельствует о критическом повреждении базы данных или ее некорректной работе.
В рамках этой статьи мы подробно разберем, откуда взялось это утверждение, почему оно технически несостоятельно, от каких факторов на самом деле зависит размер файлов 1sjourn и как правильно оптимизировать этот важнейший узел файловой базы 1С 7.7.
Первоисточником этого заблуждения является публикация конца 2012 года в одном из популярных блогов системных администраторов, где автор безапелляционно утверждал: «Индекс журнала документов должен быть примерно в 1.5 раза больше самого dbf». Никаких серьезных математических или архитектурных выкладок в подтверждение этой теории не приводилось.
Профессиональное сообщество разработчиков 1С единогласно сошлось во мнении, что данное утверждение «взято с потолка» и является вредным. Оно заставляет администраторов выполнять ненужные действия и паниковать там, где база находится в абсолютно здоровом и оптимальном состоянии. Более того, путать поведение индексов журнала документов с индексами таблиц итогов регистров (где соотношение размеров действительно подчиняется определенным закономерностям из-за структуры хранения движений и остатков) — грубая техническая ошибка.
Чтобы понять, почему размеры файлов могут так сильно отличаться, проанализируем их внутреннюю структуру.
Файл 1sjourn.dbf — это физическая таблица, в которой хранятся заголовки абсолютно всех документов системы. Каждая строка этой таблицы содержит фиксированный набор полей, определенный структурой словаря данных 1cv7.dd:
# Пример структуры таблицы 1SJOURN в словаре данных 1cv7.dd
T=1SJOURN
Fields:
F=ROW_ID (Row ID)
F=IDDOC (Document ID)
F=DATE (Document Date)
F=TIME (Document Time)
F=CLOSED (Document Closed Flag)
F=ACTFLAGS (Activity Flags)
F=DOCNO (Document Number)
...
Файл 1sjourn.cdx — это мультииндексный файл формата *FoxPro/CodeBase*, который содержит сбалансированные деревья (B-Tree) для быстрого поиска и сортировки записей в таблице БД. Размер этого файла зависит исключительно от количества индексных тегов (ключей) и степени их фрагментации.
Выясним причины, по которым размер индекса может быть как значительно больше, так и значительно меньше размера самой таблицы данных.
Это самый главный фактор, определяющий объем индекса. Для журнала документов платформа всегда строит базовые системные индексы (по уникальному идентификатору IDDOC, по дате/времени и по номеру документа).
Однако, если в вашей конфигурации создано множество общих реквизитов документов (например, «Контрагент», «Склад», «Автор», «Фирма», «Проект») и для каждого из них в Конфигураторе установлен флаг «Отбор», система вынуждена создавать под каждый такой отбор отдельное индексное дерево. Индексный ключ в этом случае строится по составному выражению вида: Реквизит + Дата + Время + IDDOC.
Проанализируем две полярные ситуации:
1sjourn.cdx будет крайне мало. В этом случае размер файла 1sjourn.cdx гарантированно окажется меньше, чем 1sjourn.dbf. И это абсолютно нормально!1sjourn.cdx может стать в 2, 3 или даже 5 раз больше, чем файл таблицы 1sjourn.dbf.При интенсивной работе пользователей (создании новых документов, их проведении, изменении дат, пометке на удаление) B-деревья в файле 1sjourn.cdx начинают фрагментироваться. Движок базы данных не умеет автоматически сжимать освободившиеся страницы индекса. Из-за этого файл индекса постепенно накапливает «логический мусор» и раздувается.
Рассмотрим характерный пример: если просто удалить файл 1sjourn.cdx физически на уровне операционной системы, а затем запустить 1С в монопольном режиме для переиндексации, размер файла индекса может уменьшиться в несколько раз (например, с 900 МБ до 300 МБ). Это происходит потому, что новые индексные деревья строятся последовательно и без фрагментации.
Для файловой версии 1С 7.7 критически важен не коэффициент соотношения файлов, а их абсолютный физический размер. Движок баз данных DBF имеет строгое ограничение на размер одного файла:
.dbf) или индекса (.cdx) к отметке в 1 ГБ стабильность системы резко падает.Error#: -70. Reading file. File name ...CDX).Поскольку журнал документов 1sjourn является одной из самых быстрорастущих таблиц, переполнение индексного файла из-за избыточных отборов — частая причина краха крупных баз данных.
Для того чтобы обезопасить базу данных от сбоев и оптимизировать скорость ее работы, выполним три простых шага.
Рассмотрим структуру метаданных в Конфигураторе. Нам необходимо избавиться от тех индексов, которые реально не используются в работе предприятия.
Это действие моментально снизит нагрузку на дисковую подсистему при записи документов и радикально уменьшит финальный размер файла 1sjourn.cdx.
Штатная процедура переиндексации через меню 1С не всегда эффективно очищает структуру файлов. Проведем очистку правильно:
*.dbf и *.md)..cdx.После этой процедуры ваши индексные файлы приобретут максимально компактный и чистый вид.
Если после всех оптимизаций размер файлов продолжает неумолимо приближаться к опасной границе в 1–2 ГБ, то полумеры больше не помогут. В такой ситуации проанализируем два системных пути решения:
1С++) для отправки прямых T-SQL запросов в обход штатного движка 1С.Kernel3x от сторонних разработчиков), которые позволяют обходить ограничение размера файлов в 2 ГБ для файловой версии, однако этот метод несет в себе риски потери данных и требует высокой квалификации администратора.Подводя итог, отметим: не стоит обращать внимание на «мифические» пропорции файлов. Оценивайте реальное быстродействие системы, следите за абсолютными размерами ваших DBF/CDX таблиц, своевременно очищайте индексы от фрагментации и отключайте неиспользуемые отборы в конфигурации.