JP Morgan Chase Oracle database outage

[oMoses]

По моему тут как раз все логично. Если верхний уровень попросил записать бредовый блок в базу, то нижние уровни должны as is этот бред отмиррорить и в бэкап положить - им же пофиг что на странице записано.

Не совсем так. Если по минимуму, то нижний уровень должен был отрапортовать о наличии плохого блока, а правильный DBA - выловить это сообщение и вовремя, а главное верно, отреагировать.

А как нижний уровень догадается что блок плохой?

Интеллектуальный нижний уровень должен проверять data block checksum перед и после записи. Правда, это неплохо работает для intrablock corruptions, но вовсе не так просто вычислить при interblock corruptions.

[Dmitry67]

Я тоже хотел спросить. Чаще всего нижний уровень об этом догадаться не может
С другой стороны, в этом случае просто были бы на одной страницы неправильные данные, типа вместо Varchar 'John Smith' было бы 'Jo@@MJ@*$&%*#@Mith'
Под '4 corrupted files' понимается чтото куда большее.
Вообще конечно без технических деталей это гадание на кофейной гуще.

[zVlad]

... Согласен - достоверных данных очень мало. Я более чем уверен, что индусы в IT Chase bank валят вину на все, что не движется, как-то Oracle, EMC и "third-party software" - это нормально потому как ставки высоки и непременно последуют (если уже не последовали) оргвыводы...

Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.

[crypto5]

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

А Вы ссылку то в первом сообщении этой темы изучали?

Изучил. А вы?

[oMoses]

Использование 8-ми Соляр с Оракл в крупном банке - это глупость.

4-node Oracle RAC + 4-node standby (Oracle Max Availability Architecture) = это как раз the must! Другое дело, похоже, что именно этого-то у Chase и не было. Иначе бы не было и столь длительного outage...

[oMoses]

Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.

Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!

[Dmitry67]

А как нижний уровень догадается что блок плохой?

Интеллектуальный нижний уровень должен проверять data block checksum перед и после записи. Правда, это неплохо работает для intrablock corruptions, но вовсе не так просто вычислить при interblock corruptions.[/quote]

Это работает если вы прочитали блок и checksum не совпала
В случае же записи:

1 формируем данные на странице
2 считаем checksum
3 записываем в базу

checksum никак не помогает если #1 сформировал бред.

[zVlad]

Использование 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.

[Dmitry67]

Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.

Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!

Интересно, как они это доказали
Типа, у нас в логе ошибок нет?

[oMoses]

Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое third-party software) просто дропнул ценную табличку с данными (скажем, паролями on-line пользователей веб-серверов банка). Естественно, что это-же послушно произошло и на standby database, если данные с primary db туда накатываются без задержки. или ошибка была обнаружена уже по истечению таковой. Далее, конечно, постребовалось восстанавливаться с бэкапов, поскольку, вероятно, содержать flashback для такой напряженной базы было очень накладно...

Ну а восстановление - это целая отдельная песня. Быстро спеть её (посредством уникальных и дорогих средств EMC/Veritas/Solaris) почему-то не получилось, и пришлось петь медленно (Oracle RMAN?). А три дня потеряли на анализ ситуации и различные попытки восстановления... Oracle datafile corruption вполне могли вылезти вследствии неудачных первых попыток и усугубить ситуацию - ведь наверняка сделать копию всего сервера перед восстановлением было некогда....

[crypto5]

Похоже что и Вы тоже не читали ссылку, с которой начали свою же тему. Про ЕМС там написано в частности явно и про другое что ускользнуло от Вашего в том числе внимания.

Да помню-помню - дескать, после тщательного изучения, EMC storage was ruled out! Просто кто-то от EMC быстрее подсуетился и доказал, что storage здесь был не при чем. Оно и понятно - репутация целой конторыц была поставлена на кон. Oracle отбится будет сложнее... Еще и потому, что Oracle + Sun теперь одна контора!

Интересно, как они это доказали
Типа, у нас в логе ошибок нет?

Там проверяли версию с проблемой в контроллере, о полной верификации абсолютной правильности решения от ЕМС речь конечно же не идет.

[Dmitry67]

Вообще к сожалению ситуация сейчас еще больше усугубляется.

Я наблюдаю конторы где production сервера SQL server держат базы в SIMPLE mode (для людей из мира Oracle и DB2 - это когда транзакции после записи в transaction log сразу оттуда чистятся, так что есть только FULL backups, как правило раз в день, а 'накатка' невозможна). Объяснение - 'ну, SAN же никогда не ошибается' (знаю. дважды помогал восстанавливать базы изза проблем с SAN). Сами бэкапы пишут, конечно же, на то же устройство. Мир сошел с ума.

[Dmitry67]

Еще меня умиляет когда клиенты A и B требуют, чтобы их базы лежали на разных Windows server/SQL server.
То, что эти виртуальные сервера лежат на одном ESX server, и базы лежат на одном SAN, их не волнует.

[zVlad]

Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое third-party software) просто дропнул ценную табличку с данными (скажем, паролями on-line пользователей веб-серверов банка). Естественно, что это-же послушно произошло и на standby database, если данные с primary db туда накатываются без задержки. или ошибка была обнаружена уже по истечению таковой. Далее, конечно, постребовалось восстанавливаться с бэкапов, поскольку, вероятно, содержать flashback для такой напряженной базы было очень накладно...

Ну а восстановление - это целая отдельная песня. Быстро спеть её (посредством уникальных и дорогих средств EMC/Veritas/Solaris) почему-то не получилось, и пришлось петь медленно (Oracle RMAN?). А три дня потеряли на анализ ситуации и различные попытки восстановления... Oracle datafile corruption вполне могли вылезти вследствии неудачных первых попыток и усугубить ситуацию - ведь наверняка сделать копию всего сервера перед восстановлением было некогда....

Из сказанного Вами следует что Вы подозреваете DBAs JPMorgan Chase в том что они плохо знают свою работу, свои обязанности и у них нет плана действий в подобной ситуации, они не тренируются и не тестируют свои ресторайшн процедуры?

[oMoses]

Кстати, я не исключаю самого тривиального случая - кто-то (а может как раз то самое пресловутое 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 длительностью в три дня. Если бы я командовал дибиэями этого банка, такого бы не было.