не так супер сложно. been there.Komissar wrote: ↑14 Apr 2021 06:27правильное замечание.uncle_Pasha wrote: ↑14 Apr 2021 05:24Если это не статическая файлопомойка, где документы только добавляются, то сделать consistent backup при такой конфигурации далеко не просто (хоть и возможно).
У нас на самом деле используется и то и другое. Кроме тех документов что в DB2, в LOB хранятся есть примочки не на MF где хранятся доки в файлах. Проблем с примочкой больше чем с DB2. Точнее с DB2 их нет нет вообще, а с примочкой есть постоянно. Осебенно с DR.StrangerR wrote: ↑16 Apr 2021 00:53 Транзакционность то конечно, но если файлы всегда _пишем новый_ то оно решается легко (базу коммитим после записи файла). А содержимое файла никто не гарантирует. Даже господь бог. Речь тут про то что если не нужна супер транзакционность и файлов очень много или это нечто вроде логов (когда мелкие потери не страшны) то база хуже файлов. Когда нужна транзакционность то конечно, лучше базы зверя нет.
GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.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 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 секунд.
Вот такие талантливые программисты работают в Оракл.
Как обычно пернул в лужу. Не надоело?iDesperado wrote: ↑17 Apr 2021 18:52GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.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.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 секунд.
Вот такие талантливые программисты работают в Оракл.
Я ж написал - на проекте примерно 30 человек. Это по списку тех кого извещают об остановке. Некоторые, и их довольно много, включены, но я не представляю что они там делают.
Что значит консистентное? Есть разные феномены: lost updates, dirty reads, nonrepeatable reads, phantoms. Первые два db2 CS лечит.iDesperado wrote: ↑12 Apr 2021 16:10да, db2 блокирует что бы получить что-то консистентное. это классический блокировочник. там есть грязное чтение и в последних версиях костыли в стиле last committed, но костыли выдают неконсистентный набор. RC, RR и Serializable - блокируют при чтении.
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 wrote: ↑24 Apr 2021 19:00Что значит консистентное? Есть разные феномены: lost updates, dirty reads, nonrepeatable reads, phantoms. Первые два db2 CS лечит.iDesperado wrote: ↑12 Apr 2021 16:10да, db2 блокирует что бы получить что-то консистентное. это классический блокировочник. там есть грязное чтение и в последних версиях костыли в стиле last committed, но костыли выдают неконсистентный набор. RC, RR и Serializable - блокируют при чтении.
С фантомами особенно тяжело бороться, в Оракле лечится только 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.
базовое понятие, из ansi sql стандарта. оракл и прочие версионники без блокировок выдают читающему запросу слепок базы на момент старта запроса/транзакции, т.е. на единый момент времени, обеспечивая read consistency. устаревшие субд блокировочники так не могут
CS выдает неконсистентную кашу вместо данных. представь таблицу счетов с балансом клиента, CS scan вычитает кашу где все баласы на разный момент времени. если клиент1 перевел денег клиенту10, то CS scan может запросто вычитать баланс клиента1, еще до того как баланс уменьшился, а баланс клиента10 после того как увеличился. на выходе каша неконсистентная. что бы получить что-то консистентное db2 должен по мере чтения хотя бы shared блокировки оставлять, значит вынужден поднимать isolation level до RS,RR или serializable. а это за собой тянет тучу сложностей с конкурирующими транзакциями, которые теперь вынуждены ждать, а то и вовсе по deadlock вываливаться.
в оракле 2 уровня изоляции. куда проще то ?
Лет пятнадцать назад, когда я имел несчастье сопрягать DB2 с .NET в одном проекте, с поддержкой ODBC у IBM было очень плохо.iDesperado wrote: ↑17 Apr 2021 18:52GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.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 секунд.
Вот такие талантливые программисты работают в Оракл.
Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.iDesperado wrote: ↑24 Apr 2021 20:18 CS выдает неконсистентную кашу вместо данных. представь таблицу счетов с балансом клиента, CS scan вычитает кашу где все баласы на разный момент времени. если клиент1 перевел денег клиенту10, то CS scan может запросто вычитать баланс клиента1, еще до того как баланс уменьшился, а баланс клиента10 после того как увеличился. на выходе каша неконсистентная. что бы получить что-то консистентное db2 должен по мере чтения хотя бы shared блокировки оставлять, значит вынужден поднимать isolation level до RS,RR или serializable. а это за собой тянет тучу сложностей с конкурирующими транзакциями, которые теперь вынуждены ждать, а то и вовсе по deadlock вываливаться.
хорошая затравка для беспощадного флейма, но дискуссия имхо уже лет 10 не актуальна. dwh уже так не работают, а версионники почти вытеснили блокировочную модель именно от того что блокировочник сложен - нужно четко понимать все типы блокировок, а их миллион, начиная с блокировок намерения. надо знать какие типы с которыми совместимы, где будет больно без read consistency. плюс тьма блокировок, в том числе и на чтение, по любому приводит к дедлокам, так что и про надежность имхо спорное утверждение.ALV00 wrote: ↑24 Apr 2021 23:37 Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.
А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.deev_a_v wrote: ↑24 Apr 2021 22:33Лет пятнадцать назад, когда я имел несчастье сопрягать DB2 с .NET в одном проекте, с поддержкой ODBC у IBM было очень плохо.iDesperado wrote: ↑17 Apr 2021 18:52GG работает с основными субд через ODBC, судя по тому что 6 часов тупит процесс db2 то проблема на стыке ODBC и базы данных из далеких 70х. сдается мне оракл посоветовал найти админа на МФ, который выяснит существуют ли в природе рабочие ODBC драйвера или платформа скисла до появления ODBC протокола.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 секунд.
Вот такие талантливые программисты работают в Оракл.
Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Если это была DB2 for zOS, то должна была бы идти речь о DB2 Connect. Если не было речи о DB2 Connect то мог бы быть драйвер от third-party (связанного с TIBCO, забыл их название), был у нас такой в начале 2000-х. Пока не заменили на IBM DB2 Connect и нас колбасило.deev_a_v wrote: ↑25 Apr 2021 16:04Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Ну, не так уж и вытеснили. В MS SQL версионность используют не так уж часто по моему опытуiDesperado wrote: ↑25 Apr 2021 08:01хорошая затравка для беспощадного флейма, но дискуссия имхо уже лет 10 не актуальна. dwh уже так не работают, а версионники почти вытеснили блокировочную модель именно от того что блокировочник сложен - нужно четко понимать все типы блокировок, а их миллион, начиная с блокировок намерения. надо знать какие типы с которыми совместимы, где будет больно без read consistency. плюс тьма блокировок, в том числе и на чтение, по любому приводит к дедлокам, так что и про надежность имхо спорное утверждение.ALV00 wrote: ↑24 Apr 2021 23:37 Это все понятно, только не всегда нужны такие строгости. Например в DW где данные заливаются по ночам а читаются днем. Блокировочники проще, надеждей и быстрей. db2 это танк со всеми его недостатками. А если это банковские транзакции, то дефолтная изоляция Оракла тоже не поможет, надо эксклюзивно блокировать счет перед тем как его апдейтить, иначе неприятности гарантированы.
ну все что мигрирует в azure чаще версионное, т.к. мсскл по дефолту версионный. всякие synapsis, sql dwh - имеющие в родителях мсскл, тоже версионные. в sql dwh вроде всего два варианта - грязное чтение, read committed snapshot
Какое еще TIBCO? Я же написал - базу и все вопросы с ней связанные поддерживал IBM. Они же и драйвер подбирали.zVlad wrote: ↑25 Apr 2021 18:22Если это была DB2 for zOS, то должна была бы идти речь о DB2 Connect. Если не было речи о DB2 Connect то мог бы быть драйвер от third-party (связанного с TIBCO, забыл их название), был у нас такой в начале 2000-х. Пока не заменили на IBM DB2 Connect и нас колбасило.deev_a_v wrote: ↑25 Apr 2021 16:04Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Но это уже не про IBM история.