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

[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

[zVlad]

2zVlad
......

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

1. "в оракле у меня все просто, пишем в таблицу payments и в той же транзакции обновляем поле balance. поскольку оракл версионный это не создает никаких проблем " - если остановиться на этом месте Вашей фразы, то можно вернуться в начало ее и заменить "оракл" на "дб2". Дальше Вы искусствено начинаете, в полном соответсвии с Оракл документацией, создавать иллюзию что кому могут быть часами интересны данные которые уже заведомо изменены. Кстати это можно сделать и в ДБ2, как с RC так и с UR. Результат во всех трех случаях будет примерно одинаков - неконсистентси, или неактуальность данных.
Финт, который Вы регулярно встречаете в ДБ2 может быть не более чем постановочный момент. Так была поставленна задача. И в самом деле кому на хрен может быть нужен отчет на произвольный текущий момент если заранее известно что он устареет в следущее мгновение?

2. В этом фрагменте Вы используете не известную мне терминологию. В ДБ2 такого термина - окошко - нет. Может Вы имеете в виду курсор? Нужно ли обязательно эмулировать блокировку строки с уровнем изоляции RC c помощью SELECT FOR UPDATE я не могу сказать, это зависит от других обстоятельств, о которых Вы здесь не говорите, что вообщем то сами подтверждаете говоря "не продумав последствия в оракле". А продумав что Вы делаете в этом случае?

[zVlad]

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

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

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

Вы забыли порассуждать о возможности совместного использования всех имеющихся процессоров всеми созданными партициями. Как я понял ни в Itanium ни в х86 этого нет. Ничего не сказали Вы о том как разделяется память. Из того что я прочитал следует что каждая ячейка имеет свою память и эта память вся вместе с ячейкой путешествует. Это плохо. Память должна быть доступна всем процессорам и делиться независимо от деления процессоров. Выгоревшие ресурсы (ни один процессор за 11 лет работы там где я работаю не сгорал) восполняются имеющимися в наличии и недоступные для распределения. В z196 используется the Redundant Array of Independent Memory (RAIM), аналог RAID.

Имеет ли смысл говорить об этом в отрыве от цены? Мне кажется что каждый выбирает себе то что ему больше подходит, соответствует его представлениям о потребительских свойствах товара. Одни покупают обувь за $15 в то время как другие за $150 и более.

Говоря о том что МФ представляет из себя некое множество серверов я не про виртуальные машины, помогающие загрузить рессурсы, говорил. Я имел в виду что, например, сетевая карта в МФ - это раутер, балансер и терминальный сервер (сотни полторы терминалов поддерживается одним из портов этой карты). Каналы ввода-вывода - это тоже практически отдельные компьютеры со своими процессорами. На системном уровне zOS (не ВМ) позволяет и прекрасно справляется (это даже весьма приветствуется и рекоммендуется) с самой разнообразной нагрузкой в количествах подъемных боксу по производительности. Я имею в виду одновременно БД, аппликэйшн сервера, веб вервера, NFS, FTP сервер, принт сервер и многое другое, все в одной системе.

[iDesperado]

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

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

И в самом деле кому на хрен может быть нужен отчет на произвольный текущий момент если заранее известно что он устареет в следущее мгновение?

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

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

Нужно ли обязательно эмулировать блокировку строки с уровнем изоляции RC c помощью SELECT FOR UPDATE я не могу сказать, это зависит от других обстоятельств, о которых Вы здесь не говорите, что вообщем то сами подтверждаете говоря "не продумав последствия в оракле". А продумав что Вы делаете в этом случае?

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

ЗЫ. забыл добавить, в лоб такое поведение db2 в оракле эмулируется через пакет DBMS_LOCK, но про его существование нужно знать ...

[zVlad]

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

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

Если Вы имеете в виду переход о котором я говорил, то это был не переход в том смысле который Вы вкладываете. Это приложение изначально разрабатывалось быть двухплатформенным - МФ, и Юникс с Оракл. Вендор предоставляет это приложение для обеих платформ. И более того, я недавно услышал что вендор ведет разработку как раз в Юникс/Оракл и лишь потом делает адаптацию на МФ.

[zVlad]

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

Вот именно. Поэтому Вы и видите "финты" в ДБ2 и наверное не только в ДБ2.
Поетому создаются warehouse на которых нет изменений и запросы с UR будут давать такие же результаты что в случае версионника.

[zVlad]

.....

Нужно ли обязательно эмулировать блокировку строки с уровнем изоляции РЦ ц помощью СЕЛЕЦТ ФОР УПДАТЕ я не могу сказать, это зависит от других обстоятельств, о которых Вы здесь не говорите, что вообщем то сами подтверждаете говоря "не продумав последствия в оракле". А продумав что Вы делаете в этом случае?

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

ЗЫ. забыл добавить, в лоб такое поведение дб2 в оракле эмулируется через пакет ДБМСЛОЦК, но про его существование нужно знать ...

Одно из применений этого пакета согласно Оракл:

Synchronizing applications and enforcing sequential processing

и это в точности то ради чего и почему ДБ2 блокировочник. Мне кажется здесь больше просто нечего сказать.

[iDesperado]

Synchronizing applications and enforcing sequential processing

и это в точности то ради чего и почему ДБ2 блокировочник. Мне кажется здесь больше просто нечего сказать.

согласен !
современные системы идут к многоядерности и параллельной обработке, а db2/zOS создан ради sequential processing
и здесь больше просто нечего сказать....

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

[zVlad]

Сынчронизинг апплицатионс анд енфорцинг сэуентиал процессинг

и это в точности то ради чего и почему ДБ2 блокировочник. Мне кажется здесь больше просто нечего сказать.

согласен !
современные системы идут к многоядерности и параллельной обработке, а дб2/зОС создан ради сэуентиал процессинг :мргреен:
и здесь больше просто нечего сказать....

ЗЫ. ну вобщем я все, что мог сделал. примерчик мой похоже для вас оказался слишком сложным, ну что же, тогда еще есть предложение Дмитры67 наспор продемонстрировать вам различия версионного и блокировочного режима

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

What do locks do? A lock associates a DB2 resource with an application process in
a way that affects how other processes can access the same resource. The process
associated with the resource is said to “hold” or “own” the lock. DB2 uses locks to
ensure that no process accesses data that has been changed, but not yet committed,
by another process.
What do you do about locks? To preserve data integrity, your application process
acquires locks implicitly, that is, under DB2 control. It is not necessary for a process
to request a lock explicitly to conceal uncommitted data. Therefore, sometimes you
need not do anything about DB2 locks. Nevertheless processes acquire, or avoid
acquiring, locks based on certain general parameters. You can make better use of
your resources and improve concurrency by understanding the effects of those
parameters.

[Abappy]

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

Давайте я Вас помирю? Что блокировка, что версионность на уровне таблиц и "гроша ломаного" не стоит. Нынешние гадкие сущности состоят из десятков таблиц зачастую никакими "связями" в БД не объединённых. Поэтому все выкручиваются как умеют (и в частности все "warehouse" делают это по своему). С точки зрения анализа "отчего оно сломалось" версионность конечно приятнее, но и код, который работает неправильно для версионных систем написать проще

[iDesperado]

ну допустим вам не доказали, пускай. не вы один такой. но речь то тут не об этом. речь то о том, что они РАЗНЫЕ. речь то о том, что если перенести блокировочный подход без редизайна в лоб то хрень на оракле получится.