Мы уходим с майнфрайм.

User avatar
idle0
Уже с Приветом
Posts: 2846
Joined: 28 Jun 2000 09:01
Location: Milwaukee, WI

Re: Мы уходим с майнфрайм.

Post by idle0 »

iDesperado wrote: 02 Jan 2021 10:40
mskmel wrote: 31 Dec 2020 15:02 flashgrid например, да это не exadata, но тоже очень быстрое:
https://www.flashgrid.io/news/oracle-ra ... t-55-gb-s/
фишка exadata в том, что превращает оракл в субд с элементами mpp. там сторидж размазывает чтение по узлам, фильтрует блоки при фулскане например. т.е. ценность exadata не в железячке, а скорее в софте.
А как она это делает? Как я понимаю в Exadata нет shared storage в традиционном смысле (SAN/SAS multipath)

Там каждый storage node - это просто коробка с локальными дисками
moria# show running-config
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

idle0 wrote: 26 Jan 2022 02:22
А как она это делает? Как я понимаю в Exadata нет shared storage в традиционном смысле (SAN/SAS multipath)

Там каждый storage node - это просто коробка с локальными дисками
Тут ответил
viewtopic.php?f=46&t=237278
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

GoldenGate, мною, послан в топку.
Оракл пыжился решить одну проблему, но так и не смог. Причем проблема эта возникала стабильно но на Продакшн, и не возникала вообще на QA. На их тестовой установке она тоже не возникает. Я сказал на прошедшей неделе хрен вам, а не тестовая площадка на нашей Продакшн. И переключился на альтернативу.
Вернулись к тому что я предлагал больше года назад - IBM InfoSphere Data Replication.
Начали на прошедшей неделе. Пока не все устаканилось, но есть уверенность что все будет ОК.
В целом по проекту ухода с мэйнфрэйм есть большой пессимизм. По срокам пока.
По деньгам уже точно это золотой проект.
А что еще смешнее это то что по разным причинам мы будем переходить на новый мэйнфрэйм взамен того что сейчас ранит приложение которое уже второй год переводится в Ажур. О котором и речь здесь.
Причем случиться это планируется самое позднее за месяц до планового срока ухода с мф. А то и позже.
Второе, маленькое, приложение вообще в тумане, нет даже сроков ухода. Там сидит программист. Единственный из оставшихся програмеров этого приложения пытается переписать его с Кобола на ... дотнет. Ему пытаются помогать наши же дотнетчики, но все что они могут сказать это что они ничего понять не могут .
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Как быстро время летит и как много происходит за несколько дней. В четверг я пошел на встречу нытью (от слова ныть) оракловцев и наших манагеров, которым главное чтобы все было хорошо, и прогнал еще один тест, который я и сам прогонял уже сразу же как был первый облом. Но в этот раз условия были немного иными и это привело к падению продакшн базы данных. Так как я и предсказывал в своем письме ко всем. Unpredictable consequences.
Благо что на падение и под"ем ушло всего 50 секунд, ровно. И все что было приконечненно либо переконектилось либо даже не заметило это.
Собрал все протоколы и отправил в Оракл - был открыт их SR. Пока молчат. Хотя нет, нарыли в гугле ссылки ра патчи DB2 с аналогичной диагностикой. Мол у тебя есть эти патчи? Конечно они есть. DB2 у нас настолько старая что уже много лет никаких новых патчей на нее не выдавалось.
Работаю с IDR. Вот это продукт. Есть и теория и средства для ее поддержки. Предсказуемость. Это то что я больше всего ценю в продуктах уже не один десяток лет.
А в эти выходные был годовой тест дизастер рекавери. Как обычно мэйнфрэймовская часть поднялась на DR сайте за час и все остальное время - два дня, была возьня с Ажуром и то что у нас в Ажуре. Меня держало только заключительная часть теста и репликация БД на мф в ms sql servera. Время заполнил продуктивным углублением в IDR. Скоро надо будет перекидывать данные из DB2 в Оракл и синхронизировать их до cutover. Т.е. повторить то что мы уже больше года делали с GoldenGate за считанные недели. Причем не только на стороне мф, но и Линукс , где Оракл сидит.
Конфигурация такая: на стороне DB2 в zOS стоит replication engine DB2. На другом мф, в zLinux стоит replication engine Oracle, который через Oracle client свет данные в Оракл на Linux x86 в Ажуре. Access Server IDR тоже стоит на zLinux. Test cases на отдельных таблицах уже гоняю. Меряю скорости. Получается быстрее чем с GoldenGate. Работает, но надо заскриптовать конфигурацию примерно 800 таблиц.
Вот такие дела. Слухи что сроки перехода с мф сорвутся усиливаются. Но я всячески стараюсь чтобы перенос данных из Дб2 в Оракл не был помехой.
User avatar
SVK
Уже с Приветом
Posts: 8394
Joined: 23 Jul 2003 03:53
Location: SPb - KW - NY - CT - MD

Re: Мы уходим с майнфрайм.

Post by SVK »

Вот, прочитал недавно заметку (пока юмористическую)
Американская ассоциация математиков думает над переименованием оси Z
Кому лень читать: там предлагается в знак протеста отныне именовать оси координат буквами Х, У, и Й. :umnik1: :gen1:

Поскольку буквы Z, V, и даже O уже начали реально запрещать на Украине, в Латвии, и еще в некоторых демократических странах, то у меня возник вопрос: не запретят ли скоро также и систему zOS, чтобы окончательно покончить с IBM под шумок? :pain1:
LG - Life's good.
But good life is much better.
User avatar
apex
Уже с Приветом
Posts: 2453
Joined: 24 May 2008 13:28
Location: Chicago

Re: Мы уходим с майнфрайм.

Post by apex »

SVK wrote: 23 Apr 2022 14:32 отныне именовать оси координат буквами Х, У, и Й. :umnik1: :gen1:
Ну это ж Z на боку.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

SVK wrote: 23 Apr 2022 14:32 Вот, прочитал недавно заметку (пока юмористическую)
Американская ассоциация математиков думает над переименованием оси Z
Кому лень читать: там предлагается в знак протеста отныне именовать оси координат буквами Х, У, и Й. :umnik1: :gen1:

Поскольку буквы Z, V, и даже O уже начали реально запрещать на Украине, в Латвии, и еще в некоторых демократических странах, то у меня возник вопрос: не запретят ли скоро также и систему zOS, чтобы окончательно покончить с IBM под шумок? :pain1:
Странные у Вас ассоциации. У ИБМ не только zOS, а вообще все системы выполняющиеся на zSeries имеют эту букву в названии, например, zLinux, zVM.
Конечно эти все истерики вокруг всего лишь буквы не от большого ума.
".. покончить с IBM под шумок" тоже не от большого ума. Так можно про любую наугад фирму сказать. И что? Сотрясение воздуха не более того. Словесный мусор.
User avatar
SVK
Уже с Приветом
Posts: 8394
Joined: 23 Jul 2003 03:53
Location: SPb - KW - NY - CT - MD

Re: Мы уходим с майнфрайм.

Post by SVK »

zVlad wrote: 24 Apr 2022 02:47 Странные у Вас ассоциации. У ИБМ не только zOS, а вообще все системы выполняющиеся на zSeries имеют эту букву в названии, например, zLinux, zVM.
Конечно эти все истерики вокруг всего лишь буквы не от большого ума.
".. покончить с IBM под шумок" тоже не от большого ума. Так можно про любую наугад фирму сказать. И что? Сотрясение воздуха не более того. Словесный мусор.
Возможно, скоро придется запрещать весь латинский алфавит, и тогда уже вообще все системы и все продукты попадут под раздачу.
Image
LG - Life's good.
But good life is much better.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Ну что ж продолжим.
Переход состоялся. 1 июля. Сказать что триумфальный не могу. Главное что вариант возвращения назад не прорабатывался и задача такая не ставилась.
Были потери данных, перформэнс, краши базы данных. До сих пор проходят сначала ежедневные сейчас дважды в неделю совещания по состоянию и проблемам и эти проблемы появляются снова и снова разные.
Мэйнфрэйм со старой системой не остановлен и в нем кто-то копошится до сих пор.
Что я считаю главным для себя из этой истории это то что один достаточно скромный МФ (напомню 4 CPU с ограниченной относительно максимальной для них производительностью, 32GB RAM) нес на себе все инстансы приложения включая базы данных, сервера бизнес функций, пакетную обработку, печать. Вообщем все. Теперь все это разнесено на десятки серверов самые маленькие из которых имеют 4CPU и 128GB RAM. Каждый инстанс теперь состоит из отдельного сервера БД, серверов бизнес функций, пакетной обработки и печати. Все это постоянно надо патчить, мониторить, восстанавливать если рушится. И оно рушится. Не далее как вчера вечером рухнул сервер репликации основной оракл бд в бд ms sql. Несколько часов ушло на его восстановление.

Я занимаюсь как раз этой репликацией. Софтина для этого ИБМ-ская. IIDR называется. Эту же софтину мы использовали для репликации с ДБ2. Начиналось же эта тема два года назад с оракловского GoldenGate, но по ряду причин, конечно не от хорошей жизни, мы сползли с GG полностью. Я лично дистанцировался от дискуссии где это решение принималось и не произнес ни слова в защиту IDR.

Что еще. Нет доказанного и проверенного сценария DR. Есть компоненты Active Data Guard, но он проверен только в режиме switch over, fail over не проверялся. Не существует и не проверялся DR для репликации.
Вот так примерно обстоят дела с переходом с мэйнфрэйм.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Прошёл почти месяц. Ничего не изменилось. Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт. Я перепробовал несколько альтернативных конфигураций на которые мы переключались "на ходу". Некоторые начинали вроде работать, но не полностью, и в итоге... самое смешное ... все разрешилось элементарной перезагрузкой оракл датабэйз сервера. Предложил это специалист из ИБМ.
null
Уже с Приветом
Posts: 2983
Joined: 09 Jul 2001 09:01

Re: Мы уходим с майнфрайм.

Post by null »

zVlad wrote: 05 Oct 2022 16:36 Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт.
постепенно всё наладится и все забудут про MF
а новонанятые и знать не будут
селяви
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

null wrote: 06 Oct 2022 18:25
zVlad wrote: 05 Oct 2022 16:36 Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт.
постепенно всё наладится и все забудут про MF
а новонанятые и знать не будут
селяви
У них изначально и не было такой опции чтобы помнить о МФ. Они прыгали с самолёта даже без запасного парашюта, не говоря уж о back out.
Налаживается все очень плохо. Но сегодняшнем совещании опять говорили о "перформанс поблем", которое на самом деле было проблемой замков (locks), которых как известно из рекламы Оракл в них быть не может.
Однако в приложении оказались SELECT .. FROM WHERE .... FOR UPDATE... И это привело к цепочкам ожидания, которые были ошибочно названы манагерами пользователя "перформансе проблем".
Никто их переубеждать не стал. Конечно, хрен же редьки не слаще. Согласны?
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

инвалиды, что не смогли собрать реплиацию на оракловом софте нашли самый лучший вариант и воткнули репликатор от ibm но чё то получают все тот же результат. 24 часа пялились на зависшую поделку ibm и девственно пустые логи приблуды, но время кончилось и пришла пора рандомно рестартить источники. и о чудо, репликатор ожил :)
очевидно, что накиданные оракл и мсскл с ibm репликатором не справляются, нужно еще усилить архитектуру рандомными продкутами: например терадата отлично пойдет где-нить между ораклом и мсскл. еще посоветовал б мсскл на линукс мигрировать, а оракл на виндос. неожиданные ходы визитная карточка этого коллектива.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Как я погляжу просмотров этой темы много, но постов мало. То-ли нечего сказать, то-ли вообще не понимают о чем речь.
Это странно. Тема, кмк, довольно злободневная. Куда идёт ИТ? В светлое, счастливое будущее. Или в тупик?
Много-много лет на форуме шли дебаты о тот что лучше. Проводились аргументы за одно,
за другое. Последние же года все свелось к тупому сравнению неких прейскурант цен. Но сравнивалось несравнимое.
Сейчас же, в этой теме, я даю уникальные данные о сравнении сравниваемого. А именно одно и тоже приложение, одни и те-же данные как по структуре, так и по размеру, один и тот же пользователь с одними и теми же привычками и заморочками.
И никаких эмоций со стороны ИТ-шников форума.
Это что вырождение профессии? Или её и не было, а были лишь способы зарабатывания денег, а все остальное это лишь красивая, или не очень (какая есть) обертка/оболочка?
Хотелось бы услышать молодых, а не тех кто всегда здесь.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Удалено. Повторение.
User avatar
katit
Уже с Приветом
Posts: 23960
Joined: 05 Jul 2003 22:34
Location: Брест -> St. Louis, MO

Re: Мы уходим с майнфрайм.

Post by katit »

zVlad wrote: 10 Oct 2022 04:00 Хотелось бы услышать молодых, а не тех кто всегда здесь.
Тогда на Фейсбуке спросите
Лучше водки — хуже нет! ©
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

katit wrote: 10 Oct 2022 21:07
zVlad wrote: 10 Oct 2022 04:00 Хотелось бы услышать молодых, а не тех кто всегда здесь.
Тогда на Фейсбуке спросите
У меня нет Фэйсбука.
Что ж получается что коллектив ИТ-шников на форуме безнадежно постарел?
А как же, например я, сумевший оседлать продукт на Линуксе когда произошел исход с мэйнфрэйма? Мне больше 67 лет. И по мне так все кому нет 50-ти это молодежь. В мои 50 я еще рос на мэйнфрэймах. И я еще далеко, я это знаю, не дорос до возможного предела роста на них. Но это уже потому что наш работодатель не был требователен по использованию МФ. Более того почти все время как я работаю здесь он "уходил" с МФ.
При всем при этом у нас остается приложение на Мф. Маленькое по сравнению с тем которое ушло, но его тоже переводят уже больше 10 лет и пока безуспешно. Таргет дата июнь/июль следущего года. Если уйдут то тогда да, МФ кирдык в отдельно взятой конторе где я остался последним и единственным МФ-щиком в смысле инфраструктуры.
Есть еще один программист (того приложения что еше осталось) и одна дама на storage (dasd's, tape's).
На это последнее приложение брошено порядка пяти не-мэйнфрэйм программистов. С одним из них я в контакте - русскоговорящий - он всячески избегает вовлечения в этот процесс. Что из этого получится? Поживем, увидим.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Вчера начался процесс обновления данных в QA данными из Production. Делается через бэкапс и почему то захотелось чтобы бэкап был по состоянию на 3 рм. Наш канадский Оракл ДВА решил что это значит надо начинать бэкапить в 3рм. Русскоговорящий ДБА убился убеждать что вообще никакого особого бэкапа брать не надо, надо лишь при восстановлении указать RMAN время.
Но разве канадцев можно переубедить? Нет, они бьются головой в то место той стенки которая им нравится. Это проверено многолетним опытом.
Тем не менее, бэкап повлиял на репликацию. Timeout with login. Пришлось несколько раз перезапустить.
Попутно выяснилась новая загогулина Windows. Оказалось что я не могу RDP к серваку где ранится IDR Access Server и где он упал. Выручило что у меня их два иина втором AS работает. RDP на второй сервак тоже также не работает. Сообщение гласит что слишком много попыток прилогиниться иои изменить пароль. При чем это сообшение выдается с первой же попытки. Предлагается подождать и повторить. Час подождать ничего не изменил.
Я не к тому чтобы мне помочь. А к тому что все эти Линуксы, Виндовсы они могу в любой момент взбрыкивать и менять свое поведение. При этом обьяснить эти взбрыкивания как правило не удается.
Я этот вывод делаю не на основе только этого примера с RDP. У меня таких примеров масса. То же падение IDR AS, которые происходят сравнительно регулярно и никто пока не смог обьяснить почему.
Я думаю любой кто имеет дело с этими убогими платформами может привести свои примеры падучей болезни. Просто им кажется что "а как иначе". Меня жто дико раздражает потому что на мэйнфрэйме такой падучей болезни нет.

На следущей неделе будет продолжение обновления QA и я уверен мне будет о чем рассказать в стиле этого моего сообщения. Народ, занимающийся этим в успех не очень то и верит. Поэтому берутся бэкапы QA чтобы хотя бы вернуться к тому что было до рефрэша.
Easbayguy
Уже с Приветом
Posts: 10700
Joined: 17 Jul 2003 22:11

Re: Мы уходим с майнфрайм.

Post by Easbayguy »

zVlad wrote: 07 Oct 2022 01:40
null wrote: 06 Oct 2022 18:25
zVlad wrote: 05 Oct 2022 16:36 Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт.
постепенно всё наладится и все забудут про MF
а новонанятые и знать не будут
селяви
У них изначально и не было такой опции чтобы помнить о МФ. Они прыгали с самолёта даже без запасного парашюта, не говоря уж о back out.
Налаживается все очень плохо. Но сегодняшнем совещании опять говорили о "перформанс поблем", которое на самом деле было проблемой замков (locks), которых как известно из рекламы Оракл в них быть не может.
Однако в приложении оказались SELECT .. FROM WHERE .... FOR UPDATE... И это привело к цепочкам ожидания, которые были ошибочно названы манагерами пользователя "перформансе проблем".
Никто их переубеждать не стал. Конечно, хрен же редьки не слаще. Согласны?
А причем здесь oracle? Она себя ведет как и положено. Это в обшем то фича. Программисты у вас криворукие.
В коде должна использоваться SELECT FOR UPDATE NOWAIT или SELECT FOR UPDATE NOWAIT 3 и обрабатывать ситуацию в коде.
Ну или For Update Skip Locked, если хотите обрабатывать не залоченные записи.
Ситуация когда в системе незакоммиченная транзакция случаются регулярно.
Пх'нглуи мглв'нафх Ктулху Р'лайх угахнагл фхтагн
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Easbayguy wrote: 15 Oct 2022 18:55
zVlad wrote: 07 Oct 2022 01:40
null wrote: 06 Oct 2022 18:25
zVlad wrote: 05 Oct 2022 16:36 Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт.
постепенно всё наладится и все забудут про MF
а новонанятые и знать не будут
селяви
У них изначально и не было такой опции чтобы помнить о МФ. Они прыгали с самолёта даже без запасного парашюта, не говоря уж о back out.
Налаживается все очень плохо. Но сегодняшнем совещании опять говорили о "перформанс поблем", которое на самом деле было проблемой замков (locks), которых как известно из рекламы Оракл в них быть не может.
Однако в приложении оказались SELECT .. FROM WHERE .... FOR UPDATE... И это привело к цепочкам ожидания, которые были ошибочно названы манагерами пользователя "перформансе проблем".
Никто их переубеждать не стал. Конечно, хрен же редьки не слаще. Согласны?
А причем здесь oracle? Она себя ведет как и положено. Это в обшем то фича. Программисты у вас криворукие.
В коде должна использоваться SELECT FOR UPDATE NOWAIT или SELECT FOR UPDATE NOWAIT 3 и обрабатывать ситуацию в коде.
Ну или For Update Skip Locked, если хотите обрабатывать не залоченные записи.
Ситуация когда в системе незакоммиченная транзакция случаются регулярно.
Программисты всегда будут криворукими если иметь дело с Оракл. Вы говорите фича. Ага фича и таких фич в продуктах Оракла несчетное количество. В GoldenGate такая же история наблюдалась. Причем было и так что фича в одном случае помогает а в другом вредит.
Так же и в случае SELECT FOR UPDATE. Как по-Вашему программист должен написать код следущий за SELECT FOR UPDATE с фичами? Как быть с пропущенными залоченными строками? Ведь когда программист пишет SELECT FOR UPDATE то его цель обработать все строки удовлетворяющие WHERE. Не так ли. Или что, обработать часть строк и выдать сообщение типа "сделано, но не все а часть того что запрашивалось?

Что Вы скажите на это?
Easbayguy
Уже с Приветом
Posts: 10700
Joined: 17 Jul 2003 22:11

Re: Мы уходим с майнфрайм.

Post by Easbayguy »

zVlad wrote: 15 Oct 2022 22:38
Easbayguy wrote: 15 Oct 2022 18:55
zVlad wrote: 07 Oct 2022 01:40
null wrote: 06 Oct 2022 18:25
zVlad wrote: 05 Oct 2022 16:36 Продолжаются проблемы с перформанс. Был аутедж на репликации, простояли больше двух суток, бизнес был на ушах, работали 24 часа в сутки, привлекали всех - ИБМ, Микрософт.
постепенно всё наладится и все забудут про MF
а новонанятые и знать не будут
селяви
У них изначально и не было такой опции чтобы помнить о МФ. Они прыгали с самолёта даже без запасного парашюта, не говоря уж о back out.
Налаживается все очень плохо. Но сегодняшнем совещании опять говорили о "перформанс поблем", которое на самом деле было проблемой замков (locks), которых как известно из рекламы Оракл в них быть не может.
Однако в приложении оказались SELECT .. FROM WHERE .... FOR UPDATE... И это привело к цепочкам ожидания, которые были ошибочно названы манагерами пользователя "перформансе проблем".
Никто их переубеждать не стал. Конечно, хрен же редьки не слаще. Согласны?
А причем здесь oracle? Она себя ведет как и положено. Это в обшем то фича. Программисты у вас криворукие.
В коде должна использоваться SELECT FOR UPDATE NOWAIT или SELECT FOR UPDATE NOWAIT 3 и обрабатывать ситуацию в коде.
Ну или For Update Skip Locked, если хотите обрабатывать не залоченные записи.
Ситуация когда в системе незакоммиченная транзакция случаются регулярно.
Программисты всегда будут криворукими если иметь дело с Оракл. Вы говорите фича. Ага фича и таких фич в продуктах Оракла несчетное количество. В GoldenGate такая же история наблюдалась. Причем было и так что фича в одном случае помогает а в другом вредит.
Так же и в случае SELECT FOR UPDATE. Как по-Вашему программист должен написать код следущий за SELECT FOR UPDATE с фичами? Как быть с пропущенными залоченными строками? Ведь когда программист пишет SELECT FOR UPDATE то его цель обработать все строки удовлетворяющие WHERE. Не так ли. Или что, обработать часть строк и выдать сообщение типа "сделано, но не все а часть того что запрашивалось?

Что Вы скажите на это?
И не говорите, сам удивляюсь, как финансовые системы с десятками тысяч транзакций в секунду работают на Оракле.
Пх'нглуи мглв'нафх Ктулху Р'лайх угахнагл фхтагн
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Easbayguy wrote: 15 Oct 2022 22:50 ...
И не говорите, сам удивляюсь, как финансовые системы с десятками тысяч транзакций в секунду работают на Оракле.
Вы не перепутали раздел форума где такая отмазка могла бы пройти.

Я задал Вам конкретные вопросы по Вашим обьяснениям. Вы ушли от ответов. Это что слив?
vladich
Уже с Приветом
Posts: 208
Joined: 15 Jan 2010 15:42

Re: Мы уходим с майнфрайм.

Post by vladich »

Писать код надо так чтобы не происходило ожидание на локах долгое время. Если локи держатся долго и мешают другим запросам, то что-то в консерватории не так.
Ответить на такой вопрос не зная что там конкретно в системе происходит невозможно. У нас есть часть системы где с множества клиентов берутся записи в обработку
и берутся как раз через For Update Skip Locked. Если запись заблокирована одним запросом, то другой ее читать в этот момент не должен, иначе обработка будет сделана дважды. Потом она будет или обработана (и тогда ее больше никто трогать не будет) или не обработана и тогда следующий запрос ее возьмет. Это стандартный алгоритм реализации обработки очереди сообщений на базе БД типа Оракла или Постгресс.
Если там какая-то другая логика то может быть и по-другому.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

vladich wrote: 16 Oct 2022 01:46 Писать код надо так чтобы не происходило ожидание на локах долгое время. Если локи держатся долго и мешают другим запросам, то что-то в консерватории не так.
Ответить на такой вопрос не зная что там конкретно в системе происходит невозможно. У нас есть часть системы где с множества клиентов берутся записи в обработку
и берутся как раз через For Update Skip Locked. Если запись заблокирована одним запросом, то другой ее читать в этот момент не должен, иначе обработка будет сделана дважды. Потом она будет или обработана (и тогда ее больше никто трогать не будет) или не обработана и тогда следующий запрос ее возьмет. Это стандартный алгоритм реализации обработки очереди сообщений на базе БД типа Оракла или Постгресс.
Если там какая-то другая логика то может быть и по-другому.
Другая логика была и есть не только в ДБ2, но и в MS SQL.
Оракл стоял и стоит в особняке. Да, на него клюнуло много пользователей, да он поднялся на фоне всеобщего восстания против IBM в 90-е. Но это уже многим надоело и скоро Оракл будут просто бить, как Шуру Балаганова из Золотого теленка. Да и уже бьют. У нас, без моего участмя выхерили GoldenGate и перешли на IBM InfoSphere Data Replication (IIDR). Я принципиально молчал на митинге где принималось решение. Говорил только наш Оракл ДВА.
Ну и банальное - Оракл это очень дорого.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

vladich wrote: 16 Oct 2022 01:46 Писать код надо так чтобы не происходило ожидание на локах долгое время. Если локи держатся долго и мешают другим запросам, то что-то в консерватории не так.
...
А есть кунштюк которым измеряется это "долгое время"? Долго это сколько?
Что-то не так это что?
И последнее (пока) а как надо писать код чтобы "не происходило ожидание на локах долгое время"?
Можно услышать не шаманские заклинания, а слова специалистов по БД?

Return to “Вопросы и новости IT”