vasilisДумаешь, зависимость масштабируемости от версии IDS будет сильно зависеть от платформы ?
Кстати, при беглом взгляде мне даже показалось, что у IDS масштабируемость лучше, чем у DB2 :)

Я думаю, что будет.

ИМХО
Для Z серии, P серии и Sparc цифры цифры масштабируемости будут сопоставимы.
Intel( независимо от бренда производителя железа) и AMD масштабируеммость
будет довольно сильно падать с ростом количества физических процессоров.


з.ы.
Как воинственный поклонник ( радикальный фанатик) Informix жду не дождусь
результатов тестирования TPC.
Думаю, что некоторым офтопичным СУБД, поклонники котрых кичатся результатами TPC
мы нос утрем .

vasilis onstat-
Для Z серии, P серии и Sparc цифры цифры масштабируемости будут сопоставимы.
Intel( независимо от бренда производителя железа) и AMD масштабируеммость
будет довольно сильно падать с ростом количества физических процессоров.

А Р-серия и Intel разве не одно и то же, в данном контексте?


P series это младший брат Z-series на базе процессоров IBM POWER и архитектуры RISK .

Сервера на базе процессоров Intel у IBM назвываются xseries


vasilis
onstat-
з.ы.
Как воинственный поклонник ( радикальный фанатик) Informix жду не дождусь
результатов тестирования TPC.
А что , кто то обещал результаты по 11-й версии ?

Нет не обещал, но если проводятся тесты для DB2 почему бы не провести и для Informix.

Журавлев Денис

onstat-Intel( независимо от бренда производителя железа) и AMD масштабируеммость
будет довольно сильно падать с ростом количества физических процессоров.
Numa?


Согласен, Numa может потягаться.


Журавлев Денис
onstat-
Как воинственный поклонник ( радикальный фанатик) Informix жду не дождусь
результатов тестирования TPC.Теперь модно tcp-E , а там один запрос надо в сериэзибл выполнить, чуете?
http://oraclemind.blogspot.com/2007/08/tpc-e-ibm-unisys.html
http://oraclemind.blogspot.com/2007/07/tpc-e.html

По диагонали просмотрел описание теста не нашел требование для serializable.
Там есть требование обеспечить консистентность.

Журавлев Денис Журавлев ДенисТ.е. в оракл и в мсскуль понятно как.С другой стороны они конечно кучу времени теряют на consistent gets. Можно заблокировать, и попытаться выполнить да используя pdq и возможно результат будет хорош, чем черт не шутит.

Думаю что у Informix v11 c 5-ю уровнями изоляции больше возможностей для маневра чем у
Oracle c 2-мя, (которые в Informix тоже присутствуют).

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

Еще один бонус у Informix - наличие hold курсора.

Один реальных примеров здесь

Хоть и неприлично обсуждать недостатки заглаза, но там всеравно не поймут.
Как говориться Остапа понесло.

ИМХО Самая большая проблема Oracle в OLTP это
поведение курсора, который пытается получить консистентный набор на момент начала foreach.
Что заставляет разработчиков опускаться до serializable.
Есть еще одна темная дорога dbms_lock, но она насколько темная, что многие не решаются по ней ходить. А когда идут то уровней изоляции всеравно нехватает и опять получается такой себе местячковый serializable только очень запутанный.

GVF112GVF

Кроме того, DB2 может масштабироваться по диагонали - BCU концепция (
Scale Up + Scale Out)

С уважением,
Вадим.

Я так понял, что про старые наработки INFORMX XPS Забыли?
Или не правильно понял?

onstat- GVF112GVF

Кроме того, DB2 может масштабироваться по диагонали - BCU концепция (
Scale Up + Scale Out)

С уважением,
Вадим.

Я так понял, что про старые наработки INFORMX XPS Забыли?
Или не правильно понял?

Имелось ввиду разработчики IBM Informix забыли.

Или забили :)

GVF112GVFДа, вот еще ....
последний релиз DB2 9.5 поддерживает - multi-threaded architecture !!!

С уважением,
Вадим.

Опять меня несет, сегодня видимо день такой.


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

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

Качество синхронизации контекстов процессов в ОС в разрезе конкуренции за блокировки в
БД самое главное достоинство архитектуры Informix.

Журавлев Денисобуждать крутость информикса в 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 лет спустя) - можете пользоваться.

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