При проведении свертки больших информационных баз на платформе 1С:Предприятие 8.3 пользователи часто сталкиваются с внезапным прерыванием процесса. Ошибка формулируется как "Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm". На первый взгляд кажется, что проблема заключается в сетевом соединении или веб-сервере, однако истинные причины кроются глубоко в механизмах работы серверного кластера и потреблении ресурсов SQL-сервером. Разберем пошагово, как диагностировать и устранить эту проблему.
Прежде всего, проанализируем, что именно происходит в момент падения. Ошибка обращения к /e1cib/logForm — это лишь следствие. В архитектуре 1С клиентское приложение пытается отправить на сервер отчет о возникшей исключительной ситуации. Если в этот момент рабочий процесс rphost, в котором выполнялась свертка, уже "упал" или был принудительно завершен операционной системой из-за нехватки памяти, клиент получает ошибку 404 или разрыв соединения при попытке логирования. Это означает, что нам нужно искать причину падения процесса rphost, а не проблему в протоколе HTTP.
Часто свертка затевается ради уменьшения объема базы, но мало кто задумывается, что именно занимает место. Рассмотрим ситуацию: база весит 100 Гб, и свертка падает на этапе формирования документов остатков. Нам необходимо выяснить распределение данных в таблицах SQL. Для этого воспользуемся стандартными отчетами SQL Server Management Studio (SSMS) или специализированными обработками для 1С, которые часто называют "базопузомерами".
Как показывает практика, в конфигурациях типа УТАП или УТ 11 основную нагрузку могут создавать не документы, а регистры сведений с двоичными данными. Проанализируем структуру: если регистр ДвоичныеДанныеФайлов занимает более 50-60% объема всей базы, свертка стандартными средствами будет постоянно "затыкаться", пытаясь пересчитать ссылки на эти огромные массивы данных.
Если мы обнаружили, что львиную долю объема занимают сканы документов или присоединенные файлы, лучшим решением будет их вынос из базы данных в файловую систему (тома хранения). Это значительно облегчит работу SQL-сервера и позволит свертке пройти успешно. Разберем процесс настройки:
Важно понимать, что после переноса файлов записи в базе физически изменятся, но размер файла базы данных (.mdf) сам не уменьшится. Чтобы освободить место и ускорить работу, необходимо выполнить операцию SHRINK (сжатие) в консоли управления SQL. Рассмотрим пример логики очистки регистра программным путем, если типовые средства не справляются (использовать с осторожностью):
// Пример логики для поиска и удаления старых двоичных данных
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДвоичныеДанныеФайлов.Файл,
| ДвоичныеДанныеФайлов.Размер
|ИЗ
| РегистрСведений.ДвоичныеДанныеФайлов КАК ДвоичныеДанныеФайлов
|ГДЕ
| ДвоичныеДанныеФайлов.Файл.ДатаСоздания < &ДатаСвертки";
Запрос.УстановитьПараметр("ДатаСвертки", ДатаСвертки);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// Логика удаления или переноса данных
КонецЦикла;
Выясним причину, почему база может "тормозить" даже при небольшом объеме документов. В современных конфигурациях 1С огромное количество места занимают кэши, настройки отчетов и протоколы обмена. Перед сверткой обязательно выполним следующие действия:
_InfoRgChngR могут раздуваться до невероятных размеров. Очистим историю версий за старые периоды.Проанализируем параметры рабочего сервера. Если rphost падает при достижении определенного порога памяти, нам нужно временно расширить границы для выполнения свертки. Рассмотрим ключевые параметры в консоли администрирования кластера:
rphost выделял больше ресурсов именно под нашу задачу.Также обратим внимание на TempDB SQL-сервера. Свертка активно создает временные таблицы. Убедимся, что диск, на котором расположен tempdb, имеет достаточно свободного места (иногда требуется объем, сопоставимый с размером всей базы) и высокую скорость записи.
Если база всё равно падает, применим метод "разделяй и властвуй". Не пытайтесь свернуть 5 лет работы за один запуск. Попробуем выполнить свертку по годам. Рассмотрим этот подход подробнее: сначала выполняем свертку за самый ранний год, проверяем результат, фиксируем остатки, затем переходим к следующему. Это позволит уменьшить размер транзакций и нагрузку на rphost и SQL лог транзакций.
В случае с УТАП 11, обратите внимание на последовательности партионного учета. Перед сверткой все задания по закрытию месяца должны быть выполнены, а последовательности восстановлены, иначе алгоритмы свертки могут уйти в бесконечный цикл пересчета остатков, что и приводит к переполнению памяти и ошибке POST /e1cib/logForm.
Подведем итог: ошибка logForm при свертке — это почти всегда признак падения рабочего процесса из-за неэффективного управления памятью при обработке гигантских объемов данных. Ключ к решению — не в наращивании мощностей сервера, а в предварительной очистке базы от "тяжелых" двоичных данных и системного мусора. Вынос файлов в тома, очистка логов ЕГАИС и поэтапное выполнение процедуры — вот три столпа, на которых держится успешная свертка базы 100 Гб+.