Хоть это и старая новость, разработчиков Oracle заслуженно можно поздравить - ещё в ноябре они оказались первым в индустрии, взявшими важный барьер в один миллион tpmC. Но самое главное, случилось то, о чём всё время говорили большевики - Intel, который-де не умел делать серверные процессоры, продолжает всех надёжно и стабильно задвигать уже в High-End. Даже если через некоторое время его и выкинут с первого места - из больших дядек его уже выпереть будет сложно. Кто бы мог подумать ещё 5 лет назад, что то, что получится из PC-серверов будет самым быстрым в TPC-C по абсолютным показателям и это будет не одиночным результатом?
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
После появления версионности в Yukon я думаю Oracle обречен. .Базы где версионности нет (DB2) будут считаться игрушкой вроде MySQL (это была провокация )
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Dmitry67 wrote:После появления версионности в Yukon я думаю Oracle обречен.
A pochemu ? Vpolne serjezno bez podkolok. Chto takogo pojavitsia v Yukone chego nebylo by uzhe v Oracle ili ne budet cherez dva goda ?
Pritom, chto Oracle na svoj DB produkt tratit namnogo bol'she chem MS.
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
В общем говоря, они после этого сравняются
То есть с появлением версионности в MS SQL Ораклу его будет просто нечем 'упрекнуть'
И наоборот, в MS SQL вообще говоря нет того чтобы не было бы в Oracle.
Итак они сравнялись по возможностям
Что выберет пользователь ?
Бесспорным козырем MS SQL яваляется администрирование. Сервера работают месяцами и никто к ним не подходит. Многие MS SQL server DBA никогда не перестраивали индексы.
А вот знакомый у меня из фирмы где был MS SQL попал в фирму где Oracle. Короче, он его возненавидел. КАЖДЫЙ день что то происходит, чтото надо делать, профилактика таблиц с переливом постоянная.
Итак это пункт первый
С другой стороны, у Oracle есть неоспоримое маркетинговое преимущество - многоплатворменность. Да и какой нибудь SAP R/3 перетаскивать на SQL если он работает уже на Oracle никто не будет
Но у M$ есть еще одна карта которая не разыграна пока - это их новая операционка со встроенным MS SQL. На мой взляд, это повторение ходя с IE. Помните как он выбивал Netscape ? Если он уже встроенный, То зачем ставить чтото другое ? А если у вас уже стоит MS SQL, и все это так классно интегрируется с .Net и друг с другом, то... короче, это сильный ход.
На ближайшую перспективу конечно Oracle ничего не угрожает, но речь идет о системах которые будут закладываться сейчас или через несколько лет и войдут в строй лет через пять.
Маркетинговые же перспективы же DB2 мне непонятны.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Странно, МС сам говорит что администрирование как-раз оставлиает желать намного лучшего и они над етим очень сильно работают (Черт не могу ссылку наити)
А нащет равных возможностей - .НЕТ дает те же возможности, что и Й2ЕЕ (хотя ето ИМХО и не так)и где же победное шествие по планете ? по netcraft.com Апаче - абсолиутный лидер(А OAS за Апачем работает ) и долиа МС постоянно уменьшаетсиа.
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
Посмотрим
Еще и не такое будет
Вот M Аксапту прикупил. Кто такая аксапта по сравнению с SAP R/3 ?
Когда M прикупил Sybase, тоже ьыла маааленька)я Sybase и большой такой Oracle. А что сейчас ?
ВОт я думаю лет через пять SAP R/3 будет сильно потеснет M на рынке ERP или что там будет тогда
Я это говорю с неким страхом. M не любдю но маркетинг у них на высоте
А про администрирование странно... Проблемы есть, но по сравнением с Oracle... MS SQL может администрировать индус после двухнедельных курсов
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
Тем более странно
Уж администрирование DB2.. даже если не брать майнфреймы то все равно. Просто чтобы сделать stored proc, надо компилятор и еще потанцевать вокруг всего этого чтобы встало
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Dmitry67 wrote:Но у M$ есть еще одна карта которая не разыграна пока - это их новая операционка со встроенным MS SQL. На мой взляд, это повторение ходя с IE. Помните как он выбивал Netscape ? Если он уже встроенный, То зачем ставить чтото другое ? А если у вас уже стоит MS SQL, и все это так классно интегрируется с .Net и друг с другом, то... короче, это сильный ход.
В Longhorn не будет сколько-нибудь полноценной версии SQL Server. Там планируется иметь новую файловую систему, построенную на базе ядра SQL Server и имеющую массу дополнительных по ставнению с обычными файловыми системами возможностей, которые будут доступны через Longhorn API и на которые будет опираться и ОС, и приложения. Но работать с этим как с обычной СУБД будет проблематично. Это даже не MSDE. Поэтому и формально, и реально оно не будет полноценной заменой SQL Server. Это скорее попытка создания ниши для нового класса приложений где операционная система берёт на себя обеспечить хранение локальных данных почти на все случаи жизни.
Location: Irkutsk.RU -> Hamden, CT-> Princeton, NJ, USA
Postby oMoses »
Dmitry67 wrote:А вот знакомый у меня из фирмы где был MS SQL попал в фирму где Oracle. Короче, он его возненавидел. КАЖДЫЙ день что то происходит, чтото надо делать, профилактика таблиц с переливом постоянная.
Это не вина Oracle, а людей при нем. "Профилактика таблиц с переливом постоянная" - если они там от балды сделаны, то ничего удивительного в этом нет.
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
Странно, МС сам говорит что администрирование как-раз оставлиает желать намного лучшего и они над етим очень сильно работают (Черт не могу ссылку наити)
Администрование бывает разное - SQL Server безусловно удобнее для большинства систем небольшого размера без изысков. Преимущество Oracle начинается там, где нужны нетривиальные повторяющиеся действия - Oracle позволяет лучше автоматизировать сложные вещи. В настоящий момент как раз наблюдается встречное движение: у Oracle появилась тенденция упрощения работы как с обычными вещами, так и для более-менее продвинутых случаев, а SQL Server подчищает недостатки администрирования при управлении сложными сценариями в больших установках.
nec wrote:Я, видно, туп совсем стал - не могу найти 10g Database ни на OTN, ни за деньги...
Еще не выложили для общедоступного download. Ждите.
What's the target date, do you know? Thanks.
Сушествует только Beta- версия, но она недоступна пока public. Нам прислали диск, мы поставили, но без документации (а еще никакой технической доки нет пока) не совсе понятно че-там поменялось и чегосмотреть ( симулировать ТПСС я не хочу - я ваще на них не смотрю).
Немного изменился процесс инсталяции.. Ипо слухам они переписали ядро... Так как последняя версия инсталяшка была на 3-4 СД а эта (хоть и бета) - всего на 1-м. Наш Оракл эккаунт менеджер сказал что 10G будеет скорре всего в конце 2 квотера ,или в начале 3-го...
Кстати, на OTN можно подписаться на нотификейшн , они вам кинут мыло со ссылкой как только появится 10G.
Представляют интерес позиции 5, и 6 в таблице результатов TPC-C. Oдна и таже техническая и системная платформа. Оракл и DB2. Результаты отличают меньше чем на 1%, цена за транзакцию на 3%. При этом мы помним (правда?) что DB2 - блокировочник, а Оракл - версионник.
zVlad wrote:Представляют интерес позиции 5, и 6 в таблице результатов TPC-C. Oдна и таже техническая и системная платформа. Оракл и DB2. Результаты отличают меньше чем на 1%, цена за транзакцию на 3%. При этом мы помним (правда?) что DB2 - блокировочник, а Оракл - версионник.
Эти платформы далеко не равноценны - посмотрите на дисковые подсистемы. DB2 показал результат близкий к Oracle на системе с 26 оптоволоконными периферийными контроллерами работающими примерно с 2000 дисков. Oracle для похожего результата нужно было задействовать 66 оптоволоконных периферийных контроллеров примерно с таким же количеством дисков. Вывод отсюда, похоже, простой - в обоих случаях CPU/память использовались на полную катушку, однако DB2 заметно лучше работает с вводом/выводом. Oracle для достижения той же пропускной способности понадобилось почти в три раза большая полоса ввода/вывода. Можно ли отсюда выудить связь с архитектурой сервера БД? Видимо можно. Но не следует забывать, что TPC-C - нагрузка очень удобная именно для блокировочника и версионник по сути дела никаких своих преимуществ показать здесь не может.
Конечно очень любопытно, за счет чего 10й Оракл показал такие результаты, учитывая, что 9й серьезно проигрывал.
Но вот еще какой вопрос покоя не дает. Если посмотреть на результаты теста tpc-H, то Оракл там малозаметен, а на первых местах в основном DB2. Хотя казалось бы у блокировочников с ad-hoc запросами врожденная проблема, а версионникам сам бог велел в таких тестах всех на клочки рвать.
Означает ли это, что у Оракл не самый удачный оптимизатор или есть другое, более прозаичное объяснение?
Merle wrote:Если посмотреть на результаты теста tpc-H, то Оракл там малозаметен, а на первых местах в основном DB2. Хотя казалось бы у блокировочников с ad-hoc запросами врожденная проблема, а версионникам сам бог велел в таких тестах всех на клочки рвать.
TPC-H - это на 99% readonly тест, поэтому ad-hoc или нет, версионник опять же не имеет никаких особенных преимуществ.
Merle wrote:Конечно очень любопытно, за счет чего 10й Оракл показал такие результаты, учитывая, что 9й серьезно проигрывал.
Тут может быть много объяснений: системы о которых идёт речь - первые в своём роде 64 процессорные Intel Pentium; Oracle имеет большой опыт работы с системами такого масштаба на спарках, поэтому сам продукт уже давно этот путь прошёл. Чего нельзя ещё сказать о Windows + SQL Server и что только частично верно для DB2 под Unix; Oracle в 10g мог исправить наиболее вопиющие недостатки - например, улучшить сканирование индексов, не говоря уже о более глубоких изменениях в ядре. Как только они опубликуют более подробные сведения о продукте - будет понятнее.
(Черт не могу ссылку наити)
) и долиа МС постоянно уменьшаетсиа.