JP Morgan Chase Oracle database outage

[mynameiszb]

...
Т.к. - заскорузл и слишком стар, чтобы в холиварах участвовать...

Нет уж дорогой. Сказал "А" скажи и "Б", а иначе это булшит по-русски называется.

"На слабо" детей в школе разводят. А в данном случае - каждый из участников сам решает, в какой дискуссии ему участвовать.

Из public информации я озвучил то, что имею право озвучить. То, что видел и про что знаю. На другие "приколы" я ссылки давать не уполномочен.

Пример с Питерским Сбером тоже не впечатляет.

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

Не знаю, кто именно провалил тот проект миграции - конкретные реализаторы, либо особенности самой системы, но факт имеет место быть. Именно по этой причине я "высунулся". Не потому что "db2 - плохой, плохой". А потому что не все так красиво "в датском королевстве", как вы меня убеждаете.

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

[crypto5]

Почему? Будет обычный index range scan вроде

Вот именно вроде. В DB2 это называется Stage 2 предикат. Т.е. применяется на уже выбранные из БД строки.

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

Индексы в DB2 - это не совсем то же что в Оракл. Индекс в DB2 дает, кратко говоря, прямой адрес памяти на дисках где хранятся искомые данные. Сам индекс тоже ищется на дисках с использованием аппаратного поиска, и в этом аппартном поиске не будет обрабатываться выражение из колонок, тем более если в выражение входят и индексированные колонки и не индексированные. Вы делаете смелые утверждения даже не уточнив все ли колонки в выражении предиката индексированны.
Я допускаю что в Оракл под видом индексированного доступа выполняется такая же работа как и в DB2 в Stage 2. Насколько мне известно Оракл не различает предикаты по признаку выполним он с использованием возможностей поиска дисков или нет. А DB2 различает и очень четко. Это целая теория.

P.S. Вот Dmitry67 примерно об этом же говорит парралельно нашей с Вами дискуссии.

Я не понимаю проблему, в оракле вы можете сделать function based индекс, и ваш запрос как я уже говорил будет использовать этот индекс. В ДБ2 вы можете построить такую же штуку с помощью тригеров, то есть везде можно и нужно использовать индексы в подобных ситуациях.

Кстати да, в оракле тут запрос можно заоптимизировать без его изменения, а в ДБ2 неполучится, так как нету function based indexes

[IvanGrozniy]

IvanGrozniy, я же код не тестировал набивал сразу
Вот тестируйте

convert(datetime,left(convert(varchar,getdate(),102),4)+'0101')

указал формат 102

Совсем другое дело, вопросов больше нет.

[zVlad]

....Я не понимаю проблему, в оракле вы можете сделать function based индекс, и ваш запрос как я уже говорил будет использовать этот индекс. В ДБ2 вы можете построить такую же штуку с помощью тригеров, то есть везде можно и нужно использовать индексы в подобных ситуациях.

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

[zVlad]

...
Т.к. - заскорузл и слишком стар, чтобы в холиварах участвовать...

Нет уж дорогой. Сказал "А" скажи и "Б", а иначе это булшит по-русски называется.

"На слабо" детей в школе разводят. А в данном случае - каждый из участников сам решает, в какой дискуссии ему участвовать.

Из public информации я озвучил то, что имею право озвучить. То, что видел и про что знаю. На другие "приколы" я ссылки давать не уполномочен.

....

Вы озвучили только то что ваши знакомые якобы "сношались" с zOS. Я работаю с zOS давно и не представляю в чем можно с zOS сношаться. Только одно объяснение приходит в голову: Ваши знакомые недоучены (если вообще) работе в zOS и это приводит к такому резьтату.

Ладно, давайте по другому. Вот публичго доступная документация по zOS:

http://www-03.ibm.com/systems/z/os/zos/ ... ves11.html

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

[zVlad]

....
Кстати да, в оракле тут запрос можно заоптимизировать без его изменения, а в ДБ2 неполучится, так как нету function based indexes

С чего Вы взяли что нет?

[zVlad]

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

Не знаю, кто именно провалил тот проект миграции - конкретные реализаторы, либо особенности самой системы, но факт имеет место быть. Именно по этой причине я "высунулся". Не потому что "db2 - плохой, плохой". А потому что не все так красиво "в датском королевстве", как вы меня убеждаете.

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

С Вами трудно спорить. Потому что Вы умудряетесь в однм сообщении утрвеждать и опровергать утвержденное.
Подумайте над выделеным мною в Вашей цитате. Ведь Вы же верно говорите что причин может быть много, и людской фактор часто бывает самым главным. Вы также соглашаететсь что Питерский пример для Вас загадка. Но почему то сомневаетесь в том что DB2 это такая же, строго говоря, БД как Оракл или MS SQL, в первом приближении, конечно. Я например не сомневаюсь что в принципе приложение с DB2 можно перенести и на ОРакл и на MS SQL. Можно, но не известно будет ли от этого выигрышь, и в первую очередь в надежности. Т.е. иными словами фиаско в Питерском Сбере, это точно низкая квалификация миграторов.

[crypto5]

....
Кстати да, в оракле тут запрос можно заоптимизировать без его изменения, а в ДБ2 неполучится, так как нету function based indexes

С чего Вы взяли что нет?

Ок, согласен ошибся - тогда ваш пример вполне подвержен использованию индекса даже на ДБ2.

[zVlad]

....
Кстати да, в оракле тут запрос можно заоптимизировать без его изменения, а в ДБ2 неполучится, так как нету function based indexes

С чего Вы взяли что нет?

Ок, согласен ошибся - тогда ваш пример вполне подвержен использованию индекса даже на ДБ2.

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

[iDesperado]

на счет непогрешимости дб2 первое, что вспоминается как НЕДЕЛЮ лежал Danske Bank
http://www.infoworld.com/d/data-managem ... e-bank-132

странно, что никто не вспомнил.

на счет JP Morgan, я не понял как им удалось снять бэкап не обнаружив поврежденного блока и что там за "smart" дба, которым понадобилось сутки на восстановление транзакций с ночного бэкапа суботы на утро вторника (т.е. по большому счету они восстанавливали примерно столько же времени сколько юзера настукивали эти данные) !?

[zVlad]

на счет непогрешимости дб2 первое, что вспоминается как НЕДЕЛЮ лежал Danske Bank
http://www.infoworld.com/d/data-managem ... e-bank-132

странно, что никто не вспомнил.

Насчет непогрешимости ДБ2 говорят только такие как Вы, развенчатели этой непогрешимости. Сами об этом говорите и сами же опровергаете. Я лично рассказывал здесь на форуме про имевшую место быть у нас на фирме дата каррапшн.

Тем не менее та история не отвернула Danske Bank от сотрудничества с ИБМ и участия в бетта-тестировании DB2 v10:
http://www-01.ibm.com/software/data/db2 ... nials.html

"Continuous availability, reduced performance cost and future growth with constraints are of paramount importance to our business. We are really excited about the potential of DB2 10 for z/OS to help us achieves our goals in each of these areas. Our high expectation is the reason why Danske Bank will invest a lot of effort in the Beta program."

А вообще история эта интересна тем что:
http://www.theregister.co.uk/2003/04/03 ... or_danish/

The problems first started on March 10 when IBM's technical division staff came in to replace a defective power unit in an IBM Ramac Virtual Array (RVA) storage system. An electrical outage occurred during the repairs, which caused operations at one of the bank's two operating centers to come to a halt.

и

"The circumstances that led to this situation were highly unusual and no other customers have reported a similar DB2 issue,"

[iDesperado]

Насчет непогрешимости ДБ2 говорят только такие как Вы, развенчатели этой непогрешимости.

может быть, наверно вот это выдал какой-то другой zVlad

А в DB2 глюков и проблем действительно меньше и разруливать такого типа проблемы ИБМ может быстрее и с меньшими последствиями для клиента.
...
А вот о случаях каррапшн в Оракл даже я, человек далекие от Оракл, слышал неоднократно. Так что на верном пути был JP Morgan Chase, и после этого случая полагаю они ускорят переход на DB2 (на МФ конечно).

и вопрос: Ramac Virtual Array, я правильно понимаю что это указывает, на то что проблема приключилась именно с мейнфремом ?

[zVlad]

Насчет непогрешимости ДБ2 говорят только такие как Вы, развенчатели этой непогрешимости.

может быть, наверно вот это выдал какой-то другой zVlad

А в DB2 глюков и проблем действительно меньше и разруливать такого типа проблемы ИБМ может быстрее и с меньшими последствиями для клиента.
...
А вот о случаях каррапшн в Оракл даже я, человек далекие от Оракл, слышал неоднократно. Так что на верном пути был JP Morgan Chase, и после этого случая полагаю они ускорят переход на DB2 (на МФ конечно).

и вопрос: Ramac Virtual Array, я правильно понимаю что это указывает, на то что проблема приключилась именно с мейнфремом ?

Нет это был я, но Вы почему вырвали из сказаного мной вот это кусочек:

В этой связи вспоминается единственный известный мне случай каррапшн данных в DB2 случившийся лет 5 назад. К моменту обнаружения каррапшн у ИБМ уже был патч. Сама каррапшн была локализована одной таблицей, в целом базу данных восстанавливать не пришлось, починили конкретно пострадавшие данные одной таблицы. Outage системы в целом не было (кроме одной из ~3000 транзакции).

, который с очевидностью показывает что безгрешность ДБ2 я не декларировал.

RVA - это дисковая подсистема. Тоже ИБМ продукт, но строго говоря не входящий в комплект МФ вовсе. У нас например используются диски от НР, ЕМС тоже производит диски используемы с МФ, вооще нынче для все платформ используются одни и теже дисковые подсистемы, разница только в адаптерах подключения. Для МФ главным образом используют FICON адаптеры.

[Dmitry67]

К пуговицам претезнии есть?
IBM продает набор железа или solution?

[iDesperado]

IBM storage subsystems have implemented the traditional count key data (CKD)
channel architecture on products like the 3880, 3990, and RAMAC Array family.
The CKD architecture defines a set of rules that determine how data is stored on
physical disk. It also defines both control and data fields on the magnetic
surface of the disk that are used for formatting and locating data.
http://www.redbooks.ibm.com/redbooks/pdfs/sg244951.pdf

полистав документ у меня сложилось впечатление, что эта штука использует "parallel and ESCON channels", которые не шибко совместимы с писюками. у меня сложилось ложное впечатление ?