Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
Добрый день. Ситуация следующая. Имеется контора, у которой 38 филиалов, расположены по всей области и объединены в КПСД. Нужно настроить репликацию, только в одну сторону, так как в головной конторе данные нужны только для просмотра. Данные реплицируются только раз в сутки, и задержка данных в один день, пока всех устраивает. Теперь о самой репликации. В районных серверах передаваемая информация находится в 9 таблиц, и все они включены в репликацию. В головном офисе , в базе имеются скажем 9 буферных таблиц куда принимаются данные с репликации. На каждой буферной таблице имелся только один триггер на Insert, назначение которого было перебросить реплицируемую запись в конечную таблицу, и удаление этой записи из буфера. После того как, уже настроил репликацию с половиной филиалов, обнаружил. Что я не отлавливаю, записи которые удаляются на районном уровне. Если новые и измененные записи, с районов реплицируются, то удаленные просто остаются в базе. И тут сразу же возникли две проблемы. Как отлавливать в буферной таблице, что репликнулась удаленная запись, при постоянно пустой буферной таблице. Понятно, что надо как то отлавливать триггером на Delete, но каждая запись удаляется из буфера , как только она перекинется в конечную таблицу. В общем решил, изменить схему репликации, и сделать буферные таблицы конечными. Проверил, вроде бы все реплицируется нормально Insert, Update и Delete. Но когда стал, настраивать репликацию со следующим филиалом, Все что было в буферных таблицам, до первой репликации с новым филиалом кануло в никуда. Вычитал в доках, что вроде бы так и должно быть. Сейчас встал вопрос, либо вернуться к первому варианту, и пытаться как-то отловить те записи, которые удаляются на районе. Либо по второй схеме, при выполнение первоначального рефреша, как-то сделать, что бы записи в приемных таблицах не удалялись. Сам склоняюсь, ко второй схеме. Планировал закончить репликацию до конца месяца, но видно не судьба. Буду признателен за любые советы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 06:17 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
OlegA67Но когда стал, настраивать репликацию со следующим филиалом, Все что было в буферных таблицам, до первой репликации с новым филиалом кануло в никуда. Вычитал в доках, что вроде бы так и должно быть.Первоначальную перезагрузку таблицы-приемника можно отключить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 10:31 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
При настройке репликации со следуующим филиалом, установите параметр APPLY "Полное обновление - вручную", тогда очередная APPLY не будет удалять предшествующие записи. Можно сделать и так: если у каждого филиала в данных есть какой-то уникальный признак, отличающий его от других можно на 1 таблицу назначения наделать 38 вьюшек типа "Select * from My.Tables Where признак" и реплицировать из таблицы каждого филиала в свою вьюшку на приемной стороне. В этом случае любая APPLY гарантированно чужие записи в таблице назначения не тронет. Метод не ахти какой (в смысле вьюшек много нужно делать), но мне по некоторым причинам пришлось им воспользоваться, работает гарантированно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 10:40 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinПервоначальную перезагрузку таблицы-приемника можно отключить. Прием данных настраиваю, через Центр репликации, и там я не видел , чтобы можно было бы выставить отменить перезагрузку таблицы-приемника. Можно об этом поподробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 12:09 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
Использовать "логическое" удаление? т.е. завест некий признак "удалено" и тогда при репликации сможешь отловить что удаляли в филиалах, "удаленные" записи время от времени можно чистить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 13:02 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
OlegA67Прием данных настраиваю, через Центр репликации, и там я не видел , чтобы можно было бы выставить отменить перезагрузку таблицы-приемника. Можно об этом поподробнее. Тут . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 13:02 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein Тут . Маленькое уточнение, это применино к 8 версии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 13:48 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
OlegA67Маленькое уточнение, это применино к 8 версии?Должно быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 13:56 |
|
||
|
SQL Репликация несколько источников один приемник, зашел в тупик
|
|||
|---|---|---|---|
|
#18+
Не смог найти, описание ни в руководстве SQL Replication Guide and Reference для версии 8.2, ни в информационном центре. В качестве решения выбрал , ручное обновление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 06:27 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=34821348&tid=1604288]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 427ms |

| 0 / 0 |
