Исходная ситуация
Розничная сеть fashion-сегмента: три страны, около 200 касс, 11 боевых баз 1С (Розница + ERP). Главная база выросла до 4,2 терабайта и продолжала расти быстрее бизнеса. Ночной полный бэкап занимал 2 часа и весил 556 ГБ в сжатом виде; места на дисках почти не оставалось. Параллельно жаловались кассиры: списки открывались десятками секунд, в вечерний пик закрытие смен “залипало”. И всё это - на общем SQL-сервере, который делят десятки баз.
Диагностика: самая важная часть проекта
Две недели ушло на карту “что сколько занимает” - связку 3 585 SQL-таблиц с объектами 1С. Результат оказался неожиданным для всех:
| Что | Объём |
|---|---|
| История версий шаблонов ограничения доступа | 3,34 ТБ |
| Очередь “пересчитать ключи доступа пользователей” (1,18 млрд строк) | 287 ГБ |
| Очередь “пересчитать ключи доступа к данным” (1,19 млрд строк) | 221 ГБ |
| Итого служебный кэш механизма разграничения доступа | ≈ 3,85 ТБ из 4,2 ТБ |
Больше 90 % базы - это не данные бизнеса, а служебный кэш универсального механизма RLS, который годами накапливался и никогда не использовался по назначению: регламентные задания пересчёта были выключены с 2020 года.
По дороге были проверены и отброшены три правдоподобные гипотезы - каждая сэкономила неделю работы впустую:
- “RLS отключён, значит всё это мусор, можно просто удалить” - неверно: 208 ролей реально используют ограничения по условию.
- “Мусор накопили уволенные сотрудники, почистим по ним” - неверно: живых ключей доступа оказалось 660 строк из миллиардов; эффект - десятки килобайт.
- “Виноват один конкретный медленный регистр” - оказалось, что этот регистр вообще из соседней базы на том же сервере.
Решение: 8 этапов
Перевести базу с универсального механизма разграничения доступа на классический (отбор по магазину прямо в запросах списков) - после чего трёхтерабайтный кэш становится безопасно удаляемым, а списки начинают работать быстро.
- Анализ и тестовая копия прода - карта объёмов, план на 4 фазы.
- Чистка справочника пользователей: 5 600 карточек → ~150 активных, с защитой “не трогать тех, у кого были транзакции за 2 месяца”.
- Вынос лога кассира в архивную базу (веб-сервисы + авто-очистка, ретеншн 180 дней) - −52 ГБ, 14,5 млн записей.
- Индексы под кассовые операции - список чеков 25 с → мгновенно.
- Оптимизация 6 тяжёлых отчётов - −22…−42 % при идентичных данных (сверка контрольными суммами SHA-256).
- Аудит вечернего пика + настройка параллелизма SQL - тормоза в пик убраны.
- Переход на классический RLS - отбор по магазину в 23 документах; чтение по чекам 162 млн → 94. Перед переключением - матрица эквивалентности прав: 329 проверок “кто что видит до и после”, 0 расхождений.
- Пересчёт итогов регистров - таблицы итогов −75 % (73,5 → 18,3 млн строк).
Ключевая ночь
- Удаление мёртвого кэша: занятое место 4 108 → 108 ГБ за секунды.
- Сжатие файла: 2 999,6 ГБ → 300 ГБ за 89 минут одним проходом (порционное сжатие оказалось медленнее - важный практический вывод).
- Перестроение 200 фрагментированных индексов: 44 минуты, 0 ошибок.
- Возврат в режим полного логирования + свежий полный бэкап (18,3 ГБ вместо 556) - чистая точка отката.
- Утром кассы работают штатно, регресса нет. Пользователи не заметили ни одного переключения.
Что было сложного
- Нельзя было ошибиться. Механизм разграничения доступа - это то, что показывает кассиру только его магазин. Отсюда 329 проверок эквивалентности прав до переключения.
- Сжатие терабайтов конфликтует с бэкапом. Параллельный плановый бэкап валил операцию с ошибкой 3140; после прерванных попыток остаётся “залипший” флаг сжатия, который лечится только переводом базы offline/online.
- Соседи по серверу. В разгар работ чужой отчёт из соседней базы (24 параллельных потока, 4,3 часа) душил весь инстанс - пришлось согласовывать и снимать.
- Запас места. После сжатия у базы осталось ~14 ГБ свободного пространства при приросте ~0,6 ГБ в сутки - это отдельно проговорено с заказчиком, а не замолчано.
Приёмка и что дальше
Приёмка выполнена представителями заказчика под ограниченными правами (кассир, менеджер): чеки, отчёты, остатки, разграничение доступа - замечаний нет. Итоговый отчёт для руководства передан отдельным документом.
Те же методы применимы к соседним базам инстанса: суммарный потенциал сервера - 6,38 ТБ → ~1,5 ТБ. Сотрудничество с этой сетью продолжается: 15 месяцев сопровождения, 39 закрытых задач, 0 потерянных документов и 0 дней простоя торговли.
Методика диагностики этого проекта - как строится карта объёмов, почему были отброшены три первые гипотезы и как проверяются права на 329 сценариях - разобрана в нашей статье на Инфостарте: “Как в базе 1С на 4,2 ТБ нашлось 3,85 ТБ мёртвого кэша”. Полная история с деталями ночного окна - в расследовании у нас в блоге.