create table test (i numeric identity, v numeric);

begin tran
select sum(v) from test;
commit;

begin tran
select sum(v) from test;
commit;

...

begin tran
select sum(v) from test;
commit;

begin tran
update test set v=1000;
commit;
begin tran
update test set v=v+1 where i in (4,2621440,151345,2343543,3,2620000);
commit;
...
begin tran
update test set v=1000;
commit;
begin tran
update test set v=v+1 where i in (4,2621440,151345,2343543,3,2620000);
commit;

5242880000
5242880006
5242880000
5242880006
5242880004

M>>Эффект ридкомиттед понятен. Но двигать транзакции, это уже слишком

Почитайте: В блокировочнике никогда нельзя быть уверенным за правильность отчета ?!

1. ... да, действительно версионники позволяют быстро начать, без лишних усилий и некоторое время не знать проблем с производительностью ...
2. ... Том Кайт советует пересоздавать таблицы при удалении например 1млн записей. ...

В свете всего вышеописанного почетной обязанностью разработчика является сведение вероятности мертвой блокировки к минимуму, а в идеале – к нулю, что является достаточно сложной, но вполне разрешимой задачей

M>Ну легкой жизни никто не обещал...

В общем случае наилучшим выходом здесь будет наложение при чтении промежуточной блокировки обновления. Такая блокировка совместима с коллективной, что позволит читающим транзакциям обращаться кэтим данным беспрепятственно. А когда понадобится их обновить, то проблем быть не должно, так как блокировки обновления между собой несовместимы, и значит, другие транзакции, читающие эти данные для последующего изменения (и естественно тоже запросившие их с блокировкой обновления), будут ждать, пока эти данные поменяются, никому не мешая. Для этого необходимо изменить первый оператор транзакции примерно таким образом:

SELECT @Var = Y FROM Tbl WITH (UPDLOCK) WHERE X = 2

begin tran 
select * from test with (UPDLOCK) where i=2;
update test set v=v+1 where i=2;
commit;

select * from test where i=2;

M>>в первой выполняю строки 1 и 2. запускаю вторую — все, курим хотя по смыслу и по описанию не должны.

begin tran 
select * from test with (UPDLOCK) where i=2;

M>>begin tran 
M>>select * from test with (UPDLOCK) where i=2;
M>>

M>>и все, но вторая курит

M>Либо у Вас не MSSQL, и не DB2 и даже не Sybase, а какой-то совершенно не известный мне сервер..

set transaction ISOLATION LEVEL SERIALIZABLE
begin tran 
select * from test with (UPDLOCK) where i=2;
--update test set v=v+1 where i=2;
--commit;

select * from test where i=2; - задумался
select * from test where i=3; - задумался
select * from test where i=4; - задумался
select * from test where i=Х; - задумался при любом Х

create table TMP (id int); 
--В начале таблица пустая. 

--транзакция 1: 

DELETE from TMP WHERE id IN (1,2) ; 
INSERT INTO TMP (id) VALUES (1); 

--транзакция 2: 

DELETE from TMP WHERE id IN (1,2) ; 
INSERT INTO TMP (id) VALUES (2); 
COMMIT; 

--транзакция 1: 
COMMIT;

разница лишь в том что когда пыль усядется, в Оракле будет в принципе неправильный результат, а МС не даст второй транзакции зеленый свет пока не кончится первая транзакция.
Если тебе нужен правильный результат в оракле — тебе не останется ничего другого как заблокировать всю таблицу, целиком и полностью — в Оракле нет предикатных блокировок.

create table TMP (id int); 
--В начале таблица пустая. 

--транзакция 1: 

DELETE from TMP WHERE id IN (1,2) ; 

--транзакция 2: 

DELETE from TMP WHERE id IN (1,2) ; 
INSERT INTO TMP (id) VALUES (2); 
COMMIT; 

--транзакция 1: 
INSERT INTO TMP (id) VALUES (1); 
COMMIT;

M>первая завершаясь добавляет в базу свою строчку 1, а то что делит второй не смог это удалить — ну так правильно, нечего на тот момент удалять то было .

-- для всех транзакций
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

-- транзакция 1 (T1)
--
SELECT (X, Y)

-- надо добавить к X два, 
-- проверяем, что X + 2 + Y < 5
--
IF ((X + 2) + Y < 5) -- все в порядке Y(=1) + X(=1+2)<5
    UPDATE SET X=X+2

-- в этот момент стартует вторая транзакция (Т2)
-- которой, в свою очередь, надо к Y добавить 2, естественно с проверкой.
--
SELECT (X, Y)

IF (X + (Y + 2) < 5) -- тоже все в порядке Y(=1+2) + X(=1)<5
    UPDATE SET Y=Y+2 -- так как SELECT(X, Y) выбрал последнюю 
                     -- зафиксированную версию X (=1)

-- ну и фиксируем обе транзакции в произвольном порядке.
-- 
COMMIT    -- T1

COMMIT    -- T2