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

[zVlad]

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

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

[zVlad]

Кстати, об эластичности.

Когда я начал работать в Канаде в апреле 2000 года я был третьим DB2 DBA в инфраструктуре МФ. Был еще IDMS DBA, два-три системщика, японец на CICS-e, дама-китаянка по сетевым делам, китаец на автоматизации, мониторинге и тулзах, тим лид, и пара человек в других тимах фактически работающих с инфраструктурой МФ. Итого больше 10 человек постоянного состава. Контрактиков нанимали когда переходили на новые версии ОС, БД, новые МФ.

В 2006 году прошло крупное сокращение. Ушли системщиков, японца, двух китайцев и тех кто не числился в нашей тиме. Меня перевели с DB2 (к тому времени нас уже было два) на все кроме CICS и сетевые дела. Потом ушла сетевичка ушел IDMS DBA. К 2016 остались два: DB2 DBA, и я, плюс тим лид, занимавшийся по мелочам, почти ничем. С 2006 никаких контрактников не брали, все апгрейды версий и МФ как таковых делал я.

В 2016 ушал на пенсию DB2 DBA. Остались я и тим лид.

В 2020 году, с началом миграций с МФ я запросил помощь потому что уже до неприличного много стали от меня требовать. Обратились к бывшей DB2 DBA, она отказалась, она на них злой уходила, до сих пор видать злится.

И вот на прошлой неделе тим лид объявил об уходе на пенсию с 1 января 2021 года.

Остаюсь я один!!!!!! На все дела двух МФ производителя электроэнергии провинции Онтарио. Причем не в стабилном периоде, а в периоде миграции обоих приложений одновременно, и при том что в обеих миграциях я оказываюсь серьезно задействован. Текущие дела тоже никто не отменяает и никаких разговоров о новых людях не ведется.

[null]

И вот на прошлой неделе тим лид объявил об уходе на пенсию с 1 января 2021 года.

может тоже?
А то отматросят на последок и выпрут
Надо будет - позовут на контракт

[Dmitry67]

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

[Dmitry67]

Где эта Ваша эластичность в вышеприведенном мной примере с 12.5 часами мигрироивания таблицы в 37.5 ГБ? А ведь это Azure.

Ну так если они это в один поток на одном сервере делают по одной записи, то можно и еще медленнее

[zVlad]

И вот на прошлой неделе тим лид объявил об уходе на пенсию с 1 января 2021 года.

может тоже?
А то отматросят на последок и выпрут
Надо будет - позовут на контракт

Ну, во-первых, меня не так то просто выпереть. У нас профсоюз и сеньорити.

Во-вторых, пока я работаю на фултайм растет моя пенсия.

В-третьих, я им нужен без вопросов "если надо".

В-четвертых, работаю с дома и больше не собираюсь посещать офис чтобы там не было с пандемией.

В-пятых, работу я знаю и делаю левой ногой.

В-шестых, мэйнфрэйм настолько удобен для всего что мне приходится делать что я буду скучать об этом. Вот если бы довелось работать с Window, или хуже того Unix/Linux то другое дело.

Достаточно?

[zVlad]

Где эта Ваша эластичность в вышеприведенном мной примере с 12.5 часами мигрироивания таблицы в 37.5 ГБ? А ведь это Azure.

Ну так если они это в один поток на одном сервере делают по одной записи, то можно и еще медленнее

Вот именно. Не все проблемы решаются эластичностью, далеко не все.

У нас в октябре, ноябре было несколько ситуаций когда система реально задыхалась от нехватки ресурса CPU. Помониторили, нашли пару-тройку досадных промохов с конфигурацией некоторых программ, и нашли баг, наиболeе выпиравший когда CPU busy, пофиксали. Вот уже несколько недель все гладко идет при той же нагрузке и том же МФ. А если всерьез заниматься, можно еще дела улучшить, и есть идеи как и есть невнедренное (с индексами). А надо ли в свете ухода с МФ?

[zVlad]

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

Такими способностями реально обладает на сегодня только zOS with WLM, а также IRD (https://en.wikipedia.org/wiki/Intellige ... e_Director). Я об этом многократно здесь упоминал и многократно сам убеждался в этом на практике. Вот и недавмно в очередной раз с помощью WLM решал проблему.

[null]

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

Достаточно?

Вполне,
я просто на ваше "до неприличного много стали от меня требовать" отреагировал

[ARARAT.]

Нашу маленькую компанию купила корпорация два года назад с очень интенсивным использованием последних технологий и очень мощными серверами/data centers по всей US...
Сначало нас Open VMS(не совсем mainframe, но очень близко) хотели "под корень", затем "успокоились", а сейчас !!! сюрприз !!! переводят всю корпорацию(medical billing) нас нашу Open VMS систему(oна давно уже не local у нас, а в одном из data center етой корпорации)...

Почему я предоставлю вам самим понять... Вступать в битву mainframe .vs. else не собираюсь, просто подумайте выше...

[zVlad]

......
я просто на ваше "до неприличного много стали от меня требовать" отреагировал

Это я регулирую через овертайм.

[zVlad]

Нашу маленькую компанию купила корпорация два года назад с очень интенсивным использованием последних технологий и очень мощными серверами/data centers по всей US...
Сначало нас Open VMS(не совсем mainframe, но очень близко) хотели "под корень", затем "успокоились", а сейчас !!! сурприз !!! переводят всю корпорацию(medical billing) нас наш Open VMS систему(oна давно уже не local у нас, а в одном из data center етой корпорации)

Почему я предоставлю вам самим понять...

Сначала я бы поменял Ваше "но очень близко" на "не очень близко". VAX это все таки superminicomputer, a VMS ближе к Unix, лишь часть zOS. Другая часть - MVS, и к ней ничто даже близко не подошло, хотя начало MVS уходит в 70-е.

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

А как бы Вы сам объяснили такую загогулину?

[ARARAT.]

Нашу маленькую компанию купила корпорация два года назад с очень интенсивным использованием последних технологий и очень мощными серверами/data centers по всей US...
Сначало нас Open VMS(не совсем mainframe, но очень близко) хотели "под корень", затем "успокоились", а сейчас !!! сурприз !!! переводят всю корпорацию(medical billing) нас наш Open VMS систему(oна давно уже не local у нас, а в одном из data center етой корпорации)

Почему я предоставлю вам самим понять...

Сначала я бы поменял Ваше "но очень близко" на "не очень близко". VAX это все таки superminicomputer, a VMS ближе к Unix, лишь часть zOS. Другая часть - MVS, и к ней ничто даже близко не подошло, хотя начало MVS уходит в 70-е.

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

А как бы Вы сам объяснили такую загогулину?

Бешенная стабильность работы системы(как аппаратная, ОС, так и приложений), очень маленький "overhead"(КПД гораздо выше на единицу аппаратной производительности), I-O, память и т.д. и т.п.
Там где миллионы accounts и необходимы сотни миллионов вычислений наша система дает фору... Причем она в основном batch processing и еще и на Cobol(тот еще диназавр, и не быстрый ко всему, ограниченный по памяти на "working storage") и DCL.
Причем именно ядро, вся "обвязка" давным давно не Open VMS, т.е. снаруже все "цивильно", web based...

PS Да и еще после переноса в data center она работает под емулятором(не native, ждем 2021 когда появится native) на еще двух слоях поверх hardware и все равное дает фору...

[Palych]

А как в облаках (ажурных и других) борются с задержками (latency)?
Мне кажется это главное что убъет миграцию: наверняка уже нарисована красивая диаграма, с толпой app servers и db servers независимых друг от друга, и неважно что где находится...
Или я отстал от жизни?

[voyager3]

А как в облаках (ажурных и других) борются с задержками (latency)?
Мне кажется это главное что убъет миграцию: наверняка уже нарисована красивая диаграма, с толпой app servers и db servers независимых друг от друга, и неважно что где находится...
Или я отстал от жизни?

У нормальных пацанов задержка от апп сервера до СУБД пренебрежимо мала по сравнению с временем поиска НЖМД. Собственно, у правильных пацанов и диски-то не в серверы СУБД воткнуты.
Но всегда есть герои, у которых приложение в Лондоне, а СУБД в Цюрихе с общением через общественный тырнет.

[zVlad]

А как в облаках (ажурных и других) борются с задержками (latency)?
Мне кажется это главное что убъет миграцию: наверняка уже нарисована красивая диаграма, с толпой app servers и db servers независимых друг от друга, и неважно что где находится...
Или я отстал от жизни?

В случае с нашим клиентом это конечно не так. Известно какие и где сервера находятся. Известно какой сервер это виртуалка и какая, а какой нет.
Собственно облако это на самом деле давно известная модель называвшаяся "Data Centre". Потом этим термином стали называть любую комнату с компьютерами и свитчами. Наконец вернулись к изначальной идее Data Centre и чтобы отличаться от комнат с компами назвали это "Облака". Кинечно написали диаграмы, подвели новую, трескучую теорию, курсы, сертификацию, все дела. И поехали.
Что выграет наш клиент от перехода в облака кроме того что избавится от "комнат с компьютерами" трудно сказать, но проблемы уже обозначаются и с ними уже борятся так или иначе. А ведь это стоит денег, это расходы и их раньше не было.
С переводом МФ в облако проблемы посыпятся как из рога изобилия. Начнется с того что нет никакого инструмента, формулы подав которым на вход параметры МФ на выходе можно получить конфигурацию и параметры набора серверов в облаке которые потянут нагрузку клиента не хуже МФ. У нашего МФ параметры изветсные и мы знаем что от них можно ожидать. Постоянно ведется мониторинг того что важно клиенту и делается поднастройка. Специфическая для ДБ2 поднастройка програм, котой в Оракле просто не существует.
Технические параметры это еще не все. Сейчас приложение на МФ использует такие средста (БД, Апп сервер, язык програмирования), которых не будет в облаке, которых нет в новой версии от вендора приложения. Там будут Оракл под Линукс и Ява. Нет формулы определения параметров железа которое потянет запросы клиента не хуже чем МФ.

Следовательно это будет поиск методом проб и ошибок. Причем что особо важно будет очень не просто понять или надо дровишек подбросить, или что-то сделать с БД, или с прогами. Самое простое, но не самое эффективное будет подбрасывание дровишек, кластеризация. Последнее - кластеризация в Оракл это известный, пресловутый RAC с нелинейной характеристикой зависимости производительности от количества узлов. А узлы в облаке это не те сервера на которых Оракл "бьет всех", это дешевые комодити серверочки с одним лишь параметром который можно бампать - количество ядер. А тут нас поджидает ловушка в виде алгоритма определения за Оракл - от количества ядер. И все поплывет, потекут денюшки.

Конечно наш клиент работает с вендором и вендор бьет себя в грудь копытом рассказывая как много их кастомеров и как успешно ушли с МФ. Только вот уже на миграции еше только малой части БД они показали печальную статистику. А что будет когда возьмемся за всю БД?
БД нашего клиент очень отличается от БД других кто использует это приложение. Это известно давно. Но это никак не учитывается помошниками от вендора кроме как ворчанием мол что ж вы раньше не думали и довели себя до такого. Думали конечно, но МФ тынул и клиенту казалось "а зачем еще что-то делать". Теперь приближается час истины и все станет на свои места, но времени для того чем нужно было заниматься еше в начле 2000 и о чем тогда же клиенту говорилось уже нет. Вот он 2021 стучится в дверь и он пролетит также быстро как и все 20 лет пролетали до него. Как говорится пить баржоми поздно.
Проект уповает на репликацию, на Oracle GoldenGate. А репликация это тоже не волшебная палочка, ей тоже нужны ресурсы и она на том же МФ должна что-то да делать. А МФ тот один и на нем все, и Продакшн и все остальное.
Я конечно сдеалаю все чтобы они успешно свалили с МФ и я знаю как это будет. Но что будет после cat-over ни я ни кто другой сказать не может. Это будет однозначно сюрприз. Причем сюрприз растянутый во времени. Это будет агония с неизвестным исходом и непредсказуемыми затратами. Я жду этого с нетерпением. Но конкретно сейчас мой партнер по репликации учится на курсах в Оракл, я лишь почитал книжки по GG и сконфигурировал EXTRACT для одной таблицы чтобы увидеть как это работает на самом деле. А сервера куда реплицировать обещали к середине декабря.

[iDesperado]

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

мне вот интересно на кой им GG ? что бы в момент миграции иметь синхронизированную с db2 бд и мигрировать без даунтайма ? это реально нужно, учитывая что у Влада какая-то бухгалтерская задача практически без ио нагрузки ?
держать после миграции GG нет смысла, если нужен DR то это делается обычным data guard, который на порядок дешевле и спецов много больше.

дальше, весь тот инструментарий в МФ мы уже видели, что фуфло не работающее. вот тут шикарное повествование от Влада как он мужественно боролся с нагрузкой 100%. много месяцев боролся, но в результате кровпролитных боев "создали индекс, из четырех колонок, только две из которых используются в планах доступа к восьми SQL statements " и вааах "загрузка CPU в пиковые часы упала со стабильных 100% до смешных для МФ 40-50%"
т.е. инструментарий на столько устрел, что DBA не видит дже базовых вещей по субд.
вобщем понятно, что если у команды и на знакомой платформе "индекс, из четырех колонок" случается, то в оракле и подавно ничего не заведется.
но когда-нибудь придет вменяемый консультат и засунет всю ту крошечную бд с МФ в оракловый кеш, перечеркнув все те оптимизации МФ, что стоят миллионы и позволяют крутить db2 на неадекватных эпохе ресурсах.

[mskmel]

Я использую pdf версию Administrator's Guide version 11. Это пробная, бесплатная версия, но идут переговоры и закупка у Оракла официальной версии, может это будет версия 19, может нет, зависит от версии нашего ДБ2, которая очень старая на сегодня.
У GG есть разные варианты начальной загрузки, в том числе внешняя, т.е. с тем же OTG, если нам удастся его ускорить.

Вы аккуратнее. У Оракла нет бесплатного старого ГГ. Есть лицензия на продукт ГГ, а какую версию использовать это Клиенту выбирать, в зависимости от нужного уровня поддержки и глючности. GG11 достаточно пожилой продукт.

Oracle Transparent Gateway для первоначальной миграции это как Ваш МФ в пасьянс косынку играть. Сложный и дорогой продукт, тем более за ГГ всё равно платить.

Если бы дело было в канале то я думаю Оракл сервер не упирался бы в ЦПУ. Юникод, конечно, не проблема. Скорее всего у них там каждая запись коммитится, и возможно это можно поправить. Я подкину им эту идейку на неделе.

Увы, было сказано что одно ядро 100%, чем именно оно было занято неизвестно.
Каким способом данные переливались - тоже не сказано.

[zVlad]

Я использую pdf версию Administrator's Guide version 11. Это пробная, бесплатная версия, но идут переговоры и закупка у Оракла официальной версии, может это будет версия 19, может нет, зависит от версии нашего ДБ2, которая очень старая на сегодня.
У GG есть разные варианты начальной загрузки, в том числе внешняя, т.е. с тем же OTG, если нам удастся его ускорить.

Вы аккуратнее. У Оракла нет бесплатного старого ГГ. Есть лицензия на продукт ГГ, а какую версию использовать это Клиенту выбирать, в зависимости от нужного уровня поддержки и глючности. GG11 достаточно пожилой продукт.

Oracle Transparent Gateway для первоначальной миграции это как Ваш МФ в пасьянс косынку играть. Сложный и дорогой продукт, тем более за ГГ всё равно платить.

Если бы дело было в канале то я думаю Оракл сервер не упирался бы в ЦПУ. Юникод, конечно, не проблема. Скорее всего у них там каждая запись коммитится, и возможно это можно поправить. Я подкину им эту идейку на неделе.

Увы, было сказано что одно ядро 100%, чем именно оно было занято неизвестно.
Каким способом данные переливались - тоже не сказано.

Начну с конца. Данные переливались через 1Gb канал. Так было сказано.
Ни GG ни OTG не были мной предложены. Я предлага IBM IDR, and DB2 Connect соответственно. И тот и другой у нас есть и мы знаем как они работают.
OTG был прописан в миграционном мануале вендора. В чем сложность OTG мне не ясно, на мой взгляд OTG прост как ведро, как впрочем и DB2 Connect не болле чем средства удаленного доступа к DB2.
Кто и как навязал нам ГГ я не знаю и знать не хочу если честно. Я сказал, меня не услышали. Мне дали то что хотят чтобы я установил и сконфигуруровал на МФ - я беру устанавливаю и конфигурирую. Что получится то они и получат.

Я последний кто хочет чтобы МФ был выброшен в организации где я проработал 20 лет мэйнфрэймщиком, и никто бы меня не осудил если бы я вообще отказался участвовать как в OTG, так и в GG..

[mskmel]

Данные переливались через 1Gb канал.

За условные 12 часов переливаются все 4ТБ в 4 ядра в виртуалке. Вопрос "как переливали" - остаётся открытым.
Это напоминает упражнения племянника с паянием усилителя. Припаяв не всегда попадая в правильные отверстия на плате, и включив - не заработало. Отбросил со словами: "Китайская херня!".
Не стоит полностью зависить от своих требующих дообучения специалистов, Оракловый суппорт работает над почти любимыми вопросами.

[mskmel]

дубль

[liamkin]

Оракла пока конь не валялся. У Оракл ДБА (а их два на миграции задействовано, один на OTG, второй на GoldenGate) нет времени и он ждет курсов по GoldenGate и эксперта из Оракл в помощь. Реально будем начинать в середине декабря.

Давайте по теме скажу. ГолденГейт очень дорогой - Голден не зря в названии. Менеджера похоже получили откат от Оракла. Требуйте свою долю!
Для передачи данных массово люди пользуют sqlloader - он бесплатно идет в составе Оракл РДБМС. И работает он очень быстро.
Если есть деньги, то нужно/правильно использовать ETL - DataStage или Informatica.
Оптимизация Оракла - отдельная задача, но решаемая, там есть встроенный генератор отчетов AWR, где говорится какие запросы жрут диск или ЦПУ.
8ядер и 32гб - ни о чем. У меня в домашнем компе 12 ядер-24 потока и 32 гб памяти. AMD 3900x -$400, RAM- $110.
Хотите нормальной Оракловой производительности - не жалейте памяти и ЦПУ. И смотрите отчеты AWR.

[DropAndDrag]

Я последний кто хочет чтобы МФ был выброшен в организации где я проработал 20 лет мэйнфрэймщиком, и никто бы меня не осудил если бы я вообще отказался участвовать как в OTG, так и в GG..

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

[valchkou]

как то мигрировали оракл из приват ДС в амазон. Оказалось что не такое тривиальное дело и лицензия к тому же дороже.
Короче мы переписали все на кассандру с микро сервисами за 4 мес. Только на лицензии сэкономили 120к в год.
Сторед процедуры и скл ушли на яву.
Железо обошлось почти так же, с одним отличием - у кассандры 6 нод и high availability, а у оракла за те же бабки только одна гигантская VM.
Мигрировать с DB2 на Оракл считаю изначально было ошибкой. Но видимо бабло уже попилено. Жаль что меня к столу не пригласили

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

[Flash-04]

Плохо попилили. Могли бы и Oracle ZFS купить на ваших задачах, Влад, он бы 90% времени простаивал бы