Журавлев Денисобуждать крутость информикса в tcp не имеет смысла. Нарисованный тигр не испугает даже кошки ((С) дедушка Брукс).
Рулит мскуль 2005.

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

Журавлев Денис onstat-поведение курсора, который пытается получить консистентный набор на момент начала foreach.
Что заставляет разработчиков опускаться до serializable.
Остапа заносит.
Любой запрос в оракле консистентен. Т.е. по мере фетча курсора идут конститент гетс. Если фетч закончится через четыре часа и коммит в текущей сессии (fetch across commit) орой1555 -- это ровно проблема индуса который не знает про коллекции.


Консистентны относительно чего?

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


Журавлев Денис
onstat-Есть еще одна темная дорога dbms_lock, но она насколько темная, что многие не решаются по ней ходить. А когда идут то уровней изоляции всеравно нехватает и опять получается такой себе местячковый serializable только очень запутанный.В 21 веке в оракле надо использовать только serializable, по моему оебс так и делает.

Так я же сказал, что это темная дорога.

Журавлев Денис onstat-
Консистентны относительно чего?
На начало запроса в дискретном целочисленном "времени".


Да, именно запроса .
Никто же не спорит, я как раз такое поведение описывал когда говорил про курсор.



Журавлев Денис
onstat-Вы не договариваете, я продолжу:
Любой запрос консистентен сам по себе,
а несколько запросов в сумме внутри транзакции консистентны
только в serializable.да, на начало транзакции.


Не понял, что Вы хотели этим сказать.

здесь написано следующее


я это имел ввиду.



Журавлев Денис
onstat-Так я же сказал, что это темная дорога.Да все прозрачно абсолютно.

Конечно , пока не начинает тормозить, и не начинаешь читать чужой код.
У каждого "индуса" свой велосипед. Иногда на 7 квадратных колесах.

з.ы. давайте прекратим офтопить.

Журавлев Денис onstat-
Никто же не спорит, я как раз такое поведение описывал когда говорил про курсор.Ок.

Что подразумевалось под этим тогда:
onstat-
ИМХО Самая большая проблема Oracle в OLTP это
поведение курсора, который пытается получить консистентный набор на момент начала foreach.
Что заставляет разработчиков опускаться до serializable.
В чем проблема? В производительности что-ли? В медленных consistent gets?
Зачем разработчикам опускаться (кстати почему опускатся?). Чем это решает проблему?

1.
Что бы было понятнее начну из далека:
Когда то очень давно гдето на sql.ru
обсуждалась проблема торговли хлебом в супермаркете.
Когда хлеб входит в 90% покупок, пока транзакции стоят в очереди за хлебом
при этом заблокировав остатки на других позициях, начинается
лавинообразный процесс блокировок.

Если вы будете отпускать хлеб по consistent gets
то стартовое значение остатка для 10 одновременно изменяющих сессий может оказаться
одинаковым и остаток в базе по завершению 10 продаж будет
значение полученное по consistent gets - расход по последней закомиченной транзакции.

Т.Е. остаток на конец периода не соответствует остатоку на начало - сумма по транзакциям(чекам).

Непомню чем это обсуждение закончилось.


2. Поведение подзапросов с consistent gets
в select for update.Они живут своей отдельной консистентной жизнью.


3. Меня лично больше интересует логическая целостность данных на уровне транзакции
( на то она и транзакция), а не на уровне запроса,
Если в сумме консистентных запросов получается не консистентность на уровне транзакци, то мне лично не нужна такая местячковая консистентность.
Как и разработчикам которые вместо Read Committed (consistent gets) используют serializable.

По этим причинам нужно опускаться(или подниматься, систему координат я Вам не навязываю) в serializable.

Журавлев Денис
Это очень простая задача в отличии от продажи билетов на электричку.


Я не говорил, что она сложная я ее привел в качестве примера, для наглядности.

По поводу производительности
Oracle Курсор не не вернет первый fetch при использованни for update
пока не проставит блокировки на все записи удовлетворяющие where.
Что бы все кому нужно начали использовать чтение undo.
Сие чудо нужно для поддержания консистентности на начало запроса.

Infomix же блокирует по мере захвата их fetch.

Поэтому конкуренция и наступление лавинообразного нарастания заблокированных записей у него
наступит позже.
Помимо этого с помощью механизма with hold можно легко пропустить
заблокированные записи, если это позволяет логика работы приложения.

Что касается данной проблемы в OpenDSA(Если он дойдет до состояния которое не стыдно будет показать) будет заложен механизм передачи блокировки,
В случае если нить попала на заблокированную запись она(запись, ее блокировка) ставиться в очередь
а нить переходит к следующей, и после комита или ролбека конкурирующей транзакции
нить которая стоит в очереди на эту запись первой, получит ее сразу при следующем fetch
при этом блокировка сниматься не будет, она будет передана от одной сессии к другой.

з.ы. Меня действительно сегодня понесло.


.

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

onstat-
По поводу производительности
Oracle Курсор не не вернет первый fetch при использованни for update
пока не проставит блокировки на все записи удовлетворяющие where.
Что бы все кому нужно начали использовать чтение undo.
Сие чудо нужно для поддержания консистентности на начало запроса.


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

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

2. Это необходимость прочитать страницу с диска, прежде чем ее блокировать.
Так как нужно блокировать все строки прежде чем вернуть 1 фетч, может сложится ситуация
когда страница вычитана для блокировки, затем вытеснена на диск, а потом снова считана.
А также время в течении которого 1-й fetch будет возвращен.

Увеличение же буферного пула, может привести к проблемам ожидания на блокировках
LRU chain, Вследвствие того, что LRU в oracle не параметризуются как в Informix.

Методами борьбы с блокировками LRU chain есть создание нескольких буферных пулов
(для таблиц лежащих на ТС с разным размером блока) если нет то ой..... как много всего переделывать нужно, или увеличение производительности CPU.
Я раньше упоминал о качестве синхронизации контекстов процессов(нитей) и блокировок
внутри БД.
ИМХО проблема с блокировками LRU chain в Oracle из этой области, но доказательств этому у меня нет, поэтому ИМХО.


з.ы. Если кто соберется писать версию статьи Informix vs Oracle 2 ( 10 лет спустя) - можете пользоваться.

з.ы.ы Если что то не так написал - поправляйте.