авторнаверно это самое лучшее - я понимаю как взять 8-ку на посмотреть - скачать с сайта Sybase. 9.0.1 на посмотреть как будто не отдают, или я не знаю куда смотреть...
Отсюда качаете ASA 9 Developer Edition. В отличие от MSDE у нее нет никаких ограничений по обьемам БД и кол-ву подключений (см.
FAQ ). Далее можно
отсюда выкачать апгрейт до версии 9.01 и последний EBF.
авторСгодится ли 8-ка как приближение, или все-таки 9-ку поискать. Вопрос задал несколько поздновато, решение практически принято, вот если в последний момент что всплывет.
Честно говоря - большой разницы именно по скорости между ASA9 и
MS SQL2000 на текущих объемах увидеть не ожидаю.
В любом случае БД с 7-ки придеться оптимизировать. Причем я ожидаю, что на таком обьеме данных при простой перегонке БД без оптимизации скорее всего даже MSSQL покажет более высокую производительность, чем ASA9, но при наборе большего кол-ва данных все равно просядет и так же потребует оптимизации. Так же на чашу вешов в пользу ASA9 я могу подкинуть более граммотные средства оптимизации запросов по сравнению с MSSQL, где графический план запросов еще сам поддчеркивает критические места запросов, консультант индексов может работать в скане всех запросов к БД, профайлер ХП и триггеров может вылавливать критические места прямо построчно по коду скриптов, а дебаггер позволяет не только во время точек останова просматривать значения переменных, но и выполнять запросы и смотреть на них планы запросов.
авторМеня больше замечания о надежности беспокоят и какое-нибудь сопоставление механизмов backup|restore интересно было бы увидеть.
С надежностью все в порядке - БД на 9-ке сложно грохнуть, есть механизм Checksum, который ставит контрольные суммы на каждую страницу БД и сверяет ее при чтении страниц, что позволяет СУБД сразу же выявить сбойные сектора накопителя или несанкционированное изменение базы данных. Ну а методов онлайн и оффлайн резервирования базы данных вообще целое множество - полный Backup, нарастающий, с обрезкой лога, живой (то есть сразу на СУБД другого сервера), методом создания копии, по сети (то есть файл бакупа на другую машину) и т.д. Восстановление аналогично очень многофункционально, вплоть до того, что при разрушении БД и остающегося в живых лога, можно с последнего бакупа поднять БД и дать указание СУБД наложить на него лог разрушенной БД, то есть поднять до последней завершенной транзакции. Вообще в ASA9 просто прекрасный по описаниям всех принципов работ и функциональности BOL, рекомендую ознакомиться в нем по всем интересующим вопросам, он поставляется вместе с Developer Edition и обновляется вместе с каждым патчем (так как ASA в отличие от MSSQL продолжает функционально эволюционировать каждый месяц, вместе с ежемесячным обязательным патчем).
А вообще резюмируя могу сказать, что тут конечно же от ручек и знаний зависеть будет. Лично я могу про себя точно сказать, что я могу на ASA9 организовать эффективную работу баз данных большого обьема с большим кол-вом подключений и без меньших затрат (я бы даже сказал геммора), чем отличный специалист на SQL2K, причем даже не я, а более опытный и граммотный - у меня просто на руках будет больше козырей (возможностей), которые позволят писать меньше кода и обходить острые углы, которые из за ограниченности присутствуют в MSSQL. Чтобы не быть голословным на вскидку приведу некоторые из них в MSSQL:
1. Траблы с кластерными ключами и множественными вставками записей.
2. Траблы с блокировками и деадлоками.
3. Ограничения с работой в ХП и триггерах типом Text и ограничения на максимальный размер VARCHAR в 8 кб убирают много хороших плюсов использования динамического SQL.
4. Сам оптимизатор запросов не любит не динамического SQL, ни использования функций или переменных в запросах.
5. Хранимые процедуры компилятся по существующей статистике, статистика обновляется можно сказать принудительно.
6. TempDB - это целая отдельная история, которая может спокойно вылиться в отдельный геммор.
Плюс мне нравиться в ASA:
1. ХП компилятся при запуске БД и первом к ним обращениям, статистика автокоррелируется самим оптимизатором запросов по принципу - я предположил, я выполнил, я проверил на сколько ошибся, я поправил для себя статистику и свои планы запросов
2. Интелектуальный блок ведения кэша планов запросов, который отслеживает эффективные планы, кэширует и в дальнейшем проводит выполнение запросов по ним, не строя заново планы, но через определенные промежутки времени ради интереса заново строя новые планы, чтобы проверить, а не устарели ли существующие.
3. Наличие глобальных сессионных переменных вкупе с ХП, инициализирующейся на каждое подключение дает неограниченные возможности по инициализации сессии и выведения в такие переменные с таблиц констант, испольщующихся в запросах.
4. Наличие локальных и глобальных временных таблиц, которые кстати могут быть нелогируеммыми (NOT TRANSACTIONAL). Неплохо повышает скорость работы. Плюс глобальные временные таблицы сессионные, то есть она создается как постоянная таблица, однако каждая подключающаяся сессия будет иметь в такой таблице свои данные и не видеть чужие. На такие таблицы еще можно вешать триггеры, на которых потом элементарно можно сделать разброс изменяющихся в времянке данных по постоянным таблицам БД (фактически сделать аналог INSTEAD OF вьюверов MSSQL).
5. Однозначно нравиться отсутствие Master и TempDB - скопировал БД на другой сервер и успокоился, никаких забот о переносе юзеров, грантов, настроек на эффективную работу темповой БД и т.д.
6. Более интеллектуальный оптимизатор запросов, который действительно сам может корректно строить планы запросов в зависимости от заполнения данных, нагрузок, и даже характеристик железа, для привязки к которым существует специальный оператор тестирования их характеристик.
7. Ну и главное - постоянная эволюция и эффективная служба поддержки, где любой специалист вправе на их форумах быстро получить помощь напрямую от команды ASA, выложить найденный баг и получить его исправления через 1-3 месяца в зависимости от его критичности. От себя только могу сказать, что с февраля команда ASA исправила 6 моих заявленных багов, включила в список расширений к 10 версии мои действительно полезные пожелания.
Из вышесказанного, я могу примерно набросать, когда полезно использовать ASA9:
1. Продукт тиражный
2. Продукт должен не требовать администрирования
3. Продукт должен быть не требовательным к аппаратной части, но масштабироваться до любого уровня аппаратуры
4. Продукт должен иметь в составе недорогую СУБД
5. Продукт должен иметь эффективный механизм репликаций
6. Продукт рассчитан на веб и должен граммотно работать с XML, HTTP и веб-сервисами
7. Продукт используется в кач-ве OLTP с достаточно мощной и сложной бизнес-логикой на борту средствами языка хранимых процедур СУБД.
8. Продукт позиционируется как мобильное приложение для КПК.
9. Продукт распределенный, где по местам OLTP СУБД должны быстро собирать и обрабатывать информацию, сливать ее в центр, где стоит OLAP/DSS сервер, который на себя берет аналитику и выборки по большим массивам данныз (в данном случае очень эффективно получается ASA + IQ, у которых общие корни развития WatcomSQL).
10. Требуется перспективная надежная быстро-развивающаяся промышленная кроссплатформенная СУБД для бюджетных и военных организаций, подтвержденно эксплуатирующаяся в мире - в общей сложности по миру официально зарегистрировано 8 миллионов инсталяций, доля в мире СУБД для КПК у ASA - 80%, клиенты - многие крупные авиалинии (например Британские Авиалинии), железнодорожные компании (ASA запущена как СУБД управления и обслуживания электропоездов Голландии), нефтедобывающие компании (Китайский нефтекомплекс, теперь судя по всему Лукойл), а так же военные программы: НАТО (программа Виртуальный солдат), Королевские вооруженные силы (СУБД для управления и координации тактическими силами) и т.д. Все это можно прочитать в историях запуска проектов ASA
здесь .
11. Требуется повышенная защита доступа к информации (поддержка криптографии по 128 ключу криптографии БД, лога и временных таблиц).
12. Требуется работа в режиме чтения с сжатыми БД (поддержка read-only archive database).
Ну а когда полезно использовать MSSQL лучше, если Вам скажут сами специалисты MSSQL со своей точки зрения (например для организации кластеров или работы множества БД, обращающихся к друг другу на одном инстансе ASA явно не подходит). Я вообще слышал вплоть до таких мотиваций выбора MSSQ, что там DTS есть, или диаграмки графические рисовать можно - бред конечно, но факт :) От себя могу сказать только одно - я 4 года работал на MSSQL, реализовыван на нем и БД с сложной бизнес-логикой на TSQL (расчет энергопотребления промышленными абонентами по схемам подключения, расчет зарплаты, расчет кварплаты). Но вот уже полтора года работаю с ASA9 (еще с полгода с ASA8) - и я просто приятно поражен и восхищен этой СУБД, которая развивается в сторону удобства и функциональности, причем именно для меня, а не маркетингова отдела Sybase и на которой я на всегда забыл слово "Геммор". Это конечно мое личное мнение и личный опыт использования и я наверное имею ее право похвалить, так как все таки считаю, что неплохо изучил ее вплоть до внутренних механизмов работы ASA и могу достаточно обьективно оценивать данную СУБД со своей колокольни :)
