Демократизация мейнфреймов

[zVlad]

....

[DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS. Алаверды, как говорится.

учитывая, что все самые вкусные плюшки сначала появляются в db2 LUW (кляузы типа skip locked, навороты оптимистичной блокировки, xml ) и только спустя несколько лет в zOS меня терзают смутные сомнения и про оптимизатор ...

Вы опустили слово "оптимизатор" в моей цитате.
Да, некоторые синтаксические штучки порой появляются раньше в db2 LUW, но это лишь отражение того что подход к разработке и выпуску новых версий для DB2 for z/OS отличается от db2 LUW. В части же оптимизатора напрасно Вас мучают сомнения. Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что разработчики DB2 LUW глупее или у них нет алгоритмов оптимизации (эта одна фирма и секретов у них нет внутри, для других фирм ИБМ оптимизатор - это секрет), а по причине отличия z/OS(МФ) и LUW с их серверами. Об этом уже много здесь говорилось.

[Zombie416]

оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS... Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что

По-моему, это из раздела "О религии".

[Dmitry67]

zVlad, а почему например Oracle мог сделать верхний уровень независимым от ОС, так что SQL одинаков (за исключением file names) что под Solaris что под Windows? зачем IBM тащить два проекта - видимо с разными code bases?

[zVlad]

судя по "в нашем приложении нет ни первичных/вторичных ключей" лайсэнс по DB2 дают к МФ в благодарность за покупку
на самом же деле ключи дают огромный пласт информации оптимизатору, в оракле, например, есть целые SQL конструкции которые без наличия внешнего ключа не запускаются. например такое не пройдет без внешнего ключа
update (select t1.name as a,t2.name as b from tab1 t1 inner join tab2 t2 on t1.id = t2.id) set a='111' ;
(кстати у мсскл пройдет, мсскл кидает монетку выбирая значение которое запишется, интересно а как с этим у дб2 ?)

...

Я не знаю как там в Оракле, но в общей теории БД первичные и внешниие ключи обеспечивают целостность по ссылкам, не более того. На выполнение или не выполнение стэйтментов они влияют только таким образом что не допускают нарушения целостности ссылок. В Вашем запросе целостность по ссылкам не нарушается поэтому я не вижу причин почему бы такой запрос не мог бы выполниться в ДБ2 или МССКЛ (предполагая что в качестве таблицы в update может использоваться сабселект, который в принципе мог бы быть заменен view, опять же предполагая что такой view будет updatable).

А этот Ваш Update я бы переписал (в первом приближении) таким образом:

update tab1 t1 set a='111' where exists (select * from tab2 t2 where t1.id = t2.id)

возможно inner join здесь вносит ньюансы, но так как я давно с ДБ2 не работал сходу точно сказать не могу. Но наш разговор не о конструкции которая не может выполняться без внешнего ключа, что само по себе странно.

Интересно что Dmitry67 скажет по поводу "мсскл кидает монетку выбирая значение которое запишется"?

[Dmitry67]

Я не знаю как там в Оракле, но в общей теории БД первичные и внешниие ключи обеспечивают целостность по ссылкам, не более того.

Ну да. Индексы - зло

[Dmitry67]

Интересно что Dmitry67 скажет по поводу "мсскл кидает монетку выбирая значение которое запишется"?

В некоторых случаях есть такой эффект
Причем если в 2000 он мог поменять значение несколько раз и оставалось последнее
то начиная с 2005 значением меняется только один раз (что видно в триггере и @@rowcount), но опять таки выбирает монетка.
Какова кверь - таков и результат...

[iDesperado]

Вы опустили слово "оптимизатор" в моей цитате.
Да, некоторые синтаксические штучки порой появляются раньше в db2 LUW, но это лишь отражение того что подход к разработке и выпуску новых версий для DB2 for z/OS отличается от db2 LUW. В части же оптимизатора напрасно Вас мучают сомнения. Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что разработчики DB2 LUW глупее или у них нет алгоритмов оптимизации (эта одна фирма и секретов у них нет внутри, для других фирм ИБМ оптимизатор - это секрет), а по причине отличия z/OS(МФ) и LUW с их серверами. Об этом уже много здесь говорилось.

вы снова выдаете желаемое за действительное. смотрим что у нас в суровой действительности:

IBM expects to integrate its advanced research in cost optimization strategies coming out of the Starburst project (undertaken in IBM's Almaden research laboratories in California) into both the MVS and Unix implementations of the DB2 database product. Gilles Fecteau, architect of DB2/6000 Parallel Edition, indicates that customers for this high-end database focused on DSS workloads should see the benefits of the Starburst research in the Common Server implementation of DB2 as early as the first half of 1997. Because the research prototype for IBM's optimizer technology was developed in C++, it will be a much faster path for integrating the advancements into DB2's Common Server database engine (which is also implemented in C++) than will be the case for DB2 on MVS (which is implemented in assembler and PL/X-390).
http://web.archive.org/web/200710092007 ... 03d15.html

т.е. основные плюшки оптимизатора db2 z/OS получал из проекта Starburst. смотрим что это за проект:
The Starburst prototype runs under AIX on IBM PC/RT
workstations, and is being implemented in C to increase
portability. Starburst is still in the early prototype phase of
implementation.
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf

zVlad, а есть ли темы в которых вы действительно разбираетесь ?

[Dmitry67]

will be the case for DB2 on MVS (which is implemented in assembler and PL/X-390).

OMG!
assembler and PL/X-390
Это не просто две ветви кода
Это... даже не знаю что сказать...

[zVlad]

zVlad, а почему например Oracle мог сделать верхний уровень независимым от ОС, так что SQL одинаков (за исключением file names) что под Solaris что под Windows? зачем IBM тащить два проекта - видимо с разными code bases?

Насколько я понимаю Оракл практически не зависим от ОС и платформы. Так было задумано в дизайне. И это в принципе понятно поскольку Оракл не имел своей ОС. DB2 for z/OS с другой стороны очень тесно интегрирована и с z/OS и с железом МФ. Так что прямой перевод кода DB2 на LUW не представлялся возможным и поэтому DB2 for LUW имеет другой код базе.

В случае с DB2 тем не менее есть подмножество, и довольно широкое, SQL который одинаков для обоих кодебазе. Может что изменилось за 5-ть лет что я не работаю ДБ2, но думаю что только в лучшую сторону.

SQL вообще должен бы быть одинаков по идее между всеми производителями, и такое подмножество в самом деле имеется. Так что проблема скорее надумана чем реальна.

В отношении Оракл ИБМ делает дополнительные реверансы в виде имплементации оракловских подходов as is для облегчения перевода с Оракл на ДБ2. Делает ли подобное Оракл, или МС СКЛ было бы интересно узнать.

[zVlad]

оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS... Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что

По-моему, это из раздела "О религии".

Пока не знаешь предмета может и так показаться.

[Zombie416]

assembler and PL/X-390
Это не просто две ветви кода
Это... даже не знаю что сказать...

Ну это все "tales from the crypt". "... as early as the first half of 1997" ага. С тех пор переписали уже не раз, наверное.

[zVlad]

Я не знаю как там в Оракле, но в общей теории БД первичные и внешниие ключи обеспечивают целостность по ссылкам, не более того.

Ну да. Индексы - зло

Речь не об индексах как Вы заметили. В ДБ2 (по-крайней мере тогда когда я работал с ДБ2) индексы на ключи создавались отдельно. Более того правильный ключ должен быть и правильным индексом. Если это не так то что-то не верно в модели данных.

[Zombie416]

Пока не знаешь предмета может и так показаться.

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

Какие именно факты позволяют вам сделать выводы что "оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS... Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что" ? При том что эээ, предвзятость, этих тезисов очевидна.

[iDesperado]

Я не знаю как там в Оракле, но в общей теории БД первичные и внешниие ключи обеспечивают целостность по ссылкам, не более того. На выполнение или не выполнение стэйтментов они влияют только таким образом что не допускают нарушения целостности ссылок.

в теории так оно и есть, только теория не описывает и десятой части того, что в суровой реальности делает субд. и в частности теория не описывает cost-based оптимизатор и его статистики.

В Вашем запросе целостность по ссылкам не нарушается поэтому я не вижу причин почему бы такой запрос не мог бы выполниться в ДБ2 или МССКЛ (предполагая что в качестве таблицы в update может использоваться сабселект, который в принципе мог бы быть заменен view, опять же предполагая что такой view будет updatable).

А этот Ваш Update я бы переписал (в первом приближении) таким образом:

update tab1 t1 set a='111' where exists (select * from tab2 t2 where t1.id = t2.id)

извиняюсь, чуток другой запрос я имел ввиду:
update (select t1.name as a,t2.name as b from tab1 t1 inner join tab2 t2 on t1.id = t2.id) set a=b ;

суть в том что на одну запись t1 может приходиться несколько записей в t2 c разными t2.name и у сервера забавный выбор вылезает, а которое значение присвоить t1.name ?
вот оракл без форен кея который может убедить его, что на одну запись t1 приходиться не более 1 записи в t2 такой запрос не запустить.

[zVlad]

....
zVlad, а есть ли темы в которых вы действительно разбираетесь ?

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

[Dmitry67]

Поздравляю!
У меня рядом коллега - у него тоже ДР
Вот совпадения...

[zVlad]

Вы опустили слово "оптимизатор" в моей цитате.
Да, некоторые синтаксические штучки порой появляются раньше в db2 LUW, но это лишь отражение того что подход к разработке и выпуску новых версий для DB2 for z/OS отличается от db2 LUW. В части же оптимизатора напрасно Вас мучают сомнения. Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что разработчики DB2 LUW глупее или у них нет алгоритмов оптимизации (эта одна фирма и секретов у них нет внутри, для других фирм ИБМ оптимизатор - это секрет), а по причине отличия z/OS(МФ) и LUW с их серверами. Об этом уже много здесь говорилось.

вы снова выдаете желаемое за действительное. смотрим что у нас в суровой действительности:

IBM expects to integrate its advanced research in cost optimization strategies coming out of the Starburst project (undertaken in IBM's Almaden research laboratories in California) into both the MVS and Unix implementations of the DB2 database product. Gilles Fecteau, architect of DB2/6000 Parallel Edition, indicates that customers for this high-end database focused on DSS workloads should see the benefits of the Starburst research in the Common Server implementation of DB2 as early as the first half of 1997. Because the research prototype for IBM's optimizer technology was developed in C++, it will be a much faster path for integrating the advancements into DB2's Common Server database engine (which is also implemented in C++) than will be the case for DB2 on MVS (which is implemented in assembler and PL/X-390).
http://web.archive.org/web/200710092007 ... 03d15.html

т.е. основные плюшки оптимизатора db2 z/OS получал из проекта Starburst. смотрим что это за проект:
The Starburst prototype runs under AIX on IBM PC/RT
workstations, and is being implemented in C to increase
portability. Starburst is still in the early prototype phase of
implementation.
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf

zVlad, а есть ли темы в которых вы действительно разбираетесь ?

Вы сначала представили бы себе последовательность событий и даты когда что и где появилось, а затем бы брались выдергивать цитатки из источников ссылки на которые не открываются (первая ссылка).
Вторая ссылка судя по всему относится к концу 80-х когда до появления DB2 LUW было еще как минимум пять лет, а оптимизатор на МФ уже во всю использовался и совершенствовался.
Более подробно об истории DB2 и о том что появилось раньше и где можете почитать здесь:

http://en.wikipedia.org/wiki/IBM_DB2

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

P.S. Вот еще рекомендую почитать, может немного поправит Ваше извращенное представление о DB2:

http://ptgmedia.pearsoncmg.com/images/0 ... s/appe.pdf

[zVlad]

Поздравляю!
У меня рядом коллега - у него тоже ДР
Вот совпадения...

Я полагаю сегодня, как впрочем и любой другой день, у многих людей ДР. Передай мои поздравления коллеге.

[iDesperado]

2zVlad

Мои поздравления !

ссылка сию секунду у меня открылась, минут 10 назад тоже не открывалась.
судя по всему вы не поняли суть моих ссылок. речь о том, что оптимизатором для zOS занималась команда, которая в первую очередь работала на Unix, применяя совершенно чуждый идеологии МФ переносимый язык C.

Вторая ссылка судя по всему относится к концу 80-х когда до появления DB2 LUW было еще как минимум пять лет

вы путаете маркетинговые названия с программными продуктами. LUW это всего лишь новое название все той же субд, что была на RS/6000.

[zVlad]

.....
Какие именно факты позволяют вам сделать выводы что "оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS... Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что" ? При том что эээ, предвзятость, этих тезисов очевидна.

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

Мое предвзятое мнение в частности базируется на том что я слышал году эдак 2004-ом от человека работающего в Toronto Lab над DB2.

Посмотрите также как обстояли дела с оптимизатор у Оракл. Давно ли у него появился cost based оптимизатор и какую роль в Оракл играют (по крайней мере недавно играли) hints.

[Abappy]

Прошу у всех прощения, что в спор встреваю, но нельзя ли его как-нибудь перевести в более уважительное по отношению друг к другу русло ?

Вы сначала представили бы себе последовательность событий и даты когда что и где появилось, а затем бы брались выдергивать цитатки из источников ссылки на которые не открываются (первая ссылка).

1) ссылка открывается .
2) о последовательности событий

Вторая ссылка судя по всему относится к концу 80-х когда до появления DB2 LUW было еще как минимум пять лет, а оптимизатор на МФ уже во всю использовался и совершенствовался.
Более подробно об истории DB2 и о том что появилось раньше и где можете почитать здесь:

2.1) по вашей ссылке о DB2 LUW говорится "An earlier version of the code that would become DB2 LUW (Linux, Unix, Windows) was part of an Extended Edition component of OS/2 called Database Manager." ... Вы хотите сказать, что в 80е его не существовало ?
2.2) фраза "In mid 2006, IBM announced "Viper," which is the codename for DB2 9 on both distributed platforms and z/OS. DB2 9 for z/OS was announced in early 2007. " скорее говорит в пользу теории Вашего оппонента.

[zVlad]

2zVlad

Мои поздравления !

ссылка сию секунду у меня открылась, минут 10 назад тоже не открывалась.
судя по всему вы не поняли суть моих ссылок. речь о том, что оптимизатором для zOS занималась команда, которая в первую очередь работала на Unix, применяя совершенно чуждый идеологии МФ переносимый язык C.

....

Спасибо.

Проверю ссылку сей момент.

Это не так повторяю ссылку:

http://ptgmedia.pearsoncmg.com/images/0 ... s/appe.pdf

там в секции "Optimizer Differences" почитайте.

[Abappy]

.....
Какие именно факты позволяют вам сделать выводы что "оптимизатора, который у DB2 для z/OS на сегодня более продвинутый чем у какой-либо другой RDBMS... Оптимизатор DB2 for z/OS - это цель к которой стремится, но никогда не достигнет, DB2 LUW, не достигнет и не потому что" ? При том что эээ, предвзятость, этих тезисов очевидна.

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

С этим всегда рад помочь (да и Вы сами уже писали). Оптимизатор DB2 в части касающейся динамического SQL лично я могу охарактеризовать только словами, за которые по головке на форуме не погладят. Одна "привычка" оптимизировать конкретный запрос не проанализировав значения всех переменных которые в данный конкретный момент в нём стоят уже достаточна для нездорового смеха. Поясню на примере

Есть две таблицы - в первой 10 миллионов (+-) записей, во второй 100 тысяч (+-) записей , создаётся запрос по объединению таблиц ( по ключу с соотношением 1:n ( то-есть н записей во второй таблице соответствует одна запись первой) ) с условием по одному из полей (не ключевых) второй таблицы (селект из второй таблицы с этим условием возвращает 1 тысячу (+-) записей . Вторичные индексы и по полям объединения и полям выборки и по всем вместе и т.д. - есть.

Все известные мне базы данных за исключением дб2 сначала выбирают данные из второй таблицы а потом с ними строят джойн с первой . Дб2 в зависимости от фазы луны и т.п. вещей в 50%+ случаев решает, что сначала стоит построить полный хэш джойн обеих таблиц, а потом уже к нему применить ограничение (и получить тысячу записей в результате).

Итого этот банальный запрос выполняется иногда больше 10 секунд.

[Zombie416]

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

С Днем рождения!

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

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

[zVlad]

..... смотрим что у нас в суровой действительности:

IBM expects to integrate its advanced research in cost optimization strategies coming out of the Starburst project (undertaken in IBM's Almaden research laboratories in California) into both the MVS and Unix implementations of the DB2 database product. Gilles Fecteau, architect of DB2/6000 Parallel Edition, indicates that customers for this high-end database focused on DSS workloads should see the benefits of the Starburst research in the Common Server implementation of DB2 as early as the first half of 1997. Because the research prototype for IBM's optimizer technology was developed in C++, it will be a much faster path for integrating the advancements into DB2's Common Server database engine (which is also implemented in C++) than will be the case for DB2 on MVS (which is implemented in assembler and PL/X-390).
http://web.archive.org/web/200710092007 ... 03d15.html
...

Cылка наконец и у меня открылась. Я не понимаю чем этот обзор всего и вся помаленьку Вас так возбудил. Это частное мнения написавших этот обзор, которое дает ложное представление что де оптимизатор для Common Server и DB2 for MVS суть одно и тоже. Плюс делает очень спорное предположение что разработка на С++ может быть быстрее чем на PL/X-390 и ассемблере. Впрочем в 97 году такие заблуждения могли быть не редкость.

Кстати Вы процитировали буквально все что в ссылке говорится об оптимизаторе ИБМ. Негусто.