Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Размер БД 10 Gb  [new]
xz321
Guest
aston писал:

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


Muzhik, ty sam ponyal chto skazal??? Eto zhe warehouse => pochti read only.
DB2 EEE, Informix XPS, Teradata.

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

P.S. Sorry for English
26 ноя 03, 12:24    [433613]     Ответить | Цитировать Сообщить модератору
 Re: Размер БД 10 Gb  [new]
aston
Member

Откуда:
Сообщений: 227
Владимир П.

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" или "по данным таких-то источников...".
26 ноя 03, 15:01    [434177]     Ответить | Цитировать Сообщить модератору
 Re: Размер БД 10 Gb  [new]
Zaxx
Guest
2 aston

автор писал:
T1 -> SELECT SomeField FROM SomeTabe FOR UPDATE
...
T2 -> SELECT SomeField FROM SomeTabe FOR UPDATE
или
T2-> UPDATE SomeTable SET SomeField=NewValue
...
Обе транзакции читающие (по крайней мере, пока).


На лицо типичная подмена понятий... SELECT FOR UPDATE специально предназначен для блокирования записей и говорить, что это просто читающая транзакция (и при этом осознанно блокировать записи) не корректно. С таким-же успехом можно заблокировать всю таблицу с помошью LOCK TABLE, и также наивно заявить - "Обе транзакции читающие (по крайней мере, пока)"
26 ноя 03, 19:00    [434800]     Ответить | Цитировать Сообщить модератору
 Re: Размер БД 10 Gb  [new]
aston
Member

Откуда:
Сообщений: 227
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 все же способен их покрывать, действуя при этом как блокировочник, хотя и с некоторыми оговорками.

    Уф. Вроде бы все.
    Спасибо за внимание.
  • 26 ноя 03, 20:26    [434907]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    2 aston

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


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

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


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

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


    Это к "SELECT FOR UPDATE" вообще отношения не имеет.

    автор писал:
    ...если используется SERIALIZABLE и consistency checks at the application level: от клиента получаем данные, сравниваем их с чем нибудь, выполняя SELECT FOR UPDATE (а иногда и вовсе LOCK TABLE...


    В SERIALIZABLE - режиме НЕ ИМЕЕТ СМЫСЛА лочить записи или всё таблицу, если вы боитесь, что кто-то изменить ваши данные, которые вы выбрали предыдущим select-ом. База данных гарантирует НЕПРОТИВОРЕЧИМОСТЬ данных по чтению в течении всей вашей транзакции от первого select (без всякого "for update") до последнего commit (даже если между этими событиями другая сессия изменила интересующие вас записи), если установлен SERIALIZABLE - режим.

    Иногда в SERIALIZABLE - режиме вы можете получить - ORA-08177: can't serialize access. Тогда Rollback и начинаем снова...

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


    При чём тут SELECT FOR UPDATE ? Причём тут SERIALIZABLE ?

    автор писал:
    к тому же могут накладывать т.н. S-блокировки, что повышает concurrency, а Oracle накладывает только X блокировки - но все равно позволяет вести себя как блокировочник.


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

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


    Не нужно ему действовать как блокировочнику...безо всяких оговорок!
    26 ноя 03, 21:55    [434972]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Gt_
    Guest
    Про S-блокировки, у оракла на пару порядков меньше блокировок и имеено поэтому такого смысла как в блокировочнике не видит (бонус слишком мал). Тем кому все же такое нужно есть пакет DBMS_LOCK и пользовательские блокировки... но не знаю кто таким пользуется.
    Про эскалацию, она вообще нафиг нужна, т.к. влияет на конкуренси, что четко видно на тестах tpc-c, т.е. это говорит о том что эскалация как минимум съедает все расходы оракла на хранение в файлах данных.
    плюс системы редко чистое OLPT или OLAP, у обычных смертных это смешаные ... вот именно тогда версионность реально рулит.
    В Юконе грят уже будет версионность (snapshot), интересно какой режим выберут большинство через пару лет, а главное почему :)
    Пророчество: след битва RAC vs федеративный кластер :)

    Gt_
    26 ноя 03, 21:59    [434973]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    aston
    Member

    Откуда:
    Сообщений: 227
    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.
    27 ноя 03, 09:09    [435264]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    2 Aston

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


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

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

    Без вашего вмешательства это не проявляется.
    Блокировочник блокирует по чтению. Чтение это SELECT (без "for update").

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


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

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


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

    автор писал:
    Как я уже сказал - это нетипичное поведение, но такие ситуации бывают, где SELECT FOR UPDATE будет предпочтительнее – но это типичное поведение блокировочника, когда читатель получил ресурс и заблокировал писателя.


    читатель НЕ получил ресурс, а намеренно заблокировал ресурс.
    Как я уже сказал это поведение не Oracle, а поведение программиста. Наличие в Oracle различных средств наложения блокировок не делает Oracle блокировочником. Даже если блокировка действительно необходима и иного выбора у программиста не было и это было самое эффективное и производительное решение, это решение программиста. И Oracle от этого блокировочником не становиться.
    27 ноя 03, 10:35    [435515]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    xz321
    Guest
    Dear, aston

    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. Who recomend you not run mixed workload on DB2, Informix, MSSQL??? About optimizer. When Oracle released they own cost based optimiser and when IBM with Teradata????

    P.S. Sorry for english?
    27 ноя 03, 11:41    [435719]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    xz321
    Guest
    Regarding TPC-C and what Oracle have more good locking model, please read my last post in topic "news from tpc" |>

    where I try compare different databases on same Hardware. Leadership in TPC-C not mean what you have fastest database in the World. This mean you have fastest combination of HW and Database in the World.

    P.S. Sorry again for English
    27 ноя 03, 11:47    [435743]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    2 xz321

    >About optimizer. When Oracle released they own cost based optimiser and when IBM with Teradata????

    Типа, чья религия древнее, та и истинная ? Арбалет тоже древнее чем снайперская винтовка... Да и догонять всегда легче, чем изобретать с нуля.
    27 ноя 03, 13:01    [436012]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    xz321
    Guest
    Здесь нет никакой религии. Достаточно понять что IBM по патентам далеко впереди.
    А если учесть что патенты Informix перешли к IBM.

    http://www-3.ibm.com/software/data/highlights/db2innovation/patents.html
    http://www.crn.com/Sections/BreakingNews/dailyarchives.asp?ArticleID=32502
    27 ноя 03, 15:42    [436590]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Gt_
    Guest
    а если чуть подумать и вспомнить Alpha ?

    все решает маркетинг, м$ красиво это показывет.
    27 ноя 03, 16:00    [436645]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    xz321
    Guest
    Не знаю как в России, но здесь в Германии у IBM c этим все в порядке.
    27 ноя 03, 16:47    [436739]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    aston
    Member

    Откуда:
    Сообщений: 227
    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, это маркетинг (кто платит-то за эти тесты), лишь косвенно отображающий потребительские достоинства СУБД. К тому же это соревнование не только софта, но и железа.

    Спасибо за внимание.
    27 ноя 03, 19:01    [437137]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Gt_
    Guest
    Я его прошу поставить блокировку FOR UPDATE, а то, что Oracle ставит X-блокировку вместо более уместной в этом случае S-блокировки - и есть основание, которое позволяет мне усомниться в эффективности реализации блокировок.

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


    1. еще раз FOR UPDATE не блокирует читателей, это не X блокировка MSSQLа ! поэтому кол-во блокировок ГОРАЗДО меньше и необходимости ставит S на порядок меньше.

    2. если нужно читать согласовано есть read only transaction
    27 ноя 03, 19:59    [437174]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    2 aston

    автор писал:
    Вопросы с chapter 7 How Oracle Processes SQL Statements сняты


    У меня по этому поводу вопросов и не было. Вы эту ссылку как я уже говорил не по делу засунули.

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


    Опять началось... Вы же сами признаёте что "блокировочник он на то и блокировочник, что не нужно указывать в конце FOR UPDATE".
    Блокировочник блокирует по ЧТЕНИЮ. Оракл этого не делает.

    Вообще мне это старый анекдот напоминает:
    процесс над самогонщиком.
    Судья:
    - Подсудимый! У вас был обнаружен самогонный аппарат?
    Подсудимый:
    -Да.
    Судья:
    - Вы гнали самогон?
    Подсудимый:
    - Нет.
    Судья:
    - Но у вас же был аппарат - значит гнал!
    Подсудимый:
    - Тогда судите меня еще за изнасилование.
    Судья:
    - Вы кого-нибудь изнасиловали?
    Подсудимый:
    - Нет, но АППАРАТ имеется!


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

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


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

    Select for update накладывает такую-же row-level lock как и обычный UPDATE или DELETE. Это не exclusive, а share lock который допускает SELECTы от других сессий и запрещает им менять заблокированные записи. Если это Х-блокировка, то чем она вас не устраивает / какую вы хотите ?

    --
    Совет: Выгоните всех юзеров из базы, "чтобы все транзакции отвечали бы критерию упорядоченности" и, исходя из принципа "АППАРАТ имеется", с полным правом заявляйте в форуме, что Oracle ведёт себя как однопользовательская СУБД.
    27 ноя 03, 20:12    [437176]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Владимир П.
    Member

    Откуда: Екатеринбург
    Сообщений: 443
    Любой, даже версионник, блокирует запись при ее обновлении.
    Иногда бывает нужно запретить изменение открытой одним пользователем записи другими пользователями, чтобы подготовить эту запись для будущего изменения.
    Можно так:

    UPDATE tab
    SET id=id
    WHERE id= :id_текущей_записи.

    Чтобы избежать такого уродства, в Oracle введен синтаксис SELECT ... FOR UPDATE. Назначение и поведение у такого запроса то же, что у псевдообновления, приведенного выше. И это не делает Oracle менее версионным, чем другие версионные БД.
    28 ноя 03, 09:13    [437467]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    aston
    Member

    Откуда:
    Сообщений: 227
    Zaxx

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

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


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

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


    Да

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


    Да. А зря.

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


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

    CREATE OR REPLACE PROCEDURE Foo(AID IN NUMBER, AValue IN NUMBER)
    
    DECLARE
    var1 NUMBER;
    BEGIN
    SELECT SomeField
    INTO var1
    FROM SomeTable
    WHERE ID=AID
    FOR UPDATE;

    IF AValue != var1 THEN
    UPDATE SomeTable SET SomeField = AValue WHERE ID=AID;
    END IF;
    END;

    Данные в 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. Назначение и поведение у такого запроса то же, что у псевдообновления, приведенного выше


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

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


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


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

    Спасибо за внимание.
    28 ноя 03, 09:58    [437525]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Я и ёжик
    Guest
    2 Zaxx
    автор писал:
    Вот и у вас так. Блокировать умеет - значит блокировочник.

    Вы будете смеятся, но это действительно так.
    Классический, т.е. ТЕОРИТИЧЕСКИЙ версионник НЕ ИСПОЛЬЗУЕТ блокировок ВООБЩЕ. Каждая транзакция работает со своей версией данных, конфликты решаются при завершении транзакции. Но поскольку откат транзакций дело достаточно дорогое, зачастую дешевле предотвратить конфликты чем разбираться с ними позже. Поэтому в Oracle пошли на создание гибридной схемы, с постановкой блокировок на изменяемые записи, т.е. внесение элементов блокировочника и это оказалось достаточно удачным решением.
    В InterBase наскольяко я незнаю:) та же проблема решается путем разрешения только одной незакомиченной версии данных, т.е. транзакция пытающаяся создать еще одну новую версию получает отлуп, эффект похожий на наличие блокировки и в их терминах вроде даже называется Deadlock-ом (наряду с реальной ситуацией deadlock-а), но реально блокировки(как специального объекта базы данных) там нет.
    На русском к сожалению книг по Concurrency control я не видел, но в сети вроде можно накопать некоторые классические труды типа "Concurrency control and recovery in database systems." Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman на языке оригинала, куда и отсылаю если появится желание покопаться в теории.
    28 ноя 03, 10:55    [437644]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    >> ...с полным правом заявляйте в форуме, что Oracle ведёт себя как однопользовательская СУБД.
    >Сбавьте тон и перечитатйте мои посты - я такого нигде не заявлял.

    Это продолжение вашей логики "Блокировки есть - значит блокировочник".
    28 ноя 03, 11:07    [437670]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    ASCRUS
    Member

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

    Так кто Вам мешает select for update перенести в блок условия ? Конструкция select for update как раз и служит тем самым инструментом для проектировщика, позволяющим вручную заблокировать нужные записи, чтобы быть уверенным, что в пределах транзакции они не изменились. Например у меня при том же расчете ЕСН в зарплате оператором select for update блокируются на изменение записи многих таблиц, которые участвуют внутри довольно большой ХП расчета ЕСН. Опять же, если бы к блокируемым таблицам в качестве требования выдвигались условия, что они не могут иметь долгих блокировок, то и методы обработки информации были бы другими и уже выгоднее было бы например воспользоваться временными таблицами. Так что считаю, что все зависит не от СУБД, а проектировщика.

    P.S. Все это IMHO, Oracle не знаю, работаю на WatcomSQL ASA, которая является блокировочником, хотя по семантике WatcomSQL очень близок к PLSQL, естественно многое в них отрабатывает по разному.
    28 ноя 03, 11:13    [437685]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Я и ёжик
    Guest
    2 Aston

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


    Вы ошибаетесь в том , что в этом случае нужна S-блокировка, как видно
    из написания FOR UPDATE, это всетаки случай наложения блокировки для последующих изменений, если тут накладывать S-блокировку мы будем получать классический DEADLOCK.
    Привожу пример:
    1) Транзакция T1 выдает select for update на строку Y, и ставит по вашему мнению достаточную S-блокировку.
    2) Транзакция T2 выдает select for update на ту же строку Y, и ставит S-блокировку, что возможно S блокирповки совместимы. Имеем две S блокировки на строке Y, допустим S1,S2.
    3) T1 пытается сделать Update строки Y, для этого ей надо наложить X блокировку, но этого она сделать не может из за наличия блокировки S2.
    T1 вподает в ожидание пока T2 снимет S2.
    4) T2 пытается сделать Update строки Y, для этого ей надо наложить X блокировку, но этого она сделать не может из за наличия блокировки S1.
    T2 вподает в ожидание пока T1 снимет S1.
    5) Имеем классический Deadlock

    FOR UPDATE в Oracle используется для предотвращения эффекта "потерянных изменений" на уровне изоляции Read Comitted, и для "упорядочевания" транзакций на уровне изоляции Serialize ( во избежание эффектов типа Write Skew), гы... кстати, интересно зачем его назвали Serialize если он реально транзакци не упорядочивает?

    Строчная S-блокировка, конечно могла бы в Oracle пригодится при некоторых специфических случаях работы и наличии требования обеспечить пессимистическую стратегию блокирования, но никак не вместо X-блокировки в SELECT FOR UPDATE. А пока юзайте dbms_lock в таких случаях.
    28 ноя 03, 11:27    [437723]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Zaxx
    Guest
    2 Ёжик

    >Классический, т.е. ТЕОРИТИЧЕСКИЙ версионник НЕ ИСПОЛЬЗУЕТ блокировок ВООБЩЕ

    Приведите пример такой СУБД. Хотя-бы одну...

    >Каждая транзакция работает со своей версией данных, конфликты решаются при завершении транзакции.

    Где вы такое видели ? В какой СУБД ?

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

    Это и есть блокировка. Точно так-же как и в оракле. Обновить запись может только один. И неважно как они это назвали. Только в оракле второй обычно ждёт, а в интербейзе отваливается.

    >эффект похожий на наличие блокировки и в их терминах вроде даже называется Deadlock-ом

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

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

    Там есть Transaction Inventory Page (TIP) и у каждой версии записи есть идентификатор транзации.
    28 ноя 03, 11:49    [437804]     Ответить | Цитировать Сообщить модератору
     Re: Размер БД 10 Gb  [new]
    Я и ёжик
    Guest
    2 Zaxx
    автор писал:
    >Где вы такое видели ? В какой СУБД ?

    Один источник я вам уже приводил: "Concurrency control and recovery in database systems." Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman.
    Существует достаточно большой список подобных работ, но не на русском :(, посмотрите например у Дейта, он листа на три ссылок наставил.
    Тут ёжик очень просил обратить Ваше внимание на слово "Теоритический".
    Люди производят исследовательские изыскания, пишут умные книжки,
    результатами их работ уже пользуются другие.
    В теории БД и "Concurrency control" описано несколько механизмов обеспечения целостности базы данных при работе паралельных транзакций, для которых доказана их верность. Основные два из них это использование механизма блокировок и механизм многоверсионности, кроме того доказывается и возможность использования гибридных схем.

    Пример СУБД работающей по классическому механизму многоверсионнасти я привести не могу, не встречал такой, думаю как раз потому что это достаточно затратный механизм в случае конфликтов, но и отрицать существование таких СУБД не буду.

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

    Это и есть блокировка. Точно так-же как и в оракле.

    Нет, не есть и не то же самое.
    В Oracle блокировка это физический объект, хранящийся в заголовке блока данных, и наложен он может быть не только при update но и при select for update т.е. без всяких изменений данных.
    В InterBase это невозможность создать новую версию, эффект в принципе тот же, но механизмы то разные. Вот и ножиком можно человека убить и из пистолета застрелить, но вы же не будете утверждать, что пистолет и нож одно и то же?
    Правда про InterBase спорит не буду, не знаю я его и механизмы работы представляю очень поверхностно.
    28 ноя 03, 12:28    [437908]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить