Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Система блокирования. Что на это ответят гуру?  [new]
nant
Guest
http://www.rsdn.ru/Forum/Message.aspx?mid=363428&only=1
25 авг 03, 15:17    [313803]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Gt_
Guest
Так вот при FOR UPDATE Oracle накладывает именно X блокировку, тоесть самую сильную и забирает объект в монопольное пользование, а значит все читающие транзакции идут лесом.

автор ламер, или студент 1-го курса.
25 авг 03, 15:30    [313833]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
.dba
Member

Откуда: Киев->Мюнхен
Сообщений: 2331
красочно написано, но в техническом плане фигня полная.

Все выводы строятся на ошибочной предпосылке, на которую уже указал Gt_
25 авг 03, 15:35    [313846]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
nant
Guest
2dba
а можно доказательство в студию? ))
25 авг 03, 15:47    [313878]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Sir
Member

Откуда:
Сообщений: 291
Ну, прямо так фигня полная. :))
Если из статьи убрать явные ошибки(типа той, на которую указал Gt_) ,
то в остальном там довольно неплохо описано,
что у Оракла есть проблемы в блокировках для OLTP систем.

Если рассмотреть тот же пример с SELECT ... FOR UPDATE,
то две сессии не могут одновременно наложить shared lock на одну и ту же запись.
А в OLTP это иногда очень хочется. :))

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

И
Естественно, ни одна из вышеупомянутых проблем не является непреодолимым препятствем и в ловких руках практически любой сервер из лидеров индустрии, на практически любой задаче способен работать с требуемой роизводительностью.
25 авг 03, 16:01    [313913]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
25 авг 03, 16:04    [313922]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Я хотел сказать, сюда.

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
25 авг 03, 16:05    [313925]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Gt_
Guest

SQLWKS> select id from TEST where id=2 for update ;
ID
----------

2
1 row selected.

берем вторую транзакцию :

SQLWKS> select id from TEST where id=2 for update nowait ;
ORA-00054: resource busy and acquire with NOWAIT specified
SQLWKS>
SQLWKS>
SQLWKS> select id from TEST where id=2 ;
ID
----------

2
1 row selected.


2 Sir

1. у оракла нет проблем с OLTP, см tpc.org
2. за это и платят ораклу в хз раз больше - чтоб "ловких рукчек практически" небыло. :)
25 авг 03, 16:09    [313936]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
softy
Member

Откуда: from Russia
Сообщений: 5911
Теория блокировок сформировалась еще в конце семидесятых но Оракл так и не реализовал хотя бы что-то близкое. Как версионник Оракл очень не плох и в Read Only транзакциях это чУдным образом работает, но как только транзакция становится R/W идиллическая картина нарушается. Надо сказать, что смешанный подход Оракла здесь смотрится предпочтительней чем чисто версионный, но хороший блокировочник (MSSQL, BD2) справляется с этим еще лучше.

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


Всё таки странная штука Oracle - хуже всех соответствует стандартам, имеет самый плохой блокировочник.

Но как ни странно почему-то самая лучшая РСУБД в мире.

to nant:

Какие могут быть доказательста?
Нужно открыть только Oracle Concepts и найти хотя-бы таблицу "Summary of Table Locks". В которой чётко видно, что: SELECT FOR UPDATE накладывает не X-блокировку, а RS- блокировку.
А X-блокировку накладывает только LOCK TABLE table IN EXCLUSIVE MODE.

Честно говоря - просто провакация против Oracle.


Row Share Table Locks (RS) A row share table lock (also sometimes called a
subshare
table lock, SS) indicates that the transaction holding the lock on the table has
locked
rows in the table and intends to update them. A row share table lock is
automatically acquired for a table when one of the following SQL statements is
executed:
SELECT . . . FROM table . . . FOR UPDATE OF . . . ;
LOCK TABLE table IN ROW SHARE MODE;
A row share table lock is the least restrictive mode of table lock, offering the
highest
degree of concurrency for a table.
Permitted Operations: A row share table lock held by a transaction allows other
transactions to query, insert, update, delete, or lock rows concurrently in the same
table. Therefore, other transactions can obtain simultaneous row share, row
exclusive, share, and share row exclusive table locks for the same table.
Prohibited Operations: A row share table lock held by a transaction prevents other
transactions from exclusive write access to the same table using only the following
statement:
LOCK TABLE table IN EXCLUSIVE MODE;
25 авг 03, 16:10    [313941]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3662
и забирает объект в монопольное пользование, а значит все читающие транзакции идут лесом.

бред.

забирает объект в монопольное пользование

Хоть бы сказал какой объект. Забирает в монопольное пользование только выбранные строки.

а значит все читающие транзакции идут лесом

без комментариев ...

Чтение в Оракл никогда не блокируется записью
Запись в Оракл никогдане плогируется стением
Оракл никогда не делает эскалацию блокировок

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21cnsis.htm#3152
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c01_02intro.htm#46633
25 авг 03, 16:15    [313953]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
.dba
Member

Откуда: Киев->Мюнхен
Сообщений: 2331
кажется уже все доказательства приведены: Gt_ - практическое, у softbuilder@inbox.ru теоретическое (т.е. из доки)

2 Sir

>Ну, прямо так фигня полная. :))
>Если из статьи убрать явные ошибки(типа той, на которую указал Gt_) ,

на этой ошибке строится вся статья (также пример с parent-child автор не удосужился проверить, но зато много нафантазировал)

>то в остальном там довольно неплохо описано,
>что у Оракла есть проблемы в блокировках для OLTP систем.

какие проблемы?

>Если рассмотреть тот же пример с SELECT ... FOR UPDATE,
>то две сессии не могут одновременно наложить shared lock на одну и ту же
>запись.
>А в OLTP это иногда очень хочется. :))

объясните на примере чего вы хотите.

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

а это вообще риторика - что это за термин "смотрится"???
25 авг 03, 16:20    [313961]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Sir
Member

Откуда:
Сообщений: 291
To Gt_

Я об этом и говорю.

Допустим необходимо следующее:
Нужно, чтобы на протяжении тразакции не изменялась строка в таблице.
Как это сделать.
Ну, например, SELECT ... FOR UPDATE
И дальше делаем все, что надо в транзакции.

Теперь есть точно такая же вторая сессия.
Ей тоже надо, чтобы не менялась эта же строка.
Что ей делать?
Если SELECT ... FOR UPDATE, то тогда эта сессия будет ждать первую.
Или вываливаться по ошибке.
Не очень хорошо.

Иногда нужен именно shared lock.

Простой SELECT, естественно, работает. Это авторы статьи ошиблись.
25 авг 03, 16:20    [313962]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3662
to Sir

Если рассмотреть тот же пример с SELECT ... FOR UPDATE,
то две сессии не могут одновременно наложить shared lock на одну и ту же запись. А в OLTP это иногда очень хочется. :))


А можно пример когда это может хотеться?
25 авг 03, 16:24    [313973]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
.dba
Member

Откуда: Киев->Мюнхен
Сообщений: 2331
>Допустим необходимо следующее:

а что ms sql такую ситуацию отрабатывает?
25 авг 03, 16:28    [313985]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3662
Нужно, чтобы на протяжении тразакции не изменялась строка в таблице.
Как это сделать.


А как же read consistency или режим serializable? В Оракл вообще нет необходимости что то блокировать чтобы получить read consistent view of data.
25 авг 03, 16:30    [313991]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Sir
Member

Откуда:
Сообщений: 291
To Violina

Да, примеров, куча.
Первое, что пришло в голову.

Ну, например, есть таблица валют. У валюты есть состяние актвивна/неактивна.
Я хочу втсавить докуменет, у котрого есть ссылка на валюту.
Хотелось бы перед вставкой проверить, что у валюты состояние активно.

To .dba
Насчет, ms sql не знаю (наверное, да)
А Informix - без проблем.
25 авг 03, 16:33    [314001]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Gt_
Guest
2 Sir:

1. вываливатся можно по NOWAIT или таймауту
2. а в чем проблема вываливатся по ORA ? ... невижу

вот то что оракл можно стандартными средствами привести в неконстстентное состаение (не сработают constraints) ... да вот это ИМХО проблема.
25 авг 03, 16:35    [314007]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
softy
Member

Откуда: from Russia
Сообщений: 5911
to Sir:

А ты не противоречишь сам себе?

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


Как ты себе это представляешь, что бы разные транзакции были одновременно удовлетворены и выполнены условия блокировки?
25 авг 03, 16:35    [314008]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
.dba
Member

Откуда: Киев->Мюнхен
Сообщений: 2331
>To .dba
>Насчет, ms sql не знаю (наверное, да)
>А Informix - без проблем.

дайте, пожалуйста, код для Информикса.
25 авг 03, 16:39    [314021]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Sir
Member

Откуда:
Сообщений: 291
To .dba

В информиксе примерно так:

BEGIN WORK
--SELECT без FOR UPDATE накладывает shared lock
SELECT status INTO var FROM currency WHERE code = ?
IF var = 'A' THEN
INSERT INTO document ....
END IF
COMMIT

Две транзакции не блокируют друг друга и обе обеспечывают
неизменность записи в таблице currency.
25 авг 03, 16:43    [314037]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3662
to Sir

Теперь есть точно такая же вторая сессия.
Ей тоже надо, чтобы не менялась эта же строка.
Что ей делать?
Если SELECT ... FOR UPDATE, то тогда эта сессия будет ждать первую.
Или вываливаться по ошибке.
Не очень хорошо.


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

Хотелось бы перед вставкой проверить, что у валюты состояние активно.

То есть заблокировать валюту на время транзакции по вставке документа чтобы другие сессии не могли за это время изменить ее статус?

to Gt_

вот то что оракл можно стандартными средствами привести в неконстстентное состаение (не сработают constraints)

что имеется ввиду?
25 авг 03, 16:45    [314042]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Merle
Guest
Забодали, в попыхах просто писал: http://rsdn.ru/Forum/?mid=363621

----------------------------
А ты не противоречишь сам себе?

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

Как ты себе это представляешь, что бы разные транзакции были одновременно удовлетворены и выполнены условия блокировки?
----------------------------
И эти люди запрещают мне ковыряться вносу?

Идем читать, что такое Share блокировки и обратно на первый курс.

Любителям ссылаться на tpc (я сам такой) задумайтесь, почему ДЕВЯТАЯ версия Оракла почи в ДВА раза проигрывала в производительности MSSQL и DB2.
Чего они там сейчас наворотили - я не знаю.

С дальнейшими КОНСТРУКТИВНЫМИ обсуждениями велкам на http://www.rsdn.ru, самому разобраться интересно...
Тока без называния друг-друга ламерами и первокурсниками, чуть больше такта plz ...
25 авг 03, 16:48    [314051]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Sir
Member

Откуда:
Сообщений: 291
To Violina

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

Реального апдейта не последует. Надо убедится в непротиворечивости
вставки документа.

То есть заблокировать валюту на время транзакции по вставке документа чтобы другие сессии не могли за это время изменить ее статус?

Да
25 авг 03, 16:48    [314052]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3662
SELECT без FOR UPDATE накладывает shared lock

Об этом писал Том Кайт и о том что есть такая привычка у "других" СУБДшников, накладывать блокировки простым селектом:)

А как долго действует такая блокировка? Как ее снимать? Не уже ли после простого селекта нужно делать commit/rollback?
25 авг 03, 16:50    [314057]     Ответить | Цитировать Сообщить модератору
 Re: Система блокирования. Что на это ответят гуру?  [new]
softy
Member

Откуда: from Russia
Сообщений: 5911
to Sir:

Две транзакции не блокируют друг друга и обе обеспечывают
неизменность записи в таблице currency.


В Oracle что-бы прочитать дынные не нужно накладывать блокировку.
Есть понятие активного набора на момент обработки курсора, есть понятие непротиворечивого чтения, реализуемого за счёт сегментов отката.

Сегменты отката - это фирменное средство Oracle. Видимо в других СУБД, что-бы произвести непротиворечивое чтение нужно накладывать блокировку.


В Oracle в этом случае блокировка не делается, а результат достигается тот-же.

Это понятно?
25 авг 03, 16:52    [314062]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Oracle Ответить