JP Morgan Chase Oracle database outage

zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

iDesperado wrote:
crypto5 wrote: То есть у вас будет разное время блокировки для собственно блокирования билета и проверки заблокирован ли он. В дб2 можно выставлять в программе время лока и/или таймаута транзакции?
в оракле можно писать так
select .. for update wait 60
или
select .. for update nowait

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

Искал, тоже так думал, но вместо этого нашел SKIP LOCKED DATA. Подумав понял что это даже лучше для ДБ2 по крайней мере. В самом деле - чего ждать то? да и сколько ждать? Дело еще в том что если запрос выполняется с уровнем изоляции cursor stability то что ж ждать на каждой залоченой строке - не годится явно.
Для Оракл, видимо, лучше wait.

А что собственно предполагается в Оракл ждать в этой конструкции? Уж не освобождения ли залоченного ресурса? А что произойдет в случае nowait?
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

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

....
Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции 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.
А можете обьяснить, чего конкретно я не понял? Потому что то что вы написали совершенно не противоречит моему примеру.
Ну а вот так понятней - сопоставьте выделенное мной в Вашем описании и из дока.
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

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

....
Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции 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.
А можете обьяснить, чего конкретно я не понял? Потому что то что вы написали совершенно не противоречит моему примеру.
Ну а вот так понятней - сопоставьте выделенное мной в Вашем описании и из дока.
Вы забыли выделить что скипнутыми будут только строки залоченные с помощью incompatible locks
In vino Veritas!
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

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

....
Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции 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.
А можете обьяснить, чего конкретно я не понял? Потому что то что вы написали совершенно не противоречит моему примеру.
Ну а вот так понятней - сопоставьте выделенное мной в Вашем описании и из дока.
Вы забыли выделить что скипнутыми будут только строки залоченные с помощью incompatible locks
И что это меняет? Перечитайте мое предложение в середины цитаты по поводу UR.
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

zVlad wrote:
crypto5 wrote:
zVlad wrote:
crypto5 wrote:
zVlad wrote: Вы неверно поняли как это работает. То как Вы описали возможно давно с уровнем изоляции UR.
А можете обьяснить, чего конкретно я не понял? Потому что то что вы написали совершенно не противоречит моему примеру.
Ну а вот так понятней - сопоставьте выделенное мной в Вашем описании и из дока.
Вы забыли выделить что скипнутыми будут только строки залоченные с помощью incompatible locks
И что это меняет? Перечитайте мое предложение в середины цитаты по поводу UR.
Вы можете не ходя вокруг да около сказать какой шаг в моем примере неправилен и почему? Не люблю знаете ли играть в загадки.
In vino Veritas!
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: JP Morgan Chase Oracle database outage

Post by iDesperado »

zVlad wrote: Т.е. Вы сами не можете объяснить что следует из арифметического факта деления одного числа на другое в ответом ~ 8 миллионов. Ладно оставим это.
для тех кто не понял, более 4Gb на 8М локов взято из документа SAP, а именно из фразы "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.."
7900000 * 540 байт (для версии v9.1) = 4.1Gb вполне сходиться с данными документации по db2/zOS v9.1:
You can estimate the IRLM control block structure at 540 bytes per lock. IRLM no longer supports placing locks in ECSA. All IRLM locks are now placed in the IRLM private address space.
http://publib.boulder.ibm.com/infocente ... stgreq.htm
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: JP Morgan Chase Oracle database outage

Post by iDesperado »

zVlad wrote: А что собственно предполагается в Оракл ждать в этой конструкции? Уж не освобождения ли залоченного ресурса? А что произойдет в случае nowait?
подождать 60 секунд пока строка разлочится, на 61 секунде выдаст ORA-xxxx resource busy
при nowait выдаст сразу ORA-xxxx resource busy

ЗЫ. sckip locked в оракле тоже есть, но не докумкентирован, а значит не рекомендован к использованию. инсайдеры говорят Advanced Quenes используют такую конструкцию.
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

crypto5 wrote:....Вы можете не ходя вокруг да около сказать какой шаг в моем примере неправилен и почему? Не люблю знаете ли играть в загадки.
Но ведь сделать Ваше первое, не верное, предположение Вы не просили ни чьей помощи. Что случилось? Я и так Вам все что можно разжевал, проглотите уж?
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

zVlad wrote:
crypto5 wrote:....Вы можете не ходя вокруг да около сказать какой шаг в моем примере неправилен и почему? Не люблю знаете ли играть в загадки.
Но ведь сделать Ваше первое, не верное, предположение Вы не просили ни чьей помощи. Что случилось? Я и так Вам все что можно разжевал, проглотите уж?
Понятно, по сути как это часто бывает обьяснений недождемся, сплошной тролизм.
In vino Veritas!
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

iDesperado wrote:
zVlad wrote: Т.е. Вы сами не можете объяснить что следует из арифметического факта деления одного числа на другое в ответом ~ 8 миллионов. Ладно оставим это.
для тех кто не понял, более 4Gb на 8М локов взято из документа SAP, а именно из фразы "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.."
7900000 * 540 байт (для версии v9.1) = 4.1Gb вполне сходиться с данными документации по db2/zOS v9.1:
You can estimate the IRLM control block structure at 540 bytes per lock. IRLM no longer supports placing locks in ECSA. All IRLM locks are now placed in the IRLM private address space.
http://publib.boulder.ibm.com/infocente ... stgreq.htm
Против арифметики не было никаких возражений. Что дальше то? Сколько локов на самом деле требуется и от чего это зависит - вот о чем можно было бы поговорить, а мы застряли на том что память для МФ стоит сумашедшие деньги.
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

iDesperado wrote:
zVlad wrote: А что собственно предполагается в Оракл ждать в этой конструкции? Уж не освобождения ли залоченного ресурса? А что произойдет в случае nowait?
подождать 60 секунд пока строка разлочится, на 61 секунде выдаст ORA-xxxx resource busy
при nowait выдаст сразу ORA-xxxx resource busy

ЗЫ. sckip locked в оракле тоже есть, но не докумкентирован, а значит не рекомендован к использованию. инсайдеры говорят Advanced Quenes используют такую конструкцию.
Так значит проблема с локами в Оракл тоже есть? Ах какая досада, а я то так понимал Вас и других здешних знатоков что в Оракл таких проблем нет.
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: JP Morgan Chase Oracle database outage

Post by iDesperado »

zVlad wrote: Против арифметики не было никаких возражений. Что дальше то? Сколько локов на самом деле требуется и от чего это зависит - вот о чем можно было бы поговорить, а мы застряли на том что память для МФ стоит сумашедшие деньги.
дальше я озвучу после того как вы выключите режим тролинга на примере логической блокировки.
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

iDesperado wrote:
zVlad wrote: Против арифметики не было никаких возражений. Что дальше то? Сколько локов на самом деле требуется и от чего это зависит - вот о чем можно было бы поговорить, а мы застряли на том что память для МФ стоит сумашедшие деньги.
дальше я озвучу после того как вы выключите режим тролинга на примере логической блокировки.
Не понял. О чем Вы?
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: JP Morgan Chase Oracle database outage

Post by Dmitry67 »

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

Dmitry67 wrote:так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?
Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

zVlad wrote:
Dmitry67 wrote:так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?
Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.
Их здесь сотни, нет тысячи :lol:
In vino Veritas!
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

crypto5 wrote:
zVlad wrote:
Dmitry67 wrote:так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?
Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.
Их здесь сотни, нет тысячи :lol:
Пока вижу только троих.
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

zVlad wrote:
crypto5 wrote:
zVlad wrote:
Dmitry67 wrote:так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?
Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.
Их здесь сотни, нет тысячи :lol:
Пока вижу только троих.
Жена звонит мужу на мобильный:
- Алло, ты где?
- Я в машине, на садовом.
- Ты там осторожнее, по телевизору показывают - там какой-то сумасшедший по встречной полосе едет!!!
- Ты не поверишь, их здесь сотни, нет тысячи!!!
In vino Veritas!
Zombie416
Уже с Приветом
Posts: 8881
Joined: 17 Jun 2003 04:41

Re: JP Morgan Chase Oracle database outage

Post by Zombie416 »

zVlad wrote:Так значит проблема с локами в Оракл тоже есть? Ах какая досада, а я то так понимал Вас и других здешних знатоков что в Оракл таких проблем нет.
А в чем состоит проблема-то? Ну да, можно таймаут указать в команде, хоть в Oracle, хоть в MS SQL, хоть в MySQL. Толку-то.

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:
логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.
Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно :)
zVlad
Уже с Приветом
Posts: 15314
Joined: 30 Apr 2003 16:43

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

Zombie416 wrote:....

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:
логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.
Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно :)
Хорошо. Давайте попробуем спуститься на уровень Ваших примеров. Не судите строго если мой пример Вам тоже покажется наивным.

1. Делаем раз (выбираем "свободные" тикеты на запрошенный рейс):

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA
2. Даем клиенту выбрать интересующий его тикет, и выдаем в ответ на его выбор:

Code: Select all

SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE
RDBMS накладывает 1 (один) лок на одну строку.

3. Coобщаем клиенту что у него 15 минут чтобы купить понравившийся ему билет и запускаем счетчик (по времени). Клиент принимает решение. Мы завершаем UPDATE и заканчиваем транзакцию. Локи в количестве 1 (одна) штука удаляется.

Если посмотреть не так предвязато как это любят мои "единомышленники" здесь на форуме, то получается ровным счетом тоже самое что и в Вашем примере, только проще и с большим автоматизмом, т.к. никаких исключительных ситуаций обрабатывать (пусть даже "элементарно") не нужно, все сделает RDBMS.
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: JP Morgan Chase Oracle database outage

Post by iDesperado »

2zVlad

1.если у вас уровень Read Commited в шаге 2 вы получите эксепшен, т.к. пока клиент раздумывал запись которую выбрал клиент могли заблокировать конкурирующие транзакции
если у вас уровень выше, вы в шаге 1 заблокировали на 15 минут все свободные билеты.

2. как вы вебного пользователя собрались связывать с транзакцией субд ?
User avatar
crypto5
Уже с Приветом
Posts: 4637
Joined: 24 Oct 2009 01:38
Location: Chicago ;-) -> SFBA!

Re: JP Morgan Chase Oracle database outage

Post by crypto5 »

zVlad wrote:
Zombie416 wrote:....

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:
логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.
Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно :)
Хорошо. Давайте попробуем спуститься на уровень Ваших примеров. Не судите строго если мой пример Вам тоже покажется наивным.

1. Делаем раз (выбираем "свободные" тикеты на запрошенный рейс):

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA
2. Даем клиенту выбрать интересующий его тикет, и выдаем в ответ на его выбор:

Code: Select all

SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE
RDBMS накладывает 1 (один) лок на одну строку.

3. Coобщаем клиенту что у него 15 минут чтобы купить понравившийся ему билет и запускаем счетчик (по времени). Клиент принимает решение. Мы завершаем UPDATE и заканчиваем транзакцию. Локи в количестве 1 (одна) штука удаляется.

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

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA
то он увидит залоченный билет, потому что операция select чтения является compatible с локом записи, который вы поставили используя select ... for update.

ну и присоединяюсь к вопросам iDesperado
In vino Veritas!
sp123
Уже с Приветом
Posts: 1962
Joined: 24 Feb 2001 10:01
Location: Челябинск -> Everett, WA

Re: JP Morgan Chase Oracle database outage

Post by sp123 »

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

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

Re: JP Morgan Chase Oracle database outage

Post by zVlad »

iDesperado wrote:2zVlad

1.если у вас уровень Read Commited в шаге 2 вы получите эксепшен, т.к. пока клиент раздумывал запись которую выбрал клиент могли заблокировать конкурирующие транзакции
если у вас уровень выше, вы в шаге 1 заблокировали на 15 минут все свободные билеты.

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

2. Не знаю. Никогда этим не занимался. Как то делается.
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: JP Morgan Chase Oracle database outage

Post by iDesperado »

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

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
Last edited by iDesperado on 27 Sep 2010 20:19, edited 1 time in total.

Return to “Вопросы и новости IT”