Свертка базы данных 1С — это сложная техническая операция, которая требует значительных ресурсов системы: процессорного времени, дисковой подсистемы и, что чаще всего становится «узким горлышком», оперативной памяти. В условиях, когда сервер имеет ограниченный объем RAM (например, 6 ГБ), стандартные механизмы свертки могут завершаться аварийно с ошибкой «Недостаточно памяти». В этой статье мы подробно разберем, как обойти эти ограничения, сравним режимы работы базы и выработаем оптимальный алгоритм действий.
Проанализируем ситуацию: при выполнении свертки типовой обработкой система выполняет сразу несколько ресурсоемких задач. Во-первых, формируются документы ОперацияБух или специализированные документы ввода остатков. Во-вторых, происходит очистка движений регистров и удаление огромного количества документов за прошлые периоды. Основная проблема заключается в том, что 1С пытается выполнить удаление или проверку ссылочной целостности большими транзакциями.
Когда рабочий процесс rphost или экземпляр SQL Server начинает обрабатывать миллионы записей, таблицы индексов и кэш метаданных переполняют выделенную оперативную память. Если файл подкачки не справляется или система имеет жесткие лимиты, процесс принудительно завершается. Рассмотрим, какой режим работы в таких условиях будет более стабильным.
Существует заблуждение, что переход из клиент-серверного режима (SQL) в файловый (ранее называемый DBF в версии 7.7, а в 8.х — это формат 1CD) может ускорить процесс за счет отсутствия накладных расходов на работу сервера приложений. Однако практика показывает обратное:
Simple (простая). Это позволит логу транзакций не раздуваться до терабайтных размеров при массовом удалении строк.1cv8.1cd имеет внутренние ограничения на размер таблиц (4 ГБ на одну таблицу при стандартных настройках). При свертке временные таблицы могут легко превысить этот порог, что приведет к неустранимой ошибке.Max Server Memory для SQL на уровне 2–3 ГБ, чтобы оставить место для rphost.Выясним причину неудач в файловом режиме: при выполнении тестирования и исправления (ТИИ) или реиндексации после свертки, файловому движку требуется загрузить значительные части таблиц в память, что на слабом «железе» гарантированно ведет к вылету системы.
Если стандартная обработка свертки не справляется с этапом удаления данных, воспользуемся комбинированным методом, который предложил автор темы. Разберем его по шагам, чтобы минимизировать нагрузку на систему.
Шаг 1: Подготовительный этап и формирование остатков
Запустим стандартную обработку «Свертка информационной базы». На этом этапе нам нужно только, чтобы система создала документы ввода остатков на нужную дату (например, на начало 2018 года). Не пытайтесь сразу запускать автоматическое удаление старых документов внутри этой обработки, если памяти мало.
Шаг 2: Групповая пометка на удаление
Вместо того чтобы заставлять механизм свертки мучительно искать зависимости, воспользуемся типовой обработкой Групповая обработка справочников и документов. Сделаем следующее:
Шаг 3: Порционное удаление объектов
Теперь перейдем к самому сложному — очистке базы. Стандартное Удаление помеченных объектов может зависнуть на проверке связей. Рассмотрим эффективную тактику:
РеализацияТоваровУслуг).Шаг 4: Окончательная корректировка и проведение остатков
После того как «мусор» вычищен, необходимо вернуть документы ввода остатков в рабочее состояние. Проанализируем ситуацию: часто при удалении могут «полететь» ссылки, которые были важны для остатков. После чистки проводим документы ввода остатков, которые обычно устанавливаются на время 23:59:59 последнего дня старого периода.
Шаг 5: Техническое обслуживание (Shrink и ТИИ)
Физически место в базе данных после удаления не освобождается. Чтобы уменьшить размер файла базы:
SHRINKDATABASE или SHRINKFILE..dt и загрузите ее обратно в чистую базу. Это пересоберет индексы и окончательно очистит базу от фрагментации.Посмотрим на ситуацию под другим углом. Если база слишком тяжелая, иногда проще не удалять старое, а перенести нужное в новую пустую базу. Разберем этот алгоритм:
ВыгрузкаЗагрузкаДанныхXML.epf переносим все справочники.Этот метод гарантирует, что в новой базе не будет «хвостов» и проблем с памятью при удалении, так как удалять ничего не придется.
При выполнении тяжелых операций на сервере с 6 ГБ оперативной памяти, рекомендуем изменить настройки кластера 1С. В консоли администрирования можно ограничить объем памяти на один процесс. Рассмотрим пример логики настройки:
// Пример настройки параметров кластера 1С
ДопустимыйОбъемПамяти = 2000000; // в КБ (около 2 ГБ)
ИнтервалПревышенияДопустимогоОбъемаПамяти = 30; // секунд
Эти параметры заставят систему перезапускать процессы, если они начинают бесконтрольно потреблять ресурсы, что может спасти сервер от полной остановки (BSOD или зависания).
Резюме: Свертка на слабом сервере возможна только при отказе от «автоматизма» в пользу ручного контроля каждого этапа. Используйте SQL-версию, ограничивайте потребление памяти сервером БД и удаляйте данные порциями, используя стандартную групповую обработку объектов.