LINUX.ORG.RU

Нда... самое главное они "забыли" указать имхо... где там у них упоминается число CPU? Я прав что этот вопрос тихо обходится?

Irsi
()

Да там вообще про железо ни слова... Только то что оно одинаковое и отслыают на другой веб сайт где мол вся информация имеется, но где конкретно указать как всегда "забыли". Но я в принципе готов поверить что оракле на НТ не очень, это известно давно и новости собой не представляет. Лучше бы сравнили Спарк линукс с САН на примере Оракле и показали бы на сколько Линукс сосет.

Ogr
()

2Ogr: я готов поспорить что железяка была однопроцессорной... ибо линукс на SMP моментально теряет все свои скоростныен преимущества... Если на однопроцессорной он обычно лидирует (если забыть про современные десктопы и браузеры), то на 2х процах он с нтей идет уже фифти-фифти (где-то опережает, где-то отстает... все очень сильно завист от того что в этой версии ядра опять сломали, а что - опять починили), то уже на 4х процах пролинукс можно забыть... У нти на х86 вообще конкурентов не остается, если не считать за таковых солярку и скотоложников, ныне перекупленных калдерой (специально для красноглазых - пожалуйста не путайте Caldera OpenLinux & Caldera OpenUnix, это принципиально разные ОС!)...

Irsi
()
Ответ на: комментарий от Ogr

Irsi&Org: A если не полениться сходить по ссылке то можно избежать того, чтобы мордой по ней возили потом за очередной голословный бред сивой кобылы и бессмысленное вякание :) "The hardware system was a Fastcenter Sysfast 2 with _twin 1 ghz processors_, 2 gig of ram, and two 10k rpm 160mb/sec disks" http://www.fastcenter.com/projects/project_two/description.htm :))

anonymous
()

Мда, как только показали линк на описание железа разговоры о плохости линукса в smp прекратились. ( 2Irsi: мы говорим про 2.4, так ведь ? )
( 2Ogr: ты оказывается не только hard-links не умеешь делать но и читать ).

2Irsi: Я вод нигде не видел чтобы обсуждали переделки ( глобальные ) в smp которые как ты говоришь планируются в 2.5.

2Ogr: А ты знаешь что такое smp ?

Boo

anonymous
()

Что меня больше всего удивляет, так это то что вместо того чтобы обсудить нормально тему начался просто "словесный понос" или как у нас говорят "пипписьками мерятся" . Противно читать. Кто-нибудь из здесь присутствующих реально Oracle под Linux эксплуатирует чтобы серьезно обсуждать эту тему?

Касательно собственно темы. Лучьше б они тест на 8.1.7 сделали - это сейчас рабочий релиз Oracle. А 9i - сначала пусть его доведут до рабочей кондиции. Еще очень рекомендую походить по сайту SUSE или сходить на Oramag там был пример кластерной системы построенной на SUSE - довольно не слабой.

Linux - уже давно пригоден для эксплуатации на нем Oracle. И сейчас все больше и больше появляется фактов подтверждающих это.Личное дело каждого на чем он будет эксплуатировать Oracle. В нише где используются системы на базе интел (2-4 проц) Linux неплохая альтернатива NT, и потихоньку умирающим Unix для Intel. Скажу больше сейчас просто не выгодно покупать например Sparc нижнего уровня(до 4проц), по той простой причине что платформа Intel быстрей и дешевле в этой категории. Понятно что быстрей это относительно, но простой тест по перебору значений на PL/SQL ( нагрузка ложилась в основном на проц) показал что 1Ghz Xeon работает быстрей чем 450Mhz Sparc. Да в системах Sun крутая шина данных, но толку то от не. Compaq 2x проц,RAM 2GB с 6x18GB(10rpm) стоит порядка 18к. А дальше как в рекламе "Зачем платить больше, покупайте Гала" Конечно Linux на лекарство от всего, но во многих случаях очень даже помагает, по этому мне смешно слышать разговоры про то что "Linux и Oracle" - это не серьезно.

СтранниК

anonymous
()

...и вообще, я не понимаю, что все так вцепились в эти персоналки ?! Какая разница, как работает Oracle под IA-32 под какой угодно OS, под AS/400 он все равно работать будет на порядки быстрее.

yakuza
()

О чём говорить - лишь-бы поговорить... На пальцорастопырках, будем считать, доказали нам, что Линух - сущий тормоз на На симметричных многопроцессорных архитектурах... :).. Ну а в цифири... В цифири дело несколько запутанней. Почему? да просто по сути вопроса. Всё дерьмо СМП заключено в самой СМП. Как описана задача (насколько сильно пересечены адресные пространства) - настолько она и хороша. Теперь к задачам. Если взять тривиальную, с раскидыванием процессов средствами ОС, где наприоритетнейших - по числу процов, то И НТ, и Линух - дело монопенисуальное. А вот далее идут фичи. Внутренняя разбивка на процессы приложения, в частности Оракула, делается... самим Оракулом! (сами почитайте доку, если не верите). А вот почему в настоящий момент 9-ка даже на 4-х кирпичах хуже под НТ? Задайте вопрос Ораклятам, но, ИМХО, ответ будет в стиле :"... Мы используем максимальные возможности, предоставляемые интерфейсом программирования для данной платформы...:)".. и тыры-пыры-ландыши...

Кстати, что цепляться за СМП (?), она реализованна фактицески также как в БСД и НТ.. Мало того - в eXPlosive она фактически НЕ "НТ", а ВСД-лике... :) Да и толку от неё (СМП) - если кластера дают бОльший выигрышь цена/производительность при правильно выГНУтом ПО и при отсутствии "промахов" по железу...

Дикси...

asoneofus
()

2asoneofus: "она реализованна фактицески также как в БСД и НТ"
Перестанте нести чушь. В Линуксе потоки реализованы через тот же fork a.k.a. clone. Что дает о себе знать при переключении контекстов. В НТ потоки могут из начально работать на разных процах, в БСД это только с 5.0 будет возможным. Так что идити и читайте TFM.

Ogr
()
Ответ на: комментарий от Ogr

2Ogr (*) (2001-11-04 20:08:53.0):

> В Линуксе потоки реализованы через тот же fork a.k.a. clone. Что дает о себе
> знать при переключении контекстов.
Ну, то, что ты, как всегда, несешь чушь, я не удивляюсь.
Но тут как раз тот случай, когда ты, наверное, можешь просветить общественность
на тему губительности "fork a.k.a. clone" реализации нитей. Уж ОЧЕНЬ часто
приходится слушать подобные утверждения.

Итак, пожалуйста, намекни, каким образом реализация нитей через clone
"дает о себе знать при переключении контекстов".

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

anonymous
()

Лучше бы были бы тесты Oracle+Win2k/Oracle+Linux.
Вот это было бы интереснее и поучительнее :))))

По своему опыту знаю, что Oracle 8.1.7 на Linux работает медленнее, чем он же, но на Windows 2000 Advanced Server.

Причем по скорости выполнения запросов - 15-20% разницы :(

А про 9-й на Linux ничего не знаю, еще не пробовал. На 2000-й ничего так, работает пока :) Правда как запасной сервер обкатывается.

Eugeny_Balakhonov ★★
()

Eugeny Balahonov
По своему опыту знаю, что Oracle 8.1.7 на Linux работает медленнее

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

anonymous
()

2anonymous (*) (2001-11-04 21:32:52.0): С начала почитай это http://www.dcs.gla.ac.uk/~ian/project3/node31.html потом заглялни в исходники и убедись, что нитка в линуксе это тот же процесс, со всеми его проблемами только память отмаплена на один участок. Если после этого еще остались вопросы, прочти еще раз пока не дойдет, я верю тебе пяти раз должно хватить.

Ogr
()

Ogr, ты дурак или как? нитки в линухе так же как и полагается им быть по POSIX: облегченный процесс, если ты думаешь что раз нити не отображаются в винде в таскманагере то они там реализованы как-то гениально?

anonymous
()
Ответ на: комментарий от Eugeny_Balakhonov

> По своему опыту знаю, что Oracle 8.1.7 на Linux работает медленнее,

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

anonymous
()

Опыт работы с Oracle есть только под соляркой. Но здесь он работает с Raw девайсами. Пробовали с файлами и оказалось, в целом, медленнее. А как NT и Linux - с Raw девайсами работать можно?

alexros
()

Насколько я знаю в 2.4 есть роу девайсы.По моему и в 2.2 с патчами есть.В НТ не знаю, пиздить не буду.Но они не дураки так что в 2000 должно быть.

anonymous
()
Ответ на: комментарий от alexros

Линух работает. В НТ, насколько я помню ддк через ioctl РУЧКАМИ.

zelya
()

Я чего-то не понял. Что Oracle делал-то? Если они внешние данные грузили sqlloader'ом, то непонятно, - кто быстрее - Oracle или sqlloader, если sqlloader - то задача нехарактерная. Очень может быть, что sqlloader подтормаживает, а не сервер. Если схему создавали, то тестом можно пренебречь - опять задача нехарактерная и редкоисполняемая. Камерный какой-то тест.

Полуденный Бес

anonymous
()
Ответ на: комментарий от Ogr

Ой, только не надо про высшие сферы. clone используется для создания 
LWP, и соответственно при использовании bound threads на каждый thread
будет создан свой LWP. Но данное "открытие" не позволяет делать 
страшных утверждений о "реализации потоков в Линуксе". Ибо никто
не мешает использовать unbound threads, которые будут сообща 
использовать один LWP на всех. См. 
http://linas.org/linux/threads-faq.html и в особенности http://linas.org/linux/threads-faq.html#Libs

В НТ... В НТ thread есть страшное ругательство, после которого 
необходимо злобно утверждать что struct _OVERLAPPED гораздо круче
"и ваабще!" ( (c)-unknown ). Т.е. они конечно же есть... можно 
создать thread на каждый accept, к примеру, если о сервере поверх
TCP речь идет...  Только толку от них..





omerm
()
Ответ на: комментарий от Ogr

2Ogr (*) (2001-11-05 00:29:52.0):
Вполне в твоем духе: на вопрос, как ТЫ понимаешь концепцию нитей,
следует RTFM. И ссылку на редкость идиотскую привел.

Хоть подумал бы, о чем тебя спрашивают...

2All:
IMHO, очевидно - Ogr способен лишь повторять общие заклинания, порожденные
маркетоидами для оболванивания массового пользователя. Информация, исходящая
от него, не имеет почти никакой ценности, разве что позволяет изучать
воздействие на психику массового потребителя маркетоидных трюков.

anonymous
()

Эх, бревна не видите. Многим линуксоидам (тем, кто поумнее) не нравятся реализация ниток в линуксе и Линусу уже предлагали их переделать. Он отказывался. И говорил не нравятся нитки - юзай другую ОС.

Havoc ★★★★
()
Ответ на: комментарий от Ogr

2 Ogr: Интересно, а вы знаете как Oracle параллелится? И то что эта БД не является по большому счету многопоточной... То есть, если я беру Oracle Standart Edition (нету там параллеь квери и т.п.) и тестю его сначала на железе с одним процом, а затем на железе с двумя процами, получаю прирост не за счет потоков, а за счет раскидывания процессов (юзер-коннекты, системные процессы, да и то не все... и т.д.). И форкает он иммено новые процессы. Это специфика Oracle.

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

sandman
()
Ответ на: комментарий от Havoc


2Havoc (*) (2001-11-05 14:29:14.0):
>Многим линуксоидам (тем, кто поумнее) не нравятся реализация ниток в линуксе
Ok, ты, вроде, в отличие от Огра, существо мыслящее. Если за свои слова отвечаешь,
(а я уже много раз слышал тут от тебя голословную критику линуховых ниток)
то, плз. поподробнее.

Я читал аргументы Линуса и нахожу их убедительными. С другой стороны,
я ни разу не видел АРГУМЕНТИРОВАННОЙ критики. Обычно это вопли Ява-программистов,
не совсем понимающих, о чем они говорят. "Линус женат на процессах", - вот и вся
аргументация.


anonymous
()

2 sandman

Так-то оно, так, только наличие нескольких процессоров тоже не гарантирует выполения запроса параллельно. Это же не та многопоточность, что в операционной системе. Даже сходство весьма отдаленное.

Полуденный Бес

anonymous
()

Были бы рулезными, не юзали бы по старой памяти fork.
Просто Java активно использует трэды и подход один клиент - один трэд вполне логичен. Но при таком подходе на солярке или на винде жабовская прога чувствует себя намного лучше и может обслужить большее кол-во клиентов.
Зайди в Development, отмотай на страницу назад. Там и ссылочка есть, правда касающаяся ядра 2.2.х.
Смысл таков, что пока еще Linux threads все же тяжеловаты. Зато умеют по процессорам разбегаться. Во фре они полегче но по процам бегать не умеют (есть в 5.0 current), в солярке и виндах они и легкие и разбегаться умеют.
Критиковал я всего пару раз (но никогда не говорил linux mustie), но сами же линуксоиды критикуют больше меня, например на /. в комментариях к какой-то новости (по моему отюда я и пошел туда) и на других сайтах.
Имхо, с трэдами в линуксе еще есть над чем работать. Солярку пока в этом плане можно считать эталоном.

Havoc ★★★★
()
Ответ на: комментарий от Havoc

2Havoc (*) (2001-11-05 16:41:52.0):
> Зайди в Development, отмотай на страницу назад.

Ну, посмотрел. Типа,
> Так JVM на линухе с нативными трэдами при большом количестве трэдов загибается.
> Винды и соляра держат трэды лучше.
Т.е. опять аргументы из разряда
> на солярке или на винде жабовская прога чувствует себя намного лучше
Почему это происходит? IMO это проблема существующих реализаций JVM.

Я не вижу проблем в Линуховой реализации ниток. Не нравятся bound нитки -
юзай либу, реализующую unbound. Только мало кто это делает, ибо при грамотном
программировании (обычно) forkа вполне хватает. А проблема упирается в
менталитет программеров, привыкших к win32.

> Критиковал я всего пару раз (но никогда не говорил linux mustie)
Ну да, под "неоднократной" критикой я имел в виду >1 :), но, согласись,
из твоих постингов вполне можно заключить, что Линух тебе несколько ...эээ...
несимпатичен. Но аргументы, что ты обычно приводишь, напоминают перепевы
маркетоидов. Большинство линуксоидов с ними знакомы и знают им цену.

Да, прошу все сказанное мной в твой адрес расценивать не как накат, а как
пожелание более аргументированной критики, если уж ты критикуешь Линух
на линуксовом сайте.

anonymous
()

я на собственном опыте полтверждаю что Linux по сравнению с NT
на 8-m Oracle на наших задачах по крайней мере на времени установления
соединения на порядок быстрее ,софт конечно написан на VB :(
но с моими тестами на dbi (perl) это согласуется. Причем под NT Oracle
был настроен специалистами их orACLE а под linux мной (нулем по
сравнению с ними). Это был dell 2-processornyi и еще Linux
2.2 кернел . По скорости на select у меня Linux где то был на 10-15%
быстрее.
Uman

anonymous
()

> Почему это происходит? IMO это проблема существующих реализаций JVM.
Может быть. Но на винду получается спортировали лучше, чем на Linux?
Сановцы вроде не дураки. А относительно нормально обрабатывать несколько клиентов в одном потоке на жабе можно только на 1.4. Наконец-то догадались асинхронный IO сделать.

>Не нравятся bound нитки - юзай либу, реализующую unbound.
Unbound можно и ручками сделать :)
Только плохо, что ожидать завершения потока в этом случае становится несколько сложнее.

>Только мало кто это делает, ибо при грамотном
>программировании (обычно) forkа вполне хватает.

Не всегда это удобно.

>А проблема упирается в менталитет программеров, привыкших к win32.

Чем плохо?
Например, был бы IIS не таким дырявым, был бы отличный продукт.

>но, согласись, из твоих постингов вполне можно заключить, что Линух
>тебе несколько ...эээ... несимпатичен

Соглашусь :) Но это мое дело. BSD я тоже могу покритиковать :)
Я буду рад, если Линукс станет мне симпатичен.

Но ты тоже согласись, что если top запросил список процессов, то то, что ему вернули нужно интерпретировать именно как список процессов.
Т.е. это жжж не спроста.
Кстати, где-то можно внятно прочесть, что с трэдами сделали в 2.4.х?

Havoc ★★★★
()
Ответ на: комментарий от Havoc

2Havoc (*) (2001-11-05 19:08:10.0):

>> Почему это происходит? IMO это проблема существующих реализаций JVM.
>Может быть. Но на винду получается спортировали лучше, чем на Linux?
Ну! IMO сановцы привыкли программировать в стиле, похожем на win32.
Точнее, конечно, наоборот.

>> Только мало кто это делает, ибо при грамотном
>> программировании (обычно) forkа вполне хватает.
> Не всегда это удобно.
Мое ощущение - в подавляющем большинстве случаев fork очень удобен.
Привычка, наверное...

>> А проблема упирается в менталитет программеров, привыкших к win32.
> Чем плохо?
Я не говорил, плохо или хорошо. Просто - по-другому.
Нитки используются в NT постоянно, без них просто не обойтись. Соответственно,
это накладывает на программиста отпечаток. Привычку чуть что - поднимать
какую-нибудь "дежурную нить", благо, NTшные "волоски" есть (как и любые unbound
нитки) просто способ вызова процедур, и система их может тысячами держать.

Дело привычки, но, все же, стандартный Юниховый подход мне кажется логичнее.

Мне такая история вспоминается: один мальчик приучил себя есть мастику для
полов. Начал понемножку, а потом ему понравилось. Зачем? - он и сам не знал.
Маленький он был...

> Но ты тоже согласись, что если top запросил список процессов, то то, что ему вернули
> нужно интерпретировать именно как список процессов. Т.е. это жжж не спроста.
А мне по-другому кажется (удобнее воспринимать): абстракция процесса
вполне самодостаточна, и в (редких) случаях, когда действительно требуется
облегченный процесс, мне удобнее думать о нитях, разделяющих общие данные,
как о различных процессах, общающихся друг с другом через разделяемую память.
Ну и что, что память статическая - никакой принципиальной разницы нет.

unbound нитки я вообще не понимаю - IMHO просто замаскированный вызов процедур,
реализованный через одно место.

Повторюсь - я признаЮ, что все это - дело привычки. Возможно, я не сталкивался с
задачами, в которых "нитяной" способ мышления дает реальный бенефит.

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

Кстати, под Солярисом такой способ программирования (мне) встречается значительно
реже, хотя все средства для подобных извращений там имеются.

> Кстати, где-то можно внятно прочесть, что с трэдами сделали в 2.4.х?
Не знаю, но у меня ощущение, что трэды в 2.4 не трогали вообще.

anonymous
()

2 anonymous (*) (2001-11-05 20:16:12.0):

>> Результат - масса пионЭрских поделок чудовищного размера с >> минимальной функциональностью.

Прям как про Linux писал. Приблуды под Win32 как раз, гораздо чаще дописывают до приемлемого уровня, чем приблуды под Linux. Странно, к чему бы это?

anonymous
()

2anonymous (*) (2001-11-05 20:55:22.0)
и например ?

anonymous
()

2 anonymous (*) (2001-11-05 21:47:52.0): Вам про Linux пример привести? Примеров слишком много. Сходите на freshmeat.net и поищите там что-нибудь для, например, EDA, или профессиональной работы со звуком, или для офиса. Одни поделки. Большая часть - альфы. Есть беты, но на поверку оказывается, что более чем на альфы они не тянут. Да взять тот же гном. Чудовищное неповоротливое глюкалово, с режущими глаз недоделками. Или KDE. Или KOffice, от малейшего чиха вылетающий в core...

anonymous
()
Ответ на: комментарий от anonymous

2anonymous (*) (2001-11-05 23:36:19.0):

> Сходите на freshmeat.net ...
Сходите на аналог freshmeatа, about win32, и ужаснитесь.
Печально(для Вас), но факт:
Среди массы малоюзабельных поделок на reshmeatе мы находим массу программ
(сделаных, как правило, студентами или энтузиастами в свободное время),
превосходящих своим качеством продукцию M$, которую ваяли в win32 коллективы
из сотен высокооплачиваемых профессионалов...

anonymous
()

Брррр...

По поводу Оракла в линухе - однозначно быстрее (8.1.6 юзаем), чем в НТ. Опробировано.

Треды в линухе реализованы действительно не совсем корректно, убедится в этом легко, попробовав, например, прокси-сервер Oops под нагрузкой из 20+ машин. Oops написан так, чтобы корректно работать с тредами, а вот с линухом у него грабля (очень жаль).

Примером правильной реализации тредов может служить Соляра, но там других проблем хватает, из-за которых использование солярки на интелах становится практически невозможным. :(

Во фре треды тоже весьма сырые, и всплывает это  в первую очередь при работе на SMP.

А про НТ я вообще молчу, потому что ничего хорошего сказать не могу - на непропатченной 2000 Оракл при поступлении запросов (повторюсь - оракл 8.1.6) начинает катастрофически пожирать камень, из-за чего все преимущества ниток в НТ испаряются. А проблема - в кривости реализации менеджеров: задач, раздачи памяти и раздачи шины.
Скромный вердикт: для работы с ораклом на интеле лучше всего подходит линух. Про спарк ничего сказать не могу, но думаю, что тормоз типа "соляроид" выигрыша в производительности не даст.

Оффтопик: я вот только понять не могу, почему на спарке НетБСД и ОпенБСД работают намного быстрее, чем "родная" соляра. Причем, насколько я заметил - и корректнее во многих случаях.
Олег

anonymous
()

2 anonymous (*) (2001-11-05 23:55:29.0): Иду на tucows. И что я вижу? Тучи юзабельных, доведенных до ума прог.

anonymous
()

> Дело привычки, но, все же, стандартный Юниховый подход мне кажется логичнее.

Этот подход просто тянется еще со времен, когда трэдов в юнихах не было.

>Во фре треды тоже весьма сырые, и всплывает это в первую очередь при работе на SMP.

К сожалению это правда, с SMP грабли :(

>А про НТ я вообще молчу, потому что ничего хорошего сказать не могу -
> на непропатченной 2000 Оракл при поступлении запросов (повторюсь -
>оракл 8.1.6) начинает катастрофически пожирать камень, из-за чего
>все преимущества ниток в НТ испаряются.

Дык тут какая-та нитка, имхо, зацикливается. В линухе тоже если вечный цикл сделать без медленных операций, камень жрется.
Как это не парадоксально, но Sleep/usleep может ускорить работу при грамотном использовании.

Havoc ★★★★
()

не обижайте OGRa он хороший и вообще бедняга рыскает по
интернету чтобы наити какую нибудь гадость наверно целые дни,
и когда он успевает работать ?

anonymous
()

To Ogr:

Очень может быть. Но тем не менее люди все равно будут ставить под SAP или Oracle, или DB2, или SAPdb (не помню, как называется родная БД, разработанная в SAP).

alexros
()

2alexros: "Но тем не менее люди все равно будут ставить под SAP или Oracle, или DB2, или SAPdb"
Поживем увидим. Решение от MS все же куда дешевле выше обозначенных.

Ogr
()

   2alexros:  "Но  тем  не менее люди все равно будут ставить под SAP или
   Oracle, или DB2, или SAPdb"
   Поживем увидим. Решение от MS все же куда дешевле выше обозначенных.
Ogr, а ты оказывается спец и по СУБД. К твоему сведению, SAPDB - бесплатна
уже как год (она стала под GPL).

anonymous
()

Это вот чтобы было о чем говорить. А то как-то безапеляционные заявления достают.

Microsoft Sqlserver 2000 versus Oracle SQL SERVER TECHNICAL LIMITATIONS ------------------------------------------------------------- By Faulkner, Kent (kent.faulkner@trane.com) USA

1. Single platform dependancy.

SQL Server is only operable on the Windows platform, and this is a major limitation for it to be an enterprise solution. Oracle is available on multiple platforms such as Windows, all flavours of Unix from vendors such as Ibm, Sun, Digital, HP, Sequent, etc. and VAX-VMS as well as MVS. The multi-platform nature of Oracle makes it a true enterprise solution.

2. Locking / concurrency

SQL Server has no multi-version consistency model which means that "writers block readers and readers block writers" to ensure data integrity. In contrast, with Oracle the rule is "readers dont block writers and writers dont block readers". This is possible without compromising data integrity because Oracle will dynamically re-create a read-consistent image for a reader of any requested data that has been changed but not yet committed. In other words, the reader will see the data as it was before the writer began changing it (until the writer commits). SQL Server's locking scheme is much simpler (less mature) and will result in a lot of delays/waits in a heavy OLTP environment.

Also, SQL Server will escalate row locks to page level locks when too many rows on a page are locked. This locks rows which are uninvolved in any updates for no good reason.

3. PERFORMANCE and TUNING

a. No control of sorting (memory allocation)

b. No control over SQL Caching (memory allocation)

c. No control over storage/space management to prevent fragmentation. All pages (blocks) are always 8k and all extents are always 8 pages (64k). This means you have no way to specify larger extents to ensure contiguous space for large objects.

d. No range partioning of large tables and indexes eg. in Oracle a large 100 GB table can be seamlessly partitioned at the database level into range partitions, for eg. an invoice table can be partitioned into monthly partitions. Such partitioned tables and partitioned indexes give performance and maintenance benefits and are transparent to the application.

e. No Log miner facility. Oracle 8i and 9i supply a Log Miner which enables inspection of archived redo logs. This comes free with the database. But in the case of Sql Server, external products from other companies have to be purchased to do this task.

4. MISSING OBJECT TYPES a. No public or private synonyms b. no independent sequences c. no packages ie. collection of procedures and functions.

5. PROGRAMMING

a. Significant extensions to the ANSI SQL-92 standard which means converting applications to a different database later will be a challenge (code re-write).

b. No inbuilt JAVA database engine as in Oracle. In Oracle, Java classes can be loaded and executed in the database itself, thus adding the database's security and scalability to Java applications.

c. Stored Procedures are not compiled until executed (overhead).

d. No ability to read/write from external files from a stored procedure.

e. Oracle Sql and Pl/Sql are more powerful and can do things better than Microsoft Transact-Sql. Try to sum up a column by each month, and show the totals for the month, in Sql Server you do it in a complicated way. In Oracle it takes one sql statement grouping by the trunc(<datecolumn>,'month') function.

6. CLUSTER TECHNOLOGY In clustering technology, Oracle is light years ahead, since Sql server has nothing like Oracle Parallel server - 2 instances acting on the SAME data in active-active configurations. And with the new version of Parallel Server in Oracle 9i, renamed as the Oracle real application cluster, there is diskless contention handling of read-read, read-write, write-read, and write-write contention between the instances. This diskless contention handling is called Cache Fusion and it means for the first time, any application can be placed in a cluster without any changes, and it scales upwards by just adding another machine to the cluster. Microsoft has nothing like this.

SUMMARY. SQL Server is clearly positioned between MS-ACCESS and ORACLE in terms of functionality, performance, and scalability. It makes a work group level solution (small number of users with small amount of data).

Oracle is much more advanced and has more to offer for larger applications with both OLTP and Data Warehouse applications. Its new clustering features are ideal for Application service providers (ASPs) on the internet who can now start with a cluster of 2 small servers and grow by just adding a server when they need to. Besides, Oracle's multi-platform capability makes it the most convincing argument for an enterprise.

anonymous
()

Дык, никто и не спорит, что Оракл стоит выше, чем MS SQL, но есть пара замечаний:

> SQL Server has no multi-version consistency model
Версионность нельзя однозначно назвать достоинством. И у версионников и у блокировочников есть свои плюсы и минусы.

>No control over SQL Caching (memory allocation)
Не уверен за MS SQL, но в Sybase это есть.

>Significant extensions to the ANSI SQL-92 standard which means
>converting applications to a different database later will be a
>challenge (code re-write).

Да, это есть, но у Оракла полно своих расширений.
Да и далеко не всегда неужен именно Оракл.

Небось с оракловского сайта агитку взял? :)

Havoc ★★★★
()

2Havoc

Дык, никто и не спорит, что Оракл стоит выше, чем MS SQL, но есть пара замечаний:

> SQL Server has no multi-version consistency model Версионность нельзя однозначно назвать достоинством. И у версионников и у блокировочников есть свои плюсы и минусы. =========================================================== Например? Как тогда реализуется целостное чтение на текущий момент? Блокировочнки - ждут фиксации изменений. Версионники - ничего не ждут. Правда могут быть проблемы ( но это как правило обходится) при длительных операциях чтения из таблицы которая постоянно обновляется. Зато удобство работы несколько выше.

>No control over SQL Caching (memory allocation) Не уверен за MS SQL, но в Sybase это есть. ====================================================== Мы сейчас сравниваем MS & Oracle причем здесь Sybase.

>Significant extensions to the ANSI SQL-92 standard which means >converting applications to a different database later will be a >challenge (code re-write). Да, это есть, но у Оракла полно своих расширений. Да и далеко не всегда неужен именно Оракл. ========================================================= Конечно все зависит от ваших потребностей и прежде всего знаний. Но от себя добавлю,что не всегда есть потребность во многих возможностях поставляемых с ПО уровня предприятия. Например Oracle Standart Edition 5 пол - ~1800$, а это уже не такие большие деньги.

Небось с оракловского сайта агитку взял? :) ========================================================= Нет в comp.database.oracle.server Просто достали утверждения что SQL - это база уровня предприятия. То что она хорошо рекламирутеся и суется куда не попадя еще не повод не знать о тех. хар-ках БД.

anonymous
()

Ну предприятия то разные бывают :)

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

Havoc ★★★★
()

2Havoc

>Ну предприятия то разные бывают :) >Если навскидку, то >версионники ресурсов поболе жрут. >

============================= Это так и есть но как правило это оправдано удобствами

>Ты привел случай, когда таблицы часто обновляются, бывает же и >наоборот, что они редко обновляются, а все больше выборки. >Просто оба подхода имеют право на жизнь, если бы блокировочники были >однозначно плохи, то от них бы давно уже отказались. > ===================================================== Ну в этом случае все равно какой тип использовать. Про подходы это конечно верно - согласен.

Здесь как говорится на вкус и цвет товарищей нет.

anonymous
()

2anonymous (*) (2001-11-07 10:58:35.0): "К твоему сведению, SAPDB - бесплатна уже как год"
Три раза ха. Если ты думаешь, что основные затраты это ПО, то выгужден тебя огорчить. Основными затратами идет желехо и обслуживание. Да и потом была бы SAPDB (или как оно там называется) достаточно быстрой, то не делали бы всю эту бодяшу на DB2 или Оракле.
2anonymous (*) (2001-11-07 11:44:07.0): Текстик конечно с сайта Оракла, тут даже вопросов нет.
"1. Single platform dependancy"
Что есть то есть. Но если учесть, что Виндовс набирает обороты на рынке серверов, то это уже не такой уж большой минус.
"2. Locking / concurrency"
Ораклистов хлебом не корми дай на эту тему поговорить. Но я не крупный спец а БД, но Havoc на мой взгляд приводит достаточно убедительные аргументы на эту тему.
"Significant extensions to the ANSI SQL-92 standard which means converting applications to a different database later will be a challenge"
Так не используй расширения ни кто ведь не заставляет пиши в лоб по стандарту.
"No inbuilt JAVA database engine as in Oracle"
Через год будет на сайте MS посвященному Ораклу: "No built-in support for .Net as in SQL Server 2002" :)
"Oracle Sql and Pl/Sql are more powerful and can do things better"
А двумя абзацами выше они писали "Significant extensions to the ANSI SQL-92 standard which means converting applications to a different database later will be a challenge" какие-то они не последовательные :)

Ogr
()
Ответ на: комментарий от Havoc

Вообще-то даже криволапые жабисты знают, что такое thread pool. А применение такового весь оверхед линуховых ниток покрывает на хрен.

Antichrist
()

2Org

Это с каких же пор стоимость железа стала занимать основную статью расходов. Всегда железо стоило 10-12% , ну 25%,а в остальном батенька все деньги на софт идут. Не ну если софт ворованный, то тогда конечно можно и на железо больше деньжат потратить. Но это уже другая история

2Org Нет текстик не с сайта Oracle ибо компания заитересована в продвижении своих продуктов и следовательно такая информация может быть рекламой. Это иэ news:comp.database.oracle.server

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.