Выбегалло
Это когда таблица автоматически становится row level -> page level -> table level внутри транзакции, чтоюы уменьшить число блокировоу (впрочем, у MS page-level blocking по-моему не участвует в excalation)


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

2 Yo.!!
Что в этом плохого, или вы вкладываете другой смысл
в понятие row excalation ?

Nikolay KulikovНу вообщето я работаю в IBM :) так что не бряхня...
В одном из списков хотелок клиентов и заказчиков, про которые ты рассказывал, я это и видел.

Я против версионности в Informix.

1. Появятся баги. Возможно ухудшится производительность

2. В Informix есть инструменты монторинга и принятия решения внутри транзации если какая либо запись заблокирована.
Вот пример

3. Поведение приложения будет более предсказуемым если
при разработке пользоваться возможностями из п.2
Чем во время эксплуатации ловить snapshot too old.
или другие ошибки нарушения изоляции транзакций присущие версионным БД.

Я считаю Informix механизмы изоляции транзакций
лучше любых версионных механизмов.

Весь последующий текст этого сообщения мое ИХМО

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

"Почему блокировочные механизмы Informix лучше версионных механизмов".

Опубликовав его с примерами для разных сред разработки.
И примерами решения тех же проблем изоляции транзакций в других базах данных.

Если документ хорошо пропиарить в кругах ИТ руководителей, то желающих переходить с Informix на другие СУБД резко поубавилось бы.

А паралельно подтягивать недостающий функционал в ДБ2.

vasilis onstat- Я считаю Informix механизмы изоляции транзакций
лучше любых версионных механизмов..
Я бы не был так категоричен :) Скорее всего, ваши заключения от незнания тонкостей как одного, так и другого механизма. Если бы у какого то из них присутствовали явные преимущества, то все бы давно перешли на него, невзирая на "исторические наследия", маркетинг и деньги. Недостатков хватает в каждом механизме, но эти недостатки постепенно нивелируют, добавляя новые возможности, используя более мощное железо, новые математические исследования и т.п.
Главное, что нужно помнить, что для каждой конкретной задачи больше будет подходить какой то один механизм, и практически нет такой задачи, которую можно было бы реализовать на одном и нельзя на другом.

[/quot]

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

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

vasilis
Во-первых, пожелания маркетинга (а значит рынка и кастомеров) учитывать надо всегда, по крайней мере, делать вид...
Во-вторых, таких документов написано много, так же как и разнообразных тестов (типа TPC-C и т.п.)

Я не встречал документов которые
помогали решать конкретные(типовые) прикладные задачи в многопользовательской среде с использованием инструментов предоставляемых СУБД.

Статьи как правило описывают механизмы, а хотелось бы что бы они
описывали решение типовых прикладных задач с использованием
тех или иных механизмов ( рюшечек и завитушечек (С) Выбегалло)

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

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

Например2: создание отчетов по постоянном меняющимся данным на определенную временную точку или период времени.

Если у вас есть на примете такие документы, дайте ссылки pls.

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


Все преймущества субьективны , так как зависят от опыта программистов
и мнения ПМ и более высокого руководства
по поводу необходимости использования того или иного инструмента или СУБД.

onstat-Если документ хорошо пропиарить в кругах ИТ руководителей, то желающих переходить с Informix на другие СУБД резко поубавилось бы.
ИТ-руководители такие документы не читают. Если ты таких руководителей знаешь, то тебе крупно повезло. Я бы на их месте тоже не читал, так как их значительно больше волнует стоимость решения, его дальнейшая поддержка, наличие квалифицированных специалистов по данной СУБД, реальные внедрения рядом и множество других более важных вопросов, чем мифические преимущества блокировочников над версионниками.
[/quot]

Под понятием ИТ руководитель я имел ввиду ПМ и выше.
Именно с ПМ и нужно начинать,
по моему софтверные конторы где высшие руководители не присушиваются к мнению ПМ не имеют будущего.

Если говорить об абстрактной СУБД то преймущества действительно
мифические, если сравнивать Informix и другие БД то можно
найти немало преймуществ.

Yo.!!

тут я согласен с IBM эскалация снижает конкурентный доступ и соответственно страдает перфоменс ...


Эскалация не снижает и не повышает конкурентный доступ
потому что производится( если производится ) внутри одной транзакции.

От чего страдает производительность?
Ведь Informix не хранит блокировки на диске.

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

Выбегалло
Это, кстати, мое второе большое недоумение, после "блокировочники vs версионники" - отчего некий "функционал", под которым как правило понимаются расширения SQL, так ценится российскими программистами ? Ведь по большому счету, это все рюшечки и завитушечки.


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

Выбегалло
А вот то, что у DB2 до совсем недавнего времени не было нормальной HADR (high availibility data replication), или то, что "процессная" архитектура жрет принципиально больше ресурсов чем "нитевая" - это почему-то никого и не волнует. Потому что спрятано под капотом, и сразу не разглядеть ?


Полностью поддерживаю мнение что многонитевую архитектуру
Informix списысывать ни в коем случае нельзя.
ИХМО Она однозначно лучше "процессной".

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

Если бы еще шедулер информиксу можно было подкрутить, чтобы у долгоигращих падал приоритет что-ли (мне кажется из-за одной долгоиграющей сессии DSS слишком сильно ухудшается время отклика у быстроиграющих OLTP, почему точно не понимаю).

Вероятнее всего производительность падает потому, что DSS
запрос вытесняет из буферов индексы,
которые постоянно нужно подчитывать обратно.
Думаю, что приоритет непоможет.

Журавлев Денис Yo.!!....
ну мы это уже проходили, когда на винде процесорная архитектура была совсем херовой ораклу пришлось портировать в нитевом варианте - результат медлено и туча гемороя на 32-битах.Вы о чем? У оракла есть режим mts и он работает, это тоже самое что у информикса. Правда у оракла есть еще режим дидикейтид, а у информикса нет.

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

На производительность влияет не склько скорость переключения контекста
а их количество.

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

Витруальный процессор informix продолжит обрабатывать следующую
пользовательскую сессию готовую к выполнению в текущем контексте.

Это наверное было основным критерием для выбора внутренней мнгонитевой
модели по сравнинию с процессной моделью построения СУБД.
И думаю она себя оправдала если в свои времена на ней остановились и полностью переделали мотор.

Кстате, а какие еще СУБД используют внутреннюю многонитевую архитектуру?

Журавлев Денис onstat-
Кстате, а какие еще СУБД используют внутреннюю многонитевую архитектуру?Смотря что понимать под словом "многонитевый", firebird classic/superserver, oracle dedicated/mts.

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

Если делать выводы из поста Тан то mts не совсем та внутренняя многонитевая обработка. Процесс работает с одной
пользовательской сессией от начала выполнения операции до ее завершения.
Соответственно спит если нет условий для ее продолжения,
Хотя в очереди на выполнение может находиться еще несколько пользовательских сессий которые можно выполнить не впадая в сон
и при этом нет свободных mts серверов, которые могут взять эти сессии в обработку.

Видимо поэтому Oracle и говорит что dedicated быстрее чем mts,
хотя ИХМО должно быть наоброт.

Журавлев Денис onstat-...
Видимо поэтому Oracle и говорит что dedicated быстрее чем mts,
хотя ИХМО должно быть наоброт.Тан хотела сказать что у mts невытесняющая многозадачность, .....

Давайте сначала остановимся на понятиях.

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

Или я не прав?

Насколько я помню информикс использует вторую ( невытесняющую многозадачность).

Мне кажется что многозадачность Oracle МТС больше похожа на последовательную пакетную обработку чем на многозадачность.
За счет большого количества этих серверов(процессов) и получается паралелизм, хотя внутрення реализация МТС не многозадачна.
Т.Е Переключением задач всеравно занимется занимается ОС.
Хотя я могу заблуждаться.

Yo.!!что-то вы нитуда отклонились, мтс совсем другая область, имхо это ближе к transaction mionitor, короче класика:

(C) Tom Kyte

Да как раз об этом и говорим, что колчество одновремменно
выполняемых запросов МТС не может быть больше чем
значения параметра mts_max_servers.

Если все сервера будут заняты выборкой данных для сессий(
ожидать чтения с диска)
а одна сессия находится в ожидании сервера MTS и
требует чтения из последовательности.
Пока какой либо сервер не освободится(зделает полную выборку)
последовательность прочитана не будет. А Сессия будет ждать.

Я правильно понял?

Т.Е. можем получить ситуацию когда делать нужно,
и для этого нет никаких ограничений кроме отсутствия свободных
серверов MTS, а сессия спит
"потому что в кузнеце небыло гвоздя" (С) не помню кто.

Ситуация конечно же правится увеличением параметра, но ее нужно расковырять, а потом перестартовать СУБД.