c127
Ну ASA близка к MSSQL, так что если пользоваться только TSQL, то наверное добиться одного клиента на ASA и MSSQL можно, хотя и сложно, отличий все равно много. Так что или у них вся бизнес-логика на клиенте или они одновременно 2 БД проектируют с учетом довольно таки разной архитектуры транзакционной модели и эффективности использования оптимизатора. В обоих случаях тормоза на ASA можно схлопотать порядочные, да и на MSSQL тоже :)

авторА что значить "трехэтажный запрос" применительно к ASA ?
Просто интересно.
У меня например в проекте "расчет зп" на ASA9 довольно шустро одним запросом считаются нарастающие с начала года по текущий месяц включительно, благодаря новым возможностям OLAP в ASA (PARTITION BY), результат перекладывается в времянку, а далее уже рассчитывается одним запросом с использованием этой времянки подоходний налог по всем сотрудникам, который учитывает нарастающие, налоговые вычеты, резиденство и налоговые шкалы (на текущий момент там всего одна запись - 13%). По обьему скрипт расчета подоходнего не маленький и там используется множество подзапросов, CROSS JOIN и LEFT JOIN. Самое удивительное, что довольно шустро работает и строиться приличный план запроса. В этом плане ASA действительно очень красиво оптимизирует - ради интереса я сравнивал аналогичные запросы у MSSQL 2000 и ASA 9.01 на одинаковых по структуре и содержанию БД и для "хитрых" (или можно еще сказать не красиво построенных) запросов ASA умудрялась производить разбор запроса, пересоединение таблиц в другом порядке (а то и просто выбрасывая таблицы, которые только служили для соединения между другими таблицами запроса, полезной нагрузки не несли и главное можно было обойтись без них) и выдавала на выходе более эффективный план запроса. Я не хочу сказать, что у MSSQL2000 плохой оптимизатор - наоборот, он очень мощный и навороченный, однако чтобы им эффективно пользоваться необходимы хорошие и глубокие знания архитектуры и принципов работы MSSQL, ASA же наоборот гарантирует, что как бы плохо не был написан план запроса, она его выполнит более менее эффективно. Раньше это выглядело бы смешно и действительно частенько ASA могла уйти в глубокий table scan, однако ее оптимизатор постоянно прогрессирует и сейчас на текущий момент по моему личному убеждению ничего смешного уже для конкурентов ASA нет по следующим причинам:
1. Существует возможность автоматической калибровки оптимизатора к показателям накопителей (оператор ALTER DATABASE CALIBRATE), позволяющего не гадать на кофейной гуще, за сколько времени считается информация с винта, а при построение запросов учитывать реальные характеристики железа
2. Работает эвристический анализатор запросов, поддерживающий автокорреляцию статистики и отслеживание лучших планов запросов с последующим их сохранением в кэш БД (т.е. планы живы даже после рестарта БД). Он отвечает за самообучение оптимизатора запросов по данным в БД и гарантирует что в независимости от содержания и кол-ва информации в БД оптимизатор будет знать ее текущее состояние и строить адекватные запросы.
3. Встроенна автоматическая поддержка RAID-массивов, гарантирующая, что оптимизатор всегда при построение планов запросов будет правильно выбирать, где лучше вести последовательное, а где параллейное чтение таблиц и индексов.
4. Синтаксис SQL расширен дополнительными конструкциями описания виртуальных представлений запросов, рекурсивных запросов, внутреннего соединения подзапроса с основным запросом (LATERAL соединение), а так же всевозможных OLAP расширений (PARTITION BY, WINDOW, RANGE и т.д.). По всем расширениям оптимизатор запросов имеет собственные специализированные алгоритмы для построения плана запроса, поэтому такие расширения с одной стороны развязывают руки программисту при построении сложных запросов, с другой стороны помогают оптимизатору запросов сразу уловить, что конкретно должен выполнить запрос и выполнить это в наиболее оптимальной форме, чем если бы действие, описанное на обычном SQL делилось на несколько запросов, с использованием времянок или циклов.
5. Поддерживаемый для программиста уровень блокировок как "всегда ROW LOCK" снимает с программиста задачу самому отслеживать, чтобы во время операций не было заблокировано лишних записей и не возникало deadlock-ов. Фактически ASA имеет довольно граммотный механизм блокировок, в которых при возможности без дополнительных последствий автоматом задействуются PRIMARY KEY и UNIQUE и программист при построении запроса всегда может быть уверен на 100%, что блокируются только те записи, которые он и предполагал заблокировать. Так же для уменьшения времени блокировок в ASA реализована модель обработки CONSTRAINTS и BEFORE триггеров во время ведения блокировок. В результате этого, если например должно измениться миллион записей и уже на второй становиться известно, что запись неудовлетворяет условию, ASA снимает блокировки, которые успела поставить и прекращает операцию изменения, откатывая начавшуюся транзакцию (откат все таки происходит по причине того, что в BEFORE триггерах возможно были изменения на обрабатываемые записи). Так же на уровне READ COMMITED открытые курсоры блокируют только текущие записи, а не все.
6. Модель нежесткой кластеризации таблиц с одной стороны в ASA, в отличие от MSSQL приводит к тому, что таблица может быть фрагментирована и для ее дефрагментации по кластерному ключу необходимо вставлять записи с указанием сортировки, приблеженной к кластерному ключу и периодически ее перестраивать с помощью команды REORGANIZE TABLE (к ее чести она не блокирует таблицу и разрешает всем продолжать с ней работать). Сама ASA по возможности старается новые записи вставлять в те странички, которые ближе по кластерному ключу, но опять же только при условии не снижения скорости вставки. Однако такое казалось бы неудобство оборачивается явным преимуществом по сранению с моделью кластарных индексов в MSSQL, так как там из за того, что MSSQL всегда при добавлении или изменении данных перетряхивает таблицу согласно ее кластерному индексу очень часто возникают случаи блокировок последней страницы таблицы, приводящие к тормозам при параллейной работе по вставке и изменению записей множества сессий. Лично мне легче в ASA периодически дефрагментировать таблицу, чем бороться с различными ньюансами блокировок в MSSQL (достаточно посмотреть на форум MSSQL - там блокировки и кластерные индексы - достаточно популярные вопросы)
7. Поддержка различного размера страниц в БД (от 1 до 32 кб), позволяет проектировать эффективные БД для различных задач, где при небольших обьемах БД и мощности серверов достаточно использовать страницы малого обьема, а при построении например аналитических хранилищ использовать большие по размеру страницы. В MSSQL размер страницы 8кб и точка, что не есть хорошее решение по моему скромному мнению
8. Модель работы компилятора ХП, представлений и триггеров в ASA организована так, что они компилируются при первом к ним обращении, однако планы запросов не привязываются к ним, а складываются в общий кэш наравне с планами запросов, непосредственно вызванных сессиями, что соотвествующе с одной стороны снимает всякую необходимость периодически обновлять статистику БД, выполнять перекомпиляцию ХП и гарантирует, что запросы в ХП будут наравне с остальными выполняться по лучшим планам запросов, составленных оптимизатором, что я тоже считаю большим преимуществом по сравнению с MSSQL.
9. Ну и в дополнение для облегчения тюнинга запросов в ASA существует прекрасная возможность создавать виртуальные индексы, которых не существует физически в БД, они не блокируют при создании таблицы, однако ASA учитывает их при построении графического плана запроса и позволяет программисту поэксперементировать с индексами и прикинуть, что и как. Так же этими виртуальными индексами активно пользуется служба "Консультант индексов", которая перехватывает поток запросов к БД, анализирует их и пользуясь такими индексами "прикидывает", а что собственно говоря можно улучшить. Причем рекомендации даются в виде 2 графических планов запросов "Как есть" и "Как может быть". Так же для тюнинга ХП существует служба "Профайлер ХП", отслеживающая все выполнения ХП, UDF и триггеров и показывающая, кто сколько выполнялся, с детальной расшифровкой времени выполнения каждой процедуры по ее строкам. Эта служба позволяет моментально "вычислить" узкие места системы, которые потом можно элементарно отладить с помощью встроенного дебаггера и графического плана запросов (в дебагере позволяется выполнять любые запросы во время точки останова).

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

авторКритично ли время выполнения SUM/GROUP BY?
В ASA 9.01 кстати появилась новая опция БД: OPTIMIZATION_WORKLOAD = MIXED/OLAP
При значении MIXED ASA при оптимизации запросов для сессии использует алгоритмы, подходящие более OLTP, а при OLAP начинает использовать алгоритмы для OLAP задач (алгоритмы хеширования групповых запросов, в т.ч. с использованием кластерного индекса). Так что развитие по аггрегатным операциям в ASA не останавливается и наоборот они сейчас аккуратненько "слизывают" самое лучшее из Оракла и DB2.

9-ая ASA вообще то уже часто используется именно как Enterprise, а не как Workgroup. Достаточно посмотреть на Story на iAnywhere.com :) От себя могу сказать из личного опыта, что гонял ее на БД 5-15 гб, с табличками по 5-15 миллионов записей и ничего страшного обнаружено не было. Если граммотно сделаны индексы и кластерные индексы, а так же запросы нормально написанны и их план приличный, то даже на серваке с гигом памяти все просто летает. Хотя заметил одну вещь: ASA очень чувствительна к методам проектирования БД: если БД красиво и правильно спроектирована, то и СУБД быстро работает по ее структуре, а если в конечном счете запросы: сплошные внешние соединения, участие по соединениям множества таблиц с огромным кол-вом записей и т.д. - то тут MSSQL прилично делает ASA благодаря своей способности на одну таблицу задействовать в запросе множество индексов.

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

P.S. Ну а про то, что у Вас решения на MSSQL тянут лучше, чем на ASA, так это тоже просто - проектировалась одна БД под 2 абсолютно разных по архитектуре СУБД и не важно, что там TSQL одинаковый. Как итог - решение не оптимизировано не под одну из СУБД, так как различий на уровне оптимизации как раз у ASA и MSSQL гораздо больше, чем например, у ASE и MSSQL (TempDB, лог-журнал, блокировки, принципы работы кластерных индексов, даже поведение оптимизатора при различных уровнях изоляции). По сравнению с 8-кой у MSSQL мощнее оптимизатор не под "заточенные" решения, поэтому быстрее он у Вас и работает. Я думаю, если взять Ваши затыки в ASA и ручками поработать, то выровнять скорость с MSSQL будет можно, только вот совместимость с ним пропадет, вернее уже решения на нем пойдут в тормоз. Ну а если вместо TSQL на ASA задействовать WatcomSQL и перевести на 9-ку, то можно будет вообще получить очень неплохие результаты по скорости работы, обьемам БД и кол-ву подключенных пользователей (особенно если вспомнить специальные OLAP фунции и алгоритмы хэширования, NOT TRANSACTIONAL времянки и т.д.). Я пару раз переводил с MSSQL2000 на ASA9 действительно большие БД (от 10 гб), после ручной оптимизации для ASA одна очень сложная ХП расчета, затрагивающая большие обьемы данных и работающая на MSSQL ровно 40 минут у меня отрабатывалась на ASA9 ровно 31 сек. Хотя далее я опять же ручками провел оптимизацию в MSSQL и сумел сократить время выполнения до 16 минут, что лишний раз подтвердило мою аксиому, что сравнивать СУБД лучше при больших нагрузках, но не на кривых решениях (разве что Оракл под эту аксиому не попадает, в этом плане ему все фиолетово, так как там все равно все ручками и делается).

Баги есть везде. Вопрос только, у кого они быстрее исправляются. Зайдите на форум MSSQL и посканьте его - и сервера просто так виснут до перезагруза и Access Violation с остановкой СУБД периодически появляются и БД в SUSPEND уходят с порчей лога.

Ну а насчет слабой надежности полностью не согласен - что у меня, что у моих друзей крутяться немалые по обьему БД с большой нагрузкой и ничего не портиться и не вылетает (причем есть реально работающее огромное аналитическое хранилище данных на базе ASA9, с кучей сервером, подвязанными как Remote Server к центральному хранилищу). Вылетает только на появляющихся фичах в новых EBF, я отловил с конца февраля 6 штук, заявил в Sybase, уже в мае они все были пофиксены (сейчас мной заявлено и зарегестрировано еще 2 бага, скорее всего они будут уже исправлены в следующем EBF) . Ну а баги, обнаруженные в MSSQL мной и коллегами тоже оперативно ... были занесены Micsrosoft в MSDN, что конечно приятно с точки зрения заботы о пользователях, но не очень полезно с точки зрения борьбы с багами. Ждать их новый сервис-пак годами и молиться, чтобы в него вошли исправления багов - лично мне это не нравиться.

P.S. Давайте кстати подведем итог так: у меня был удачный опыт использования ASA, а у Вас неудачный. Признайте, что просто так БД не портятся ни в одной СУБД, в основном это проблемы железа. Просто так запросы, которые долго работали сами по себе не вылетают, это или накатили непроверенный EBF, где есть эти проблемы или же неправильная настройка сервера. И т.д. и т.п. Я лично считаю, что проблемы можно обсуждать только указывая на причины их возникновения, у меня тоже например в MSSQL базы улетали, но это были проблемы железа, поэтому обвинить MSSQL в том, что он портит БД я не могу. Зато могу указать на конкретные проблемы с float, TempDB, кластерными индексами и времянками, которые действительно возникали по вине MSSQL и в дальнейшем были исправлены в его последующих сервис-паках (шаманским путем было выявлено, что и где было исправлено).

Согласен, только одно хвалить не стоит. Но и не стоит забывать, что ASA8 и ASA9 довольно таки разные уже СУБД по возможностям и наворотам. Было бы здорово конечно услышать от Вас мнение о 9-ке на Ваших БД, так что если решитесь переводить и будут какие нибудь вопросы/проблемы, то с удовольствием помогу в решение проблем и тестах 9-ой версии.

авторASCRUS, а как Ваше мнение о select * from big_table. big_table напр. 1.5Mln строк, resultset - 20000 /300kB/.
Скорость такого SELECT-а зависит только от скорости жесткого накопителя, пропускной способности сети и драйвера доступа к СУБД. Это тоже самое, что сравнивать, в какой ОС быстрее обычное копирование файлов по сети работает :)