JP Morgan Chase Oracle database outage

[Zombie416]

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

Да вы как-нибудь объясните. Начните хотя бы. Пока что никаких объяснений я не заметил, кроме парада аббревиатур и дампов event log-ов.

[Dmitry67]

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

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

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

Я понимаю
Я сам испорчен мифами, сами знаете - при слове МФ у веня представляются перфокаты
такие мифы безусловно надо развенчивать

Однако заявлять (притом с пафосом) 'на МФ/DB2 такой проблемы даже не возникает' а потом не приводить никаких аргументов и решений даже на игрушечном примере - это скорее работает против МФ/DB2.

Мы тут не сейлзы и не маркетологи, большая красная галка в презентации "Supported" нам пофигу, нам покажите, КАК это работает.

[zVlad]

....

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

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

Вы что свято верите SAP что DB2 for zOS называется UDB? В добавок, это наоборот раньше использовали UDB в названии DB2 for zOS, а в v9 перестали.

[zVlad]

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

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

...

Это не то чтобы спорное, это ложное утверждение. ИБМ документация всегда была эталоном для других и к моему счастью таковой остается.

[zVlad]

....

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

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

1. читаю, те же цифры:
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.

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

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

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

Боже как все запущенно.
1. Вы что утверждаете что для lock structures доступны только 6 МВ? Кстати в Вашей цитате из SAP цифры (правильно говорить числа, кстати) были другие совсем. Что Вы хотели сказать?
2. Интересно разбирались ли Вы тогда с причинами нехватки памяти? Ну и что нашли?
3. Да, конечно, я за почти 30 лет работы главным образов системным программистом как то умудрился не знать этого. А Вот сказанное Вами навевает мне мысль, которую я пытаюсь отогнать, что Вам не ведома виртуальная память.

[iDesperado]

1. Вы что утверждаете что для lock structures доступны только 6 МВ? Кстати в Вашей цитате из SAP цифры (правильно говорить числа, кстати) были другие совсем. Что Вы хотели сказать?

я утверждал что 8М локов займет более 4Gb памяти, откуда вы могли взять это "что для lock structures доступны только 6 МВ", у меня даже идей нет.
числа/цифры SAP совершенно идентичны числам/цифрам документации db2/zOS v9.1, раз уж документация такая чудесная у вас не займет много времени это проверить

2. Интересно разбирались ли Вы тогда с причинами нехватки памяти? Ну и что нашли?

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

3. Да, конечно, я за почти 30 лет работы главным образов системным программистом как то умудрился не знать этого. А Вот сказанное Вами навевает мне мысль, которую я пытаюсь отогнать, что Вам не ведома виртуальная память.

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

[zVlad]

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

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

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

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())

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

Чтобы лучше понять этот принцип, скажите пожалуйста:
1. Каким образом было определено какой именно тикет (@TicketID) можно логически заблокировать?
2. Может ли так оказаться что предикат (BlockedBy IS NULL OR BlockedUntil<NowUTC() OR BlockedBy=@UserId) не вернет значение True? Что тогда? Что будет с этим предикатом если BlockedBy не нул, а BlockedUntil > NowUTC()
3. Что предполагается делать сразу после выполнения UPDATE - завершить транзакцию или нет?

[zVlad]

ДБ2 v8 - SKIP LOCKED DATA

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

....

Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции UR.

The SKIP LOCKED DATA clause specifies that rows are skipped when incompatible locks are held on the row by other transactions. These rows can belong to any accessed table that is specified in the statement. SKIP LOCKED DATA can be used only with isolation CS or RS and applies only to row level or page level locks.

[zVlad]

.....

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

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

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

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

....

1. Тогда используйте SKIP LOCKED DATA, в чем проблема?

2. Пару секунд, секунду, пять секунд. Между нулем и 60 секундами примерно шестьдесят значений. Выбирайте любое на Ваш вкус.

[zVlad]

.....
Однако заявлять (притом с пафосом) 'на МФ/DB2 такой проблемы даже не возникает' ....

....

Дима, могу я Вас попросить приводить мои высказывания в достаточном объеме чтобы было понятно к чему вырванный Вами фрагмент относится. Ведь Вы же не станете утверждать ято я так сказал вообще, безотносительно чего-либо. О какой проблеме шла речь?

[iDesperado]

2. Может ли так оказаться что предикат (BlockedBy IS NULL OR BlockedUntil<NowUTC() OR BlockedBy=@UserId) не вернет значение True? Что тогда? Что будет с этим предикатом если BlockedBy не нул, а BlockedUntil > NowUTC()

простите за может хамский вопрос, но вы уверенны, что изучали SQL ? я к тому, что если у вас действительно опыт 30 лет и возникают такие вопросы, возникает вопрос, а был ли опыт ...

[zVlad]

1. Вы что утверждаете что для lock structures доступны только 6 МВ? Кстати в Вашей цитате из SAP цифры (правильно говорить числа, кстати) были другие совсем. Что Вы хотели сказать?

я утверждал что 8М локов займет более 4Gb памяти, откуда вы могли взять это "что для lock structures доступны только 6 МВ", у меня даже идей нет.
числа/цифры SAP совершенно идентичны числам/цифрам документации db2/zOS v9.1, раз уж документация такая чудесная у вас не займет много времени это проверить

....

Хорошо, а откуда взялись 8М локов? И о чем это говорит?
Вот Ваша цитата:

читаю, те же цифры:
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.
.

Из который пользуясь Вашей логикой выводится другое число - ~25 000 локов.
Цифры совершенно разные, не так ли? А идея все равно не понятна. К чему эти Ваши арифметические вычисления?

[Zombie416]

Чтобы лучше понять этот принцип, скажите пожалуйста:
1. Каким образом было определено какой именно тикет (@TicketID) можно логически заблокировать?
2. Может ли так оказаться что предикат (BlockedBy IS NULL OR BlockedUntil<NowUTC() OR BlockedBy=@UserId) не вернет значение True? Что тогда? Что будет с этим предикатом если BlockedBy не нул, а BlockedUntil > NowUTC()
3. Что предполагается делать сразу после выполнения UPDATE - завершить транзакцию или нет?

1. Путем выборки из билетов. Например, пользователю был показан список доступных (не блокированных, или блокированных им самим, или с истекшей блокировкой).

Далее пользователь выбирает один из билетов, нажимает кнопку "Броня" и может думать покупать-не покупать на протяжении @locktime

2. Тогда данный билет недоступен. "если BlockedBy не нул, а BlockedUntil > NowUTC() " => билет заблокирован

3. Да, вполне можно завершать транзакцию "блокирование пользователем Х билета Y на время Z".

При такой организации можно элементарно ответить на вопрос "сколько некупленных, но забронированных билетов, имеется на рейс №123?". Или "когда истекает первая и последняя броня на рейс №124?". Или "отменить все блокировки сделанные пользователем Х на рейсы 200-250".

[Dmitry67]

.....
Однако заявлять (притом с пафосом) 'на МФ/DB2 такой проблемы даже не возникает' ....

....

Дима, могу я Вас попросить приводить мои высказывания в достаточном объеме чтобы было понятно к чему вырванный Вами фрагмент относится. Ведь Вы же не станете утверждать ято я так сказал вообще, безотносительно чего-либо. О какой проблеме шла речь?

О локах.
Вы так и не привели решения.

[zVlad]

....

2. Интересно разбирались ли Вы тогда с причинами нехватки памяти? Ну и что нашли?

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

....

Эсклация, черт возьми (спокойно Ипполит, спокойно - это я себе), это не причина - это следствие. Не знаю как в LUW, но в DB2 for zOS эскалация вызывается превышением заданого количества локов наложенных транзакцией на таблицу.

Примерно тоже самое происходит в LUW:

Lock escalation is the process of replacing row locks with table locks, reducing the number of locks in the list. This parameter defines a percentage of the lock list held by an application that must be filled before the database manager performs escalation. When the number of locks held by any one application reaches this percentage of the total lock list size, lock escalation will occur for the locks held by that application. Lock escalation also occurs if the lock list runs out of space.

Несмотря на то что из последнего предложения следует что, да, эскалацию может вызвать нехватка памяти в lock list, мы так и не продвинулись ни на шаг к тому что же у Вас вызвало эту самую нехватку памяти. Так что же?

[zVlad]

.....
Однако заявлять (притом с пафосом) 'на МФ/DB2 такой проблемы даже не возникает' ....

....

Дима, могу я Вас попросить приводить мои высказывания в достаточном объеме чтобы было понятно к чему вырванный Вами фрагмент относится. Ведь Вы же не станете утверждать ято я так сказал вообще, безотносительно чего-либо. О какой проблеме шла речь?

О локах.
Вы так и не привели решения.

Я ж сдался уже и приготовился анализировать ваши решения.

[iDesperado]

Хорошо, а откуда взялись 8М локов? И о чем это говорит?

из документа SAP, я уже цитировал выше "the IRLM private address space is 4 GB, IRLM can hold up to approximately 7900000 locks."

Вот Ваша цитата:

это не моя цитата, это цитата из ссылки приведенной вами ведущей на документацию db2/zOS v7
как я понял в чудесной документации IBM вы не нашли описания IRLM из v9 и поэтому дали ссылку на v7

[iDesperado]

Несмотря на то что из последнего предложения следует что, да, эскалацию может вызвать нехватка памяти в lock list, мы так и не продвинулись ни на шаг к тому что же у Вас вызвало эту самую нехватку памяти. Так что же?

можете объяснить, что вам осталось не понятным из моего первого поста:

для дб2 логические локи зачастую нужней. лично у меня с детства выработалось табу на транзакции которые ожидают пользовательского ввода (zVlad вообще методично озвучивает мои табу в плане архитектуры ). а табу выработалось именно благодаря знакомству с дб2. была у нас система с дб2 под низом, там пользователь стартовал нехилую транзакцию и где-то посередине этой транзакции система что-то спрашивала у пользователя. если бы это был оракл может быть оно бы и прокатило, но это был дб2 ... стандартная ситуация была такой: пользователь знал, что транзакция длинная, жал на ее старт и шел курить, транзакция в час пик начинала эскалировать блокировки в плоть до блокировки всей таблицы и останавливалась ожидая ответа пользователя. в результате пол офиса с матом бегает по офису ища курильщика который вместо блокировки ему нужных пары записей останавливал работу всего подразделения.

ЗЫ. оракл никогда не блокирует больше чем необходимо

раз уж вы выяснили, что в LUW "эскалацию может вызвать нехватка памяти в lock list" ?

[zVlad]

Чтобы лучше понять этот принцип, скажите пожалуйста:
1. Каким образом было определено какой именно тикет (@TicketID) можно логически заблокировать?
2. Может ли так оказаться что предикат (BlockedBy IS NULL OR BlockedUntil<NowUTC() OR BlockedBy=@UserId) не вернет значение True? Что тогда? Что будет с этим предикатом если BlockedBy не нул, а BlockedUntil > NowUTC()
3. Что предполагается делать сразу после выполнения UPDATE - завершить транзакцию или нет?

1. Путем выборки из билетов. Например, пользователю был показан список доступных (не блокированных, или блокированных им самим, или с истекшей блокировкой).

Далее пользователь выбирает один из билетов, нажимает кнопку "Броня" и может думать покупать-не покупать на протяжении @locktime

2. Тогда данный билет недоступен. "если BlockedBy не нул, а BlockedUntil > NowUTC() " => билет заблокирован

3. Да, вполне можно завершать транзакцию "блокирование пользователем Х билета Y на время Z".

При такой организации можно элементарно ответить на вопрос "сколько некупленных, но забронированных билетов, имеется на рейс №123?". Или "когда истекает первая и последняя броня на рейс №124?". Или "отменить все блокировки сделанные пользователем Х на рейсы 200-250".

1. Поскольку, как я понимаю, на момент выборки билетов Вы ничего не блокируете, ни физически ни логически, то когда Ваш клиент кликнул на понравившийся ему билет этот билет запросто может оказаться уже логически заблокирован другим, более шустрым клиентом. И мы переходим к пункту 2.

2. И что дальше? Снова предложите клиенту выбирать билет из списка якобы доступных билетов?

3. Транзакцию завершили, клиент тоже ушел из системы (не нужен ему стал билет), а билет остается заблокирован. На 30 минут?

Да при такой организации легко делать то что Вы перечислили, но возникает вопрос, а зачем и кто и когда будет делать эти элементарные вещи. Вы хотите посадить человека-надсмотрщика над Вашей системой?

[crypto5]

ДБ2 v8 - SKIP LOCKED DATA

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

....

Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции UR.

The SKIP LOCKED DATA clause specifies that rows are skipped when incompatible locks are held on the row by other transactions. These rows can belong to any accessed table that is specified in the statement. SKIP LOCKED DATA can be used only with isolation CS or RS and applies only to row level or page level locks.

А можете обьяснить, чего конкретно я не понял? Потому что то что вы написали совершенно не противоречит моему примеру.

[crypto5]

.....

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

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

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

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

....

2. Пару секунд, секунду, пять секунд. Между нулем и 60 секундами примерно шестьдесят значений. Выбирайте любое на Ваш вкус.

То есть у вас будет разное время блокировки для собственно блокирования билета и проверки заблокирован ли он. В дб2 можно выставлять в программе время лока и/или таймаута транзакции?

[Dmitry67]

.....
Однако заявлять (притом с пафосом) 'на МФ/DB2 такой проблемы даже не возникает' ....

....

Дима, могу я Вас попросить приводить мои высказывания в достаточном объеме чтобы было понятно к чему вырванный Вами фрагмент относится. Ведь Вы же не станете утверждать ято я так сказал вообще, безотносительно чего-либо. О какой проблеме шла речь?

О локах.
Вы так и не привели решения.

Я ж сдался уже и приготовился анализировать ваши решения.

А единственное решение - логические локи
Их миллионы разных вариантов но все они примерно одни и те же, различаются меловчами и названиями полей
Один вариант тут показывает Zombie

[iDesperado]

То есть у вас будет разное время блокировки для собственно блокирования билета и проверки заблокирован ли он. В дб2 можно выставлять в программе время лока и/или таймаута транзакции?

в оракле можно писать так
select .. for update wait 60
или
select .. for update nowait

думаю в db2, что-то подобное есть.

[zVlad]

Хорошо, а откуда взялись 8М локов? И о чем это говорит?

из документа SAP, я уже цитировал выше "the IRLM private address space is 4 GB, IRLM can hold up to approximately 7900000 locks."

Вот Ваша цитата:

это не моя цитата, это цитата из ссылки приведенной вами ведущей на документацию db2/zOS v7
как я понял в чудесной документации IBM вы не нашли описания IRLM из v9 и поэтому дали ссылку на v7

Т.е. Вы сами не можете объяснить что следует из арифметического факта деления одного числа на другое в ответом ~ 8 миллионов. Ладно оставим это.

Я преводил там две ссылки. Одну из v9 другую из версии v7. Там же рассуждал о том что были времена 31 битовой организации адресации и 64 битовой сейчас. v7 был примером ограничений памяти с 31 битовой адресации, а v9 (документаци по v7, v8 и v9 находятся на одной странице: http://www-01.ibm.com/support/docview.w ... wg27011660 - ее не надо искать) с 64 битовой.
Ваши цитата, да, состоит из цитаты из дока, и из не понятно к чему относящимся взвизгом "читаю те же самые цифры:", хотя цифры (числа) как мы выясняли очень разные.

[Zombie416]

1. Поскольку, как я понимаю, на момент выборки билетов Вы ничего не блокируете, ни физически ни логически, то когда Ваш клиент кликнул на понравившийся ему билет этот билет запросто может оказаться уже логически заблокирован другим, более шустрым клиентом. И мы переходим к пункту 2.

2. И что дальше? Снова предложите клиенту выбирать билет из списка якобы доступных билетов?

3. Транзакцию завершили, клиент тоже ушел из системы (не нужен ему стал билет), а билет остается заблокирован. На 30 минут?

Да при такой организации легко делать то что Вы перечислили, но возникает вопрос, а зачем и кто и когда будет делать эти элементарные вещи. Вы хотите посадить человека-надсмотрщика над Вашей системой?

1,2. В самом простом варианте - да. Кто первый нажал, того и тапки. В зависимости от требований к системе правила можно менять.

3. Клиент ушел из системы сразу после запроса. Клиент сидит дома, а HTTP - простой протокол, и сессии к нему искусственно прикручивается.

Да, билет остался заблокирован. Или можно сделать что билет разблокируется при Logout. И один пользователь может заблокировать много билетов. Или до 5 билетов. Никакого надсмотрщика для этого не надо. И если билет 24 часа блокируется, не надо транзакцию на сервере подвешенной 24 часа держать.

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