Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
https://connect.microsoft.com/SQLServer/feedback/details/744433/partitioned-view-instead-of-trigger-data-not-locked

прикол ситуации в том, что при наличии instead of триггера на update / delete вы теряете контроль над данными - так как в этом случае и если в представлении более 1 секции стейтменты запускаются одновременно и "не ждут" (что делают для той же модели, если в ней всего 1 таблица в представлении) "перед входом в триггер"
а раз так - запросто сделать пример с "одновременным" удалением + изменением, когда прикладная система сначала дала команду изменить и "чуть после" - команду удалить, но так, что удаление не имеет смысла по результатам обновления. и при работе по 1 таблице все будет замечательно. сначала ожидание, после - выполнение. но вот при работе по куче секций у вас "одновременно" (!) выполнятся обе операции, оба экземпляра триггера на вход получат одинаковые (!) данные в DELETED и оба отработают (!). а средств убедиться в том, что у вас в DELETED именно те данные, которые были на входе в statement - нет ибо единственный способ это контролировать - timestamp - запрещед для partitionde view. отакот.
28 май 12, 12:37    [12625122]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
1. instead of триггера на update / delete
2. в представлении более 1 секции
3. "одновременным" удалением + изменением: когда прикладная система
- сначала дала команду изменить и
- "чуть после" - команду удалить
4. удаление не имеет смысла по результатам обновления
Баг: "одновременно" (!) выполнятся обе операции, оба экземпляра триггера на вход получат одинаковые (!) данные в DELETED и оба отработают (!).

при работе по 1 таблице все будет замечательно. сначала ожидание, после - выполнение.

+ скрипт
-- drop table dbo.a1
create table a1 ( id int , flag int , primary key ( id ) , check( id < 10 ) )
go
-- drop table dbo.a2
create table a2 ( id int , flag int , primary key ( id ) , check( id > 10 ) )
go
insert into dbo.v1 ( id , flag ) select 1, 1
insert into dbo.v1 ( id , flag ) select 2, 2
insert into dbo.v1 ( id , flag ) select 3, 3
go
insert into dbo.v1 ( id , flag ) select 11, 11
insert into dbo.v1 ( id , flag ) select 12, 12
insert into dbo.v1 ( id , flag ) select 13, 13
go
-- drop view dbo.v1
create view dbo.v1 as select * from dbo.a1 union all select * from dbo.a2
-- create view dbo.v1 as select * from dbo.a1
go

-- drop trigger dbo.tv1 
create trigger dbo.tv1
on dbo.v1 instead of update 
as
set nocount on
exec sp_lock @@spid
return
go
update dbo.v1 set flag = flag where id = 2
update dbo.v1 with (updlock) set flag = flag where id = 2
go
28 май 12, 13:28    [12625480]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Вы не протестировали пример, когда отправляли в M$. Там очепятки. Поправьте.
28 май 12, 13:30    [12625486]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Скрипт вообще ничего явно не показвает.

Вы это знаете?
28 май 12, 13:33    [12625501]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Разница блокировок c одной таблой или несколькими:
resource_typeresource_descriptionresource_associated_entity_idresource_lock_partitionrequest_moderequest_status
OBJECT1934629935 (view)14IXGRANT
resource_typeresource_descriptionresource_associated_entity_idresource_lock_partitionrequest_moderequest_status
OBJECT1934629935 (view)14IXGRANT
OBJECT1646628909 (table)14IXGRANT
PAGE1:24552602043729615912960IUGRANT
KEY(020068e8b274)526020437296159129614UGRANT
Когда с одной (не важно JOIN или UNION), то у M$ другая стратегия, она как-бэ напрямую с ней работает.
Надо найти в доке.
28 май 12, 13:55    [12625640]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Т.е. лучше бы сюда изначально сеинули проблемы для обсуждения.
Можете отозвать запрос, в таком виде он не тянет, нужно решить:
1. Ести ли реально в доке описанное
2. Это поведение не устраивает большинство или обратное хуже
3. Что предложить M$ явно.
28 май 12, 14:00    [12625676]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
разница при обновлении представления с хинтом UPDLOCK или без него

spid   dbid   ObjId       IndId  Type Resource                         Mode     Status 
------ ------ ----------- ------ ---- -------------------------------- -------- ------ 
    55      8           0      0 DB                                    S        GRANT
    55      8  1573580644      0 TAB                                   IX       GRANT
    55      1  1131151075      0 TAB                                   IS       GRANT

(3 row(s) affected)

spid   dbid   ObjId       IndId  Type Resource                         Mode     Status 
------ ------ ----------- ------ ---- -------------------------------- -------- ------ 
    55      8           0      0 DB                                    S        GRANT
    55      8  1573580644      0 TAB                                   IX       GRANT
    55      1  1131151075      0 TAB                                   IS       GRANT

    55      8  1205579333      0 TAB                                   IX       GRANT
    55      8  1125579048      0 TAB                                   IX       GRANT

    55      8  1125579048      1 PAG  1:114                            IU       GRANT
    55      8  1125579048      1 KEY  (61a06abd401c)                   U        GRANT

(7 row(s) affected)


проблема - в последних 2 строках, которые есть, если в представлении 1 таблица и есть, если указан любой хинт для запроса
28 май 12, 17:56    [12627639]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mnior
Скрипт вообще ничего явно не показвает.

Вы это знаете?


все он показывает. ссылка - "ниочем" в контексте обсуждаемой проблемы
28 май 12, 17:59    [12627667]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Лять, что значит ни о чём.
Никогда небыло такого что INSTREAD локировал таблицы для обновления. Он делает селелект и передаёт Inserted/Deleted в триггер и всё. Как делать селект решается уровнем изоляции (по умочанию или заднным).
Разве что для одной таблы он явно локирует, только нигде эта фича не оговорена (скорее всего).

UpdLock-ом вы просто подняли изоляцию чтения. Всё как обычно.
12625640 - с двумя и одной таблой (без UpdLock)
28 май 12, 18:42    [12627924]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mnior
Разве что для одной таблы он явно локирует, только нигде эта фича не оговорена (скорее всего).


отош! а как бизнес-логику делать, если даже когда в триггере первой строкой идет к примеру select from mytable with (xlock) и на этот момент (уже!) данные в таблице не соответствуют (!) ни deleted ни inserted, а timestamp поля у нас запрещены для партишенед вью? везде писать with ()? и не забывать?
28 май 12, 19:20    [12628056]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
везде писать with ()?
А чем это вы, Crimean, такой особенный, кожа более белая?! ;) Все пишут и вы пишите.
Crimean
и не забывать?
Ну дык, смотря где. Для внешней своей системы просто прописывает в DB классе эту особенность (для вьюх по умолчанию) и всё.

Вот я и предлагаю, может стоит обсудить и накатить бочку на M$:
Капитан, большинство с вами не согласны, вот чёрная метка. Тысяча чертей! Или ставьте опцию (флаг) для сервера или меняйте по нормальному поведение по умолчанию.

Но на самом деле всё намного хуже. У вас там проблем никаких, а кодась система "кривая" и дофига таблиц JOIN-ятся (справочники не дай бог) то всё, хамба - пол системы в U локировках.
А я и предлагал ранее (10286971), чтоб декларативности добавить. (не могу найти все посты)
Но посмотришь в Microsoft Research и плакать хочется. Джими, ну на кого ты нас оставил.
28 май 12, 21:05    [12628490]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
с таким поведением получается, что триггера на партишенед вью (кроме insert, разумеется) - вообще отдельная статья разработки
так как "по умолчанию" сейчас блокировки "до того" не накладываются (в отличие от работы по 1 таблице, пусть и через представление) - в триггерах на update / delete мы становимся перед фактом полного развала бизнес-логики. поясню
к примеру, пусть у нас есть 2 конкурирующих процесса, они оба "взяли" одну запись. пусть запись была "никакая". один процесс решил ее "оживить" (1), второй - "удалить" (2). собственно "оживляльщик" свое дело сделал, но технически его транзакция пролетела между (!) началом выполнения стейтмента "удаляльщика" и, грубо говоря, первой строкой триггера "удаляльщика"
теперь, со стороны, с бизнесовой точки зрения "удаляльщик" сделал что-то типа

delete from mytable where ( условия для удаления == выполняются ) - и это всегда для прикладушников было законно

в триггер "удаляльщику" в deleted легло, безусловно, то, что удовлетворяло егойному запрошенному условию. а вот в реальных данных-то уже "оживленная" запись, которую теперь удялять нет никакого смысла. но если триггер работает тупо по deleted / inserted - мы таки эту запись удалим, так как в deleted у нас "все в поряде". упс
с третьей стороны "удаление" может быть более сложным процессом, чем кажется и "просто" в триггере проверить та ли эта запись, которую смотрел "удаляльщик" - нереально, так как timestamp - единственное, что бы помогло - нам недоступен для таких конструкций. а лочить данные в триггере - уже поздно, так как - читаем выше - другая транзакция все равно успеет "пролететь"
29 май 12, 11:00    [12630145]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
aleonov
Member

Откуда:
Сообщений: 96
Crimean,

Если у вас есть реальный (работающий) пример потверждающий вашу теорию, запостите в топик п-ста. Тот что обсуждается в данной теме имеет два изъяна: 1. несущественный, дизайнерский - использование instead of trigger для обновления updateable view .
2. серьезный - вызов процедуры из триггера, хорошая иллюстрация на тему - "Почему не следует вызывать процедуры из триггеров".

Протестируйте свой пример в SQL profile без вызова процедуры sp_lock в триггере и увидите, что разницы в блокировках на update с хинтом или без нет.
29 май 12, 17:20    [12633332]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
2 тов aleonov,

а вы сами-то работали с updateable partitioned views?
(вопрос насчет триггера подсказывает что нет - ошибаюсь?)
опять же, каким боком здесь упомянутые в вашем посте "хранимки из триггера"? или вам больше по душе вычитки из dmv? так пробуйте, уверяю, результат будет ровно тем же
p.s.
с примером-то проблем никаких, но как мне кажется проблема более чем очевидна
29 май 12, 17:44    [12633454]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
aleonov
Member

Откуда:
Сообщений: 96
Crimean
2 тов aleonov,

а вы сами-то работали с updateable partitioned views?
(вопрос насчет триггера подсказывает что нет - ошибаюсь?)
опять же, каким боком здесь упомянутые в вашем посте "хранимки из триггера"? или вам больше по душе вычитки из dmv? так пробуйте, уверяю, результат будет ровно тем же
p.s.
с примером-то проблем никаких, но как мне кажется проблема более чем очевидна



да не только работал, но и работаю, и не только с updateable partitioned view, но и с distributed updateable partitioned views, а что ?
а чем вычитки из dmv, лучше ? некрасиво из транзакции обращаться к системным таблицам, вот в чем проблема. Если для вас все очевидно и не хотите посмотреть на результаты профайлера, то мне больше нечего добавить к уже сказанному.
29 май 12, 17:54    [12633507]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
aleonov,

хорошо. модельку (таблички + представление) оставляем ту же. к триггеру:

drop trigger dbo.tv1 
go

create trigger dbo.tv1
on dbo.v1 instead of update 
as
set nocount on

update	v
set	v.Flag		= i.Flag
from	dbo.v1		v

join	inserted	i
	on	i.Id		= v.Id

return
go


вопросов нет? или модифицировать сразу, до начала "примеров"?

p.s.

поскольку вопрос (а особенно обсуждение интимных подробностей) может быть не особо интересен "широкой общественности" - у меня icq в профиле, может для оперативности "в приват"?
29 май 12, 18:21    [12633628]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
aleonov
Member

Откуда:
Сообщений: 96
Crimean
aleonov,

хорошо. модельку (таблички + представление) оставляем ту же. к триггеру:

drop trigger dbo.tv1 
go

create trigger dbo.tv1
on dbo.v1 instead of update 
as
set nocount on

update	v
set	v.Flag		= i.Flag
from	dbo.v1		v

join	inserted	i
	on	i.Id		= v.Id

return
go


вопросов нет? или модифицировать сразу, до начала "примеров"?

p.s.

поскольку вопрос (а особенно обсуждение интимных подробностей) может быть не особо интересен "широкой общественности" - у меня icq в профиле, может для оперативности "в приват"?


я понял в чем у вас проблема :-) хорошо обсудим в личке.
29 май 12, 18:26    [12633662]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
поясню
Мусолите одно и тоже по нескольку раз.
Так было всегда. Да, неудобно.

То что кто-то в триггерах на View "доверяет" данным из Inserted / Deleted - то это их проблемы (если конечно не указано жёстко что вызывается всегда через UpdLock).

Да, ваши разработчики ошиблись по незнанию. Как "выкрутится" вы сами написали.
В чём дальнейший вопрос непонятно. Что вы предлагаете?
29 май 12, 19:22    [12633920]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mnior,

неинтересно - игнорь тему, делов-то
30 май 12, 00:41    [12634779]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
неинтересно - игнорь тему
Тема-то как раз интересна, вот только никто не высказывается.
30 май 12, 09:24    [12635231]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
RubinDm
Member

Откуда:
Сообщений: 461
Mnior, я приблизительно, не в деталях понимаю, о чем тут. понятно, что могут быть весьма специфические сценарии, при исполнении которых могут появляться спец-эффекты, могущие показаться "чудом" (кошмаром) для тех, кто не особенно разбирается в тонкостях реализации сервера. Вы можете дать какие-то конкретные рекомендации о том, что и как НЕ надо делать, чтобы не приходилось вникать в такое "чудо"?
30 май 12, 12:50    [12636661]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
RubinDm
кто не особенно разбирается в тонкостях реализации сервера.
Ну, есть две вещи:
1. Проблемы понимания/использования со стороны программистов (пользователей, нас с вами)
2. Проблемы среды/продукта (разработчиков M$)

Первый пункт относительно быстро и легко устраняется/выясняется, большая часть постов на форуме.
А вот второй очень вяло. А это необходимая вещь. Общение специалистов в любой области поддерживает и развивает её. Само за нас если и решается, то не факт что правильно и очень медленно.

КО

RubinDm
Вы можете дать какие-то конкретные рекомендации о том, что и как НЕ надо делать, чтобы не приходилось вникать в такое "чудо"?
Эм. Странный поворот вопроса.
"Как не надо" было написано: не надо считать данные в таких триггерах как "первичные".

НО есть несколько оговорок.
1. "Как не надо" можно перечислять долго. Это бесполезно. Надо развивать понимание предметной области. И скорее нарабатывать варианты "как надо" или как желательно. Можно написать работающий вариант, но который будет идти в разрез остальной системе.
2. Выбор/определение "принципов" тут стоит остро. Как "проще думать" - все триггера показывают "первичные" данные или только AFTER. И на чём остановиться.
3. Касательно текущеё задачи, то Crimean описал пару способов контроля. Но на самом деле подойдёт любой какой используют в обычных процедурах + вариант, что UpdLock ставится всегда.

RubinDm
не приходилось вникать в такое "чудо"
Скорее изложение Crimean-а слишком запутанное, оно словестное в строку. По пунктом со скриптами понятнее было-бы. "Проблема" очень простая как 2 копейки.
Но не скажу что я хорошо излагаю (слишком подробно).

Вопросы "к сообществу" я поствил (12625676). Ибо я не могу сказать что M$ делает неправильно, проблемы в модели серьёзные. Применял часто UpdLock, но и "последствия" тоже знаю. В основном был JOIN чем секциорирование, где обычно народ пользуется процедурами.

Это (локировки) не единственный недостаток триггеров. Сиквенсы (Identity) тоже в пролёте. Вот как раз хочу пощупать новые SEQUENCE в данном ракурсе. Можно ли выработать алтернативные решения.

RubinDm, или вы хотите чтоб я разжевал всё по пунктам с решениями, как 3х летнему?
30 май 12, 15:49    [12638440]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Crimean
Member

Откуда:
Сообщений: 13147
ремарка!
"голый" updlock - обычно прямая дорога к дедлокам. тогда уже xlock как лечение, если говорим вообще, непредметно. updlock был применен в примере только чтобы "выровнять" картину блокировок с другим примером, не более чем
30 май 12, 16:25    [12638794]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
xlock
Согласен, но это только для вашего варианта (секционирование выровненных таблиц) отлично подходит. Когда делается JOIN это уже плохо катит - т.к. локируются общие объекты и возникает очередь. Конечно можно логику в процедуры перенести.
На самом деле UpdLock в целом нормально (они же несовместимы одновременно), но есть вероятность нарваться, конечно, и неплохая такая вероятность. Когда система плохо сбалансирована или нет нужных индексов или сложные перекрёстные/параллельные запросы.

Например, UpdLock используется как механизмах тестирования системы, если вываливается, то система допиливается, а после хинт снимается/заменяется.

Почему дедлок в принципе это нормальное явление по допустимости.
1. Уже странно что в бизнес задаче допускается одновременный запрос-обновление. Обычно есть жизненный цикл объекта. Не всегда, конечно.
2. От него нельзя избавить в принципе. Особенно возникает у любителей размазать по процедурам или децентрализации логики.
3. У одного логического явления два варианта, это ещё когда к примеру UPDATE WHERE ID = @ID AND State = @State вернул 0 строк. Палюбэ надо обрабатывать.
Явление же если и возникает, то очень редко (иначе скорее ошибка в архитектуре).
30 май 12, 21:06    [12640269]     Ответить | Цитировать Сообщить модератору
 Re: и опять партишенед вьювы. еще один нюанс. теперь блокировки  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mnior
JOIN это уже плохо катит - т.к. локируются общие объекты и возникает очередь.
Т.к. хинт применяется для всего выражения.
Вот если можно было поставить только для конкретных таблиц.
Можно конечно ставить в самой VIEW, но это уже не дело, т.к. она чаще применяется и не для обновления.
Ещё есть
UPDATE <View> SET ... OPTION(TABLE HINT (<Table> XLock) )
Если мне не изменяется память, то он не катит (или появился в 2008), поправьте меня. Ну во всяком случае, тоже не цветочек заранее знать таблы.
30 май 12, 21:22    [12640347]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить