zNext = z13

[Мальчик-Одуванчик]

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

[zVlad]

P.S. Мне не людей приводить надо, а факты, технические факты почему миграция сорвалась, из-за каких недостатков DB2 или zOS или МФ в целом.

А технические факты надо не у меня спрашивать, а у вас, почитателя DB2

....

Я не "почитатель DB2", а 7 лет проработавший DB2 DBA, и сейчас время от времени помогаю нашему DBA когда ей что-то не удается сделать. Поэтому можете спрашивать меня о DB2 что угодно - я Вам отвечу обязательно.
Что касаемо очередной порции сплетен по поводу неудачной миграции с Оракл на МФ на DB2 тоже на МФ то мне так и нечего сказать поскольку информации как не было от Вас так и нет. Я уж подумывал не запросить знакомых в московском представительстве ИБМ, может что знают. Но решил что Вам было бы легче добыть технические детали, да и Вам это нужнее, ибо любому со стороны специалисту, каким бы он ни был, то, что Вы заявляете будет видеться как в лучшем случае сплетня. Чтобы понять представьте что это не Вы а я рассказал и в моем рассказе все наоборот и тоже нет фактов. Как Вы к такому бы отнеслись?

[mynameiszb]

Как Вы к такому бы отнеслись?

Спросите. Я историю знаю от тех, кто помогал выполнить данный проект. К сожалению, в Питере по работе не был, работал только по Москве.

[zVlad]

Как Вы к такому бы отнеслись?

Спросите. Я историю знаю от тех, кто помогал выполнить данный проект. К сожалению, в Питере по работе не был, работал только по Москве.

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

Вы по Москве были не в Оракл представительстве часом?

[mynameiszb]

Вы хотели сказать помогали завалить проект.

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

Только не говорите мне, что вы не в одном проекте по миграции не участвовали. Потому как это - азы. И то, как делается. И то, как люди там вкалывают. И то, что при всем желании подкузьмить соседям не получится. Если только сами соседи не навернутся.

Знаете, Влад, я несколько устал от столь "продуктивного" общения. Возможно, это ваш стиль. Но я утомился. Что-то объяснять, доказывать, какие-то примеры приводить.

Знаете, я с интересом смотрел соседние ветки, поднятые вами. Я еще могу поверить, что человек с семилетним опытом администрирования DB2 не имеет представление, что такое EXPLAIN PLAN для базы. Возможно, вы прошли мимо этого. Может, это специфика именно DB2. В Оракле и MS SQL именно explain plan позволяет оценить статистику по запросам в наиболее удобоваримой форме. Хотя те же самые "сырые" трейсы для Оракла я использовал в том числе. Но черт с ним, вам виднее.

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

Поэтому - я для себя составил личное впечатление. Мое личное впечатление я оставлю для себя, а сам в дальнейшем воздержусь от продолжения беседы. На мой (личный, я повторюсь) взгляд вы себя как специалист раскрыли. За жизнь поговорить было бы интересно, а в остальном - пусть Десперадо про планы запросов разговаривает. У него терпения куда как больше.

С уважением,
...

[zVlad]

Вы хотели сказать помогали завалить проект.

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

Только не говорите мне, что вы не в одном проекте по миграции не участвовали. Потому как это - азы. И то, как делается. И то, как люди там вкалывают. И то, что при всем желании подкузьмить соседям не получится. Если только сами соседи не навернутся.

Да я участвовал. В тех миграциях. Одной с MФ на Оракле, и двух с Оракле на МФ. В первой я скорее был наблюдателем правда, было это давно, но хорошо помню как ехал с озера и мне позвонил мой нынешний босс о том что этой миграции нужно помочь. Ну я и помог чем мог. А вообще эта первая миграция проходила с минимумом освещения что и как там происходит. Ползователь после этой миграции стоял на ушах несколько лет, начиная от неадекватного переноса данных (данные доводили вручную после миграции) и заканчивая надежностью (было много оутагес, которые для атомной станции очень не желательны) и отсутствием DR solution (сейчас это наконец решено, после нескольких лет отсутствия). Обратите внимание я дал краткое описание миграции и уже в нем есть три технические позиции о проблемах: данныe, надежность и DR strategy. Причем ни одна из проблем, какими бы они ни было важными и болезненными не вынудили пользователя вернуться назад. Потому что такое было принято человеческое решение - уходить не считаясь с потерями. Производительноеть там была тоже ужастной по началу, параметры серверов были определены не верно. Вскоре пришлось закупать более мощное (и следовательно более дорогое) железо.

Вторая миграция. Проиводительность была ужасной. Нанятые писатели увлеклись nested views и stored procedures до такой степени что DB2 только и строил прoмежуточные данныe. После анализа их творчества (моего анализа) я указал им где и как надо сделать материализацию промежуточных view (таких было немного) и поддержать ее тригерами. К их чести они не упирались и после имплементации моих рекомендаций проблема с производительностью была снята. Вы говорите в том случае в Питере причина отката была в производительности. Я не стану утверждать что ее не могло быть. Но нормальный и реальный путь решения любой проблемы производительности существует. Даже теоритически существует - почитайте (или перечитайте) Дэйт, одного из создателей RDBMS.
У нас был upgrade нашего ERP softa лет десять назад. Было принято решение имплементировать baseline, т.е. то что vendor дал, т.е. наши примочки отбрасывались. Началась эксплуатация и сразу понеслись нарекания на производительность. Сидели целыми днями в мониторах, вытягивали проблеммные запросы, находили решения (в основном это были индексы) и довели систему до приемлемого состояния. В следущий upgrade уже действовало правило все наши примочки обязательно переносить в новую версия vendora.

Вот так это на самом деле происходит и вот это можно не разглашая секретов рассказывать

Знаете, Влад, я несколько устал от столь "продуктивного" общения. Возможно, это ваш стиль. Но я утомился. Что-то объяснять, доказывать, какие-то примеры приводить.

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

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

Знаете, я с интересом смотрел соседние ветки, поднятые вами. Я еще могу поверить, что человек с семилетним опытом администрирования DB2 не имеет представление, что такое EXPLAIN PLAN для базы. Возможно, вы прошли мимо этого. Может, это специфика именно DB2. В Оракле и MS SQL именно explain plan позволяет оценить статистику по запросам в наиболее удобоваримой форме. Хотя те же самые "сырые" трейсы для Оракла я использовал в том числе. Но черт с ним, вам виднее.

И Вы туда же (уж не один ли Вы с iDesperado человек?). Нет такого термина "EXPLAIN PLAN для базы". Есть термин "ACCESS PLAN" или по русски "план доступа" Читайте основателей RDMBS - Дэйта читайте.
Если опуститься с небес теории в реальный DB2 for zOS, то eсть SQL statement EXPLAIN и есть PLAN_TABLE куда EXPLAIN записывает свои обяснения в виде чисел, имен и текста. Есть графические тулзы которые данные в PLAN_TABLE представляют в виде прямоугольничков, многоугольничков и стрелок сопровождаемых числа (из PLAN_TABLE и DSN_STATMNT table, есть еще таблицы на самом деле). Для целей нахождения проблемы производительности графы мало интересны, по сравнения с данными в PLAN_TABLE. Что дает граф так это общее представление о том как запрос выполняется, последовательность и характер действий. Но рассматривать граф каждого запроса это контрпродуктивно если вы имеете дело с сотнями тысяч запросов и ваша задача улучшать перформанc не портя ничего в БД.

И еще, там у меня не было никаких "сырых" трейсов, там у меня трейсов не было вообще, oni ne umestny v tom kontekste. Трайсы это совсем другая тема. И я не догоняю почему Вы вообще об этом решили упоминуть.

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

Поэтому - я для себя составил личное впечатление. Мое личное впечатление я оставлю для себя, а сам в дальнейшем воздержусь от продолжения беседы. На мой (личный, я повторюсь) взгляд вы себя как специалист раскрыли. За жизнь поговорить было бы интересно, а в остальном - пусть Десперадо про планы запросов разговаривает. У него терпения куда как больше.

С уважением,
...

Нет я так не писал. Был сигнал, не сигнал даже а вопль - e-mail с subject следущего содержания: "Performance is SUPER BAD right now" от пользователя и этот e-mail был форварднут мне менедженор проекта миграции (пистон мне вставлял уже после мой линейный манагер). Я в это время сидел дома и смотрел live webcast о новом IBM z13. И я об этом говорил с самого начала.

Я до сих пор не могу понять почему то что я в итоге сделал не было включено в план миграции с самого начала. По крайней мере нам, мне, это было известно загодя, я уже над аналогичной проблемой работал в связи с другим удаленным приложением, которое как раз было мигрированно полностью на МФ и та проблема сама собой исчезла. Мне даже смутно вспоминается что нами (мною) было подано в списке наших действий что мы должны будет сделать во время миграции. Я все собираюсь найте тот e-mail.

Тем не менее, в общем и целом я с Вами согласен. Не след делать резкие движения в Production. Но, здесь еще одна особенность zOS и продуктов в нем сказывается. В отличии от других систем и продуктов последствия изменений как правило очень хорошо предсказуются, данные для принятия решений как правило полны и очевидны - из-за развитой системы мониторинга. Поэтому разница в том случае была только в том что если я начал процедуру, то еще один день пользователи бы слали письма с subject "Performance is SUPER BAD right now".

Пожалуй хватит, хотя можно и больше сказать

[mynameiszb]

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

Ой, это не миграция. Это - самодеятельность (если я правильно вас понял).

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

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

И все равно, не смотря на столь многократное резервирование по безопасности, случаются проблемы (что Чернобыль, что Фукусима, на последней вообще был дикий провал в проектировании).

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

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

Вторая миграция. Проиводительность была ужасной. Нанятые писатели увлеклись nested views и stored procedures до такой степени что DB2 только и строил прoмежуточные данныe.

Кстати, а разве DB2 плохо уживается со сложными view? Вроде не должно такого быть. Я знаю, что Оракл ведет себя паршиво при ручной имплементации Streams между разнесенными узлами. Т.е. когда у вас MatView, они ходят за обновлениями на другие машины по линкам. Так вот при передачи рефрешей в этом случае Оракл без оптимизации зачастую посылает реальный recordset, не обращая внимание на конкретные колонки, указанные в запросе. При больших таблицах и больших объемах это сказывается. Поэтому можно сначала формировать промежуточный обновляемый view на поставщике данных, а уже с него забирать выборку. По-крайней мере, десятая версия этим грешила.

Я тоже устал добиваться от Вас конкретики, и крайне удивлен что Вы сами не видите насколько Вы неубедительны.

Влад, какая может быть конкретика для DB2, если это закрытая для меня информация? Меня удивил сам факт, что производитель на своей же операционке не смог перетащить клиента под DB2. На стороне Ораклоидной базы не было ничего экстра-ординарного. Один instance, тысячи однородных схем, тысячи таблиц в каждой. OLTP-запросы в основном. Нагрузка достаточно ровная, но большая. Ну и некоторый слой аналитики поверх этих транзакций. Все. Ничего "экстра".

Ключевой вопрос - записи должны укладываться во временные рамки, аналитика должна выдавать отчеты в указанный промежуток времени. Все.
Сухое итого, которое запомнил из рассказа коллег - базу перетащили, по производительности система не взлетела, как должно. Т.е. - Оракл не затыкался, DB2 вставал колом: либо на аналитике по срокам не укладывался, либо при подкрутке - начинали затыкаться транзакции.

Почему - а вот это мне и самому интересно. К сожалению, у меня только сухой остаток: "не шмогла".

Нет такого термина "EXPLAIN PLAN для базы". Есть термин "ACCESS PLAN" или по русски "план доступа" Читайте основателей RDMBS - Дэйта читайте.

Да что вы говорите

На вскидку: Using EXPLAIN PLAN, из раздела "Oracle Database Performance Tuning Guide and Reference"

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

Кстати, я не знаю, откуда Десперадо стрелочки и пр. нашел, для Ораклоидного explain plan вполне достаточно даже sqlplus и терминального соединения.

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

Тем не менее, в общем и целом я с Вами согласен. Не след делать резкие движения в Production. Но, здесь еще одна особенность zOS и продуктов в нем сказывается. В отличии от других систем и продуктов последствия изменений как правило очень хорошо предсказуются, данные для принятия решений как правило полны и очевидны - из-за развитой системы мониторинга. Поэтому разница в том случае была только в том что если я начал процедуру, то еще один день пользователи бы слали письма с subject "Performance is SUPER BAD right now".

Э, нет, тут я с вами не согласен. Нет никакой особенности на zOS или разных Unix/Windows серверах. Есть его величество Процедура. Которая говорит: никогда, ни при каких обстоятельствах нельзя что-либо трогать на боевой машине без а) официального запроса, б) все действия должны быть предварительно проверены на тестовом клоне в) все должно быть логгировано для последующего анализа.

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

Надо различать Critical Issue и тюнинг. При первом случае у вас нештатная ситуация, когда бизнес уже несет потери. И когда он готов на любые разумные действия технического персонала, чтобы уменьшить убытки. Но(!), даже в этом случае есть официальный запрос + существует процедура на решение возникшей проблемы. Для базы данных даже описывают и обкатывают "аварийные планы", где разобраны основные issues, а так же поэтапные шаги по их решению. Т.е. даже при падении вашего сервера вы работаете по формализованным правилам. Да, триггер на начало работы другой (критическая проблема), но - все равно, никакой самодеятельности. Кстати, зачастую в случае таких проблем автоматом врубают запись происходящего в зале для последующего разбора полетов.

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

Вы не видели, как это заканчивается? Я видел. Приходит менеджер и говорит:

- Руки с клавиатуры убрать. Коробку с личными вещами - к досмотру. Сдать пропуска, брелки с кодами удаленного доступа. Эти господа в галстуках вас проводят до проходной. Письмо с официальным расчетом получите по почте. Вы здесь больше не работаете...

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


PS. Пойду я дальше над кодом медитировать. С кодом намного проще. Если он не работает - значит сам дурак. И объяснять ему очевидные вещи не надо Никакого несовпадения форматов, однако...

[zVlad]

Нужно пояснить что наше ЕРП приложение не управляет непосредственно реакторами. Оно управляет людьми, или помогает им управлять самими собой.

....

Вторая миграция. Проиводительность была ужасной. Нанятые писатели увлеклись nested views и stored procedures до такой степени что DB2 только и строил прoмежуточные данныe.

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

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

[sp123]

Т.е. - Оракл не затыкался, DB2 вставал колом: либо на аналитике по срокам не укладывался, либо при подкрутке - начинали затыкаться транзакции.

Это классика, обсуждали давно и многостранично. Разный подход к блокировкам и разруливанию read/write. Миграция предполагает полный ре-дизайн и большие трудозатраты, в общем случае простое переливание схемы и данных не работает. Что, скорее всего, и произошло в том банке.

Я сейчас волею судьбы сижу на Hadoop посередине между Oracle и DB2. Во втором случае, если мне надо глянуть что-то на Prod, приходится быть аккуратным и работать в read uncommitted ('dirty read') режиме. Но мне проще, так как я лезу в Reporting, а там все статично в течение дня.

Кстати, основную часть OLTP у нас ребята в прошлом году перетащили с DB2 на Cassandra, очень довольны. То же самое ожидает кое-какие приложения в Oracle, но там чисто из-за денег.

[zVlad]

Т.е. - Оракл не затыкался, DB2 вставал колом: либо на аналитике по срокам не укладывался, либо при подкрутке - начинали затыкаться транзакции.

Это классика, обсуждали давно и многостранично. Разный подход к блокировкам и разруливанию read/write. Миграция предполагает полный ре-дизайн и большие трудозатраты, в общем случае простое переливание схемы и данных не работает. Что, скорее всего, и произошло в том банке.

...

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

Основные, кстати, разработчики ПО такие как SAP, PeopleSoft наверняка учитывают эту особенность и сразу делают правильные вещи.
Наше, опять же кстати, ERP приложение разрабатывается в Оракле и лишь потом делается версия для DB2.

[Kolbasoff]

Послужной список у автора прост - 33+лет зарабатываю на жизнь работая в область ПО на компьютерах.

А может это - на пасеку, а?

[zVlad]

Послужной список у автора прост - 33+лет зарабатываю на жизнь работая в область ПО на компьютерах.

А может это - на пасеку, а?

Я бы с радостью, но моргедж еще не выплочен, да и работа не пыльная - че не работать то?

А Вы уже на пасеке?

[mynameiszb]

Наше, опять же кстати, ERP приложение разрабатывается в Оракле и лишь потом делается версия для DB2.

Мудрые люди. DB2 еще исключить - и будет вообще хорошо

PS. Ушел, ушел...

[zVlad]

Наше, опять же кстати, ERP приложение разрабатывается в Оракле и лишь потом делается версия для DB2.

Мудрые люди. DB2 еще исключить - и будет вообще хорошо

PS. Ушел, ушел...

С этим нашим ERP приложением на МФ интересная фигня происходит. Вот для начала из форума по этому приложению:
http://passportgeek.com/forum

Asset Suite / PassPort originated on IBM MVS mainframes with the online environment running under CICS, a high volumn transaction processing environment, and the database being DB2. At some point a decision was made to go multi-operating system and multi-database and PassPort was ported to work on various flavors of Unix and the Oracle database. Maintaining the business logic in one place was paramount and to accomplish this Indus (now Ventyx) created psuedo-CICS environments for Unix. It allows the same .ccp and .csm programs, containing most of the business logic, to execute on HP-Unix and on MVS. This is what makes Asset Suite / PassPort so warm and fuzzy.

Knock on effects of this include an Indus custom CICS precompiler when compiling for Unix and an Indus custom SQL precompiler when compiling for Oracle. (See why you want those compiler listings!) Indus developers must restrict themselves to CICS commands supported by the psuedo-CICS environment and to using SQL common to both DB2 and Oracle, I believe it's a POSIX standard. Developers customizing Asset Suite / PassPort can use Oracle or DB2 specific SQL.

У этого приложения много мелких пользователей и немного крупных. Крупные сидят на МФ и уходить с МФ не хотят. Вендор однако постоянно давит их чтобы они уходили на Юникс/Оракл, видимо потому что поддерживать две платформы им просто не хочется - больше затрат. Наша контора относится к крупным, но так сложилось что во-первых, наш клиент слушает нас в последнюю очередь, а наш новый (с 2001 года) хозяин сам бежит от МФ постоянно. Вот так мы и живем - нас постоянно хоронят, но мы почему то живы. У клиента, кстати, два лагеря - один за, и второй против МФ. Как они решают эту дилему нам не ведомо, лично я за 15 лет работы ни раз с живым клиентом сколько-нибудь высокого ранга не имел возможности говорить об этом. А разговоры с нашими менеджерами были всегда скучными - они соглашались, но потом завершали утверждением что "клиент выбрaл вот это" и все. Никто, как я понял, не интересуется лучшими решениями для клиента. Лучшие это те что выбрал клиент и те что приносят нам больше денег. Технический аспект всегда стоит номером шесть в процессах принятия решения. В итоге все тратят больше денег чем могло бы быть и все рады этому. Поэтому кстати все наши споры о более дешевых решениях (как правило по приобретению железок) это такой детский лепет, что просто стыдно порой бывает за наш уровень понимания экономики IT.

[zVlad]

....
Я знаю, что в Питере пытались провести миграцию высоконагруженной системы с Оракла под zOS под DB2. ...
а так же знаю, что под Ораклом система как жила, так и живет по сей день.

....

Неужели правда система та до сих пор выполняется в Oracle for zOS? Ведь Oracle прекратил развитие их версии for zOS много-много лет назад. Да и имплементация Oracle в MVS (на самом деле речь следует вести об MVS конечно) была весьма поверхностной, не использующей всех возможностей MVS. Об этом был спор здесь и меня кто-то (не Вы ли) убеждал что имплентация Oracle в MVS была едва ли не полноценней чем DB2.

[mynameiszb]

Неужели правда система та до сих пор выполняется в Oracle for zOS?

Влад, вы как маленький капризный ребенок с любимой игрушкой. Но мы же взрослые люди и прекрасно понимаем, что бизнесу не нужен DB2. Бизнесу не нужен Oracle. Бизнесу нужна большая железная коробка, которая будет приносить деньги. Долго, без проблем. И если что-то выбрали, это что-то работает и приносит доход, то причины для перехода на другое решение должны быть очень серьезными. Например - пообещали "все будет так же хорошо", плюс откат нарисовали с кучей нолей. Либо ваша система стала сбоить и падать через раз.

У Оракла в Premium Support есть шикарная команда поддержки zOS. Банк платит - его проблемы решают. Поэтому второй случай, когда вы не можете существовать на старом ящике - не подходит. А объем головной боли с миграцией и технические проблемы превысили некое пороговое значение, вот и не пошел заказчик на тотальное изменение системы.

Поэтому - да, до сих пор выполняется. По-крайней мере, я не слышал, чтобы их куда-то перетаскивали.

[krids]

Неужели правда система та до сих пор выполняется в Oracle for zOS? Ведь Oracle прекратил развитие их версии for zOS много-много лет назад.

К примеру, ЦБ РФ как сконсолидировал ораклы из 70+ расчетных центров на z/OS лет 7-8 назад так и сидит до сих пор на последней 10-ке. Там по слухам оракл божится, что будет в индивидуальном порядке делать патчи пока "ишак не сдохнет или падишах". Опять же по слухам нешатко-невалко пытаются смигрировать/переписать на db2/zOS, но пока "воз и ныне там".

[mynameiszb]

Там по слухам оракл божится, что будет в индивидуальном порядке делать патчи пока "ишак не сдохнет или падишах".

Когда у вас такой заказчик, который платит ОЧЕНЬ большие деньги, вы наступите на горло любой маркетологической песне и будете облизывать хоть падишаха, хоть его осла до посинения

[krids]

Когда у вас такой заказчик, который платит ОЧЕНЬ большие деньги, вы наступите на горло любой маркетологической песне и будете облизывать хоть падишаха, хоть его осла до посинения

Угу, "любой каприз за ваши деньги - вы платите, мы капризничаем"

А что за питерский банк такой ? (если не NDA конечно). Насколько знаю даже в Москве ни у кого из банков кроме ЦБ нету System z.

[zVlad]

Неужели правда система та до сих пор выполняется в Oracle for zOS?

Влад, вы как маленький капризный ребенок с любимой игрушкой. Но мы же взрослые люди и прекрасно понимаем, что бизнесу не нужен DB2. Бизнесу не нужен Oracle. Бизнесу нужна большая железная коробка, которая будет приносить деньги. Долго, без проблем. И если что-то выбрали, это что-то работает и приносит доход, то причины для перехода на другое решение должны быть очень серьезными. Например - пообещали "все будет так же хорошо", плюс откат нарисовали с кучей нолей. Либо ваша система стала сбоить и падать через раз.

У Оракла в Premium Support есть шикарная команда поддержки zOS. Банк платит - его проблемы решают. Поэтому второй случай, когда вы не можете существовать на старом ящике - не подходит. А объем головной боли с миграцией и технические проблемы превысили некое пороговое значение, вот и не пошел заказчик на тотальное изменение системы.

Поэтому - да, до сих пор выполняется. По-крайней мере, я не слышал, чтобы их куда-то перетаскивали.

Давайте во-первых не будем переходит на личности. Это создает не нужный шум и отвлекает от дела.

Про бизнес и его видение мне известно, но если скатываться на такой уровень то цмысла в разделе "Вопросы ИТ" не будет вообще. Но раздел есть и в нем есть люди которым хочется понять где собака порылась.

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

Следовательно мы топчемся на одном месте.

[zVlad]

Неужели правда система та до сих пор выполняется в Oracle for zOS? Ведь Oracle прекратил развитие их версии for zOS много-много лет назад.

К примеру, ЦБ РФ как сконсолидировал ораклы из 70+ расчетных центров на z/OS лет 7-8 назад так и сидит до сих пор на последней 10-ке. Там по слухам оракл божится, что будет в индивидуальном порядке делать патчи пока "ишак не сдохнет или падишах". Опять же по слухам нешатко-невалко пытаются смигрировать/переписать на db2/zOS, но пока "воз и ныне там".

Ну а Вы можете приподнять савесу тайны над тем почему у ЦБ попытки "смигрировать/переписать на db2/zOS" идут ни шатко не валко? Бесконечно сидеть на старом железе физически не возможно. Появляются новые МФ с новыми возможностями, которые использует DB2, a Оракл даже с "шикарной командой поддержки zOS" не в состоянии все эти новые возможности внедрить в Oracle for zOS.

Oracle не выкатил версию 11g для zOS (Oracle Note 461234.1)

A в Oracle 10g говорится:
http://docs.oracle.com/html/B13524_01/overview.htm

Foremost in this category is the Oracle relational database server, which has been ported to z/OS, OS/390, and predecessor IBM MVS operating systems since Oracle RDBMS Version 5 (1986). The current product is Oracle Database 10g Release 1 (10.1) for IBM z/OS (OS/390). As with all prior Oracle versions, the z/OS implementation of this product is compiled from the same C language source code as on other platforms, differing only in the thin layer of programming that adapts it to the host operating system. ....

А самое печальное открывается из вот этой фразы:

This means the SQL and PL/SQL languages, Java facilities, SQL statement optimizer, and other Oracle features work the same on z/OS as they do on other Oracle platforms.

Это значит что оптимаизер Oracle на МФ даже не в курсе механизмов ввода-вывода МФ для более еффективного чтения данных с дисков. Это полный абзац.

Правда они успокаивают своим клиентов тем что:

Despite this commonality, the Oracle Database for z/OS makes extensive use of features unique to the operating system: it is managed by a formal z/OS subsystem, uses cross-memory services for inter-address-space operations, and exploits z/OS Workload Manager (WLM) facilities to classify and dispatch database requests from remote clients. Because of current limitations in IBM's Language Environment (LE) for z/OS support for 64-bit virtual memory addressing, a patented multi-address-space server architecture allows Oracle Database for z/OS to support far larger workloads than the available 31-bit addressing would normally permit. The Oracle software component that provides the subsystem and address space management facilities is called OSDI (Operating System Dependent Interface) and is unique to z/OS.

T.e. Oracle на zOS даже не использует 64 bit addressing, что и предполагалось.

[zVlad]

Хорошая статья:

http://www.longpelaexpertise.com/ezine/Oracle_zOS.php

[iDesperado]

Ну а Вы можете приподнять савесу тайны над тем почему у ЦБ попытки "смигрировать/переписать на db2/zOS" идут ни шатко не валко?

да какая тут может быть тайна ? db2/zos просто полный примитив на фоне старенького oracle10. db2 на мф до сих пор юзают как тупой сторидж, вся логика в программах аля cobol. в SQLPL языке нет ни пакетов ни примитивных массивов. нет рефкурсоров. понятно, что суровый софт на такую субд

Нанятые писатели увлеклись nested views и stored procedures до такой степени что DB2 только и строил прoмежуточные данныe.

замахаешся мигрировать с оракла.