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

[zVlad]

С августа начались работы по уходу с Мф с таргет датой конец 2021. Я естественно вовлечен как ДБ2 ДБА. Настраиваивал Oracle Transparent Gatewaya (OTG), и начал работать с Oracle GoldenGate.
По идее мог бы послать все это далеко и надолго. Мог бы вынудить нанять другого ДБ2 ДБА (мне и кроме ДБ2 есть чем заниматься, да и достаточно дел с ДБ2 без участия в миграции на Оракл). Кроме того ситуация такова что в пиковые, дневные часы зачастую ЦПУ 100% загружен и в связи с тем что этот майнфрайм уже не поддерживается ИБМ повысить его производительность не предтавляется возможным я мог бы настойчив и убедительно предложить не делать миграцию в эти часы пиковой нагрузки, т.е. согнать их дела на ночные часы и в выходные.
Но я решил иначе. Я решил всячески содействовать успешной миграции баз даных с майнфрайм на Оракл, и нахожу для этого возможности. Но пока оказывается что дело вовсе не в возможностях МФ, а в слабости инфраструктуры Оракл. Оракл на который идет миграция в данный момент находится в Azure и представляет собой виртуальный Linux сервер с 8 корами и 32 GB RAM. В августе и сентябре они совершили подвиг и мигрировали одну базу данных размером промерно 500 ГБ за 5 дней (100 часов) с их слов. Было много проблем которые можно было решить, но те кто работает на стороне Оракл никак не могли понять что нужно сделать для этого. Я же был занят имплементацией нового МФ под другое приложение (а также попытакми попасть на шоу Последний Герой на ТВ3, ну и котедж с катером зазимовывал, строил бейсмент).
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

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

[Komissar]

где-то с середины 2021 будешь безработный?

[zVlad]

где-то с середины 2021 будешь безработный?

Нет. Думаю что до семидесяти лет, если захочу, я продержусь без напряжения.

P.S. Вообще то я уже достиг и пенсионный возраст и условие нашего корпоративного пенсионного плана для полной, заработанной пенсии. Так что безработным мне уже не быть. Но я мог бы и другую работу на МФ поискать. Не думаю что есть молодежь способная меня перебить на МФ по спектру моих знаний и опыта.

[iDesperado]

40Gb за 12 часов. DBA, который ждет курсов и эксперта по ораклу в помощь. чувствуется профессионализм команды. что бы получить такие скорости нужно одним потоком читать по одной записи и фигачить инсерт + комит на каждую запись.
azure продает vCpu, т.е. пенсионер так и продолжает путать cores с threads.

зы. в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.

[deev_a_v]

Зато из первых рук узнаем изнанку канадского социализма

[jekasa]

С августа начались работы по уходу с Мф с таргет датой конец 2021. Я естественно вовлечен как ДБ2 ДБА. Настраиваивал Oracle Transparent Gatewaya (OTG), и начал работать с Oracle GoldenGate.
По идее мог бы послать все это далеко и надолго. Мог бы вынудить нанять другого ДБ2 ДБА (мне и кроме ДБ2 есть чем заниматься, да и достаточно дел с ДБ2 без участия в миграции на Оракл). Кроме того ситуация такова что в пиковые, дневные часы зачастую ЦПУ 100% загружен и в связи с тем что этот майнфрайм уже не поддерживается ИБМ повысить его производительность не предтавляется возможным я мог бы настойчив и убедительно предложить не делать миграцию в эти часы пиковой нагрузки, т.е. согнать их дела на ночные часы и в выходные.
Но я решил иначе. Я решил всячески содействовать успешной миграции баз даных с майнфрайм на Оракл, и нахожу для этого возможности. Но пока оказывается что дело вовсе не в возможностях МФ, а в слабости инфраструктуры Оракл. Оракл на который идет миграция в данный момент находится в Azure и представляет собой виртуальный Linux сервер с 8 корами и 32 GB RAM. В августе и сентябре они совершили подвиг и мигрировали одну базу данных размером промерно 500 ГБ за 5 дней (100 часов) с их слов. Было много проблем которые можно было решить, но те кто работает на стороне Оракл никак не могли понять что нужно сделать для этого. Я же был занят имплементацией нового МФ под другое приложение (а также попытакми попасть на шоу Последний Герой на ТВ3, ну и котедж с катером зазимовывал, строил бейсмент).
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

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

вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов, но, процесс как говориться пошел ....
я уже молчку сколько стоит nvme сейчас.... гиганты обманули всех опять....

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

[voyager3]

40Gb за 12 часов. DBA, который ждет курсов и эксперта по ораклу в помощь. чувствуется профессионализм команды. что бы получить такие скорости нужно одним потоком читать по одной записи и фигачить инсерт + комит на каждую запись.
azure продает vCpu, т.е. пенсионер так и продолжает путать cores с threads.

зы. в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.

Аж в Канаду захотелось.

[Komissar]

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

это новое кожно-венерическое заболевание?

[alex_127]

В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре.

вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов,

ну вот как не работает - так амазон хоть он и азур... обидно, дааа?

[jekasa]

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

это новое кожно-венерическое заболевание?

нет, это наследники эпика с 64 ядрами и 128 потоками только подешевле и в серверном шасси с IPMI. Ну а что... дешего и сердито

[jekasa]

В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре.

вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов,

ну вот как не работает - так амазон хоть он и азур... обидно, дааа?

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

[zVlad]

...
В понеделник на прошедшей недели они запустили миграцию одной таблицы из ДБ2 в Оракл в Ажуре. Таблица под 40ГБ. Миграция заняла 12.5 часов, и выполнялась в пиковые часы работы на Продукшн. При этом время в ДБ2 оказалось 9 минут, время CPU 13 минут, включая 8 минут специального CPU - zIIP. Никакого восдействия на Продукш это не оказало - слишком низкий, растянутый во времемни спрос. В тоже врамя Оракл сервер показывал около 100% одного из восьми кор, остальные были на нуле. Память в данном случае никакого значения не имеет, понятно почему.
Я предложил им запускать минимум 4, и более, таблиц в паралель (дело в том что базы данных которые они сейчас мигрируют находятся на том же МФ где и Продукшн. Поэтому воздействие на Продукшн остается возможным. Начнут в середине декабря.

....

вот и верить потом в эти все ваши облака, у меня под руками простые сервера 28 ядер / 56 потоков с 1.5 TB (ОЗУ) памяти на борту. и дешевле ваших амазонов, но, процесс как говориться пошел ....
я уже молчку сколько стоит nvme сейчас.... гиганты обманули всех опять....

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

МФ с которго уходят имеет 4 ядра (с ограниченной производительностью, в 3.5 раза меньше чем неограниченная на 4 ядрах), 32 GB и на нем стоят все инстансы приложения - Production, Dev. QA, Training, Sandbox, etc.. И это не только базы данных, но и аппсервра, batch processing, replication, и другое.

P.S. Недавно я делал рефреш QA и Dev с Production. QA полноразмерная Production и Dev та часть которую мигрировали в Azure 5 дней (100 часов, как они говорят, календарно они бодались месяца два). Делался рефреш по схеме UNLOAD/FTP/LOAD, и заняло это у меня 2 дня - суббота и воскресенье. Та часть что мигрировали в Azure прошла по этой схеме за 4 часа. 44 часа ушло на то что в Azure еще и не пытались мигрировать, начнем в середине декабря. Тогда обещают какие-то другие сервера закупить, "оптимизированные под ДБ", но я как-то слабо верю что это сильно ускорит процесс.
У них проблема еще в том что на Оракл стороне Unicode, и им приходится все транслировать из SBCS. Насколько это трудоемко я не знаю, а все уверения что этого делать не надо, наш клиент не будет использовать иероглифы уперлись в то что это requirement (certification) новой версии приклада. Попахивает непрофессионализмом, причем дремучим..

[Palych]

в свое время я был прав, мейнфреймы Влада запросто заменит ноутбук в 4 ядра 8 потоков.

Думаю именно поэтому миграция займёт лет 10.
И закончится тем, что всё останется как было.
Причина чисто психологическая: грамотные не-МФ спецы за это дело не возьмутся, их и не наймут.
А грамотные мейнфреймщики на каждый сих будут заявлять что эти ваши писюки в принципе не способны решать такие сложные задачи (как перевод символов из одной кодировки в другую).
Год-другой срача - и всё переедет на Z20.

[Oleg Co]

zVlad унд майнкамп.

[zVlad]

.... миграция займёт лет 10.
И закончится тем, что всё останется как было.
Причина чисто психологическая: грамотные не-МФ спецы за это дело не возьмутся, их и не наймут.
А грамотные мейнфреймщики на каждый сих будут заявлять что эти ваши писюки в принципе не способны решать такие сложные задачи (как перевод символов из одной кодировки в другую).
Год-другой срача - и всё переедет на Z20.

Палыч, ты не внимательно читаешь то что написано выше:

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

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

[mskmel]

Не совсем ясно зачем OTG при наличии GG. GG сам по себе умеет делать первоначальное копирование.
GG простой как палка продукт, с весьма архаичным синтаксисом. По начальной загрузке https://docs.oracle.com/en/middleware/g ... -load.html

40ГБ за 12.5 часов больше похоже на конвертацию видео, а не перекладывание данных с места на место. Конвертация в юникод это не задача. Может канал слабый?
С ДБ2 не мигрировал, но с того чего мигрировал слабое место почти всегда канал, редко IO источника.

[zVlad]

Не совсем ясно зачем OTG при наличии GG. GG сам по себе умеет делать первоначальное копирование.
GG простой как палка продукт, с весьма архаичным синтаксисом. По начальной загрузке https://docs.oracle.com/en/middleware/g ... -load.html

40ГБ за 12.5 часов больше похоже на конвертацию видео, а не перекладывание данных с места на место. Конвертация в юникод это не задача. Может канал слабый?
С ДБ2 не мигрировал, но с того чего мигрировал слабое место почти всегда канал, редко IO источника.

Спасибо, добрый человек.

OTG было прописано в инструкции по миграции от вендора. И в принципе я не вижу ничего плохого в OTG за исключением того что с нашим обьемом данных и полученными результатами тестирования варинат OTG не видится приемлемым по времени. Поэтому решили использовать репликацию.
В принципе у нас всегда была и есть репликация из ДБ2 в MS SQL - IBM InfoSphere Data Replication, и этот продукт способен реплицировать в Oracle, но наши манагеры (они очень "умные") решили не ходить протоптаными путями, им подавай что-нибудь неизвестное. Поэтому собственно появился GG на горизонте.

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

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

[Dmitry67]

Неэластичные системы пихать в AWS дорого. Хотя по сравнению с мэйнфреймами может быть и дешевле

[zVlad]

Неэластичные системы пихать в AWS дорого. Хотя по сравнению с мэйнфреймами может быть и дешевле

В мире нет систем эластичнее мэйнфрэймов. Они же самые гибкие, самые масшатбируемые и многое другое "самые-самые" (без кавычек).

Мы уходим с МФ по каким угодно причинам только не цена, при том что я всегда говорил и говорю своим что мы используем наши МФ не более чем наполовину несмотря на то что в пиковые часы бывает 100% CPU busy. Но после нескольких, недавних мер по повышению производительности, а также устранении бага в одном из приложений удаленно достающем ДБ2, и это стало крайне редко.

Причины ухода следущие:

- Желание клиента избавиться он своих Data Centre's. Под эту причину Windows/Linux servers пачками переводятся в Azure. МФ тоже можно было бы перевести в IBM Cloud, или "облоко" тех компаний что продолжают использовать МФ и принимают таких как наш клиент, пожелавших превратиться в бомжей. Это при том что много лет заявлялось о том что атомной энергетике подходят только МФ, и что ИТ для атомной энергетики может быть только private. Все это успешно похерено.

- Вендор приложения выкручивает руки своим клиентам с МФ тем что орешает проблемы только в новых версиях, которые не сертифицирует на МФ. Причем проблемы вовсе не связанные с МФ, проблемы в интерфейсах, удаленных от МФ компанентах приложения, но тем не менее это создает определенные проблемы. А наличия огромного количества "in house customizations" переход на новую версию дополнительно усложняется, удорожается. В остальном другом у уклиента нет никакх причин и желания идти на новую версию.

Уже ясно и очевидно что на платформе Oracle/Linux в Azure нас ждум большие приключения и трудности. В какие деньги это выльется пока тоже не известно. Наши Oracle DBA с ужасом ждут появления моей базы данных на Оракле и они уже зондирует меня на предмет не хочу ли я продолжить быть ДБА для ныне ДБ2-шной базы данных в Оракле. Дело в том что их штат увеличивать не будут, а я уходить тоже пока не собираюсь.

[Dmitry67]

Спасибо.за подробный ответ. Да, любая миграция это боль.

Единственное что, под словом "эластичность" сейчас подразумевается вполне определенная вещь, у одиноких мейнфреймов ее нет.

[zVlad]

Спасибо.за подробный ответ. Да, любая миграция это боль.

Единственное что, под словом "эластичность" сейчас подразумевается вполне определенная вещь, у одиноких мейнфреймов ее нет.

Например?

[Dmitry67]

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

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

[zVlad]

Сейчас был на конфколе по поводу DR exercise проходивший в субботу с приложением на МФ, которое тоже должны уйти в следущем году. Это микроскопическое приложение давно должное быть снесно, но по каким-то причинам до сих пор занимающее целый МФ (благо хоть что это МФ - DR site для большого приложения о котором речь в этой теме идет.
Так вот говорилось о том что видимо это последний раз мы делаем этот DR test, и манагер этого упражния высказался в том роде что по его мнению МФ самый, как оно сказал, manageable компонент наряду с понятными другими. Этот манагер ни бум бум в МФ и других платформах, он просто организует многих людей с разными платформами когда такие упражнения проводятся, но он всегда говорил и вот опять повторяет что с его колокольни МФ самый самый.

[zVlad]

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

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

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

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

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

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

[Flash-04]

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