10 Гб, а не 10 Тб. Если данные меняющиеся - Interbase умрет тихой смертью со своей версионностью. MSSQL или Oracle.

Иногда лучше жевать, чем говорить. Как могут быть связаны версионность и размер базы. Похоже на зависимость соленого от длинного.

Denis A.

f_w_p Вам уже вкратце ответил.
От себя добавлю, что как версионники, так и блокировочники на типовых задачах (коих большинство) покажут примерно одинаковую производительность.

Преимущества архитектуры сервера проявляетя в:
очень жесткий OLTP (от 1 тыс. транзакций в секунду) - блокировочник будет явно предпочтительнее, так как выгодней будет потратить ресурсы на блокировки, чем на операции по записи версий в блоки данных;

OLAP или преоблдание ad-hoc запросов - версионник рулит, так как версии не плодятся вообще.

З.Ы. Здесь кто-то обозвал Oracle версионником. IMHO, это не совсем так. Он, по сути дела, все таки нечто среднее между версионником и блокировочником.

Владимир П.

Oracle версионник, т.к. блокировка возникает только при одновременном обновлении одной и той же строки. Читатели не блокируются писателями и наоборот. И какая разница: сохраняет он в специальной структуре новые версии строк или старые?

T1 -> SELECT SomeField FROM SomeTabe FOR UPDATE
...
T2 -> SELECT SomeField FROM SomeTabe FOR UPDATE
или
T2-> UPDATE SomeTable SET SomeField=NewValue
...

Обе транзакции читающие (по крайней мере, пока). T2 ждет на блокировке, причем на самой сильной - X блокировке, хотя и зря, можно было бы наложить более уместную в этом случае S блокировку - но это уже другая тема. Так что все-таки зачатки блокировочника имеются.

xz321

Я писал - "..преобладание ad-hoc запросов", что вовсе не означает, что нужно городить DataWarehouse. К тому же OLAP запросы в Oracle можно получать на рабочей базе, а не выносить всю аналитику в хранилище - сказывается больший уклон в сторону версионника - ему такое по плечу. Вот делать OLAP на рабочей базе или гнать много ad-hoc запросов на чистом блокировочнике не рекомендуется, так как блокировки являются ресурсом , причем конечным. Поэтому разумным решением для OLAP на блокировочнике - вынести всю аналитику на отдельный сервер, так как with nolock не всегда использовать уместно, а использовать Dirty Read просто опасно.

Ad-hoc query??? Oracle optimizer is not so good as DB2 or Teradata...

Перед таким высказыванием обычно ставят - "IMHO" или "по данным таких-то источников...".

2 Zaxx.

Не все так просто, как кажется.
Итак, поехали.

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

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

Цитата из документации по Oracle:
.../appdev.920/a96590/adg08sql.htm#15057

"...Because Oracle does not use read locks, even in SERIALIZABLE transactions, data read by one transaction can be overwritten by another. Transactions that perform database consistency checks at the application level should not assume that the data they read will not change during the execution of the transaction (even though such changes are not visible to the transaction). Database inconsistencies can result unless such application-level consistency checks are coded carefully, even when using SERIALIZABLE transactions..."

Полную версию описания данного явления читайте "Oracle9i Application Developer's Guide - Fundamentals
Release 2 (9.2) chapter 7 How Oracle Processes SQL Statements".

Ключевое поняте здесь - database consistency checks at the application level.
Т.е. когда не используются констрэйнты, а вся логика лежит на клиенте.

Рассмотрим теперь эти 2 архитектуры построения приложений с точки зрения обработки клиентских вызовов:

если используется SERIALIZABLE и consistency checks at the application level:
от клиента получаем данные, сравниваем их с чем нибудь, выполняя SELECT FOR UPDATE (а иногда и вовсе LOCK TABLE - да, да - может и так), проверяем данные - если они правильные - то записываем данные и коммитим транзакцию, если нет - то отправляем сообщение об ошибке клиенту; конкурирующие транзакции при этом ждут на блокировке;


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

Так вот, первый вариант при очень большом количестве транзакций иногда будет предпочтительнее, так как дешевле проверить данные "вручную" и подержать на блокировках конкурирующие транзакции, а не получать RAIS'ы. Именно в таких ситауциях чистые блокировочники (MSSQL, DB2) имеют потенциальное преимущество, потому что их LockManager'ы, в зависимости от степени загрузки сервера, анализа конкурирующих запросов к страницам данных, селективности индексов могут динамически управлять блокировками - реализовывать т.н. эскалацию блокировок вплоть до полного LOCK TABLE, к тому же могут накладывать т.н. S-блокировки, что повышает concurrency, а Oracle накладывает только X блокировки - но все равно позволяет вести себя как блокировочник.

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

Уф. Вроде бы все.
Спасибо за внимание.

Zaxx

автор писал:Это не так. SELECT FOR UPDATE нужен чтобы заблокировать нужные записи в таблице (причём иного способа это сделать нету).

Я бы сказал так: SELECT FOR UPDATE необходим для того, чтобы заблокировать нужные записи в таблице чтением . Поймите, выполнение SELECT FOR UPDATE не означает, что мы будем менять данные, а означает, что мы " может быть будем менять данные, но нам необходимо, чтобы все транзакции отвечали бы критерию упорядоченности" и для этого просим заблокировать запись.
В этом случае это эквивалентно обычному SELECT на блокировочнике. То же можно сказать в обратную сторону - SELECT ... WITH NOLOCK на блокировочнике с оговорками примерно соответствует обычному SELECT на версионнике. Что и требовалось доказать – ORACLE может вести себя как блокировочник . Другое дело, что чистый блокировочник на определенном круге задач способен реализовать блокировки и concurrency более эффективно, так как присутствует полноценный LockManager и, следует честно признаться, весьма продвинутый (MSSQL, DB2).


автор писал:Для чего он нужен я прекрастно знаю и использую. Но SELECT FOR UPDATE тут не причём. SERIALIZABLE включается путём : ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE или set transaction isolation level serializable.

Фишка в том, что не надо включать этот режим изоляции явно или такой режим не всегда нужен в пределах сессии, а эмулировать его средствами приложения, чтобы не получать …
автор писал:Иногда в SERIALIZABLE - режиме вы можете получить - ORA-08177: can't serialize access. Тогда Rollback и начинаем снова...
Потому как всегда писать в базу, наталкиваться на констрэйнты, получать exception и заново накатывать транзакцию не всегда бывает дешевле - иногда лучше подержать конкурентов на блокировках.

автор писал:Это к "SELECT FOR UPDATE" вообще отношения не имеет.

Советую вам все-таки прочитать этот раздел документации от начала до конца .

автор писал:При чём тут SELECT FOR UPDATE ? Причём тут SERIALIZABLE ?

Констрэйнты гарантируют согласованное состояние базы. С помощью SELECT FOR UPDATE тоже можно обеспечить согласованное состояние без увлечения констрэйнтами (например, при обеспечении согласованности с удаленной базой или еще каким-нибудь внешним хранилищем) и transisolation level. Как я уже сказал - это нетипичное поведение, но такие ситуации бывают, где SELECT FOR UPDATE будет предпочтительнее – но это типичное поведение блокировочника, когда читатель получил ресурс и заблокировал писателя.

автор писал:Oracle тоже может накладывать S-блокировки...и что ? А X-блокировки oracle без вашего вмешательства с "select for update" тоже просто-так накладывать не будет


S-блокировки в Oracle можно наложить только с помощью LOCK TABLE – но это на всю таблицу. При управлении блокировками на уровне строк, для чего и служит SELECT FOR UPDATE – он всегда накладывает только X блокировку. Попробуйте:
T1 - > SELECT SomeField FROM SomeTable WHERE ID=1 FOR UPDATE
T2 - > SELECT SomeField FROM SomeTable WHERE ID=1 FOR UPDATE
Вторая транзакция стоит на блокировке, т.е. T1 получила ресурс в режиме eXclusive. Заметьтьте, T2 не пыталась обновить данные, она лишь запросила блокировку. Если бы была наложена более уместная Shared блокировка, то SELECT FOR UPDATE во второй транзакции прошел бы без проблем и на блокировку бы она натолкнулась только тогда, когда стала записывать данные. Но не факт, что у T2 возникла бы потребность изменять данные после SELECT FOR UPDATE. За счет этого в некоторых случаях здорово можно выиграть в скорости – потому что часть транзакций типа T2, которые отказывались бы от записи в базу, могли бы не стоять на блокировках.

Эмулирование S-блокировок на уровне строк можно реализовать, используя пакет DBMS_LOCK (причем даже более продвинутые, так как можно наложить блокировку в одной транзакции, а снять в другой), но это эмулирование , следовательно, проигрыш в скорости обязательно будет, т.к. переключение между SQL и PL/SQL engine не дается даром.


автор писал:Не нужно ему действовать как блокировочнику...безо всяких оговорок!

Нет, ну все-таки нужно перед такими утверждениями ставить “IMHO” и попытаться обстоятельно объяснить в доступной форме свою позицию.

З.Ы. По моему, все движется к тому, что в версионники будут добавляться фичи блокировочников и наоборот. Вон недавно Oracle10 ходил в лидерах по tpc-с, IMHO наверное, за счет более продвинутого механизма блокировок – в жестком OLTP они реально могут дать прирост. Говорят, и грядущий Yukon будет «не совсем чистым» блокировочником. Однако это пока только слухи - время покажет. Ждем полной официальной документации по Oracle10 и релиза Yukon.

Zaxx

Ну вот, уже какой-то прогресс есть. Вопросы с chapter 7 How Oracle Processes SQL Statements сняты, вопросы о том, может ли Oracle накладывать S-блокировки тоже. Идем дальше.


автор писал:Повторюсь: Oracle не блокирует записи чтением. НИКОГДА. SELECT FOR UPDATE необходим для того, чтобы заблокировать нужные записи в таблице БЛОКИРОВАНИЕМ

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

автор писал:Вы сами, намеренно ставите X-блокировку и заявляете, что Oracle неэффективно управляет блокировками.

Я его прошу поставить блокировку FOR UPDATE, а то, что Oracle ставит X-блокировку вместо более уместной в этом случае S-блокировки - и есть основание, которое позволяет мне усомниться в эффективности реализации блокировок.

автор писал: автор писал:
ORACLE может вести себя как блокировочник

Без вашего вмешательства это не проявляется.
Блокировочник блокирует по чтению.

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

автор писал:Чтение это SELECT (без "for update").
SELECT FOR UPDATE - это чтение и блокирование. Ну согласитесь - данные то я все-таки считываю. Написав SELECT FOR UPDATE, мы говорим Oracle: прочитай нам данные, но поступи как блокировочник.


автор писал:SERIALIZABLE - режим позволит вам получить непротиворечивость гораздо эффективнее чем блокировки.
По этому поводу я уже высказывался - не факт - возбуждение исключения, лишний rollback(особенно) и накат транзакций - штука по меркам БД весьма не дешевая.

Про констрэйнты поскипано.


автор писал:читатель НЕ получил ресурс, а намеренно заблокировал ресурс.
Ну ладно, обзовем это не ресурсом, а данными. Но он их все-таки прочитал.


автор писал:Как я уже сказал это поведение не Oracle, а поведение программиста. Наличие в Oracle различных средств наложения блокировок не делает Oracle блокировочником. Даже если блокировка действительно необходима и иного выбора у программиста не было и это было самое эффективное и производительное решение, это решение программиста. И Oracle от этого блокировочником не становиться.


Никто и не говорит, что он блокировочник - он, как я уже говорил, IMHO - гибрид. В зависимости от желания программиста он может вести себя как версионник (в подавляющем большинстве случаев реальной практики), так и (в нужные программисту моменты) как блокировочник (ведь приемы и методы те же).

Не следует считать все мое словоблудие как наезд на Oracle. Я лишь пытаюсь изложить свое мнение насчет того, является ли Oracle чистым версионником. IMHO - чистым не является. И именно за счет этого при прочих равных я считаю его на данный момент времени лучшим СУБД (эх, ему бы еще S-блокировки - тогда вообще монстрюга).


xz321

автор писал:You say what locks is limited resources. Additional pages in Oracle is not limited resources??? Create 1 new page (block 4K) data in oracle is aproximate 113 row locks in DB2 or MSSQL. And for increase concurency you need decrease amount of data on you page. This mean you table get more space. This mean what you shoud have more I/O... May this limit for you resources may be not. But on server with pessimistic model of processing transaction you also can have good perfomance on mixed workloads.

Честно говоря, я не совсем основательно подкован в вопросе, как Oracle хранит блокировки, но пользуясь недолгими, но утомительными выкладками, умозаключаю:раз Oracle хранит блокировки в блоках данных (насколько я помню - в заголовках), т.е. вместе с данными, то получается, что ивлекая данные, он всегда знает - заблокированы они или нет. Если заблокированы- он достает данные из сегмента отката (в чистом SELECT, без FOR UPDATE). Таким образом блокировка в Oracle является практически неисчерпаемым ресурсом - ограничением является только размер доступной физической памяти на винтах. Хотя вы правы в том, что присутствуют дополнительные I/O-операции. Но никогда, понимаете, никогда я не видел, когда при длинных транзакциях в Oracle росло потребление памяти и заметно падала производительность. За подробностями остылаю к Тому Кайту.

Как хранит блокировки, к примеру, MSSQL - там это отдельная структура в памяти , где каждая блокировка занимает X байт. Следовательно, чем длиньше транзакции, тем больше блокировок - тем меньше памяти. Эффект видел своими глазами. Ресурс исчерпаемый. Поэтому в блокировочниках длинные большие транзакции - вред.

Если чего перемудрил - знающие люди поправят.


автор писал:Who recomend you not run mixed workload on DB2, Informix, MSSQL???
Жизнь. На MSSQL приходится выносить аналитические данные в суррогатные аггрегирующие таблицы или вьюхи, для того, чтобы понизить concurrency cost.

автор писал:About optimizer. When Oracle released they own cost based optimiser and when IBM with Teradata????
Вам самому не смешно?

автор писал:Regarding TPC-C and what Oracle have more good locking model
Я не считаю, что Oracle имеет more good locking model. Напротив, здесь есть над чем работать.
Насчет тестов TPC - IMHO, это маркетинг (кто платит-то за эти тесты), лишь косвенно отображающий потребительские достоинства СУБД. К тому же это соревнование не только софта, но и железа.

Спасибо за внимание.

Zaxx

... поскипано, поскольку это уводит нас от темы.

автор писал:Вот и у вас так. Блокировать умеет - значит блокировочник.

Скажем так, он может вести себя как блокирововчник. Но это не значит, что он блокировочник - он гибрид.

автор писал:Кстати, а вы уверены что это именно X-блокировка ? Что вы понимаете под X-блокировкой ? Exclusive lock ?

Да

автор писал:Select for update накладывает такую-же row-level lock как и обычный UPDATE или DELETE.

Да. А зря.

автор писал:Если это Х-блокировка, то чем она вас не устраивает / какую вы хотите ?

Я хочу S-блокировку. Поясню на абстрактном примере.


Данные в SomeTable
ID SomeField
---- ---------
1 1
2 2

T1 -> Foo(1, 2) --not commuted
T2 -> Foo(1, 1) --not commited

T2 стоит и ждет на блокировке, т.е. на SELECT FOR UPDATE. Но процедура с параметрами, как в T2, никогда бы не произвела UPDATE. Соответственно, пока выполняется T1, Т2 вполне могла бы не стоять на блокировке и ждать завершения Т1. А по логике же, надо, чтобы она вошла в блокировку в том случае, если 2-ой параметр был бы не равен 1 и не в SELECT FOR UPDATE, а при UPDATE. Зачем забирать строку в монопольное пользование, если нет уверенности в том, что она все таки будет изменена. Вот при изменении и возникла бы блокировка. А тут на тебе, X блокировка и никаких вариантов.

Пример, как говорится, абстрактный, но показывает, что во время SELECT FOR UPDATE нелья быть уверенным в том, что в дальнейшем потребуется изменение.


автор писал:...с полным правом заявляйте в форуме, что Oracle ведёт себя как однопользовательская СУБД.

Сбавьте тон и перечитатйте мои посты - я такого нигде не заявлял.


Владимир П.

автор писал:Любой, даже версионник, блокирует запись при ее обновлении.
Разумеется. Вот при обновлении и нужна X-блокировка, но не при запросе блокировки.

автор писал:Иногда бывает нужно запретить изменение открытой одним пользователем записи другими пользователями, чтобы подготовить эту запись для будущего изменения.
Все правильно. Но если при SELECT FOR UPDATE еще не известно, будет ли обновляться запись. См. пример.

автор писал:Чтобы избежать такого уродства, в Oracle введен синтаксис SELECT ... FOR UPDATE. Назначение и поведение у такого запроса то же, что у псевдообновления, приведенного выше

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

SELECT FOR UPDATE - это чтение и запрос блокировки . Первое и второе равноправны. И это типичное поведение блокировочника.


автор писал:И это не делает Oracle менее версионным, чем другие версионные БД.

Разумеется - кто то утверждал обратное? Я лишь пытаюсь объяснить - что в некоторых ситуациях блокировочник может иметь преимущество перед версионником - и Oracle позволяет вести себя как блокировочник. А не устравиает то, что они сказали A (SELECT FOR UPDATE), но не сказали Б (накладывать при этом более уместные S-блокировки).

Спасибо за внимание.

2 Ёжик

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

автор писал:5)... Имеем классический Deadlock

Не, ну реализовать Deadlock Manager то надо, обязательно.

автор писал:...но никак не вместо X-блокировки в SELECT FOR UPDATE. А пока юзайте dbms_lock в таких случаях.

Ну ладно, пускай придумают команду SELECT FOR SHARED UPDATE - меня это вполне устроит.

2 ASCRUS

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

И все таки - есть еще сомневаюшиеся, что Oracle - чистый версионник и не может вести себя как блокирововчник?