Любая процедура, которая следует за шаблоном:
BEGIN TRAN
check if row exists with SELECT
if row doesn't exist INSERT
COMMIT
может привести к проблемам в работе, потому что ничто не мешает двум ступеням выполнять проверку одновременно, и оба приходят к выводу, что их следует вставить. В частности, на уровне изоляции сериализации (как в вашем случае) этот шаблон гарантирован для взаимоблокировки.
A намного Лучше использовать шаблон уникальных ограничений базы данных и всегда вставлять, регистрировать ошибки дублирования ключа. Это также значительно более эффективно.
Другой альтернативой является использование оператора MERGE :
create procedure usp_getOrCreateByMachineID
@nMachineId int output,
@fkContract int,
@lA int,
@lB int,
@lC int,
@id int output
as
begin
declare @idTable table (id int not null);
merge Machines as target
using (values (@nMachineID, @fkContract, @lA, @lB, @lC, GETDATE()))
as source (MachineID, ContractID, lA, lB, lC, dteFirstAdded)
on (source.MachineID = target.MachineID)
when matched then
update set @id = target.MachineID
when not matched then
insert (ContractID, iA_Metric, iB_Metric, iC_Metric, dteFirstAdded)
values (source.contractID, source.lA, source.lB, source.lC, source.dteFirstAdded)
output inserted.MachineID into @idTable;
select @id = id from @idTable;
end
go
create procedure usp_getOrCreateByMetrics
@nMachineId int output,
@fkContract int,
@lA int,
@lB int,
@lC int,
@id int output
as
begin
declare @idTable table (id int not null);
merge Machines as target
using (values (@nMachineID, @fkContract, @lA, @lB, @lC, GETDATE()))
as source (MachineID, ContractID, lA, lB, lC, dteFirstAdded)
on (target.iA_Metric = source.lA
and target.iB_Metric = source.lB
and target.iC_Metric = source.lC)
when matched then
update set @id = target.MachineID
when not matched then
insert (ContractID, iA_Metric, iB_Metric, iC_Metric, dteFirstAdded)
values (source.contractID, source.lA, source.lB, source.lC, source.dteFirstAdded)
output inserted.MachineID into @idTable;
select @id = id from @idTable;
end
go
Этот пример разделяет два случая, поскольку запросы T-SQL не должны никогда пытаться разрешить два разных решения в одном запросе (результат никогда не оптимизируется). Так как две задачи под рукой (получить по идентификатору mahcine и получить по метрике) полностью разделены, процедуры должны быть отдельными, и вызывающая сторона должна вызывать соответствующую процедуру, а не передавать флаг. В этом примере показано, как достичь (вероятно) желаемого результата с помощью MERGE, но, конечно, правильное и оптимальное решение зависит от фактической схемы (определение таблицы, индексы и существующие указатели на месте). ) и о фактических требованиях (не ясно, что должна делать процедура, если критерии уже соответствуют, а не выводятся и @id?).
Устраняя СЕРИАЛИЗИРУЕМУЮ развязку, это больше не гарантирует для взаимоблокировки, но может все еще оставаться в тупике. Решение взаимоблокировки, конечно же, полностью зависит от схемы, которая не была указана, поэтому решение взаимоблокировки не может быть предоставлено в этом контексте. Кувалда блокирует все возможные строки (принудительно UPDLOCK или даже TABLOCX), но такое решение может снизить пропускную способность при интенсивном использовании, поэтому я не могу рекомендовать это без знания варианта использования.