JP Morgan Chase Oracle database outage

[zVlad]

....

Я не знаю что творится в Оракл с этим, и в MS SQL

Вы не знаете что творится, но вполне себе позволяете утверждать что "сам Оракл делает это как-то не очень"

Я сделал предположение на основании развернувшейся дискуссии по поводу "логических локов", которые я знаю не имеют отношение к ДБ2.

Еще раз - они(логические локи) имеют такое же отношение к ораклу как и к ДБ2.

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

[iDesperado]

Еще раз - они(логические локи) имеют такое же отношение к ораклу как и к ДБ2.

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

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

[crypto5]

....

Я не знаю что творится в Оракл с этим, и в MS SQL

Вы не знаете что творится, но вполне себе позволяете утверждать что "сам Оракл делает это как-то не очень"

Я сделал предположение на основании развернувшейся дискуссии по поводу "логических локов", которые я знаю не имеют отношение к ДБ2.

Еще раз - они(логические локи) имеют такое же отношение к ораклу как и к ДБ2.

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

Но как именно БД2 native локи способны решить выше описанные проблемы, вы никому не скажете

[iDesperado]

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

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

[zVlad]

- Во-первых при наступлении нежелательного события, связанного с локами (таймаут или дэдлок) DB2 выдает сообщение со всем необходимым что можно пожелать знать об этом:

Пример: Простая система с одной таблицей "Customers" и многими клерками, которые могут забивать туда информацию.

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

Принимая что запись блокируется на уровне базы:

Вопрос №1: сколько времени пройдет пока клерк №2 узнает что запись заблокирована и кем?

Вопрос №2: какое выражение лица будет у клерка №2 когда он увидит на экране подобное сообщение " со всем необходимым что можно пожелать "?

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

Ответ №1: В случае ДБ2 столько сколько установлено DBA в параметрах ДБ2. Это могут быть секунды, минуты. Иными словами столько сколько разумно для того или иного приложения.

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

[zVlad]

....- как дб2 native локи спасают от того что connection в connection пуле в j2ee приложении нельзя реюзать, пока лок не снят?
....

Я не Java программист и никогда им не был, поэтому мне нечего сказать по этому поводу кроме того что не думаю что в случае ДБ2 эта проблема (если она вообще имеет место быть) трудноразрешима.

Ну а вам не сложно было бы обьяснить что дает вам основания так думать?

Мне по этому вопросу нечего добавить. Мне кажется я все сказал.

[Zombie416]

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

В моей реальной жизни и с секретаршами разговаривают, и сами адреса меняют только так. И в реальной жизни, где вместо людей - компьютеры, такой пример вообще сплошь и рядом.

Но неважно, считайте пример абстрактным: великий босс сказал так надо, приказано выполнять. Причем требуемый результат работы в такой ситуации: клерк №2 должен сразу же сообщить тов. John Smith что его запись заблокирована 3 минуты назад, и попросить перезвонить позже. Сразу же. А если она уже 5 минут как заблокирована, то спросить в соседнем кубикле: "Вася, ты чего там John Smith-овый адрес заблокировал?".

Неприемлемый вариант: оставлять John Smith-а слушать elevator music в течение 20 минут (разумное время на то чтобы поменять адрес беседуя с клиентом, в который DBA поставил timeout), после чего ему сообщить "oops, my computer failed, let's try again".

И без логических блокировок обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL (который и версионник, и блокировочник на выбор).

[crypto5]

....- как дб2 native локи спасают от того что connection в connection пуле в j2ee приложении нельзя реюзать, пока лок не снят?
....

Я не Java программист и никогда им не был, поэтому мне нечего сказать по этому поводу кроме того что не думаю что в случае ДБ2 эта проблема (если она вообще имеет место быть) трудноразрешима.

Ну а вам не сложно было бы обьяснить что дает вам основания так думать?

Мне по этому вопросу нечего добавить. Мне кажется я все сказал.

Точнее ничего не сказали.

[iDesperado]

ЧТо касается точности отчетов. Мне сходу не привести пример когда это критично (прошу помощи у зала, в тяпницу голова плохо работает)

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

[zVlad]

Еще раз - они(логические локи) имеют такое же отношение к ораклу как и к ДБ2.

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

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

Мне очень жаль что когда Вы были младенцем (в смысле программирования) у Вас не было достаточно в рационе витамина D. Это так сказать литературный образ.
Вернемся к технике. Давным-давно существует правило что транзакции должны быть сделаны так чтобы они начинались после клика и заканчивались перед обновлением экрана. Вот это действительно табу, а то что Вы говорите табу - это недостаток ватимина D, извините.
Ну и по поводу "блокировки в плоть до блокировки всей таблицы". Снова Вы даете повод говорить что Ваши мозги промыты Оракловской пропагандой, которую я достаточно тщательно в свое время изучал. Это одна из излюбленных тем Оракла. Но дело в том что описанная Вами ситуация это не тот случай когда эскалация действительно может произойти. Эскалация возникает в процессе накопления блокировок (например в пакетном задании обрабатывающем большие количества данных), а не по ожиданию чего-то, для эскалации нужно движение, а не стояние.

[zVlad]

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

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

Покажите мне, пожалуйста, хоть один такой учебник, кроме написанного Вами конечно.

[zVlad]

....
И без логических блокировок обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL (который и версионник, и блокировочник на выбор).

Я готов с Вами согласиться, но в следущей редакции:

И без логических блокировок, некоторым программистам, обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL....

[Palych]

....
И без логических блокировок обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL (который и версионник, и блокировочник на выбор).

Я готов с Вами согласиться, но в следущей редакции:

И без логических блокировок, некоторым программистам, обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL....

А просто будет только тем программистам кто не будет писать программ где без логических блокировок не обойтись.

[zVlad]

....
И без логических блокировок обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL (который и версионник, и блокировочник на выбор).

Я готов с Вами согласиться, но в следущей редакции:

И без логических блокировок, некоторым программистам, обойтись будет непросто. Хоть в DB2, хоть в Oracle, хоть в MS SQL....

А просто будет только тем программистам кто не будет писать программ где без логических блокировок не обойтись.

[Zombie416]

Я готов с Вами согласиться, но в следущей редакции:

Ну вот и славно. Т.е. как обойтись чисто блокировками на уровне базы вы, на конкретном примере, не знаете. И я не знаю.

Возможно, есть программисты на DB2 (обязательно исполняемой на zOS) в вакууме которые знают, и пишут такие системы. Но существование ни таких программистов, ни таких таких систем, ни доказать, ни опровергнуть невозможно. Можно только верить. Правильно?

[zVlad]

Я готов с Вами согласиться, но в следущей редакции:

Ну вот и славно. Т.е. как обойтись чисто блокировками на уровне базы вы, на конкретном примере, не знаете. И я не знаю.

Возможно, есть программисты на DB2 (обязательно исполняемой на zOS) в вакууме которые знают, и пишут такие системы. Но существование ни таких программистов, ни таких таких систем, ни доказать, ни опровергнуть невозможно. Можно только верить. Правильно?

Лучше чем сказал Palych я сказать не смогу (см. выше), да и не надо - краткость сестра таланта.

[Zombie416]

Лучше чем сказал Palych я сказать не смогу (см. выше)

Да, похоже на то. Хотя казалось бы: простой пример, всего одна таблица, элементарная задача. "Не дает ответа..."

[zVlad]

Я готов с Вами согласиться, но в следущей редакции:

Ну вот и славно. Т.е. как обойтись чисто блокировками на уровне базы вы, на конкретном примере, не знаете. И я не знаю.
.....

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

[crypto5]

Я готов с Вами согласиться, но в следущей редакции:

Ну вот и славно. Т.е. как обойтись чисто блокировками на уровне базы вы, на конкретном примере, не знаете. И я не знаю.
.....

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

Остралось выяснить какое отношение имеет ваш конкретный пример к конкретному примеру зомби

[zVlad]

Лучше чем сказал Palych я сказать не смогу (см. выше)

Да, похоже на то. Хотя казалось бы: простой пример, всего одна таблица, элементарная задача. "Не дает ответа..."

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

[Zombie416]

А я говорил (повторяю для Вас) что программисты в ДБ2 для МФ вообще ничего не знают о блокировках. Они пишут программы, а МФ с ДБ2 эти программы выполняет как то и все довольны.

Ну и некоторые программисты на MS SQL (в блокировочном режиме) ничего не знают о блокировках, пишут программы и они работают "как-то". Пока гром не грянет. Если железо мощное, а объемы небольшие - может и не грянуть никогда.

Но речь в конкретном примере была про ситуацию в которой "как-то", когда John Smith будет 20 минут слушать elevator music, занимать телефонную линию и оплачиваемое ухо клерка, чтобы потом получить Ooops по непонятной причине, неприемлема изначально. О блокировке надо узнать мгновенно, и также узнать кто заблокировал и сколько еще ждать (в худшем случае). Такая задача, и которая, практически, без John Smith-oв и клерков, встречается постоянно.

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

[iDesperado]

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

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

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

судя по всему вы совершенно не понимаете, что вам говорят. кроме этого вы явно не понимаете как работает субд дб2. для того чтоб нарваться на эскалацию в дб2 пакетному заданию совершенно не обязательно обрабатывать большие данные, достаточно попробовать наложить блокировку на небольшой набор записей в момент когда конкурирующие транзакции исчерпали "lock space". что касается движения, попробуйте сконцентрироваться:
update .. where payment_date between ...
вопрос пользователю: обнаружены авансовые платежи, будем делать их перерасчет ? да / нет

так вот на вопросе пользователя может быть два варианта: апдейту хватило места в "lock space" и залочилось ровно столько записей, сколько попадает под условие where, а в час пик могло и не хватить и благодаря эскалации залочилось значительно больше строк.

[iDesperado]

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

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

[crypto5]

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

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

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

[zVlad]

....

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

судя по всему вы совершенно не понимаете, что вам говорят. кроме этого вы явно не понимаете как работает субд дб2. для того чтоб нарваться на эскалацию в дб2 пакетному заданию совершенно не обязательно обрабатывать большие данные, достаточно попробовать наложить блокировку на небольшой набор записей в момент когда конкурирующие транзакции исчерпали "lock space". что касается движения, попробуйте сконцентрироваться:
update .. where payment_date between ...
вопрос пользователю: обнаружены авансовые платежи, будем делать их перерасчет ? да / нет

так вот на вопросе пользователя может быть два варианта: апдейту хватило места в "lock space" и залочилось ровно столько записей, сколько попадает под условие where, а в час пик могло и не хватить и благодаря эскалации залочилось значительно больше строк.

Ладно я не стану Вас пугать тем что Вы пытаетесь нагнуть IBM certified Solution Expert (сертификат могу предъявить если не верите). Я просто попрошу Вас прочитать два фрагмента ДБ2 документации:

http://publib.boulder.ibm.com/cgi-bin/b ... 4234&CASE=
и

http://publib.boulder.ibm.com/cgi-bin/b ... 4#HDRLKMAX

или просто прочитайте и вникните вот в эту цитату (из второй ссылки):

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 и вовсе нет. Не зря Вы взяли его в кавычки - теперь можете попробовать отмазаться.