Синхронизация данных между крупными информационными базами, такими как Управление торговлей 11 и Бухгалтерия предприятия 3.0, часто сталкивается с проблемами при передаче значительных объемов информации. Одной из самых коварных является ошибка На устройстве нет свободного места, которая может возникать даже в тех случаях, когда на жестких дисках сервера мониторинг показывает десятки и сотни гигабайт свободного пространства. Рассмотрим подробнее, почему это происходит и как решить данную проблему системными и программными средствами.
Разберем ситуацию: при попытке загрузки файла обмена (например, размером около 1 Гб) платформа 1С выполняет копирование данных из сетевого каталога во временную папку пользователя, под которым запущена служба сервера 1С (обычно это USR1CV83). Ошибка Ошибка при копировании файла... На устройстве нет свободного места часто вводит в заблуждение системных администраторов, так как они проверяют общее место на диске C:, но не учитывают специфику работы платформы и механизмов Windows.
Выясним основные причины «ложного» отсутствия места:
USR1CV83 в операционной системе могут быть установлены дисковые квоты. Даже если на диске свободно 100 Гб, лимит пользователя может быть ограничен 5 Гб, которые быстро забиваются временными файлами прошлых сессий.%TEMP% может увеличиваться в 5–10 раз.tempdb. Если под нее выделено фиксированное пространство, которое закончилось, 1С может интерпретировать это как общую нехватку места.rphost.exe.Первым делом проанализируем состояние сервера и выполним регламентные действия по очистке. Если загрузка «зависла» и показывает старую ошибку, это означает, что результат предыдущей неудачной попытки закешировался в регистрах состояния обмена.
Выполним следующие шаги:
C:\Users\USR1CV83\AppData\Local\Temp) и полностью удалим все содержимое.USR1CV83 на папку обмена и временные каталоги. Рекомендуется временно дать права «Полный доступ» для группы «Все», чтобы исключить фактор блокировок безопасности.
DBCC FREEPROCCACHE;
DBCC FREESESSIONCACHE;
DBCC FREESYSTEMCACHE ('ALL');
DBCC DROPCLEANBUFFERS;
GO
После выполнения этих действий запустим службу 1С заново. Важно также проверить в настройках синхронизации в обеих базах (УТ и БП) флажок «Сжимать отправляемые данные в архив». Это значительно сократит объем передаваемого по сети файла.
Если типовой обмен не может «прожевать» порцию в 50 000 и более объектов, необходимо перейти к тактике разделения данных. Как показывает практика, при критических сбоях стандартная синхронизация может бесконечно пытаться выгрузить один и тот же огромный пакет, который всякий раз будет падать по таймауту или нехватке памяти. Для устранения зависания при передаче избыточного пакета подойдёт обработка для разгрузки переполненного плана обмена.
Рассмотрим алгоритм порционной регистрации изменений, который применил автор темы. Если документов слишком много, мы можем написать небольшую обработку, которая будет регистрировать объекты к обмену частями (например, по месяцам или по 5000 объектов).
Пример логики для управления регистрацией в плане обмена:
// Выберем узел обмена, для которого нужно перерегистрировать данные
Узел = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("Бухгалтерия предприятия");
// Сначала снимем регистрацию со всех объектов, чтобы начать "чистую" порционную выгрузку
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);
// Определим период, за который хотим передать данные (например, за один месяц)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТоваровУслуг.Ссылка КАК Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
|ГДЕ
| РеализацияТоваровУслуг.Дата МЕЖДУ &ДатаНач И &ДатаКон";
Запрос.УстановитьПараметр("ДатаНач", '20200701000000');
Запрос.УстановитьПараметр("ДатаКон", '20200731235959');
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
// Регистрируем только объекты выбранного периода
ПланыОбмена.ЗарегистрироватьИзменения(Узел, Результат.Ссылка);
КонецЦикла;
После такой «ручной» регистрации запустим стандартную синхронизацию. Пакет данных будет значительно меньше, что позволит серверу успешно завершить транзакцию записи в базе-приемнике. Для удобного отбора и порционной регистрации данных без написания кода можно использовать инструмент для массовой регистрации объектов к обмену по запросу и спискам.
Посмотрим на ситуацию со стороны базы-приемника (БП). Часто ошибка возникает из-за того, что платформа пытается записать все принятые объекты в рамках одной огромной транзакции SQL. Если в процессе записи одного из 50 000 объектов возникнет ошибка, вся транзакция откатится, а лог транзакций .ldf вырастет до гигантских размеров.
Проанализируем возможности оптимизации:
КоличествоОбъектовНаТранзакцию.Разберем важный момент: почему при новом запуске синхронизации вы видите ошибку вчерашним числом? Платформа 1С хранит состояние последнего обмена в специализированных регистрах сведений (СостоянияОбменаДанными). Если процесс загрузки завершился аварийно (crash процесса rphost), запись о начале нового обмена может просто не успеть зафиксироваться, и в интерфейсе вы будете видеть статус последней «записанной» попытки.
Чтобы сбросить это состояние, выполните следующие действия:
Состояния обмена данными.Проанализировав все вышеперечисленные методы, мы видим, что проблема нехватки места при синхронизации — это комплексный вопрос, требующий внимания как к настройкам Windows/SQL, так и к объему порций данных, которыми оперирует 1С. Последовательная очистка кэша и переход на порционную выгрузку позволяют успешно завершить обмен даже в самых тяжелых случаях.