Поздравьте меня! Я не избежал кармы нехватки памяти на сервере предприятия, как многие здесь присутствующие! Платформа 319, УПП 1.3.26.1. вываливает болт при загрузке из периферийной базы. Изучив темы, предполагаю попробовать сделать через стандартную загрузку XML. В связи с этим вопрос к знатокам: при такой загрузке не будет происходить пометки подтверждения загрузки объектов в центр? Т.е. как подчиненная база узнает, что все выгруженные из нее объекты удачно загружены в центр? Спасибо!

в таком случае в центре надо очистить регистрацию объектов для подчинённого, если уверен что всё загружено

по номерам сообщений. Головная база отправляет в переферийную базу сообщение с номером загруженного сообщения. После прочтения его в периферии просиходит сброс регистрации объектов

Посмотри сколько зарегистровано объектов перифирии

(1) Т.е. из центра в периферийку все выгружу (благо в одну сторону работает пока), загружу ответ от периферийки, и после этого сниму регистрацию объектов для подчиненного (в центре)? Так?

(4) куда ответ загрузиш? ответа не будет, если загрузкой XML сделаеш. раз одностороннее - просто регистрация в центре почистить

т.е. если очистишб регистрацию в центре - ему уже не надо будет ответа о загрузке из перефирии

(4) Если обмен одностронний, то обратно достаточно выгрузить файл с одним номером.

непойму зачем лишние движения по выгрузке чего то из перефирии в данном случае

(7) обмен к сожалению/счастью в обе стороны.

продвинулся : оказывается, спотыкается на документах, которые созданы в периферийной базе: распределение материалов, списание НЗП. Т.е. в момент записи проводок от этих документов он не находит самих документов, при этом возникает ошибка "Не хватает памяти" - в файловом режиме,(Недостаточно памяти на сервере 1С предприятия" - в серверном режиме. Кто-нибудь боролся с такой проблемой?

Коллеги, прошу помощи! Неужели Титьница важнее?!?

обработкой регистрация изменений смотрел сколько будет пегружается документов? 100, 200 и т.д. По ходу выгрузки сомтри до какого размера растет файл с данными (путь получиться определить через отладку т.к сохраняет во временную)

(12) не, не смотрел - ща гляну

(12) порядка 250 документов. Справочников - 3500. Регистры сведений -2000, регистры накопления - 4500 (самые большие). Файл обмена в зипе - 15 метров.

(12) кстати проблемы то не при выгрузке, а при загрузке...

(0) Попробуй, убрать использование транзакции. Т.е "по умолчанию" обмен идет в рамках одной общей транзакции - вот памяти и не хватает. Правда есть риск вылететь во время обмена по ошибке. Тогда придется повторить или химичить танцами с бубном.

(16) Уже делал: сначала было 200 элементов в транзации, потом 50, потом 30. Потом 0. При нуле быстрее всего выдает ошибку.

Тогда у тебя проблема не с обменом скорее всего. Точнее сказать - с теми данными, что он изменяет при обмене.

Придумал вариант - центр похерю, из периферийной щас сделаю центр, сорганизую из центра  новую периферию. Если щас тестирование покажет что все ок, то так и заделаю и конец...

(10) раз не видит документов, то может их перепровести в базе и заново сформировать выгрузку?
PS. как вариант установить x64

(20) вот щас их распровел, тестирую базу и пытаюсь еще раз загрузить. 64 не катит - у нас сервера пятьсотзатертого года выпуска

Может это поможет? У меня нечто анналогичное было: один документ потребовалось выбросить из обмена (в ТЧ документа был сбой, который ТиИ в файловой не вылавливало).

Как выкручивался: файл обмена парсил, разделял на две части и по очереди их в копию базы принимал. Ту часть сообщения, что сбоила - делил ещё раз "надвое". И так, пока не определил сбойный документ.

Да, кстати вспомнил: для каждой части сообщения - увеличивал номер сообщения на единицу.

(22) о, буду пробовать, а как делить на две части?

(0) 8.2.16 нужна

10101535  (SW661489)  Создание образа узла распределенной информационной базы
Проблема:
При создании образа узла распределенной информационной базы может происходить ошибка "Недостаточно памяти".
Дата публикации:
2012-07-05

Структура файла сообщения простая. Можно и текстовым редактором, но лучше для редактор xml. Там заголовок, тело и окончание. "Тело" состоит из независимых частей - собственно говоря самих изменений. У них есть тег начала и окончания. Нужно взять копию файла сообщения и удалить из него половину информации. Границы удаления - с начала одного изменения до границы окончания любого другого изменения включительно.

(25) Спасибо, я так-то делал самописки загрузки/выгрузки через XML, но просто тут файл фееричных размеров, думал что не каждый редактор потянет его...

(24) да там небось куча других траблов. ну его пока, воздержусь...

(24) Сорри, но типовым созданием начльно образа, имхо, уже никто не пользуется. Алтернативно, только альтернативно :)

(24) а, ну так ДА, и  быстрее альтернативным.

Ну вот первые результаты - база центральная БИТАЯ. Что-то в регистрах сведений... Пока тестирование продолжается...

(26) v8: Посоветуйте Hex, Xml-редакторы для файлов за 2гига без крякозяб в русском

(0) (30) начинать работы нужно с поиска на каком объекте падает загрузка.

В режим отладка и "останавливаться при ошибке" запустить обмен - и надеяться что он сам покажет, где ошибка.

Всем спасибо! Вопрос решился: центральная база содержала битые ссылки на книги покупок и продаж - за весь первый квартал, а строк в книге продаж за 1 месяц - более 8000. Вот так и валилось. Выгрузка 20 Гб SQL в файловую, тестирование исправление в файловой, восстановление обмена, выгрузка из файловой в SQL. Все это время пользователи работали в периферийной. Еще раз всем спасибо!

P.S. ПОПРАВКА: Все таки на ошибку влияли проведенные документы Распределение материалов на выпуск - их было 3 штуки по 10,16 и 29 тысяч строк. На них и падала система. Если Их распроводить - то все было нормально. Обмен потом делал по одному обмен - все прошло.