Yo.! GVF112GVFЯ уже молчу о том, что RAC плохо масштабируется горизонтально (максимум в рабочей среде 4 - ноды), проблемы синхронизации нод (кэш памяти и т.д.)

факты говорят об обратном, на данный момент более масштабируемой технологии не существует. 5 нод Power6 RACа на SAP-SD parallel оказались более масштабируемы чем самый крупный (на тот момент) SMP из Power6. Кроме этого eBay использует 8 нод RACа.
http://www.sap.com/solutions/benchmark/sd1_results.htm
ЗЫ. пара "лишних" нод RAC обойдутся гораздо дешевле чем полное дублирование, которое вынуждены будете делать для SDS (для rw транзакций).

Батенька, не надо нас дурить !!!
Всем известно, что решение RAC - стоит дороже чем аналогичное решение IBM
(как минимум на ~ 28%, в основном за счет стоимости лицензий ORACLE).

Например, самое простое сравнение для двух-узлового кластера:
- для DB2 EE on 2-сервера 8-cpu System p5 570 (1.5 Ghz), 16 GB RAM, 2TB Storage ~ $ 449 000
- Oracle EE + RAC on 2-сервера 4-cpu System p5 570 (1.5 Ghz), 8 GB RAM, 1TB Storage ~ $626 000

Как видно в случае ORACLE, отсутствует аппаратное резервирование на уровне процессорных мощностей и на уровне дисковой подсистемы. В случае использования дополнительной (резервной) дисковой системы общая стоимость решения ORACLE будет толко расти возрастать.
Если узел выходит из строя, то потеря процессорных мощностей приводит к значительно потери производительности (как минимум в два раза) в случае выхода дисковой подсистем - страшно и подумать.

Время реакции у DB2 системы на сбой и переключение на резервный узел, составляет - менее 20 секунд (Тotal Failover Time < 20 sec., Failover in 11 seconds demonstrated in test of SAP environment with 600 users.).

Для ORACLE.
Время реакции системы на сбой и переключение на резервный узел, составляет - более 20 секунд (Тotal Failover Time > 20 sec).

Тotal Failover Time:
- Reconfigure Group Membership -15 секунд,
- Reconfigures Distributed Locks - 5 секунд,
- Recover Oracle ~ 20 секунд

Использование решение DB2 (HADR) или IDS (MACH11), позволяет резервировать аппаратные мощности !!! Общее решение HW + SW - будет дешевле !!! Заказчик получает более мощную технику !!!

Кроме того,
если приводить примеры, то в типовой конфигурации (ближе к реальной жизни).

Например - DB2 работает в кластере на 1000 узлах,
DB2 Scales in Multiple Directions:
- Scale Up (SMP) – Unlimited
- Scale Out (MPP) – up to 1,000 nodes

для ORACLE теоретически возможное число узлов ~ 128 узлов (практически было - мax 16) !!!

Можно сказать, что такое сравнение не совсем корректное - DB2 vis ORACLE.

Дело в том, что Informix требует еще меньше аппаратных ресурсов чем DB2 и ORACLE.
Вот, что пишут наши эксперты - IBM Informix Dynamic Server 11 The Next Generation in OLTP Data Server Technology (ftp://ftp.software.ibm.com/software/data/information/ids-ebook.pdf):

Page-7
--------------
In fully utilizing the hardware processing cycles, the IDS data server requires less hardware power to achieve performance comparable to or better than other data servers.
In fact, real-world tests and customer experiences indicate that IDS needs only 35 percent to 50 percent of the hardware resources to meet or exceed the performance characteristics of single-threaded or process-based database servers.
With this kind of efficiency, you can extend the life of your existing systems, defer costly expenditures, avoid migration-oriented outages and work, and, most important, contribute directly to the bottom line of your company’s financials.

Я уже молчу как масштабируется ORACLE вертикально .... :) ...
performance (48 CPU DB2 == 64 CPU ORACLE).

Думаю, все понятно - стоимость дополнительных 16 CPU лицензий ORACLE (плюс RAC)
совсем дешево ... :)

Не спасет ORACLE и Power 6 !!!
И еще - все, что хорошо для ORACLE - хорошо только для ORACLE (простите не для ВАС) !!!

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

Yo.! GVF112GVFЯ уже молчу о том, что RAC плохо масштабируется горизонтально (максимум в рабочей среде 4 - ноды), проблемы синхронизации нод (кэш памяти и т.д.)

факты говорят об обратном, на данный момент более масштабируемой технологии не существует. 5 нод Power6 RACа на SAP-SD parallel оказались более масштабируемы чем самый крупный (на тот момент) SMP из Power6. Кроме этого eBay использует 8 нод RACа.

http://www.sap.com/solutions/benchmark/sd1_results.htm

ЗЫ. пара "лишних" нод RAC обойдутся гораздо дешевле чем полное дублирование, которое вынуждены будете делать для SDS (для rw транзакций).


Если захотелось сравнивать решение ORACLE для SAP,
то нужно сравнивать ORACLE c DB2 !!! Я даже боюсь приводить такой пример - дабы не оскорблять Ваши чувства и чувства сотрудников компании ORACLE.

DB2 Crushes Oracle in TPC-C
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

As of July 23, 2008, DB2 has the top benchmark result in the following benchmarks:

* SAP SD 3-tier
* SAP Transaction Banking
* SAP Business Warehouse
* TPC-C
* TPC-H 10TB
* SPECjAppServer

Отмечу лишь - DB2 Business Value for SAP customers:
1. SAP/Oracle customers can save 30 % of his database cost by switching to DB2.
2. SAP & DB2 startegic development partnership.
3. DB2 runs 25 % faster on same hardware than Oracle.
4. DB2 for SAP BI outperforms Oracle by a factor of 2X at least.
5. DB2 needs 30 % less DBA effort than Oracle.
6. Oracle is 38 % more expensive than DB2 in SAP space.
7. Oracle RAC is 75 % more expensive than DB2 HADR in SAP space.
8. IBM runs SAP, SAP runs DB2.
9. DB2 is SAP‘s strategic database for today and the future.
10. Migrating from SAP/Oracle to SAP/DB2 is risk free.

Референции заказчиков, использующих решение DB2 for SAP

Switzerland - Nestle - very large:
http://www-01.ibm.com/software/success/cssdb.nsf/CS/STRD-7CTKET?OpenDocument&Site=gicss67sap&cty=en_us

Switzerland - IWB - small:
http://www-01.ibm.com/software/success/cssdb.nsf/cs/STRD-7DKHC3?OpenDocument&Site=corp&cty=en_us

Germany (german) - REHAU - medium:
ftp://ftp.software.ibm.com/software/emea/de/db2/8029_HiR_oB_GK12-4350-00.pdf


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

Yo.! GVF112GVFЯ уже молчу о том, что RAC плохо масштабируется горизонтально (максимум в рабочей среде 4 - ноды), проблемы синхронизации нод (кэш памяти и т.д.)

факты говорят об обратном, на данный момент более масштабируемой технологии не существует. 5 нод Power6 RACа на SAP-SD parallel оказались более масштабируемы чем самый крупный (на тот момент) SMP из Power6. Кроме этого eBay использует 8 нод RACа.

http://www.sap.com/solutions/benchmark/sd1_results.htm

ЗЫ. пара "лишних" нод RAC обойдутся гораздо дешевле чем полное дублирование, которое вынуждены будете делать для SDS (для rw транзакций).

Почитай здесь на счет фактов
http://www-306.ibm.com/software/data/db2/press/ciba.html
или здесь http://www-03.ibm.com/solutions/sap/index.jsp?re=boost

или где-то еще

ПРОЕКТ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ IBM DB2 9.x
Анализ эффективности затрат на совершенствование коммерческих систем SAP
http://download.boulder.ibm.com/ibmdl/pub/software/dw/ru/download/DB29fSAP.pdf

IBM IDS ROI Tool for Continuous Availability
http://www-306.ibm.com/software/data/information/ids-roi-availability.html

SAP Standard Application Benchmarks
http://www.sap.com/solutions/benchmark/index.epx

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

... эко вас торкнуло.... Взаимно ... :)


Я сравниваю - DB2 HADR и ORACLE RAC !!!
Теперь будем вносить ясность ... :)
Основное назначение технологии ORACLE RAC:
1. Обеспечение отказоустойчивости на уровне ноды кластера ORACLE.
2. Обеспечение балансирования и распределение нагрузки в кластере ORACLE.

Все что Я сказал так это следующее:
1. Все что хорошо для ORACLE - хорошо только для ORACLE (в данном случае технология RAC ORACLE)
2. Технология DB2 HADR - решает аналогичные задачи намного дешевле и эффективнее (даже с учетом полного дублирования аппаратных ресурсов). Для DB2 не надо ни какого кластера !!!
Достаточно один (основной) мощный сервер с тем же пулом процессорных ресурсов (что и в случае использования технологии RAC) и резервный сервер для обеспечение отказоустойчивости.
В совокупном владении решение на основе DB2 - дешевле чем аналогичное решение ORACLE !!!
Плюс - заказчик получает более мощную технику с аппаратным дублированием !!!

Далее, сравнивая:
1. ORACLE RAC/Clustering for High Availability и DB2 HADR(not DPF) - DB2 HADR can offer ~ 10 second failover, RAC cannot !!!

2. ORACLE RAC/Clustering for Scalability и DB2 DPF - DB2 DPF can scale-out ~ 1000 nodes. RAC is limited in-practice to 8 nodes.

3. ORACLE DATA GUARD и DB2 HADR - HADR offers both HA and DR support, plus ~ 10 second failover with minimal overhead!!!

Теперь если речь зашла об использовании технологии ORACLE DATA GUARD то нужно сравнивать ее
с решение IBM - IBM xkoto DB2 GRIDSCALE !!! Это будет более чесно !!!

Теперь об INFORMIX. Сервер Informix работать на многих аппаратных платформах - начиная с
мейнфрем, заканчивая Apple MAC OS и т.д. Сервер DB2 так же как и сервер Informix - поддерживают мульти-поточную архитектуру "shared nothing" на UNIX/LINUX/WINDOWS и т.д.

Чего не скажешь об ORACLE. С увеличение количества пользовательских соединений (в случае ORACLE) растет количество процессов на уровне OS UNIX/LINUX - что требует значительных аппаратных ресурсов памяти да и процессорных ресурсов. Управляемость такой системы - крайне сложная да и есть ограничение на аппаратные ресурсы.

Теперь относительно решения SAP.
Насколько мне известно SAP BI - использует исключительно технологию DB2 DPF !!!
Так как хранилище данных проще и дешевле масштабировать горизонтально, да и производительность системы растет с увеличение узлов в кластере почти линейно (нет архитектурных ограничений как в случае с ORACLE) !!!

Если Вы используете решение ORACLE - у Вас толко один путь для масштабирования - вертикальный (в силу ограничения max числа узлов в кластере ORACLE, решение проблем синхронизации кэшей, взаимных блокировок, full scan и т.д.). Так что Вы должны отдавать себе отчет - рано или поздно Вам потребуется - мейнфрем ... :)

Теперь о вашем sizing - к сожалению, Я не знаю кто Вам его так насчитал (saps-ы).
Я вам расскажу другую историю ... :)

Решени SAP состоит из нескольких систем:
DEV + TEST + HA ( PROD (Active) + PROD (Passive) ) + PROD (DR)

Так вот в случае если у Вас продуктивная система имеет 64 cpu, то Вам милейший
прийдется заплатить ORACLE:

DEV (64 CPU) + TEST(64 CPU) + HA ( PROD(64 CPU) (Active) + PROD(64 CPU) (Passive) ) + PROD(64 CPU) (DR) - 320 CPU License ORACLE EE ~ 2.35m with discount

В случае решения DB2
DEV (64 CPU) + TEST(64 CPU) + HA ( PROD(64 CPU) (Active) + PROD(1 CPU) (Passive) ) + PROD(1CPU) (DR) - 66 CPU License DB2 + 200 DB2 UDE Licenses ~ 1.33m with discount

Таким образом Вы уже экономите 43.4 % !!! Считайте Ваши денежки !!!

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

[quot GVF112GVF] ... эко вас торкнуло.... Взаимно ... :)

Теперь можно поговорить об технологии репликации ORACLE и IDS (MACH11).

Для начала, IDS(MACH11) может эффективно использоваться как для небольших solution - например в BLADE - ситемах та и на уровне Enterprise. Далее, резервные узлы могут рабтать на чтение или на DDL-обнавление и т.д.

Основное отличие от OARCLE 11g Data Guard Physical Standby

1. Secondary/Standby remains “hot” during failover - IDS(YES), ORACLE(NO)
2. Failover in seconds - IDS(YES), ORACLE(NO)
3. Simple to configure / monitor - IDS(YES), ORACLE(NO)
4. Read on Secondary/Standby - IDS(YES), OARCLE (YES Must stop DG)
5. Simple log management - IDS(YES), ORACLE(NO)
6. Primary can be reintegrated after failover - IDS(YES), ORACLE(NO)
7. Licenses on Secondary/Standby - IDS (None (if no connection)), ORACLE(YES)

Сравнение Informix (MACH11) SDS и Oracle RAC:
SDS: Shared Disk Secondary
RAC: Real Application Cluster

1. Add nodes without interrupting processing - IDS(YES), ORACLE (NO)
2. Take nodes offline without interrupting processing - IDS(YES), ORACLE (NO)
3. Co-exists with other HA solutions - IDS(YES), ORACLE (NO)
4. R/W on all nodes - IDS(YES), ORACLE (NO)
5. Configure in <1 hour - IDS(YES), ORACLE (No, days or weeks)
6. Protection from Storage Failure - IDS(YES), ORACLE (No)
7. Protection from Site Failure - IDS(YES), ORACLE (No)
8. Geographically dispersed - IDS(YES), ORACLE (No)
9. Supports all applications without modification - IDS(YES), ORACLE (No)

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

Выделенное -- неправда.
Почему не правда ?

Оракл умеет и так и этак. Выбор лежит на dba.
Если и так и этак - то отчасти это правда !!! Допустим, что в какой-то версии ORACLE
есть механизм, позволяющий обойти проблемы множественных клиентских соединений.
А как на счет управляющих процессов, которые выполняют сложные SQL-запросы ?
Как они зависят от транзакционной нагрузки ? Как ORACLE взаимодействует с планировщиком операционной системы ? Умеет ли он динамически перераспределять ресурсы на уровне сегментов памяти, внутри сегмента памяти, на уровне пула процессорных ресурсов, динамически устанвливать приоритет выполненния SQL-запросов для конкретного SQL-запроса, , создание многомерной кластерной таблицы (например как в DB2) и т.д. ?

Насколько Я помню,
ORACLE не поддерживает мульти-поточность на UNIX -с системах !!!

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

... RAC же это shared-disk кластер, технология гораздо сложней банального standby, соответственно и возможностей администрирования на ходу и 24/7 предоставляет много больше. ничего похожего ни в IDS ни в Db2 просто нет.

Ну батенька Вы загнули ... :) ... В IDS есть MACH11 (SDS) в DB2 DPF !!!

[quot GVF112GVF]
2. ...
у db2 по сути нет кластера, потому и маркетологам оно не надо. shared nothing архитектура бесполезна на большинстве нагрузок, понятно, что такого кластера DB2 и не надо.


Это кто Вам такую чушь сказал ? Есть и еще какой (см. выше - SAP BI, SAP R3 и т.д.) !!!

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


Клиетам предлается более эффективная технология и дешевая !!!
Зачем мне Ваш RAC - с потенциальным пробоем в дисковой стойке, с проблемами синхронизации нод (shared - архитектура), с проблемами переноса приложений (которые должны быть адаптированы к RAC) к безумной стоимости решения ?

Что вы будете делать когда объемы базы возрастут в 10, 100, 1000-раз - увеличивать RAM и количество CPU на каждой ноде ??? Проще ставить громадного монстра или сразу покупать System z (мейнфрейм) ?!

RAC совершенно другая технология, призванная по настоящему балансировать любую нагрузку
Да,
если у Вас нет выхода и приходится использовать решение на ORACLE. А как на счет паразитного трафика между нода, проблемами синхронизации кэшей, блокировок, архитектурных ограничений технологии ORACLE RAC ? Или Вы решили убедить меня в том, что таких ограничений нет ?!

Вы правы - совершенно другая технология ... :)

в моем примере было 5 нод, т.е. при падении одной из нод 80% пользователей вообще ничего не заметят (остальные 20% потеряют аж минуту) ...


Сомневаюсь - транзакции будут утеряны. Почему бы не вырубится дисковой системе ?

... HADR же вурибит всю кантору

Не вырубит. Если используется DB2 DPF + HADR - тогда один раздел с данными временно будет не доступен (< 10 секунд) другие ноды будут доступны (точно так же как и у ORACLE).

ну зачем же сочинять ? к примеру в amazon уже 16 нод RACа, а вот в чем смысл 1000 shared-nothing нод db2 хоть убей не пойму ...


Я еще раз подчеркиваю,что мы говорим не о крайностях (исключениях) - речь идет о типовых решениях !!!

Возможно, что у ORACLE есть пара десятков установок с max 16-нод ... возможно.
Речь шла о том, что ORACLE - плохо масштабируется горизонтально в силу архитектурных ограничений !!!

Очень жаль, если Вы этого объективно не понимаете.

что умеет Data Guard и не умеет HADR я уже http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardHADR.html]озвучивал.


Пускай себе умеет.
Возможно, что в нем есть что-то такое которое не пригодится в случае использования DB2 или Informiх ... :) Пусть администраторы ORACLE используют эти особенности.

это не я должен доказывать, это IBM должен доказывать, что Informix на что-то способен публикуя результаты в промышленных тестах. на данный момент Oracle занимает если не лидирующие, то борется за лидирующие позиции во ВСЕХ промышленных тестах от TPC-C и TPC-H до SAP-SD. IBM же по каким-то причинам стесняется публиковать такие результаты, хотя я уверен если бы у Informix было бы все в порядке с масштабируемостью, такие результаты были бы давно опубликованы.

IBM доказывает, что ее технологии имею опеделенные преимущества:
- 8 of the top 10 U.S. Retailers
- 20 of the top 25 U.S. Supermarkets
- Every VISA transaction authorization in U.S.
- United States “911” Emergency System
- etc ...

Теперь относительно тестов TCP.
IBM сознательно не проводит тесты TCP для Informix для того, что бы не возникало
конкуренции между IDS и DB2 !!! Сервер IDS - позиционируется исключительно для OLTP-решений
(может использоваться и как DSS для отчетный систем). Для OLCP-систем (OLTP+DSS) или DSS-систем - использовать DB2 !!!

Теперь относительно тестов - DB2 Crushes Oracle in TPC-C
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

Почитай здесь на счет фактов
http://www-306.ibm.com/software/data/db2/press/ciba.html
или здесь http://www-03.ibm.com/solutions/sap/index.jsp?re=boost

или где-то еще

ПРОЕКТ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ IBM DB2 9.x
Анализ эффективности затрат на совершенствование коммерческих систем SAP
http://download.boulder.ibm.com/ibmdl/pub/software/dw/ru/download/DB29fSAP.pdf

IBM IDS ROI Tool for Continuous Availability
http://www-306.ibm.com/software/data/information/ids-roi-availability.html

SAP Standard Application Benchmarks
http://www.sap.com/solutions/benchmark/index.epx

Думаю, что этого достаточно.
Смотри выше по ленте (ранее обсуждалось).

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

как печально, RAC даже r/w не на всех нодах оказывается умеет ...
Конечно не умеет ... если данные находятся на одной ноде ... как другие ноды могут записать этот же набор данных.... без синхронизации изменений данных в блоке ?!!!

Что удивляет - синхронизации данных или то, что в один и тот же момент времени
уникальные данные может писать только одна нода ?

... зато IDS по щучьему велению и с помощью белой магией научился защищать такой-же как у RAС единый сторадж и пускать на standby r/w приложения (вероятно шаря блокировки через HDD

Да научилась и научилась еще чему-то .... :) ... что в этом плохого.
Другая технология - более детально читай IDS MACH11 !!!

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

Журавлев Денис http://www.google.com/trends?q=informix%2C+db2%2C+oracle]Нам не нужны перфораторы, нам нужны отверсия. А ВСЕ пишут софт только для оракла.

Google как поисковик хороший - во только с WEB 2.0 справиться не может ....более 30% сайтов уже не индексирует ...

Пускай себе пишут для ORACLE (PeopleSoft, Sibel - это ORACLE) ... :)
Новые модули SAP - исключительно на IBM DB2 !!!

Мало кто и под что пишет - пишут и под MySQL, MS SQL, .... и т.д. ...
.... мы Вас в десантные войска определим ... так Вы там и под ... DB2/informix ... писать будете ... :)

Уже один такой пример есть - 1C под DB2 !

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

Поэтому я не спрашиваю у Вадима и Николая почему IBM до сих под не делает(публикует)
ТПС тесты для Informix. Если для этого есть сугубо технические причины, я бы хотел бы знать какие.

Ответ на этот вопрос был дан директором центра разработки INFORMIX - Jerry Keesee (IBM Lenexa)
на конференции IBM Informix в Москве - IBM не проводит тесты TCP для Informix что бы не возникало конкуренции между IDS и DB2.

Думаю, что Анатолий Лой поддержит меня в данном вопросе (как один из участников, который задавал подобный вопрос) ... :)

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

и еще ... см. выше ....

Дело в том, что Informix требует еще меньше аппаратных ресурсов чем DB2 и ORACLE.
Вот, что пишут наши эксперты - IBM Informix Dynamic Server 11 The Next Generation in OLTP Data Server Technology (ftp://ftp.software.ibm.com/software/data/information/ids-ebook.pdf):

Page-7
--------------
In fully utilizing the hardware processing cycles, the IDS data server requires less hardware power to achieve performance comparable to or better than other data servers.
In fact, real-world tests and customer experiences indicate that IDS needs only 35 percent to 50 percent of the hardware resources to meet or exceed the performance characteristics of single-threaded or process-based database servers.

Справедливо нужно отметить, что IDS хорош на OLTP-задачах.

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

... информикс не супортит, т.е. информиксу остается лишь TPC-E, а там вероятно будут рулить сервера с версионным механизмом и неблокируемым чтением и IBM не хочет пока туда суваться.


Возможно .... время покажет ... :)

Новый сервер Informix 11.5 (да и DB2 9.5) поддерживает оптимистический алгоритм блокировок (как у
ORACLE) и пессиместический алгоритм для совместимости с более ранними версиями.


приходите в "сравнение субд", я с радостью попробую разжувать как синхронизируется блоки RAC, что такое resource governor, почему не стоит сравнивать тесты tpc, на диаметрально разном железе, когда там же есть тесты на практически идентичном железе и почему даже с помощью магии SDS не сможет гонять r/w транзакции на stanby нодах ...[/quot]

Спасибо за приглашение. Будет время зайду ... :)
Как работает RAC - Я знаю, знаю и его болевые точки.

Теперь относительно сравнений - есть у меня сравнительный тест ORACLE 11.g и DB2 9.5 на одном железе .... IBM Power6 4.7 GHz !!!

Не хочу Вас расстраивать - 76 cores of Oracle to equal DB2 on just 64 cores !!!

Думаю, что все остальное понятно.

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

Кроме Валерия Кравчука, и Дениса Журавлева( о своей кандидатуре я скромно умолчу), на этом форуме я не знаю людей способных объективно сравнивать архитектуры Oracle vs Informix.
По этому считаю перенос обсуждения началом бессмысленного флейма.

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

На этом форуме есть достаточно толковых людей, способных объективно оценивать границы применимости той или иной технологи - Василий Шульженко, Анатолий Лой, и т.д.
Другое дело, что крайне важно понимать эти границы.

Каждая технология имеет право на существование. У ORACLE есть очень интересные feature!
Если компании будут улучшать свои технологии в результате конкурентной борьбы - выиграют многие заказчики.

Я думаю, что вопрос в цене на билет .... :)

p.s. Я езжу на шевроле , а хочу ездить на БМВ, это не мешает мне хотеть, но есть обьективные обстоятельства по которым я не могу себе позволить ездить на БМВ, тоже касается и людей понимающих преймущества Informix , но неимеющих возможности его использовать в повседневной работе. На мою обьективную оценку Вы можете полностью расчитывать , если будут приведены соответствующие факты и аргументы.

PS: Аргументов и фактов - вполне достаточно. Другое дело, насколько они Вам нужны в Вашей повседневной работе.

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