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 на МФ. Свежеиспеченный.