Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9   вперед  Ctrl      все
 Re: Informix displaces Oracle at China Telcom  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30233
вот так возникают мифы о блокировочных версионниках...
стоило только "разблокировать" конфликты R-W в Read Committed - и уже сразу "версионник".

см. тут
http://informix-technology.blogspot.com/2007/02/cheetah-spot-by-spot-last-committed.html

Some of you with knowledge from other RDBMS like Oracle or Postgres may be wondering what's new about this... Well, historically there have been two types of RDBMS: The versioning (each transaction gets a "version" number that marks all the data it changes) and the non-versioning. The versioning RDBMSs have always this sort of isolation levels because each transaction sees the "current image" of the Database. But the non-versioning RDBMS usually didn't implement this. They have more light-weight reading primitives that read the data directly (not the before images marked with earlier versions stamps) and this causes the locking conflicts.
Also, some versioning RDBMS don't support the ANSI UNCOMMITTED READ, because the way they read doesn't allow it.

So, it's has been a kind of trade-off. But currently, most of the non-versioning databases implement this kind of COMMITTED isolation without blocking the readers.
22 дек 08, 21:06    [6605739]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

Никто же не запрешает пользоваться стандартным infromix READ COMMITED
и другими более сильными уровнями.

не говорите ерунды, LAST COMMITTED запрещает, он каждый раз будет получать другое значение одной и той же записи т.е. даже неповторяемое чтение уже нарушает. к стате говоря формально LAST COMMITTED не нарушает RC, он слабее того RC, что сейчас используются в блокировочниках.

Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?

Yo.!

onstat-

Поэтому логично что oracle RC тоже слабее informix RC .

не смешите мои тапочки, оракловый RC получает согласованое чтение на момент запуска стейтмента, RC информикса (пофигу ест) получает кашу из записей которые были на момент старта,

[/quot]
Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

Yo.!

записи которые появились по ходу выполнения запрса, он не прочтет записи, что вроде как были в момент старта, но были удалены раньше и самое замечательное это НЕСКОЛЬКО РАЗ одни и той же записи (запись после чтения RC-читателя может быть другой перемещена после обновления конкурентным писателем).

с опцией LAST COMMITTED каша лишь усугубляется и мне собственно совершенно не понятно чего в этой каше вы увидили больше похожего на версионник или


Если Вам нужен RR так и пользуйтесь RR зачем сюда притягивать за уши использование
RС , который вернет некий набор записей консистентный на момент запуска,
Меня лично и многи других консистентнось на момент запуска запроса мало интересует,
меня интересует
консистентность записи на момент fetch это должно быть текущее реальное значение,
а не какоето там реальное в прошлом и с неизвесным значением в момент доступа( fetch ).
Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.


Yo.!

вы уже не настаиваете на появлении версионности в IDS ?


В вашей понимании нет.
22 дек 08, 21:10    [6605744]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
MasterZiv

Что значит "RC, что сейчас используются в блокировочниках" ?
Уровни изоляции прописаны в стандарте ANSI.

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

MasterZiv

А откуда вы знаете, может он тоже на время начала стейтмента или транзакции
берёт ? я вот не читал про это в топике или где-то ещё, это утверждение
ваше на каких-то более глубоких знаниях основано?

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

MasterZiv

Ну, даже допустим это так. Но это ещё не говорит, что LAST COMMITTED
ниже READ COMMITTED. READ COMMITTED тоже читает неизвесно какой транзакцией
закоммиченые данные, и повторно может их не прочитать.

ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED потому как выдает более несогласованое чтение, чем RC типичного блокировочника. если мы с такой опцией расчитываем какие-нибудь бонусы расчитываем у нас больше ерунды получится, чем при обычном RC. посути если грязное чтение при блокируемой записи берет грязное значение, то LAST COMMITTED в том же случае возьмет последнее, закомиченное, а версионник будет реконструировать то значение какое было на момент старта транзакции/стейтмента. и НИКОГДА не прочтет одну и ту же запись двадцать пять раз.
22 дек 08, 21:33    [6605790]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?

вы скзали, что опция LC "в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам". полная ерунда - эта опция может быть использована только с IL Read committed и только с ним. больше ни с каким уровнем. да и дает оно не больше свободы, а больше рассогласованости в наборе.

onstat-

Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

признаю, но блокировочные уровни дающие согласованный набор требуют залочить по бол базы и часто не применимы в реальных олтп. в результате приходится проэктировать БД так чтоб можно было получать согласованные данные на уровне RC, типа таких как сумма "закрытия рабочего дня" + "проводки текущего дня". мне

onstat-

Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.

не правада, ни стандарт ни RC в субд MSSQL такого не требуют/гарантируют. MSSQL на RC может прочесть залоченую эксклюзивно запись взяв значение из индекса (если конкурентная транзакция изменило значение строки на то же значение, что и было до этого)
22 дек 08, 21:55    [6605833]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
kdv
...Well, historically there have been two types of RDBMS...

Исторически было только 2 типа: Oracle, который сделал все правильно с саого начала и все остальные (IBM/Sybase=>ANSI), сделавшие это неправильно и десятилетиями отстаивавшие совершенно абсурдый механизм реализации уровней изоляции с помощью блокировок, пока не признали что были неправы (teоретически в 1995 -> Critique of ANSI isolation levels статья, а практически в MSSQL 2005 snapshot isolation).
Почитайте биографию Jim-a Gray (его печальный конец мне кажется связан с
этим, так как он и был осовным атором и исправителем ошибки IMHO)
22 дек 08, 23:02    [6605959]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
MasterZiv

к стате LAST COMMITTED из феноменов банальный LOST UPDATE добавляет ко всем имеющимся в RC феноменам.
23 дек 08, 10:18    [6606609]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?

вы скзали, что опция LC "в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам". полная ерунда - эта опция может быть использована только с IL Read committed и только с ним. больше ни с каким уровнем. да и дает оно не больше свободы, а больше рассогласованости в наборе.


Имелось ввиду возможность изменять уровень изолированности на лету , по ходу транзакции через
set isolation

Одновременно использовать разные уровни внутри одного запроса конечно же нельзя.

Yo.!

onstat-

Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

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


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

Потому как:
Yo.!

типа таких как сумма "закрытия рабочего дня" + "проводки текущего дня". мне

Еще раз повторяю:
onstat-

Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

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


Yo.!

onstat-

Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.

не правада, ни стандарт ни RC в субд MSSQL такого не требуют/гарантируют. MSSQL на RC может прочесть залоченую эксклюзивно запись взяв значение из индекса (если конкурентная транзакция изменило значение строки на то же значение, что и было до этого)


согласен , что никто этого не гарантирует, но IMHO так было бы логичней.
23 дек 08, 10:22    [6606628]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Zhora
kdv
...Well, historically there have been two types of RDBMS...

Исторически было только 2 типа: Oracle, который сделал все правильно с саого начала и все остальные (IBM/Sybase=>ANSI), сделавшие это неправильно и десятилетиями отстаивавшие совершенно абсурдый механизм реализации уровней изоляции с помощью блокировок, пока не признали что были неправы (teоретически в 1995 -> Critique of ANSI isolation levels статья, а практически в MSSQL 2005 snapshot isolation).
Почитайте биографию Jim-a Gray (его печальный конец мне кажется связан с
этим, так как он и был осовным атором и исправителем ошибки IMHO)


Я не вижу логики в Ваших словах,
Все было правильно сделано изначально, а затем туда был добавлен неправильный DBMS_LOCK,
Может рассказать зачем испортили правильную систему?
23 дек 08, 10:27    [6606648]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

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

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

onstat-

Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

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

onstat-

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

не правда, максимум что есть у оракла - оптимизация с рестартом пишуших транзакций в случае изменения предикатов, но к подзапросам никакого отношения она не имеет, тем более логику не нарушается ни при каких условиях ни на одном из уровней.
23 дек 08, 10:54    [6606762]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

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

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

[/quote]


Вы хотите сказать что нафетчить из undo было бы правильнее?
Да будет быстрее, но логическою целостность я предсказывать боюсь.
А что обчно делают разаработчики oracle что бы не фетчить из undo? :)

Если конкуренция есть то она везде есть хоть это блокировочник, хоть версионник.

Yo.!

onstat-

Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

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

Ваша позиция понятна.


Yo.!

onstat-

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

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


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

ИМХО лучше ничего не делать на блокировке чем делать работу зря.
23 дек 08, 11:21    [6606899]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

> ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED
> потому как выдает более несогласованое чтение, чем RC типичного
> блокировочника.

Где ? Пример давайте.

Posted via ActualForum NNTP Server 1.4

23 дек 08, 11:36    [6606992]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

> к стате LAST COMMITTED из феноменов банальный LOST UPDATE добавляет ко
> всем имеющимся в RC феноменам.

LOST UPDATE как с READ COMMITED связан, а ?

Posted via ActualForum NNTP Server 1.4

23 дек 08, 11:38    [6607019]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

> Что значит "RC, что сейчас используются в блокировочниках" ?
> Уровни изоляции прописаны в стандарте ANSI.

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

Да. Но я имел в виду не это, а то, что никакого другого
RC не существует. То, что вы пишите "RC, что сейчас используются в
блокировочниках" - его не существует.


> ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED

Да, но там описаны уровни изоляции. Если вводите новые -- опишите, как
Грей с товарищами. Тогда будет разговор.

Posted via ActualForum NNTP Server 1.4

23 дек 08, 11:43    [6607056]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

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

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

onstat-
ИМХО лучше ничего не делать на блокировке чем делать работу зря.

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

2MasterZiv

стандарт RC лишь требует чтоб выданая запись была закомиченой и все, больше стандарт ничего не требует. все известные блокировочники берут на себя повышенные обязательства, хотя в полне действительно могли бы в соответствии со стандартом выдавать значения к примеру из вчерашнего бэкапа. поэтому стандарт и реализация в субд все же отличаются.
почитайте уже упомянутую тут критику уровней, там не менее уважаемые товарищи дали определения недостающих феноменов, я свои выдумывать ленюсь ...
их терминами RC иногда возможен лост апдейт, а RC c last_committed его гарантирует к стате не заслужено забыт skip_committed, опция из той же серии.
23 дек 08, 13:28    [6607868]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

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

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


Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.

Может кто то из Oracle Гуру прояснит сообществу, что же происходит на самом деле?


Yo.!

onstat-
ИМХО лучше ничего не делать на блокировке чем делать работу зря.

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

Еще раз напоминаю МС обсуждается в других темах.

Yo.!

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

Я немного поковырялся в логике работы oracle и думаю (ИМХО) пока коренным образом
не будет изменена работа с SCN & UNDO добавить новые уровни изолированности не представляется возможным. Основная проблема в том что он всю свою консистентность
счинает на начало запроса.
Другими словами его нужно блокировочником сделать ( считать консистентность по fetch).
23 дек 08, 13:47    [6608025]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
onstat-
меня интересует консистентность записи на момент fetch

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

onstat-
Полной уверенности у Вас нет, у меня тоже нет. Я все еще думаю, что консистентность разъедестя.

Признаться, не очень понял, о чем вы спорите.

В Оракле результат любого одного запроса (целиком, со всем подзапросами) консистентен на некий момент времени. Собственно, это характерная черта версионного подхода. Неконсистентны могут быть результаты других запросов, если те выполняются в функциях, вызываемых из запроса.

Пример:

Connected to Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 
Connected as test

SQL> create table consistency (id integer);

Table created

SQL> create sequence consistency_seq;

Sequence created

SQL> insert into consistency select consistency_seq.nextval from dual connect by level <= 5;

5 rows inserted

SQL> create function consistency_cnt return integer as
  2    cnt integer;
  3  begin
  4    select count(*) into cnt from consistency;
  5    return cnt;
  6  end;
  7  /

Function created

SQL> create function consistency_add return integer as
  2    new_id integer;
  3    pragma autonomous_transaction;
  4  begin
  5    select consistency_seq.nextval into new_id from dual;
  6    insert into consistency (id) values (new_id);
  7    commit;
  8    return new_id;
  9  end;
 10  /

Function created

SQL> select
  2    c.id,
  3    (select count(*) from consistency where dbms_random.value >= 0) select_cnt,
  4    consistency_cnt func_cnt,
  5    consistency_add new_id
  6  from
  7    consistency c;

                                     ID SELECT_CNT   FUNC_CNT     NEW_ID
--------------------------------------- ---------- ---------- ----------
                                      1          5          5          6
                                      2          5          6          7
                                      3          5          7          8
                                      4          5          8          9
                                      5          5          9         10

SQL> 

onstat-
ИМХО лучше ничего не делать на блокировке чем делать работу зря.

ИМХО критерием истины здесь является практика. А именно - производительность реальных систем.

onstat-
Основная проблема в том что он всю свою консистентность счинает на начало запроса.

Основное преимущество.
23 дек 08, 14:23    [6608350]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.

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

onstat-

Я немного поковырялся в логике работы oracle и думаю (ИМХО) пока коренным образом
не будет изменена работа с SCN & UNDO добавить новые уровни изолированности не представляется возможным. Основная проблема в том что он всю свою консистентность
счинает на начало запроса.

если вы обнаружили сходство RC+last_committed с версионностью и ищите рассогласованость в подзапросах то позволю себе усомнится, что вы в чем-то версионном копались.

onstat-
Другими словами его нужно блокировочником сделать ( считать консистентность по fetch).

нет, не нужно.
23 дек 08, 14:25    [6608366]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

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

Имеют право.

> почитайте уже упомянутую тут критику уровней, там не менее уважаемые
> товарищи дали определения недостающих феноменов, я свои выдумывать
> ленюсь ...

Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?

> их терминами RC иногда возможен лост апдейт, а RC c last_committed его
> гарантирует к стате не заслужено забыт skip_committed, опция из той же
> серии.

Вы так и не привели пример. ТАк что будем считать, что вы ничего не сказали.

Posted via ActualForum NNTP Server 1.4

23 дек 08, 15:27    [6608834]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer пишет:

>
> Признаться, не очень понял, о чем вы спорите.

Да собственно ни о чём. Yo тут гонит что-то, а мы пытаемся его
утихомирить.

Posted via ActualForum NNTP Server 1.4

23 дек 08, 15:29    [6608847]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
onstat-
Yo.!
onstat-

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

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


Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.

Может кто то из Oracle Гуру прояснит сообществу, что же происходит на самом деле?


Я не гуру, но попробую ответить:

Если не вдаваяться в подробности реализации, то Оракл гарантирует согласованность данных как минимум для данного запроса. Эта гарантия не зависит от наличия или отсутствия в нем подзапросов. Она так же не зависит от того какой план был выбран оптимизатором для выполнения данного запроса. Read consistency работает на уровень ниже, в "storage engine" выражаясь языком open-source СУБД. Этот уровень и отвечает за всякие table scans и index scans. Упрощенно говоря, в блок пишется когда его крайний раз модифицировали (на самом деле все несколько сложнее и туда еще много чего пишется). Когда выполняется сканирование некого сегмента (т.е. таблицы или индекса) то поблочно проверяется когда данный блок изменялся. Если обнаруживается что блок был изменен после того как был запущен запрос, то Оракл лезет в undo с целью восстановить как же записи в этом блоке выглядели на момент запуска запроса.

В Оракле вы либо получите согласованные данные либо широко известное среди критиков данной СУБД сообщение об ошибке "ORA-1555: Snapshot too old". Ошибка происходит когда при попытке восстановления картины на момент запуска запроса обнаруживается что нужных данных в undo уже нет. Их там может не быть, потому что если транзакция которая изменила блок была прибита commit'ом то старая версия данных лежащая в undo при этом была помечена как свободное место, доступное для записи в него новых данных. На этом месте критики оракла обычно начинают говорить что-то в духе "Оракл аццтой" и "блокировщики форева". Они упускают один немаловажный нюанс. Писать в undo данные поверх того что там лежит оракл будет не сразу а через некоторое время. Этой задержкой по времени управляет DBA через undo retention period. Например в одной из OLTP баз у меня на работе он установлен в 3 часа. Поскольку запросы выполняющиеся по 3 часа в OLTP базах как правило не встречаются, то вероятность получить ошибку вместо данных мизерная.
24 дек 08, 04:56    [6611105]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
MasterZiv

Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?

Утопший Джимми, Берштейн и Co, а чо критику не стали читать ? :- D

MasterZiv

Вы так и не привели пример. ТАк что будем считать, что вы ничего не сказали.

Пример: select * from table
24 дек 08, 11:34    [6612131]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:
> Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?
>
>
> Утопший Джимми, Берштейн и Co,

Да вы, вы придумали, только что в топике. Ну да ладно.

а чо критику не стали читать ? :- D

Да читал, как же ...

> Пример: select * from table

Блин, вы видимо критику-то читали. Ну так вот так, как там сделано,
и надо пример пивести. А ДО этого дать определение нового
уровня изоляции LAST COMMITTED. Тоже так, как там.

Posted via ActualForum NNTP Server 1.4

24 дек 08, 12:24    [6612679]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
MasterZiv

Да читал, как же ...

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

"We believe the isolation levels called Locking READ UNCOMMITTED, Locking READ COMMITTED, Locking REPEATABLE READ, and Locking SERIALIZABLE are the locking definitions intended by ANSI SQL Isolation levels — but as shown next they are quite different from those of Table 1. "

MasterZiv

А ДО этого дать определение нового
уровня изоляции LAST COMMITTED. Тоже так, как там.

немогу, я собствено и не считаю LAST COMMITTED уровнем изолированности, просто опция (хинт) к грязному чтению (оказывается к нему тоже) и RC. ну а то, что ерунда которую вычитает обычный RC лишь усугубится при отказе дожидаться снятия блокировок мне представляется очевидной. а что-то доказывать если и должен, так ИБМ.
24 дек 08, 14:11    [6613768]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

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

А с чего вы взяли, что я "невъехал" ? Наоборот даже.
Вы ссылались на термины оттуда ? Надо было так и сказать (сразу).
По умолчанию есть только ANSI.

> немогу, я собствено и не считаю LAST COMMITTED уровнем изолированности,

Ну тогда что ж говорить-то о его "хуже"/"лучше" ?

Posted via ActualForum NNTP Server 1.4

24 дек 08, 16:09    [6614859]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Yo.!

Утопший Джимми,

Зря вы так о покойнике. Джим Грей был замечательным человеком. Несмотря на его многочисленные заслуги у него не было ни капли зазнайства, ни малейших следов "звездной болезни". Он не любил когда его называли Джеймс, всегда просил "зовите меня просто Джим". Общаться с ним было одно удовольствие.
24 дек 08, 19:35    [6616326]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить