Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 уровень изолированности транзакций  [new]
stepancheg
Member [заблокирован]

Откуда:
Сообщений: 139
Подскажите, please, как в SQL*Plus-е посмотреть текущий для данной сессии уровень изолированности транзакций.
10 сен 07, 14:22    [4643746]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
SQL> select * from dual where 1=0 for update;

DUMMY
-----

SQL> select to_char(flag,'XXXXXXXX') from v$transaction;

TO_CHAR(FLAG,'XXXXXXXX')
------------------------
     1603

SQL> rollback;

Rollback complete

SQL> alter session set isolation_level=serializable;

Session altered

SQL> select to_char(flag,'XXXXXXXX') from v$transaction;

TO_CHAR(FLAG,'XXXXXXXX')
------------------------
 10001603

SQL> 


Господа форумяне, у меня тоже есть вопрос: а как установить сессионный уровень изоляции READ COMMITED?!
Никогда раньше не задумывался, а тут обнаружил засаду:
В концептах пишут, что
alter session set isolation level read commited
Не работает, ибо "missing equal sign"
В синтаксисе alter session говорят, что
alter session set isolation level = read commited
ругается, что {SERIALIZABLE | READ COMMITED} - парсер не справляется с пробелом.
Воооот :)
10 сен 07, 15:03    [4644088]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Maxim Demenko
Member

Откуда: Munich, Germany
Сообщений: 940
SQL> alter session set isolation_level = read committed;

Best regards

Maxim
PS Или это была шутка? тогда сорри.
10 сен 07, 15:08    [4644134]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Beretta
Member

Откуда: Киев
Сообщений: 319
andrey_anonymous
SQL> select * from dual where 1=0 for update;

DUMMY
-----

SQL> select to_char(flag,'XXXXXXXX') from v$transaction;

TO_CHAR(FLAG,'XXXXXXXX')
------------------------
     1603

SQL> rollback;

Rollback complete

SQL> alter session set isolation_level=serializable;

Session altered

SQL> select to_char(flag,'XXXXXXXX') from v$transaction;

TO_CHAR(FLAG,'XXXXXXXX')
------------------------
 10001603

SQL> 


Господа форумяне, у меня тоже есть вопрос: а как установить сессионный уровень изоляции READ COMMITED?!
Никогда раньше не задумывался, а тут обнаружил засаду:
В концептах пишут, что
alter session set isolation level read commited
Не работает, ибо "missing equal sign"
В синтаксисе alter session говорят, что
alter session set isolation level = read commited
ругается, что {SERIALIZABLE | READ COMMITED} - парсер не справляется с пробелом.
Воооот :)


:-) Буковка одна выпущена из виду.
10 сен 07, 15:10    [4644148]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Maxim Demenko
Или это была шутка? тогда сорри.

Нет, это у меня был ступор:
SQL> alter session set isolation_level = read committed;

Session altered

SQL> alter session set isolation_level = read commited;

alter session set isolation_level = read commited

ORA-02183: valid options: ISOLATION_LEVEL { SERIALIZABLE | READ COMMITTED }

SQL>
Спасибо, Максим!
10 сен 07, 15:10    [4644152]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Подскажите а как "read uncommitted" установить?
ANSI уровень изоляции и все такое.
10 сен 07, 18:09    [4645395]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Ionah
Подскажите а как "read uncommitted" установить?
ANSI уровень изоляции и все такое.

Никак.
Oracle не поддерживает грязное чтение.
10 сен 07, 18:11    [4645410]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Сорри за степп, не сдержался.
10 сен 07, 18:13    [4645419]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
Ionah
Подскажите а как "read uncommitted" установить?
ANSI уровень изоляции и все такое.

Пяць ! Могешь !
10 сен 07, 18:19    [4645445]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Кстати, а на первоначальный вопрос уже кто-то ответил?
10 сен 07, 18:23    [4645463]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Кстати, очень меня интригует задача, которая привела к такому вопросу,
т.к. насколько я понимаю, ORACLE не особо заточен под уровни изоляции,
отличные от read committed.

Т.е. использование других уровней изоляции скорее очень редкое исключение:
- read uncommitted нет вообще
- repeatable read возможен только с использованием костылька "for update" для каждого repeatable read чтения
- serializable плюется дополнительным исключением "can't serialize"

И зачем понадобилось узнавать текущий уровень изоляции, ума не приложу
10 сен 07, 18:35    [4645520]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Ionah
Кстати, очень меня интригует задача, которая привела к такому вопросу,
т.к. насколько я понимаю, ORACLE не особо заточен под уровни изоляции,
отличные от read committed.

Из чего сделан такой вывод?
10 сен 07, 18:36    [4645527]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Timm
Ionah
Кстати, очень меня интригует задача, которая привела к такому вопросу,
т.к. насколько я понимаю, ORACLE не особо заточен под уровни изоляции,
отличные от read committed.

Из чего сделан такой вывод?


Ну... кажется мне так... убеждение у меня такое есть...

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

Типа если нужен repeatable read, то нельзя просто сказать

alter session set isolation level = repeatable read

а нужно для каждого select, если нужен repeatable read, указывать for update.

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

А чтобы заставить serializable работать, по хорошему, нужно в приложение втыкать обработчики can't serialize, со сложной логикой обработки таких исключений, типа повторителей транзакций в случае такой ошибки.

Т.е. например, в отличие от MSSQL, где deadlocks (результат любого уровня изоляции, кроме read uncommitted, т.к. блокировочник) все-равно нужно обрабатывать и где включить serializable ничего не стоит - просто станет больше ошибок deadlock и повторов транзакций.
10 сен 07, 19:03    [4645655]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8131
Ionah
Типа если нужен repeatable read, то нельзя просто сказать

alter session set isolation level = repeatable read
Можно просто сказать
SET TRANSACTION READ ONLY
10 сен 07, 20:10    [4645844]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Привет
Ionah
Т.е. например, в отличие от MSSQL, где deadlocks (результат любого уровня изоляции, кроме read uncommitted, т.к. блокировочник) все-равно нужно обрабатывать и где включить serializable ничего не стоит - просто станет больше ошибок deadlock и повторов транзакций.
Тема длинная, и на раз не раскалывается.

ИМХА (которой я тут уже всех задолбал) заключается в том, что, по-видимому, разработчики ядра RDBMS сделали сознательный выбор в пользу максимального уменьшения препятствий для работы многопользовательского OLTP. Возможно, это было результатом тогдашней оценки рынка, на который был ориентирован продукт.

Отсюда взялся версионник и неблокирующие чтения, которые на версионнике - как два байте переслать. При том, что данные некоторым документированным образом согласованы. А на блокировочнике альтернатива - dirty read и никакой гарантии согласованности. Или, как вы отметили, ожидания, deadlock'и и прочие прелести.

просто станет больше... deadlock ... - на самом деле == непредсказуемые тормоза во времени отклика. Обработка каждого deadlock'а включает timeout и собственно время обработки. А ожидания от блокирующих чтений - та еще песня :-).

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

Если же задуматься об устранении самОй причины deadlock'ов, то на Oracle этого добиться проще (заточен так).

Ммм... бесплатный сыр он да... Так что за все приходится платить - я видел лет 5 назад документ (распространявшийся, кстати, Oracle'ом) с независимым сравнением нескольких БД. Там было много позиций (в частности скорость выполнения SELECT'ов)... Единственный параметр, по которому Oracle на порядки превосходил все остальные (DB2 на mainframe, MSSQL, Informix) - concurrency. В остальных параметрах уступал главному конкуренту DB2, но выглядел достаточно достойно (MSSQL в той сводной табличке вообще был "мальчиком для битья" ;-)).

Всего
--
Disclaimer: Opinions are of my own and not necessar[-il]y
10 сен 07, 20:55    [4645946]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Ionah
Timm
Ionah
Кстати, очень меня интригует задача, которая привела к такому вопросу,
т.к. насколько я понимаю, ORACLE не особо заточен под уровни изоляции,
отличные от read committed.

Из чего сделан такой вывод?


Ну... кажется мне так... убеждение у меня такое есть...

Низнаю что на это ответить. Я к примеру своим убеждениям верю не всегда (в особенности когда для них нет даже примитивных предпосылок).
10 сен 07, 20:56    [4645951]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Так, если кто вдруг за десять лет не успел прочитать ;)
Перевод не очень, в табличках есть ошибки. Лучше оригинал.

Data Base Management Systems: #2/96 Критика уровней изолированности в стандарте ANSI SQL Х. Беренсон, Ф. Бернштейн, Д. Грэй, Д. Мелтон, Э. О'Нил, П. О'Нил
10 сен 07, 21:55    [4646068]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
Ааз
аналитический отдел нашего мозга склонен думать последовательно
:-)
10 сен 07, 23:25    [4646252]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Владимир Бегун
Ааз
аналитический отдел нашего мозга склонен думать последовательно
:-)
Я рад, что тебе понравилось :-)

Всего
11 сен 07, 00:06    [4646325]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Ааз
Привет
Ionah
Т.е. например, в отличие от MSSQL, где deadlocks (результат любого уровня изоляции, кроме read uncommitted, т.к. блокировочник) все-равно нужно обрабатывать и где включить serializable ничего не стоит - просто станет больше ошибок deadlock и повторов транзакций.
Тема длинная, и на раз не раскалывается.

ИМХА (которой я тут уже всех задолбал) заключается в том, что, по-видимому, разработчики ядра RDBMS сделали сознательный выбор в пользу максимального уменьшения препятствий для работы многопользовательского OLTP. Возможно, это было результатом тогдашней оценки рынка, на который был ориентирован продукт.

Отсюда взялся версионник и неблокирующие чтения, которые на версионнике - как два байте переслать. При том, что данные некоторым документированным образом согласованы. А на блокировочнике альтернатива - dirty read и никакой гарантии согласованности. Или, как вы отметили, ожидания, deadlock'и и прочие прелести.

просто станет больше... deadlock ... - на самом деле == непредсказуемые тормоза во времени отклика. Обработка каждого deadlock'а включает timeout и собственно время обработки. А ожидания от блокирующих чтений - та еще песня :-).

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

Если же задуматься об устранении самОй причины deadlock'ов, то на Oracle этого добиться проще (заточен так).

Ммм... бесплатный сыр он да... Так что за все приходится платить - я видел лет 5 назад документ (распространявшийся, кстати, Oracle'ом) с независимым сравнением нескольких БД. Там было много позиций (в частности скорость выполнения SELECT'ов)... Единственный параметр, по которому Oracle на порядки превосходил все остальные (DB2 на mainframe, MSSQL, Informix) - concurrency. В остальных параметрах уступал главному конкуренту DB2, но выглядел достаточно достойно (MSSQL в той сводной табличке вообще был "мальчиком для битья" ;-)).

Всего
--
Disclaimer: Opinions are of my own and not necessar[-il]y


Могло показаться что это была критика ORACLE. На самом деле нет! Хотя в самой малой мере да :)
Мастдай уже заепп пренебрежением стандартами в других областях, а вот в случае MSSQL, на удивление,
пошел очень близко к ANSI, чем несказанно порадовал, в отличие от ORACLE,
который, к сожалению, сам себе стандарт и этим слегка дискредитирует направление.

Что касается разрешения конкуренции, неблокирующих чтений и версионника,
я сам в глубоком экстазе от подхода ORACLE - изоляция read uncommitted
просто не поддерживается, т.к. от нее нет нихрена никакого выигрыша.
Изоляция уровнем выше (read committed) просто не стоит ни на копейку больше!

Абсолютно согласен что в ORACLE можно забыть про deadlocks
(главное помнить индексировать внешние ключи, как считает дядя Кайт)

Но совершенно не согласен что блокировочник более понятен разработчику - вот мысли по теме тынц

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

Может это компенсируется тем, что такие системы "масса разработчиков" на MSSQL реализуют не так часто как на ORACLE.
А чаще реализует более-менее однопользовательские / настольные, где не нужно сильно париться про конкуренцию.
Хотя блокировочник MSSQL частенько вылезает боком даже в однопользовательских системах.
11 сен 07, 10:40    [4647145]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Змей Равниныч
Member

Откуда: Из тридевятого царства
Сообщений: 284
Ionah
...Изоляция уровнем выше (read committed) просто не стоит ни на копейку больше!

Абсолютно согласен что в ORACLE можно забыть про deadlocks
(главное помнить индексировать внешние ключи, как считает дядя Кайт)...
Наивный юноша...
11 сен 07, 12:27    [4648265]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

Откуда: Новосибирск
Сообщений: 290
Змей Равниныч
Ionah
...Изоляция уровнем выше (read committed) просто не стоит ни на копейку больше!

Абсолютно согласен что в ORACLE можно забыть про deadlocks
(главное помнить индексировать внешние ключи, как считает дядя Кайт)...
Наивный юноша...


Оставьте свой менторский тон, Старик Хоттабыч,
и снизойдите до дискуссии, мы Вас все очень просим...
11 сен 07, 13:04    [4648631]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Ionah
Змей Равниныч
Ionah
...Изоляция уровнем выше (read committed) просто не стоит ни на копейку больше!

Абсолютно согласен что в ORACLE можно забыть про deadlocks
(главное помнить индексировать внешние ключи, как считает дядя Кайт)...
Наивный юноша...


Оставьте свой менторский тон, Старик Хоттабыч,
и снизойдите до дискуссии, мы Вас все очень просим...

Зря ты так, зря.
Тебя не удивляет тот факт что 2 и более update/delete/insert/select for update либо 1 merge,
выполняемые одновременно в разных транзакциях, потенциально могут привести к дедлоку?
11 сен 07, 13:15    [4648734]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Ionah
снизойдите до дискуссии

Да не о чем тут дискутировать.
Поищите по форуму слово "deadlock" и будет Вам счастье.
11 сен 07, 13:17    [4648752]     Ответить | Цитировать Сообщить модератору
 Re: уровень изолированности транзакций  [new]
Ionah
Member

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

Если же говорить о нормальной ентерпрайз многопользовательской системе,
в которой не бывает ad-hoc update или merge и в которых каждый use-case,
который касается базы, известен и нормально спланирован, то, думаю,
дедлоки можно исключить из рассмотрения.
11 сен 07, 13:30    [4648875]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить