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

Откуда: Москва
Сообщений: 9347
Владислав Колосов
invm - хорошим будет тот способ, который не использует сортировки и хинты, т.к. они не являются обычной практикой.
Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам.
И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае.

TaPaK
сдаюсь.
При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов.
Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс
Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON

msLex
Range локи накладываются на предыдущую запись
На следующую.
22 окт 19, 13:58    [21999837]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
invm

msLex
Range локи накладываются на предыдущую запись
На следующую.


точно, все время путаю.
22 окт 19, 14:03    [21999842]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Владислав Колосов
Member

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

я же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросе и не требуется поддерживать сортировку в новых запросах. Кроме того, можно не перекладывать, а удалить лишнее.
22 окт 19, 14:03    [21999843]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
invm
Владислав Колосов
invm - хорошим будет тот способ, который не использует сортировки и хинты, т.к. они не являются обычной практикой.
Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам.
И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае.

TaPaK
сдаюсь.
При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов.
Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс
Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON

msLex
Range локи накладываются на предыдущую запись
На следующую.

почему не накладывать это на получатель?
22 окт 19, 14:05    [21999847]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
Владислав Колосов
я же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросе и не требуется поддерживать сортировку в новых запросах. Кроме того, можно не перекладывать, а удалить лишнее.



Слишком много слов, давайте вы на примере покажите как без not exists вы решаете следующую задачу

есть таблица
create table dbo.dict(id int not null primary key) 


нужно реализовать процедуру
create proc dbo.dict_add

принимающую на вход список id и добавляющую в dbo.dict, те что отсутствуют.
процедура вызывается во много потоков, входящие id в разных потоках могут совпадать.


для простоты (что бы не генерить дополнительных сущностей), список id будет # таблица
create table #t(id int not null primary key) 

создаваемая и заполняемая вне этой процедуры
22 окт 19, 14:12    [21999858]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
TaPaK
invm
пропущено...
Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам.
И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае.

пропущено...
При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов.
Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс
Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON

пропущено...
На следующую.

почему не накладывать это на получатель?


потому что между exists (или left join) и insert проходит достаточно времени, чтобы другой поток вставил отсутствующие записи
22 окт 19, 14:14    [21999862]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
msLex
TaPaK
пропущено...

почему не накладывать это на получатель?


потому что между exists (или left join) и insert проходит достаточно времени, чтобы другой поток вставил отсутствующие записи

т.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени?
22 окт 19, 14:37    [21999913]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
TaPaK
т.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени?


конечно, можете проверить
22 окт 19, 14:41    [21999923]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
msLex
TaPaK
т.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени?


конечно, можете проверить

а разве не сразу получение всех блокировок, а потом выполнение?
22 окт 19, 14:50    [21999935]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
msLex
TaPaK
т.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени?


конечно, можете проверить



вот вам простой репро

создаем таблицу справочник
create table dbo.dict(id int not null primary key) 



и в двух (уже достаточно) потоках запускаем конкурентную вставку с serializable на получателе

declare @id int = 0

while 1=1
begin
	begin tran
	begin try
		/*выбираем id+1 ключ для имитации конкурентной вставки*/
		select top 1 
			@id = id+1
		from dbo.dict
		order by 
			id desc


		insert dbo.dict with(holdlock, rowlock, updlock) (
			id
		) 
		select 
			@id
		where 
			not exists (
				select *
				from dbo.dict
				where 
					id = @id
			)
		commit tran
	end try
	begin catch 
		rollback tran
		;throw 
	end catch 
end 


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

declare @id int = 0

while 1=1
begin
	begin tran
	begin try
		/*выбираем id+1 ключ для имитации конкурентной вставки*/
		select top 1 
			@id = id+1
		from dbo.dict
		order by 
			id desc


		insert dbo.dict  (
			id
		) 
		select 
			@id
		where 
			not exists (
				select *
				from dbo.dict with(holdlock, rowlock, updlock)
				where 
					id = @id
			)
		commit tran
	end try
	begin catch 
		rollback tran
		;throw 
	end catch 
end 
22 окт 19, 14:53    [21999942]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
TaPaK
а разве не сразу получение всех блокировок, а потом выполнение?



нет, конечно.
22 окт 19, 14:59    [21999952]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Cristiano_Rivaldo
Member

Откуда:
Сообщений: 327
Если требуется исключить повторяющиеся - то почему бы не повесить уникальный констрейнт на таблицу ?
22 окт 19, 15:03    [21999957]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Cristiano_Rivaldo
Member

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

Ничего лочить не надо будет. И дублей гарантированно не будет...
22 окт 19, 15:04    [21999958]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
Cristiano_Rivaldo
Если требуется исключить повторяющиеся - то почему бы не повесить уникальный констрейнт на таблицу ?

и откатывать всю транзакцию, при его нарушении?
22 окт 19, 15:04    [21999959]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Cristiano_Rivaldo
Member

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

Нужно написать грамотный блок обработки ошибок
22 окт 19, 15:05    [21999963]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
invm
Member

Откуда: Москва
Сообщений: 9347
Владислав Колосов
я же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросе
Для заботы о стронних разработчиках придумали комментарии.
Владислав Колосов
не требуется поддерживать сортировку в новых запросах.
Зачем ее там поддерживать?
Владислав Колосов
Кроме того, можно не перекладывать, а удалить лишнее.
Задача - добавить из источника строки, отсутствующие в целевой таблице.
Что тут лишнее, которое можно удалить?
22 окт 19, 15:06    [21999964]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
Cristiano_Rivaldo
msLex,

Нужно написать грамотный блок обработки ошибок


до блока ошибок, вставка в таблицу уже откатится
если вставлять одну запись, вроде и не так жалко (хотя это уже двойная вставка в лог)
а если за раз нужно вставить отсутствующие из 10000 входящих записей и вставка упадет из-за 1-й последней записи?

Сообщение было отредактировано: 22 окт 19, 15:09
22 окт 19, 15:09    [21999967]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Владислав Колосов
Member

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

при многопоточности должны быть очереди в любом проявлении - блокировки страниц или блокировки уровня приложения. Позвольте мне воздержаться от написания примера, мозг и так взрывается :) Ищу решение для каскадного удаления.
22 окт 19, 15:13    [21999973]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Владислав Колосов
Member

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

Зачем ее там поддерживать?


Вот в этом и вопрос - разве одновременной выполнение другого запроса к этой же таблице не будет потенциальным источником взаимоблокировок? В нем ведь последовательность наложения блокировок не будет упорядоченной.
22 окт 19, 15:16    [21999980]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
msLex,

Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним
22 окт 19, 15:16    [21999981]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Cristiano_Rivaldo
Member

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

Да - от ошибки нарушения уникальности никуда не денешься...
Но есть практики,которые позволяют заинсертить большое количество данных в максимально короткое время.
Чем быстрее завершится insert - тем меньше шансов на дубли.
22 окт 19, 15:16    [21999983]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7759
invm
Задача - добавить из источника строки, отсутствующие в целевой таблице.
Что тут лишнее, которое можно удалить?


Поясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится.
22 окт 19, 15:19    [21999985]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
Владислав Колосов
msLex,

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


т.е. блокировки уровня ключей вас не устраивают, а страницами пожалуйста



Владислав Колосов
Позвольте мне воздержаться от написания примера, мозг и так взрывается :)

Я не в коем случае не заставляя вас, просто хотелось понять на примере простого кода о чем вы говорите.
Мне до сих пор не понятно как вы решаете проблему многопоточной конкурентной вставки в уникальный ключ.
22 окт 19, 15:21    [21999987]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
Cristiano_Rivaldo
msLex,

Да - от ошибки нарушения уникальности никуда не денешься...


денешься. один из вариантов показан выше
22 окт 19, 15:22    [21999991]     Ответить | Цитировать Сообщить модератору
 Re: Принудительный ordered scan по временной таблице  [new]
msLex
Member

Откуда:
Сообщений: 8091
TaPaK
msLex,

Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним

Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут.
22 окт 19, 15:25    [21999996]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить