JP Morgan Chase Oracle database outage

[Dmitry67]

1. В примере Zombie UPDATE выполняется в короткой транзакции. Поэтому физической блокировки нет.
2. Вот первый честный ответ Отвечаю. "Как то" - через некоторые поля в логических локах

[crypto5]

Есть мнение что когда зайдет следующий клиент и сделает запрос:

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

то он увидит залоченный билет, потому что операция select чтения является compatible с локом записи, который вы поставили используя select ... for update.

думаю не увидит, WHERE <condition> SKIP LOCKED DATA будет пытаться ставить шаред лок (или лок намерений, но тут не суть важно), который не совместим с апдейт локом. поэтому SKIP LOCKED DATA пропустит все, что залочено запросом FOR UPDATE

Где про такое можно почитать?

[iDesperado]

Где про такое можно почитать?

по идеи тут:
http://publib.boulder.ibm.com/infocente ... 005274.htm

но тут получается, что совместимы.
интересный поворот. тогда я ничего не понимаю

UPD: FOR UPDATE вообще exclusive блокировку должна наверно ставить, сейчас проверим

[Dmitry67]

Кстати в SQL server есть hint (READPAST) который делает то же самое.

Кстати в нашей дискуссии потерялся еще такой момент - а как длинный лок (понятно что решение безумное) держат в IIS или иной системе? Итак, делается чтото вроде

BEGIN TRANSACTION
UPDATE...

И потом return??? В IIS произойдет следующее: у объекта коннекции счетчик ссылок станет 0, она отресетится (с rollback), вернется в pool, а блокировка сбросится. Если стоит noreset, то коннекция уйдет в пул, вместе с транзакцией. Потом эта коннекция с транзакцией будет выдана случайному процессу Впрочем, я уверен что zVlad никогда не работал с системами, работающими через connection pool.

[sp123]

а как длинный лок (понятно что решение безумное) держат в IIS или иной системе?

Никак. В stateless OLTP приложениях борьба идет за сотые доли секунды, а за длинный лок разработчика убивают.

[Dmitry67]

Вы мне это говорите? Я то это знаю

[iDesperado]

Никак. В stateless OLTP приложениях борьба идет за сотые доли секунды, а за длинный лок разработчика убивают.

точно так же как за создание бутылочного горлышка из единой записи итога. но зато у zVlad 30 лет опыта

[mynameiszb]

В stateless OLTP приложениях борьба идет за сотые доли секунды, а за длинный лок разработчика убивают.

Мы когда в Дойче данные лили - то вообще через промежуточный буфер это забрасывали и через партиции потом буфер чистили. И какие там могут быть локи, когда по 4-5 тысяч записей в секунду прокачивало.

[iDesperado]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

[sp123]

Никак. В stateless OLTP приложениях борьба идет за сотые доли секунды, а за длинный лок разработчика убивают.

точно так же как за создание бутылочного горлышка из единой записи итога. но зато у zVlad 30 лет опыта

Ну, справедливсти ради, zVlad - сисадмин и DBA в традиционной enterprise application, а не архитектор. Поэтому об особенностях разработки веб-приложений может не знать. Точно так же, как девелопера нельзя подпускать к администрированию production железяки, хотя у него тоже есть кое-какой опыт .

[crypto5]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Вот тут написано что можед быть U: http://publib.boulder.ibm.com/infocente ... lkwhat.htm, если я не ошибаюсь.
Понятно что я смотрю только CS изоляцию.

[iDesperado]

Вот тут написано что можед быть U: http://publib.boulder.ibm.com/infocente ... lkwhat.htm, если я не ошибаюсь.
Понятно что я смотрю только CS изоляцию.

ну я вроде туда-же смотрел. если смотреть на красненькую, то U, но мне теперь больше кажется, что следует зелененькие смотреть.
это к вопросу о хорошести документации, для db2/zOS так и не смог найти таблицу совместимости блокировок.

[crypto5]

Вот тут написано что можед быть U: http://publib.boulder.ibm.com/infocente ... lkwhat.htm, если я не ошибаюсь.
Понятно что я смотрю только CS изоляцию.

ну я вроде туда-же смотрел. если смотреть на красненькую, то U, но мне теперь больше кажется, что следует зелененькие смотреть.
это к вопросу о хорошести документации, для db2/zOS так и не смог найти таблицу совместимости блокировок.

Нам нужна последняя колонка. Та которую вы смотрите - для блокировки всей таблицы, опять же если я правильно понимаю/.

[iDesperado]

Нам нужна последняя колонка. Та которую вы смотрите - для блокировки всей таблицы, опять же если я правильно понимаю/.

да, наверно вы правы, последняя. тады ой

[zVlad]

Моя цель лишь поправлять наиболее горячие головы здесь на форуме, развеивая мифы о МФ и ДБ2 в частности. Увы в этой область очень высок уровень мифотворчество.

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

P.S. На этой неделе интервьюировал одного перца. У перца последний проект был на связке MF - Oracle. Ребята выгружали из MF данные в виде плоских файлов, грузили их в Oracle, там ваяли какой-то back-end и front-end, данные усиленно массировали и отправляли назад. Я ему говорю - все это интересно, но ведь можно было бы все то же самое сделать на самом MF, там у вас и DB2 есть, и REXX, и вообще много всего, на хрена такой overhead? А он грит - так все проще и быстрее...

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

Если у Вашего перца основной бэкграунд это Оракл (а это видимо так раз Вы его интервьюировали), то ничего удивительного. И более того глупо, хотя бы потому что к ДБ2 можно коннектиться и выполнять запросы с любого софтвэра, работающего с ODBC или JDBC. Я бы такого "специалиста" даже не рассмотривал бы. Это не специалист.Вот вам еще один миф о ДБ2 на МФ. Свежеиспеченный.

[iDesperado]

Ну, справедливсти ради, zVlad - сисадмин и DBA в традиционной enterprise application, а не архитектор. Поэтому об особенностях разработки веб-приложений может не знать. Точно так же, как девелопера нельзя подпускать к администрированию production железяки, хотя у него тоже есть кое-какой опыт .

ну немного выше zVlad писал так:

Программисты для ДБ2 на МФ вообще мало что знают о локах и как правило используют накатанные подходы не особо вдумываясь в них. В результате нам, DBA, порой приходится с программистами проводить разъяснительную работу о том что надо делать чтобы не только написать программу, но и сделать так чтобы программа работала эффективно в многопользовательской среде выполнения.

[sp123]

Вот и Вы говорите что "чтобы было кул, и DB2 в это ну никак не вписывается.". Почему не вписывается? Что нужно такое кул от БД чтобы молодое поколение интересовалось такого что нет в ДБ2? Очередной миф.

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит. А вот замутить что-нибудь на бесплатном mysql или там postgres в гараже - это нынче самое то, та самая струя.

Если у Вашего перца основной бэкграунд это Оракл (а это видимо так раз Вы его интервьюировали), то ничего удивительного. И более того глупо, хотя бы потому что к ДБ2 можно коннектиться и выполнять запросы с любого софтвэра, работающего с ODBC или JDBC. Я бы такого "специалиста" даже не рассмотривал бы. Это не специалист.Вот вам еще один миф о ДБ2 на МФ. Свежеиспеченный.

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

А интервью, он, кстати, не прошел - было много вранья в резюме, ну и на простых вопросах сыпался.

[zVlad]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

[Dim LEO]

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит.

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

[sp123]

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

Oracle уже все знают (или делают вид ), спецов на рынке масса, не пробиться, хочется что-то посвежее и погорячее. Это со стороны выпускников колледжа. А со стороны бизнеса - хоть оно и примитивно, зато халява.

[Dim LEO]

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

Oracle уже все знают (или делают вид ), спецов на рынке масса, не пробиться, хочется что-то посвежее и погорячее. Это со стороны выпускников колледжа. А со стороны бизнеса - хоть оно и примитивно, зато халява.

понятно, спасибо

[zVlad]

Вот и Вы говорите что "чтобы было кул, и DB2 в это ну никак не вписывается.". Почему не вписывается? Что нужно такое кул от БД чтобы молодое поколение интересовалось такого что нет в ДБ2? Очередной миф.

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит. А вот замутить что-нибудь на бесплатном mysql или там postgres в гараже - это нынче самое то, та самая струя.

Если у Вашего перца основной бэкграунд это Оракл (а это видимо так раз Вы его интервьюировали), то ничего удивительного. И более того глупо, хотя бы потому что к ДБ2 можно коннектиться и выполнять запросы с любого софтвэра, работающего с ODBC или JDBC. Я бы такого "специалиста" даже не рассмотривал бы. Это не специалист.Вот вам еще один миф о ДБ2 на МФ. Свежеиспеченный.

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

А интервью, он, кстати, не прошел - было много вранья в резюме, ну и на простых вопросах сыпался.

Я думаю что все таки есть разная молодежь. Одни хотят из гаража в миллионеры выйти. Другие хотят серьезными делами держать синицу в руках.

Ситуация когда нанимают контракторов при наличии собственных ресурвов известна и распространена. Те, кто сидит постоянно как правило не реагируют ни на какие изменения в работе, им невозможно объяснить почему они должны сегодня делать то что не делали вчера или год назад. Многие люди в динамичной компьютерной сфере ведут себя как те на конвейерах. На МФ таких больше, просто потому что МФ дольше. Пройдет время и такие же будут на РС. На Оракл уже таких до вала. Да и в Юникс саппорте тоже. Будут и на MySQL.

P.S. кстати на МФ для молодежи (и я уже об этом много раз говорил) открывается прекрасная перспектива роста потому что идет смена поколений. Да и насчет интересности я бы поспорил. Интересно хотя бы потому что нет предела для освоения нового. И не такого нового как скажем на РС где просто одна и та же тема с разной глубиной реализуется в десятках продуктах по сути повторяя одно и тоже многократно. В zOS есть одна компонента для работы со storage (диски, ленты, иерархическая сторидж), но эту компоненту можно годами изучать и будешь находить новое. У нас двое в компании на этом только и работают. Двое осталось и на все системные работы по всем (двум) МФ, включая ДБ2 и аппликэйшн сервера и сети и секьюрити и WebSphere и Юникс и Линукс и мониторинг, все кроме собственно прикладных программ. Молодому у нас раздолье бы было для развития, многие бы позавидовали.

[Dim LEO]

IMHO "старики" не хотят потерять специализацию и по моему правильно делают

[zVlad]

IMHO "старики" не хотят потерять специализацию и по моему правильно делают

Я старик, но мне несовсем понятно что Вы имеете в виду.

[crypto5]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

А ниче что там в шапке написано: DB2 UDB for z/OS Version 8?