зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"

cool
и это у IBM нет опыта с 64 ? а можно точнее на мэйнфрейме нет или POWER4 ? ? у интела 64 бита родилось благодоря DECовской альфы ... а откуда инфо что сан имеет какое-то отношение к интелу ?
чо-то в теорию 64-бита пока слабо верится ...

то выясняется, что DB2 работал на 20 оптоволоконных контроллерах,

ну и о чем это говорит ? ... мне не очем, но могу как офигенный проффесионал в этом деле (в прочем как и все сдесь ) пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM) т.е. у IBM "далеко не все шоколадно, а это как раз и Concurrency Control в том числе." т.к. не могут эфективно использовать диски.
а если еще пивка глотнуть — еще могу пару теорий двинуть

Gt_

Здравствуйте, Merle, Вы писали:


M>Есть redo запись, есть undo запись. И redo запись хранится в redo журнале. Про то где хрантится undo запись и что она содержит, тут аккуратно обходится

В redo log записи всегда идут парами — old image и new image. Old image — это содержимое rollback сегмента, new — соответственно значения, которые пойдут в data block(s). Одна запись в redo log-е содержит оба image-а. Идея в том, что redo "охраняет" как сами данные, так и rollback.

А вообще это уже выбилось из основной темы.

Здравствуйте, KGP, Вы писали:

KGP>А из собственного (вашего) опыта ответ есть ... что в итоге перевесит версионность или блокировочность (в MS SQL Server ...) в тенденции так сказать.
Ээээ... Это вопрос?

А>>не ну мне интересна ваша версия куда могли пропасть 140 слотов из базовой конфигурации ? просто в любой high-end системе их больше сотни ...
M>Да зачем в эти слоты что-то забивать, если IBM на тот момент и так первыми были?

так небыло возможностей или надобности ?
вы знаете, мне сложно представить что у IBM небыло возможности заполнить слоты, и не верится, что IBM не выжала из своей системы все, что можно для db2, как это они же сделали для оракла.

Gt_

L>Тем-то и опасен READ UNCOMMITTED, что нет защиты от dirty reads. А что касается Тома Кайта, то он же о версионнике толкует. Т.ч. возвращаемся к словам Merle: "Должно быть что-то сильно не так, если по другому приложение работать не может..." (c)

это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot. ждите.

Gt_

Здравствуйте, <Аноним>, Вы писали:

А>это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot.
Ну уж всяко не для скорости, а сугубо удобства для....
И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...

Здравствуйте, Merle, Вы писали:

M>И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...
А из собственного (вашего) опыта ответ есть ... что в итоге перевесит версионность или блокировочность (в MS SQL Server ...) в тенденции так сказать.

Здравствуйте, Merle, Вы писали:

M>Ээээ... Это вопрос?
Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?

Здравствуйте, KGP, Вы писали:
KGP>Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?
Что значит "полной"? Нет, MS не собирается отказываться от блокировок. Уж очень они себя хорошо показывают

Здравствуйте, KGP, Вы писали:

KGP>Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?
Однозначно нет. В любом случае это не будет "полной версионностью". Не смотря на ряд удобств, в производительности на OLTP задачах чистые версионники явно проигрывают, что подтверждается и теорией и тестами. Тот же Оракл далеко не чистый версионник.
При работе с чистым блокировочником проблема одна — свести задачу к OLTP. Иногда это довольно трудоемкий процесс, да и не всегда это в принципе возможно. И в таких случаях наличие версионности здорово помогает, так что в MSSQL'е будет одинаково развиваться и блокировочность, и версионность, (благо реализация это позволяет: http://rsdn.ru/?Forum/?mid=525046

Автор: Иван Бодягин (Merle)
Дата: 30.01.04

) и, возможно, что-то еще.

В идеале, для разработчика должно быть совершенно не важно, какой механизм Concurrency Control применяется в СУБД. Он должен обеспечивать честный Serializability с приемлимой производительностью, и это все что требуется.
Все остальные уровни изоляции, существующие на данный момент и в теории, и в реализациях — "от бедности", от того, что при любой реализации "честного" Serializability производительность серьезно страдает.
На сколько мне известно, теоретические работы в этом направлении довольно активно ведуться, но как это будет выглядеть вконечном итоге, если вообще получится, не известно.
Это вполне может быть и не версионность и не блокировочность, а какой-нибудь Serialization Graph Testing навороченый или вообще, гибрид трех-четырех различных механизмов.

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

странно, а вот на tpc-c версионный оракл на одинаковом железе одного производителя делает блокировочника MS на 25% ... или речь о других тестах, может SAP ?


ЗЫ. модель должна определятся задачей, тут красавцы MySQL — модель привязана к типу таблицы, где нада — там версионность, где не нада — там реактивные атомарные операции без транзакций, красота жаль на серьезных нагрузках проседает
ЗЗЫ. опен соурс например тоже как-то не увидело преимуществ блокировочника, все кто появился — версионники Firebird, Posgres, SAP, Mysql ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>странно, а вот на tpc-c версионный оракл на одинаковом железе одного производителя делает блокировочника MS на 25% ... или речь о других тестах, может SAP ?
Во-первых Оракл не чистый версионник, о чем я, кстати, написал.
Во вторых, в тестах tpc Оракл побежает за счет того, что сейчас там используется 64bit интеловские процессоры, которые по архитектуре схожи с сановскими спарками, под которые у Оракла написаны тонны софта, вотличие от MS и IBM. Так что выигрывает он там не за счет механизма параллелизма, а за счет более оптимально написаных низкоуровневых алгоритмов, заточеных под конкретную архитектуру. Позволю себе напомнить, что предыдущая версия сливала раза в два.
В третьих, даже при этом, если внимательно посмотреть на 5е и 6е места tpc-c тесте, где на одном и том же железе и одной и той же операционке Oracle и DB2 показали практически одинаковые результаты, то выясняется, что DB2 работал на 20 оптоволоконных контроллерах, в то время как Ораклу, чтобы достичь той же пропускной способности понадобилось 70. Что говорит о том, что с дисковой подсистемой у Оракла далеко не все шоколадно, а это как раз и Concurrency Control в том числе.
В четвертых, у SAP'а свой собственный менеджер транзакций, который механизм параллелизама СУБД не трогает вообще. Поэтому в споре версионность vs блокировочность его тесты вообще не при чем.

А>ЗЫ. модель должна определятся задачей,
Да кто бы спорил...

А> тут красавцы MySQL
По мне бы лучше бы в транзакции они вообще не совались. Был неплохой сервер для своих задачь, единственный в своем роде, а сейчас получится уродец, который толком работать не сможет ни там, ни там.. (IMHO).

А>ЗЗЫ. опен соурс например тоже как-то не увидело преимуществ блокировочника, все кто появился — версионники Firebird, Posgres, SAP, Mysql ...
Ага, и приличного сервера из них ни одного... Даже до уровня Sybase ни один и близко не дотягивает, не говоря уже об остальных лидерах.

Здравствуйте, Аноним, Вы писали:

А>достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
tcp.org
Ткни пальцем хоть в один чистый версионник присутствующий в этих тестах. Заранее оговорюсь, даже самые упертые Ораклоиды чистым версионником Оракл не считают.

А>и это у IBM нет опыта с 64 ?
Да. UDB разрабатывает совершенно отдельная команда, от той, которая пишед под майнфреймы. Одни в торонто, а другие где-то в штатах.

А>ну и о чем это говорит ?
О том, что у Оракла проблемы с дисковой подсистемой.

А>... мне не очем, но могу как офигенный проффесионал в этом деле
Оно и видно, так что молчал бы уж....

А> (в прочем как и все сдесь )
А вот я бы не обобщал, все обобщения — ложны, как известно.

А>пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается
Тут одно из двух, либо пофигу, либо проблемы с блокировками. Так что опять ты промазал и совсем что-то не то нафантазировал.

А>, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM)
Еще раз посмотри внимательно, он с 70 показал не лучше, а такой же результат, как IBM с 20.
Из чего явно следует, что проблемы у него а не у DB2.

А>а если еще пивка глотнуть — еще могу пару теорий двинуть
Иногда лучше жев... пиво пить, чем дурацкий флейм разводить в приличном месте.

Здравствуйте, Аноним, Вы писали:

А>ну и о чем это говорит ? ... мне не очем, но могу как офигенный проффесионал в этом деле (в прочем как и все сдесь ) пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM) т.е. у IBM "далеко не все шоколадно, а это как раз и Concurrency Control в том числе." т.к. не могут эфективно использовать диски.
А>а если еще пивка глотнуть — еще могу пару теорий двинуть

1) Причем здесь процессоры если мы обсуждаем СУБД???

2) на 40 контроллеров больше, а результат лучше на 4% и у DB2 проблемы "не смешите меня Муля". Причем посмотри на время выпуска IBM опубликовал результат раньше. А то что увеличение кол-ва дисков и контроллеров приводит к увеличению производительности СУБД это к гадалке не ходи. Так как диски обычно и есть узкое место. Смотри золотое правило Amdahl.

Здравствуйте, <Аноним>, Вы писали:

А>1) Причем здесь процессоры если мы обсуждаем СУБД???
Рад низкоуровневых алгоритмов, типа сканирования индекса, довольно серьезно зависит от архитектуры процессора.

Здравствуйте, <Аноним>, Вы писали:

А>зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
Вот, кстати, о птичках.
DB2 дернул все рекорды Оракла оптом, в не кластерах.
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster
Что характерно, на 32 разрядном процессоре собственного производства.
Подробно не сравнивал, но на первый взгляд, они добавили пару(!) контроллеров, чуть-чуть разогнали процессоры и перевели клиентов на wintel...

А>1) Причем здесь процессоры если мы обсуждаем СУБД???
в этом мире все взаимосвязанно, например МС не может в принципе использовать не интел (ну альфа исключение), дальше можно развести флейм на тему риски/мэйнфреймы и интел ...


А>2) на 40 контроллеров больше, а результат лучше на 4% и у DB2 проблемы "не смешите меня Муля". Причем посмотри на время выпуска IBM опубликовал результат раньше. А то что увеличение кол-ва дисков и контроллеров приводит к увеличению производительности СУБД это к гадалке не ходи. Так как диски обычно и есть узкое место. Смотри золотое правило Amdahl.


а вы случайно к разработке 1C не имете отношения ? там тоже ребята добились феноменального результата — сколько не тратся на железо система бысрее шевилится не будет. для справки это называется маштабируемостью (непомню как по русски звучало в ширину и в ...), т.е. еслиб дб2 могла она естественно показала бы лучший результат, но как грит оракл когда им надо показать лучший результат они берут оракл ...

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
M>Вот, кстати, о птичках.
M>DB2 дернул все рекорды Оракла оптом, в не кластерах.
M>http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster
M>Что характерно, на 32 разрядном процессоре собственного производства.
M>Подробно не сравнивал, но на первый взгляд, они добавили пару(!) контроллеров, чуть-чуть разогнали процессоры и перевели клиентов на wintel...

ну ? если бы на этом железе запустили бы оракл то можно было бы делать выводы, а так — соглашусь POWER4 на сервере покруче чем интел, но стоимость ...
сейчас у нас есть тесты HP и предыдущие тесты IBM где на близких конфигурация разные БД

Gt_

Здравствуйте, <Аноним>, Вы писали:

А>ну ? если бы на этом железе запустили бы оракл то можно было бы делать выводы, а так — соглашусь POWER4 на сервере покруче чем интел, но стоимость ...
Да что опять за дешевые отмазки? Пускали уже Оракл на этом железе, и даже с той же операционкой. Сейчас это шестое место.
Причем опять-таки, Ораклу понадобилось почти в три раза больше дисковых контроллеров.
Вообщем, говоря твоими же словами, "могли бы сделать быстрее — сделали бы".
Да, и вот еще что, UDB 8.1 уже черти сколько времени, а Оракл типа новый.

я не знаю что вы там пускали, а IBM последний результат получил на своих новых процах, я не знаю чем они отличаются но как минимум тактовая частота у них на 200MHZ больше (power4 1.9ghz), а судя по прес релизу не только. то что оракл не запустили на таком железе минус ораклу, но на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...

Да. UDB разрабатывает совершенно отдельная команда, от той, которая пишед под майнфреймы. Одни в торонто, а другие где-то в штатах.

ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM

Gt_

Здравствуйте, <Аноним>, Вы писали:

А> на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...
Что составляет полтора процента, и при этом ораклу потребовалось в три раза больше дисковых контроллеров, чтобы этой производительности добиться.
Рекордная же система DB2 имеет всего на два контроллера больше чем их же предыдущая, что говорит как раз о том, что с дисковой подсистемой у DB2 проблем нет, в отличии от Оракла.
Кстати, я ошибся, процессоры там, на самом деле, 64 разрядные.

А>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM
Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, и делиться опытом просто некому.

А>> на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...
M>Что составляет полтора процента, и при этом ораклу потребовалось в три раза больше дисковых контроллеров, чтобы этой производительности добиться.
M>Рекордная же система DB2 имеет всего на два контроллера больше чем их же предыдущая, что говорит как раз о том, что с дисковой подсистемой у DB2 проблем нет, в отличии от Оракла.
M>Кстати, я ошибся, процессоры там, на самом деле, 64 разрядные.

кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
на счет IBM я вижу все на оборот — проц на 10% бысрее, а дисков не добавили — бесполезно, блокировки не дают эфективно использовать диски, поэтому сколько их не суй толку нет. у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc. зато у IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост производительности причем всего 32 проца (!)


А>>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM
M>Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, и делиться опытом просто некому.

в интеле от интела одни x86 инструкции остались, большинство это технологии DEC и риск проца альфа. IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего с новой архитектурой интела не имеют"

Gt_

Здравствуйте, Аноним, Вы писали:

А>кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
Ну хоть прессрелизы-то можно почитать.

<...> юмор поскипан <...>
А> у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc.
Ага, напихать на 50 контроллеров больше, чтобы получить выигрыш в полтора процента, и при этом утверждать, что это преимущество — это надо Ларри Элисоном быть..

Что же касается MSSQL'я то 5 лет назад, когда писали 2000, систем такого масштаба попросту не было и тестировать было не начем. И тот факт, что в этих условиях MSSQL рвал и Оракл, и DB2, до выхода их новых версий, говорит очень о многом.

А>зато у IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост производительности причем всего 32 проца (!)
На самом деле 64 — там в одном чипе 2 процессора, всего 32 чипа, итого 64 64-разрядных процессора.


А>IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего с новой архитектурой интела не имеют"
Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

Здравствуйте, Merle, Вы писали:
M>Что составляет полтора процента,
0.6%. Где там полтора-то???

Здравствуйте, Аноним, Вы писали:

А>кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
>на счет IBM я вижу все на оборот — проц на 10% бысрее, а дисков не добавили — бесполезно, >блокировки не дают эфективно использовать диски, поэтому сколько их не суй толку нет. у >оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc. зато у >IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост ?>производительности причем всего 32 проца (!)

1) Почитай сначала README к IBMким фикспакам они добавляют в низ новую функциональность в DB2 (ассиметричный алгоритм сканирования индексов это одно из последних добавлений) так что разница между DB2 сейчас и три месяца назад все-таки есть.

2) Раскажи пожалуйста как блокировки мешают исполдьзовать диски??? Чем больше дисков тем меньше время сканирования (таблиц, индексов) и следовательно меньше время ожидания на юлокировке. Неувязочка у вас дорогой товарищ получается.

>>>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, >а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы >индусы придумали. global services это не про IBM
>M>>Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, >и делиться опытом просто некому.

>А>в интеле от интела одни x86 инструкции остались, большинство это технологии DEC и риск >проца альфа. IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего >с новой архитектурой интела не имеют"

IBM между прочим всю жизнь была на 31-bit (тридцать один) на mainframe. И DB2 на mainframe
до сих пор 31-bit с элементами 64-bit. B это не мешает иметь DB2/390 отличную производительность на mixed worload. А 64 Bit в DB2 появились в 7 версии в 2000 году помоему

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot.
M>Ну уж всяко не для скорости, а сугубо удобства для....
M>И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...

а чем получше ?

А>> у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc.
M>Ага, напихать на 50 контроллеров больше, чтобы получить выигрыш в полтора процента, и при этом утверждать, что это преимущество — это надо Ларри Элисоном быть..

итак полтора процента — это 5 тыщ транзакций в минуту, это нагрузка для целого сервера фирмы средней паршивости. это долполнительно сотни юзеров в системе, для кого-то эти 100 юзеров будет решающим фактором, не брать мэйнфрейм, а просто напихать еще 50 контроллеров.


M>Что же касается MSSQL'я то 5 лет назад, когда писали 2000, систем такого масштаба попросту не было и тестировать было не начем. И тот факт, что в этих условиях MSSQL рвал и Оракл, и DB2, до выхода их новых версий, говорит очень о многом.

о чем ? о том что это субд способная решать задачи энтерпраиз ? 24x7 ? крутить решения лидеров SAP, Peoplesoft ? более продвинута в техническом плане ?
это были риторические вопросы, да МС хорошо развивается, но по фичам еще не дотянула до
Sybase & Posgres, Yukon большой шаг вперед, практически исчезают идеологические различия с ораклом, т.е. в результате МС пришел туда куда идет оракл — версионность и ядро java в субд. остались кластера shared nothing vs oracle RAC, кто победит тут х.з. но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP) ни MS Axapta (поддерживает оракл),к стате зачем ? переживают что кому то понадобятся эти полтора процента ? ведь у MS прекрасные результаты в tpc !

M>Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

что то я потерял нить — итак IBM всегда была 64бит, круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ? ведь "в производительности на OLTP задачах чистые версионники явно проигрывают" ? ах да оракл не чистый блокировочник ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>итак полтора процента — это 5 тыщ транзакций в минуту, это нагрузка для целого сервера фирмы средней паршивости. это долполнительно сотни юзеров в системе, для кого-то эти 100 юзеров будет решающим фактором, не брать мэйнфрейм, а просто напихать еще 50 контроллеров.
Агащазблин.
Для тех фирм которым нужны такие мощности — это именно 0.6 процента — тоесть ничто.
Проще поставить рядом такой же DB2. Или процы поменять. Выигрыш будет гораздо существеннее.

А>о чем ? о том что это субд способная решать задачи энтерпраиз ? 24x7 ? крутить решения лидеров SAP, Peoplesoft ? более продвинута в техническом плане ?
Угу именно об этом.
И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.

А>это были риторические вопросы, да МС хорошо развивается, но по фичам еще не дотянула до
А>Sybase & Posgres,

Это ты кому-нибудь другому рассказывай. Sybase и Postges хороши в своих нишах, но до MSSQL'я им еще расти.

A> идет оракл — версионность и ядро java в субд. остались кластера shared nothing vs oracle RAC, кто победит тут х.з.
Не версионность, а гибридные системы — это две большие разницы. MS никогда не откажется от блокировок — и правильно сделает. В обозримом будующем ддвигаться в сторону от shared nothing MS, на сколько мне известно, не собирается.

A>но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP)
Ну ясен хвост. В этом секторе всего 3-4 сервера брятся за лидерство, с кем же им еще соревноваться?

A>MS Axapta (поддерживает оракл),к стате зачем ?
Затем, что это не детище MS, а MS ее купило и на этот момент она уже поддерживала Оракл.

A>переживают что кому то понадобятся эти полтора процента ?
Да это Оракл переживает, что на одинаковом железе явно проигрывает.


M>>Если у процессоров одна и та же разрядность — это не значит, что у них одна и та же архитектура. Так что ни AIX, ни Power 4 действительно ничего нового с новым интелом не имеют.

А>что то я потерял нить — итак IBM всегда была 64бит,
Еще раз есть разрядность и есть архитектура. разрядность ... архитектура. Еще раз повторить?

А>круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ?
Дык, порвали же. Чего еще надо?

Здравствуйте, s.ts, Вы писали:

ST>а чем получше ?
1. 100% определение конфликтов. Оракл при "Serializable" иногда обнаруживает конфликт там, где его нет на самом деле и откатывает транзакцию. Это особенность его версионного алгоритма.
2. В MSSQL'е никогда не будет ошибки "snapshot too old", пока есть место на диске. То есть нет проблемы случайно проскочившего слишком длинного запроса и неожиданно короткого сегмента отката.
3. Теоретически более быстрый алгоритм поиска нужной версии данных.

M>Не версионность, а гибридные системы — это две большие разницы.
класный прием, нада взять на вооружение — в конце топика оракл уже ближе к блокировочнику получается


A>>но без оракла пока не может обойтись ни IBM до сих пор пускает тесты с ораклом, (нада показать результат лучше чем HP)
M>Ну ясен хвост. В этом секторе всего 3-4 сервера брятся за лидерство, с кем же им еще соревноваться?
не понял мысли .. это возражение, вопрос ? уточню сою мысль (точнее мысль оракла) — IBM продает во первых железо, очень тяжело называть свое железо лучшим, когда ты не лидер на tpc. когда IBM не может своими силами (DB2) выйти в лидеры, они берут оракл.

A>>переживают что кому то понадобятся эти полтора процента ?
M>Да это Оракл переживает, что на одинаковом железе явно проигрывает.

выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда

M> И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.

что за бред, не знаю что там было до семерки но начиная с него оракл всегда был лидером выпуская новый сервер
9ка рвет MS в 2 раза http://www.oracle.com/corporate/press/index.html?1440470.html
8рка на IBM http://www.findarticles.com/cf_dls/m0WUB/1999_Oct_11/56260522/p1/article.jhtml

утверждать не буду но почти уверен в свое время оракл лет 10 не слезал с первого места.

M>Еще раз есть разрядность и есть архитектура. разрядность ... архитектура. Еще раз повторить?

угу а то чо-то не догоняю.
еще раз для тех кто в танке — в тесте архитектура/разрядность у них одна — IBM Power4, OS одна — AIX, разные только модели — блокировочник и ораверсионник. ораверсионник показал лучший результат на как тут сосчитали 0.6 процента. байка о "опыте" IBM на своей архитектуре конечно веселая, но не выдерживает критику. а теперь вопрос, что ты пытаешся доказать ?

А>>круче них в этой области только горы, что же им могло помешать порвать оракл как тузик грелку ?
M>Дык, порвали же. Чего еще надо?
порвали — это хотя бы в 2 раза, как это обычно в tpc и было. как только оракл запустят на этих процах, все станет на свои места.


Gt_

Здравствуйте, <Аноним>, Вы писали:

А>класный прием, нада взять на вооружение — в конце топика оракл уже ближе к блокировочнику получается
Я этого не говорил...

А> когда IBM не может своими силами (DB2) выйти в лидеры, они берут оракл.

Я конечно понимаю твою любовь к ораклу, но не до такой же степени..

А>выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда
Это точно в юмор. Результаты публикует Оракл, на том железе, которое ему удобнее. Попробовали погоняться на IBM'овском и облажались. На том же железе не получилось. Чтобы хоть как-то сравняться им пришлось в три раза увеличить производительность дисковой подсистемы.
Ты можешь выдвигать и другие.. версии.. но против фактов не попрешь.

M>> И возвраящаясь к изначальному спору версионник vs блокировочник, даже такому полуверсионнику как Оракл, понадобилдось сменить две версии сервера и кардинально поменть все железо, чтобы превзойти результаты MSSQL.
А>что за бред, не знаю что там было до семерки но начиная с него оракл всегда был лидером выпуская новый сервер
Нет, это не так. Оракл был лидером ровно до того момента, как MS запускала следующий тест на том же сервере.
Всерьез перегнать SQL 2000 смог только 10 Оракл, хотя, по логике вещей это должно было произойти гораздо раньше.

А>утверждать не буду но почти уверен в свое время оракл лет 10 не слезал с первого места.
Ну да, до выхода MSSQL 7.0

А> разные только модели — блокировочник и ораверсионник. ораверсионник показал лучший результат на как тут сосчитали 0.6 процента.
Нет, не так. Точнее будет сказать, что Оракл показал результат лучше на 0.6% увеличив исходную производительность дисковой подсистемы в 3 раза. Договаривай уж до конца.

А>байка о "опыте" IBM на своей архитектуре конечно веселая, но не выдерживает критику. а теперь вопрос, что ты пытаешся доказать ?
Я уже давно ничего не пытаюсь доказать, я, повторюсь, слежу лишь за точностью формулировок.

А> как только оракл запустят на этих процах, все станет на свои места.
Свежо предание...
В этих тестах Оракл уже давно сдал лидирующие позиции, и с появлением UDB и MSSQL 7.0 лишь изредка вырывается вперед выпуская новую версию. Но это счастье длится лишь до следующих тестов старых версий блокировочников.

Опять-таки, чтобы выбраться из окончательного офтопика, если я правильно помню, то ты возражая против утверждения, что OLTP быстрее, привел в качестве аргумента тесты tpc и результаты Оракла.
Так вот это не аргумент, как минимум по двум причинам.
1. Оракл не чистый версионник.
2. В этих тестах Оракл занимает отнюдь не лидирующие позиции.

А>>выигрывает, поэтому IBM уже черт знает сколько ставит рекорды именно на оракле, а не на своем DB2. когда следующий их обойдет на пару процентов они опубликуют тесты на оракле, так было всегда
M>Это точно в юмор. Результаты публикует Оракл, на том железе, которое ему удобнее. Попробовали погоняться на IBM'овском и облажались. На том же железе не получилось. Чтобы хоть как-то сравняться им пришлось в три раза увеличить производительность дисковой подсистемы.
M>Ты можешь выдвигать и другие.. версии.. но против фактов не попрешь.

tpc тесты железа, оракл там как консультант. IBM не пробывала — это практика последних лет 10 — рекорды ставить на оракле.

А>> как только оракл запустят на этих процах, все станет на свои места.
M>Свежо предание...
M>В этих тестах Оракл уже давно сдал лидирующие позиции, и с появлением UDB и MSSQL 7.0 лишь изредка вырывается вперед выпуская новую версию. Но это счастье длится лишь до следующих тестов старых версий блокировочников.

M>Опять-таки, чтобы выбраться из окончательного офтопика, если я правильно помню, то ты возражая против утверждения, что OLTP быстрее, привел в качестве аргумента тесты tpc и результаты Оракла.
M>Так вот это не аргумент, как минимум по двум причинам.
M>1. Оракл не чистый версионник.
да называй его хоть слоном, я лишь назыаваю так как вещи называют IBM&MS. мы сравниваем модель оракла и чистого блокировочника поэтому я сравниваю с IBM как лучшего представителя.

M>2. В этих тестах Оракл занимает отнюдь не лидирующие позиции.
еще раз — мы сравниваем модель, не версию субд, а модель.
у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.

Gt_

Здравствуйте, Аноним, Вы писали:

А>у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
Это преимущество для разработчика. Писать удобнее.
Но в плане скорости для OLTP — это недостаток. Именно поэтому, ближайшее обозримое будущее за гибридными системами, которые позволят когда надо использовать всю производительность блокировок, а когда надо — гибкость версионного механизма.

А>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.
А во вторых, как я уже говорил, тесты SAP'а к данному разговору вообще никакого отношения не имеют, поскольку в SAP'е реализован свой собственный менеджер транзакций. И механизмы параллельной обработки транзакций СУБД, в его тестах попросту не задействованы.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, s.ts, Вы писали:

ST>>а чем получше ?
M>1. 100% определение конфликтов. Оракл при "Serializable" иногда обнаруживает конфликт там, где его нет на самом деле и откатывает транзакцию. Это особенность его версионного алгоритма.

можно пример ? (хочу разобраться)

M>2. В MSSQL'е никогда не будет ошибки "snapshot too old", пока есть место на диске. То есть нет проблемы случайно проскочившего слишком длинного запроса и неожиданно короткого сегмента отката.

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

M>3. Теоретически более быстрый алгоритм поиска нужной версии данных.

разговор о внутренней реализации или есть принципиальные отличия ?

Здравствуйте, s.ts, Вы писали:

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


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

M>>3. Теоретически более быстрый алгоритм поиска нужной версии данных.
ST>разговор о внутренней реализации или есть принципиальные отличия ?
Да, отличия принципиальные. Оракл поддерживает версионность на уровне страниц данных, а Юкон на уровне отдельных записей. В Оракле предыдущие версии данных берутся из Undo лога, а в Юконе из специального хранилища, специально для этого преспособленного — version store heap.
В итоге в Юконе механизм должен дыть не только быстрее, но и менее ресурсоемким.

А>>у ораверсионной модели есть преимущество — читатели не блокируют писателей, писатели не блокируют читателей.
M>Это преимущество для разработчика. Писать удобнее.
M>Но в плане скорости для OLTP — это недостаток. Именно поэтому, ближайшее обозримое будущее за гибридными системами, которые позволят когда надо использовать всю производительность блокировок, а когда надо — гибкость версионного механизма.

что ж посмотрим, но пока этот "недостаток" как-то никак не получается увидеть в реальных тестах ...


А>>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
M>Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.

опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем IMB, берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне 50 контролеров нужны были для увеличения отрыва.

Gt_

Здравствуйте, Аноним, Вы писали:

А>что ж посмотрим, но пока этот "недостаток" как-то никак не получается увидеть в реальных тестах ...
Да ну?
На протяжении последних 3-4х лет очень даже получалось, и сейчас, вполне себе получается.

А>опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем IMB,
Да бога ради, чтож не показал-то? Не смог?


А> берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне 50 контролеров нужны были для увеличения отрыва.
Ну молодец Оракл, обошел сервер 5-ти летней давности, который вышел, когда такого железа еще и близко не было. Для этого ораклу понадобилось две новых версии продукта выпустить. Что можно сказать? Зачет.

Здравствуйте, Merle, Вы писали:

M>Да, отличия принципиальные. Оракл поддерживает версионность на уровне страниц данных, а Юкон на уровне отдельных записей. В Оракле предыдущие версии данных берутся из Undo лога,
Не совсем так, в Oracle нет UNDO-лога, есть REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом. Но он используется только для восстановления базы после сбоев.

Для обеспичения версионности ( и отката транзакций при выдаче rollback ) используется отдельные структуры —
ROLLBACK- сегменты ( UNDO-tablespace начиная c 9-ки, но по сути тоже самое), которые UNDO логом можно назвать только с точки зрения храненеия UNDO информации, но при их ведении не требуется соблюдать протокол ведения undo журнала ( т.к. для восстановления они не используются), а потому и классическим undo логом они не являются.

Надеюсь окончательно всех запутал

Здравствуйте, KisA, Вы писали:

KA>Надеюсь окончательно всех запутал
О да..

KA>REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом.
Нет, REDO лог хранит только Redo информацию и действительно используется только для восстановления после сбоев, а undo информация хранится в rollback сегменте. И используется и для восстановления и для отката транзакций.

С формальной точки зрения в Оракле undo/redo лог разнесен на два файла (на самом деле не два, а больше, ну назовем это двумя группами файлов).
Redo лог, который служит для наката транзакций, и Rollback сегмент, который служит для отката транзакций (то есть то, для чего в других системах служит undo лог).
Разнесено это дело из соображений производительности. Поскольку в версионнике откат транзакции явление очень частое, то подобная схема позволяет избежать ненужных очередей в том случае когда одной транзакции надо сбросить redo информацию, а другой откатить часть данных или посмотреть предыдущую версию.
Естественно, в случае восстановления после сбоя, ничто не мешает воспользоваться undo информацией из rollback сегмента.

Кажется, у того же Тома Кайта это было расписано достаточно подробно, вечером постараюсь посмотреть, сейчас к сожалению времени не очень много...

А>>>у блокировочной модели преимуществ нет, в тестах OLPT на одинаковом железе (от IBM) они показывают схожие результаты, в то же время на тестах SAP оракловой модели до сих пор нет равных.
M>>Во-первых схожи не на одинаковом железе, ораклу приходится увеличивать производительность дисковой подсистемы в несколько раз, чтобы показать схожие результаты.



А>опять фантазии — а я вот считаю что на с 20 конролерами бы оракл показал бы лучше результат чем >IMB, берем тест HP и смотрим как он делает MS на 25% с 26 контролерами (vs 64 у MS), дополнительне >50 контролеров нужны были для увеличения отрыва.

Не надо делать обобщенных выводов сравнивая MS SQL и Oracle и отображать свои выводы на DB2.
Это в корне не верно. Пока мы видим что на практически одинаковой железке Oracle менее производителен чем DB2. Причем адаптеров у DB2 28 FC. A у Oracle 66 FC и 6 _SSA_ который во многих случаях быстрее чем FC (при правильной настройке)

DB2 и MS SQL хоть и блокировочники, но разные.
И потом какой из тестов SAP ты имеешь в виду?

А>Не надо делать обобщенных выводов
как бы я эту мысль уже месяц пытаюсь донести до Мерле

А>Это в корне не верно. Пока мы видим что на практически одинаковой железке Oracle менее производителен чем DB2.

блин а вот сдесь я не вьезжаю, может мы на разные тесты смотрим, дайте плиз линк с 2 тестами ? а то я вижу тест от IBM где практически одинаковой железке Oracle боле производителен чем DB2.

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, KisA, Вы писали:

KA>>Надеюсь окончательно всех запутал
M>О да..

KA>>REDO лог , т.е журнал доката в оракловской терминологии, который фактически является undo/redo логом.
M>Нет, REDO лог хранит только Redo информацию и действительно используется только для восстановления после сбоев, а undo информация хранится в rollback сегменте. И используется и для восстановления и для отката транзакций.

REDO лог содержит не только информацию доката но и информацию отката, запись в redo логе Oracle содержит информацию и о старом и о новом значении, т.е. это вроде классический undo/redo журнал, и зачем при востановлении еще и информация из rollback непонятно, но судя по доке она действительно используется, тут я был не прав.
Может ошибка в документации .
Из Oracle Concepts 8.1.7:

Each redo record contains both the old and the new values. Oracle also records the old value to a rollback block.
...
Among other things, the information in a rollback segment is used during database recovery to undo any uncommitted changes applied from the redo log to the datafiles.

M>Естественно, в случае восстановления после сбоя, ничто не мешает воспользоваться undo информацией из rollback сегмента.
Кроме того, что в случае сбоя её может не быть, ну не сбрасывается она на диск при фиксации транзакций, т.е. её саму надо восстанавливать. Отсюда у меня и сомнения по поводу её использования при восстановлении...
Опять же зачем в redo лог тогда пихать undo информацию, лишняя она там получается... непорядок...

Здравствуйте, Аноним, Вы писали:

А>блин а вот сдесь я не вьезжаю, может мы на разные тесты смотрим, дайте плиз линк с 2 тестами ? а то я вижу тест от IBM где практически одинаковой железке Oracle боле производителен чем DB2.
Нет, стоп, ты определись:
Либо железка разная и тогда ораклу понадобилось более производительная железка, чтобы схожие результаты показать. Либо железка одинаковая, но тогда она одинаковая и с теперешним первым местом в этих тестах, и тогда оракл явно сливает.
А то у тебя какие-то двойные стандарты получаются.

Здравствуйте, KisA, Вы писали:

KA>Может ошибка в документации .
Да туману они там напустили в этой документации, не разгребешь...

Из 10G, про Redo log:

Oracle uses the redo log to record all changes made to the database. Oracle records every change in a redo record, an entry in the redo buffer describing what has changed. For example, assume a user updates a column value in a payroll table from 5 to 7. Oracle records the old value in undo and the new value in a redo record. Since the redo log stores every change to the database, the redo record for this transaction actually contains three parts:

The change to the transaction table of the undo
The change to the undo data block
The change to the payroll table data block

Есть redo запись, есть undo запись. И redo запись хранится в redo журнале. Про то где хрантится undo запись и что она содержит, тут аккуратно обходится

далее про Undo.

Every Oracle database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. Oracle refers to these records collectively as undo. Historically, Oracle has used rollback segments to store undo.

То есть, undo записи, хранятся в rollback сегменте.
далее опять про undo.

Undo records are used to:

Roll back transactions when a ROLLBACK statement is issued
Recover the database
Provide read consistency
When a rollback statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.

То есть, из redo лога накатывается все новая информация, а из undo откатывается обратно, если она не зафиксирована.
Все-таки по этому описанию Rollback сегмент — это полноценная часть undo/redo лога, и из redo лога берутся только новые значения, даже не зафиксированных транзакций.

Все-таки надо Кайта почитать, там, как мне помнится, довольно внятно все было описано..

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

формально двойные, поэтому тот анонимус и оговорился "практически одинаковой". я на "формальную" правоту и не претендую, я по "понятиям" рассуждаю:

IBM vs Oracle, в оракле на 50 контролерров больше (хотя наверника если приглядется можно еще различия найти, но лень). я считаю это "практически одинаковой" конфигурацией и не считаю "практически одинаковой" конфигурацию второго теста IBM где только процы были на 200MHZ быстрее, формально я не прав
далее какой результат показал бы, если бы, и т.п. оракл без этих котролер не понятно, тут можно только гадать, что мне например не интересно, но дб2 такой результат показать не смог, хотя возможности напихать эти контролеры естественно были.
уверен что IBM на новых процах запустит оракл на своем лучшем железе только если кто-то переплюнет ее лучший результат с db2. оракл вновь по установит рекорд с разницей в пару процентов,но об этом тоже пока можно только предполагать.
еще раз — такие "рекорды" ничего не показывают, чтоб заявить что модель имеет преимущество, то разница должна быть посущественней. Я не говорю что оракловая модель имеет на OLPT имет преимущества, но утверждаю что и блокировочник не имет преимуществ на OLPT, эти пара процентов скачущая то в один лагерь то в другой говорят о "практически одинаковой" скорости.

M>Ну молодец Оракл, обошел сервер 5-ти летней давности, который вышел, когда такого железа еще и близко не было. Для этого ораклу понадобилось две новых версии продукта выпустить. Что можно сказать? Зачет.

1. что-то не понял — я запостил пару ссылок где оракл рвал 2000 в разы, можно линки где ораклу для этого надо было версии выпускать ?? менялось железо — менялся результат, причем не на пару процентов, согласен у оракла еще и изредка менялись версии
2. восьмерка от девятки скоростью практически не отличалется (на мелком железе)
3. MS отстает не на 5 лет, 2000 не дотягивает по фичам даже до семерки, заявленые фичи Юкона, рядом не лежат с восмеркой, но это уже отдельная песня.

хочешь сравнивать историю и конкретные версии субд, давай заведем отдельный топик, давай сдесь c моделю разберемся — версионник vs блокировочник, ОК ?

Gt_

Здравствуйте, <Аноним>, Вы писали:

А>3. MS отстает не на 5 лет, 2000 не дотягивает по фичам даже до семерки, заявленые фичи Юкона, рядом не лежат с восмеркой, но это уже отдельная песня.

Извини пожалуйста, вот ты не в первый раз говоришь что MS SQL по фичам отстает. Не мог бы ты расшифровать по каким именно фичам он отстает?

Здравствуйте, Аноним, Вы писали:

А>но дб2 такой результат показать не смог, хотя возможности напихать эти контролеры естественно были.
С какого перепугу?
Такой возможности не было, поскольку Оракл делал тесты позже IBM, а на тот момент IBM были первыми.

А>еще раз — такие "рекорды" ничего не показывают
Так показывают или не показывают? Если не показывают, то зачем ты их вообще приплел?

А> утверждаю что и блокировочник не имет преимуществ на OLPT,
Ну и ошибаешься.

А>1. что-то не понял — я запостил пару ссылок где оракл рвал 2000 в разы, можно линки где ораклу для этого надо было версии выпускать ??
Ну залезь на tpc.org и посмотри. 2000 MSSQL делает 9й RC2 Оракл процентов на 45, какие тебе еще ссылки нужны?

А> согласен у оракла еще и изредка менялись версии
Если ты считаешь, что с изменением версий они не оптимизировали сервер под новое железо, то ты глубоко заблуждаешься.

А>2. восьмерка от девятки скоростью практически не отличалется (на мелком железе)
Ага, на tpc теперь мелкое железо.... Еще чего расскажешь?

А>3. MS отстает не на 5 лет, 2000 не дотягивает по фичам даже до семерки,
Про фичи отдельный разговор. Как СУБД функциональность этих серверов абсолютно одинаковая.

А>хочешь сравнивать историю и конкретные версии субд, давай заведем отдельный топик, давай сдесь c моделю разберемся — версионник vs блокировочник, ОК ?
Я уже давно разобрался.
А от тебя пока ни одного аргумента по данному вопросу не было, впрочем, как обычно, но какие-то непонятные возражения появляются постоянно. Мы уже пятый раз по кругу идем, пора завязывать.

Здравствуйте, lazymf, Вы писали:

L> Не мог бы ты расшифровать по каким именно фичам он отстает?
Лучше не надо, один топик уже снесли в "священные войны".

А>>но дб2 такой результат показать не смог, хотя возможности напихать эти контролеры естественно были.
M>С какого перепугу?
M>Такой возможности не было, поскольку Оракл делал тесты позже IBM, а на тот момент IBM были первыми.

у IBM для DB2 небыло возможности а для оракла у того же IBM "возможность" вдруг появилась, ну это из серии некомпетентности IBM в 64 битах ...

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

наверно потому что не все способны увидеть это преимущество на tpc ...

Gt_

Здравствуйте, lazymf, Вы писали:

L>Здравствуйте, <Аноним>, Вы писали:

А>>3. MS отстает не на 5 лет, 2000 не дотягивает по фичам даже до семерки, заявленые фичи Юкона, рядом не лежат с восмеркой, но это уже отдельная песня.

L>Извини пожалуйста, вот ты не в первый раз говоришь что MS SQL по фичам отстает. Не мог бы ты расшифровать по каким именно фичам он отстает?

кросс платформеность, packages, valid procedures, exception, collections, java, RAC, autonomous transactions, advanced quenes, Reverse & Bitmap indexes, Partitioning tables, Fine Granted Access Control ... дальше лень, если интересно в новый топик накидаю линков почему MS&Oracle считают что все это должно быть в субд, а не на мидл-тиер.

Gt_

Здравствуйте, Аноним, Вы писали:

А>у IBM для DB2 небыло возможности а для оракла у того же IBM "возможность" вдруг появилась, ну это из серии некомпетентности IBM в 64 битах ...
А с логикой принципиально не дружим?
Оракл проводила тесты позже, причем на тот момент DB2 был лидером. Тесты проводятся не пару часов, а несколько недель. Какой смысл IBM гоняться на старом железе, если есть чуть-чуть помощнее? По этому у IBM и не было возможности. Как только возможность появилась они и погонялись, результаты на лицо.

А>>у IBM для DB2 небыло возможности а для оракла у того же IBM "возможность" вдруг появилась, ну это из серии некомпетентности IBM в 64 битах ...
M>А с логикой принципиально не дружим?
M>Оракл проводила тесты позже, причем на тот момент DB2 был лидером. Тесты проводятся не пару часов, а несколько недель. Какой смысл IBM гоняться на старом железе, если есть чуть-чуть помощнее? По этому у IBM и не было возможности. Как только возможность появилась они и погонялись, результаты на лицо.

Мда вот она — железная логика т.е. вы уважаемы утверждаете что в оракловом железе "появились" дырки (куда там контролеры втыкают) которых пару недель у IBM небыло ?

up to 160 hot-plug PCI and PCI-X slots
http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/pSeries/high_end/690.html

Gt_

Здравствуйте, Аноним, Вы писали:

А> т.е. вы уважаемы утверждаете что в оракловом железе "появились" дырки (куда там контролеры втыкают) которых пару недель у IBM небыло ?
Юмор — это конечно хорошо, но зачем из себя полного идиота-то корчить?
Или я по русски не очень понятно излагаю?

А>> т.е. вы уважаемы утверждаете что в оракловом железе "появились" дырки (куда там контролеры втыкают) которых пару недель у IBM небыло ?
M>Юмор — это конечно хорошо, но зачем из себя полного идиота-то корчить?
M>Или я по русски не очень понятно излагаю?

не ну мне интересна ваша версия куда могли пропасть 140 слотов из базовой конфигурации ? просто в любой high-end системе их больше сотни ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>не ну мне интересна ваша версия куда могли пропасть 140 слотов из базовой конфигурации ? просто в любой high-end системе их больше сотни ...
Да зачем в эти слоты что-то забивать, если IBM на тот момент и так первыми были?

Здравствуйте, Аноним, Вы писали:


А>>>не ну мне интересна ваша версия куда могли пропасть 140 слотов из базовой конфигурации ? просто в любой high-end системе их больше сотни ...
M>>Да зачем в эти слоты что-то забивать, если IBM на тот момент и так первыми были?

А>так небыло возможностей или надобности ?
А>вы знаете, мне сложно представить что у IBM небыло возможности заполнить слоты, и не верится, что IBM не выжала из своей системы все, что можно для db2, как это они же сделали для оракла.

Во первых AIX и DB2 производят разные подразделения.
Так что смотри на это с точки зрения как IBM может заработать денег.
Никто внутри IBM не мешает делать тесты DB2 на Sun (только Sun этого не хочет)
И никто не мешает делать тесты AIX + Oracle.

1) Зачем полностью забивать машину если можно быть первым и без этого??
2) Косвенно иметь повод пошпынять Oracle.

Здравствуйте, Аноним, Вы писали:

>о чем ? о том что это субд способная решать задачи энтерпраиз ? 24x7 ? крутить решения лидеров SAP, Peoplesoft ?

SAP Business One, 4 CD, на одном из них MS SQL Server 2000.

ну как говорится не прошло и 3 года, открываем документацию по Юконовскому snapshot
http://msdn2.microsoft.com/en-us/library/tcbchxcb(en-us,vs.80).aspx
и обана ...
SQL Server 2005 introduces a new snapshot isolation level to enhance concurrency for OLTP applications. In earlier versions of SQL Server, concurrency was based solely on locking, which caused blocking and deadlocking problems for some applications. Snapshot isolation, by contrast, depends on enhancements to row versioning and is intended to improve performance by avoiding reader-writer blocking scenarios.
[scip]
This non-blocking behavior also significantly reduces the likelihood of deadlocks for complex transactions.

оказывается даже microsoft не видит чтоб блокировочники имели какие-то преимущества в OLPT

Gt_