JP Morgan Chase Oracle database outage

[Dmitry67]

Разумеется
Задача как раз в том чтобы индекс использовался, как я и писал в первом посте
а в общем случае выражения типа ВЫРАЖЕНИЕ ( колонка ) не индексируются

[IvanGrozniy]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

Хотел протестировать на скорость и написал

select COUNT(*) from MyTable where created > convert(datetime, left(convert(varchar, getdate()), 4)+'0101')

Выдал ошибку The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

Пошел дальше и поправил

select convert(varchar(11), getdate())

Получил

Sep 20 2010

Понятно уже да к чему я?

select left(convert(varchar(11), getdate()), 4)

Выдал вместо года

Sep

По крайней мере у ваших индусов код работает

[zVlad]

как Вы наверное понимаете напрочь исключающий использование индексов.

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

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

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

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

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

[crypto5]

как Вы наверное понимаете напрочь исключающий использование индексов.

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

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

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

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

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

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

[Dmitry67]

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

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

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

[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", которые не шибко совместимы с писюками. у меня сложилось ложное впечатление ?

[mynameiszb]

Т.е. иными словами фиаско в Питерском Сбере, это точно низкая квалификация миграторов.

Может быть.

Возвращаясь к тому, о каких проблемах мне рассказали.
Речь идет о том, насколько «весело и бодро» можно использовать Oracle на zOs и на какие «грустности» народ наступил в связи с этим:

Огромное количество фич (особенно новых) не реализовано. Плюс, свои заморочки. Например:

- сессии живут в адресном пространстве листенера, если он упал – все пользователи бодро «идут в сад»
- ASM и иже с ним – отсутствуют
- автоменеджмент памяти – есть, но использовать не рекомендуется.

Из грустного – на 31-битном адресном пространстве только 2 гига адресации на все, начиная с ядра базы и заканчивая пулами данных.

Из практики – народ активно использовал в качестве oltp системы, но под варехаузы затачивать даже не пытался – не тянет из-за особенностей базы.

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

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

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

PPS. Готов обсуждать особенности использования 11g и проектирование oltp/dwh систем. Т.к. этим занимаюсь, и это мне интересно

[iDesperado]

2mynameiszb

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

[mynameiszb]

2mynameiszb
имхо тут интересней был бы вопрос почему на столь чудотворном МФ людям так регулярно приходит в голову выплачивать гигансткие деньги ораклу за кривой порт, только бы не использовать родной для МФ db2 за который уже уплочено ?

Ну, если этот кривой порт настроить корректно - он живет. И даже не падает.

А почему, так причины примитивные:

а) поставщик предлагает тот же банковский софт, заточенный под Oracle. Кто будет портировать его под другую базу ради одного заказчика?
б) даже если портировать - это же любимый exUSSR, в котором те спецы, которые есть. И которые в итоге могут убить год, прорву финансов и пр. - а получить результат "ну вас вместе с вашим проектом"...

К сожалению, количество действительно вменяемых людей ограничено и они (обычно) уже работают в других местах...

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

[Dmitry67]

А вот я вам скажу про то как фирму можно положить на пару дней.
Жила была фирма X. И какой то мальчик, который работал у провайдера, решил в выходные, что нашел ошибку в настройках DNS. И исправил ее.
В итоге все запросы к сайту фирмы X (а также многочисленным ресурсам и сервисам) стали идти не туда.
Когда ошибку обнаружили, неправильная запись DNS уже расползлась по DNS серверам всего мира
Ее конечно исправили, но пока она оплецируется назад пройдет день-два. Так что кластеры, мирроринги, бэкапы а тут раз - и не сделать НИЧЕГО
Только ждать.

[IvanGrozniy]

А вот я вам скажу про то как фирму можно положить на пару дней.
Жила была фирма X. И какой то мальчик, который работал у провайдера, решил в выходные, что нашел ошибку в настройках DNS. И исправил ее.
В итоге все запросы к сайту фирмы X (а также многочисленным ресурсам и сервисам) стали идти не туда.
Когда ошибку обнаружили, неправильная запись DNS уже расползлась по DNS серверам всего мира
Ее конечно исправили, но пока она оплецируется назад пройдет день-два. Так что кластеры, мирроринги, бэкапы а тут раз - и не сделать НИЧЕГО
Только ждать.

Сталкивался с подобной проблемой. Сделать что-то можно. Например, поставить прокси на тот неправильный IP, на которые идут пакеты. Прокси будет перенаправлять пакеты на правильный IP. Другой вопрос, что у провайдера не было специалиста, который такое решение бы осуществил.