Scott TigerБог спас от необходимости работать с DB2, хотя не спас от Информикса.

Вы право, удивляете все больше и больше .. :)

Informix rated #1 by VendorRate in survey: beats Oracle! Read the press release!!
http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20081016005336&newsLang=en

Я бы мог предоставить достаточно обширный список, кто работает и использует технологии Informix.
For example:
- Every VISA transaction authorization in US goes through IDS
- 8 of the top 10 U.S. Retailers
- 20 of the top 25 U.S. Supermarkets
- United States “911” Emergency System
- and so on.

В настоящий момент, у Informix - самый мощный OLTP движок в мире.
Если сравнивать СУБД ORACLE 11g , DB2 9.5 и Informix 11.50 для OLTP - то решение на DB2 требует в два раза меньше аппаратных ресурсов чем ORACLE, а Informix - в два раза меньше чем при использовании DB2 - при одинаковой производительности (транзакционной нагрузки).
Вот и считай ваши денежки. Есть желание купить больше железа для достижения той же производительности, покупай ORACLE ... :) .... хочешь иметь дополнительный запас прочности ... Informix !!!

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

SAP - DB2 has significant advantages running under SAP compared to Oracle that will not only give customers better performance, but will also lower their operating costs.


Сегодня, крайне редко встречаются задачи где требуется только использование режима OLTP.
Для смешанных сред - лучше использовать DB2 чем Informix.

Версия DB2 9.5, предлагает уникальные технологии - MDC, MQT, Deep Compression, LEO-оптимизатор,
WLM на уровне СУБД (или WLM - интегрированную с OS, например AIX), встроенный тип данных XML,
SQL-репликацию, HADR-репликацию, Q-репликацию, поддержку хранимых процедур на PL/SQL, C/С++, Java, thread-based process model и т.д. В следующей версии DB2 Cobra, планируется поддержка хранимых процедур, написанных в диалекте ORACLE (PL/SQL) .... :)

Так что, DB2 - очень даже хорошая СУБД ... просто,
инструменты нужно ипользовать по назначению ... :)

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

Есть много разных мнений .... и хороших и плохих.

Если администратор не может поднять базу - это говорит о том, что он не тестировал
процедуру восстановления для данного архитектурного решения (action plan, configuration, bug fix, and so on.). Видел Я такие конфигурации.

Как правило,
успех мероприятия во многом зависит от уровня профессионализма бизнес-партнеров,
которые настраивают и устанавливают подобные системы.

Не совсем понятно, причем здесь база данных ?

Например,
Я знаю другой вариант, когда у одного заказчика на площадке работают DB2 for SAP и ORACLE RAC.
С DB2 никаких проблем, а вот у ORACLE RAC - ноды между собой не могут договориться ... вылетает то одно то другая ... :)

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

Незря уж говорят - лучше поже, чем никогда
Уже интересно, автор использует все еще Informix?

Да - это так ... лучше позже, чем никогда .... :)

В данный момент ... разбираюсь с новой версией IDS 11.50 - технологией MACH11.
Собираюсь покопаться в новой версии DB2 Cobra - если времени будет достаточно ... :)

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

Приложения которые пытаются поддерживать несколько субд -- это супергеморой для пользователей.


Причем здесь пользователи ?
Пользователь должен получить комфорт от работы с приложением и нужный перечень сервисов.
Архитектурные особенности решения его не должны волновать ... :) ... это дело IT-архитектора и т.д. Опять же, каждый инструмент хорош для определенных задач.

То 2-2<>0 (потому что в оракле number, а в информиксе float), то отчеты выполняющиеся в dirty reads, показывают не пойми что.

Ну батенька, используйте другой вид изоляции транзакций. Никто не заставляет Вас использовать для отчетов - dirty reads. Интересно, как в ORACLE можно прочитать данные, когда в базу BI они только загружаются (в процессе загрузки) ... :) ... ?

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

С точки зрения базы данных - это оказывает влияние на эффективность распределение ресурсов.
Работал же Informix c оптимистическими блокировками много лет ... думаю, что ни у кого не вызывало сомнений, что это самый быстрый OLTP-движок ... :)

Хотите еще быстрее - используйте новой возможности ... :)

Есть много разных мнений ...
What strategies are available to organizations for executing mixed OLTP and DSS workloads using current DBMS technology? The most straightforward approach is simply to execute all DSS queries/reports using an isolation level of uncommitted read (UR) so that it does not cause any locks, or wait for any locks held by other applications.

In this manner OLTP transactions continue to execute (with the locks they need to ensure the data integrity) and are not impacted by the DSS queries since they do not acquire any locks and therefore do not block any other queries (OLTP or DSS). The reality is that 90%+ of all transactions in an OLTP system are committed, not rolled back, so the fact that the DSS queries see the uncommitted data is inconsequential. As well, the DSS queries are typically calculating monthly or yearly values, so the fact that they might see a query that is not yet committed does not affect the result ...

Какую стратегию выбрать - решать Вам.
В данном случае, Informix и DB2 не ограничивают Вас в выборе .... :)

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

Это не мне, у меня в консерватории все ок, это индусам которые сап и баан пишут посоветуйте.

Это хорошо, что у Вас все - OK!
Проблемы индейца - вождя не волнуют ... :) ... шутка.

Примеры конечно - показательные ... :) ... но и рекомендации могут быть разные.
Например, использовать уровень изоляции транзакций CS, установить для сессии2 TIMEWAIT и т.д. Вообще-то, рецептов может быть много ... в том числе и использование optimistic locking.

Improve concurrency with DB2 9.5 optimistic locking
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0801schuetz/

Угадайте как эту проблему решил 1С?
Думаю, что 1C - затачивает свою систему под DB2, а IBM, свою базу - под 1С ... :)

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

Дело в том что прикладной разработчик, не знает в какой СУБД будет работать код, он пишет на 4gl языке (baan-sql, abap, 1c) .На уровень изоляции тут повлиять нельзя. Залочить и то проблема. Эти запросы трансформируются в запросы к разным СУБД и надо написать так чтобы работало у всех.


Если прикладной разработчик заранее не знает в какой СУБД будет исполняться его код,
тогда, тем более есть все основания для того чтобы придерживаться стандарта ANSI.
Насколько мне известно DB2 и Informix, предоставляют такую возможность.

Далее, если SQL-запросы трансформируются к разным СУБД, тогда необходимо понимать методологию и логику такой трансформации. Как минимум, должны быть определенные рекомендации со стороны - SAP, 1C и т.д.

Например,
SAP все больше поддерживает технологию Java. Соответственно Java, поддерживает J2EE Isolation Level - который хорошо совместим с ANSI Isolation Level. Если разработчик поддерживает ANSI-стандарт, тогда и проблем меньше. Если нет ... ну тогда больше лишней работы - за все нужно платить

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

Насколько мне известно,
в 1C, используется не так много хранимых процедур (может с десяток и то менее).
В основном, используется чистый SQL. Наверное, разработчики 1С не хотели привязываться к конкретной СУБД. Эффективность выполнения запросов 1С, во многом зависит от реализации внутренних механизмов в самой СУБД. Здесь разработчик прикладного решения повлиять не может, а вот на параметры пользовательской сессии, уровни изоляции транзакций и SQL-запросы - изменить может.

Если для решение проблемы Lost updates или Old Data Reads будут введены новые уровни изоляции в стандарт ANSI, тогда по всей логике онидолжны будут поддерживаться и всеми промышленными производителями СУБД.

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