Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 service broker транзакционные и справочные данные  [new]
Andrew Dragon
Guest
Имеется таблица транзакций и 2 справочные таблицы. SQL Server 2005
Для каждой из таблиц добавлена service broker очередь. Для транзакций - MAX_QUEUER_READERS = 4, для справочников по 2.
Для обновления данных справочников каждый раз открывается новый диалог.
Для транзакций есть подобие пула диалогов (по spid).
Иногда получается, что транзакционные данные добавляются раньше справочных и в результате получаю FK violation.

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

Спасибо.
29 май 13, 23:11    [14367343]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
При обработке транзакционных данных ждите, пока не появятся справочные. Например.
29 май 13, 23:47    [14367462]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andrew Dragon
Иногда получается, что транзакционные данные добавляются раньше справочных и в результате получаю FK violation.
Не надо лечить симптомы, надо лечить болезнь.

Где-то же оно разделяется на два потока. А зачем? Что бы решать эту надуманную проблему?
Нет?
30 май 13, 09:24    [14368111]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Mnior
Где-то же оно разделяется на два потока. А зачем? Что бы решать эту надуманную проблему?
Нет?


Классическая задача - перенос данных из транзакционной системы в отчетную.
Средство переноса данных - service broker.
В транзакционной системе добовляются и справочники и данные о самих транзакциях.
Т.е чтобы это ни было добавление новой транзакции или добавление/редактирование справочников, в соотв. очереди кладутся
сообщения.
Система еще только разрабатывается.
И вот процессе тестирования выявдено, что иногда транзакции обрабатываются раньше справочников.


Гавриленко Сергей Алексеевич
При обработке транзакционных данных ждите, пока не появятся справочные. Например.


Вы имеете ввиду валидировать транзакцию и если чего-то не хватает вернуть ее в очередь ?
30 май 13, 10:48    [14368541]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
mike909
Member

Откуда:
Сообщений: 662
Andy Dragon
Гавриленко Сергей Алексеевич
При обработке транзакционных данных ждите, пока не появятся справочные. Например.


Вы имеете ввиду валидировать транзакцию и если чего-то не хватает вернуть ее в очередь ?

Ну если у Вас цель - загасить систему, то можно и вернуть в очередь через rollback
Ждать в SB Reader_е - черевато серьезными задержками обработки (особенно когда кол-во Reader_ов закончится на ожидании)
Наиболее быстрый вариант (не факт что наиболее правильный), это:
1) Перекинуть сообщение в "локальную" очередь без SB_Reader_а, открыв новый диалог с conversation_group_id = входящему диалогу
2) Повесить тамер на входящий диалог
3) По срабатыванию - считать из "локальной" очереди по conversation_group_id.
4) Если опять облом, то перейти к п.п. 1

PS. Наиболее правильный вариант предложил Mnior
Mnior
Не надо лечить симптомы, надо лечить болезнь
30 май 13, 11:37    [14368924]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
Т.е чтобы это ни было добавление новой транзакции или добавление/редактирование справочников, в соотв. очереди кладутся сообщения. Система еще только разрабатывается.
И вот процессе тестирования выявдено, что иногда транзакции обрабатываются раньше справочников.
Это очевидно было, что оно так сложилось.
Как обычно, сначала делаем, а потом думаем почему не вышло.

Andy Dragon
Классическая задача - перенос данных из транзакционной системы в отчетную.
Какая нифиг классика.
Классика в том что никогда не трогать фантомные данные. Все данные должны быть связаны - всягда.
Любая операция в системе или юзает уже гарантированные данные (логически связанные), или данные связаны в пачку (физически).

PS: Чё за день - одни вопросы по физику бытия. Базовые знания.
31 май 13, 01:55    [14373221]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Связь товара (справочных данных) с транзакцией это Ассоциация.
Не агрегация и не композиция.
Товары существуют вне зависимости от того, заказывали их или нет.
Все тут с точки зрения "физики" правильно.
Это не заказ и его линия, где линия живет столько, сколько и сам заказ.
Нету тут никаких фантомов.
Справочники первичны.

А проблема тут чисто техническая - не всегда успевают товары заполнится к моменту добавления заказов и все.
31 май 13, 10:08    [14373918]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
Связь товара (справочных данных) с транзакцией это Ассоциация.
Не агрегация и не композиция.
FP.JPG О боже. Много синонимичной байды не по делу.
Andy Dragon
Товары существуют вне зависимости от того, заказывали их или нет.
Бредятина. Заказать невозможно того чего ещё нет. А того что ещё до COMMIT ещё не существует.

Andy Dragon
А проблема тут чисто техническая - не всегда успевают товары заполнится к моменту добавления заказов и все.
Вы так говорите словно есть логика и некие "технические" проблемы, которые совсем никак не связаны, менее чем тёплое и яблоки. А может всё-таки они решают конкретную логику (и ничего более)?

Вы всегда когда ездите на машине из точки А в Б, то каждая часть машины "едет"/доставляется по разным дорогам раздельно?!
Когда вы читаете книгу вы всегда разрываете её на листы и перемешиваете?

Каков логический и технический смысл "разобрать" и "собрать"? Какую он несёт логическую функцию в бизнес задаче?
Ну кроме как всё запутать и повысить требование к производительности в 10 раз.

И ещё. Объясните, как список типов товаров (мы же не про наличие говорим) попадают к заказчику до их появления в системе?
4 июн 13, 10:29    [14387598]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Бредятина. Заказать невозможно того чего ещё нет. А того что ещё до COMMIT ещё не существует.


Товары, например "Шоколад Аленка 100г." существуют вне зависимости от того заказывал их или нет.
Этот товар будет в тысячах разных заказов. Связь товара с заказом - ассоциация.

Добавление/редактирование товаров и добавление заказов - это абсолютно разные транзакции разделенные во времени .


Вы всегда когда ездите на машине из точки А в Б, то каждая часть машины "едет"/доставляется по разным дорогам раздельно?!
Когда вы читаете книгу вы всегда разрываете её на листы и перемешиваете?


Товар, это не часть заказа. Нечего путать композицию с ассоциацией.

Есть конструктивные предложения ?
Даже если я их в одну очередь направлю, нету абсолютной гарантии, что новые товары обработаются раньше.
Только диалог это гарантирует.
10 июн 13, 08:31    [14412896]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
invm
Member

Откуда: Москва
Сообщений: 9406
Andy Dragon
Есть конструктивные предложения ?
Уберите FK на принимающей стороне. Или воспользуйтесь штатной репликацией.
10 июн 13, 08:36    [14412914]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
Товары, например "Шоколад Аленка 100г." существуют вне зависимости от того заказывал их или нет.
Пока их не закомитили в базе, их не существует. И никто не знает что вообще есть такого рода товар. Его нет в списках, ибо эти списки не могут читать будущее (что вы через 3 дня сделаете INSERT).
Andy Dragon
Добавление/редактирование товаров и добавление заказов - это абсолютно разные транзакции разделенные во времени.
Естественно разные, но связанные. Транзакция о заказе товара, не может начаться раньше чем закомитится появление этого типа товара.

Или я у вас уже могу заказать Delorian машину времени? А скажите, а сколько видов товаров есть за всю историю вашей фирмы? И назовите точную дату когда же она закроется?
Mnior
И ещё. Объясните, как список типов товаров (мы же не про наличие говорим) попадают к заказчику до их появления в системе?
Andrew Dragon, Где ответ?
10 июн 13, 16:01    [14416063]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Mnior
И ещё. Объясните, как список типов товаров (мы же не про наличие говорим) попадают к заказчику до их появления в системе?

Есть 2 интрфейса (формы) : для добавления товаров и для добавления заказов.

Еще раз : система только разрабатывается.
И в процессе тестирования : добавляются новые товары и заказы одновременно
Заказ содержат N случайных товаров.
Я получал несколько раз (редко, но получал) FK violation на новых товарах.

И возможным решение было бы эмулировть автономную транзакцию внутри активационной процедуры для очереди заказов и
добавлять в ней новые товары с пустыми св-вами.
А в активационной процедуре добавления/обновления товаров дополнять пустые св-ва.

invm
Или воспользуйтесь штатной репликацией.

Я не специалист в репликации, но наверное из-за того что структура немного разная репликация невозможна ?
10 июн 13, 18:33    [14417148]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
invm
Member

Откуда: Москва
Сообщений: 9406
Andy Dragon,

Зависит от того, в чем именно различия. Если их покажете, то можно будет ответить конкретнее.
10 июн 13, 19:00    [14417251]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
капитан очевидностЪ
Guest
Andy Dragon,

"...Я не специалист в репликации..."

поправил
10 июн 13, 19:14    [14417307]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
Есть 2 интрфейса (формы) : для добавления товаров и для добавления заказов.

Еще раз : система только разрабатывается.
И в процессе тестирования : добавляются новые товары и заказы одновременно
Заказ содержат N случайных товаров.
Вы уходите от ответа.
Как в заказе появляются ID новых товаров, которых ещё нет в базе?

Andy Dragon
Есть 2 интрфейса (формы)
добавляются новые товары и заказы одновременно
Правильно.
1. Имеем 10 товаров.
2. Открываем 2 формы сразу.
2.1. В форме заказ видим только 10 товаров, выбираем из них
2.2. В форме товар описываем новый 11й товар.

Вопрос, как можно в форме заказа увидеть этот новый товар, если список товаров его ещё не содержит? (ещё не отослан на сервер)

Andy Dragon
Я получал несколько раз (редко, но получал) FK violation на новых товарах.
Кхм. Из этого вы сделали выше описанный вывод?
На товарах или на заказах? Вы определитесь.
10 июн 13, 21:11    [14417587]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Mnior
На товарах или на заказах? Вы определитесь.


Как у товара может быть fk на заказ ?
Конечно у заказа на товар.


Mnior
Как в заказе появляются ID новых товаров, которых ещё нет в базе?

Генерируется, обычный identity столбец.

Mnior
Правильно.
1. Имеем 10 товаров.
2. Открываем 2 формы сразу.
2.1. В форме заказ видим только 10 товаров, выбираем из них
2.2. В форме товар описываем новый 11й товар.


Неправильно, 11 товар сохраняется, потом открывается форма заказа и он добавляется как линия заказа.
Сколько еще раз повторить? , что ввиду распределенности системы заказ, который содержит 11 товар обрабатывается
раньше чем сами данные о 11ом товаре.
10 июн 13, 21:42    [14417665]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
11 товар сохраняется, и лишь после того как он сохранён в базе открывается форма заказа и он добавляется как линия заказа.
Ну так откуда может быть тогда мисс FK?
Andy Dragon
заказ, который содержит 11 товар обрабатывается
раньше чем сами данные о 11ом товаре.
Это как? Вы же строкой выше написали что товар появляется в списке только после сохранения.

Andy Dragon
что ввиду распределенности системы
Какой ещё распределённости? Вы о чём? Где вы это упомянули?
Где вы описали архитектуру?

Если вы о том что вы синхроните 2 сервера. Тогда тут формочки и параллелизмы ваще не причём. Или вы запутать хотите?
Так вот, при синхронизации данных последовательность синхронизации обязательна. Или вы думаете всякие RowVersion (TimeStamp) и другую лабуду придумали идиёты, просто так, паржать?
Данные в системе имеют естественный порядок, потому нельзя просто глупо рассматривать и обрабатывать их независимо.

Или у вас данные приходят из разных систем? Справочники из одной, данные сохраняются в другой?
Ну тогда нескромный вопрос: А зачем так?

--
Ой люблю такие вещи перечитывать:
Нечего путать композицию с ассоциацией.
Доставляэ.
11 июн 13, 00:03    [14418133]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Andy Dragon
Member

Откуда:
Сообщений: 7
Классическая задача - перенос данных из транзакционной системы в отчетную.
Средство переноса данных - service broker.
В транзакционной системе добовляются и справочники и данные о самих транзакциях.
Т.е чтобы это ни было добавление новой транзакции или добавление/редактирование справочников, в соотв. очереди кладутся
сообщения.


RowVersion (TimeStamp) придумали для того чтобы более старыми изменениями объекта новую версию не затереть.
Но! одного и того же объекта : будь то справочные данные (продукты) или транзакции (заказы в моем случае).

Суть моего теста :
2 разных физических сервера и по базе на каждом.
Каждую минуту создается по одному новому товару (отдельная транзакция)
2 потока с интрвалом в 15 секунд редактируют по одному случайному продукту.
8 потоков в бесконечном цикле постоянно создают новые заказы с числом случайных продуктов от 5 до 15.

И вот периодически в отчетной базе случаются fk violation.


Mnior
Ой люблю такие вещи перечитывать:

И в чем тут конкретно логическая ошибка ?

И что по вашему есть "естественный порядок" ?
11 июн 13, 00:25    [14418176]     Ответить | Цитировать Сообщить модератору
 Re: service broker транзакционные и справочные данные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Andy Dragon
RowVersion (TimeStamp) придумали для того чтобы более старыми изменениями объекта новую версию не затереть.
Какие обрубчатые однобокие познания.
А почему тогда тупо не увеличивать некий счётчик для каждой строки. Почему RowVersion уникален в рамках всей базы?
Да с таким восприятием мира жди бяды на кажом углу. Что и происходит.
Andy Dragon
Mnior
Ой люблю такие вещи перечитывать:
И в чем тут конкретно логическая ошибка?
Доставляэ всё и к чему было сказано и как. Это шедеврально.
Я тут бессилен что либо объяснить. Мне даже страшновато.
Ладно, давайте "по делу".
Andy Dragon
Суть моего теста :
2 разных физических сервера и по базе на каждом.
Пол бита инфы.
Andy Dragon
Каждую минуту создается по одному новому товару (отдельная транзакция)
2 потока с интрвалом в 15 секунд редактируют по одному случайному продукту.
8 потоков в бесконечном цикле постоянно создают новые заказы с числом случайных продуктов от 5 до 15.
Нуль инфы.
Такими темпами новый год пора праздновать.

Опишите когда и как и почему что либо происходит. Откуда берутся данные для заказов.
Вы должны чётко объяснить, откуда в форме появлятся товар, которого нет в базе.
Опишите как связаны клиенты и сервера (топология), нет ли такого что клиент смотрит на 2 сервера.
Проблема в заведении заказа или в синхронизации баз?

Да я столько вопросов до этого задавал, а вы всё игнорите и игнорите.

Скорее всего в заведении заказа и сохранении данных нет проблем. Проблема в синхронизации.
Кто-то синхронизирует данные минуя их естественную и физическую зависимость.

В идеале синхронизируется потоком по ходу RowVersion (ближе к логу базы). В целом может быть накладно. Тогда можно схалтурить:
Так как данные как правило имеют однонаправленную зависимость (граф без циклов), то можно синхронить блоками.
Т.е. "нарушать" порядок в одну сторону и не нарушать порядок в другую.
Т.е. можно брать пачку изменений справочника (типы товаров), по максимуму, затем брать уже данные (заказы), но не больше чем максимальный RowVersion справочника. И так итеративно до опупения.
Данные надо брать аккуратно, чтобы не забрать ничего лишнего (изменяемого на момент генерации пачки).
При использовании подхода RowVersion надо чётко понимать - DELETE запрещён, флагами разруливать.

Блин, такую банальщину пишу. Дет сад.
11 июн 13, 05:27    [14418359]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить