Есть 2 базы. Довольно большие, раз в месяц делают сверку, при которой в каждой базе изменяют очень до фига разных документов. Соответственно обмен по УРБД идет долго плюс постоянно блокировки для уже работающих в базе. В одной из баз практически круглосуточная отгрузка. Пока до чего додумался, это для отгрузки сделать отдельную базу УРБДшную и чтобы там колотили доки. Еще есть компонента терминал_слип, если ее подключить, то можно сделать чтобы групповой перепроведение при наличии файла, сигнализирующего о блокировке, останавливалось и давало пользователю провести документ. Вот только к обмену по УРБД ее прикрутить наверно не получится. Что посоветуете чтобы и обмены шли и пользователи могли нормально работать?

Делай большие обмены на выходных

Ну, как вариант.

делай чаще обмен. контролируй объем 1супдтс и по превышении лимита юзверей - задрачивай сообщениями типа "пните срочно администратора - пора делать обмен!".

>>контролируй объем 1супдтс
На предмет каких параметров?

Вот к примеру в базе из которой выгружаю, 1SUPDTS.DBF размером в 4мегб, это много или мало?

как долго ждут юзеры при загрузке большого обмена ?
какого размера файл обмена ?
хочется понять масштаб

до получаса. Файл обмена метра 4.

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

(8) Как часто делаешь обмен?

Ну обычно ежедневно, проблем нет, но раз в месяц проблема встает в полный рост.

(10) Обмен в одну сторону?

(0) Может, пересмотреть методику сверки? Не изменять много документов, а откорректировать все, что надо, одним-двумя доками?
Иначе - только дробить обмены на мелочь, нпр, обмениваться после обработки небольшой части доков.
ЗЫ. Как-то давно у нас такое сделали, что изменения доков одного вида не влазили в файл обмена. Проблема разовая, времени не было. Скопировал в сторонку таблицу 1супдтс, оригинал очистил и возвращал его содержимое примерно по одной трети строк, проводил обмен.

(12): Корректировки собирать в файлы во всех ИБ.
И актуализировать корректировкой документов в центральной ИБ (в которой не работают 24/7) - рассылая с очередным автообменом.
Вроде должно ускорить работу, не?..

(11) Двусторонний.

(4) Количество записей или размер, но придется подбирать опытным путем и учитывать с запасом. Обмены будут немного разные по времени и тяжести - это не так уж и критично.

центральную базу сделать без юзверей. обмен каждые 10 минут, тогда файлики обмена крохотные.. блокировки никто не заметит

(15) + Блин, запас не нужен(это я в воспоминания ударился :))
Кста, замеров не проводил, но на глазок - зависимость нагрузки на базу от объема файла загрузки далеко не линейная. Так что уменьшение объема файла будет очень эффективно.

(16) Кстати, вариант!

Хотя не, все равно обмен большой будет, т.к. в одной из баз очень много доков меняется, изменения небольшие, но УРБД то пофигу, документ изменен, он в работу идет.

Отдельная база по принципу "только товарооборот" - это интересно. Если удастся ничего туда регулярно не грузить по УРБД. Но могут понадобиться еще и взрасчеты - для контроля макс задолженности.

(19) Сколько?

(21) Ну, правят номенклатуру, меняют оперции в счетах и т.д. Вообще, от этого уходить надо, меняю потихоньку, но пока от больших обменов сложно уйти.

Очень много это несколько тыр доков.

(23) Ежедневно?

(5) апдейтс 4 метра - это значит, что для обмена зарегистрировано около 130 тысяч объектов.
на мой взгляд - дофига.
делай обмены почаще.

(8) Это нормально. в разделенном режиме он делает паузы по полчаса, чтобы юзверы могли работать

Делай обмен ночью, в монопольном режиме, если БизнесПроцесс компании это позволяет. Монопольный режим резко ускоряет загрузку. Примерно 5 минут против 30-60 минут.

с такими объёмами у вас ДБФ? не страшно?

(28) поставят сиквельную - получат тормоза. а справиться с тормозами ТС не сможет...

(29) смотря насколько таблички распухли. А то, ведь, всё равно придётся переводить

(30) ему проще порезать, чем думать...

(29) Я работал с сиквельной, 23млн документов было. Ничего, вроде справлялся. )

Мне главное, распараллелить отгрузку в одной из баз, которая идет по ночам (днем работают все остальные), и загрузку по УРБД.

(25) не факт, что размер данных в нем тоже 4 мегабайта, знаете же фичу - этот размер может остаться после удаления всех строк из таблицы, пока сжатие не сделаешь

(26) Паузы он делает, только транзакции все равно.

Наконец Антошу заставили поработать..

По существу вопроса:

1. Центральная база это не центральный филиал. Предназначена для консолидации данных и формирования отчетности. Должны формироваться документы или выполняться обработки влияющие на все филиалы сразу.

2. Обмены должны выполняться несколько раз в сутки (каждые 2-3-4 часа). Для филиалов с наибольшим документооборотом - чаще, чем для остальных.

3. Провести анализ данных для обмена. Много думать.
Подсказка:
- дублирование данных (документ-справочник);
- анализ перед сохранением/перепроведением (до = после).

(35) Вот предположим, раз в месяц из одной базы в центральную универсалом грузятся отгрузки за месяц, примерно 30000 доков. И как тут поможет обмен раз в 2-3-4 часа?

Чтобы не объяснять, есть база 1, центральная, и база 2 периферийная. В центральную раз в месяц грузят универсалом доки из третьей. Соответственно при выгрузке в периферийную затык.

Проверил щас на копии - 10 минут проблемная загрузка идет в монопольном режиме. о_О так что в обед спокойно загрузим.

(36) Мне не понятно, как в периф. базе одномоментно "нарисовалось" 30000 документов. Что мешает создавать их ежедневно? не иначе лень проектировщика.

(37) Периферийных баз две или три? Непонятно.. И что с чем обменивается?

(38) Поиск решения проведен по направлениям наименьших телодвижений для сопровождающего.

(39)
1.Про черный и белый учет слышал?
2.ЦБ и одна периферийка. Миграция все объекты.
3. Это временное решение, буду искать решения не требующие постоянного присутствия сопровождающего.

(40)

1. Белый ведется постоянно, а черный один раз в месяц?  :-)
2. Что и требовалось доказать. В ЦБ работают как в периферийной базе. Проблема (0) только начало.
3. Следующий вопрос на форуме - "Подскажите выгонялку для юзеров"?

Я так понимаю, все это ТЫ придумал?

(41) В куче баз работали по отдельности, хотя учет общий, доки переносили универсалом, в общем, задолго до меня все сложилось как засохший кусок г(о)вна. Объединил все в УРБД, но вот тут возникла проблема с самой большой базой. Причем не вижу смысла центральную только для отчетности делать, т.к. это не решит проблему единовременных загрузок большого количества доков.

Выгонялку найду. )

(42) Я сделал следующие выводы:
1. Проектировщик из тебя никакой.
2. С УРБД ты работать не умеешь.
3. Не готов воспринимать советы.

Ну и чем твой "кусок" лучше предыдущего?

про ускорение обмена в монопольном режиме уже было
---
есть еще 1 спорный вариант ускорения - делать почаще ВЫГРУЗКУ из базы  (ПБ1) где колотят / меняют документы.
Например
Выгрузка из ПБ1 каждые 5-15 минут
Обмен в ЦБ каждые 5-15 минут
Загрузка в ПБ1 каждые 3-4 часа
---
Зависит от схемы обмена, где больше изменений делается и как быстро надо видеть данные в других ПБ

(44) Молодец, теперь со своими выводами можешь идти в любом выбранном направлении. )
(45) С ежедневными обменами проблемы нет... Проблема как разово ежемесячно впихнуть большое невпих(у)емое. Пока решилось монопольной загрузкой но это временное решение.

(46) а грузить сразу в ЦБ или отдельную ПБ?

(47) Из ЦБ в ПБ. Да по большому счету разницы нет, можно местами поменять, все равно миграция полная.

я про то, что большой объем данных можно ночью загрузить и выгрузить по периферийкам

(49) Я тоже так думал, но ночью отгрузка. МОжно конечно просто их выгнать, сделать большую загрузку за 10-15 минут, но это ведь ручное решение.

Это уже административное решение - типа все выходят из базы с ... до ....

Ну да.

1.Перевод на SQL.
2.Переписываение Рачсета Остатков и Взаиморасчетов на прямые запросы.
3.Распределение регламента работы обменов.

У меня 31 филиал обменивается и ничего никто не жалуется.
Для этого я вообще сделал отдельную базу обменов из которой старуют конфигураторы.
Основная цель которой это отслеживание выгрузок.
Инициатором обмена всегда является ПБ. А вот база обменов периодически просматривает каталоги выгрузки с филиалов и ни наличии файла выгруки бросает его во временную папку, далее создает список загрузки выгрузки и толкает обмен в центральной.
Дополнительно определить Приоритетность главенствующих документов.
Причем есть вносятся изменения в них принудительно фиксировать для базы обменов флаг что требуется принудительная выгрука с филиала.
А если нет то период обмена делать для ВЕСХ один большой.
В реультате у меня выходит что с урта обмены ломятмя все, но в течении для они растягиваються во времени и нагрузка на ЦБ становиться меньше.

(0) если интересно стучись 477687116

(53) Ну, у меня одна большая база, и еще три маленькие, тоже урбдшные, в которых с обменами уже полгода проблем нет. Просто объединил главную, она большая и начались проблемы типа озвученной в этом топике. Меняю через УРБД мастер, очень удобная хрень.

К главной правда скоро еще периферийка будет, вот поэтому и призадумался как кошернее все организовать.