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чку просто пока отложили.

Марсель Это случайно не описанная вами проблема?
Да, это близкая проблема, но не та. Так скажем, случаи поломки не кончились.

Off: Меня совсем недавно поразил другой случай. Была некая БД под линуксовой АСА9, база лежала на файловой системе ext-3, которая собственно является журнальной. И вот в один прекрасный день, анализируя логи, я увидел, как драйвер ext-3 проводя процедуру восстановления системы после вырубания питания воссоздал состояние файлов БД по состоянию за ЧАС до отключения. В логе АСА, однако, отчетливо были приписаны проведенные за потеряный час чекпоинты, в логе клиентского ПО - проведенные базой операции и УСПЕШНОЕ выполнение commit'ов... Вывод об откате в файлах я сделал по полному отсутствию каких-либо данных и упоминанию о них в БД и в оттранслированном логе.
Принимая во внимание последнее, я уж точно и не уверен, что АСА9 единственная "виновница". Ведь между ней и диском еще столько посредников, драйвера и кэши, программные и аппаратные. Я не понимаю, почему бы в АСА не сделать также, как и в тех СУБД, которые не пользуются файловыми системами, а хранят данные непосредственно на выделенных разделах носителей. Обеспечивая полный контроль, и за кэшированием, и за журналированием, и за успешностью проводимых операций I/O. А они только версии гонят вперед, форматы файла меняют...