JP Morgan Chase Oracle database outage

[zVlad]

....

в свою очередь Оракл на МФ выглядит как бедный родственник.

снова лишь ваше предположение, по мне так db2/zOS сильно бедней, я уже пару раз перечислял насколько богаче возможности предоставляет оракл на том же zOS.

Ваши перeчисления прошли мимо меня. Это было не в этой теме? Не могли бы освежить или дать ссылку. Очень хотелось бы посмотреть на преимущества Оракл перед ДБ2 на МФ.

[Dmitry67]

Нет, от кривых рук это не зависит.

Итак, у нас есть таблица счетов BILLS (ID INT, AMOUNT MONEY)
Пусть select SUM(AMOUNT) from BILLS дает 0
теперь у нас есть куча транзакций которые постоянно перебрасывают деньги со счета на счет, типа

BEGIN TRANSACTION
UPDATE BILLS SET AMOUNT=AMOUNT+@a WHERE ID=@M
UPDATE BILLS SET AMOUNT=AMOUNT-@a WHERE ID=@N
COMMIT TRANSACTION

где @a - некая сумма, а @M и @N - некоторые разные счета.
От того что где то добавили а гдето столько убрали общая сумма не изменяется.
То есть, сколько таких процессов не запускай, в итоге SUM(AMOUNT) дает 0, правильно?

тем не менее, для READ COMMITTED стейтмент

SELECT SUM(AMOUNT) FROM BILLS

При активной работу указанные транзакций по переброске часто дает не 0.

[zVlad]

Вы как-то легко перескакиваете с обсуждения DB2 на разных платформах к обсуждению Оракла. Кроме того я Вам пытаюсь объяснить почему DB2 не может быть одинаков на разных платформах, а Вы меня отсылаете к факту что Оракл одинаков, не замечая что это лишь потому так что Оракл (вендор) не может и не хочет использовать возможности МФ, он хочет лишь портировать то что наваял под Юникс в zOS и отрапортовать. Это разные бизнес модели не более того.

"DB2 не может быть одинаков на разных платформах" - это лишь ваше предположение. я с ним не согласен. во времена появления LUW ничто не мешало ИБМ написать отпимизатор и подсистему с SQLPL на переносимом языке типа С и под LUW и zOS, как это в свое время сделал оракл. ничто не мешало. если бы эти подсистемы были бы из единого кода, можно было бы получить 100% идентичные языки на всех платформах используемых db2. но ИБМ предпочла тащить весь груз непероносимых никуда нароботок под МФ и получила то что получила. 3 раных субд, объединеных лишь названием. zOS, LUW, AS/400 (или что там теперь iSeries ?)

....

Я Вам уже несколько раз обьяснял почему, но Вы упорно мои обьяснения игнорируете. Мне лично мотивация ИБМ совершенно понятна и очевидна. Почему Оракл сделал выбор в пользу одной кодебэйз тоже понятно - мощей для правильной разработки на МФ не было, да и конкурировать с ДБ2 на МФ безполезно. Т.е. это была вынужденная мера со стороны Оракл. ИБМ в другой ситуации находится и поетому другие подходы использует.

[zVlad]

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

Дима, в DML и в самом деле практически нет разницы (в DML и имен то файлов нет), просто iDesperado излишне несколько раздувает проблему потому что Оракл в своих пропагандистских документах постоянно выпячивает факт что кодебэйз Дб2 разный на МФ и на LUW.

[iDesperado]

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?

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

[zVlad]

Нет, от кривых рук это не зависит.

Итак, у нас есть таблица счетов BILLS (ID INT, AMOUNT MONEY)
Пусть select SUM(AMOUNT) from BILLS дает 0
теперь у нас есть куча транзакций которые постоянно перебрасывают деньги со счета на счет, типа

BEGIN TRANSACTION
UPDATE BILLS SET AMOUNT=AMOUNT+@a WHERE ID=@M
UPDATE BILLS SET AMOUNT=AMOUNT-@a WHERE ID=@N
COMMIT TRANSACTION

где @a - некая сумма, а @M и @N - некоторые разные счета.
От того что где то добавили а гдето столько убрали общая сумма не изменяется.
То есть, сколько таких процессов не запускай, в итоге SUM(AMOUNT) дает 0, правильно?

тем не менее, для READ COMMITTED стейтмент

SELECT SUM(AMOUNT) FROM BILLS

При активной работу указанные транзакций по переброске часто дает не 0.

Дима, если сумма по счетам ноль, то откуда у Вас взялись деньги для переброски денег содного с чета на другой? Как это цозможно без того чтобы на каких-то счетaх оказывались отрицательные остатки?

[Dmitry67]

Если хотите переименуйте поле AMOUNT в поле ABSTRACT_MATH_VALUE.
Это чтото меняет в сути прoблемы?
C нулем просто значительно легче показать что результат inconsistent.

[zVlad]

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?

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

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

[zVlad]

Если хотите переименуйте поле AMOUNT в поле ABSTRACT_MATH_VALUE.
Это чтото меняет в сути прoблемы?
C нулем просто значительно легче показать что результат inconsistent.

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

[iDesperado]

Что Вы предложите чтобы такого не было?

лит-ру бы посоветовал почитать, помню в школе видел книжки где были по азам проектировщика БД. думаю и сейчас такая лит-ра есть. это называется оптимистическая стратегия, от субд стратегия не зависит, оптимистическую стратегию давольно часто применяют в блокировочном db2 и полно статей на эту тему. к стате в db2 9.7 целая конструкция ROW CHANGE TIMESTAMP FOR добавлена для удобства реализации такой стратегии на db2.
если не найдете лит-ру, почитайте мануал:
http://publib.boulder.ibm.com/infocente ... 51459.html

[zVlad]

Что Вы предложите чтобы такого не было?

лит-ру бы посоветовал почитать, помню в школе видел книжки где были по азам проектировщика БД. думаю и сейчас такая лит-ра есть. это называется оптимистическая стратегия, от субд стратегия не зависит, оптимистическую стратегию давольно часто применяют в блокировочном db2 и полно статей на эту тему. к стате в db2 9.7 целая конструкция ROW CHANGE TIMESTAMP FOR добавлена для удобства реализации такой стратегии на db2.
если не найдете лит-ру, почитайте мануал:
http://publib.boulder.ibm.com/infocente ... 51459.html

Как это делается в ДБ2 я сам знаю, речь идет об Оракл.

[iDesperado]

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

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

[Dmitry67]

Если хотите переименуйте поле AMOUNT в поле ABSTRACT_MATH_VALUE.
Это чтото меняет в сути прoблемы?
C нулем просто значительно легче показать что результат inconsistent.

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

zVlad, чтобы доказать что в READ COMMITTED не гарантируется получение CONSISTENT репорта достаточно привести ОДИН пример это доказывающий
Также, чтобы опровергнуть физический закон достаточно привести всего ОДИН пример где закон не работает
Помните ответ Эйнштейна на выход в нацисткой германии книги "100 физиков опровергают Эйнштейна"? Он ответил в духе "Если я неправ, то было бы вполне достаточно и одного"

таким образом вы признаете что READ COMMITTED не гарантирует получение CONSISTENT reportа?

[zVlad]

Если хотите переименуйте поле AMOUNT в поле ABSTRACT_MATH_VALUE.
Это чтото меняет в сути прoблемы?
C нулем просто значительно легче показать что результат inconsistent.

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

zVlad, чтобы доказать что в READ COMMITTED не гарантируется получение CONSISTENT репорта достаточно привести ОДИН пример это доказывающий
Также, чтобы опровергнуть физический закон достаточно привести всего ОДИН пример где закон не работает
Помните ответ Эйнштейна на выход в нацисткой германии книги "100 физиков опровергают Эйнштейна"? Он ответил в духе "Если я неправ, то было бы вполне достаточно и одного"

таким образом вы признаете что READ COMMITTED не гарантирует получение CONSISTENT reportа?

А что для того чтобы доказать верность Вашего примера нужно моё признание?

P.S. Read Commited - это не единственный уровень изоляции.

[zVlad]

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

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

А что не так с масштабируемостью в моем варианте с триггером, обновляющим одну единственную запись?

[iDesperado]

Как это делается в ДБ2 я сам знаю, речь идет об Оракл.

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

[iDesperado]

А что не так с масштабируемостью в моем варианте с триггером, обновляющим одну единственную запись?

вы наверно пропустили мой диагноз:

Есть таблица куда пихает строки ОЛТП и на ней триггер по инсерт, который, наприрем, увеличивает сумму чего и количество событий в, например, единственной итоговой строке хранимой в другой таблице.

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

[Dmitry67]

P.S. Read Commited - это не единственный уровень изоляции.

А в более высоких уровнях изоляции отчет получается consistent, но система становится однопользовательской
Это не проблема DB2: это проблема блокировочников.
Доказывается абстрактно, в абстрактной нотации w(...)r(...)

[zVlad]

Как это делается в ДБ2 я сам знаю, речь идет об Оракл.

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

Точно также как в ДБ2, я понимаю, означает блокировку.
Да нет с клиентом и лицензированием все в порядке, просто те кто писал этот приклад не продумали эту ситуацию - азбучную в случае ДБ2, да и Оракл тоже.

[iDesperado]

Точно также как в ДБ2, я понимаю, означает блокировку.

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

[crypto5]

...

Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

если отчет состоит из нескольких запросов вы получаете гарантированную неконсистентную кашу.

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?

А какое точное название продукта? И изменения чего он должен контролировать(исходный код, документация, что-то еще)?

[zVlad]

...

Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

если отчет состоит из нескольких запросов вы получаете гарантированную неконсистентную кашу.

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?

А какое точное название продукта? И изменения чего он должен контролировать(исходный код, документация, что-то еще)?

Action Request System, "Remedy" from BMC Software Inc.

[zVlad]

Точно также как в ДБ2, я понимаю, означает блокировку.

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

Вряд ли я что-нибудь смогу найди почитать о ДБ2 такого чтбы мне было не известно уже. Если бы Вы не затуманивали разговор абстрактными терминами общей теории БД, а высказывались нормальным языком реальных БД, то мы скорее бы нашли взаимопонимание. А в данном случае Вам просто не хочется соглашаться со мной в том что без локов здесь не обойтись, вот Вы и прячетесь за оптимизм-пессимизм.

[crypto5]

...

Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

если отчет состоит из нескольких запросов вы получаете гарантированную неконсистентную кашу.

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?

А какое точное название продукта? И изменения чего он должен контролировать(исходный код, документация, что-то еще)?

Action Request System, "Remedy" from BMC Software Inc.

Из описания в вики - эта система работает на разных БД, ну и случай описанный вами я бы например не реализовывал через БД локи, а делал некие логические локи(например флаг в таблице что доkумент открыт с соответствующим таймаутом), то есть на мой взгляд этот пример иррелевантен сравнению механизмов обеспечения concurrency и consistency в разных БД.

[iDesperado]

Вряд ли я что-нибудь смогу найди почитать о ДБ2 такого чтбы мне было не известно уже.

в этом вы ошибаетесь, обязательно найдете. не так уж давно мы выяснили, что вы не знали о существовании MQT в дб2

Если бы Вы не затуманивали разговор абстрактными терминами общей теории БД, а высказывались нормальным языком реальных БД, то мы скорее бы нашли взаимопонимание. А в данном случае Вам просто не хочется соглашаться со мной в том что без локов здесь не обойтись, вот Вы и прячетесь за оптимизм-пессимизм.

какое затуманивание. я вам дал ПРЯМУЮ ссылку на реализацию оптимистической стратегии в db2. вот даю повторно:
http://publib.boulder.ibm.com/infocente ... 51459.html

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

P.S. BMC Remedy AR System uses a third party database (Sybase, MS SQL Server, Oracle, IBM DB2) for storing data in tables. In addition, the database stores a set of metatables known as the data dictionary. These metatables contain the source code which tells the applications how to interact with the users and the data. Action Request System has an open API, a feature which allows users to create custom client tools and scripts that talk directly to the Action Request System.
интересно зачем было разводить зарпарк с базами данных, если у вас дб2, зачем этот ремеди было ставить на оракл ?