Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Есть такая проблема у нас. Долгое время писался ETL, завязанный на rowversion. А именно, если надо инкрементально выгрузить данные, то брался последний уже загруженный rowversion и по нему выгружались записи имеющие больший по величине rowversion. В какой-то момент обнаружилась проблема: есть пропуски в записях. И связано это, судя по всему, с тем, что данные выгружаются с реплики, а нее из фактической первой БД. Скажу сразу, что исходная БД очень высок нагружена и нами не контролируется. Дали реплику нам и сказали выгружать с неё. Так вот rowversion-ы приходят на реплику не всегда в той последовательности, в какой они возникли в исходной. Как я понимаю, это связано с транзакциями. Одна транзакция создала запись и но ещё не закоммитила её, а другая транзакция создала запись позже, но уже закоммитила ей. Теперь вопрос. Мы взяли в таблицы X последний @MAX_RV = MAX(rowversion). Существует ли способ убедиться в том, что все записи с rowversion <= @MAX_RV поступили на реплику? Или существует ли способ взять rowversion, до которого все записи уже точно поступили на реплику? |
15 сен 15, 16:35 [18152184] Ответить | Цитировать Сообщить модератору |
Konst_One Member Откуда: Сообщений: 11568 |
а с чего вы решили , что rowversion вам поможет пропуски избежать? https://msdn.microsoft.com/ru-ru/library/ms182776(v=sql.120).aspx |
15 сен 15, 16:41 [18152227] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Так решили те, кто начинал писать ETL. В том, что теперь с этим можно сделать? |
||
15 сен 15, 16:45 [18152252] Ответить | Цитировать Сообщить модератору |
Konst_One Member Откуда: Сообщений: 11568 |
видимо нужен столбец с временем обновления конкретной записи в таблице |
15 сен 15, 16:48 [18152273] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Вот эта штука поможет? https://msdn.microsoft.com/en-us/library/bb839514.aspx |
15 сен 15, 16:58 [18152328] Ответить | Цитировать Сообщить модератору |
Konst_One Member Откуда: Сообщений: 11568 |
похоже , что поможет. сам не использовал такие техники. так что , проверяйте |
||
15 сен 15, 17:03 [18152367] Ответить | Цитировать Сообщить модератору |
-=Гость=-
Guest |
a_voronin, У вас на реплику приходит rowversion с Паблишера - или локальный ? если с Паблишера - рассмотрите вариант локального rowversion (табличка рассширется на одно поле) У вас транзакционная репликация ? |
15 сен 15, 17:06 [18152383] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Это AwaysOn SQL 2012 -- честно говоря, в подробности того как это настроена не вникал, потому что источник это не моя система. |
||
15 сен 15, 17:22 [18152454] Ответить | Цитировать Сообщить модератору |
-=Гость=-
Guest |
a_voronin, Ясно, тогда всё верно - такая проблема была с timestamp помоему у вас rowversion приходит с мастер базы и не имееет отношения к локальной @@DBTS |
15 сен 15, 17:41 [18152530] Ответить | Цитировать Сообщить модератору |
-=Гость=-
Guest |
-=Гость=-, Мне кажется здесь примерно ваша проблема описана http://blogs.msdn.com/b/ialonso/archive/2015/05/08/how-is-dbts-expected-to-behave-on-an-always-on-availability-group-secondary-replica-a-database-mirroring-mirror-or-a-database-which-is-being-created-out-of-a-restored-backup-and-is-in-standby-or-in-recovery-state.aspx К сожалению опыта с AlwaysOn репликой нет. Подсказать не смогу. |
15 сен 15, 17:49 [18152577] Ответить | Цитировать Сообщить модератору |
Между сообщениями интервал более 1 года. |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Если какая то запись с rowversion < min_active_rowversion(), будет доставлена уже после того, как вы выгрузили записи rowversion < min_active_rowversion(), то вы её уже не выгрузите. |
||||||||
23 янв 20, 09:16 [22064953] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
Да, гарантия (в рамках sql server без багов) есть. |
||||
23 янв 20, 09:16 [22064954] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
a_voronin,
да, главеное что бы источник не был репликой :) |
||
23 янв 20, 10:18 [22064995] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
А вот это проблема -- источник реплика и вопрос как раз про min_active_rowversion() на реплике. Но насколько мой опыт говорит, записи не пропускаются. |
||||||
23 янв 20, 11:22 [22065067] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
на реплике не тот min_active_rowversion хотя тут скорее вопрос какая реплика Сообщение было отредактировано: 23 янв 20, 11:24 |
||||||||
23 янв 20, 11:24 [22065071] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
ALWAYSON |
||||||||
23 янв 20, 12:15 [22065122] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
там не те дроиды. на secondary @@DBTS и min_row_active можно использовать только например сохраняя в таблицу на primary и опираясь на эти значения на secondary. "Подряд" rowversion не будут понятное дело |
||||||||
23 янв 20, 12:21 [22065135] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
что в общем странно в вашем вапросе, если вы сами это уже упоминали :) 18929494 |
23 янв 20, 12:36 [22065159] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Я вернулся к этой теме. Есть несколько мест, где говорят, что "нет не герантирует", но кто проводил тесты? И на практике мы читали с реплике и пропусков как ни странно не было. |
||||
23 янв 20, 12:41 [22065164] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
у нас тоже долго не было :) Это же вопрос стечения нескольких факторов во времени |
||||||||
23 янв 20, 12:44 [22065169] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
Хмм, провел натурный эксперемент (синхронная реплика), и да проблемы с пропусками могут быть. |
||||||||
23 янв 20, 12:48 [22065174] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Каких? |
||||||||
23 янв 20, 12:58 [22065191] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
как-то так Старт транзакции 1 получение stamp 1 Старт транзакции 2 получение stamp 2 COMMIT 2 в синхроной она уж уезжает, в асинхронной как пойдёт в сей момент вы отгребаете все что было с полследней синхронизации и столбите стемп 2 что бы с него начать COMMIT 1 тут уже при отборе стемп 1 не доступен |
||||||||
23 янв 20, 13:03 [22065202] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
описываю последовательность шагов 1. создаем таблицу в базе create table dbo.test(id rowversion not null, f int not null) 2. в первом коннекте выполняем begin tran insert dbo.test(f) select 1 коннект не закрываем 3. во втором коннекте выполняем begin tran insert dbo.test(f) select 2 commit 4. на реплики читаем все, что меньше "активных rowversion" (нужно дождаться передачи данных) select * from dbo.test where id < min_active_rowversion() и видим запись с f = 2 и запоминаем его id 5. в коннете из пункта 2 (там где вставка f=1) делаем commit и дожидаемся появления этой записи на реплике. убеждаемся, что id у нее меньше, чем у записи с f=2, а значит на шаге 4 мы пропустили f=1 |
||||||||
23 янв 20, 13:06 [22065208] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |