JP Morgan Chase Oracle database outage

[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.

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