{{branchTel}}

{{section.attributes.section}}

Все результаты

  • По вашему запросу {{search.q}} ничего не найдено.

Перейти на страницу поиска
{{countBasket}}

{{userFullName}}

Личный кабинет

Выйти
Доставка и оплата
Контакты

Сложности обмена в РБД

Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.

Поиск  Правила 
Страницы: 1
RSS
Сложности обмена в РБД, Сложности после восстановления посследовательностей
 
#1
07.05.2013 10:07:25
Здравствуйте.

Имеется АА ред. 4., релиз 15.  Доработанная.

Проблема: нарушился обмен данными между подразделениями рбд.
Причина: были нарушены последовательности с 2010 года. С этого периода в базе наверное около 100 000 документов. В общем после восстановления последовательностей, файл обмена данными весит более 1,5 гига. И то это я запустил обмен на 12-ти ядерном серваке, продолжался трое суток, и я его прекратил... так бы наверное стол еще с месяц. На слабом сервере вообще через 3 часа пишет недостаточно памяти и закрывается все.
Вопрос: уважаемые гуру, как разбить процедуру обмена на несколько этапов?? Или как разбить файл?
Первый вопрос предпочтительнее, т.к. ждать неделю пока сформируется файл обмена не реально.

Или что посоветуете вообще?
 
 
 
#2
07.05.2013 13:20:51
Я с РБД толком не знаком, но разве при восстановлении последовательностей необходимо заново переносить документы в подчиненную базу? Это вопрос к разработчикам. Мне кажется процесс востановления последовательностей не должен влиять на формирование файла обмена.
 
 
 
#3
07.05.2013 13:22:52
Артем, все таки в данном случае мне кажется легче заного создать подчиненный узел,и не мучаться с переносом. А если есть возможность, вообще уйти от рбд, с ней вечно проблемы....
 
 
 
#4
07.05.2013 14:03:06
Цитата
Дуганов Александр Юрьевич пишет:
Артем, все таки в данном случае мне кажется легче заного создать подчиненный узел,и не мучаться с переносом. А если есть возможность, вообще уйти от рбд, с ней вечно проблемы....

Ни один способ не гарантирует, к сожалению, более стабильного способа "соединения" удаленных подразделений. Интернет соединение по впи и единая база - не вариант, т.к. инет вечно скачет, может на сутки и более пропасть. На резервные каналы тоже нет особой надежды... да и потом надежные каналы связи стоят дорого...
Облака тоже не подходят, по той же причине + дорого :)
Больше вариантов я не вижу! Мне самому рбд не нравится, очень много заморочек с ней.
 
 
 
#5
07.05.2013 14:05:27
Цитата
Дуганов Александр Юрьевич пишет:
Я с РБД толком не знаком, но разве при восстановлении последовательностей необходимо заново переносить документы в подчиненную базу? Это вопрос к разработчикам. Мне кажется процесс востановления последовательностей не должен влиять на формирование файла обмена.

А мне наоборот, это кажется логичным. Ведь при перепроведении изменяется много вещей,  в том числе и, нередко, сами документы. Поэтому подразделения должны обязательно их видеть.
 
 
 
#6
07.05.2013 16:56:20
Была подобная проблема, файл обмена был около 2 Гб. Для того, чтобы прогнать все изменения в центральную базу - создавали дополнительный план обмена в конфигураторе, регистрировали в нем изменения документов порциями (например по 2000 документов) и производили обмен. Таким образом разгребли изменения и снизили файл обмена до приемлемых размеров. Потребовалось около недели работы специалиста имеющего опыт работы с планами обменов. После этого - вспомогательный план обмена - удалили.

Причина проблемы была в том, что специалист, контролирующий обмены ушел в отпуск, а замещающий его - забыл контролировать. А фтп-сервер, через которые шел обмен - остановился.
 
 
 
#7
07.05.2013 18:04:11
Цитата
Владимир Гаврилов пишет:
Была подобная проблема, файл обмена был около 2 Гб. Для того, чтобы прогнать все изменения в центральную базу - создавали дополнительный план обмена в конфигураторе, регистрировали в нем изменения документов порциями (например по 2000 документов) и производили обмен. Таким образом разгребли изменения и снизили файл обмена до приемлемых размеров. Потребовалось около недели работы специалиста имеющего опыт работы с планами обменов. После этого - вспомогательный план обмена - удалили.

Причина проблемы была в том, что специалист, контролирующий обмены ушел в отпуск, а замещающий его - забыл контролировать. А фтп-сервер, через которые шел обмен - остановился.

Очень сложный и дорогой вариант!
А как же все таки универсальный обмен XML? Вернее так - выгружаем все доки из периферии за период когда не было обмена. Удаляем подразделение в главной базе. Загружаем недостающие доки и регистры. Восстанавливаем последовательности. Создаем периферийную базу заново и вуаля! Все будет по прежнему... нет? НЕ получится?

Я где то видел опцию - разбивать файл обмена на части... но где не помню)) показалось?

Рарус ПОМОГИТЕ!
 
 
 
#8
07.05.2013 18:18:12
Цитата
Артём Бавенд пишет:
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
В обработке обмена есть параметр количества элементов в транзакции.
 
 
 
#9
08.05.2013 11:52:51
Цитата
Александр Яблочкин пишет:
Цитата
Артём Бавенд пишет:
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
В обработке обмена есть параметр количества элементов в транзакции.

Он ни на что не влияет! Ставил и 1 и 10 и 50 и 1000 и 10 000 ... все тоже самое. Обмен висит трое суток и не доходит до конца!

Что делать??
 
 
 
#10
08.05.2013 11:54:16
Цитата
Александр Яблочкин пишет:
Цитата
Артём Бавенд пишет:
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
В обработке обмена есть параметр количества элементов в транзакции.

А что конкретно он подразумевает этот параметр?
 
 
 
#11
08.05.2013 12:26:14
Да, это не совсем то. Этот параметр задает число элементов, записываемых в одной транзакции. Подробнее описание параметра в синтаксис-помощнике функций ЗаписатьИзменения/ПрочитатьИзменения менеджера планов обмена.

Что касается ошибки загрузки надо понять причину ошибки. Надо попробовать в функции одОбменДанными.ПрочитатьСообщениеСИзменениями после вызова ПрочитатьСообщениеОбменаНаКлиенте/пвПривилегированныйМодуль.ПрочитатьСообщениеОбмена получить ошибку методом ОписаниеОшибки(). Может что то более понятное будет.
 
 
 
#12
09.05.2013 10:12:02
Цитата
Александр Яблочкин пишет:
Что касается ошибки загрузки надо понять причину ошибки. Надо попробовать в функции одОбменДанными.ПрочитатьСообщениеСИзменениями после вызова ПрочитатьСообщениеОбменаНаКлиенте/пвПривилегирован ­ныйМодуль.ПрочитатьСообщениеОбмена получить ошибку методом ОписаниеОшибки(). Может что то более понятное будет.

Ошибок никаких нет. Просто файл обмена стал невероятно большим и все. Нет возможности его сформировать, т.к. процедура обмена продолжается несколько суток. Сообщение обмена становится более 2х Гб.
Вопрос в том, можно ли разбить файл обмена?
Или же, возможно сначала загрузить все документы из периферии, а потом вновь создать периферийную базу?
Пожалуйста, читайте сообщение #1 от 07.05.2013 10:07:25
 
 
 
#13
13.05.2013 09:22:20
У платформы такого функционала нет. А именно этими методами выгрузка/загрузка осуществляется.
 
 
 
#14
13.05.2013 13:43:19
Мне никто не может помочь!? Я правильно понял?
 
 
 
#15
13.05.2013 19:25:42
Можно попробовать такой вариант:

1) Очищаем регистрацию изменений в периферийной базе для центральной базы методом: "УдалитьРегистрациюИзменений". При этом сохраняем в каталоге на диске файлы XML, каждый из которых содержит 1000 объектов, для которых очистили изменения.

2) По очереди регистрируем изменения для объектов, содержащихся в каждом XML-файле, полученном на этапе 1 и прогоняем обмен между всеми базами распределенки (чтобы не перебрать с накоплением изменений в центральной базе). После обработки каждого XML файла - он удаляется из каталога

Метод на практике не проверен, нужно проверить реализуемость, программировать, тестировать.  Ну и если все нормально - разгребать 2 Гб.
 
 
 
#16
22.06.2013 21:01:36
Цитата
Владимир Гаврилов пишет:
Можно попробовать такой вариант:

1) Очищаем регистрацию изменений в периферийной базе для центральной базы методом: "УдалитьРегистрациюИзменений". При этом сохраняем в каталоге на диске файлы XML, каждый из которых содержит 1000 объектов, для которых очистили изменения.

2) По очереди регистрируем изменения для объектов, содержащихся в каждом XML-файле, полученном на этапе 1 и прогоняем обмен между всеми базами распределенки (чтобы не перебрать с накоплением изменений в центральной базе). После обработки каждого XML файла - он удаляется из каталога

Метод на практике не проверен, нужно проверить реализуемость, программировать, тестировать.  Ну и если все нормально - разгребать 2 Гб.

Воспользовались советом и сделали так:

1. Удалили всю регистрацию изменений;
2. Зарегистрировали справочники в каждой базе по префиксам, прогнали по всем узлам, обменялись;
3. Зарегистрировали изменения по месяцу, начиная с дня когда остановился обмен, обменялись.

В итоге обмен восстановлен.

Минусы - некоторые справочники не зарегистрироли (как-то упустили их из виду), в результате в узлах теперь не видны к примеру пользователи-создатели, некоторая контактная информация и др. Пока других ошибок не замечено!

В итоге нескольких месяцев поиска, проблема решилась банально просто... если конечно не вылезут какие-то косяки в дальнейшем.
 
 
 
Страницы: 1
Читают тему
Поддержка отраслевых решений «1С-Рарус»
Узнать подробнее
Услуги 1С