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

[StrangerR]

Я глянул - это надо сразу из кармана выкладывать примерно $100K - $200K на одну железку. ПОтом еще столько же на вторую. А потом надеяться что угадали с конфигурацией и с потребностями и не потребуется еще тыс 200 выкладывать (про софт я и не говорю). Если учесть что проекты начинаются с небольших конфигураций, и принести менеджерам запрос на $100K _ап-фронт_ конечно можно но итоги предсказуемы - то будущего это все не имееет просто никакого.

Вообще-то 100-200К апфронт на железо это иногда даже не повод поморщиться (что никак не отменяет того факта, что ибм штука дорогая)

Кстати, тут подивился разбирая очередную железяку от IBM которую только что спустили в джанк ярд (точнее диски от нее). У меня лежат дисковые треи от - IBM, Compaq, Sun, Dell (ну эти отличаются многообразием, не знаю что там за полиси но они их меняют как перчатки). У всех треи как треи, у IBM - расчитаны на попадание ядерной бомбы и зачем то к диску прилеплен еще пассивный переходник - то есть вместо того чтобы scsi (треи от SCSI дисков) от диска втыкать в бэкплейн, диск воткнут в переходник, переходник ввернут в трей пудовыми шурупами, а потом с другой стороны он же втыкается в бэкплейн. А теперь вопрос - вы думаете это все бесплатно??

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

Ну да - я в итоге нашел фотку, как в японии все ИБМовское железо попадало на бок, валяется на полу, погнулось - но работало. Правда, я не очень понял откуда оно электричество брало, но тем не менее. Глядя на пустой трей (диск из которого уехал жить дальше в DELL), по весу как кирпич, и по исполнению - абсолютно железобетонное кондовое изделие (куда до него DELL-у или SUN-у с их смешными жестяными треями) - готов поверить. Только вот все это денег стоит, и немалых, и главное - платить надо СРАЗУ И СЕЙЧАС.

100 тыс - это кстати не так уж и мало, хотя конечно большой проект больше стоит. Но как то мы все последние проекты успешно начинали с апфронт в несколько десятков тысяч - штук 6 серверов, пара свитчей, пара фиреволлов, iSCSI стоечка, лицензия на Vmware VC, кластеры - и все это уезжает в отдальенный центр и там успешно встает и работает. А потом уже, когда у клиента глазки разгорятся, можно и о 200 тыс разговаривать... Притом за это время сервера становятся вдвое быстрее и диски вдвое больше, за те же деньги... поэтому чем меньше апфронт вложений тем выходит лучше. Опыт сразу о миллионом развороте говорить был... бобик сдох не вылупившись в итоге.. клиенту ждать надоело...

[iDesperado]

Payment Solution Providers Expects to Save up to 35% in IT costs with IBM System z and DB2 Software over HP servers with Oracle databases

интересно а самих товарищей то предупредили что они чего-то expects или как обычно это фантазия сугубо IBM?

Я глянул - это надо сразу из кармана выкладывать примерно $100K - $200K на одну железку. ПОтом еще столько же на вторую. А потом надеяться что угадали с конфигурацией и с потребностями и не потребуется еще тыс 200 выкладывать (про софт я и не говорю). Если учесть что проекты начинаются с небольших конфигураций, и принести менеджерам запрос на $100K _ап-фронт_ конечно можно но итоги предсказуемы - то будущего это все не имееет просто никакого.

100к фигня, на фоне денег которые за спеца по МФ придется выложить.

проблемы перехода с IBM видел не раз: берут CABOL в без переделок забубенивают на оракл, а потом долго удивляются чего это блокировочный подход IBM так хренового работает на версионном оракле.

[zVlad]

1. 100к фигня, на фоне денег которые за спеца по МФ придется выложить.

2. проблемы перехода с IBM видел не раз: берут CABOL в без переделок забубенивают на оракл, а потом долго удивляются чего это блокировочный подход IBM так хренового работает на версионном оракле.

1. Ну сколько же по Вашему нужно выкладывать за сеца на МФ? А сколько их надо?

2. Что такое CABOL и какое отношение он имеет к блокировочникам или версионникам?

Как там идет изучение надежности в общем и МФ в частности?

[Зырянин]

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

[iDesperado]

2zVlad
а можно я нарвусь уже на беспощадный игнор с вашей стороны ? ваша манера общения и нравоучения достали ...

[zVlad]

2zVlad
а можно я нарвусь уже на беспощадный игнор с вашей стороны ? ваша манера общения и нравоучения достали ...

Конечно можно, но Вы, извините, сами упорно нарывались.
Такая манера общения и нравоучительство, к которым Вы сами вынудили меня, мне неестественны и я тоже как все нормальные люди не люблю такие манеры и нравоучительство. Поверьте на слово, в жизни это так. Вообще то я человек толлерантный и много могу понять и пропустить, но в определенный момент дискуссий (гораздо реже в жизни) мне вдруг становится очевидным что с этим человеком бесполезно толлерантничать и можно не сдерживаться, тем более что сдерживание сродни насилию над собой, а это нездоровый фактор.
Ну и учтите как смягчающий фактор моей вины что мне, в свою очередь, тоже приходится много негативно читать в отношении себя и Вы не единственный манеры общения которого и нравоучительство меня тоже уже порядком достали. А еще больше и уже давным давно меня достало дремучее невежество в вопросах крупных ИТ архитектур, качественно иного уровня чем уровень ПС-ков.
Подходы с писюковым мышлением меня не только здесь на форуме достали но гораздо больше на работе, где, как наверное в большенстве контор, я опутан этими писюковыми решениями, которые затрудняют мне доступ к МФ, работа на которых собственно и является моей задачей. Это еще при том что мне удается выкручиваться и делать этот доступ короче чем требуется официально. Мне это удается потому что я умею находить подход к людям и угововаривать их делать для меня исключение и поблажки. Моя коллега, которая более покладиста и менее требовательная, постоянно стонет и плачет от официально предусмотренного доступа к МФ, который проходит через паутины из Citrix серверов, часть из которых вообще находятся в США, в то время как мы и наши МФ здесь в Канаде. Я считаю это просто вредительство.

[Dmitry67]

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

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

[Zombie416]

качественно иного уровня чем уровень ПС-ков.

О. Так в чем же именно состоит "качественно иной уровень", на который вы постоянно ссылаетесь? Все время кажется что под PC и x86 вы подразумеваете IBM PC AT x286 образца 1984 года.

Воды с тех пор утекло много, и в x86 уже приехала и виртуализация, и MCA, и hot-swap/hot-plug/.., и т.д. А с чистой производительностью так и вообще дела обстоят лучше чем у МФ, и при этом дешевле.

Так что осталось такого качественно иного в МФ? Ну кроме системы сбора денег с пользователей основанной на MIPS-ах, до реализации которой продавцы Intel/AMD пока не дошли (хотя слухи ходили).

[zVlad]

качественно иного уровня чем уровень ПС-ков.

О. Так в чем же именно состоит "качественно иной уровень", на который вы постоянно ссылаетесь? Все время кажется что под PC и x86 вы подразумеваете IBM PC AT x286 образца 1984 года.

Воды с тех пор утекло много, и в x86 уже приехала и виртуализация, и MCA, и hot-swap/hot-plug/.., и т.д. А с чистой производительностью так и вообще дела обстоят лучше чем у МФ, и при этом дешевле.

Так что осталось такого качественно иного в МФ? Ну кроме системы сбора денег с пользователей основанной на MIPS-ах, до реализации которой продавцы Intel/AMD пока не дошли (хотя слухи ходили).

Нет я не подразумеваю IBM PC AT x286 образца 1984 года, не надо меня выставлять идиотом, пожалуйста. Наоборот это о МФ регулярно приходится здесь читать - это компьютер с перфокарточным вводом. И на МФ много воды утекло с 1964 года.

Да, для меня было в нове узнать о MCA, и hot-swap/hot-plug/. И я почитал даже больше чем мне было предложено и привел ссылку где это читал в надежде что если этого окажется недостаточно, но мне на это укажут. Не указали. Но из этой ссылки следует что по сравнению с МФ эта тема находится в самом своем зачаточном виде и выглядит очень непрактично (только dedicated процессора и только кратно 4-м полность с их памятью не больше и не меньше, процессора для замены выбывших "отбираются" у менее привелигированных систем) и вряд ли (поправьте) широко используется. Совсем иначе обстоят дела на МФ. Там все это используется всегда и везде без исключения. Потому что реализованно весьма практично и удобно, а это потому что работы в этом напралении на МФ ведутся уже лет двадцать. Все просто, надо только понять.

Про качественные отличия МФ я здесь исписал тонны байтов. Были очень подробные изложения этих возможностей. Да многим из Вы и Ваши коллеги находили аналогии, но при близком рассмотрении эти аналоги оказывались очень далекими по многим параметрам от того что есть на МФ. Миллион раз я здесь писал что МФ не одиночный сервер (компьютер если хотите). Один МФ уже представляет из себя целый комплекс серверов если сравнивать с архитектурами (реальными не в вакууме) на базе Интел серверов. Как результат, если приложение переносится с МФ то заменяющая его архитектура всегда состоит из набора серверов, раутеров и лоад балансеров.

[zVlad]

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

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

Когда я это писал, поверьте мне Дима, я знал о чем пишу и что мне найдут пример бьющий не в бровь а в глаз.

Главная задача ВМ - это моделирование реальной машины. Реальные машины делают по определенным спецификациям и эти спецификации хорошо известны и для этих спецификаций есть тест кейсы. Всякий раз когда ИБМ выдают новый релиз zVM, все эти тесты прогоняются и если какой-нибудь не проходит то релиз возвращается на доработку. Это первый момент.
Второй момент состоит в том что бОльшая часть исполняемого кода виртуальной машины исполняется непосредственно реальным процессором, и только привелигированные команды эмулируются управляющей программой VM в соответсвии с принципами работы МФ, опять же хорошо известными и достаточно хорошо тестируемыми в каждом релизе.
Все сказанно мной естественно не исключает багов как нечто что было бы здорово не иметь и надо бы пофиксать. Но к главной задаче ВМ (см. выше) отношение не имеет. Тот пример что был мне приведен в ответ на мое заявление касался (если мне память не изменяет) утечки памяти которая приводила к краху системы (или виртуальной машине). Мое же мнение таково что по настоящему ьагом ВМ следует считать не выполнение ей принципов работы реальной машины. Крах управляющей системы к таким багам не относится - это лишь говорит о том что в управляющей программе хорошо налажен контроль.
В 80-е годы я участвовал в бета тестировании новой версии СВМ из Минска. Система рушилась на день по нескольку раз и работа прерывалась. Я терпеливо собирал дампы памяти и отправлял их разработку, а систему перезагружал. Это все делалась как нынче бы сказали на продакшн, а тогда это была физически единственная система той компании где это происходило. Но ни разу не прозошло искажения информации или ее потери (кстати это было ВЦ областного статуправления). Вот в этом смысле я и сейчас могу повторить что в ВМ z/VM багов нет. Как мы все считаем их нет в реальной машине, хотя и относимся к этому конечно скептически.

Вас, Дима, такое объяснение удовлетворяет или Вы будет повторять как заклинание что нет программ без багов с которым в принципе я согласен если мы говорим о программах вообще?

[zVlad]

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

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

Касательно того как я с менеджерами работаю. Ваш пример не релевантен просто потому что с менеджерами мы совсем на другом уровне разговариваем, и совсем о другом. И Ваше преположение что я всего лишь пытаюсь "вдалбливать, что МФ лучше" тоже не имеет никакого отношения к тому что на самом деле происходило там. Ну и наконец, Дима, если бы я в самом деле обладал таким мощным влиянием на мнение менеджеров, то я бы наверно догадался вдалбливать им что МФ хуже и как результат они бы поступали по своему, т.е. диаметрально противоположно мне, и я был бы доволен.
Наивно это все, Дима, очень наивно. Уж извините другого ничего сказать не могу.

[zVlad]

....
2. проблемы перехода с IBM видел не раз: берут CABOL в без переделок забубенивают на оракл, а потом долго удивляются чего это блокировочный подход IBM так хренового работает на версионном оракле.

.....
2. Что такое CABOL и какое отношение он имеет к блокировочникам или версионникам?

.....

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

[iDesperado]

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

да я не обижаюсь, просто мне не приятно общаться с людьми которые на форумах решают какие-то свои психологические проблемы. вам явно нужно доказать свою правоту и вам пофигу на технические аспекты и аргументы. может у вас есть свои причины так вести разговор, но мне честно говоря в них разбираться не интересно, я кому считал это важно все, что хотел доказал. на самом деле мне бы многое было бы интересно поспрашивать о МФ, но от вас за последние пару лет я не услышал ни одного внятного пояснения. вы сыпите какими-то не нужными подробностями и терминами но не можете элементарно разьяснить чем RACF принципиально лучше банального LDAP.
что касается версионника то прикладухи под db2 всегда заточены на пессимистичный блокировочный режим. db2 как и все блокировочники в поисках компромисса между скоростью и concurrency изобрели тьму видов блокировок, от блокировок намерения до shared. в оракле такого зоопарка блокировок нет, поэтому если логику приложения переносить на версионный оракл в лоб, результат гарантированно окажется хреновым. если халтурить и не проводить редизайна логики прикладухи, то можно запросто получить дурное приложение которое будет фиговое на современных платформах, хотя и ворочилось на стареньком МФ.

[Dmitry67]

zVlad, то что вы написали относится к ядру VM. Vm же программный продукт, который содержит кучу всего, а не только собственно 'железную эмуляцию', про которую вы говорили. А в программном коде всегда бывают ошибки.

[zVlad]

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

.....
что касается версионника то прикладухи под db2 всегда заточены на пессимистичный блокировочный режим. db2 как и все блокировочники в поисках компромисса между скоростью и concurrency изобрели тьму видов блокировок, от блокировок намерения до shared. в оракле такого зоопарка блокировок нет, поэтому если логику приложения переносить на версионный оракл в лоб, результат гарантированно окажется хреновым. если халтурить и не проводить редизайна логики прикладухи, то можно запросто получить дурное приложение которое будет фиговое на современных платформах, хотя и ворочилось на стареньком МФ.

А можно было обойтись без неуместного эпитета "старенький"? Ладно хрен с ним пропустим.

Весь этот как Вы говорите заоопарк блокировок в приложениях никак не выражается, просто для них нет в языке конструкций, - это внутренне дело ДБ2, который сам их так или иначе разруливает. При переносе на версионник включается внутренний механизм версионника и в общем случае нужды переписыват логику не должно возникать. Если Вы не согласны приведите пример таких трудностей и как бы следовало с ними поступать. И мы на этом примере может и разберемся.
Другое дело когда мы делаем обратный перенос. Поскольку версионник - это оптимистический режим, то, как я понимаю, при таком переносе действительно требуется что-нибудь поделать, например, добавить коммитов, которых так не любят, точнее забывают о них, программисты на МФ (как поступают программисты на Оракл я не знаю).

А вопросы по МФ задавать не стесняйтесь. Я постараюсь как-нибудь изменить свой стиль объяснения чтобы сделать это более доходчиво.

[Dmitry67]

Я приведу пример.
Имеем два процесса. Процесс A меняет чтото в документе. Процесс B в этот момент пытается создать копию.

Блокировочник:
А начинает менять документ
B начинает читать его и останавливается изза блокировки
A делает commit
B копирует измененный документ

Версионник:
А начинает менять документ
B начинает читать его и читает оригинальную версию
A делает commit
B не дожидаясь этого делает копию документа ДО изменений

В итоге при переходе на версионник поведение меняется

[iDesperado]

2zVlad

старенький это именно возраст. т.е. заточенная на блокировочник прикладуха может неплохо работать на db2 и железе 10 летней давности, но при этом плохо на новом железе с ораклом.
пример: в дб2 я часто встречаю при организацию oltp нагрузки схему по разводу читателей и писателей. например у нас таблица accounts в нем поле balance, и таблица payments. в оракле у меня все просто, пишем в таблицу payments и в той же транзакции обновляем поле balance. поскольку оракл версионный это не создает никаких проблем любой читатель ради отчета может хоть несколько часов читать таблицу acounts не создавая проблем остальным. в db2 такой подход не приемлим, т.к. если читатель начнет читать таблицу accounts он не сможет получить консистентный отчет на уровне Read Commitedd, а более высокий уровень стопорнет пишушие транзакции, т.к. те буду ждать пока отчет с более высоким уровнем изоляции чем RC отпустит блокировки. в db2 я регулярно встречаю такой финт. вводится понятие закрытый период, асинхронный процесс, допустим раз в сутки "закрывает день" вычитывая payments поступившие за день и обновляет поле balance таблицы accounts. дальше что бы получить консистентный отчет на определенное время (на время Ч) читатель составляющий отчет читает на уровне RC balance и прибавляет к ним сумму payments за этот день зафиксированных до времени Ч. как видите оптимальные подходы db2 и оракла совершенно разные.
что плохо проэмулируется в оракле элементарно - оператор открывает окошко и db2 накладывает shared блокировку на запись (не дает изменить другим), не продумав последствия в оракле в лоб это можно проэмулировать SELECT FOR UPDATE, т.е. установкой эксклюзивной блокировкой, но тогда все открыватели должны открывать окошко последовательно.

[Zombie416]

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

В DB2 нет способов управления блокировками? Ну и при переходе на версионник проблемы именно что должны возникать.

Элементарный пример, работающий (медленно) в блокировочнике:

SELECT @x=Balance FROM UserBalance WHERE UserName='John'
...
UPDATE Balance=@x-1

В версионнике может запросто приводить к порче данных, если запустить 2 запроса параллельно.

Давайте лучше все-таки про достоинства МФ как класса, без баз. Базы это так, прикладная программа. Да, весь этот hotswap CPU появился в x86 недавно, и врядли используется сильно чаще чем МФ, поэтому людей щупавших это руками не так много. А людей которым это реально было надо, еще меньше (часто у вас на МФ процессоры практически горели?). Но факт - это сегодня есть в x86, а в Itanium-ах было давно. И сбойная память на лету обнаруживается и отключается, в том числе до того как это дошло до приложения, и т.д.

Лучше-хуже оно сделано чем в МФ - второй вопрос, а размер ячейки и отбираются ли ресурсы у менее привилегированных работающих систем, или менее привилегированные системы всегда простаивают в резерве, вообще бессмысленный в отрыве от цены. И современные x86 сервера - это тоже много серверов в одном, т.к. загрузить 96+ потоков даже обычного 4х процессорного сервера без многих VM крайне сложно.

Есть какие-то действительно принципиальные отличия?

[iDesperado]

Давайте лучше все-таки про достоинства МФ как класса, без баз. Базы это так, прикладная программа.

я привел базы просто как элементарное объяснение почему миграция с МФ в unix/оракл могла хреново окончиться и причем там cobol.

[zVlad]

2zVlad

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

Мы в прошлом году летом перешли на z10, которое было аннонсированно за год полтора до этого. Это что по Вашему старое железо? db2 как впрочем и Оракл появились лет тридцать назад. То что Вы называете "новым" железом тоже в основном сформировалось пару десятков лет назад и лишь увеличивалась его производительность. Я честно хочу Вас понять, но всегда говорите такие вещи, которые просто шокирует своей непродуманостью. Как так получается?
Какие механизмы давно стандартизованного SQL могут мешать прикладухам "неплохо работать на db2 и ....но при этом плохо на .... оракл"? Объясните. То что Вы написали в Вашем примере не имееет никакого отношения к тому что Вы заявляете абстрактно. Я это Ваш пример еще поизучаю, но уже видно что Вам просто не нравится некая модель данных и Вы пытаетесь обяснить ее происхождения какими то недостатками ДБ2. На самом же деле моделирование данных в реляционных БД - это теория абстрагированная от любой конкретной реализации DBRM. Я изучал эту теорию в начале 90-х по книжке Дэйта "DB2 руководство по реляциооной БД". По ней же учились наши ребята пишущие для Оракл.

[Dmitry67]

Это не недостаток DB2 а разница работы версионников и блокировочников.
Вы действительно, прежде чем обвинять других (шокирует своей непродуманостью), действительно, "шокирует своей непродуманостью"
Поизучайте, поизучайте. Вы знаете, я этим придеметом занимаюсь годы, а вам похоже лишь бы потроллить.

[Dmitry67]

А вообще давайте так. В MS SQL версионность может включаться и выключаться.
Я могу написать пример, который работает одним способом в блокировочнике и иным в версионном режиме.
Если мне это удасться, то мне $1000. Если нет - то я вам плачу $1000.
Идет?
Я серьезен. И отвечаю за это своим опытом и деньгами.
А вы деньги свои положите на свои заявления?

[iDesperado]

Мы в прошлом году летом перешли на z10, которое было аннонсированно за год полтора до этого. Это что по Вашему старое железо?

давайте вспомним, что вы писали

Клиент, ушедший три года назад с МФ на Юникс с Оракл, едва ли не каждую неделю "лежит" по нескольку часов. А до того у него лишь иногда на МФ были проблемы с респонс тайм, исключительно потому что они не хотели немного потратиться либо на хард либо на тюнинг базы данных и решить эту проблему радикально (уже намыли лыжи тогда).

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

Вы пытаетесь обяснить ее происхождения какими то недостатками ДБ2. На самом же деле моделирование данных в реляционных БД - это теория абстрагированная от любой конкретной реализации DBRM. Я изучал эту теорию в начале 90-х по книжке Дэйта "DB2 руководство по реляциооной БД". По ней же учились наши ребята пишущие для Оракл.

проектирование в отрыве от конкретной реализации - утопия. вникните в мой пример с accounts и payments

[zVlad]

2zVlad

....
пример: в дб2 я часто встречаю при организацию oltp нагрузки схему по разводу читателей и писателей.....

Я начал было разбираться с этим Вашим пример, но на самой первой фразе споткнулся. Откуда Вы это взяли? Никогда и нигде в рукодствах по ДБ2 мне не встречалась эта тема. Даже терминологии такой: читатели, писатели. Вы ее сами придумали.
Попробую читать дальше.

[iDesperado]

Я начал было разбираться с этим Вашим пример, но на самой первой фразе споткнулся. Откуда Вы это взяли? Никогда и нигде в рукодствах по ДБ2 мне не встречалась эта тема. Даже терминологии такой: читатели, писатели. Вы ее сами придумали.
Попробую читать дальше.

To avoid these problems, RR readers take an additional S-lock in the first row that does not qualify as the RR predicate, that is, in this example ...

In general, writers (an update statement in this case) make an implicit read claim, which can be either a CS or RR read claim (it will be a RR read claim if WITH RR is specified).
http://www.redbooks.ibm.com/redbooks/pdfs/sg244725.pdf