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

gardenman2 ASCRUS
Не знаю как между ASA-ASA, но ASA-ASE - это выглядело чудовищно... :(
А вот не надо мазохизмом заниматься просто :)

Локшин Марк ASCRUSТак что не надо - двунаправленные репликации - это просто и удобно, если готовить на подходящей платформе.
А если добавить возможность отложенного обновления? Тогда (в зависимости от структуры базы) проблемы с целостностью могут быть большими или очень большими :) .
Думать головой при проектировании БД это второе, первое - нужно просто еще думать головой и при построении правильных технологических процессов. Для реализации репликации любого уровня сложности в ASA все необходимое уже есть. Однако каким узлам принадлежит та или иная информация, как часто будет идти обмен изменениями, кто, что и где имеет право изменять, почему и зачем информация должна изменятся на разных удаленных узлах одновременно и чья версия записи будет считаться правильной в данном случае - на все эти и прочие вопросы и необходимо первоначально знать ответ перед тем, как спроектировать БД и схему репликации. Так что я и моими коллеги по ASA в не частой периодической сеансовой репликации сложностей совсем не видим (хоть раз в год), главное знать что нужно, как правильно это сделать и иметь подходящий инструмент, функционально покрывающий потребности поставленных задач.

авторВот например, есть ли в ASA подокументная репликация, а репликация последовательности документов для сохранения целостности базы?
Что такое "подокументная репликация" и "репликация последовательности документов" ?

P.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на удаленные узлы и обратно в консолидированные реплицируются не данные, а SQL скрипты, которые были зафиксированны в лог-файле на момент их удачного выполнения. Причем в механизме лог-файла сразу предусмотренны различные расширения для репликации, позволяющие по области видимости информации указывать, по каким узлам пойдут зафиксированные DML скрипты, будут ли на узлы пересылаться все DML-операторы, выполненные внутри триггеров, есть режим прямой трансляции по узлам любых, в т.ч. DDL операторов для изменения схем удаленных БД. К примеру в консолидированной БД в таблицу добавляется поле и потом оно обновляется:
Здесь по консолидированному подписчику Pub_User на публикацию Pub_Name будет на консолидированной БД выполнено добавление столбца в таблицу и в случае успешного выполнения скрипта, разослано всем подписчикам публикации. Далее будет обновленно добавленное поле таблицы, изменения которого разойдутся по всем подписчикам в зависимости от информации, описанных в правилах репликации подписчиков. Соотвествующе в лог-файле эти SQL-операторы будут зафиксированны, в дальнейшем передадуться по удаленным БД и будут выполнены. Естественно через утилиту трансляции лог-файла их можно будет спокойно поднять из лога в SQL-скрипт чтобы посмотреть, как это выглядит на самом деле и естественно в случае потери пакетов или отката удаленной БД с бакупа ранее точки выполнения этих операторов, репликация их снова выполнит на удаленной БД. Так что лично я никаких сложностей в ссылочной целостности двусторонних репликаций ASA до сих пор не заметил

авторА, так вот пока это выясните, большая часть времени и уйдет. Пока объясните заказчику, что если проводить репликацию раз в день, и требовать чтобы все было "как в одной базе" - вещи несовместимые.
Это что то новенькое - а как же не выяснять то ТЗ, перед написанием проекта ? И на это действительно больше всего времени уходит, если мы не хотим получить безнадежный проект. А обьяснять заказчику я ничего не буду, это он мне будет обьяснять, а я ему задавать грамотные профессиональные вопросы. И кстати опять не понимаю фразы "требовать, чтобы было все как в одной базе" ? У меня различные схемы репликаций на проектах есть - и с централизованными справочниками и разделением данных по узлам и общим владением данных по узлам, даже форумы по узлам,новостные каналы и единая админстраторская консоль управления всеми узлами с любого узла - все это как бы не испытывает проблем и я не помню, что мне реализация каких либо ньюансов на ASA доставило хлопоты или геммор.

авторОчень похоже на заявления из отдела продаж :)
Это не заявления, а факты. На Украине есть пару проектов на ASA, филиалы которых периодически и не часто поднимают информацию на верх, где имеется 500-700 удаленных узлов. За рубежом реально работают проекты продаж, имеющие 10000 удаленных узлов (я уж молчу про КПК решения, там узлы никто не считает). В России так же уже имеются подобные проекты, начиная от автоматизации казино и бензоколонок, заканчивая обменом информации в крупных холдингах, где каждый узел - это огромные предприятия и большое кол-во информации. Странно, что в реальности все это прекрасно работает, причем само, без админов на узлах, а в теории Вы рассуждаете, что это невозможно или сложно

Локшин Марк ASCRUSЧто такое "подокументная репликация" и "репликация последовательности документов" ?
Пример: у нас есть документ, который хранится в базе в виде двух таблиц шапка/подвал. Допустим, какой-то документ уже среплицировался между двумя базами. И тут обнаружилось, что в документ в забили внести одну строку в подвал. Набивают в обоих базах. Происходит репликация. В результате имеем документ с лишней строкой. Это самый тривиальный пример. Если поредактировать какой-нибудь иерархический документ можно тоже много веселого поиметь (даже редактируя только различные записи на разных узлах). Можно вместо дерева запросто произвольный граф получить :)
Вот и я про тоже - не нужно путать бизнес-логику с физической реализацией. Момент изменения документа на двух удаленных узлах одновременно - это организационный момент и решается на уровне ТЗ с заказчиком, а не принципом, пущай сама репликация разруливает. Если мы ничего в этой ситуации не предусмотрем, то было бы странно, если бы сама репликация не разослала по обоим узлам и в консолидированную добавленные строки пользователями. А вот разруливается это все централизованно в консолидированной БД через триггера конфликтов версий записей и правильной логикой на удаленных узлах.

Локшин Марк ASCRUSP.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на удаленные узлы и обратно в консолидированные реплицируются не данные, а SQL скрипты, которые были зафиксированны в лог-файле на момент их удачного выполнения
И только? Других вариантов нет?

Насколько мне известно: оффлайн репликация по лог-файлу - это самый надежный, мало потребляющий ресурсов сервера и выдерживающий огромные нагрузки способ репликации серверов, гарантирующий доставку информации, ссылочную целостность, поддержку изменения схемы БД и т.д. Уж все лучше, чем срезы, timestamp и прочие танцы с бубнами, которые кстати поддерживаются в другом штатном механизме репликации ASA Mobilink, что правда было сделано из за того, что он предназначен для гетерогенных репликаций ASA с серверами других производителей и я мало видел ASA-шников, которые хотели бы иметь лишний геммор, имея на всех узлах только ASA и используя вместо SQLRemote репликацию MobiLink.

Локшин Марк ASCRUSЭто что то новенькое - а как же не выяснять то ТЗ, перед написанием проекта ?
Я про то, что это отнимет времени как бы не больше, чем реализация самой репликации на уровне послать строку/скрипт вставить сроку/запустить скрипт.
Репликацию реализовывать не нужно, она есть и все умеет. Нужно точно знать только, что нужно реализовать, а не гадать на кофейной гуще.


Локшин Марк ASCRUSИ кстати опять не понимаю фразы "требовать, чтобы было все как в одной базе" ?
А вот так. Чтобы остатки всегда актуальные были, чтобы конфликтов при изменении данных не было. Типа как с одной базой в одной сети работают. Внес и забыл...
Так и есть - есть логика движения информации, есть разделение информации по узлам и понятие общей информации, есть триггера конфликтов версий - все при правильном сложении дает искомый результат.

Локшин Марк ASCRUSТак что лично я никаких сложностей в ссылочной целостности двусторонних репликаций ASA до сих пор не заметил
Не с сылочной целостностью, а с согласованностью изменений на различных узлах,
Согласованность изменений означает согласованность процессов того предприятия, что мы автоматизируем. Если пользователи находясь в сотнях километров друг от друга меняют документ, который был внесен на основе оригинала в консолидированной БД и прислан с центра - печально конечно, но тоже лечиться, если стоит в условиях ТЗ.

Локшин Маркулыбчивый вы наш.
Спасибо, Вам тоже желаю хорошего настроения

Локшин МаркТа же построчная репликация позволяет снизить траффик при частом обновлении одних и тех же строк за периоды между репликациями. И представляете, с полями одной и той же записи - ну никаких проблем. А моментальными снимками - при больших периодах между сеансами. Естественно, есть и свои недостатки, но...
Есть у меня проекты, где одна и та же расчетная информация мутузиться сколько угодно раз, добавляется, изменяется, удаляется в пределах открытого расчетного периода в специально отведенных под это таблицах (кэшах). Если бы я ее постоянно реплицировал, то вместо репликации был бы сплошной спам. Однако все проще - как только период закрывается, данные фиксируются в таблицы фиксированного хранения информации, которые уже подвязаны на репликацию и все конечные изменения уходят наверх в консолидированную БД и по другим удаленным узлам, имеющим область видимости этой информации. Еще можно вспомнить фильтры WHERE на информацию, что позволяет помимо распределения информации по кодам подписчиков отсылать не все записи таблиц (например по флагу готовности).

Локшин МаркПочему сотрудники разных филиалов не могут вносить изменения в один и тот же документ? Чем это отличается от возможности изменения документа на разных рабочих местах? Т.е. по вашему внесли мы документ на компьютере 1, и все не редактировать не удалить его с других компьютеров мы не можем?
Все таки Вы Марк путаете бизнес-логику и реализацию. По определению один документ не могут одновременно править два человека, ибо только один из них имеет зафискированный оригинал, с которого шли исправления (если они конечно ксерокопией его не размножили). А вот если документ составной, то его дочерние документы вполне могут править разные люди, наглядный пример - юрист заключил с клиентом договор на покупку недвижимости и расписал плановые платежи по рассрочкам и ссудам. В процессе работы с документом другие юристы вносили дополнительные соглашения к договору, фиксируя их документами. В отделе платежей по пришедшим платежам фиксировалась платежки, пришедшие от клиента. Аналитики использовали информацию для построения отчетов и выявления неплательщиков, с передачей данных юристам для выставления пеней. Поэтому мне странно представить себе одновременную правку одного документа что через онлайн в сети, что в оффлайне через репликации, это явное нарушение технологического процесса, которое сразу начинает ассоциироваться с автоматизацией бардака.

Александр ГoлдунНу, везде есть недостатки и достоинства. Из всего, что я видел и
анализировал, для решения задач с которыми я сталкиваюсь более всего
подходит ASA, причем с большим отрывом. В других условиях возможно
подойдет что-то более другое, но в плане поддержки репликации, особенно
offline, многими ASA признается лучшим выбором.
Полностью подписываюсь. Правда сейчас насколько я читал, достаточно неплохо подтянули уровень механизма репликаций в Юконе, однако как мне показалось, по функциональным возможностям он все таки не дотягивает до уровня ASA, хотя в описаниях тоже выглядит неплохо и в дальнейшем я надеюсь будет возможность рассмотреть и сравнить достоинства и недостатки репликаций MSSQL2005 с репликациями ASA на живых проектах, а не только по описаниям.

P.S. И я тоже кстати навряд ли тяну на маркетингового представителя Sybase, как раз наверное наоборот, я в данном случае провожу антимаркетинговую политику, так как в представительствах Sybase признается исключительно ASE. Но против истины не попрешь - ASA действительно хороша и многое умеет :)

Марк, а я утверждаю из личного опыта, а так же опыта своих коллег. Не знаю, что там Билли или Ларри говорили, не имея еще на руках реально работающего ПО, но как бы приведенные мною возможности ASA показывают, что на функциональном уровне реализации репликаций все необходимое есть. Если есть какие то сомнения в недостающей функциональности, то я всегда готов ответить на вопросы, поэтому мне не понятна, в чем Ваши сомнения. Это мне напоминает сомненья типа, у нас этого нету, значит этого нигде нету, что не раз демонстрировалось на различных форумах SQL.RU. Хорошо, лично для Вас я переформулирую: ASA в области двусторонних оффлайн репликаций умеет не хуже и в некоторых планах лучше решения, чем решения производителей других РСУБД. Такая формулировка подойдет ?

Локшин МаркНикакая это не автоматизация бардака. Привожу конкретный пример.
Есть центральный офис. Есть склад. В центральном офисе дают разрешение отгрузить Иванову 1000 ед. товара. Иванов берет пять машин и едет на этот склад забирать товар на 5 машинах, допустим с этим разрешением. Ему отгружают в эти 5 машин товару, допустим по 100 единиц, а когда ТТН оформляли - одну строку пропустили. Уехал он со своим товаром. На следующий день в центральный офис. Давайте мне счет-фактуру. А счет-фактура выписывается только на основании отгрузки, т.е. той ТТН, которая ночью, допустим, попала в центральный офис. А там 4 строки. Что делать? Говорить - звиняйте, завтра приезжайте, сейчас нам подправят на складе, а завтра к нам изменения только дойдут? Изменять на месте? А если на складе обнаружат, что не верно ввели, но данные уже отправлены?
Самое интересное, что данная ситуация решается обычными административными мерами. В любом случае в центральном офисе после обнаружения неправильной ТТН позвонят на склад, ведь так ведь ? В любом случае на складе поднимут ТТН и сверят с данными в программе ? В любом случае для правильного оформления в центральном офисе им придется по факсу или телефону выслать правильные данные, которые вобьются в центральном офисе и вниз спустяться на склад во время следующей ночной репликации. Это наиболее вероятная ситуация. Рассмотрим более нестандартную и маловероятную ситуацию (во всяком случае в моем представлении) - ночью прошла репликация и кладовщики вдруг с какого то перепугу вдруг вспомнили, что они что то неправильно оформили и вбили это в программу. Соотвествующе данные попадут только на следующую ночь, а клиент уже приехал в офис и жаждет счета фактуры. Ок, раз есть такая ситуация, значит и в структуре БД необходимо предусмотреть пути ее решения. В таблицу ТТН добавляем флаг IsLocal, на фильтр репликации вешаем IsLocal = 0 и на триггер добавления записей вешаем удаление из таблицы записи с IsLocal = 0, по номеру строки равному номеру вставляемой из репликации записи. В итоге ночью придут оригинальная строка со склада, автоматом удалит временно введенную строку в офисе, однако это удаление не отобразится в репликации и на склад удаление этой строки не пойдет. Следующая ситуация - в офисе и на складе поменяли одни и те же существующие записи. Тут мы спокойно все сможем урегулировать, написав триггер на конфликт версий, в котором может определить, чью строку считать правильной, а чью откатить до состояния правильной - по последней дате изменения, по приоритету что здесь складская информация является оригинальной, и т.д. Так же никаких сложностей. Хотя лично считаю, что пример притянут за уши и я бы на самом деле после отпуска машины со склада блокировал флагом документ на складе, чтобы его изменить мог только офис, как более приоритетная организация, решающая вопросы таких ошибок, во избежания ошибочных ситуаций и увода от отвественности кладовщиков, допускающих такие серьезные ошибки.

Все проще, реально у меня есть понимании ситуации - как никак если посмотреть на оформление ГТД начиная отпуском от постов и завершая завершением оформления на таможнях, с параллейным движением платежек сверху вниз к таможням, да еще с почетным кругом через наличку - то есть задачки и посложнее ситуации с недобросовестными кладовщиками, однако в любом случае любой процесс требует документрирования и четкого разграничения на административном уровне что прав доступа, что ситуаций изменения информации в пути, что прочих неприятных ситуаций. Иначе можно и правку закрытого опердня в банке разрешить, мало ли, оператор ошибся, а утром вот вспомнил ;)

авторМожно чуть подробне, особенно в районе "номера вставляемой из репликации записи".
Извиняюсь, что не точно выразился. Я имел ввиду, что в любом случае строка ТТН должна помимо синтетического ключа иметь естественный ключ (хоть порядковый номер в накладной, вбиваемый ручками) и именно по этому ключу можно было бы отследить, что пришла запись с IsLocal = 0 и на нее уже существует с таким же натуральным ключом запись с IsLocal = 1, т.е. как временно введенная и ожидающая своего замещения с удаленного узла. Так или иначе мне кажется для конкретной задачи можно найти множества вариантов решений и выбрать из них наиболее оптимальный и лучший. Ну а кол-во таких решений определяется (ограничивается) как раз рамками функциональности сервера, на котором пишется проект. Здесь меня ASA вполне устраивает именно тем, что у этого сервера присутствует на борту широкий функционал, который позволяет мне действительно большой выбор решений и главное, легкий в освоении и использовании, с минимальным кол-вом ограничений и условий применения (ветвления), и сделанный в единой концепции языка WatomSQL, без каких либо прикруток, примочек или привязки к ОС (естественно кроме таких расширений, как поддержка MAPI, SNMP и т.д.).

Локшин Марк ASCRUSЗдесь меня ASA вполне устраивает именно тем, что у этого сервера присутствует на борту широкий функционал, который позволяет мне действительно большой выбор решений и главное, легкий в освоении и использовании, с минимальным кол-вом ограничений и условий применения (ветвления), и сделанный в единой концепции языка WatomSQL, без каких либо прикруток, примочек или привязки к ОС (естественно кроме таких расширений, как поддержка MAPI, SNMP и т.д.).
Ну не знаю. Мне просто больше нравится идея такой "подокументной" репликации в том случае, про который я говорил. Достаточно легко отследить все такие "нехорошие" случаи взаимного изменения данных, без всяких фокусов с такими дополнительными полями и т.д. У нас все скрипты (тригера, sp) генерятся по некоей метаинформации о базе в один скрипт, запускаеь его и репликация готова. :) Удобно.
Ну тут кому как удобно и кто на чем готовит :) Я просто стараюсь всеми силами избегать велосипедов и пользоваться штатным функционалом. До перехода на ASA это не удавалось в полном обьеме, сейчас тьфу тьфу, куча проектов различных направлений и сложности, а ничего прикручивать не пришлось.

Так и есть - через WHERE можно определить фильтр, под который будут попадать в репликацию записи (как раз мой пример с IsLocal). Перечислением полей можно указать, какие поля будут реплицироваться. А через указание поля или выражения кода подписчика можно регулировать направление движение информации по удаленным узлам (что как раз наглядно демонстрирует вот этот топик ).

protectorТ.е. как я понимаю в публикации под условие Where попадают как уже удалённые
так и не удалённые записи. А состояние записи (удалена не удалена) можно
проверить?
Во первых когда на удаленной или консолидированной БД применяются изменения, то в срабатываемых триггерах можно спокойно видеть, кто их вызывает - пользовательская сессия или же репликация. Во вторых как я уже говорил, все что пойдет по репликации фиксируется в логе, причем фиксируется на момент произведения DML операции. Соотвествующе это означает, что мы на публикацию таблицы можем нацепить выражение/запрос в WHERE и в SUBSCRIBE BY (возврат кода подписчика для определения видимости информации). Таким образом, отвечая на Ваш вопрос, пишем в WHERE для публицируемой таблицы:
Здесь я отсекаю по репликации изменяемые записи, если поле Field равно 1 и удаляемые записи, если Field равняется 2. INSERTINT/UPDATING/DELETING - это ключевые слова WatcomSQL, позволяющие определить, какая операция производится на текущий момент, разрешенные к использованию в триггерах и всех процедур, функций и операторов, попадающих в внутрь области видимости триггера. Таким же образом я могу в WHERE репликации поставить свою функцию и вызывать ее с параметрами, передавая к примеру поля реплицируемой таблицы. В общем тут насколько хватает фантазии

авторПотому что, при репликации любое значения нужно искать не только по столбцу и ключу, но и по имени сервера.
Это еще как ?