KinDzaDza wrote:Читая zVladа (не только в этой теме), складывается впечатление, что везде (ну кроме ИБМ конечно же), работают одни криворукие идиоты. И все, кто не работает на МФ - ущербные, жалкие людишки, которые чужие на этом празднике жизни и им всем крупно не повезло, потому что богоподобные творения непогрешимой ИБМ прошли мимо них.
Пусть zVlad это откомментирует, но с Вами сложно не согласится!
KinDzaDza wrote:Пока не известно, что именно там случилось и почему, как-то странно обвинять именно Оракл. А особенно странно говорить, что вот если бы там была DB2 на МФ, то такого (а какого?) никогда бы не произошло. В Оракле глюков конечно хватает, но конкретно в этой ситуации там может быть все что угодно.
Согласен - достоверных данных очень мало. Я более чем уверен, что индусы в IT Chase bank валят вину на все, что не движется, как-то Oracle, EMC и "third-party software" - это нормально потому как ставки высоки и непременно последуют (если уже не последовали) оргвыводы...
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
Dmitry67 wrote:По моему тут как раз все логично. Если верхний уровень попросил записать бредовый блок в базу, то нижние уровни должны as is этот бред отмиррорить и в бэкап положить - им же пофиг что на странице записано.
Не совсем так. Если по минимуму, то нижний уровень должен был отрапортовать о наличии плохого блока, а правильный DBA - выловить это сообщение и вовремя, а главное верно, отреагировать.
Нижний уровень - это миррор. Это аппаратная фича которой глубоко наплевать наданные как таковые. Все что миррор дисков делает - это, как и в обычной жизни, отражает то что есть. Вот если бы у них была репликация, то тогда могла бы быть разница.
Использование 8-ми Соляр с Оракл в крупном банке - это глупость.
1. Почему?
она принесла плоды как мы видим.
2. Это неправда, пока что не выяснили почему именно случился outage.
1. Потому что 1000 РС серверов заменили бы 8-мь Соляр за меньшие деньги. Интересно что у нас одна атомная станция два года назад тоже почему то ушли с одного МФ на 8 System p серверов.
Да уж, серьезный аргумент..
2. Но разве о том что делалось восстановление БД с бэкапа мы не знаем? А какие еще могут причины для этого если технических не было?
Очевидно что кроме бага в оракле могло быть куча других проблем, например проблемы с storage system, или какой нибудь логический баг в банковском ПО.
crypto5 wrote:....
Очевидно что кроме бага в оракле могло быть куча других проблем, например проблемы с storage system, или какой нибудь логический баг в банковском ПО.
А Вы ссылку то в первом сообщении этой темы изучали?
Dmitry67 wrote:По моему тут как раз все логично. Если верхний уровень попросил записать бредовый блок в базу, то нижние уровни должны as is этот бред отмиррорить и в бэкап положить - им же пофиг что на странице записано.
Не совсем так. Если по минимуму, то нижний уровень должен был отрапортовать о наличии плохого блока, а правильный DBA - выловить это сообщение и вовремя, а главное верно, отреагировать.
А как нижний уровень догадается что блок плохой?
Интеллектуальный нижний уровень должен проверять data block checksum перед и после записи. Правда, это неплохо работает для intrablock corruptions, но вовсе не так просто вычислить при interblock corruptions.
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
Я тоже хотел спросить. Чаще всего нижний уровень об этом догадаться не может
С другой стороны, в этом случае просто были бы на одной страницы неправильные данные, типа вместо Varchar 'John Smith' было бы 'Jo@@MJ@*$&%*#@Mith'
Под '4 corrupted files' понимается чтото куда большее.
Вообще конечно без технических деталей это гадание на кофейной гуще.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
oMoses wrote:... Согласен - достоверных данных очень мало. Я более чем уверен, что индусы в IT Chase bank валят вину на все, что не движется, как-то Oracle, EMC и "third-party software" - это нормально потому как ставки высоки и непременно последуют (если уже не последовали) оргвыводы...
Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.
crypto5 wrote:....
Очевидно что кроме бага в оракле могло быть куча других проблем, например проблемы с storage system, или какой нибудь логический баг в банковском ПО.
А Вы ссылку то в первом сообщении этой темы изучали?
Использование 8-ми Соляр с Оракл в крупном банке - это глупость.
4-node Oracle RAC + 4-node standby (Oracle Max Availability Architecture) = это как раз the must! Другое дело, похоже, что именно этого-то у Chase и не было. Иначе бы не было и столь длительного outage...
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
zVlad wrote:Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.
Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
oMoses wrote:
А как нижний уровень догадается что блок плохой?
Интеллектуальный нижний уровень должен проверять data block checksum перед и после записи. Правда, это неплохо работает для intrablock corruptions, но вовсе не так просто вычислить при interblock corruptions.[/quote]
Это работает если вы прочитали блок и checksum не совпала
В случае же записи:
1 формируем данные на странице
2 считаем checksum
3 записываем в базу
checksum никак не помогает если #1 сформировал бред.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Использование 8-ми Соляр с Оракл в крупном банке - это глупость.
4-node Oracle RAC + 4-node standby (Oracle Max Availability Architecture) = это как раз the must! Другое дело, похоже, что именно этого-то у Chase и не было. Иначе бы не было и столь длительного outage...
Опять же, по разному мы читаем одно и тоже. Как я понял, из прочитанного, переходить на standby смысла не было потому что и standby имел те же карраптед данные. Поэтому делалось восстановление с субботнего кажется бэкапа (на лентах по всей видимости) и накат журнала изменений. Что и объясняет столь длительное восстановление.
Before long, JPMorgan Chase DBAs realized that the Oracle database was corrupted in about 4 files, and the corruption was mirrored on the hot backup. Hence the manual database restore starting early Tuesday morning.
# The Oracle database was restored from a Saturday night backup. 874K transactions were reapplied, starting early Tuesday morning and ending late Tuesday night.
# $132 million in ACH transfers were held up by the JPMorgan Chase database outage.
Last edited by zVlad on 18 Sep 2010 20:57, edited 1 time in total.
zVlad wrote:Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.
Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!
Интересно, как они это доказали
Типа, у нас в логе ошибок нет?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое third-party software) просто дропнул ценную табличку с данными (скажем, паролями on-line пользователей веб-серверов банка). Естественно, что это-же послушно произошло и на standby database, если данные с primary db туда накатываются без задержки. или ошибка была обнаружена уже по истечению таковой. Далее, конечно, постребовалось восстанавливаться с бэкапов, поскольку, вероятно, содержать flashback для такой напряженной базы было очень накладно...
Ну а восстановление - это целая отдельная песня. Быстро спеть её (посредством уникальных и дорогих средств EMC/Veritas/Solaris) почему-то не получилось, и пришлось петь медленно (Oracle RMAN?). А три дня потеряли на анализ ситуации и различные попытки восстановления... Oracle datafile corruption вполне могли вылезти вследствии неудачных первых попыток и усугубить ситуацию - ведь наверняка сделать копию всего сервера перед восстановлением было некогда....
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
zVlad wrote:Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.
Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!
Интересно, как они это доказали
Типа, у нас в логе ошибок нет?
Там проверяли версию с проблемой в контроллере, о полной верификации абсолютной правильности решения от ЕМС речь конечно же не идет.
Вообще к сожалению ситуация сейчас еще больше усугубляется.
Я наблюдаю конторы где production сервера SQL server держат базы в SIMPLE mode (для людей из мира Oracle и DB2 - это когда транзакции после записи в transaction log сразу оттуда чистятся, так что есть только FULL backups, как правило раз в день, а 'накатка' невозможна). Объяснение - 'ну, SAN же никогда не ошибается' (знаю. дважды помогал восстанавливать базы изза проблем с SAN). Сами бэкапы пишут, конечно же, на то же устройство. Мир сошел с ума.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Еще меня умиляет когда клиенты A и B требуют, чтобы их базы лежали на разных Windows server/SQL server.
То, что эти виртуальные сервера лежат на одном ESX server, и базы лежат на одном SAN, их не волнует.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
oMoses wrote:Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое third-party software) просто дропнул ценную табличку с данными (скажем, паролями on-line пользователей веб-серверов банка). Естественно, что это-же послушно произошло и на standby database, если данные с primary db туда накатываются без задержки. или ошибка была обнаружена уже по истечению таковой. Далее, конечно, постребовалось восстанавливаться с бэкапов, поскольку, вероятно, содержать flashback для такой напряженной базы было очень накладно...
Ну а восстановление - это целая отдельная песня. Быстро спеть её (посредством уникальных и дорогих средств EMC/Veritas/Solaris) почему-то не получилось, и пришлось петь медленно (Oracle RMAN?). А три дня потеряли на анализ ситуации и различные попытки восстановления... Oracle datafile corruption вполне могли вылезти вследствии неудачных первых попыток и усугубить ситуацию - ведь наверняка сделать копию всего сервера перед восстановлением было некогда....
Из сказанного Вами следует что Вы подозреваете DBAs JPMorgan Chase в том что они плохо знают свою работу, свои обязанности и у них нет плана действий в подобной ситуации, они не тренируются и не тестируют свои ресторайшн процедуры?
oMoses wrote:Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое third-party software) просто дропнул ценную табличку с данными (скажем, паролями on-line пользователей веб-серверов банка). Естественно, что это-же послушно произошло и на standby database, если данные с primary db туда накатываются без задержки. или ошибка была обнаружена уже по истечению таковой. Далее, конечно, постребовалось восстанавливаться с бэкапов, поскольку, вероятно, содержать flashback для такой напряженной базы было очень накладно...
Ну а восстановление - это целая отдельная песня. Быстро спеть её (посредством уникальных и дорогих средств EMC/Veritas/Solaris) почему-то не получилось, и пришлось петь медленно (Oracle RMAN?). А три дня потеряли на анализ ситуации и различные попытки восстановления... Oracle datafile corruption вполне могли вылезти вследствии неудачных первых попыток и усугубить ситуацию - ведь наверняка сделать копию всего сервера перед восстановлением было некогда....
Из сказанного Вами следует что Вы подозреваете DBAs JPMorgan Chase в том что они плохо знают свою работу, свои обязанности и у них нет плана действий в подобной ситуации, они не тренируются и не тестируют свои ресторайшн процедуры?
Скажем так, если допустить, что доля индусского аутсорсинга в IT банка Chase достаточно велика, то это весьма вероятно. Иначе сложно оправдать столь длительный system outage длительностью в три дня. Если бы я командовал дибиэями этого банка, такого бы не было.
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
P.S.Dmitry67, Komissar, zVlad - приятно было с Вами опять поболтать!
Увы, редко сюда заглядываю (даже сам не знаю почему), но убедился, что таки "не старееют душой ветераны!"
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
oMoses wrote:
В общем и целом, согласен, консервативный подход в деле администрирования баз данных есть благо. Но столь кардинально менять платформу в надежде, что все после этого станет очень и очень хорошо - большая глупость. К таким вещам нужно относиться философски и не спешить делать столь нелепые выводы.
Все это очень резонно. Только сейчас появилась такая тенденция убегать на DB2 с других СУБД. Может это следствие маркетинговой активности IBM, может у людей действительно проблемы. Одна контора даже middleware пишет (ANTS SsacSA ), который на лету транслирует T-SQL и PL/SQL в DB2 SQL.
oMoses wrote:
В общем и целом, согласен, консервативный подход в деле администрирования баз данных есть благо. Но столь кардинально менять платформу в надежде, что все после этого станет очень и очень хорошо - большая глупость. К таким вещам нужно относиться философски и не спешить делать столь нелепые выводы.
Все это очень резонно. Только сейчас появилась такая тенденция убегать на DB2 с других СУБД.
А откуда информация про тенденции?
Может это следствие маркетинговой активности IBM, может у людей действительно проблемы. Одна контора даже middleware пишет (ANTS SsacSA ), который на лету транслирует T-SQL и PL/SQL в DB2 SQL.
Оракл уже давно такое ПО написал (в другую сторону конечно) и распространяет его бесплатно в составе sql developer.
Flying Hen wrote:
Все это очень резонно. Только сейчас появилась такая тенденция убегать на DB2 с других СУБД. Может это следствие маркетинговой активности IBM, может у людей действительно проблемы. Одна контора даже middleware пишет (ANTS SsacSA ), который на лету транслирует T-SQL и PL/SQL в DB2 SQL.
Компания супруги отказалась от продления многолетнего контракта с IBM.
А по теме Чейза - последние две недели онлайн аккаунты работали отвратительно, медленно, постоянные таймауты. Так что проблема скорее всего была не внезапной, но по индусской традиции все было ОК пока не наступил конец.
zVlad wrote:Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.
Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!
Интересно, как они это доказали
Типа, у нас в логе ошибок нет?
IMHO, инфу для статьи слил представитель EMC, участвовавший в escalation.
Интересно что у нас одна атомная станция два года назад тоже почему то ушли с одного МФ на 8 System p серверов.
