ASCRUSP.S. И не очень понятно как баги связаны с моей "корпоративной этикой".
Да не баги, а "хвалебные оды"))

Я про 10-ку не был бы столь категоричным. Пробовал ее нагрузить. Мучился два месяца и ушел обратно на 9-ку. Были и безобидные проявления глюкавости (работа оптимизатора), а были и серьезные камни преткновения (к примеру невозможность создания он-лайн бэкапа). Может сейчас принципиальные моменты и исправились, но в сентябре...
Мериться нагрузками абсолютно бессмысленно, как и продолжать делать выводы основываясь на удачной эксплуатации. Условия эксплуатации видимо у нас разные. Но повторюсь, 10-ка не так хороша, как 9-ка.

P.S.: Хотя и у 9-ки есть один недостаток, отсутствующий в 6-ке. Базу на 9-ке можно убить внезапным отключением сервера по питанию, при нагрузке это происходит с вероятностью 1 к 50. 6-ка же неубиваемая, но и тормозная.

ASCRUSP.S. Кстати падение 10-ки на Вашем проекте таким же образом не дает возможности утверждать в глюкавости 10-ки ... один проект не показатель, никто не знает, что там и как у Вас используется ;) Тем более, что вопросы идущие на саппорт касательно АСА мимо меня не проходят ... особых проблем с SA 10 у саппорта я не заметил.

Да пусть и не показатель, но в моем контексте она повела себя совсем не как 9-ка.
Скажем так, есть сервак, к нему идет по 50 коннектов в секунду, отваливаются по мере завершения работы. Каждое подключение в базе совершает ряд операций с 3 табличками, операции затрагивают от единиц записей до несколько десятков тысяч (чем меньше тем чаще, чем реже тем больше). Есть еще встроеные евенты, они тоже дергают эти таблички и тоже делают операции чтения/записи с ними. А есть еще коннекты которые только делают выборки по этим же табличкам. И эта конкурирующая ботва в круглосуточном режиме крутится. Про бэкап я уже писал - фиг с ним, иначе извернулся. Но 10-ка иногда входила в ступор: полное пожирание одного ядра процессора под 100% и не способность ни дать ответ существующим подключениям, ни принять новые, причем даже отлупа не дает, все запросы на подключения видимо встают в очередь и подсоединяющийся клиент (банальные test ODBC connection) висит в бесконечности. Это состояние может длиться часами, причем запрос на остановку сервера тоже не обрабатывается, на сигнал SIGTERM не реагирует. Такое поведение в моем контексте не допустимо. Я даже не могу сказать, в чем причина и что именно происходит, может это из-за сложности операций и ее заваливают все новые и новые подключения, а может еще что-то - мне не известно. Знаю, что 9-ка работает, и ни разу себя так не вела...

Ggg_oldстало интересно, а за счет 9ка менее устойчива к сбоям чем шестерка?
По моему опыту - да.
На 6.0.4 ни интенсивные манипуляции с данными, ни физ.воздействие на выполняемую среду не приводили к Assertion failed, только отказы железа могли к ним привести. В 9-ке же, и "жесткий трах" посредством SQL инструкций (опытным путем установлено, что как-то связано с типом данных long varbinary), и внезапное выключение питания иногда могут привести к порчи файлов БД и/или лога. Ведь СУБД ведет журнал не просто так и должна быть готова к сбоям питания, раз ответила, что получила комманду COMMIT - будь добра зафиксить все изменения и не терять данные, и уж тем более не портить их, чтоб при следующем старте сообщить, что кто-то изгадил ей жизнь и она работать не будет))).

iLLerASCRUSP.S. Кстати падение 10-ки на Вашем проекте таким же образом не дает возможности утверждать в глюкавости 10-ки ... один проект не показатель, никто не знает, что там и как у Вас используется ;) Тем более, что вопросы идущие на саппорт касательно АСА мимо меня не проходят ... особых проблем с SA 10 у саппорта я не заметил.

Да пусть и не показатель, но в моем контексте она повела себя совсем не как 9-ка.
Скажем так, есть сервак, к нему идет по 50 коннектов в секунду, отваливаются по мере завершения работы. Каждое подключение в базе совершает ряд операций с 3 табличками, операции затрагивают от единиц записей до несколько десятков тысяч (чем меньше тем чаще, чем реже тем больше). Есть еще встроеные евенты, они тоже дергают эти таблички и тоже делают операции чтения/записи с ними. А есть еще коннекты которые только делают выборки по этим же табличкам. И эта конкурирующая ботва в круглосуточном режиме крутится. Про бэкап я уже писал - фиг с ним, иначе извернулся. Но 10-ка иногда входила в ступор: полное пожирание одного ядра процессора под 100% и не способность ни дать ответ существующим подключениям, ни принять новые, причем даже отлупа не дает, все запросы на подключения видимо встают в очередь и подсоединяющийся клиент (банальные test ODBC connection) висит в бесконечности. Это состояние может длиться часами, причем запрос на остановку сервера тоже не обрабатывается, на сигнал SIGTERM не реагирует. Такое поведение в моем контексте не допустимо. Я даже не могу сказать, в чем причина и что именно происходит, может это из-за сложности операций и ее заваливают все новые и новые подключения, а может еще что-то - мне не известно. Знаю, что 9-ка работает, и ни разу себя так не вела...

Да, кстати, 10-ка была взята на обкатку именно из-за возможности распараллеливать на несколько ядер выполнение одного запроса. Но возможно именно это также могло являться и причиной такого стопорения. Железка, как и АСА 64-х разрядная, 4 ядра, 8Гб памяти, база небольшая ~15Гб, ОС RedHat V. Где рылась собака искать сложно, поэтому 10чку просто пока отложили.