Репликация или давайте жить дружно.

Тема горячего жареного гуся типа like a cat on a hot bricks. Хочешь пользоваться, а не можешь.
Что мешает?

1. Связанные данные. Это как раз то, что нагородили разработчики БД, пытаясь внести некие логические связи в схему. Это и констрайнты, и нот нулы, и ... Я называю это спотыкач, по имени гарной хохляцкой горылки.

2.Версионность. Какой же программист, извините меня, не ведет записи типа:"здесь были киса и ося". Число и версию можете поставить сами. Любая собака метит свои места. Если вторая собака видит помеченное место, то она тоже метит и увеличивает номер версии. Но какая то сука (тоже собака) дает избирательно только одной версии. М.б. это и верно, но не для репликации.

3.Динамический контент БД. Правда он не во всякой БД присутствует, но в моей БД его достаточно в виде бизнесс процессов. Так вот, статический контент БД (подлежит репликации) базируется на динамическом контенте БД бизнесс процессов (не подлежит репликации). Типа мне нужна ваша невозмутимость, а свои эмоции засуньте себе в ...

4. Права доступа к данным. Мы вытащили нечто из одной БД с некоей оснасткой доступа и положили в другую БД со своей оснасткой прав. Что получается? Получаются голые guids, которые надо разрешать ручками или прописывать некую схему трансформации прав доступа. Что называется "На страже Родины", "Враг не пройдет", ... Прошу добавлять лозунги.

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

29

Когда презрен фортуной и людьми,
Когда один, отвержен и гоним,
Я небу приношу мольбы любви
Изгоя, путь земной неисправим.

Кто верит в человечества князей,
А у того искусства дар или влюблен,
Кто красотой богат,обилием друзей,
Изгоя путь лишь небом наделен.

Святое небо, уповаю на тебя,
Когда, вдруг чувствую, что я тобой призрен,
Взлетает жаворонком вверх Душе моя
И у ворот небес стою почти нетлен.

Мысль о тебе дают душе богатство,
Что Дух бессмертен и обрящет царство.

Forums: 

Механизмы репликации, встроенн

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

Если это условие не выполняется, то нужен свой репликатор. К Ультиме Жемеров такой в свое время написал - переносил классы, методы, папки, документы по выбраным критериям.

ДТ года 3 назад излакал идею универсального поратала по обмену данными (объектами), я тогда ее раскритиковал. Признаю был не прав. Оракл в прошлом году выпустил Data bus - портал обмена информацией.

Изображение пользователя ipanshin.

нужен свой реплик

нужен свой репликатор.

То есть агента репликации snapshot сразу выкидывать на помойку? А зачем он тогда писался?

идею универсального поратала

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

У меня большое желание реплицировать все, а потом правами доступа вырезать доступное для БД подписчика.

переносил классы, методы, папки, документы по выбраным критериям.

Что дешевле вырезать и переносить или перенести все, но дать только то, что можно. На первый взгляд вроде первое.

Изображение пользователя st.

Кроме снапшот-репликации есть

Кроме снапшот-репликации есть еше транзакционная и слиянием.
Вторая наиболее надежна, но требует онлайн.
Для фильтрации есть штатные средства: пишешь процедуру, она отсекает ненужное
sp_articlefilter (Transact-SQL)

Изображение пользователя ipanshin.

Спасибо.Вторая н

Спасибо.

Вторая наиболее надежна

LogRead vs. ReplMerg. Поясни, плз. Что же она дает ошибки или может не окончиться?

Изображение пользователя st.

LogRead vs. ReplMe

LogRead vs. ReplMerg. Поясни, плз. Что же она дает ошибки или может не окончиться?

Она не соблюдает порядок. Т.е. может сначала передать строки из подчиненной таблицы, а потом из главной. Если есть внешние ключи, то это дает ошибку, которая штатными средставми не решается, надо через одно место или так
ADD ... FOREIGN KEY ... NOT FOR REPLICATION

Изображение пользователя ipanshin.

При ближайшем рассмотрении про

При ближайшем рассмотрении процесс репликации не так дешев.

1. Добавляется одна колонка rowguid uniqueidentifier, not null к реплицируемым таблицам. Отсюда появляется особое требование к приложению, работающему с БД. Оно должно быть инвариантно к появлению таких колонок.

2. Добавляются триггера как мин три на insert,delete and update с не маленьким контентом.

3. В скриптах генерируемых автоматически все-таки отсутствуют ряд объектов и доп. проверок наличия/отсутствия, которые должны быть.

Так что слиться (merge) в экстазе не так просто. :)

Изображение пользователя st.

Да. Поэтому надо всеми силами

Да. Поэтому надо всеми силами стараться использовать транзакционную репликацию. Однонаправленную.
Там указанные недостатки отсутствуют (наследие Sybase).

Изображение пользователя ipanshin.

всеми силами</bloc

всеми силами

Да я за транзакционную однонаправленную репликацию.

Изображение пользователя ipanshin.

В конечном итоге в

В конечном итоге выбрана все же merge репликация.

Что важно знать.

1. В БД подписчика должна входить только одна стрелка. Т.е. микрософт предлагает только такие варианты репликации как
БД<-->БД и БД-->БД, что в переводе БД<-->БД<-->БД не позволено и БД-->БД<-->БД также не позволено. Позволено БД<--БД<-->БД-->БД ну и т.д.

Т.е. задача консолидации данных в единой БД репликацией в чистом виде не решить и надо придумывать механизм консолидации данных в БД публикатора на основе "расщепления таблиц", что дает замечательный результат по консолидации данных в рамках одной БД или главного офиса и списка подписчиков или его филиалов.

2. Хитрая колонка rowguid, добавляемая к любым публикуемым объектам, представляет определнную трудность при работе с вью.

3. Никуда не деться. Все же пришлось писать свой API слой ХП, которые честно разбирают ситуацию в БД и делают нужные действия, а не кричат тебе, ты не можешь удалить публикацию так как на нее существует подписка. Такой кричащий, я бы сказал, стиль написания sp_ процедур мягко говоря задалбывает.