Я - автор этой самой "галимой" "аналитической" статьи, которая так разочаровала Scott Tiger-а. Я собираюсь поспорить со второй частью данной им оценки:

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

А именно, про наличие фактических ошибок. Про поверхностность или тенденциозность спорить не буду - это первоначально вообще были тезисы одного весьма давнего (конец 2001 года) доклада, с вполне определенной и обоснованной, по опыту компании ProFIX, позицией. Тезисы, которые можно развивать и обосновывать, при необходимости.

"Итак, по пунктам:"

"1. Предисловие
--------------
Непонятно проведение аналогий 7.31 -> 9.21 - насколько я могу судить, 9-я версия отличается, в основном, расширенной функциональностью, вроде даже весьма заметно расширенной. Поправьте, если не прав, 9-ку не пользовал."

9-ку большинство использует как 7-ку с меньшим количеством ошибок. Не так уж много "бизнес-приложений" (о которых и шла речь в статье), скажем, банковских систем, использует технологию DataBlade, хранимые процедуры на Java и объектно-реляционные расширения. Используют 9-ку как обычный реляционный сервер, на который многие перейти были просто вынуждены, например, при смене версии базовой ОС или из-за наличия серьезных ошибок (например, 7.31UC6 для Solaris 8 x86 не позволяет взаимодействовать с удаленными базами данных на той же Solaris 8 и, как следствие, выполнять репликацию, - вот вам и причина перехода на 9.21 на этой платформе). Аналогия вполне обоснована и реальна.

"2. Установка сервера
--------------------
Я абсолютно убеждён, что любым делом должен заниматься профессионал, в том числе и установкой программного продукта. Особенно это касается таких традиционно сложных и тяжёлых приложений, как СУБД. Таким образом, отметаем "В идеале, заказчик, при наличии...". К тому же, я не встречал необходимости настолько часто переустанавливать СУБД, чтобы время инсталляции играло хоть какое-то значение. Если так уж нужно тиражировать (по тем или иным причинам) инсталляции СУБД, в юниксах это легко делается банальным копированием инсталляционной директории, для Oracle - точно, для Informix - не знаю, но на 99,9% уверен, что тоже. В виндах ситуация обратная, опять же, думается для обоих продуктов."

Да, но "профессиональный установщик программных продуктов" - это уж слишком. Профессионал должен написать один раз сценарий установки или инструкцию по установке. А сидеть и тыкать мышкой в кнопки на экране профессионал не должен - я в этом абсолютно убежден.

Компания ПроФИКС занимается технической поддержкой многих десятков клиентов в банковской сфере. Не в каждом Крыжополе есть профессионал, способный самостоятельно решить любые проблемы с установкой или резервным копированием. И не всегда можно и финансово оправдано командировать профессионала или обучать клиента. Поэтому чем проще эти процедуры для СУБД - тем проще сопровождать свои программные продукты на этой СУБД.

Добиться такой простой и автоматизированной установки можно и в Oracle (если знать, как работает Universal Installer и как ему подложить соответствующие файлы), но в Informix - это намного проще, и работать будет быстрее. Это утверждение и доказывается данным разделом статьи. Оно абсолютно соответствует моему опыту - я ставил Oracle многие десятки раз, версии от 7.0.16 до 9.0.1, на разных платформах. Я ставил десятки раз и Informix, от 7.13 до 9.30, правда, только на Intel-архитектурах. Так вот, процедура установки Informix всегда была и остается проще, она легче поддается автоматизации, и требует намного меньше ресурсов. Точка.

"Конфигурацию для промышленной инсталляции надо делать руками...
Сетевая конфигурация средствами Net8 Configuration Assistant, в частности, выполняется только самая примитивная. Ну и т.д."

Согласен. Ну и зачем тогда такой GUI-шный инсталлятор и средства конфигурирования у Oracle? Жрущие столько ресурсов?

"...если сложно поднять X-сервер, то это уже, простите, клиника. Хотя не спорю, лень. Сложно понять, почему использование JRE - недостаток (или преимущество) - это фича. "

Берем хорошую, современную серверную материнскую плату на 845 чипсете от Intel, хорошую ОС Solaris 8 x86, и поднимаем X-сервер на встроенной графике в VGA-режиме. Другой эту плату не поддерживает. Очень удобно в нем с OUI работать... Или нам рядышком Linux|Xfree86 ставить? Я - поставлю, а администратор в Крыжополе (райцентр в Винницкой области) как будет работать? Использование JRE в процессе установки - "фича", усложняющая сам процесс установки. Хотя и позволившая Oracle больше не заниматься созданием новых инсталляторов для разных платформ.

"На UNIX-платформе в процессе установки требует не менее 128 Мб ОЗУ..." - глюки JRE, наблюдается в некоторых версиях и на некоторых платформах. Не смертельно, в конце концов."

Требование 128 Мбайт ОЗУ - не глюк JRE. Это так Oracle инсталлятор написал. Жрущий ресурсы и требующий конкретной версии JRE. Ставили когда-нибудь Oracle 8.1.7 на Linux, уровня Red Hat 7.2? Популярное сочетание. Надо загрузить отдельный, специальный JRE, для него - специальную версию glibc, еще одну фигню, прописать кучу всего ручками... (А перед этим найти в сети, как все это делать). И это чтобы инсталлятор запустить... Очень удобно.

"... - 10 минут, бесспорно, чудовищное время. несколько часов - это только с созданием новой базы разве что."

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

"Требует согласованного изменения большого количества параметров ядра для успешной установки. Стандартные значения, предлагаемые руководством по установке, не всегда адекватны" - неправда."

Иногда - правда (хотя, если внимательно читать документацию, действительно, всегда все запускается). Пример - Oracle 8.1.7 на Solaris 8 SPARC. Берем стандартную установку PROCESSES и стандартные значения параметров IPC (не рассчитанные по указанной формуле, а приведенные как достаточные по умолчанию). Получаем проблему нехватки семафоров и не запускающийся сервер.

Берем Informix, читаем значения параметров в Release Notes, ставим - и все работает, со стандартным файлом ONCONFIG. В моей практике - всегда все работало. И параметров ядра надо менять меньше. В Oracle 8.1.6 для UnixWare 7.1.1, помнится, десятка два необходимых параметров были в документации перечислены...

"...Всё-таки мы про администраторов говорим, а не про домохозяек."
Ну, и зачем администраторам инсталлятор OUI?

"Однако, стоит признать, что многопоточный сервер работает плохо, в некоторых случаях от > него приходится отказываться."

Потому что за уши притянут. Если в Informix и есть что-то хорошее, так это прозрачная и масштабируемая многопоточная архитектура сервера.

"Не более 32 Кб пользовательских сеансов для экземпляра" - что-то совсем непонятное. Автор количество процессов в килобайтах меряет, что ли. Одним словом, глупость"

Признаю. Лень было написать 32767. Первая фактическая ошибка. Но проблема остается - больше одновременных сеансов сервер не поддерживает в принципе. Отсюда и тяга Oracle к серверам приложений...

"Не выполняется локальная дефрагментация страниц данных" - боюсь, не понял термина "локальная дефрагментация".

Речь идет о перестановке строк в пределах страницы (блока) так, чтобы все свободное место было представлено одним куском.

"... и возможность работы с базами данных и таблицами без журнализации транзакций" - в Oracle тоже."

Я не говорю, что работа без журнализации - это хорошо. Но, позвольте спросить - и как это сделать в Oracle, чтобы операторы INSERT, UPDATE и DELETE не генерировали REDO- и UNDO-информацию? Подобное утверждение - это уже ваша ошибка.

"Количество файлов данных - до 2048" - ну и чёрт с ним. В жизни не встречается."

Автоматически ограничивает размер базы - 2048 * 2 Гбайта. Oracle потенциально поддерживает базы данных намного большего размера. Хотя да - для нас это не существенно.

"Отсутствие стандартных средств трассировки и документирования хранимого кода" - чем автора не устраивают комментарии в теле, например, процедуры? Куда уж "стандартнее"?

Речь идет об операторе TRACE в SPL, позволяющем направлять отладочную печать в файл, и конструкции DOCUMENT там же (CREATE PROCEDURE). В этой конструкции можно задать описание процедуры, которое легко и эффективно выбирается затем из таблицы системного каталога sysprocbody. Не надо строки с комментариями искать в тексте процедуры. Вот в чем идея.

"Нетрадиционная поддержка временных таблиц" - использование временных таблиц практически никогда не требуется. Подобного рода вопросы разрешаются за счёт более функционального SQL."

Согласен - не нужны они, особенно в Oracle. Но зачем Oracle вообще их добавил? Зачем плодить сущности? Да еще и такие своеобразные...

"Последние 2 пункта обвинения характеризуют специфичность Oracle, а не недостатки, тем более что, положа руку на сердце, с такой концепцией работать удобнее, чем с "традиционными" несколькими базами данных и временными таблицами в других СУБД (Informix, MS SQL Server и т.д.). Просто надо понять и принять."

"Стандартные средства документирования и трассировки в SPL" - уже писал выше, что неясно, что понимать под "стандартным средством документирования". Комментарии? Они везде есть. И что понимается под "стандартным средством трассировки"? Какая-то пока глупость.."

Выше уже написано, о чем идет речь. Это не глупость - просто вы не знаете SPL.

"Автоматическое определение ряда оптимальных параметров конфигурации при установке" - совершенно не ясно, что автор имеет в виду."

Я имею ввиду те размеры областей SGA и файлов данных в табличных пространствах, которые предлагает OUI (в зависимости от объема ОЗУ и выбранного администратором назначения системы и набора компонентов). В Informix вам никто и ничего не предлагает.

"Кластеры как средство эффективного хранения связанных таблиц - я бы поспорил насчёт эффективности. Кластеры хороши для хранения сложных, редко изменяющихся справочников из-за проблем с производительностью операций вставки/обновления/удаления в кластерах."

То-то у Oracle почти весь словарь данных сделан на кластерах. Чтобы проблем было побольше с эффективностью... А есть еще хэш-кластеры и однотабличные хэш-кластеры, - там вообще другие проблемы с производительностью операций вставки/обновления/удаления... Кстати, а в "бизнес-приложениях" знаете сколько этих нечасто меняющихся справочников имеется? Десятки и сотни.

"Относительная сложность конфигурирования (более 180 параметров конфигурации)" - больше возможностей настройки. Это, господа, преимущество, и важное."

Просто система - сложнее, компонентов - больше. Кому - преимущество, а кому и нет. Пока не разберется, как эта сложная система устроена. Автомат Калашникова почему популярен - прост в изготовлении и эксплуатации.

"Отсутствие простых, стандартных терминальных средств (удаленного) администрирования" - враньё. ВСЕ задачи администрирования Oracle решаются стандартным и весьма удобным и функциональным средством командной строки sqlplus."

Согласен, в sqlplus можно сделать все. Но не все знают - как. Если бы это было просто и доступно - зачем Oracle Enterprise Manager, а прежде - SQL*DBA и svrmgrm... Текстовые формочки и окошки - полезная вещь для начинающих. И ресурсов требует - минимум.

"Контроль сервера только с помощью SQL через многочисленные (более 120) представления динамической производительности. Требует знания SQL и подготовки" - автор, очевидно, хочет, чтобы каждая домохозяйка могла быть DBA?

Нет. Но выполнить несколько опций onstat (под диктовку по телефону) и переслать результат в службу поддержки сможет и домохозяйка - а это хорошо.

"К тому же, стандартные (входящие в комплект поставки) графические средства администрирования позволяют контролировать почти всё то же, что и доступно через системные вьюхи."

Написаны эти стандартные средства на Java, написаны, мягко говоря, не оптимально - тормозят и жрут ресурсы. Поэтому так любит народ другие графические средства для Oracle использовать и создавать...

"Необходимость отдельного администрирования пользователей базы" - не понял, что имеется в виду. Или автор предлагает средствами операционной системы давать гранты на select из таблиц?"

Нет. Речь идет о том, что Oracle поддерживает свою систему учетных записей пользователей и свои пароли. Пользователями этими и паролями надо отдельно заниматься. Кстати, чтобы от этой проблемы избавиться, Oracle теперь поддерживает аутентификацию операционной системой и прокси-аутентификацию. Informix использует средства аутентификации и управления учетными записями операционной системы.

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

Автор имел в виду фрагментацию (partitioning у Oracle и fragmentation у Informix) - возможность создавать таблицы и индексы в нескольких табличных пространствах, в терминах Oracle.

"Возможность контроля сервера с помощью SQL-запросов (SMI)" - плохо документированная, к сожалению."

Да, а вот словарь данных Oracle и представления V$ очень хорошо документированы... Все их прекрасно знают и эффективно используют. ;)

"Адекватная система защиты на базе привилегий и ролей" - адекватная чему? В Oracle возможностей больше."

Адекватная требованиям бизнес-приложений архитектуры клиент-сервер. А у Oracle возможностей больше почти во всем...

"Использование аутентификации пользователей операционной системой снимает задачу ее отдельного администрирования" - и добавляет гимора."

Приведите пример, пожалуйста, этого добавленного "гимора".

"Простая и эффективная система фрагментации таблиц и индексов" - не понял.

А вы вообще про фрагментацию в этих СУБД что-то знаете? RTFM.

"Простой механизм уведомления об основных событиях и проблемах сервера" - лог? В Oracle тоже есть, разумеется."

Кроме журнала сообщений, лога, речь идет об автоматическом вызове указанной программы при наступлении определенного события. С передачей информации о событии. Задается параметром ALARMPROGRAM. RTFM. Вы в Oracle будете на cron задание вешать и логи разбирать? Очень удобно...

"Обеспечивает многократное резервирование системных файлов" - не системных (таких нет), а управляющих."

Помимо управляющих файлов, речь идет также о журналах повторного выполнения (REDO logs), которые можно мультиплексировать на сколько угодно дисков.

"Обеспечивает резервное копирование и восстановление на уровне табличных пространств (т.е. вплоть до фрагментов таблиц), при условии резервного копирования журналов, и экземпляра в целом" - таблица находится всегда в одном табличном пространстве, так что ошибочно заявление про "фрагменты таблиц"."

Опять двойка... Таблица не всегда находится в одном табличном пространстве. Какая полезная штука - фрагментация (partitioning), а мы про нее ничего не знаем... См. оператор CREATE TABLE и CREATE INDEX.

"К тому же, экземпляр - это набор процессов и структур памяти, поэтому получение их резервной копии - задача, мягко говоря, нетривиальная и совершенно не нужная."

Но зато как придираемся к словам. Никто не собирается процессы и память копировать. В Informix под резервным копированием экземпляра (instance backup) иногда подразумевают резервное копирование всех (а не отдельных) пространств хранения данных, dbspace. Все, не буду больше этот термин употреблять.

"Сложность организации оперативного резервного копирования (при работающих пользователях)" - ничего сложного. Файлы данных по очереди переводятся в специальный backup-режим (1 команда), копируются на уровне ОС, возвращаются обратно. Набор восстановления - вот такие копии файлов + набор архивных журналов с момента начала копирования + копия контрольного файла. Справедливости ради следует сказать, что "горячее" резервное копирование несколько замедляет работу (несильно).
"Сложность организации параллельного резервного копирования и восстановления" - ничего сложного."

Речь идет о том, что это немножко сложнее, чем:

ontape -s -L 0

или

onbar -b -L 0

соответственно.

"Авторизованный учебный центр - единственный..." - не единственный (в Москве, во всяком случае)."

Речь шла об Украине в 2001 году.

"Активная дискуссионная группа ukr.comp.dbms.informix позволяет оперативно обсудить проблемы с другими разработчиками и администраторами" - чуть ли не единственная русскоязычная..."

А много и не надо. Надо активное и знающее сообщество специалистов (или хоть один, дающий ответы по делу и с удовольствием). Для поддержки Oracle вполне достаточно сайта asktom.oracle.com. Но он - англоязычный.

Резюме
----------

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

Комментарий - тоже так себе... Автор плохо знает СУБД Informix, и далеко не все еще знает о СУБД Oracle. Написал бы хоть про многовариантную согласованность (multiversion consistency). За одно это СУБД Oracle можно простить все недостатки...

Кто сравнивает - тот проигрывает. Я это давно знаю.

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

В. Кравчук
http://ln.com.ua/~openxs

Спасибо за комментарий. Мы практически сошлись во мнениях. ;)

Статья, даже не статья - тезисы, весьма старые. Призвана была показать, почему, при всех преимуществах Oracle, в определенной среде и для определенного класса приложений использовать Informix удобнее и проще.
Это утверждение, по-прежнему, мне кажется похожим на правду. И статья намеренно должна была вызвать поток возмущения со стороны Oracle и оракловской общественности, но им на это было наплевать. Вы - первый серьезно откликнувшийся с этой стороны.

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

Рассылка по Oracle начала выходить намного позже, через полгода.

Серьезные же публикации по сравнению СУБД, несомненно, нужны и интересны. Просто их мало - производители коммерческого софта нынче не приветствуют сравнения, да и сложное это дело. Надо одинаково хорошо знать сравниваемые продукты и ставить чистые эксперименты... А кому это надо, из тех, кто мог бы?

С наилучшими пожеланиями,

В.К.