Как отслеживать время реплицируемых строк для подписчиков в SQL Server 2005?

Основная проблема заключается в следующем: Абонент успешно реплицировал строку из издателя, используя транзакционную репликацию. Теперь, как мы отслеживаем время последней успешной репликации этой строки?

Друг предложил следующее решение, которое он использовал для своего SQL Server 2000: 1) Добавьте столбец datetime. 2) Измените хранимую процедуру репликации, чтобы обновить столбец datetime (!).

На шаге №2 меня предупреждают всевозможные предупреждающие сигналы, поэтому я спрашиваю, есть ли в этой ситуации лучшие решения для SQL Server 2005, прежде чем я даже подробно рассмотрю его решение.

4 ответа

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

Проблема с этим подходом заключается в том, что вам нужна блокировка записи, но я не вижу другого практического пути.

В противном случае вы могли бы использовать триггер, который срабатывает при извлечении строки (не цитируйте меня на этом, я редко использую триггеры), но это не кажется правильным (вы можете положить конец ложным срабатываниям)


У меня была эта точная проблема несколько недель назад, пытаясь найти недавно измененные записи.

Создайте новый столбец и установите тип данных в TIMESTAMP. SS2005 автоматически обновляет этот тип при обновлении строки. Единственная проблема заключается в том, что эта метка времени не имеет ничего общего с датой или временем, это всего лишь номер, который отражает последнее успешное обновление этой строки (любое обновление, а не только через репликацию). Если это все, что вам нужно, тогда все будет хорошо.

Если вам нужно последнее обновление репликации, все может немного запутаться, и вам нужно замарать руки триггерами и хранимыми процедурами.

http://www.sqlteam.com/article/timestamps-vs-datetime-data-types

Надеюсь, что помогает ~


@Philippe: Основная проблема с этим подходом заключается в том, что репликация может занять некоторое время, чтобы добраться до какой-либо из более удаленной базы данных из-за плохого сетевого подключения. Таким образом, время обновления основной записи не будет отражать время записи, реально реплицируемой в удаленной базе данных.

В любом случае, я проверил метод моего друга, и он отлично работал для нашего требования.

Если кто-то хочет это сделать, обратите внимание: обратите внимание на инициализацию подписки и изменений будущей схемы.

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


Если вы работаете с транзакционной репликацией, почему бы вам просто не записать время первичного обновления данных и считать, что оно было реплицировано в другие базы данных в следующем задании репликации?

licensed under cc by-sa 3.0 with attribution.