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

alex_127
Уже с Приветом
Posts: 7723
Joined: 29 Mar 2000 10:01
Location: Kirkland,WA

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

Post by alex_127 »

Komissar wrote: 14 Apr 2021 06:27
uncle_Pasha wrote: 14 Apr 2021 05:24
StrangerR wrote: 14 Apr 2021 04:19 все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов.
Если это не статическая файлопомойка, где документы только добавляются, то сделать consistent backup при такой конфигурации далеко не просто (хоть и возможно).
правильное замечание.
не так супер сложно. been there.
https://docs.microsoft.com/en-us/sql/re ... rver-ver15
StrangerR
Уже с Приветом
Posts: 38046
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Транзакционность то конечно, но если файлы всегда _пишем новый_ то оно решается легко (базу коммитим после записи файла). А содержимое файла никто не гарантирует. Даже господь бог. Речь тут про то что если не нужна супер транзакционность и файлов очень много или это нечто вроде логов (когда мелкие потери не страшны) то база хуже файлов. Когда нужна транзакционность то конечно, лучше базы зверя нет.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Многие data storage умеют создавать crash consistent snapshots файловой системы
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

StrangerR wrote: 16 Apr 2021 00:53 Транзакционность то конечно, но если файлы всегда _пишем новый_ то оно решается легко (базу коммитим после записи файла). А содержимое файла никто не гарантирует. Даже господь бог. Речь тут про то что если не нужна супер транзакционность и файлов очень много или это нечто вроде логов (когда мелкие потери не страшны) то база хуже файлов. Когда нужна транзакционность то конечно, лучше базы зверя нет.
У нас на самом деле используется и то и другое. Кроме тех документов что в DB2, в LOB хранятся есть примочки не на MF где хранятся доки в файлах. Проблем с примочкой больше чем с DB2. Точнее с DB2 их нет нет вообще, а с примочкой есть постоянно. Осебенно с DR.
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

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

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

Post by iDesperado »

zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий 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 протокола.
User avatar
Komissar
Уже с Приветом
Posts: 65200
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

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

Post by Komissar »

zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.
Оракл издавна проеден индусами, вот и получаем г на палке.
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

iDesperado wrote: 17 Apr 2021 18:52
zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий 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
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Komissar wrote: 17 Apr 2021 19:49
zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.
Оракл издавна проеден индусами, вот и получаем г на палке.
В данном случае не получилось лишь с одним типом данных - LOB.
Обсуждается альтернатива - IBM IDR. Но в сязи с лучшими временами через промежуточную таблицу вероятно остановятся на нем. Деньги платить они не захотят.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

zVlad wrote: 17 Apr 2021 21:08 Как обычно пернул в лужу. Не надоело?
Потрясающие soft skills!
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

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

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

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

А мне хочется в Сочи. Сын там занимается реновацией купленного дома. Там тепло, там хорошо. Но Ковид не пускает.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

Так вы, теперь миллионер? 10 лямов на двоих ;)
Not everyone believes what I believe but my beliefs do not require them to.
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

Flash-04 wrote: 24 Apr 2021 16:11 Так вы, теперь миллионер? 10 лямов на двоих ;)
Я ж написал - на проекте примерно 30 человек. Это по списку тех кого извещают об остановке. Некоторые, и их довольно много, включены, но я не представляю что они там делают.
Я с начала года зачарджил не более 30 часов. Это копейки. Причем я именно те часы ставлю что трачу на проект, для остального у меня есть другой код. Куда лямы уходят не представляю.
User avatar
ALV00
Уже с Приветом
Posts: 1491
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

iDesperado wrote: 12 Apr 2021 16:10
Flash-04 wrote: 12 Apr 2021 15:55 Большой объем памяти конечно помогает. А разве 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.
User avatar
ALV00
Уже с Приветом
Posts: 1491
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

ALV00 wrote: 24 Apr 2021 19:00
iDesperado wrote: 12 Apr 2021 16:10
Flash-04 wrote: 12 Apr 2021 15:55 Большой объем памяти конечно помогает. А разве 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
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

ALV00 wrote: 24 Apr 2021 19:00 Что значит консистентное?
базовое понятие, из ansi sql стандарта. оракл и прочие версионники без блокировок выдают читающему запросу слепок базы на момент старта запроса/транзакции, т.е. на единый момент времени, обеспечивая read consistency. устаревшие субд блокировочники так не могут
ALV00 wrote: 24 Apr 2021 19:00 Есть разные феномены: 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 вываливаться.
ALV00 wrote: 24 Apr 2021 19:00 С последним особенно тяжело бороться, в Оракле лечится только serializable уровнем.
в оракле 2 уровня изоляции. куда проще то ?
собственно на дворе 2021 год, оркловая модель победила. в postgres уже выкатили zheap таблицы в альфа версии, скоро postgres еще на хороший шаг будет ближе к оракловой модели.
deev_a_v
Уже с Приветом
Posts: 4660
Joined: 07 Apr 2018 15:16

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

Post by deev_a_v »

iDesperado wrote: 17 Apr 2021 18:52
zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий 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 было очень плохо.
User avatar
ALV00
Уже с Приветом
Posts: 1491
Joined: 08 Mar 2002 10:01
Location: NJ

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

Post by ALV00 »

iDesperado wrote: 24 Apr 2021 20:18 CS выдает неконсистентную кашу вместо данных. представь таблицу счетов с балансом клиента, CS scan вычитает кашу где все баласы на разный момент времени. если клиент1 перевел денег клиенту10, то CS scan может запросто вычитать баланс клиента1, еще до того как баланс уменьшился, а баланс клиента10 после того как увеличился. на выходе каша неконсистентная. что бы получить что-то консистентное db2 должен по мере чтения хотя бы shared блокировки оставлять, значит вынужден поднимать isolation level до RS,RR или serializable. а это за собой тянет тучу сложностей с конкурирующими транзакциями, которые теперь вынуждены ждать, а то и вовсе по deadlock вываливаться.
Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

ALV00 wrote: 24 Apr 2021 23:37 Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.
хорошая затравка для беспощадного флейма, но дискуссия имхо уже лет 10 не актуальна. dwh уже так не работают, а версионники почти вытеснили блокировочную модель именно от того что блокировочник сложен - нужно четко понимать все типы блокировок, а их миллион, начиная с блокировок намерения. надо знать какие типы с которыми совместимы, где будет больно без read consistency. плюс тьма блокировок, в том числе и на чтение, по любому приводит к дедлокам, так что и про надежность имхо спорное утверждение.
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

deev_a_v wrote: 24 Apr 2021 22:33
iDesperado wrote: 17 Apr 2021 18:52
zVlad wrote: 17 Apr 2021 13:27 Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий 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.
deev_a_v
Уже с Приветом
Posts: 4660
Joined: 07 Apr 2018 15:16

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

Post by deev_a_v »

zVlad wrote: 25 Apr 2021 15:14
А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.
Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
zVlad
Уже с Приветом
Posts: 16201
Joined: 30 Apr 2003 16:43

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

Post by zVlad »

deev_a_v wrote: 25 Apr 2021 16:04
zVlad wrote: 25 Apr 2021 15:14
А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.
Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Если это была DB2 for zOS, то должна была бы идти речь о DB2 Connect. Если не было речи о DB2 Connect то мог бы быть драйвер от third-party (связанного с TIBCO, забыл их название), был у нас такой в начале 2000-х. Пока не заменили на IBM DB2 Connect и нас колбасило.
Но это уже не про IBM история.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

iDesperado wrote: 25 Apr 2021 08:01
ALV00 wrote: 24 Apr 2021 23:37 Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.
хорошая затравка для беспощадного флейма, но дискуссия имхо уже лет 10 не актуальна. dwh уже так не работают, а версионники почти вытеснили блокировочную модель именно от того что блокировочник сложен - нужно четко понимать все типы блокировок, а их миллион, начиная с блокировок намерения. надо знать какие типы с которыми совместимы, где будет больно без read consistency. плюс тьма блокировок, в том числе и на чтение, по любому приводит к дедлокам, так что и про надежность имхо спорное утверждение.
Ну, не так уж и вытеснили. В MS SQL версионность используют не так уж часто по моему опыту

А в хипстерских базах (no sql, big data) про нее вообще не слышали)
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

Dmitry67 wrote: 26 Apr 2021 06:29 Ну, не так уж и вытеснили. В MS SQL версионность используют не так уж часто по моему опыту

А в хипстерских базах (no sql, big data) про нее вообще не слышали)
ну все что мигрирует в azure чаще версионное, т.к. мсскл по дефолту версионный. всякие synapsis, sql dwh - имеющие в родителях мсскл, тоже версионные. в sql dwh вроде всего два варианта - грязное чтение, read committed snapshot
deev_a_v
Уже с Приветом
Posts: 4660
Joined: 07 Apr 2018 15:16

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

Post by deev_a_v »

zVlad wrote: 25 Apr 2021 18:22
deev_a_v wrote: 25 Apr 2021 16:04
zVlad wrote: 25 Apr 2021 15:14
А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.
Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Если это была DB2 for zOS, то должна была бы идти речь о DB2 Connect. Если не было речи о DB2 Connect то мог бы быть драйвер от third-party (связанного с TIBCO, забыл их название), был у нас такой в начале 2000-х. Пока не заменили на IBM DB2 Connect и нас колбасило.
Но это уже не про IBM история.
Какое еще TIBCO? Я же написал - базу и все вопросы с ней связанные поддерживал IBM. Они же и драйвер подбирали.

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