Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
При получении некоторых изменений по репликации удаленная база не смогла их приложить из-за элементарных ляпов, типа нарушения ссылочной целостности с таблицей, не участвующей в репликации. Ошибка устранена, дальнейшие изменения проходят, но таблицы остались в несинхронизированном состоянии. Отличаются как раз на те самые ошибки. Как это лучше всего исправить в удаленной базе (добавить нужные записи, удалить ненужные), ничего не меняя в консолидированной? Через PASSTHROUGH ONLY FOR userid со стороны консолидированной базы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 20:22 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Самое простое, остановить репликацию, сделать изменения, стартовать репликацию опять. На удаленой: Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 22:18 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Александр ГoлдунЧерез PASSTHROUGH ONLY FOR userid со стороны консолидированной базы? скорее всего да. данные не вставились по причине ограничения внешнего ключа? кстати, я заметил, что при выгрузке новой копии базы, ASA заменяет внешние ключи таким образом, чтобы они могли быть NULL, наверное как раз для случаев, когда подчиненные строки приехали, а главные нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 22:19 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Рыжий Кот пишет: > данные не вставились по причине ограничения внешнего ключа? Да. > кстати, я заметил, что при выгрузке новой копии базы, ASA заменяет > внешние ключи таким образом, чтобы они могли быть NULL, наверное как раз > для случаев, когда подчиненные строки приехали, а главные нет Насколько мне известно, в ASA невозможно такое нарушение ссылочной целостности между таблицами, участвующими в репликации, даже если они объявлены в разных подписках для одного подписчика. У меня нарушился FK на таблицу, которая не была в репликации - синхронизировалась другим путем. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 00:52 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Насколько мне известно, в ASA невозможно такое нарушение ссылочной целостности между таблицами, участвующими в репликации, даже если они объявлены в разных подписках для одного подписчика. к сожалению возможно :( например у вас уникальный индекс, например на номер документа, и на обоих концах в пределах простоя репликации добавили по одному документу. Нумерация идет по возрастающей. Соответственно на одном из узлов (или даже наобоих) не придет нужный документ, а значит и подчиненные строки вылетят с сообщением в логе dbremote no primary key.... по этой причине я часто не создаю уникальные индексы для потенциально конфликтных таблиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 10:01 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Рыжий Кот пишет: > к сожалению возможно :( > например у вас уникальный индекс, например на номер документа, и на Нет, я имел в виду ситуацию с нарушением FK между двумя таблицами по причине того, что нарушится последовательность например вставки. Если обе таблицы участвую в репликации, пусть даже и в разных подписках, в какой последовательности были изменения в одной базе, в такой же они и приложатся в другой. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 12:55 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
Александр ГoлдунПри получении некоторых изменений по репликации удаленная база не смогла их приложить из-за элементарных ляпов, типа нарушения ссылочной целостности с таблицей, не участвующей в репликации. Ошибка устранена, дальнейшие изменения проходят, но таблицы остались в несинхронизированном состоянии. Отличаются как раз на те самые ошибки. Как это лучше всего исправить в удаленной базе (добавить нужные записи, удалить ненужные), ничего не меняя в консолидированной? Через PASSTHROUGH ONLY FOR userid со стороны консолидированной базы? Я в этой ситуации запрашиваю удаленную БД и через proxy ищу расхождения и добавляю данные. Или ручками из лога репликации вырезать и выполнять, но это муторная работа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 13:05 |
|
||
|
ASA. Исправление ошибок в репликации.
|
|||
|---|---|---|---|
|
#18+
А вот такое (см. ниже) не спасет отца русской демократии ? UPDATE table PUBLICATION publication { SUBSCRIBE BY expression | OLD SUBSCRIBE BY expression NEW SUBSCRIBE BY expression } WHERE search-condition "PASSTHROUGH ONLY FOR userid" годится только для изменения структуры базы (ИМХО) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 17:43 |
|
||
|
|
start [/forum/topic.php?fid=55&gotonew=1&tid=2013123]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
9ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 354ms |
| 0 / 0 |
