Sgt.Pepper пишет:

> не обратный, конечно, простите, все тот же с commited на uncommited...
Я ж все написал. Могут использоваться другие алгоритмы доступа к данным,
например, менее эффективные.
Posted via ActualForum NNTP Server 1.4

Vetal пишет:

> Ну, по идее, если есть тяжелые длительные UPDATE, то в случае READ
> COMMITED читающих транзакций они будут ожидать окончания UPDATE, а в
> случае READ UNCOMMITED они ждать не будут.

> По-моему, это и есть то преимущество, которое может дать READ
> UNCOMMITED... Правильно я понимаю?

Ты понимаешь, в общем, правильно.

Но надо понимать и следующее :
не во всех СУБД читающие транзакций на READ COMMITED будут ожидать
окончания тяжелых длительных пишущих транзакций, меняющих эти же данные.


не во всех СУБД читающие транзакций на READ UNCOMMITED гарантированно НЕ
БУДУТ ОЖИДАТЬ окончания тяжелых длительных пишущих транзакций, меняющих эти же
данные. READ UNCOMMITED имеет полное право работать как все уровни изоляции
более высокого уровня - READ COMMITED и выше.

Т.е. ключевое слово тут - "МОЖЕТ". Может дать преимущество, а может и не
дать.
Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:
> а ссылки на "производительность может упасть"?... правда интересно - я
> не занимался серьезно этим вопросом, может просветите?...

Ну на тебе ссылку .
http://www.sql.ru/forum/actualthread.aspx?tid=559758&pg=1&hl=
Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:

> Согласен. Но как производительность может ухудшиться?.. почему?...

Ты чего, читать не умеешь ?
я же написал :

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

> И еще - у меня создалось впечатление, что Вы рассматриваете серверы, в
> которых cost-based optimizer учитывает еще и кол-во коннектов или даже
> статистику обращения этих конкурентных запросов к конкретным
> таблицам?...

Думаю, никакой cost-based оптимизатор это не учитывает. По крайней мере
многие не учитывают точно, а чтобы учитывали, я не слыхал.
Я такое не рассматривал.

было сказано намеками, так что простите, если не так
> понял... А если так, то полцарства за ссылки :))

Зачем оно вам ? Я дал вам ссылки
Я просто не хочу писать долго поднобно, если НАДО - могу.
Но думаю, вам достаточно и общего осознания того, что так
может быть.
Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:

> а что это за алгоритмы такие?.. я так понимаю, что алгоритмы чтения
> данных определяет оптимизатор при построении плана запроса, или нет?.. и

Да. Он выбирает из числа возможных алгоритмов обработки данных, реализованых
в данной СУБД.

> если Вы утверждаете, что оптимизатору при построении плана фиолетово
> сколько сейчас коннектов, то почему "алгоритмы чтения данных" изменятся?..

Сколько коннектов оптимизатору фиолетово, как правило. А режим работы
транзакции с данной таблицей - нет. Это - разные вещи. У тебя может
не быть ни одного коннекта во время работы оптимизатора, а во время
работы уже самого запроса, использующего грязное чтение, он может и
появится.

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


Держи еще ссылок

http://infocenter.sybase.com/help/topic/com.sybase.dc33621_33620_33619_1250/html/ptallbk/X12268.htm
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.sqlug/html/sqlug/sqlug860.htm
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc33621_33620_33619_1250/html/ptallbk/X13628.htm
Posted via ActualForum NNTP Server 1.4