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

[iDesperado]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.

[Komissar]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

Оракл издавна проеден индусами, вот и получаем г на палке.

[zVlad]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.

Как обычно пернул в лужу. Не надоело?

[zVlad]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

Оракл издавна проеден индусами, вот и получаем г на палке.

В данном случае не получилось лишь с одним типом данных - LOB.
Обсуждается альтернатива - IBM IDR. Но в сязи с лучшими временами через промежуточную таблицу вероятно остановятся на нем. Деньги платить они не захотят.

[Dmitry67]

Как обычно пернул в лужу. Не надоело?

Потрясающие soft skills!

[zVlad]

Оракл пообещал к четвергу на селeдущей неделе исправиться и предоставить нормально работающий GoldenGate.

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

На проекте насчитывается порядка 30 человек. Переносом данных ~ 4 ТБ (без индексов) занимаются всерьез двое. Я и коллега из Москвы. В конце прошлого года нас остановили по нехватке денег. В начале марта дали сигнал отправки в путь. Ждали сервер приготовят для QA, потом выяснелось что скоро, по плану, рефреш QA с Продакшн. Сделал рефреш за Easter weekend. Только начали двугать LOB's в QA всплыла проблема в Оракле GoldenGate. Митинги, балтовня. Прошло две недели и сбнова кончились деньги.

А мне хочется в Сочи. Сын там занимается реновацией купленного дома. Там тепло, там хорошо. Но Ковид не пускает.

[Flash-04]

Так вы, теперь миллионер? 10 лямов на двоих

[zVlad]

Так вы, теперь миллионер? 10 лямов на двоих

Я ж написал - на проекте примерно 30 человек. Это по списку тех кого извещают об остановке. Некоторые, и их довольно много, включены, но я не представляю что они там делают.
Я с начала года зачарджил не более 30 часов. Это копейки. Причем я именно те часы ставлю что трачу на проект, для остального у меня есть другой код. Куда лямы уходят не представляю.

[ALV00]

Большой объем памяти конечно помогает. А разве select блокирует в DB2?

да, db2 блокирует что бы получить что-то консистентное. это классический блокировочник. там есть грязное чтение и в последних версиях костыли в стиле last committed, но костыли выдают неконсистентный набор. RC, RR и Serializable - блокируют при чтении.

Что значит консистентное? Есть разные феномены: lost updates, dirty reads, nonrepeatable reads, phantoms. Первые два db2 CS лечит.
С последним особенно тяжело бороться, в Оракле лечится только serializable уровнем.
При CS блокируется только одна запись, которую в данный момент читают.

The duration of row locking varies with the isolation level being used:
UR scans: No row locks are held unless row data is changing.
CS scans: Row locks are generally held only while the cursor is positioned on the row. Note that in some cases, locks might not be held at all during a CS scan.
RS scans: Qualifying row locks are held only for the duration of the transaction.
RR scans: All row locks are held for the duration of the transaction.

[ALV00]

Большой объем памяти конечно помогает. А разве select блокирует в DB2?

да, db2 блокирует что бы получить что-то консистентное. это классический блокировочник. там есть грязное чтение и в последних версиях костыли в стиле last committed, но костыли выдают неконсистентный набор. RC, RR и Serializable - блокируют при чтении.

Что значит консистентное? Есть разные феномены: lost updates, dirty reads, nonrepeatable reads, phantoms. Первые два db2 CS лечит.
С фантомами особенно тяжело бороться, в Оракле лечится только serializable уровнем.
При CS блокируется только одна запись, которую в данный момент читают.

The duration of row locking varies with the isolation level being used:
UR scans: No row locks are held unless row data is changing.
CS scans: Row locks are generally held only while the cursor is positioned on the row. Note that in some cases, locks might not be held at all during a CS scan.
RS scans: Qualifying row locks are held only for the duration of the transaction.
RR scans: All row locks are held for the duration of the transaction.

[iDesperado]

Что значит консистентное?

базовое понятие, из ansi sql стандарта. оракл и прочие версионники без блокировок выдают читающему запросу слепок базы на момент старта запроса/транзакции, т.е. на единый момент времени, обеспечивая read consistency. устаревшие субд блокировочники так не могут

Есть разные феномены: lost updates, dirty reads, nonrepeatable reads, phantoms. Первые два db2 CS лечит.

CS выдает неконсистентную кашу вместо данных. представь таблицу счетов с балансом клиента, CS scan вычитает кашу где все баласы на разный момент времени. если клиент1 перевел денег клиенту10, то CS scan может запросто вычитать баланс клиента1, еще до того как баланс уменьшился, а баланс клиента10 после того как увеличился. на выходе каша неконсистентная. что бы получить что-то консистентное db2 должен по мере чтения хотя бы shared блокировки оставлять, значит вынужден поднимать isolation level до RS,RR или serializable. а это за собой тянет тучу сложностей с конкурирующими транзакциями, которые теперь вынуждены ждать, а то и вовсе по deadlock вываливаться.

С последним особенно тяжело бороться, в Оракле лечится только serializable уровнем.

в оракле 2 уровня изоляции. куда проще то ?
собственно на дворе 2021 год, оркловая модель победила. в postgres уже выкатили zheap таблицы в альфа версии, скоро postgres еще на хороший шаг будет ближе к оракловой модели.

[deev_a_v]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.

Лет пятнадцать назад, когда я имел несчастье сопрягать DB2 с .NET в одном проекте, с поддержкой ODBC у IBM было очень плохо.

[ALV00]

CS выдает неконсистентную кашу вместо данных. представь таблицу счетов с балансом клиента, CS scan вычитает кашу где все баласы на разный момент времени. если клиент1 перевел денег клиенту10, то CS scan может запросто вычитать баланс клиента1, еще до того как баланс уменьшился, а баланс клиента10 после того как увеличился. на выходе каша неконсистентная. что бы получить что-то консистентное db2 должен по мере чтения хотя бы shared блокировки оставлять, значит вынужден поднимать isolation level до RS,RR или serializable. а это за собой тянет тучу сложностей с конкурирующими транзакциями, которые теперь вынуждены ждать, а то и вовсе по deadlock вываливаться.

Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.

[iDesperado]

Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.

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

[zVlad]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.

GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.

Лет пятнадцать назад, когда я имел несчастье сопрягать DB2 с .NET в одном проекте, с поддержкой ODBC у IBM было очень плохо.

А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.