Добрый день.

В прошлогодней репликации были проблемки с 4 базами даже на пустом обмене уходило 150 секунд и была зависимость от увеличения числа таблиц для обмена и привязка была ко времени. Что и побудило переписать все полностью. Сейчас неважно сколько таблиц в обмене нет данных нет и лишних действий 11 секунд. У клиента сейчас по статистике от 6 до 30 секунд на обмен уходит. НО.

Так получилось когда писалась репликация для уменьшения конфликтов в каждой процедуре выполняющей определенные действия (удаление + запись подтверждений удаления, проверка наличия новых данных + создание данных для подтверждения о передаче в удаленные базы и т.д.) создавался компонент транзакции TpFIBTransaction.
с характеристиками
T2.TPBMode := 0;//tpbDefault;
T2.TRParams.Clear;
T2.TRParams.Add('write');
T2.TRParams.Add('read_committed');
T2.TRParams.Add('wait');
T2.TRParams.Add('no_rec_version');

В принципе сейчас добился того что конфликтов DEADLOCK не наблюдаю.

Вопрос есть ли смысл оставить так или сделать 1 компонент и каждое завершенное действие просто подтверждать как CommitRetaining?

wadmanЧтение и запись в одной транзакции?

Да

Dimitry SibiryakovЕвгений Болтикдобился того что конфликтов DEADLOCK не наблюдаю
А взамен получил молчаливое и непредсказуемое затирание данных. Оно того действительно
стоит?..


Может и не стоит. Можно сделать так что бы были deadlock для конфликтовавших строк изменив параметры транзакций это понятно. И товароведу сказать нажмешь позже еще раз обмен. Но тут и это не поможет данные будут затерты тоже. Теток не заставишь лог читать после обмена у них с 30/08/2013 документ закрылся от изменений они 2 числа весь день делали обмен и хоть бы одна сволочь прочитала русский текст. И открыла злощастный документ для изменений. Начальнику сказал мол учите теток, а он достали они меня. Иногда проще пусть затрет как легло. Одно правило основная база главней и сначала из нее данные выливаются, а уж потом забираются из удаленных баз. Пока нареканий не было. Я понимаю дилемму а что же оставить то что на удалёнке поправили или в главной базе тут можно понять только по дате, но эти админы даты не блюдут. Первый вариант репликации был на датах там Ж еще та была с датами. начальнику пофигу с той фирмы на наши проблемы. Вот и был сделан выбор такой, но я хочу сделать более грамотно с возможность выбора вариантов транзакций. Вот 1 компонент и проще для работы использовать хотя можно и процедуру для заполнения параметров транзакций сделать.

1.Какие параметры выставил бы ты. Готов выслушать не пойму вопросы задам. Щас на фиг знает какой раз перечитываю про транзакции на всякий случай.
2.И все же ответ по теме хотелось услышать. Сейчас получается сделал блок дело и исчезла транзакция. Я так понимаю при одном компоненте на все действия хоть они и будут подтверждаться будет одна длинная(как ее там, уже кучу всего перечитал и нужны подсказки т.к. в одном месте так советуется в другом так) ... Где то читал, что лучше так не делать вот и спрашиваю. С одним компонентом проще 1 раз параметры задал и ... Но т.к. я не знаю полной его работы из нутри много вопросов возникает.

Dimitry SibiryakovЕвгений Болтик1.Какие параметры выставил бы ты. Готов выслушать не пойму вопросы
задам.
Административный бардак параметрами транзакции не лечится.


Я понимаю и меня интересует как правильнее, сделать по умолчанию. А не так как это сейчас для определенной фирмы. Вообще я привык работать в онлайн и у меня несколько клиентов так и работают. Но т.к. какойнить начальник может сказать, а мы хотим офлайн, Я ему да пожалуйста а как вы хотите видеть что происходит или как попроще с административным бардаком ;)

Меня тут вообще один начальник удивил. Мол дорого 5400 в месяц за сопровождение 13 рабочих мест 7 из них вне офиса 3 в удаленном городе 1 еще в одном удаленном и 3 в родном городе. Я ему ну можно вообще без обслуживания и тогда сами ищите кто базу будет обслуживать. И кто ее восстановит если грохнется. Сошлись на том что 1800 и про удаленные точки я не отвечаю. и не анализирую как работает бухгалтерия.

Второй поменял роутер и сказал ты виноват что твоя программа не работает. Я ему воткни старый роутер работает, то воткнул и сказал да. Я разбирайтесь с роутером прокидывайте пути. Меня обхаяли сначала мол программа должна понимать как связываться. Поговорили на высоких тонах, я их админу сказал больше я ему ничего объяснять не буду. Сел с начальником поговорил и сказал как подключитесь к SQL серверу без программы так позовете. И объяснил ему что все не может один человек знать и разгребать за всех их нее оборудование. Программист должен писать программы а не заниматься делами админов из кучи организаций. Они когда разобрались с роутером сказали да надо было там кое что в роутере настроить. Начальник то осознал, а вот тот его админ хоть бы признал что был неправ.

Я вообще не понимаю куда мир катится никто нифига делать не хочет. Говоришь почитайте про железяку, а тебе ну ты же программист тебе проще. Бухгалтера считают что просто одна кнопка должна быть и все за них сделается. А как программа поймет оптовый отдел продал, торговый отдел продал и за что заплатил тот кто и там и там покупал. Ладно накипело слегка высказался...

PEAKTOPDimitry SibiryakovАдминистративный бардак параметрами транзакции не лечится.

Лечится.

1. репликация производится ХП, которая работает через CROSS-DATABASE запросы. Там два варианта: 1) есть связь с филиалом, 2) базу привезли на флешке. сути не меняет.

2. Параметры транзакции:
isc_tpb_read_committed
isc_tpb_write
isc_tpb_rec_version
isc_tpb_nowait

на этой фигне с декабря 2009 работает ABS у нескольких клиентов-"сетей" (не банк, но все равно "финансовая организация", с погашением кредита, процентами).
сбоев за все время - ни одного.

С похожими параметрами я и работал раньше. Просто через 1 минуту запускали и все отрабатывало.

Когда обмен с 1 базой в один момент конфликтов нет. Просто последнее время получаются конфликты т.к. главный склад делает обмен с 4-мя базами зараз, есть оператор который делает тоже со всеми за раз. Есть 4 товароведа которые делают обмены только со своими базами. И вот первые два стали сталкиваться периодически с товароведами т.к. иногда параллельно запускают обмен и на каких то данных им вылетал deadlock. Теткам объяснить тяжело что надо еще раз запустить обмен чуть позже. Они это чуть позже забывают. И при торговле программа выдает цена товара неизвестна.

Начал искать и в какой то из статей Бузза по ФБ+ вычитал параметры которые сейчас использую на тот момент подумал да вроди они мне и надо.

Коллега я с микрокредитами и коопиративами работаю. Но они все онлайн ;). Они напрямую из моего ПО из других городов подключаются и работают в онлайн. Разово 9Мб для работы прога качает (права доступа, интерфейс). Реализовал работу через флешку с привязкой к ней ключа в этом ключе инфа для подключения по VPN. Просто создаю ключ бросаю на флешку копию программы на флешку и все с любой точки мира можно подключаться, но нужно знать пароль к ключу на флешке. (ВПН парол знает только тот кто создал ключ.

Dimitry SibiryakovЕвгений БолтикЯ понимаю и меня интересует как правильнее, сделать по умолчанию.

1) Проанализировать на какой таблице возникают конфликты.
2) Выяснить на каких основаниях два независимых человека редактируют одну и ту же запись.
3) Разделить сферы ответственности и/или таблицу.


1.Да проанализировано.
2.1.Изменяется информация в записи "КАРТОЧКА(кредитная, скидочная или т.п.)" при добавлении подстрок на карту к примеру. То есть в 1 магазине продали по карте, бухгалтер зачислил этому сотруднику сумму на карту или списал долг. При зачислении или продаже на КАРТОЧКЕ в поле сумма происходит перерасчет остатков. Ну и при обмене 2-мя операторами естественно конфликт. Сам процесс перерасчета на карте написан так что не перекрываются авто суммы остатка. Так что даже при первом варианте данные не потеряются. В этой области подкован, практика вещ суровая. И тем более в репликации предусмотрено что такие поля хоть и физические перекрывать нельзя.
2.2 вторая ситуация когда пересекаются процедуры репликатора обмена данными. Они же разными юзерами запущены. В области таблиц подтверждений для репликатора. При работе с одними и теми же данными. Товаровед запустил обмен со своей (одной) базой, но кладовщик запустил на 10 секунд раньше. У кладовщика и у товароведа совпало на том что кладовщик только, что сделал передачу данных в базу нашего товароведа и начались проставляется подтверждения, что данные переданы. И тут процедура товароведа тоже сделала передачу того же и пытается тоже проставить подтверждение переноса. Грубо говоря так. Но по сути пофиг кто из них последний запишет данные одни и те же.
2.3 может быть еще один момент данные пере изменены и нужно стереть таблицу подтверждений а обмен с какойнить базой пытается прописать подтверждения. Это еще один особый механизм для 100% передачи данных из базы в базу. Он родился при пропаже данных на тестах.
3 сферы деятельности разделены. Мало что правиться одновременно в одном месте практически может 0.01%.

Можно конечно избежать часть столкновений репликаторских моментов но тогда придётся работать с каждой записью в отдельной транзакции, что сильно замедляет работу. Проверено на блоке удаления удаленных данных. Пришлось переписывать для быстрой работы. В одном ЕХЕ БЛОКЕ.

Вот по этим причинам и выбрал те параметры про которые рассказал в вопросе.

Dimitry Sibiryakov2.1 http://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept
2.2 Не надо давать пользователям управление репликацией. Она должна проходить полностью
автоматически.
2.3 Что-то ты бредишь, delete и insert в Firebird конфликтовать не могут.

Те параметры транзакции только понижают вероятность конфликта, но не устраняют его.


2.1 мысль интересная разжуй фразу
"Необходимо знать текущий остаток товара на складе. Прямое суммирование движений неэффективно при большом объёме данных. Создадим таблицу хранимых агрегатов:"

2.2 если я ее буду делать сам то конфликтов вообще может и не быть в моем случае. Им разрешено это делать по той причине, что:
мать твою Машка нет цены, Машка бежит в главную базу вносит цену и тут же сделала обмен с удаленной базой.
Если на автомате то нельзя сразу делать обмен после ввода цены надо подождать сек 30 хотя бы вдруг передумает и удалит или исправит. Тут можно заспориться все зависит от задачи.

2.3 тут ты меня не понял, я не про то говорил. edit того что удаляется или то же edit в другой транзакции. Забудь. Этот момент еще на целый том. При авто репликации он даже не пикнет.

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

Dimitry Sibiryakov2.1 Какое слово тебе непонятно?
2.2 Если Машка дура и цену назначает от балды, то не коммить её изменения 30 секунд. С
другой стороны - а почему, собственно, нельзя? Сейчас отреплицируется новая цена, а через
30 секунд - удалённая или исправленная. В чём проблема-то?
2.3 А вот тут и надо выяснять с какого перепою одно и то же редактируется сазу в друх
транзакциях. Что, Машка за одним столом ставит цену 100р, а её соседка Нюрка в тот же
самый момент - 200? Кто из них дура?

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


2.1 я не понял какие действия ты вложил в эту фразу. ты имел ввиду при изменении подчиненной строкой делать -ОЛД+НЬЮ в главной строке накладней?
2.2 я к тому что Маша еще не сказала, а репликатор данные передал(если авто репликация) оператор увидел и быстро продал товар а потом Маша правит и звонит оператору а тот ей уже продали .... Ладно забудь от темы уходим я это все понимаю. Но если каждого увольнять работать некому будет у нас с такими то кадрами напряженка. Хот так работают и то хорошо.
2.3 причем здесь маша продажи идут и пишутся на карту к примеру и данные обновились. Забудь тоже я это все понимаю.

И мы ушли вообще от темы вопроса который задал я.

PS. Кое что по ссылке интересное почитал. Не тебе, не мне решать как работать предприятию. Начальство сказало будет так и я ничего сделать не могу. Нету у нас админов платить не хотим, будут Машки делать это вручную. В одно ухо влетело в другое вылетело что начальство что пользователи. Я уже и видео с экрана показывал операторам так делать нельзя. Надоело, забил я на всех них и занимаюсь своим делом так что бы у меня проблем было меньше.

Dimitry Sibiryakov2.1 Какую именно фразу? Ты их процитировал три.
2.2 "Не сказала", значит не было commit, нечего реплицировать.

Ты же сам пишешь, что это не твоё дело - указывать как работать предприятию. Продали товар
по ошибке - их проблема. Не хочешь чтобы её перекладывали на тебя - пиши логи кто что
когда и почему. Ими будешь тыкать в морду лица.

Болтик, твои грабли, о которых ты так восторженно тут пишешь, каждый из здесь
присутствующих прошёл уже давно и не раз.


2.1 ты издеваешься? я уже попытался понять что ты имел ввиду и ты снова вопрос. Если на то пошло не понял полностью ту которая в кавычках была процитирована. Судя из нашего разговора.
2.2 ты сам сказал репликатор должен сам делать, а не пользователь. И если сам то автоматом через промежутки. В моем понимание внесла значит подтвердила и значит commit.

Этих начальников как грязи в каждой фирме. Да мне тыкают что не твое дело мы знаем как нам надо. По этой причине и логи ведутся и бакупы на такие случаи частые. И по случаю этому же начальству показываю и они уже профилактику проводят. А персонал как злобные ... снова те же грабли через время ;)

Я эти грабли тоже давно проходил окромя репликации в нормальном виде, мне оно не надо было. Всегда онлайн. Один клиент только захотел так работать в офлайн и то потому что его друг на 1 из другого города ему сказал так сделать. А репликация просто пригодилась мне для обновления программы. Понимаю не меньше твоего чего и где, постоянно ктонить мозги парит из клиентов. Приходишь, туда ткнул, туда ткнул и невиноват, сотрудникам прочищают потом мозги. Но а ты по существу вопроса так и не ответил который я задал. Основная прога всегда висела на одном компоненте и проблем у меня нету. И если я интересуюсь это не значит что я чего то не проходил, я сейчас некоторые моменты переосмысливаю при необходимости и переписываю. А дабы не сделать глупость переспрашиваю кто что и как. Советуюсь смотрю ничего нового значит так и будет как задумал. Походу дела узнаю дополнительную инфу и по возможности перепроверяю потом.

Dimitry SibiryakovЕвгений Болтикты издеваешься?
Нет, я действительно не в состоянии фильтровать твой мутный поток сознания.

"Необходимо знать текущий остаток товара на складе. Прямое суммирование движений
неэффективно при большом объёме данных. Создадим таблицу хранимых агрегатов:"
Это три фразы, три разных тезиса.


Прямое суммирование движений неэффективно при большом объёме данных

Dimitry SibiryakovЕвгений БолтикПрямое суммирование движений неэффективно при большом объёме данных

Предположим, существует один склад и один товар. По нему существует 100500 движений. Для
получения текущих остатков придётся извлечь и просуммировать 100500 записей. Это медленно.
И чем больше записей в таблице движений, тем медленнее.


Зачем почему не -old и +new?