Рассмотрим классическую, но от этого не менее сложную задачу: база данных 1С:Управление торговлей 10.3 на MS SQL Server за 8 лет работы разрослась до 120 Гб. Работа ведется почти круглосуточно, и на обслуживание есть всего 4-5 часов монопольного доступа. Главная цель — уменьшить размер базы в несколько раз, оставив данные только за последние 2 года. Проанализируем ситуацию по шагам и выясним, почему стандартное удаление документов не дает желаемого результата, как найти скрытые причины «раздувания» базы и как правильно работать со средствами СУБД.
Многие ожидают, что удаление старых документов или даже проведение свертки за несколько лет автоматически освободит место на жестком диске. Однако, если мы посмотрим на файл базы данных .mdf, его размер останется прежним. Разберем причину этого явления.
Это стандартное поведение Microsoft SQL Server. Когда СУБД удаляет строки из таблиц, она лишь помечает это пространство как свободное внутри самого файла .mdf. Физически место операционной системе не возвращается. Для реального уменьшения размера файла необходимо выполнить операцию сжатия.
На уровне SQL Server для этого применяются команды сжатия, такие как DBCC SHRINKDATABASE или DBCC SHRINKFILE. Выполнять эти операции необходимо средствами SQL Server Management Studio (SSMS).
Сразу после успешного сжатия файла базы данных возникает новая проблема — катастрофическая фрагментация индексов. В результате выполнения операции Shrink индексы перемешиваются, и фрагментация может достигать 99%. Если оставить базу в таком виде, пользователи столкнутся с сильным падением производительности 1С.
Следовательно, после любого сжатия файла обязательно нужно выполнить перестроение индексов (Index Rebuild) и обновить статистику. Обычная реструктуризация средствами Конфигуратора 1С здесь избыточна и не обязательна, работу с индексами лучше и быстрее проводить напрямую средствами SQL.
Учитывая жесткие временные рамки (4-5 часов), процесс удаления огромного массива документов стандартными средствами 1С кажется бесконечным. Возникает соблазн удалить объекты напрямую через SQL-запросы.
Проанализируем риски прямого удаления: при удалении документа из 1С платформа автоматически подчищает все его движения по регистрам и убирает связанные ссылки. Если же удалять данные командой DELETE или TRUNCATE напрямую в SQL Server, необходимо досконально знать структуру хранения данных 1С. В противном случае мы получим базу, наполненную битыми ссылками и «осиротевшими» записями в регистрах.
Безопасные альтернативы:
.ldf) и нехватке оперативной памяти. Проводите свертку постепенно — по полгода или году, регулярно усекая лог транзакций. Каждая свертка сформирует документы Корректировка записей регистров.Вместо того чтобы сразу удалять документы вслепую, посмотрим на реальные размеры таблиц в SQL Server. В нашем случае анализ показал следующую картину по объему таблиц:
Д.ТранспортнаяПартияМеркурий — 13% от общего объемаРН.ПартииТоваровНаСкладах — 11%РН.Продажи.Обороты — 8%РН.НДСРасчетыСПокупателями — 7%Д.Меркурий... (прочие документы) — 5%РН.Продажи — 5%Мы видим, что главная причина дикого роста базы за последние 1.5 года — интегрированная подсистема Меркурий (ВЕТИС). Электронные ветеринарные сопроводительные документы (эВСД), логи запросов и транспортные партии генерируются в астрономических масштабах. Хранить эти данные за все годы в рабочей базе 1С бессмысленно, так как юридически значимые оригиналы хранятся на серверах Россельхознадзора.
Решение: Настройте регулярную очистку устаревших данных ВЕТИС (например, удаление погашенных ВСД старше 3-6 месяцев). Это кардинально уменьшит размер базы без необходимости проводить тяжелую свертку торговых регистров.
Пользователи часто жалуются, что база весит 120 Гб, но при этом выдает ошибку при попытке выгрузки в файл .dt. Разберем этот момент.
Формат .dt не является средством создания полноценных резервных копий! Это внутренний формат 1С, который имеет архитектурные ограничения (например, ограничение в 4 Гб на размер одной таблицы во внутреннем формате). Для баз размером более 10-20 Гб необходимо использовать исключительно средства резервного копирования SQL Server (создание файлов .bak).
Дополнительную нагрузку на таблицы создают прикрепленные файлы. Даже если фото номенклатуры весят по 50-100 Кб, за 8 лет их количество превращается в гигабайты, хранящиеся внутри SQL.
Чтобы моментально облегчить базу, воспользуйтесь типовым механизмом 1С: перенесите хранение присоединенных файлов в тома на диске. Настроив пути к сетевой папке, вы вынесете тяжелый бинарный контент за пределы СУБД, что существенно ускорит как создание бэкапов, так и общую работу базы.