>Данных в БД относительно немного (от 1-й до примерно 500000 записей), но довольно сложная бизнес-логика, много различных потоков репликации и "чудовищные" требования к интерфейсу клиентов (АРМы оперативных работников). В общем, довольно сложная распределённая система, да ещё и в реальном времени должна работать. И что-то всё как-то медленно начинает елеворочаться.

Это нормально. У меня была аналогичная ситуация: юзеры (~20000 шт, ожидалось 5*10**6), группы, права на доступ к неким объектов (~50000 шт) и группам объектов, права наследуются в группах юзеров и группах объектов. Задача: определить имеет ли юзер v право смотреть объект w. Все реализовано чистым скл без сохраненок и временных таблиц. MSSQL 2000 (основная база) просто зависал напрочь, сайбейз анивер (тестовый пример) выполнял по 30 запросов в секунду. Все таблицы, въю, данные одинаковые, индексы тоже одинаковые, оптимизированные в меру сил под MSSQL.

MS техсаппорт долго думал, признал, что вроде формально все сделано правильно, и посоветовал менять структуру БД. Что и было сделано: появилось 6 триггеров, вспомогательная таблица прав и вероятность внести дополнительные ошибки. Еще замедлился инсерт, но это уже другая история. И даже после этого сайбейз работал быстрее.

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

>Я думаю, на одинаковом железе и при одинаковой квалификации разработчиков и админов скорость должна быть одинаковой. При низкой квалификации разработчиков и админов MSSQL многие ошибки простит, и сам что-то оптимизирует, хотя замедление может быть раз в 10 - 100. Но оракл при таких условиях вообще не заработает :-)

Это сказки, распространяемые мелкософтом. Контрпример. Тупое добавление 1000000 записей в таблицу, из иднексов только первичный ключ identity. Еще поле current_timestamp, коммит проходил после каждых 10 записей. Обе СУБД (MSSQL-7 и Оракл 8i) устанавливались по дефолту на чистую вынь НТ, дофига места и пр. Установка прошла без проблем.

MSSQL плавно замедлялся от примерно 6000 записей в минуту в нуле до 1000 при 300000 записях в таблице по кривой напоминающей 1/x или экспоненту, после чего был остановлен (достал уже, часа 3 как работал). Попытки исправить ситуацию провалились: агония повторялась раз за разом. Я и сейчас не знаю, в чем там было дело. Хотя миллионный рубеж таки был успешно преодолен мелкософтом в MSSQL2000.

Оракл загнулся при 800000 (уже больше чем 300000), какой-то там сегмент роста у него закончился. Правда не мучился, в отличии от коллеги, помер сразу. Замедления не наблюдалось и средняя скорость составила ~10000 записей/минуту. При увеличении сегмента повторный тест прошел без проблем. Исправление заняло минут 20 чтения документации.

Низкая квалификация разработчиков и админов налицо, ибо это был наш первый опыт работы с данными SQL серверами, поэтому контрпимер является корректным и следовательно опровергает распространенное заблуждение о легкости администрирования MSSQL по сравнении с ораклом. :) Просто на тех данных, где оракл требует действительно серьезного администрирования, MSSQL не заработает вообще никак, а на небольших объемах и я его (оракл) заставлю работать, хоть и не админ.

Ну накидали, я не ожидал.

2alexeyvg как зачинщику подтемы.

>Но ведь MS SQL 2000 справился с вашим тестом, а Oracle 8i - нет :-)

Это точно, через 2 года, когда появился MSSQL2000 он с задачей справился. А когда проходил тест в середине 1999г. MSSQL2000 был только в проекте.

>А если серьёзно, я не писал, что эти серверы БД идентичны. Я писал, что разница не принципиальна, она не в разы и не в десятки раз.

Как, а это что?

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

Если один работает, а другой нет, то это как раз принципиальная разница.

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

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

Теоретически да, но если для оракла это будут в большинстве "правильные" решения, то для MSSQL-а это будут в большинстве пляски с бубном. А у последних есть такое свойство, что если начал плясать, то остановится удасться в лучшем случае по окончании проекта, а в худшем - только после остановки дыхания.

2tygra
>Угу, а в transaction log то надо писать? Надо! Поэтому при увеличении количества измененных записей он пухнет как воздушный шар - отсюда и тормоза.
И чего-то я не понял, как это коммит проходил после каждых 10 записей? Что это такое и как делалось? А то расхождения какие-то у вас, сэр :)

коммит проходил примерно так, только на TSQL-е:
if (mod(ncount,10)==0) commit;
Тут ncount - переменная цикла. Я тоже на транзакшн лог сразу подумал, симптомы уж очень типичны. Но во-первых commit, во-вторых ведь и оракл туда пишет, или нет?

2f_w_p
>За MSSQL 6.5 подобное нами замечалось. Я даже вопрос сюда выносил. Потом сами разобрались. Дело было в размере кэша под лог. По умолчанию он равен какой-то смешной цифре (~1кб).

Во, это ближе к теме. Я первым делом кинулся искать в документации настройки логов, но не нашел.


Теперь отвечаю всем сразу.

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

Как я вижу была проделана серьезная работа по добавлению 10**6 записей в таблицы разной сложности и это весьма похвально. Я и сам подозревал, что в вычислительной технике за последние 4 года наметился некоторый прогресс и теперь процесс заполнения таблиц проходит значительно быстрее. Ну и что?
А кто проводил тест на MSSQL-7.x? Если есть желание - проинсталлируйте MSSQL, не меняйте ничего в установках, повторите тест. Еще могу добавить, что машина была по-моему 300 пентюх со 128 метрами мозгов. А потом поставьте туда же оракл 8i и повторите. И мы обсудим, с кем из них легче работать.

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

2mumu

DB2 посоветуй. Вроде бы дешевле оракла но ничем не уступает. Если дорого, то выбирай сайбейз ASE или ASA. Если задачки небольшие либо средние (десятки миллионов записей, 10-40 одновременных коннекшинов), то ASA ИМХО идеальное решение, легкая и стоит совсем немного.

На всякий случай: когда я говорил о полуграмотных людях, навязывающих нам дурацкие решения я имел в виду создателей MSSQL и мелкософтовский техсапорт (с которым я имел удовольствие пообщаться). Мне казалось что это очевидно из контекста. К программистам и админам, работающим на MSSQL мои слова не относились.

2 Cat2
Мы так скоро уйдем в область отрицательных чисел и встретим там любителей фокспро и dbf файлов. Это я шучу. Ты пару нулей случайно не забыл? Твой результат отличается от моего почти на 2 порядка. Что я должен был сделать с MSSQL-ем, чтоб он начал считать в 100 раз медленнее? Это нужно сильно постараться, а я не старался.

А какая динамика по времени?
А как оракл себя ведет? Вопрос ведь в сравнении простоты администрирования и работы, а не в абсолютных значениях. Так вот я утверждл, что простота администрирования MSSQL-я (например в ставнении с ораклом) есть сказка для управляющего персонала.

2 чингиз

24 минуты по крайней мере по порядку величины совпадает с ожидаемым результатом. Сайбейз добавлял по 20000 записей в минуту в максимумах, я ему мешал, работая с вордом. Получается 50 мин. на тест. Было еще поле char(32) заполняемое чем-то типа cast(current_timestanp as string). Врядли оно сильно влияет на результат. Я его не упоминал, поскольку в нашем контексте оно не важно.

2 mumu

Не знаю, GUI совсем другое дело, тут нужно выбирать что знаешь и что нравится. Могу только сказать, что например ASA с VB уживаются очень плохо. Это из-за кривой имплементации ADO - DAO, никак не могу запомнить кого именно. С фокспро, наверное будет та же история. Мелкософт вообще не любит чужих продуктов.

А еще можно почитать соседний топик по фокспру и вообще смело выбирать его в качестве сервера. Все равно он скоро вытеснит всю эту мелочь вроде оракла.