JP Morgan Chase Oracle database outage

[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, прочитает модифицированные записи? Так что ли?

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

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

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

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

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

?

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

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

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

Я думаю что посмотрев на себя со стороны вы узнаете тоже много нового в этом направлении

[Dmitry67]

Я бы чувствовал себя неуютно сидя на Db2 или Мф - не с технической точки зрения а с точки зрения мобильности. Мест где можно работать всего несколько... Это неважно гуру, который работает 20 лет на одном месте и купил рядом дом. А молодым... Я кстати тоже не реже раза в 4 года меняю работу.

Кроме того, это гарантированно работа в больших компаниях. Я работал в Siemens... У меня нет желания больше работать в фирмах >50-100 человек. ПОтому что если небольшая фирма может набрать талантливых - более или менее - то большая фирма ориентирована на обычных людей. В итоге всегда получается нечто вроде cоветского НИИ.

Вопрос zVlad: а можно посмотреть screenshot того как работает какой нибудь select и выбираются результаты? Для все баз видел, для DB2 не видел...

[iDesperado]

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

именно. на уровне CS
SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE
поставит блокировку U, которую
SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

из конкурирующей транзакции без всяких проблем прочитает, т.к. S накладываемая этим запросом совместима с U блокировкой. со всеми вытекающими. это следует из документации.

[zVlad]

Я бы чувствовал себя неуютно сидя на Db2 или Мф - не с технической точки зрения а с точки зрения мобильности. Мест где можно работать всего несколько... Это неважно гуру, который работает 20 лет на одном месте и купил рядом дом. А молодым... Я кстати тоже не реже раза в 4 года меняю работу.

Кроме того, это гарантированно работа в больших компаниях. Я работал в Siemens... У меня нет желания больше работать в фирмах >50-100 человек. ПОтому что если небольшая фирма может набрать талантливых - более или менее - то большая фирма ориентирована на обычных людей. В итоге всегда получается нечто вроде cоветского НИИ.

Вопрос zVlad: а можно посмотреть screenshot того как работает какой нибудь select и выбираются результаты? Для все баз видел, для DB2 не видел...

Я кстати радикально поменял специализацию за последние 10 лет два раза. Сначал я стал DB2 DBA просто потому что у меня был хороший бэкграунд на МФ и интервьюверы были славяне (венгр и чех). И пощти 5 лет назад я из DB2 DBA перквалифицировался в zOS систем программер. А сейчас, кстати, собираюсь осваивать ранее непаханое мной поле под названием CICS. Я уж не говорю о WebSphere, NetView, System Automation, Omegamon и т.д.

Не понимаю как вообще можно показать "как работает какой нибудь select и выбираются результаты". Если по простому то так же как и в других БД. Показать screenshot я не понимаю. Текст select-а Вы имеете в виду? Или план доступа? Или что?

[crypto5]

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

именно. на уровне CS
SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE
поставит блокировку U, которую
SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

из конкурирующей транзакции без всяких проблем прочитает, т.к. S накладываемая этим запросом совместима с U блокировкой. со всеми вытекающими. это следует из документации.

Ну так это не модифицированные данные. Когда данные промодифицируются на них наложится эксклюзивный лок, который ни с какими другими локами не совместим.

[iDesperado]

Ну так это не модифицированные данные. Когда данные промодифицируются на них наложится эксклюзивный лок, который ни с какими другими локами не совместим.

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

[zVlad]

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

именно. на уровне CS
SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE
поставит блокировку U, которую
SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

из конкурирующей транзакции без всяких проблем прочитает, т.к. S накладываемая этим запросом совместима с U блокировкой. со всеми вытекающими. это следует из документации.

Вы наверняка знаете что U блокировка сделана совместимой с S чтобы уменьшить количество дедлоков. Но, в DB2 for zOS, U блокировка не дает права изменять данные, SELECT .... FOR UPDATE вовсе не предполает изменение всех строк резалт сета. Может и ни одна запись не будет изменена этим стэйтментом. Но на те, которые будут изменены будет наложена X блокировка со всеми вытекающими последствиями.
Более очевидный и доходчивый пример для иллюстрации SKIP LOCKED DATA - это чистый UPDATE, или DELETE стэйтменты.

[zVlad]

Кстати, пока форум лежал, я пошуршал в интернете и обнаружил что за почти пять лет с тех пор как я перестал профессионально заниматься DB2 многое изменилось. Вот две ссылки с короткими сообщениями, где кроме SKIP LOCKED DATA рассматриватся еще один механизм работы с локами, очень напоминающий "локические" локи против которых я тут бьюсь который день:

Another DB2 9 improvement is optimistic locking support. With optimistic locking, locks are obtained immediately before a read and then released. Update locks are obtained immediately before an update operation and held until the end of the transaction. Optimistic locking uses the RID and a row change timestamp to test whether data has been changed by another transaction since the last read operation. A row change timestamp, new DB2 9, is an automatically generated timestamp column, defined as follows:

NOT NULL [GENERATED ALWAYS | BY DEFAULT]
FOR EACH ROW ON UPDATE
AS ROW CHANGE TIMESTAMP

http://www.dbmag.intelligententerprise. ... =201200471

http://www.craigsmullins.com/zjdp_031.htm

[zVlad]

Ну так это не модифицированные данные. Когда данные промодифицируются на них наложится эксклюзивный лок, который ни с какими другими локами не совместим.

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

Если Вы имеете в виду вот это описание:

........
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 (одна) штука удаляется.
....

..., то не надо принимать его "близко к сердцу". Я не практикующий программист, как Вы уже наверняка поняли, я лишь бывший DB2 DBA, и как выяснилось с устревшими представлениями (я вместе с вами узнал про SKIP LOCKED DATA пару дней назад). Возможно бронировать надо просто UPDATE.

[crypto5]

Ну так это не модифицированные данные. Когда данные промодифицируются на них наложится эксклюзивный лок, который ни с какими другими локами не совместим.

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

Я согласен что в своем первом примере с select for update Влад был не прав, но в данной ветке обсуждается уже другой пример.

[Dmitry67]

И все же, может кто нибудь выложить screenshot с select и результатом - не важно каким - просто интересно как 'выглядит рабочее' место DBA DB2

[zVlad]

И все же, может кто нибудь выложить screenshot с select и результатом - не важно каким - просто интересно как 'выглядит рабочее' место DBA DB2

Интструментарий DB2 DBA на МФ это не SQL (хотя и им пользуемся конечно), а главным образом утилиты (реорганизации, бэкапа, рестор, лоад, анлоад, и т.п.) и команды DB2.
Интерфэйс - это терминал IBM 3270, хотя есть не мало GUI тулсов из которых я лично пользовался только Visual Explain (изначально написанный в Visual Age for Smalltalk несколько лет назад переписанный на Java).
Утилиты выполняются как батч задания. Хаускипинг утилиты выполняются по графику, автоматически. У нас есть домашняя разработка выполнения реоргов ночью в автоматическом режиме по заданиям составленным админом в дневное время. Никакого интерфейса практически нет. Текстовым редактором создается задание, представляющее из себя список объектов для реорга и дополнительных, необязательных параметров. Затем выполняется программа (опять же как бат задание), которая делает разнообразные вычисления и готовит развернутое задание сохраняемое в базе данных. Ночью по графику запускается программа (батч) используящая данные созданные предыдущей программой для запуска утилит реорг (батч задания) и управлет их выполнением, а именно анализирует завершение утилит и "подчищает" за ними если надо.

[Dmitry67]

Хорошо, а если надо вам говорят - а правда что такая то табличка содержит 100 записей и все 2008 года,
то в какой утилите вы будете это смотреть? Где напишете select * from TAB ?

[zVlad]

Хорошо, а если надо вам говорят - а правда что такая то табличка содержит 100 записей и все 2008 года,
то в какой утилите вы будете это смотреть? Где напишете select * from TAB ?

Кто спросит? (подсказка - у нас есть еще программисты)

[Dmitry67]

Ваш начальник
Подойдет и спросит - zVlad, а правда что такая то база не использовадлась долго? Там вроде таблица лога есть, посмотрите какая самая последняя запись?
Или вы скажете: это не мое дело, пусть программисты занимаются? На MS SQL такие вещи глянуть - 5 сек.

[iDesperado]

Я согласен что в своем первом примере с select for update Влад был не прав, но в данной ветке обсуждается уже другой пример.

в пылу я не заметил.

..., то не надо принимать его "близко к сердцу". Я не практикующий программист, как Вы уже наверняка поняли, я лишь бывший DB2 DBA, и как выяснилось с устревшими представлениями (я вместе с вами узнал про SKIP LOCKED DATA пару дней назад). Возможно бронировать надо просто UPDATE.

ну вот видите, а говорили мы вам ничего нового по db2/zOS не расскажем

[zVlad]

.....

..., то не надо принимать его "близко к сердцу". Я не практикующий программист, как Вы уже наверняка поняли, я лишь бывший DB2 DBA, и как выяснилось с устревшими представлениями (я вместе с вами узнал про SKIP LOCKED DATA пару дней назад). Возможно бронировать надо просто UPDATE.

ну вот видите, а говорили мы вам ничего нового по db2/zOS не расскажем

Премного вам благодарен. Почти пять лет без практики в DB2 дали себя знать. Вы подтянули мой уровень немного.

[zVlad]

Ваш начальник
Подойдет и спросит - zVlad, а правда что такая то база не использовадлась долго? Там вроде таблица лога есть, посмотрите какая самая последняя запись?
Или вы скажете: это не мое дело, пусть программисты занимаются? На MS SQL такие вещи глянуть - 5 сек.

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

[Dmitry67]

zVlad, по моему вы там совсем выработали tunnel vision в своем сферическом environment в вакууме на МФ. Вас надо для расширения кругозора отправить в стартап какой нибудь месяцев на шесть - чтобы дедлайн был завтра, что делать было бы непонятно, и чтобы все вокруг бегали с круглыми глазами и рвали на себе волосы.

Пример абсолютно жизненный. Или для вас DBA - это тот, кто делает там бэкапы и еще что и никогда внутрь баз не заглядывает? Есть тысячи причи и тысячи ситуаций, когда надо заглянуть в табличку и посмотреть, что там.