Доброго дня!
Есть небольшая по размеру временная таблица TmpT , используется как промежуточная для вставки в "рабочую" WrkBigTable .
Наполняемость многократно варьируется - от 1 до 1000 строк. Несколько клиентов (через разные хранимки или напрямую) накидывают в TmpT свои рекордсеты, маркированные ключевым полем (KeyField). Клиентами запускается одна и та же хранимая процедура с соответствующим полю KeyField значением параметра - выбирает из TmpT записи, обрабатывает их и кидает в WrkBigTable .

Суть проблемы: для получения значения KeyField происходит выборка:
.
Вставка записей в TmpT, их выборка из TmpT и удаление,- совершенно ни как не связаны. В какой-то момент начинается конфликт. Причём, похоже, всё сходится именно на несчастной TmpT, а именно её KeyField .
По KeyField есть первичный ключ в связке ещё с одним полем. Почесав затылок и вспомним лекции Дмитрия Короткевича, не придумал ни чего лучшего, как создать отдельный некластерный индекс по KeyField. Индекс получился страшным (на 1000 обновлений всего 500 seek-ов), но сервер использует его в estimated plan для select @NewKey = isnull(max(KeyField),0)+1 From TmpT WITH (UPDLOCK HOLDLOCK) (!!!!)

Насколько удачным можно считать такое решение?

С одной стороны, индекс волочиться "мёртвым хвостом". С другой,- это, на мой взгляд, единственное решение в рамках неизменяемости архитектуры базы и приложения...

--------------------------
No ROM Basic...
Как-то так (на вскидку, не проверял ;-) ) :

Код: sql

1.
2.
3.
4.
5.
6.
7.

create table TmpT ( KeyField int not null
                            ,pointNumber int not null
                            ,otherField varchar(20)
                            ,anotherField int
                            );
Create primary key clustered TmpT_clust on  TmpT (KeyField asc, pointNumber asc );
create index TmpT_idx on  TmpT ( KeyField desc);

Владислав КолосовSIMPLicity_,

Я бы это сделал через Service Broker для разделения отправителя и получателя. На стороне инициатора помещаете данные в очередь, а на стороне получателя забираете из очереди и обрабатываете. Используйте группы, чтобы из одной очереди могли забирать разные получатели или сформируйте несколько очередей. Кроме того, можно накопленные сообщения обрабатывать "оптом".

Спасибо за комментарий, но этот вариант в данном случае неприемлем - слишком велико время прохождения всей цепочки.

invmSIMPLicity_,

Тип KeyField принципиален?
Замена на uniqueidentifier?- не, "не катит" .... К тому же это не моя архитектура...

alexeyvgSIMPLicity_Вставка записей в TmpT, их выборка из TmpT и удаление,- совершенно ни как не связаны. В какой-то момент начинается конфликт. Причём, похоже, всё сходится именно на несчастной TmpT, а именно её KeyField .Так конфликт происходит при получении новой KeyField? оно же редко вызывается, по сравнению с вставками в TmpT вообще, правильно?

Конфликт происходит как в момент непосредственного захвата, так и в моменты других операций ... Ошибки спонтанные, плюс ко всему тут замешаны распределённые транзакции. И всё это происходит только на "боевой" базе. Сымитировать не удаётся :( ... Думаю переделать кластерный индекс в некластерный ;-) ....