MS SQL синхронизация / Timestamp

← →
Ellisium © (2014-11-11 19:26) [0]

Верен ли нижеприведенный алгоритм синхронизации удаленной БД с центральной БД?

1) имеем запомненное с предыдущей синхронизации значение @oldTimeStamp (в первый раз равное нулю) для удаленной таблицы
2) определяем максимальный timestamp в удаленной таблице типа:

select @newTimeStampmax=max(timestamp) from MyTable

3) делаем выборку всех записей в удаленной таблице: ... where timestamp >= @oldTimeStamp and <= @newTimeStamp

Записи, попавшие под условие - синхронизируем в центральную базу.
Отдельная песня - удаление записей.

4) запоминаем @newTimeStamp для этой таблицы в пункт 1) как @oldTimeStamp для следующей синхронизации.

Есть ли недостатки?

← →
Ellisium © (2014-11-11 19:30) [1]

Ну в принципе я вижу один подводный камень в виде вопроса. После того, как выполнен запрос:

select @newTimeStamp=max(timestamp) from MyTable

может ли в таблице появиться запись, у которой timestamp будет меньше или равен @newTimeStamp?

← →
Ega23 © (2014-11-11 19:46) [2]

> Есть ли недостатки?

http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.110%29.aspx

> После того, как выполнен запрос:

По-идее, эти дела надо в snapshot-транзакции у источника делать.

← →
Ellisium © (2014-11-11 19:49) [3]

> http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.
> 110%29.aspx

Эта статья не противоречит моему алгоритму, но они и не подтверждает основной вопрос, сформулированный мной в Ellisium © (11.11.14 19:30) [1]

← →
Ega23 © (2014-11-11 20:19) [4]

Скажем так. Задачи связанные с синхронизацией времени - наиболее муторные. В частном случае твой алгоритм будет работать. В общем - можно придумать ситуацию, когда нет.
Именно это я и имел ввиду, когда о недостатках писал.
Тут надо внимательно на исходные условия смотреть. Может синхронизируемая таблица небольшая, тогда имеет смысл её вообще полностью перенести например. Или сделать составную искусственную метку guid + rowversion. Или ещё что-нибудь.
Одного timestamp, ИМХО, будет мало. Вдобавок я уже не помню, он в UTC идёт или нет, а это тоже проблема.

← →
Кщд © (2014-11-11 21:11) [5]

>Ellisium © (11.11.14 19:26)
учитывая транзакционность и часовые пояса, ваше решение не будет работать, в общем случае

← →
TohaNik © (2014-11-11 21:15) [6]

Опять же ИМХО. Блокировки нужны. Сыылку не читал.

← →
Кщд © (2014-11-11 21:16) [7]

вдогоночку: не надо выдумывать велосипед при наличии штатных средств
тем паче, не понимая основ РСУДБ

← →
Кщд © (2014-11-11 21:17) [8]

*РСУБД))

← →
Ega23 © (2014-11-11 21:21) [9]

> не надо выдумывать велосипед при наличии штатных средств

Штатные средства, порой, тоже ещё с теми загогулинами бывают.
К примеру, в том же MSSQL (2000 - это точно, как в новых - не знаю) тип datetime имел дискрет в 3 миллисекунды.

← →
TohaNik © (2014-11-11 21:32) [10]

И иногда текущее время не совсем текущее...

← →
Ega23 © (2014-11-11 21:41) [11]

> И иногда текущее время не совсем текущее...
>

Синхронизация между разными машинами - вообще отдельная и очень больная тема.

← →
картман © (2014-11-11 21:46) [12]

> Ega23 © (11.11.14 20:19) [4]

> он в UTC идёт или нет

а что такое UTC? Или что у них там написано:
Типы данных rowversion и timestamp являются синонимами. ... Тип данных rowversion является увеличивающимся числом и не основан на дате или времени
?

← →
TohaNik © (2014-11-11 21:54) [13]

> Ellisium © (11.11.14 19:26)
> Верен ли нижеприведенный алгоритм синхронизации удаленной
> БД с центральной БД?

> Ega23 © (11.11.14 21:41) [11]
> > И иногда текущее время не совсем текущее...> Синхронизация
> между разными машинами - вообще отдельная и очень больная
> тема.

На радостях отпуска всяко не внимательно читаю.
Но даже при центральной БД, иногда текущее время не совсем текущее...;)

← →
Ega23 © (2014-11-11 21:55) [14]

> а что такое UTC?

https://ru.wikipedia.org/wiki/%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%D0%BD%D0%BE%D0%B5_%D0%BA%D0%BE%D0%BE%D1%80%D0%B4%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B2%D1%80%D0%B5%D0%BC%D1%8F

> Типы данных rowversion и timestamp являются синонимами

Я вот тоже удивился, честно говоря.

← →
картман © (2014-11-12 11:58) [15]

> Ega23 © (11.11.14 21:55) [14]

ну я и спрашиваю, какое отношение число, не относящееся к дате, имеет отношение к UTC? Или справка кривая?))

← →
Кщд © (2014-11-12 13:46) [16]

>Ega23 © (11.11.14 21:21) [9]
>Штатные средства, порой, тоже ещё с теми загогулинами бывают.
согласен абсолютно
но это повод разобраться со штатными средствами, а не "пилить" собственную нерабочую синхронизацию а-ля "select @newTimeStamp=max(timestamp) from MyTable"

← →
Ega23 © (2014-11-12 14:19) [17]

> ну я и спрашиваю, какое отношение число, не относящееся
> к дате, имеет отношение к UTC? Или справка кривая?))

ХЗ, если честно. Я вчера прочитал и очень удивился.

← →
TohaNik © (2014-11-12 14:43) [18]

> но это повод разобраться со штатными средствами

Там тоже люди...
А дата + время нельзя, наверное, для случки использовать, даже если с поясами разобрались.Там ИМХО даже время обработки кода гуляет.

← →
Труп Васи Доброго © (2014-11-12 15:07) [19]

> может ли в таблице появиться запись, у которой timestamp
> будет меньше или равен @newTimeStamp?

А твоё изобретение сработает, когда запись не добавят или изменят, а удалят?

← →
TohaNik © (2014-11-12 18:32) [20]

> Отдельная песня - удаление записей.

> А твоё изобретение сработает, когда запись не добавят или
> изменят, а удалят?

Нельзя удалять.

← →
Труп Васи Доброго © (2014-11-13 11:38) [21]

> Нельзя удалять.

А как же ошибки? А срабатывание триггеров? Затея с привязкой ко времени гнилая изначально. Это проколется либо на рассинхроне времени на машинах, либо на записях, изменённых во время синхронизации, либо ещё как. Проще записывать по порядку все SQL команды, приходящие к БД и при синхронизации передавать их же на дубликат.

← →
TohaNik © (2014-11-13 12:59) [22]

> А как же ошибки? А срабатывание триггеров?

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

← →
Труп Васи Доброго © (2014-11-13 13:30) [23]

> Тригеры в коде бизнес-процесса зло

Не знаю что такое "бизьнесъ-процессъ", извините, но отсутствие триггеров в БД на мой взгляд, должно означать увольнение архитектора этой БД однозначно. И как же у вас в БД организована целостность? Руками все логические связи отслеживаете и изменения вносите? Тогда зачем вообще БД нужна? Бумага и три слоя копирки, вот и будет синхронизация данных, причём мгновенная.

← →
Труп Васи Доброго © (2014-11-13 13:38) [24]

> Ошибки выявлять надо до записи в базу

Это как? Примеры:
1) Продали товар, занесли информацию в базу, потом покупатель товар вернул (совсем или обменял на другой).
2) Приняли товар на склад по накладной, занесли в БД, в одном из 100500 ящиков оказались "носки вместо трусов", надо делать возврат поставщику (с уменьшением стоимости, изменением договора и т.д. либо с заменой)
И таких вариантов море морьское. Как ты, о знаток "бизнесс-процессов" выявишь такие ошибки ДО внесения в БД???

← →
TohaNik © (2014-11-13 13:41) [25]

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

← →
Труп Васи Доброго © (2014-11-13 13:51) [26]

> Не надо просто их отрабатывание связывать с действиями пользователя,
> хотя бы визуально.

Э.......э........ъ..?
??? КУДА ???

← →
Труп Васи Доброго © (2014-11-13 13:53) [27]

> Не надо просто их отрабатывание связывать с действиями пользователя,
> хотя бы визуально.

Прочитал ещё несколько раз... Только два вопроса возникло: Где грибочки брал и сколько стоят?

← →
TohaNik © (2014-11-13 13:54) [28]

> "носки вместо трусов", надо делать возврат поставщику (с
> уменьшением стоимости, изменением договора и т.д. либо с
> заменой)

И причем тут триггеры?

← →
brother © (2014-11-13 13:55) [29]

забористая трава

← →
Труп Васи Доброго © (2014-11-13 13:57) [30]

> И причем тут триггеры?

Потому что "сторно"!

← →
Труп Васи Доброго © (2014-11-13 14:00) [31]

Я гидроусилитель руля, АБС и климат-контроль не хаю. Не надо просто их отрабатывание связывать с действиями пользователя, хотя бы визуально.
Аналогия ясна?

← →
TohaNik © (2014-11-13 14:01) [32]

Да сторно, уже как бы отмена. и при чем тут триггеры?

← →
TohaNik © (2014-11-13 14:07) [33]

по факту... :)

← →
Труп Васи Доброго © (2014-11-13 14:11) [34]

> как бы отмена

Правильно, "как бы"! Ведь перед тем, как удалить запись о "трусах" на складе надо проверить, а не отправили ли этот ящик в магазин и не продали. Если не продали, то сформировать заявку на возврат, забронировать место в транспорте, оформить накладную на возврат на склад и т.д и т.п. То есть проверить на возможность удаления, сделать все необходимые перед удалением действия, а уж только потом удалять. Ты предлагаешь всё это делать вручную? Это работа триггеров.

← →
TohaNik © (2014-11-13 14:16) [35]

Да удалять ничего не нужно!

← →
Ellisium © (2014-11-13 16:37) [36]

Ребят, хотелось бы услышать мнение людей, которые работали с Ms sql и которые в частности хорошо понимают как работает timestamp. Особенно интересует вопрос озвученный в [1]

← →
TohaNik © (2014-11-13 16:52) [37]

Я особо не работал! Нельзя... Лень- timestamp,
Ну так и расскажи, или покритикуй, или наоборот чинавыворот?.
Репликации идеальной просто не бывает.

← →
Ellisium © (2014-11-13 19:09) [38]

> Ну так и расскажи

что рассказать? У меня у самого вопросы, я поэтому тему создал.

Просто тут столько понаписали, а явно видно, что люди даже минимально не знают, что такое timestamp в ms sql. А половина, видимо, даже и вопроса не прочитала.

Главным остается вопрос в [1]:

После выполнения запроса:

select @newTimeStamp=max(timestamp) from MyTable

Может ли в MyTable появиться запись, у которой timestamp будет меньше или равен @newTimeStamp?

← →
Inovet © (2014-11-13 19:27) [39]

> [38] Ellisium © (13.11.14 19:09)
> а явно видно, что люди даже минимально не знают, что такое timestamp в ms sql

Знают тут люди, а понаписали потому, что ты что-то неправильное хочешь сделать.

← →
TohaNik © (2014-11-13 19:31) [40]

> После выполнения запроса:select @newTimeStamp=max(timestamp)
> from MyTableМожет ли в MyTable появиться запись, у которой
> timestamp будет меньше или равен @newTimeStamp?

Может, он не для этого.
Блокировки нужны... ИМХО

← →
Inovet © (2014-11-13 19:38) [41]

> [27] Труп Васи Доброго © (13.11.14 13:53)
> Где грибочки брал и сколько стоят?

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

← →
Кщд © (2014-11-14 10:42) [42]

>TohaNik © (13.11.14 19:31) [40]
http://msdn.microsoft.com/ru-ru/library/ms152531.aspx
чем не устраивает?

← →
TohaNik © (2014-11-14 11:11) [43]

Да нормально, в 99, 99, а больше и не надо... Просто как по мне, пусть лучше приложение вылетит, чем разбирать: а откуда эта запись взялась. Это о ключах, суррогатных... и разных

← →
Ega23 © (2014-11-14 11:44) [44]

> Может ли в MyTable появиться запись, у которой timestamp
> будет меньше или равен @newTimeStamp?

может.

← →
Кщд © (2014-11-14 11:49) [45]

>Ellisium © (13.11.14 19:09) [38]
вы за два дня не способны прочитать документацию?
срываю покровы: http://msdn.microsoft.com/en-us/library/ms182776.aspx
но ключевое слово для вас: репликация
а не велосипед

← →
Ega23 © (2014-11-14 12:50) [46]

> срываю покровы

Да тоже непонятно. Вдруг у него данные в приёмнике тоже меняются как-то?

← →
junglecat © (2014-11-14 12:55) [47]

репликация слиянием?
http://technet.microsoft.com/en-us/library/ms151329(v=sql.105).aspx

← →
Кщд © (2014-11-14 13:07) [48]

>TohaNik © (14.11.14 11:11) [43]
вы пьяны?

← →
TohaNik © (2014-11-14 13:24) [49]

Угу, ищу старых знакомых...Ну сделайте номер,ФИО, или код там какой. еще чего то добавьте- ответит любовью

← →
Ellisium © (2014-11-15 20:05) [50]

> Может

> может.

можно пример алгоритма действий, когда после выполнения запроса:

select @newTimeStamp=max(timestamp) from MyTable

в таблице MyTable появится запись c timestamp равным или меньше @newTimeStamp?

← →
Кщд © (2014-11-15 22:18) [51]

>Ellisium © (15.11.14 20:05) [50]
нужно прочитать документацию
приведенных ссылок достаточно для ответа на ваш вопрос

← →
Ellisium © (2014-11-16 13:26) [52]

Ссылки я читал, ситуацию для меня они не прояснили - потому и спрашиваю

← →
Кщд © (2014-11-16 21:03) [53]

http://msdn.microsoft.com/en-us/library/ms182776.aspx
"Each database has a counter that is incremented for each insert or update operation that is performed on a table that contains a rowversion column within the database. This counter is the database rowversion. "

вы ТОЧНО читали документацию?

← →
Ellisium © (2014-11-17 09:26) [54]

>вы ТОЧНО читали документацию?

Да. Из цитаты я делаю вывод что ответ на мой вопрос - нет, не может. Но тут кругом люди пишут что может появится запись с timestamp меньше. Я не понимаю как такое может получиться

← →
Юрий Зотов © (2014-11-17 14:26) [55]

> Ellisium © (17.11.14 09:26) [54]
> Я не понимаю как такое может получиться

Навскидку, возможен такой сценарий.
1. Юзер1 делает select и получает new_Ts = max(поле)+добавка. 2. Юзер1 делает insert (или update) с new_Ts, но еще не коммитит. 3. Юзер2 делает тот же самый select и получает то же самое new_Ts. 4. Юзер1 коммитит. Появляется запись с new_Ts. 5. Юзер2 делает insert (или update) с new_Ts. 6. Юзер2 коммитит. Появляется вторая запись с new_Ts.
Но могу и ошибаться, БД - не моя стихия.

← →
Юрий Зотов © (2014-11-17 14:40) [56]

Вообще, полагаться на уникальное значение Timestamp вряд ли стоит - могут быть совпадения из-за слишком большой дискретности. Например, в документации по DB2 для IBM AS/400 прямо сказано, что так делать нельзя, а надо использовать функцию Create_Unique(Timestamp).

← →
Ellisium © (2014-11-17 17:33) [57]

Дядь Юр, спасибо за попытку помочь , но вы не читали что такое timestamp. Почитайте хотя бы что написано в [53]

← →
Юрий Зотов © (2014-11-17 18:45) [58]

> Ellisium © (17.11.14 17:33) [57]

До сих пор я полагал что timestamp - это тип данных.

← →
Ellisium © (2014-11-17 19:33) [59]

> До сих пор я полагал что timestamp - это тип данных.

это и есть тип данных. Но он не имеет отношения к времени (datetime) в MS SQL и трансляция его во время невозможна. Это скорее уникальный счетчик, уникальный в пределах инстанса БД за мелкими исключениями.

← →
Ellisium © (2014-11-17 19:39) [60]

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

Критика только в том, что поскольку timestamp глобальный идентификатор по сути, то max(timestamp) from MyTable - это может занять много ресурсов, а лучше использовать MIN_ACTIVE_ROWVERSION

← →
Ellisium © (2014-11-17 19:40) [61]

Заодно привет знатокам в виде TohaNik и Ega23

← →
Ellisium © (2014-11-17 19:44) [62]

В особенности, конечно, Ega23, который сначала дает ссылку на: http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.110%29.aspx

а потом говорит что-то про timestamp и часовые пояса UTC. Мог бы хоть минуту почитать собственную ссылку. Вот как так можно помогать :))

Всем спасибо.

← →
картман © (2014-11-17 19:49) [63]

> Ellisium © (17.11.14 19:44) [62]

> В особенности, конечно, Ega23, который сначала дает ссылку
> на: http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.
> 110%29.aspx
>
> а потом говорит что-то про timestamp и часовые пояса UTC.
> Мог бы хоть минуту почитать собственную ссылку.

ну да, а тебе, как автору, прочесть по той же ссылке не судьба была:
Тип данных rowversion является увеличивающимся числом и не основан на дате или времени.
пришлось
> поговорил я с шарящими людьми

← →
Кщд © (2014-11-17 20:24) [64]

>Ellisium © (17.11.14 19:44) [62]
вам шашечки или ехать?
если ехать, то в доке всё написано

← →
Ega23 © (2014-11-18 03:29) [65]

> В особенности, конечно, Ega23

Ega23 уже 300 лет с MSSQL дела не имел.

Но если судить по доке, то timestamp - суть deprecated type, должен использоваться rowversion. Судя по описанию rowvwrsion, он инкрементируется на каждый чих по изменению данных (и я там ещё не сильно вникал в транзакционность, типа, значение не откатывается).
Таким образом, ежели в таблице-приёмнике данные меняются, то rowversion однозначно расползётся с таблицей-источником. А значит, что надо на больше-равно сравнивать. А это, в свою очередь означает, что в некоторой перспективе все данные в таблице будут попадать под это условие, и что проще таблицу целиком скопипастить.
О чём кое-кому уже говорилось.

← →
Ega23 © (2014-11-18 08:49) [66]

Ух-ты. Прикольный у меня в полчетвёртого полёт фантазии.

← →
Ellisium © (2014-11-18 18:48) [67]

> Ega23 уже 300 лет с MSSQL дела не имел.

ну а зачем тогда так категорично в [44] утверждать:

> может.

← →
Кщд © (2014-11-18 18:51) [68]

>Ellisium © (18.11.14 18:48) [67]
пожалуйста, используйте штатные средства для репликации
пока-что вы даже доку не в силах осмыслить

> Судя по описанию rowvwrsion, он инкрементируется на каждый
> чих по изменению данных (и я там ещё не сильно вникал в
> транзакционность, типа, значение не откатывается).

Это просто другое имя, для соместимости со стандартами, можешь использовать и старое имя, ничего в данный момент не изменится.
Вот выписка из справки http://msdn.microsoft.com/ru-ru/library/ms182776.aspx

> Тип данных timestamp является синонимом типа данных rowversion
> и подчиняется правилам поведения синонимов типа данных.

И откатываться он не должен, для обеспечения целостности, как и первичный ключ

Остается маленький вопрос как с ним работать из Delphi.

Студия его представляет в виде: 0x000000000014B46F

Но как из дельфи составить запрос с этим timestamp...

> Но как из дельфи составить запрос с этим timestamp...

Тип binary(8) или varbinary(8)

> Тип binary(8) или varbinary(8)

и?

SomeQuery.ParamByName("TS").Value := $000000000014B46F;

> SomeQuery.ParamByName("TS").Value := $000000000014B46F;

Delphi вроде это представляет тогда как LongWord...

А если большое число - то как UInt64...

Наверное, тогда с ним так и надо работать, как с UInt64...

кстати, как с UInt64 - не получилось почему-то (((

Работаю как с Variant... Читаю в Variant, а потом в параметр пишу, как Variant - работает. Не разбирался.

Может немного не в тему, но есть заковырка с timestamp в mssql - он может округляться (или терять точность, не знаю).
Была значит колонка типа timestamp, в которой хранились только даты (тип date в mssql, по-моему, только в 2008 версии запилили), а время всегда в 0 было. Нужно было пофильтровать записи по какой-то дате. Был запрос типа

select * from table_t where date_p>=10.10.2012 00:00:00.000 and date_p<=10.10.2012 23:59:59.999

Так в выборку попадали записи за 11.10.2012, т.к. mssql представил 10.10.2012 23:59:59.999 как 11.10.2012 00:00:00.000. В чем он там у себя внутри даты хранит - может в double, не знаю, но факт остается фактом.
Пришлось переписать запрос на строго меньше начала следующего дня.

select * from table_t where date_p>=10.10.2012 00:00:00.000 and date_p<11.10.2012 00:00:00.000

> Пришлось переписать запрос на строго меньше начала следующего
> дня

и это правильный вариант.

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

>> [77] Омлет © (06.12.14 10:33)
>> date_p<11.10.2012 00:00:00.000
>Вроде как это первое и приходит на ум.

Приходит, да не всем )
Надо сказать запросы с <= или between успешно работали на Постгресе.

> Надо сказать запросы с <= или between успешно работали на
> Постгресе.

они везде правильно работают, если дату правильно указать

> они везде правильно работают, если дату правильно указать

а between, кстати, включает концы?

http://www.w3schools.com/sql/sql_between.asp

http://www.techonthenet.com/sql/between.php

Удалено модератором

Не специалист в MS SQL, но будет ли этот случай коректно обработан?

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; GO BEGIN TRANSACTION; GO INSERT(..); GO WAITFOR DELAY "02:00 ;" /* Тут запускается сериализация */ GO COMMIT TRANSACTION; /* Тут старые записи должны попасть в базу */ GO

казалось бы, причём здесь сериализация?))

и причем тут timestamp и between? )

мне, вот, тоже не ясно, зачем на форуме спрашивать, как работает between)

> [90] Кщд © (09.12.14 12:09)

ну, тут люди опытные собрались... мало ли у кого-то битвин не включал концы, или включал, но только один

> казалось бы, причём здесь сериализация?))

Синхронизация, очепятка

> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Mystic, ты гений! Спасибо )

Вот именно в этом режиме и надо делать САМУ синхронизацию, чтобы она зависала на каждый чих, дожидаясь, сделают commit или rollback для данных. Чуть подправил проект.

А вот "сломать" синхронизацию можно например на уровне SNAPSHOT. Данные прочтутся "старые" из снимка, а потом после commit "станут" новыми, но в новую синхронизацию уже не попадут.

Кстати, есть способ сделать данные не подпадающие под синхронизацию. С помощью DDL операций, например вставка нового столбца с Default значением. Это не меняет ни timestamp записей, ни приводит к срабатыванию триггеров.

автор похоже так и не сподобится справку открыть

Удалено модератором

MS SQL синхронизация / Timestamp Найти похожие ветки