JP Morgan Chase Oracle database outage

[iDesperado]

Ну, справедливсти ради, zVlad - сисадмин и DBA в традиционной enterprise application, а не архитектор. Поэтому об особенностях разработки веб-приложений может не знать. Точно так же, как девелопера нельзя подпускать к администрированию production железяки, хотя у него тоже есть кое-какой опыт .

ну немного выше zVlad писал так:

Программисты для ДБ2 на МФ вообще мало что знают о локах и как правило используют накатанные подходы не особо вдумываясь в них. В результате нам, DBA, порой приходится с программистами проводить разъяснительную работу о том что надо делать чтобы не только написать программу, но и сделать так чтобы программа работала эффективно в многопользовательской среде выполнения.

[sp123]

Вот и Вы говорите что "чтобы было кул, и DB2 в это ну никак не вписывается.". Почему не вписывается? Что нужно такое кул от БД чтобы молодое поколение интересовалось такого что нет в ДБ2? Очередной миф.

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит. А вот замутить что-нибудь на бесплатном mysql или там postgres в гараже - это нынче самое то, та самая струя.

Если у Вашего перца основной бэкграунд это Оракл (а это видимо так раз Вы его интервьюировали), то ничего удивительного. И более того глупо, хотя бы потому что к ДБ2 можно коннектиться и выполнять запросы с любого софтвэра, работающего с ODBC или JDBC. Я бы такого "специалиста" даже не рассмотривал бы. Это не специалист.Вот вам еще один миф о ДБ2 на МФ. Свежеиспеченный.

Перец решений не принимал, его дело было контракторское. На мой вопрос - а нахерна, собсно, было огород городить, даже слегка удивился - мне, пол, приказали грузить вот этот файл вон туда и обсчитывать данные так-то и так-то, я это и делал в течение месяца. Компания занимается финансовыми операциями, имеет старую большую систему на MF, и там наверняка есть подготовленные кадры. Почему они не смогли убедить руководство, что справятся сами, история умалчивает. Может, "ресурсов не хватило". А может, виной тому мифы, летающие по конторе. Так тоже бывает. Но в обычных условиях мифы очень легко разбиваются конкретными примерами. Типа, надо вам вот такой функционал соорудить за вот такое время - вот вам живые цифры и результаты. Видимо, не смогли.

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

[zVlad]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

[Dim LEO]

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит.

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

[sp123]

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

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

[Dim LEO]

дико извиняюсь , а в чем Oracle не катит (кроме стоимости) интересно?

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

понятно, спасибо

[zVlad]

Вот и Вы говорите что "чтобы было кул, и DB2 в это ну никак не вписывается.". Почему не вписывается? Что нужно такое кул от БД чтобы молодое поколение интересовалось такого что нет в ДБ2? Очередной миф.

А тут дело не в технических особенностях баз данных. Молодежи хочется стартап организовать и стать миллионерами, а-ля facebook. Про подобные проекты на mysql они слышали много, а вот на MF/DB2 - не очень. Или просто им хочется сделать карьеру, попав в струю. И в качестве струи рассматривать MF/DB2 они не будут. Да и Oracle уже не всегда катит. А вот замутить что-нибудь на бесплатном mysql или там postgres в гараже - это нынче самое то, та самая струя.

Если у Вашего перца основной бэкграунд это Оракл (а это видимо так раз Вы его интервьюировали), то ничего удивительного. И более того глупо, хотя бы потому что к ДБ2 можно коннектиться и выполнять запросы с любого софтвэра, работающего с ODBC или JDBC. Я бы такого "специалиста" даже не рассмотривал бы. Это не специалист.Вот вам еще один миф о ДБ2 на МФ. Свежеиспеченный.

Перец решений не принимал, его дело было контракторское. На мой вопрос - а нахерна, собсно, было огород городить, даже слегка удивился - мне, пол, приказали грузить вот этот файл вон туда и обсчитывать данные так-то и так-то, я это и делал в течение месяца. Компания занимается финансовыми операциями, имеет старую большую систему на MF, и там наверняка есть подготовленные кадры. Почему они не смогли убедить руководство, что справятся сами, история умалчивает. Может, "ресурсов не хватило". А может, виной тому мифы, летающие по конторе. Так тоже бывает. Но в обычных условиях мифы очень легко разбиваются конкретными примерами. Типа, надо вам вот такой функционал соорудить за вот такое время - вот вам живые цифры и результаты. Видимо, не смогли.

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

Я думаю что все таки есть разная молодежь. Одни хотят из гаража в миллионеры выйти. Другие хотят серьезными делами держать синицу в руках.

Ситуация когда нанимают контракторов при наличии собственных ресурвов известна и распространена. Те, кто сидит постоянно как правило не реагируют ни на какие изменения в работе, им невозможно объяснить почему они должны сегодня делать то что не делали вчера или год назад. Многие люди в динамичной компьютерной сфере ведут себя как те на конвейерах. На МФ таких больше, просто потому что МФ дольше. Пройдет время и такие же будут на РС. На Оракл уже таких до вала. Да и в Юникс саппорте тоже. Будут и на MySQL.

P.S. кстати на МФ для молодежи (и я уже об этом много раз говорил) открывается прекрасная перспектива роста потому что идет смена поколений. Да и насчет интересности я бы поспорил. Интересно хотя бы потому что нет предела для освоения нового. И не такого нового как скажем на РС где просто одна и та же тема с разной глубиной реализуется в десятках продуктах по сути повторяя одно и тоже многократно. В zOS есть одна компонента для работы со storage (диски, ленты, иерархическая сторидж), но эту компоненту можно годами изучать и будешь находить новое. У нас двое в компании на этом только и работают. Двое осталось и на все системные работы по всем (двум) МФ, включая ДБ2 и аппликэйшн сервера и сети и секьюрити и WebSphere и Юникс и Линукс и мониторинг, все кроме собственно прикладных программ. Молодому у нас раздолье бы было для развития, многие бы позавидовали.

[Dim LEO]

IMHO "старики" не хотят потерять специализацию и по моему правильно делают

[zVlad]

IMHO "старики" не хотят потерять специализацию и по моему правильно делают

Я старик, но мне несовсем понятно что Вы имеете в виду.

[crypto5]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

А ниче что там в шапке написано: DB2 UDB for z/OS Version 8?

[crypto5]

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

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

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

Мифы о МФ распростроняет Оракл и Микрософт.

А себя вы посавить в этот ряд почему поскромничали?

[zVlad]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

А ниче что там в шапке написано: DB2 UDB for z/OS Version 8?

Точно. Вы уже оказывается вышли на нормальную документациюю Первоначально iDesperado точно ссылался на LUW. А эти ссылки я не смотрел. В чем же проблема тогда у вас, парни?

http://publib.boulder.ibm.com/infocente ... ements.htm

[crypto5]

в чуднОй документации разобраться тяжело но судя по этому

When FOR UPDATE is used, FETCH operations referencing the cursor acquire U or X locks rather than S locks when:

* The isolation level of the statement is cursor stability.
* The isolation level of the statement is repeatable read or read stability and field U LOCK FOR RR/RS on installation panel DSNTIPI is set to get U locks.
* |The isolation level of the statement is repeatable |read or read stability and USE AND KEEP EXCLUSIVE LOCKS or USE AND |KEEP UPDATE LOCKS is specified in the SQL statement, an X lock or |a U lock, respectively, is acquired at fetch time.

http://publib.boulder.ibm.com/infocente ... ements.htm

и вот этому

http://publib.boulder.ibm.com/infocente ... xf6a19.htm
(раздел SELECT with FOR UPDATE OF)

выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Ваша ошибка в том что Вы пытаетесь объяснить фичу DB2 for zOS используя документацию по DВ2 for LUW. Это не верный подход и поэтому вы запутались. А вот если бы ВЫ искали объяснение zOS фичи в документации по zOS, то Вы бы нашли:

U (UPDATE)
The lock owner can read, but not change, the locked page or row.
Concurrent processes can acquire S locks or might read data without
acquiring a page or row lock, but no concurrent process can acquire a U
lock.
U locks reduce the chance of deadlocks when the lock owner is reading a
page or row to determine whether to change it, because the owner can
start with the U lock and then promote the lock to an X lock to change the
page or row.

А ниче что там в шапке написано: DB2 UDB for z/OS Version 8?

Точно. Вы уже оказывается вышли на нормальную документациюю Первоначально iDesperado точно ссылался на LUW. А эти ссылки я не смотрел. В чем же проблема тогда у вас, парни?

http://publib.boulder.ibm.com/infocente ... ements.htm

У нас - ни в чем
У нас все во всем разобрались и все поняли уже

[zVlad]

....У нас - ни в чем
У нас все во всем разобрались и все поняли уже

Вы вот это называете разобрались:

.....
выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Вот тут написано что можед быть U: http://publib.boulder.ibm.com/infocente ... lkwhat.htm, если я не ошибаюсь.
Понятно что я смотрю только CS изоляцию.

?

Т.е. вы с iDesperado теперь оба считаете что SKIP LOCKED, имеющее смысл только c СS или RS, прочитает модифицированные записи? Так что ли?

[crypto5]

....У нас - ни в чем
У нас все во всем разобрались и все поняли уже

Вы вот это называете разобрались:

.....
выглядит, что FOR UPDATE поставит U блокировку которая совместима с S блокировкой которую будет ставить SKIP LOCKED. т.е. SKIP LOCKED из db2/zOS считает залоченные данные.
UPD: а может и IX, я не понимаю этих таблиц. блин ну почему нельзя по человечески хотя бы базовые вещи описать ?

Вот тут написано что можед быть U: http://publib.boulder.ibm.com/infocente ... lkwhat.htm, если я не ошибаюсь.
Понятно что я смотрю только CS изоляцию.

?

Т.е. вы с iDesperado теперь оба считаете что SKIP LOCKED, имеющее смысл только c СS или RS, прочитает модифицированные записи? Так что ли?

Нет, точный ответ именно на этот вопрос я не знаю.
А вас почему это интересует?