JP Morgan Chase Oracle database outage

[zVlad]

... всякое не относящееся к задаче поскипано... Если за отведененное время (обычно 15 минут) решение не было принято, то билет (место) вернется в пул доступных для продажи билетов (мест). Просто снимется блокировка.

Про реальную жизнь не надо, а? В реальной жизни задача покупки авиабилетов или там на ночной поезд (там конкретные места сразу продают) гораздо сложнее приведенного примитивного примера и содержит гораздо больше компонентов и множество распределенных баз данных. Рассматриваем конкретную приведенную задачу. К которой можно прибавить что я, претендуя на единственный оставшийся билет в 12:05, хотел бы узнать что несмотря на то что билетов прямо сейчас нет, шансы у меня еще есть, и если попробовать еще раз через 25 минут, мне может повезти если билет не выкупят. Раньше чем в 12:30 мне пробовать смысла нет никакого - пустая трата времени и ресурсов, поэтому и я, и веб-сервер можем заняться чем-то более полезным.

Теперь подробнее про блокировку. Как эта блокировка сделана? Где установлен 15 минутный timeout? Средствами DB2 и чего-то-там с очередной нечитаемой многобуквенной аббревиатурой большими буквами заблокирована запись? Или все-таки логическими средствами достигается и что билет убирается из пула (блокируется), и что через 15 минут или ранее он туда возвращается?

Если делать блокировку средствами Бд, то по какой бы причине транзакция не завершилась и блокировка будет снята автоматически и начатые изменения будут отменены, причем надежным отлаженным кодом. Логические же средства изобретамые каждым новым программистом потребуют совершенно других подходов и будут источником потенциальных проблем всегда когда код меняться будет.

А почему вы считаете что код использующий IFCID не может быть источником потенциальных проблем? Как мне работать с этой штукой из джавы? Ну и вы сами не рекомендовали ее использовать в конце концов..

Не понял причем здесь IFCID?

[Zombie416]

По крайней мере Вы могли бы из того сообщения понять что произошел таймаут и понятно что до слов "IS TIMED OUT" даны координаты того кто был таймед аут, а после этих слов координаты того кто держал данные к которым обращался первый. Во втором сообщении рассказано о ресурсе из которого произошел сыр-бор. В том примере это была строка некой таблицы и в сообщении вы может увидеть и имя таблицы и номер страницы и номер строки в странице. Так что нечитаемы те сообщения только для ленивых, а того что написано оно большими или маленькими буквами ровным счетом ничего не меняется вовсе.

Ну под чем-то нечитаемым большими буквами я имел ввиду не сообщение об ошибке, а некий магический блок в DB2/zOS/MF и т.д. чудесным образом решающий проблему, и позволяющий избежать логических блоков и программистами писать "как-то работающие программы".

Но не суть, вернемся же к конкретной задаче. Вы, анонимный пользователь, из дома, через WebSphere запущенной прям на MF с базой, в 12:00 заблокировали билет на 30 минут, до 12:30. Как именно происходит блокировка записи?

Потом я, тоже анонимный пользователь, пытаюсь купить тот же, еще не купленный, билет в 12:05. Сколько мне придется ждать до получения ответа могу я его купить или нет? Что если блокировка не 15 минут, а 24 часа? С точки зрения базы, кстати, и вы, и я, один и тот же пользователь.

Только не придирайтесь к условию задачи, ладно? Это лишь пример очень частой и реальной ситуации когда требуется распределять ограниченные ресурсы между пользователями. И к консистентости отчетов это тоже относится напрямую - не может быть один билет заблокирован или куплен двумя разными людьми. Что именно блокируется - билеты, клерки, адреса -- не суть.

[zVlad]

.... я, тоже анонимный пользователь, пытаюсь купить тот же, еще не купленный, билет в 12:05. ....

Что значит "купить тот же билет"? Вы сможете выбирать только из тех билетов которые Вам предложит система. В этот набор не будет включен билет уже удерживаемый другим пользователем.

[crypto5]

... всякое не относящееся к задаче поскипано... Если за отведененное время (обычно 15 минут) решение не было принято, то билет (место) вернется в пул доступных для продажи билетов (мест). Просто снимется блокировка.

Про реальную жизнь не надо, а? В реальной жизни задача покупки авиабилетов или там на ночной поезд (там конкретные места сразу продают) гораздо сложнее приведенного примитивного примера и содержит гораздо больше компонентов и множество распределенных баз данных. Рассматриваем конкретную приведенную задачу. К которой можно прибавить что я, претендуя на единственный оставшийся билет в 12:05, хотел бы узнать что несмотря на то что билетов прямо сейчас нет, шансы у меня еще есть, и если попробовать еще раз через 25 минут, мне может повезти если билет не выкупят. Раньше чем в 12:30 мне пробовать смысла нет никакого - пустая трата времени и ресурсов, поэтому и я, и веб-сервер можем заняться чем-то более полезным.

Теперь подробнее про блокировку. Как эта блокировка сделана? Где установлен 15 минутный timeout? Средствами DB2 и чего-то-там с очередной нечитаемой многобуквенной аббревиатурой большими буквами заблокирована запись? Или все-таки логическими средствами достигается и что билет убирается из пула (блокируется), и что через 15 минут или ранее он туда возвращается?

Если делать блокировку средствами Бд, то по какой бы причине транзакция не завершилась и блокировка будет снята автоматически и начатые изменения будут отменены, причем надежным отлаженным кодом. Логические же средства изобретамые каждым новым программистом потребуют совершенно других подходов и будут источником потенциальных проблем всегда когда код меняться будет.

А почему вы считаете что код использующий IFCID не может быть источником потенциальных проблем? Как мне работать с этой штукой из джавы? Ну и вы сами не рекомендовали ее использовать в конце концов..

Не понял причем здесь IFCID?

ПРи том что это единственный озвученный вами механизм который позволяет понять что строка в базе залочена не дожидаясь таймаута. А без такой функциональности все ваши теории накрываются медным тазом.

[crypto5]

.... я, тоже анонимный пользователь, пытаюсь купить тот же, еще не купленный, билет в 12:05. ....

Что значит "купить тот же билет"? Вы сможете выбирать только из тех билетов которые Вам предложит система. В этот набор не будет включен билет уже удерживаемый другим пользователем.

Ну вот в системе видимо где то будет скрин, который будет показывать список доступных билетов. Он видимо будет выводится запросом вроде select * from tickets where ..., так вот что нужно подставить в where что бы исключить уже заблокированные билеты? Или какой другой механизм позволяет достич такого исключения?

Ну кроме логических блокировок

[zVlad]

Не понял причем здесь IFCID?

ПРи том что это единственный озвученный вами механизм который позволяет понять что строка в базе залочена не дожидаясь таймаута. А без такой функциональности все ваши теории накрываются медным тазом.

У Вас бедное воображение. На самом деле IFI в прикладных программах не используется, используется в мониторных программах для наблюдения за работой ДБ2 и решения проблем. Я лишь отвечал на вопрос можно ли мониторить локи в ДБ2. К ответу притензии есть?

[crypto5]

Не понял причем здесь IFCID?

ПРи том что это единственный озвученный вами механизм который позволяет понять что строка в базе залочена не дожидаясь таймаута. А без такой функциональности все ваши теории накрываются медным тазом.

У Вас бедное воображение. На самом деле IFI в прикладных программах не используется, используется в мониторных программах для наблюдения за работой ДБ2 и решения проблем. Я лишь отвечал на вопрос можно ли мониторить локи в ДБ2. К ответу притензии есть?

Есть конечно, в третий раз спрашиваю, как система может узнать что билет/документ/тикет и т.д. залочен не дожидаясь таймаута.

[crypto5]

P.S.

У Вас бедное воображение.

Обьясните к чему эта фраза?

[iDesperado]

Вы что верите что кто-нибудь делает LOCKMAX 0?

смотрю сейчас SAP на z/OS, там по дефолту LOCKMAX 0 много где.

Кстати, то над чем Вы хихикаете - это состояние ДБ2 на начало 2000-х. Я пытался найти это же место в ДБ2 9, но пока не смог.

а я нашел:
The number of locks that IRLM (the DB2 locks manager) can manage
concurrently is limited by 90% of the total storage given to the IRLM private
address space. Each lock requires about 540 bytes. For example, if the size of
the IRLM private address space is 4 GB, IRLM can hold up to approximately
7900000 locks. Once this limit is reached, the report or transaction that requests
additional locks will be abnormally terminated with the ‘resource unavailable’
symptom (SQL return code –904). In many cases this is the very application
process that accumulated all these locks and performed a large number of
updates that now need to be backed out, for example, the application must do a
rollback. Consequently, the back out process takes very long (much longer than
the time the application spent until it abended). During this long time, the
affected resources (including the IRLM itself!) cannot be accessed by other
transactions and reports.
http://www.sdn.sap.com/irj/scn/index?ri ... ayout=true

4Gb на 8М локов, я потрясен. имхо поведение LUW мне в данном случае кажется гораздо более адекватным

UPD: блин не заметил, это и есть LUW, интересно почему SAP не хочет юзать родной db2/zOS, а предлагает именно LUW на zOS, видимо именно от мегокрутости db2/zOS

[Zombie416]

Что значит "купить тот же билет"? Вы сможете выбирать только из тех билетов которые Вам предложит система. В этот набор не будет включен билет уже удерживаемый другим пользователем.

Так мы возвращаемся к вопросу, который вы пропускаете: как именно происходит "удерживание" билета другим пользователем, и возвращение его обратно в 12:30.

Я бы также хотел чтобы система мне, как тетенька в ж/д кассе, сказала "у нас тут еще есть X подходящих невыкупленных билетов, но на них бронь, первая снимется в 12:30, приходите тогда".

[zVlad]

P.S.

У Вас бедное воображение.

Обьясните к чему эта фраза?

Эта фраза к тому что с Вашей легкой руки мы уперлись в один единственный вариант работы когда почему то обязательно нужно узнавать есть ли уже лок на ресурсе который, возможно, нам понадобится. Да, есть такое средство, но его ни один прикладной программист ДБ2 не использует (разве что этот программист из России). Он пишет программу в предположении что ресурсы свободны, и предусматривает специальную обработку если на самом деле ресурсы заняты. Есть способы минимизировать такую ситуацию, их несколько (в том числе начиная с ДБ2 v8 - SKIP LOCKED DATA), но мы с Вами уперлись в:

...в третий раз спрашиваю, как система может узнать что билет/документ/тикет и т.д. залочен не дожидаясь таймаута.

Cамое простое что могло и должно было бы придти Вам в голову - это то что сам таймаут уже с очевидностью говорит что ресурс занят, а сопровождающая это событие информация дает представление о том кем он занят, хотя пользователю совершенно это не интересно знать. Вы также уперлись в то что таймаут одна минута. Таймаут может быть любим на самом деле, зависит от задачи которая решается, и если это ОЛТП, то таймаут естественно будет установлен меньше, а если это WH то больше.
Вот и получается что (извините если обидел) у Вас бедная фантазия.

[zVlad]

Вы что верите что кто-нибудь делает LOCKMAX 0?

смотрю сейчас SAP на z/OS, там по дефолту LOCKMAX 0 много где.

Кстати, то над чем Вы хихикаете - это состояние ДБ2 на начало 2000-х. Я пытался найти это же место в ДБ2 9, но пока не смог.

а я нашел:
The number of locks that IRLM (the DB2 locks manager) can manage
concurrently is limited by 90% of the total storage given to the IRLM private
address space. Each lock requires about 540 bytes. For example, if the size of
the IRLM private address space is 4 GB, IRLM can hold up to approximately
7900000 locks. Once this limit is reached, the report or transaction that requests
additional locks will be abnormally terminated with the ‘resource unavailable’
symptom (SQL return code –904). In many cases this is the very application
process that accumulated all these locks and performed a large number of
updates that now need to be backed out, for example, the application must do a
rollback. Consequently, the back out process takes very long (much longer than
the time the application spent until it abended). During this long time, the
affected resources (including the IRLM itself!) cannot be accessed by other
transactions and reports.
http://www.sdn.sap.com/irj/scn/index?ri ... ayout=true

4Gb на 8М локов, я потрясен. имхо поведение LUW мне в данном случае кажется гораздо более адекватным

UPD: блин не заметил, это и есть LUW, интересно почему SAP не хочет юзать родной db2/zOS, а предлагает именно LUW на zOS, видимо именно от мегокрутости db2/zOS

Странный способ узнавать о ДБ2 от SAP. Не правильней ли это делать через ИБМ?

Я не знаю с какой целью SAP написал эту чушь, введя попутно Вас в состояние ложного понимания будто бы DB2 for LUW может быть выполняться на zOS (c чего Вы это взяли кстати, где у SAP так говорится?).

Вот лучше читайте здесь:

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

это по поводу v9, или здесь:

http://publib.boulder.ibm.com/cgi-bin/b ... 0715135732

это по поводу v7. V9 - это 64 bit адресация и память вовсе не ограничена 4 GB (кстати такого ограничения в zOS никогда не было, было 2 GB), v7 - это 31 bit адресация. В последнем случае размер блока для лока - 250 байт.

Никогда не слышал и никогда самому не проходилось видеть проблем с памятью для IRLM. Это не более чем Ваши, навеянные SAP, фантазии. Как правило DBA устанавливает такие ограничения по локам что до нехватки памяти дело дойти не может. Кроме того IRLM резервирует 10% памяти для must complete ситуаций.

Ну а в случае с v9 и 64 bit адресацией когда виртуальная память может быть 16 exa-bytes вообще говорить не о чем, верно?

[iDesperado]

ну то есть у zVlad все 30 минут висела бы мертвым грузом транзакция. наверно от того МФ и вымерли ...

[Dmitry67]

Дааа, уж... zVlad, либо сдайтесь либо предложите работающий механизм.

[iDesperado]

Странный способ узнавать о ДБ2 от SAP. Не правильней ли это делать через ИБМ?

ну документация у IBM мягко говоря оставляет желать лучшего, вот и приходиться смотреть в другие достоверные источники.

Я не знаю с какой целью SAP написал эту чушь, введя попутно Вас в состояние ложного понимания будто бы DB2 for LUW может быть выполняться на zOS (c чего Вы это взяли кстати, где у SAP так говорится?).

действительно, это я слунил. речь в документе идет именно о db2/zOS, меня сбила с толку UDB (раньше UDB только LUW бывала, маркетологи ИБМ на высоте)

Вот лучше читайте здесь:

http://publib.boulder.ibm.com/cgi-bin/b ... 0715135732

читаю, те же цифры:
You can estimate the IRLM control block structure at 250 bytes per lock. First, plan 6MB for the IRLM control block structure, then adjust according to your needs.

Никогда не слышал и никогда самому не проходилось видеть проблем с памятью для IRLM.

ну помнится вы утверждали, что и оракл на zOS не существует и с MQT не сталкивались, но это не означает что такого не существует в природе. я вот на LUW сталкивался, не вижу ни одной причины почему бы ровно те же проблемы не могли бы образоваться на db2/zOS

Ну а в случае с v9 и 64 bit адресацией когда виртуальная память может быть 16 exa-bytes вообще говорить не о чем, верно?

выглядит, что вы на полном серьезе считаете 64-бит из воздуха материализовывает память. я бы понял такое заявление в рамках x86. там действительно память резиновая т.к. стоит дешевле картошки, но в МФ активировать те 4гб небойсь тысяч 20 зеленых будет стоить.

[Zombie416]

обязательно нужно узнавать есть ли уже лок на ресурсе который, возможно, нам понадобится. Да, есть такое средство, но его ни один прикладной программист ДБ2 не использует

Вообщем, это, если не ошибаюсь, надо понимать так: целый класс задач на DB2 не решается вообще никак, в связи с редко встречающимися прикладными программистами достаточной для решения таких задач квалификации. Все сбежали на x86 и Oracle

Таймаут может быть любим на самом деле, зависит от задачи которая решается, и если это ОЛТП, то таймаут естественно будет установлен меньше, а если это WH то больше.

Ну так задача, которая решается, написана выше. Билет блокируется на время 30-1440 минут. Как?

[zVlad]

Дааа, уж... zVlad, либо сдайтесь либо предложите работающий механизм.

Работающий механизм чего? Купли-продажи авиабилетов? Я никогда не писал таких приложений и выдумывать наскоро не вижу смысла. Скажу лишь системам резервирования авиабилетов на МФ уже болше 40 лет. Да и вообще я не прикладной программист по жизни, хотя конечно приходилось писать в том числе и для баз данных.

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

[zVlad]

Дааа, уж... zVlad, либо сдайтесь либо предложите работающий механизм.

Хорошо. Будем считать что я сдался. Расскажите тогда мне как Вы или любой другой спорящий со мной будете продавать авиабилеты без использования блокировок или с использованием "логических" блокировок.

[Zombie416]

Работающий механизм чего? Купли-продажи авиабилетов? Я никогда не писал таких приложений и выдумывать наскоро не вижу смысла. Скажу лишь системам резервирования авиабилетов на МФ уже болше 40 лет.

Работающий механизм решения примитивной задачи из одной таблицы, которая к купле-продаже имеет такое же отношение как конструктор LEGO к небоскребу. Принцип, в целом, показывает.

Ну и явно 40 лет назад обходились без SKIP LOCKED, раз оно появилось в DB2 v8?

Да и вообще я не прикладной программист по жизни, хотя конечно приходилось писать в том числе и для баз данных.

Вы, если не ошибаюсь, раньше писали что проектировали базы, немножко знаете SQL, и устраиваете программистам инструктажи, чтобы они правильно писали код. Вот, пришли к вам программисты с проблемой. На оракле/mysql/mssql в такой ситуации прищлось бы делать блокировку на логическом уровне. Скажем, в ультра-наивном варианте, сделать из таблицы Tickets(TicketID,FlightID,...) нечто вроде Tickets(TicketID,FlightID, ... , BlockedBy, BlockedAt, BlockedUntil ).

Но читали эти программисты в форумах что на DB2 все не так, и так не делается. Так как именно делается?

[zVlad]

...

Таймаут может быть любим на самом деле, зависит от задачи которая решается, и если это ОЛТП, то таймаут естественно будет установлен меньше, а если это WH то больше.

Ну так задача, которая решается, написана выше. Билет блокируется на время 30-1440 минут. Как?

Вы окончательно запутались в расставленных, как Вам наверное кажется ловко, сетях. Вы даже не видите разницы между временем удержания ресурса транзакцией и временем ожидания освобождения (timeout) залоченного ресурса. О чем же мы тогда с вами говорим?

[Zombie416]

Вы окончательно запутались в расставленных, как Вам наверное кажется ловко, сетях. Вы даже не видите разницы между временем удержания ресурса транзакцией и временем ожидания освобождения (timeout) залоченного ресурса. О чем же мы тогда с вами говорим?

Какие уж тут сети. Я вас прошу предложить решение конкретной примитивной задачи, не использующее логические блокировки. Теоретически, такое решение может существовать при определенной конструкции базы.

Но вы все время пытаетесь то придраться к условию, то обнаружить сети или недостаток ума/витамина Д/фантазии/чего угодно у оппонентов. Зачем - не понимаю. Никакие мифы это явно не развенчивает.

[zVlad]

.... На оракле/mysql/mssql в такой ситуации прищлось бы делать блокировку на логическом уровне. Скажем, в ультра-наивном варианте, сделать из таблицы Tickets(TicketID,FlightID,...) нечто вроде Tickets(TicketID,FlightID, ... , BlockedBy, BlockedAt, BlockedUntil ).

Но читали эти программисты в форумах что на DB2 все не так, и так не делается. Так как именно делается?

Ну и как интересно эти Ваши дополнительные поля могут решить проблемы решаемые физическими блокировками? Каков по-Вашему алгоритм использования этих полей в процессе покупки билета?

[zVlad]

Вы окончательно запутались в расставленных, как Вам наверное кажется ловко, сетях. Вы даже не видите разницы между временем удержания ресурса транзакцией и временем ожидания освобождения (timeout) залоченного ресурса. О чем же мы тогда с вами говорим?

Какие уж тут сети. Я вас прошу предложить решение конкретной примитивной задачи, не использующее логические блокировки. Теоретически, такое решение может существовать при определенной конструкции базы.

Но вы все время пытаетесь то придраться к условию, то обнаружить сети или недостаток ума/витамина Д/фантазии/чего угодно у оппонентов. Зачем - не понимаю. Никакие мифы это явно не развенчивает.

А как я по-Вашему могу Вам объяснить что-нибудь если Вы даже в двух различные по природе временных параметрах запутались? Если Вы не видите между ними разницы и считаете что это одно и тоже. Ну как?

[Zombie416]

Ну и как интересно эти Ваши дополнительные поля могут решить проблемы решаемые физическими блокировками? Каков по-Вашему алгоритм использования этих полей в процессе покупки билета?

Что значит "решаемые физическими блокировками"? Есть решение с чисто физическими блокировками?

Блокировка вроде:

Code: Select all

UPDATE Tickets
SET BlockedBy=@UserId,BlockedTime=NowUTC(),BlockedUntil=NowUTC()+@LockTime
WHERE TicketID=@TicketID AND (BlockedBy IS NULL OR BlockedUntil<NowUTC() OR  BlockedBy=@UserId)

Соответственно, выдать все доступные билеты:

Code: Select all

SELECT * FROM Tickets WHERE <condition> AND (BlockedBy IS NULL OR BlockedBy=@UserId OR BlockedUntil<NowUTC())

Решение наивное, но принцип показывает.

[crypto5]

ДБ2 v8 - SKIP LOCKED DATA

Эта штука дает разницу только если если лок incompatible, то есть в нашем воркфлоу с билетами юзер выбирает билет, и блокирует его на запись. ПОсле этого другой юзер заходит, и делает select ... SKIP LOCKED DATA и заблокированный билет ему показывается! А опаньки наступает уже когда он хочет его проапдейтить.

Cамое простое что могло и должно было бы придти Вам в голову - это то что сам таймаут уже с очевидностью говорит что ресурс занят, а сопровождающая это событие информация дает представление о том кем он занят

А я в н-тый раз повторяю - я не хочу дожидаться таймаута.

Вы также уперлись в то что таймаут одна минута. Таймаут может быть любим на самом деле, зависит от задачи которая решается, и если это ОЛТП, то таймаут естественно будет установлен меньше, а если это WH то больше.

Ну и какой таймаут вы выставите в примере с билетами?

хотя пользователю совершенно это не интересно знать

Влт именно ДБА должен решать что пользователю интересно знать

Вот и получается что (извините если обидел) у Вас бедная фантазия.

Я понял вашу мысль, но на мой взгляд на самом деле это у вас больная фантазия, а не у меня бедная.