Господа такой вопрос по блокировкам и уровням изоляции:

создаю таблицу и наполняю её
create table test_block (id int)
go

insert into test_block values (1)
insert into test_block values (2)
insert into test_block values (3)
insert into test_block values (4)
go

создаю 2ю таблицу
create table tt (id int)

в 1й сессии эксклюзивно блокирую test_block
begin transaction
lock table test_block in exclusive mode
select * from test_block

во 2й сессии читаю из неё с грязным чтением
set transaction isolation level read uncommitted
begin tran
select * from test_block
commit

Всё работает, запрос возвращает данные

Пробую сделать вставку грязных данных в таблицу tt

set transaction isolation level read uncommitted
begin tran
insert into tt
select * from test_block
commit
Всё виснет - грязное чтение не работает

Главный вопрос - что insert into не поддерживает грязное чтение?


И ещё такой дополнительный вопрос:

set transaction isolation level read uncommitted
begin tran
select * from test_block
commit
работает

begin transaction
select * from test_block at isolation read uncommitted
commit
требует уникального индекса.


Один и тот же запрос - по сути, но почему 2й синтаксис требует уникального индекса?

Всем заранее спасибо

MasterZiv
Kru пишет:

> И ещё такой дополнительный вопрос:
>
> set transaction isolation level read uncommitted
> begin tran
> select * from test_block
> commit
> работает
>
> begin transaction
> select * from test_block at isolation read uncommitted
> commit
> требует уникального индекса.

> Один и тот же запрос - по сути, но почему 2й синтаксис требует
> уникального индекса?

Вообще говоря, оба должны требовать уникального индекса.
Но там требование не жесткое.

Блин, вообще, Kru, дался вам этот read uncommitted ?
Я думаю все нормальные люди уже давно про него и думать
забыли, с тех пор как появился LOCK SCHEME DATAROWS.
Вы LOCK DATAROWS лучше юзайте, эффект почти тот же,
а проблем почти никаких.
Posted via ActualForum NNTP Server 1.4

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

В жизни я грязным чтением не пользуюсь, но теоретически интересно.

MasterZiv
Kru пишет:

Дело в том, что грязное чтение - это ТОЛЬКО грязное чтение.
Но не грязная запись.

На самом деле уровни изоляций у транзакций такие
(от самого "слабого" к "сильным"):

dirty write
dirty read
read committed
spapshot isolation и repeatable read (два уровня, схожих по "силе")
serializable

Это не по ANSI, это по Грею et al, где они выступали с критикой
стандарта.

"Минимальный" dirty read не является на самом деле логически
минимальным, но dirty write ни одна СУБД делать не позволяет,
поскольку это явно порождает wormhole и просто не дает
возможность реализовать durability транзакций. Т.е. это просто
физически невозможно в любой транзакционной системе.

Вам бы тут хотелось именно грязной записи, но ее не существует
в природе. Так что то, чего вы хотите, никогда работать не будет.

Если рассмотреть это не с точки зрения теории, а с точки зрения
реализации ASE, то lock table накладывает X Table lock до конца
транзакции. SELECT на read uncommitted читает данные вообще без
локов (без транзакционных локов), поэтому это возможно -
прочитать таким select-ом данные из залоченной таблицы. UPDATE
накладывает блокировки X Row, X Page или X Table (в зависимости
от ситуаций), и ни одна из них не совместима с другим X Table lock,
т.е. залоченную таблицу в другой транзакции изменять нельзя.
А, извините, у вас там INSERT был, ну он накладывает X ROW или X PAGE,
или иногда даже X Table, ситуация та же.

Вам надо подумать о другом сценарии взаимодействия ваших транзакций.

Posted via ActualForum NNTP Server 1.4

У нас один из пользователей решил написать процедуру которая могла бы работать параллельно с reorg. Расчёт был на то, что если использовать dirty reading, то не будет никаких блокировок и соответственно проблем. И ему бы это удалось если бы он просто селектил записи. Но т.к. пользователь захотел сохранить результаты выборки во временной таблице, то у него ничего и не получилось.

В общем понятно, что работу reorg надо планировать правильно, тогда и проблем не будет, но!

родился теоретический вопрос - почему нельзя сохранить результаты грязного чтения?
Замечу, что insert выполняется в другую таблицу и блокировки здесь кажется не при чём. А вот то что Вы про идеологию написали
MasterZiv "Минимальный" dirty read не является на самом деле логически
минимальным, но dirty write ни одна СУБД делать не позволяет,
поскольку это явно порождает wormhole и просто не дает
возможность реализовать durability транзакций. Т.е. это просто
физически невозможно в любой транзакционной системе.

звучит довольно интересно. Трудно представить задачу, где-бы требовалось сохранение куда-то ещё грязных данных. Но если бы такая задача возникла бы, то кажется, что по определению она бы не имела решения.

простой тест и результаты:

Session 1
begin transaction
lock table test_block in exclusive mode

locktype /table_id
Ex_table-blk/ 465162640

Session 2
set transaction isolation level read uncommitted
begin tran
select * from test_block
commit

no locks

set transaction isolation level read uncommitted
begin tran
insert into tt
select * from test_block
commit

locktype / table_id
Sh_intent-request /465162640

Видно, что при insert (даже в совершенно другую таблицу) сервер пытается перед чтением записей установить shared блокировку. Другими словами он игнорирует установку read uncommitted.

Вопрос почему он так себя ведёт? Может действительно "грязная" запись запрещена идеологией.

>> И ещё такой дополнительный вопрос:

>> set transaction isolation level read uncommitted
>> begin tran
>> select * from test_block
>> commit
>> работает

>> begin transaction
>> select * from test_block at isolation read uncommitted
>> commit
>> требует уникального индекса.


>> Один и тот же запрос - по сути, но почему 2й синтаксис требует уникального индекса?

Оба случая требуют уникального индекса. Я просто по отдельности запускал в артизане сначала begin tran и потом уже select. Если их запустить вместе, то сервер ругнётся и потребует индекса.

Этот вопрос закрываю, т.к. вопроса собственно больше и нет :-)

MasterZiv
Kru wrote:

> Видно, что при insert (даже в совершенно другую таблицу) сервер пытается
> перед чтением записей установить shared блокировку.

На таблицу, которую он читает для инсерта, так ?

Другими словами он
> игнорирует установку read uncommitted.

А попробуй

select * into #tt from test_block at isolation level read uncommitted

> Вопрос почему он так себя ведёт? Может действительно "грязная" запись
> запрещена идеологией.

Запрещена-то она запрещена, в этом сомнения быть не может.
Но здесь-то эта таблица только читается. Ну не знаю.


А можно вопрос - чем вообще -то REORG мешает ?
Posted via ActualForum NNTP Server 1.4

Попробовал и так
select * into #tt from test_block at isolation read uncommitted

-- Error: Number (7375) SELECT INTO cannot be specified with isolation level clause.

и вот так
insert into tt
select * from test_block at isolation read uncommitted
и даже так : -)
insert into tt
select a.* from
(select * from test_block at isolation read uncommitted) a

--Error: Number (7377) SELECT INSERT cannot be specified with isolation level clause.

Нашел на буржуйском форуме похожий вопрос, но там тоже нет ответа, зато узнал оттуда, что на MSSQL так делать можно. Значит идеология не причём.
Цитата из форума 2002 года.
"What I'd like to be able to do is something with this equivalent in SQL Server 2000:
select distinct fieldname into #temp from tablename with (readpast)
Sybase version is 11.9.2."


Может в Sybase написать? Есть готовая репромодель (они так называют скрипт воспроизводящий багафичи)

Народ! Есть кто-нибудь подписанный на сайбезовскую техподдержку? Может напишите?

Раньше, за обнаружение "хорошей" багафичи дарили игрушечный грузовичок с логотипом Sybase через весь кузов.
Не шучу. В руках держал : -)))

По поводу reorg - скорее всего выполняется reorg rebuild, поэтому и таблица эксклюзивно блокируется. Я думаю, что не трудно будет разнести по времени процедуру и reorg,
но вопросик то остался : -)

А интересно на ASE15 тоже такое поведение будет?

В общем, нельзя напрямую сделать select..into или insert..select.
Я вчера, кстати нашел ответ супер гуру Rob Verschoor, тот самый который Tips, Tricks & Recipes for Sybase ASE написал: http://www.dbforums.com/archive/index.php/t-743460.html .

Он тоже говорит что так нельзя и идеологически это обосновано.

Ну если уж очень хочется записать грязные данные то можно сделать вот так, через курсор.
На курсор сервер позволяет утановить уровень изоляции isolation read uncommitted.


declare c_test cursor for
select * from test_block
at isolation read uncommitted
go
declare @i int
open c_test
fetch c_test into @i
while @@sqlstatus =0
begin
insert into tt values (@i)
fetch c_test into @i
end

close c_test
go
deallocate cursor c_test
go

У меня вопросов больше нет. Всем огромное спасибо!

Наверное есть один вопрос - всё-таки интересно - есть ли реальные задачи, не связанные с ошибками в расписании как в моём случае : -)), требующие сохранения "грязных" данных.
Кто-инбудь видел что - нибудь подобное?

В голову лезут детективные фантазии о службе безопасности отлавливающей тёмных личностей, которые уже почти выполнили преступную транзакцию, но вдруг их что-то насторожило и они решили на этот раз сделать rollback : -))))


Ну это уже наверное вопрос не к Sybase форуму :-)

MasterZiv
Kru wrote:

> Наверное есть один вопрос - всё-таки интересно - есть ли реальные
> задачи, не связанные с ошибками в расписании как в моём случае : -)),
> требующие сохранения "грязных" данных.

Так вы и не ответили в конце концов, ЗАЧЕМ же вам такое извращение
понадобилось. Потому что вроде бы как REORG может выполняться
on-line, не мешая пользователям (правда, не все его комманды).


Извращение понадобилось одному из разработчиков чью процедуру выполняли во время работы reorg rebuild. Последний эксклюзивно блокирует таблицы т.к. rebuild. В общем первопричина - организационная ошибка.
Почему-то решили, что проще будет отделаться грязным чтением, чем менять расписание.
Удалось убедить, что не надо создавать лишние сложности и что единственно правильное решение это поправить расписание.

Ну а дальше просто любопытно стало почему сервер себя так ведёт. Вот собственно как топик и появился :-)

MasterZiv
Kru wrote:

> Извращение понадобилось одному из разработчиков чью процедуру выполняли
> во время работы reorg rebuild. Последний эксклюзивно блокирует таблицы
> т.к. rebuild.

Так пускали бы RECLAIM SPACE , COMPACT вместо этого.
Posted via ActualForum NNTP Server 1.4

Проблему решили изменением времени запуска процедуры.

Огромное спасибо за ответы!