Что растёт в базе 1С помимо документов

Когда база 1С разрослась, первый инстинкт - обвинить документы: “десять лет продаём, вот и накопилось”. Иногда так и есть. Но на больших базах гораздо чаще основную массу занимают не данные бизнеса, а служебные структуры платформы и конфигурации, о которых обычно никто не думает. Пока их не видно, оптимизация превращается в гадание.

На одном из наших проектов (розничная сеть, база 4,2 ТБ) больше 90 % объёма оказалось служебным кэшем механизма разграничения доступа, а вовсе не документами. Ниже - каталог того, что реально растёт в базе кроме документов, с признаками, по которым это распознать.

Начните с карты, а не с догадок

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

Строится такая карта из двух источников, и отвечают они на разные вопросы. Обработка Карта объёмов базы 1С проходит по объектам метаданных и служебным таблицам платформы и показывает число записей и долю каждого объекта рядом с оценкой объёма по объявленным типам реквизитов, то есть говорит, где искать. Сколько таблица весит на самом деле, знает только СУБД: запросы для этого собраны ближе к концу статьи, в разделе про реальный вес.

Что карта по метаданным умеет и чего не умеет

Насколько такой карте можно верить, мы проверили в августе на своей же обработке. Взяли недельную копию рабочей базы УПП заказчика, 3 446,7 ГБ файлов данных, посчитали оценку тем же алгоритмом, что стоит в карте, и сверили с размерами из СУБД. Строк, где есть и оценка, и настоящий размер, набралось 932.

Вопрос к карте	Что показал замер
Совпала ли пятёрка самых тяжёлых таблиц	0 из 5
Первая десятка	3 из 10, после поправки на ширину записи 4 из 10
Первая двадцатка	10 из 20
Сколько из настоящей десятки попало в первые 30 строк оценки	7 из 10, в первые 50 строк 9 из 10
Первая сотня	81 из 100
Отношение факта к оценке по строкам	медиана 1,15; у каждой десятой строки оценка завышена вчетверо и больше, ещё у каждой десятой занижена вдвое и больше

Корреляция Спирмена по всем 932 строкам 0,907 и смотрится знаком качества, но среди первых 50 таблиц по факту она падает до 0,484. Согласие набирают мелкие таблицы в хвосте, где порядок угадать легко, а в верхушке, ради которой карту и открывают, он разваливается.

Промах зависит от ширины записи. Узкие таблицы до 100 байт, где лежат ссылки, числа и даты, оценка занижает: медиана факта к оценке у них 1,58, потому что служебные колонки платформы и накладные расходы страницы в расчёт не попадают. Таблицы шире 3 200 байт она завышает, медиана 0,13, потому что строка считается по объявленной длине, а на диске занимает столько, сколько в неё записали. Худший случай верхушки - табличная часть “Контакты” на 207 млн записей: по оценке 244 ГБ и первое место в списке, на диске 19 ГБ. Поправка на ширину почти не помогает: заполненность строк у каждой таблицы своя, из метаданных её не вывести.

Вывод для работы: карта хороша как фильтр кандидатов и плоха как рейтинг. Кандидатов берите с запасом, строк 30-50, а место в списке ответом не считайте. Замер у нас один и база одна, поэтому сверьте на своей: первые десять таблиц по запросу из конца статьи против первых десяти строк карты. Дальше по списку - что в такой карте чаще всего оказывается наверху.

Кэш механизма разграничения доступа (RLS)

Главный чемпион по незаметному росту. Универсальный механизм ограничения доступа на уровне записей (RLS в терминах БСП) - это большой материализованный кэш прав. Как любой кэш, он требует инвалидации: каждое изменение ролей, профилей или состава пользователей ставит в очередь задания на пересчёт ключей доступа.

Пока регламентные задания пересчёта работают, очереди перемалываются и система в равновесии. Но если задания однажды выключить (частый случай - “пересчёт грузил сервер, отключили”), механизм не останавливается. Он продолжает ставить задачи в очередь, которые больше никто не забирает, и накапливать версии шаблонов ограничений, которые больше никто не читает. Ошибок при этом ноль: просто через несколько лет у вас две очереди по миллиарду строк и терабайты истории версий.

Как распознать: в карте объёмов в топе по размеру регистры сведений подсистемы доступа: ключи доступа к объектам, очереди обновления ключей, история ограничений. В СУБД это обычные таблицы вида _InfoRgNNN, по имени таблицы их не узнать. Что делать: осторожно, кэш нельзя просто снести, пока RLS работает через универсальный механизм - сначала база переводится на классический отбор в запросах, и только потом кэш становится по-настоящему мёртвым и безопасно удаляемым. Это отдельный проект с проверкой матрицы прав, а не “удалить и разойтись”.

История версий объектов

Механизм версионирования объектов хранит каждую редакцию документа или справочника: кто, когда и что изменил. Штука полезная для аудита, но если версионирование включено широко и хранится вечно, регистр версий растёт быстрее самих объектов - у одного документа могут быть десятки версий.

Как распознать: регистр сведений с версиями объектов в топе карты. Что делать: настроить срок хранения версий и состав версионируемых объектов. Часто версионирование включено “на всё подряд” по умолчанию, хотя реально нужно на десяток ключевых документов.

Итоги регистров накопления и бухгалтерии

Итоги - это предрассчитанные остатки на каждый период, чтобы отчёты не пересчитывали историю с нуля. Нужная вещь, но у неё есть цена в объёме: чем больше периодов хранится и чем детальнее аналитика, тем толще таблицы итогов. Плюс включённое разделение итогов (нужное для параллельной записи) тоже добавляет строк.

В карте по метаданным итогов не видно: своих объектов в дереве конфигурации у них нет, и оценка считает таблицу движений. На той же копии УПП вне карты целиком остались 225 таблиц итогов, оборотов, значений субконто и журналов документов, в них 582,1 ГБ данных и 533,9 ГБ индексов. Регистр бухгалтерии вместе с итогами и субконто занимал 448 ГБ данных, оценка дала ему 30,7 ГБ, в 14,6 раза меньше.

Как распознать: таблицы итогов регистров сопоставимы по размеру с таблицами движений или больше. Что делать: проверить глубину хранения итогов и не держать их за периоды, которые давно закрыты и не запрашиваются.

Хранилища значения и неограниченные строки

Если в хранилище значения или в неограниченную строку положили что-то крупное, СУБД держит это отдельно от основных страниц таблицы, в LOB. Объявленного размера у такого реквизита нет: в нём бывает и пустая структура, и присоединённый файл на десятки мегабайт, поэтому оценка по метаданным тут бессильна в принципе. На копии УПП из замера в LOB лежало 234,2 ГБ. Отсюда и самый большой промах замера: регистр сведений на 18 тысяч записей занимал 46 ГБ при оценке 0,06 ГБ, в 745 раз больше, и в списке карты стоял на 358-м месте, до которого никто не дочитывает.

Как распознать: у таблицы единицы мегабайт основных страниц и десятки гигабайт LOB, это показывает второй запрос из раздела про реальный вес. Что делать: выяснить, что пишут в этот реквизит и сколько это нужно хранить; объём такой таблицы считается только в СУБД.

Индексы: вторая половина объёма

Индексов карта не считает совсем, хотя весят они сопоставимо с данными. На той же копии индексы добавляли 61 % к данным по таблицам, которые есть в карте, и 71 % по всей выборке из 1 157 таблиц. У отдельных таблиц доходило до +645 %, то есть индексы весили в шесть с лишним раз больше самих записей. В разговоре “почему база 3,4 ТБ” это половина ответа, и в карте её нет.

С объёмом связан и другой частый вопрос: почистили половину записей, а файл базы не уменьшился. Удаление освобождает место внутри файла, а сам файл остаётся прежнего размера, пока его не сожмут. Как это делают и чем за это платят, разобрано в SQL-версии обрезки базы.

Как распознать: в первом запросе из раздела про реальный вес у таблицы index_to_data больше единицы. Что делать: место под базу и эффект чистки считать по данным вместе с индексами, иначе прогноз выйдет заниженным.

Журнал регистрации

Отдельная история, потому что журнал регистрации обычно лежит в файлах платформы, отдельным каталогом с логами рядом с базой. Но растёт он не менее агрессивно: нагруженная база пишет десятки, а то и сотни миллионов событий в сутки, каждое по несколько сотен байт. Гигабайты в день на дисках сервера.

Как распознать: каталог журнала регистрации на сервере весит сотни гигабайт, просмотр журнала из конфигуратора виснет. Что делать: настроить периодичность и состав событий, а на действительно нагруженных базах - выносить журнал во внешнее хранилище. Подробный разбор - в статье про разросшийся журнал регистрации.

Полнотекстовый индекс и прочее служебное

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

Как распознать: в карте объёмов служебные таблицы платформы, за которыми не стоит ни один объект метаданных из конфигуратора. Что делать: разбирать по одному, начиная с самых крупных; часть чистится штатными средствами, часть говорит о неверных настройках механизмов.

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

Как увидеть реальный вес

Запросы ниже для MS SQL, для PostgreSQL они пишутся иначе. Оба только читают системные представления, базу для них останавливать не нужно.

Первый запрос отдаёт по каждой таблице строки, данные и индексы, самые тяжёлые сверху:

USE [YourDb];  -- представления ниже видят только текущую базу

SELECT TOP (50)
    t.table_name,
    t.rows_cnt,
    t.data_pages * 8 / 1024  AS data_mb,
    t.index_pages * 8 / 1024 AS index_mb,
    CAST(t.index_pages * 1.0 / NULLIF(t.data_pages, 0) AS decimal(9, 2)) AS index_to_data
FROM (
    SELECT
        o.name AS table_name,
        -- строки берём по куче или кластерному индексу, иначе они умножатся на число индексов
        SUM(CASE WHEN ps.index_id IN (0, 1) THEN ps.row_count ELSE 0 END)       AS rows_cnt,
        SUM(CASE WHEN ps.index_id IN (0, 1) THEN ps.used_page_count ELSE 0 END) AS data_pages,
        SUM(CASE WHEN ps.index_id > 1 THEN ps.used_page_count ELSE 0 END)       AS index_pages
    FROM sys.dm_db_partition_stats AS ps
    JOIN sys.objects AS o ON o.object_id = ps.object_id
    WHERE o.type = 'U'
    GROUP BY o.name
) AS t
ORDER BY t.data_pages + t.index_pages DESC;

Второй отделяет LOB от основных страниц: в sys.allocation_units тип 1 означает IN_ROW_DATA, 2 это LOB_DATA, 3 это ROW_OVERFLOW_DATA.

USE [YourDb];

SELECT TOP (30)
    o.name AS table_name,
    SUM(CASE WHEN au.type = 1 THEN au.used_pages ELSE 0 END) * 8 / 1024 AS in_row_mb,
    SUM(CASE WHEN au.type = 2 THEN au.used_pages ELSE 0 END) * 8 / 1024 AS lob_mb,
    SUM(CASE WHEN au.type = 3 THEN au.used_pages ELSE 0 END) * 8 / 1024 AS row_overflow_mb
FROM sys.allocation_units AS au
JOIN sys.partitions AS p
    ON (au.type IN (1, 3) AND au.container_id = p.hobt_id)
    OR (au.type = 2 AND au.container_id = p.partition_id)
JOIN sys.objects AS o ON o.object_id = p.object_id
WHERE o.type = 'U'
  AND p.index_id IN (0, 1)  -- сама таблица, без некластерных индексов
GROUP BY o.name
HAVING SUM(CASE WHEN au.type IN (2, 3) THEN au.used_pages ELSE 0 END) > 0
ORDER BY SUM(CASE WHEN au.type IN (2, 3) THEN au.used_pages ELSE 0 END) DESC;

Про общий инстанс: оба запроса читают представления текущей базы, и фильтр по базе здесь делает USE. Запущенные из master или из соседней базы, они покажут чужую карту, вполне правдоподобную на вид. Серверным представлениям вроде sys.dm_db_index_usage_stats, если добавите их к запросу, нужен явный WHERE database_id = DB_ID().

Имена вида _AccumRgT12345 переводит в объекты конфигурации сама платформа:

// Карта "таблица СУБД -> объект 1С" в CSV, чтобы соединить её с результатом запросов.
// Выполняется на сервере. Истина во втором параметре: имена в терминах СУБД.
Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
ИмяФайла = ПолучитьИмяВременногоФайла("csv");
Запись = Новый ЗаписьТекста(ИмяФайла, КодировкаТекста.UTF8);
Запись.ЗаписатьСтроку("table_name;metadata;purpose");
Для Каждого СтрокаСтруктуры Из Структура Цикл
    Запись.ЗаписатьСтроку(СтрокаСтруктуры.ИмяТаблицыХранения + ";"
        + СтрокаСтруктуры.Метаданные + ";" + СтрокаСтруктуры.Назначение);
КонецЦикла;
Запись.Закрыть();
Сообщить("Карта имён: " + ИмяФайла);

Второй параметр переключает только термины. С Истина имена приходят такими, какими их видит СУБД, без него - в терминах модели 1С, и с результатом SQL они не сойдутся: на нашей тестовой базе одна и та же таблица пришла как Document562 и как _Document562X1. Итоги и обороты регистров попадают в результат отдельными строками со своим назначением при любом значении параметра. Объект берите из колонки Метаданные: у таблиц итогов ИмяТаблицы приходит пустым, на нашей тестовой базе так было во всех 69 строках итогов.

Итог

Раздутая база 1С - это почти всегда повод сначала посмотреть, а потом действовать. Очень часто оказывается, что документы бизнеса занимают меньшую часть, а основной вес - служебные структуры: кэш разграничения доступа, история версий, итоги, журнал. Ни одно из этого не чинится вслепую: кэш RLS нельзя удалить без перевода на классический механизм, версии и итоги настраиваются, журнал выносится. Но всё начинается с одного шага - увидеть реальную картину.

Порядок такой: карта объёмов даёт кандидатов, вес подтверждает СУБД запросами из раздела выше, и только после этого решается, что чистить. Если в подтверждённом топе стоит что-то служебное, а не ваши документы, посмотрите нашу услугу свертки и обрезки базы 1С: мы разбираем такие базы с диагностики, а не с удаления наугад. Быстрый старт - бесплатный экспресс-аудит.