JP Morgan Chase Oracle database outage

[zVlad]

Мне очень жаль что когда Вы были младенцем (в смысле программирования) у Вас не было достаточно в рационе витамина D. Это так сказать литературный образ.

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

.....

Согласен, приношу извинения - не сдержался. Вернемся на поле технической дискуссии.

[iDesperado]

Проблема описанная в примере зомби не может быть решена простой докупкой мощностей.

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

[zVlad]

Расскажите пожалуйста решение без логических блокировок. Ведь вы утверждали что оно существует, поэтому оные логические блокировки в DB2/zOS не нужны?

на самом деле на МФ они действительно не нужны, zVlad совершенно верно описал как там пишется софт. они просто пишут софт, там не замарачиваются с коннекшен пулами, стейтлес апликациями, им это не нужно. если апликация тормозит они просто докупают копасити к МФ и проблема решена.

Не совсем так. На самом деле после того как поработали программисты и аппликуха пошла в продакшн проблемы переходят к DB2 DBA и он/она начинают изгалятся на предмет как бы так сделать чтобы аппликуха работала нормально без того чтобы просить программиста ее переписать нормально. В основном это удается, но иногда все таки приходится взывать к совести программиста, проводить ликбез и т.п.

[iDesperado]

LOCKMAX n
Specifies the maximum number of page or row locks that a single application process can hold on the table space before those locks are escalated as described in "Lock escalation" in topic 5.7.4.5.3. ....

А понятия "lock space" в ДБ2 и вовсе нет. Не зря Вы взяли его в кавычки - теперь можете попробовать отмазаться.

If maxlocks is set too low, lock escalation happens when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume most of the lock space, and other applications will have to perform lock escalation. The need for lock escalation in this case results in poor concurrency.
http://publib.boulder.ibm.com/infocente ... 000268.htm

[Palych]

Расскажите пожалуйста решение без логических блокировок. Ведь вы утверждали что оно существует, поэтому оные логические блокировки в DB2/zOS не нужны?

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

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

[Zombie416]

Кстати поиск в Google по словосочетанию "логическая блокировка" дает очень бедный урожай. Можете убедиться сами.

Да чего мне убеждаться и искать правильное словосочетание?

Ладно, мой пример вам не нравится, секретарши не звонят, джона смита не бывает, нереально. Хорошо, я перефразирую. Вам вроде нравились покупки авиабилетов, когда вы дома на вебсайте покупаете билет, и оно вам находит конкретный билет и говорит: в течение 30 минут или покупаете, или все сначала. Но в эти 30минут этот ваш конкретный билет можете купить только вы. Так?

Для простоты дела, предположим что все доступные билеты лежат в таблице вроде Tickets( TicketID, FlightId, Place, Price ) . Все это, для простоты дела опять, лежит в единственной DB2/zOS/IBM/MF базе со стописятпиццот процессоров, поддерживаемых грамотными сертифицированными DBA-ями, к которой базе напрямую подключен некий вебсервис. Теперь допустим что в базе единственная запись, #123 YYZ->FRA, рейс X222, место B15.

Вы сидите дома, из браузера заходите на этот вебсервис, блокируете этот билет на 30 минут в 12:00, т.е. до 12:30. При этом я тоже захожу в 12:05, и пытаюсь купить тот же билет. Что при этом происходит? Как происходит блокировка?

[iDesperado]

If maxlocks is set too low, lock escalation happens when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume most of the lock space, and other applications will have to perform lock escalation. The need for lock escalation in this case results in poor concurrency.
http://publib.boulder.ibm.com/infocente ... 000268.htm

хи-хи, а теперь сравните поведение db2/zOS
Alternatively, if lock escalation is a problem, use LOCKMAX 0 to disable
| lock escalation. However, acquiring too many locks can cause DB2 to fail
| if IRLM runs out of storage for the locks.

т.е. там где LUW начнет нещадно эскалировать, мегонадежный zOS начнет fail'ить
это еще к вопросу одинаковости db2 на разных платформах

[zVlad]

LOCKMAX n
Specifies the maximum number of page or row locks that a single application process can hold on the table space before those locks are escalated as described in "Lock escalation" in topic 5.7.4.5.3. ....

А понятия "lock space" в ДБ2 и вовсе нет. Не зря Вы взяли его в кавычки - теперь можете попробовать отмазаться.

If maxlocks is set too low, lock escalation happens when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume most of the lock space, and other applications will have to perform lock escalation. The need for lock escalation in this case results in poor concurrency.
http://publib.boulder.ibm.com/infocente ... 000268.htm

Увы, но это не ДБ2 на МФ, в zOS. На zOS другой подход и MAXLOCKS измерятся в количестве локов, а не в процентах.

[zVlad]

If maxlocks is set too low, lock escalation happens when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume most of the lock space, and other applications will have to perform lock escalation. The need for lock escalation in this case results in poor concurrency.
http://publib.boulder.ibm.com/infocente ... 000268.htm

хи-хи, а теперь сравните поведение db2/zOS
Alternatively, if lock escalation is a problem, use LOCKMAX 0 to disable
| lock escalation. However, acquiring too many locks can cause DB2 to fail
| if IRLM runs out of storage for the locks.

т.е. там где LUW начнет нещадно эскалировать, мегонадежный zOS начнет fail'ить
это еще к вопросу одинаковости db2 на разных платформах

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

[iDesperado]

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

acquiring too many locks can cause DB2 to fail, я не вижу связи с 0, кроме того что вероятность этого fail c 0 много выше.

[iDesperado]

кстати возвращаясь к моей ситуации с "update .. where payment_date between ..."
выходит там где LUW почуяв попу проэскалировал до блокировки таблицы, zOS эскалировать не станет т.к. запрос не привысил LOCKMAX и при нехватки памяти под "storage for the locks" никакой защиты нет.
судя по документации в этой ситуации под zOS я бы получил краш всей субд. мило.

[zVlad]

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

acquiring too many locks can cause DB2 to fail, я не вижу связи с 0, кроме того что вероятность этого fail c 0 много выше.

С ненулевым значением LOCKMAX вероятность fail равна нулю. Как Вы этого не понимаете? А в 64-битовой архитектуре и с LOCKMAX 0 дела не так плохи как Вам хочется.

[zVlad]

кстати возвращаясь к моей ситуации с "update .. where payment_date between ..."
выходит там где LUW почуяв попу проэскалировал до блокировки таблицы, zOS эскалировать не станет т.к. запрос не привысил LOCKMAX и при нехватки памяти под "storage for the locks" никакой защиты нет.
судя по документации в этой ситуации под zOS я бы получил краш всей субд. мило.

"storage for the locks" защищена несколькими лимитами которые наступают задолго до наступления нехватки памяти для локов.
Вы неправильно понимаете документацию и практику работы под zOS. Чисто из моего опыта: желаемые Вами страсти я ни разу видел. Другие были, но вот с локами как-то все на удивление безпроблемно происходит. Программисты жалуются иногда что их то или иное ограничение останавливает, но при разборке полетов выясняется что они просто не утруждают себя оценкой чего и сколько им будет надо и как сделать чтобы не нарываться на ограничения. При этом я точно знаю что наши ограничения сильно зажаты и их можно было бы существенно ослабить. Но зачем?

[zVlad]

If maxlocks is set too low, lock escalation happens when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume most of the lock space, and other applications will have to perform lock escalation. The need for lock escalation in this case results in poor concurrency.
http://publib.boulder.ibm.com/infocente ... 000268.htm

хи-хи, а теперь сравните поведение db2/zOS
Alternatively, if lock escalation is a problem, use LOCKMAX 0 to disable
| lock escalation. However, acquiring too many locks can cause DB2 to fail
| if IRLM runs out of storage for the locks.

т.е. там где LUW начнет нещадно эскалировать, мегонадежный zOS начнет fail'ить
это еще к вопросу одинаковости db2 на разных платформах

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

[crypto5]

Проблема описанная в примере зомби не может быть решена простой докупкой мощностей.

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

Никто не говорил про 2-ух звенную систему, это вполне себе может быть web application, который ходит в БД используя всего лишь один username который конечно не совпадает с username пользователя залочившего документ, и таких пользователей может быть не несколько, а десятки тысяч, и поэтому нужно делать еще скрины менеджерам, которые смогут снимать локи юзеров, ушедших домой и забывших закрыть документ, не дожидаясь таймаута лока, который тоже может устанавливаться менеджером для его подразделения через веб интерфейс.
С помощью логических локов вся БД логика уместится в десяток тривиальных и переносимых SQL запросов, а в вашем подходе какова будет сложность решения, если оно вообще существует?

[Dmitry67]

Вообще да, для старых добрых старых аппликаций, где каждый пользователь входит в базу со своего компьютера, под своим логином... Эх, времена... Первое время от Web аппликаций я был в шоке. Тем не менее это реальность. Интересно, какие есть примеры крупных Web имеющих как backend DB2 (и какую?)

[Dmitry67]

Курьезно
http://en.wikipedia.org/wiki/IBM_DB2

In 2009, it was announced that DB2 can be an engine in MySQL.

Надо Борису посоветовать

[zVlad]

Кстати поиск в Google по словосочетанию "логическая блокировка" дает очень бедный урожай. Можете убедиться сами.

Да чего мне убеждаться и искать правильное словосочетание?

Ладно, мой пример вам не нравится, секретарши не звонят, джона смита не бывает, нереально. Хорошо, я перефразирую. Вам вроде нравились покупки авиабилетов, когда вы дома на вебсайте покупаете билет, и оно вам находит конкретный билет и говорит: в течение 30 минут или покупаете, или все сначала. Но в эти 30минут этот ваш конкретный билет можете купить только вы. Так?

Для простоты дела, предположим что все доступные билеты лежат в таблице вроде Tickets( TicketID, FlightId, Place, Price ) . Все это, для простоты дела опять, лежит в единственной DB2/zOS/IBM/MF базе со стописятпиццот процессоров, поддерживаемых грамотными сертифицированными DBA-ями, к которой базе напрямую подключен некий вебсервис. Теперь допустим что в базе единственная запись, #123 YYZ->FRA, рейс X222, место B15.

Вы сидите дома, из браузера заходите на этот вебсервис, блокируете этот билет на 30 минут в 12:00, т.е. до 12:30. При этом я тоже захожу в 12:05, и пытаюсь купить тот же билет. Что при этом происходит? Как происходит блокировка?

Вы что никогда не покупали авиабилеты по интернет? Билеты изначально продаются на рейс, места резервируются дополнительно. Пока один держит билет или место другому его не покажут и другой не сможет даже сказать "хочу". Если за отведененное время (обычно 15 минут) решение не было принято, то билет (место) вернется в пул доступных для продажи билетов (мест). Просто снимется блокировка.

[zVlad]

Курьезно
http://en.wikipedia.org/wiki/IBM_DB2

In 2009, it was announced that DB2 can be an engine in MySQL.

Надо Борису посоветовать

А че Вы второе то предложение не скопировали?

...This allows users on the System i platform to natively access the DB2 under the IBM i operating system (formerly called OS/400), and for users on other platforms to access these files thru the MySQL interface.

У Бориса, я так полагаю, не System i platform стоит.

[zVlad]

Вообще да, для старых добрых старых аппликаций, где каждый пользователь входит в базу со своего компьютера, под своим логином... Эх, времена... Первое время от Web аппликаций я был в шоке. Тем не менее это реальность. Интересно, какие есть примеры крупных Web имеющих как backend DB2 (и какую?)

Есть веб аппликации стоящие непосредственно на МФ, т.е. прямо из паутины вы попадаете на МФ.
К аппликации, которую я саппортаю, клиенты имеют доступ через микрософтовский IIS и Java (но это только фронтэнд). В следующей версии аппликухи это будет делаться через WebSphere (надеюсь WS будет стоять на МФ).

[Zombie416]

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

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

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

[zVlad]

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

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

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

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

[zVlad]

Средствами DB2 и чего-то-там с очередной нечитаемой многобуквенной аббревиатурой большими буквами заблокирована запись?

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

[Palych]

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

То есть: каждый раз когда кто-то заходит на сайт - открывается соединение с базой, и пока пользователь не уйдёт остаётся открытым?

[crypto5]

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

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

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

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

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