Vetal пишет:

> Я вот думаю, а к каким плохим для сайта последствиям может привести
> изменение уровня изоляции для базы на READ UNCOMMITED? Может, стоит все
> таки перевести базу в READ UNCOMMITED, с целью оптимизации
> производительности?

Смотря какая СУБД. Не все СУБД это вообще поддерживают, не на всех
будет повышение производительности. Я бы сказал, что повышения
производительности не будет вообще никогда, на любой БД.
Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:
> и при большом количестве юзеров и "длинных" транзакциях?..

Цель у снижения уровня изоляции - это потенциальное повышение
возможности параллельной работы пользователей. Производительность
может измениться только опосредованно.

Тут может быть несколько случаев

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

она может не измениться, например, вследствии того, что
конкретная СУБД вообще не поддерживает уровень изоляции 0.
Т.е. позволяет его ставить, но ведёт себя так же, как и на уровне 1 или 2.
Напомню, что READ_COMMITED НЕ ОБЯЗАН проявлять феномены грязного чтения,
вы, устанавливая READ_COMMITED, только разрешаете им появляться, а
будут они появляться или нет - зависит от СУБД. СУБД вполне
может вести себя как на READ_COMMITED.
(многие версионники, как InnoDB или Interbase так себя и ведут).

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

Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:
> 2. Понял так, что не все серверы поддерживают READ_COMMITED как это
> описано у классиков

Поддерживают-то практически все. Как-то по-другому работают при этом - не все.
Posted via ActualForum NNTP Server 1.4

Sgt.Pepper пишет:

> 3. она может и упасть, знать бы кто она...

Производительность. О ней речь.
Posted via ActualForum NNTP Server 1.4

Кот Матроскин пишет:

> Так все-таки, в какой СУБД на RR два *читающих* процесса могут
> заблокировать один другого?

Два читающих процесса ни на какой СУБД вообще не могут друг друга
заблокировать. Ну если только из-за конкуренции за ресурсы сервера.
Но не по доступу к данным.
Posted via ActualForum NNTP Server 1.4

Кот Матроскин пишет:

> Ну вот gardenman, похоже, считает, что могут. И, более того, каждый
> "грамотрый" человек
> должен про это знать.
> Давайте его послушаем - вдруг узнаем чего нового?
Давайте.
Posted via ActualForum NNTP Server 1.4

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