Informix displaces Oracle at China Telcom / Сравнение СУБД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix displaces Oracle at China Telcom

25 сообщений из 203, страница 2 из 9

все

Informix displaces Oracle at China Telcom

#35728873

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

вот так возникают мифы о блокировочных версионниках...
стоило только "разблокировать" конфликты 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.

...

Рейтинг:

0 / 0

22.12.2008, 21:06

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728876

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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 ?

В вашей понимании нет.

...

Рейтинг:

0 / 0

22.12.2008, 21:10

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728903

Yo.!

Гость

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

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

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

ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED потому как выдает более несогласованое чтение, чем RC типичного блокировочника. если мы с такой опцией расчитываем какие-нибудь бонусы расчитываем у нас больше ерунды получится, чем при обычном RC. посути если грязное чтение при блокируемой записи берет грязное значение, то LAST COMMITTED в том же случае возьмет последнее, закомиченное, а версионник будет реконструировать то значение какое было на момент старта транзакции/стейтмента. и НИКОГДА не прочтет одну и ту же запись двадцать пять раз.

...

Рейтинг:

0 / 0

22.12.2008, 21:33

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728927

Yo.!

Гость

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

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

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

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

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

...

Рейтинг:

0 / 0

22.12.2008, 21:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729007

Zhora

Участник

Откуда: USA New York

Сообщения: 371

Рейтинг: 0 / 0

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)

...

Рейтинг:

0 / 0

22.12.2008, 23:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729405

Yo.!

Гость

MasterZiv

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

...

Рейтинг:

0 / 0

23.12.2008, 10:18

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729419

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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 так было бы логичней.

...

Рейтинг:

0 / 0

23.12.2008, 10:22

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729430

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Zhorakdv...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,
Может рассказать зачем испортили правильную систему?

...

Рейтинг:

0 / 0

23.12.2008, 10:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729488

Yo.!

Гость

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

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

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 10:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729549

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

[/quote]

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

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

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 11:21

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729600

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

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

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

Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 11:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729618

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

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

LOST UPDATE как с READ COMMITED связан, а ?
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 11:38

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729635

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

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

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

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 11:43

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730022

Yo.!

Гость

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

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

2MasterZiv

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

...

Рейтинг:

0 / 0

23.12.2008, 13:28

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730092

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 13:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730191

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

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

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

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

Пример:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.

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-Основная проблема в том что он всю свою консистентность счинает на начало запроса.
Основное преимущество.

...

Рейтинг:

0 / 0

23.12.2008, 14:23

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730198

Yo.!

Гость

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 14:25

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730399

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

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

Имеют право.

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

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

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

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

...

Рейтинг:

0 / 0

23.12.2008, 15:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730409

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

softwarer пишет:

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

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

...

Рейтинг:

0 / 0

23.12.2008, 15:29

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731324

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

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 базах как правило не встречаются, то вероятность получить ошибку вместо данных мизерная.

...

Рейтинг:

0 / 0

24.12.2008, 04:56

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731800

Yo.!

Гость

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

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

Пример: select * from table

...

Рейтинг:

0 / 0

24.12.2008, 11:34

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731972

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

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

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

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

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

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

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

...

Рейтинг:

0 / 0

24.12.2008, 12:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35732365

Yo.!

Гость

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

...

Рейтинг:

0 / 0

24.12.2008, 14:11

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35732822

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

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

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

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

Ну тогда что ж говорить-то о его "хуже"/"лучше" ?
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

24.12.2008, 16:09

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35733493

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Yo.!
Утопший Джимми,

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

...

Рейтинг:

0 / 0

24.12.2008, 19:35

| Ответить | Цитировать | Написать

25 сообщений из 203, страница 2 из 9

все

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix displaces Oracle at China Telcom

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=35&msg=35730409&tid=1552984]:	0ms
get settings:	10ms
get forum list:	13ms
check forum access:	4ms
check topic access:	4ms
track hit:	43ms
get topic data:	10ms
get forum data:	2ms
get page messages:	61ms
get tp. blocked users:	1ms
others:	250ms

total:	398ms