powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Принудительный ordered scan по временной таблице
12 сообщений из 62, страница 3 из 3
Принудительный ordered scan по временной таблице
    #39880002
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав КолосовinvmЗадача - добавить из источника строки, отсутствующие в целевой таблице.
Что тут лишнее, которое можно удалить?

Поясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится.
удаление избыточных данных не поможет в проблеме с уникальностью, отсутствующие в таблице данные по прежнему могут начать вставляться одновременно из двух параллельных потоков.
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880003
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLexTaPaKmsLex,

Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним
Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут.
ошибка? я про ignore dup key
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880010
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TaPaKmsLexпропущено...

Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут.
ошибка? я про ignore dup key
а, ясно.

ну во-первых, он тоже вешает тот же holdlock
во-вторых, работает медленнее (появляются какие-то дополнительные накладные расходы).
плюс, как уже говорили, спамит варнингами
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880012
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLexTaPaKпропущено...

ошибка? я про ignore dup key
а, ясно.

ну во-первых, он тоже вешает тот же holdlock
во-вторых, работает медленнее (появляются какие-то дополнительные накладные расходы).
плюс, как уже говорили, спамит варнингами
У меня получилось в разы быстрее при отказе от exists, особенно на больших объёмах

на варнинги всё равно в общем
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880013
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,

Код: sql
1.
Мне до сих пор не понятно как вы решаете проблему многопоточной конкурентной вставки в уникальный ключ.



Да, не подумал. конкуренции у меня нет на самом деле, т.к. включается sp_getapplock или выполнение по расписанию. Борьба происходила с deadlock, вызванными запросом внутри себя. Возможно у меня сортировкофобия, не знаю :)
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880014
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TaPaKУ меня получилось в разы быстрее при отказе от exists, особенно на больших объёмах
очень, очень странно
физически он проделывает тоже самое, что и not exists

может у вас not exists в скан сваливлся? у нас еще forceseek четвертым хинтом обязательно стоит.
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880015
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав КолосовmsLex,

Код: sql
1.
Мне до сих пор не понятно как вы решаете проблему многопоточной конкурентной вставки в уникальный ключ.




Да, не подумал. конкуренции у меня нет на самом деле, т.к. включается sp_getapplock или выполнение по расписанию. Борьба происходила с deadlock, вызванными запросом внутри себя. Возможно у меня сортировкофобия, не знаю :)

если у вас допустима синхронизация на уровне sp_getapplock, то вам, конечно, не нужны все эти holdlock-и
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880057
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав КолосовПоясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится.Чтобы избавиться от избыточных данных, нужно определить, что они избыточные.
Для этого нужно проделать те же самые манипуляции с целевой таблицей, что и в стартовом посте. В результате получите те же дедлоки.

Вы в своих решениях принципиально не хотите учитывать конкурентность выполнения запросов?
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880080
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

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

Для запросов вида update table1 where exists (select * from table1) можно получить дедлок единственным запросом.
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880082
Ftt330
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLexи откатывать всю транзакцию, при его нарушении?
Вставляйте по строке за раз :)
Для соблюдения уникальности в СУБД придуманы unique констрейнты.
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880100
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ftt330msLexи откатывать всю транзакцию, при его нарушении?
Вставляйте по строке за раз :)
Для соблюдения уникальности в СУБД придуманы unique констрейнты.Ваш метод организации конкурентной вставки понятен, но далеко не у всех у базы один пользователь.
...
Рейтинг: 0 / 0
Принудительный ordered scan по временной таблице
    #39880105
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосовя уже ответил, что дедлоки в моем случае были вызваны не конкурентностью между потоками, а конкурентностью внутри самого запроса. Поэтому, если ситуации с одновременным выполнением нет, то можно производить все действия, которые я описал.Тогда непонятно зачем вообще предлагать решение заранее зная, что оно не подойдет?
Что такое "конкурентностью внутри самого запроса"?
Владислав КолосовДля запросов вида update table1 where exists (select * from table1) можно получить дедлок единственным запросом.Как это относится к запросу ТС?
...
Рейтинг: 0 / 0
12 сообщений из 62, страница 3 из 3
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Принудительный ordered scan по временной таблице
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]