Возникла такая ситуация - полностью портировал структуру БД с Sybase ASE 15 на MSSQL 2008. При этом никаких изменений ни в стркутуре таблиц, ни в текстах ХП не потребовалось.
Т.е. можно со 100% уверенностью сказать, что структуры БД полностью идентичны.
Далее перелил данные из Sybase в MS. Т.е. и по данным обе базы стали полностью идентичны.

А теперь главная фишка - MS при этом работает раза в 3-3,5 быстрее чем Sybase.
Никаких шаманств с МС в плане настройки производительности не делалось (равно как и с сайбезом)... Т.е. оба сервака по дефолту устанавливались...

Отсюда вопрос: почему у Сайбеза такой проигрышь в производительности?

2 Компостеров :Страница сервака 2к. Паралельные запросы включены.

2 Ggg_old : в том-то и дело, что довольно долго бился с производительностью АСЕ. По отношению к первоначальной производительности получил на АСЕ прирост в 1,5-2 раза (за счет индексов и парсинга запросов - неоднократно и здесь темы поднимал).

2 MasterZiv : в какой-то степени "быстрометром" :). Есть ПОшка, которая делает обращения к базе через ADOQuery, StoredProc и т.п. Перед началом запроса (Active := true) пишется в лог дата/время со строчкой "Бегин", сразу после Active := true стоит запись в лог даты/времени со строчкой "Ендид". Дык вот, разница временных показателей для сайбеза и МСа как раз обозначилась в 2.5-3 раза...

Т.е. если при Сайбезе открытие окна, сопровождающееся вызовом ХП, происходит в среднем за 28-31 секунду, то на МСе это же действо пробегает за 9-10 секунд. Если построение отчета на Сайбезе занимает приблизительно минуту (ФастРепорт в качестве генератора отчета), то на МСе те же данные вылетают секудн за 20 максимум.

Как еще замерить? Есть ли какие-либо "официальные быстрометры" - готов запользовать их.

З.Ы.: ну и в конце концов вызов хранимой процедуры в обертке на таймер никто не отменял:


Вообщем МС пока в основательном плюсе

Да кстати, забыл отметить МС и Сайбез крутятся на одной машине. Замеры производились при "тушении" конкурента.

Ggg_old, ну вообще задачи ДБА на меня ложаться в последнюю очередь :)
Поидее у нас есть отдельный отдел, который должен этим заниматься, НО для себя определенные выводы я сделал: вот объясните мне с позиции директора конторы - зачем ему держать двух спецов (дба + разработчик), либо одного из красной книги, совмещающего в себе обе эти свойства да еще из отряда сайбезоговорящих, если можно взять одного толкового МСника?

С размерами страниц - на досуге поиграюсь - скажу результаты...

на счет того, что MSSQL заберет все что есть - говорю же опыты производились, когда конкуренты были задисаблены. Т.е. работает Сайбез - молчит МС, работает МС - дисаблен сайбез.

Честно говоря меня больше всего интересует вопрос - возможно ли добиться на сайбезе большей производительности, нежели на МСе :)...
Ибо при прочих равных (платформа - винда) МС, к сожалению, на мой взгляд, выигрывает...

MasterZiv , как бы то ни было, АСЕ имеет много подводных камней, которые необходимо учитывать при использовании. Все-таки задачи ДБА и программера - несколько разные задачи.
Можно кончено программить с учетом особенностей администрирования сервера АСЕ, но все-таки, на мой взгляд более глубоким администрированием и настройкой производительности должен заниматься другой чел, либо программеру необходимо на это выделять отедльное время.

К сожалению, не встречал еще ни одного начальникам, который последний пункт воспринимал адекватно.
По крайней мере мне никогда не удавалось провести отдельным пунктом оптимизацию работы БД. Либо приходилось чуть увеличивать время на разарботку (что не всегда возможно - начальник просто не понимает, почему на эту задачу нужно столько времени - там же все просто! - напиши запрос и все, а то, что надо соптимизировать работу запроса - хотя бы поиграться с планами - это не воспринимается), либо просто делать "Как есть" - в результате рано или поздно производительность падала до минимума и тогда начальство после криков о криворуких программерах, не умеющих писать нормальные запросы - выделяло время на оптимизацию работы системы В ЦЕЛОМ.

По опыту оптимизация запросов может занимать время сравнимое с половиной времени, затрачиваемых на реализацию самой логики... Может я ошибаюсь?

Вот такая вот суровая реальность. Хочется надеяться, что не у всех так сложилось...