Странно все это. У меня личные проекты эксплуатируются на множестве клиентов на базе WIN 2000/XP и далеко не везде есть даже UPS - нигде БД не портилась ни разу. Далее работаю в компании, у которой на базе ASA много лет стоит полноценный биллинг как для себя, так и других компаний - нигде БД не рушилась. Запись в БД естественно для такого класса приложения идет непрерывно по звонкам, оплатам и т.д. Та же самая ситуация с версией под Линукс, работаем на этой ОС правда недолго - около полгода, но проблем данного характера не наблюдается. Видимо зависит от кармы и каких то случайностей, а не от упсов, характеристик железа, ОС и EBF ;)
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase

bindto:
я гонял 10-ку не так много - просто физически было мало на это времени. Однако пришел к выводу, что в ней было приложено много усилий для того, чтобы вывести сервер на уровень обслуживания больших обьемов данных. Введен целый комплекс мер и функциональности, позволяющий:
Увеличить скорость обработки промежуточных расчетов данных на глобальных временных таблицах, где такая таблица может быть не транзакционной и видимой всем (NOT TRANSACTIONAL SHARE BY ALL) - получается аналог MyISAM таблиц MySQL.

Увеличить скорость работы с длинными и BLOB полями посредством поддержки компрессии столбцов и возможности хранения начальной и конечной частей BLOB полей в страницах вместе с полями записей таблицы.

Увеличить скорость обработки длинных запросов путем распараллеливания выполнения этапов запроса между несколькими процессорами.

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

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

Увеличить отказоустойчивость сервера для работы в круглосуточном режиме 365 дней в году путем поддержки онлайн-зеркалирования БД на другой сервер с автоматическим переводом сессий на него в случае отказа работы основного сервера.

Увеличить производительность обработки аггрегатов путем поддержки материализованных представлений, позволяющих хранить предрассчитанные аггрегатные запросы как виртуальные табличные данные БД, с возможностью их использования в запросах как таблиц, так и оптимизации аггрегированных запросов к первичным данным, где оптимизатор может определять по таким запросам, в каких мат представлениях эти данные уже лежат предрассчитанными и вместо выполнения операций аггрегации просто брать данные из мат. представлений.

Расширить поддержку оптимизации OLAP путем возможности задания индексов, оптимизированных по хранению информации для OLAP операций (FOR OLAP WORKLOAD).

Улучшить качество построения планов путем оценки не среднестатических, а физических характеристик накопителей не только привязкой к скорости накопителей (CALIBRATE), но и оценкой производительности параллейного чтения дисков RAID-массивов (PARALLEL READ).

Расширением управляемостью множеством серверов ASA с помощью SNMP Agent и поддержкой в БД Maintance Plan, позволяющим описать штатные профилактические и административные работы по расписанию.

Добавлением возможности ведения отладочных трассировок клиентских приложений для проверки и оценки посылаемых ими команд на сервер.

Введением нового типа данных для поддержки хранения многоязыковой символьной информации (NCHAR) для интернациональных БД, работающих одновременно с множеством языков.

Снижением занимаемого обьема данных индексами в БД путем ввода возможности зашаривания неявных, автоматически создаваемых индексов на PK/UK/FK на явно созданные/

Увеличением скорости сложных расчетов на языке хранимых процедур путем переработки интрепретатора WatcomSQL.

Увеличением защиты обычным и материальных представлений от изменения структуры участвующих в них таблиц БД путем добавления к представлениям поддержки взаимосвязей и статуса их соответствия текущей схеме БД.

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

Возможность управления сборщиком мусора очистки устаревших версий страниц данных (для БД, работающих в режиме версионности), для ускорения выборки информации из БД путем снижения чтения страниц версий.

Оптимизация хранения и обработки флагов в информации путем поддержки битовых массивов.

Поддержка эмулиции мультинитей Windows (fibers) на Unix платформах для уменьшения накладных расходов ОС.
Это что касается добавлений и расширений на сервер. С другой стороны явно на лицо и ужесточение курса на собственное развитие и ввод множества ограничений и удаление функциональности, уводящих ASA с курса маленького брата ASE и роли маленького сервера:

Поддержка outer-join синтаксиса TSQL (=* и *=) обьявлена как нежелательная (то есть она будет снята в следующей версии ASA).

Больше не поддерживаются сжатые БД, для хранения БД на CD производитель рекомендует просто туда писать обычные БД, пользуясь возможностями компрессии столбцов таблиц для сжатия обьема БД и запускать сервер в режиме READ ONLY.

Убраны системные представления и хранимые процедуры, более не существующие в новой версии ASE.

Убрана поддержка Win9x и Win NT4 платформ.

Убраны устаревшие алгоритмы обработки данных из плана запросов (и оптимизатора соотвествующе).

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

ЗЫ: Переход на ASE конечно круто, но к примеру знаю реальные случаи, когда именно из за необходимости увеличения производительности OLTP люди специально с ASE переходили на ASA и получали существенный выигрыш в скорости (при условии конечно, что они не пытались на ASA работать как на ASE)