JP Morgan Chase Oracle database outage

[Dmitry67]

Ваш начальник
Подойдет и спросит - zVlad, а правда что такая то база не использовадлась долго? Там вроде таблица лога есть, посмотрите какая самая последняя запись?
Или вы скажете: это не мое дело, пусть программисты занимаются? На MS SQL такие вещи глянуть - 5 сек.

[iDesperado]

Я согласен что в своем первом примере с select for update Влад был не прав, но в данной ветке обсуждается уже другой пример.

в пылу я не заметил.

..., то не надо принимать его "близко к сердцу". Я не практикующий программист, как Вы уже наверняка поняли, я лишь бывший DB2 DBA, и как выяснилось с устревшими представлениями (я вместе с вами узнал про SKIP LOCKED DATA пару дней назад). Возможно бронировать надо просто UPDATE.

ну вот видите, а говорили мы вам ничего нового по db2/zOS не расскажем

[zVlad]

.....

..., то не надо принимать его "близко к сердцу". Я не практикующий программист, как Вы уже наверняка поняли, я лишь бывший DB2 DBA, и как выяснилось с устревшими представлениями (я вместе с вами узнал про SKIP LOCKED DATA пару дней назад). Возможно бронировать надо просто UPDATE.

ну вот видите, а говорили мы вам ничего нового по db2/zOS не расскажем

Премного вам благодарен. Почти пять лет без практики в DB2 дали себя знать. Вы подтянули мой уровень немного.

[zVlad]

Ваш начальник
Подойдет и спросит - zVlad, а правда что такая то база не использовадлась долго? Там вроде таблица лога есть, посмотрите какая самая последняя запись?
Или вы скажете: это не мое дело, пусть программисты занимаются? На MS SQL такие вещи глянуть - 5 сек.

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

[Dmitry67]

zVlad, по моему вы там совсем выработали tunnel vision в своем сферическом environment в вакууме на МФ. Вас надо для расширения кругозора отправить в стартап какой нибудь месяцев на шесть - чтобы дедлайн был завтра, что делать было бы непонятно, и чтобы все вокруг бегали с круглыми глазами и рвали на себе волосы.

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

[zVlad]

zVlad, по моему вы там совсем выработали tunnel vision в своем сферическом environment в вакууме на МФ. Вас надо для расширения кругозора отправить в стартап какой нибудь месяцев на шесть - чтобы дедлайн был завтра, что делать было бы непонятно, и чтобы все вокруг бегали с круглыми глазами и рвали на себе волосы.

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

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

[Flash-04]

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

у нас примерно так и есть. DBA обычно занимаются только "тех.обслуживанием". Я к примеру могу посмотреть внутрь своей DB, но обычно и этого не надо. Хотя при траблшутинге мне support говорит какие квери надо запустить. Т.е. я такой полу-DBA

[Dmitry67]

А я квери пишу, хотя подо мной сейчас 114 production servers.
Какие квери? Собираю размеры таблиц для оченки скорости их роста, скорость выполнения jobs,
количество записанных объектов определенного типа опять таки для long term trends.
Еще есть куча метрик.

[crypto5]

Ваш начальник
Подойдет и спросит - zVlad, а правда что такая то база не использовадлась долго? Там вроде таблица лога есть, посмотрите какая самая последняя запись?
Или вы скажете: это не мое дело, пусть программисты занимаются? На MS SQL такие вещи глянуть - 5 сек.

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

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

[mynameiszb]

В Вашей практике, Дима, роль DBA слишком расплывчата, что может быть приемлемо для стартапа, но не для ответственной продакшн системы, например, в банках, или атомной энергетики.

Ну, здесь раз на раз не приходится, zVlad.

Когда я сидел в Дойчебанке, то у меня основной задачей было - саппорт девелоперских и тестовых серверов. А еще - preproduction/production migration, а еще - саппорт ряда боевых как "чистого dba", так и в рамках анализа внедренной системы и помощь девелопменту в оптимизации работающей системы и внедрения новых фич. Плюс - участие в разработке новых вещей с точки зрения админа. Плюс - верификация кода, выкладываемого на базу (организация таблиц, ключей, запросы, серверный и клиентский код и пр.).

Все сильно зависит от того, на каком участке трудишься.

Те же production support dba из Лондона и Штатов - были более узко заточены на поддержку боевых систем + любой экстренный подъем упавших систем.

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

[zVlad]

А я квери пишу, хотя подо мной сейчас 114 production servers.
Какие квери? Собираю размеры таблиц для оченки скорости их роста, скорость выполнения jobs,
количество записанных объектов определенного типа опять таки для long term trends.
Еще есть куча метрик.

А я один раз написал такие запросы и создал процесс их регулярного выполнения с цохранинием результатов в БД и с использованием их в процессе реорганизации табличных пространств (вычисление размера для будущего роста, простая эсстраполяция), и вот уже несколько лет ни писать не выполнять такие запросы нет нужды.

[zVlad]

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

И Вы туда же, нереальные примеры приводите. Любой вменяемый человек понимает что список заблокированных билетов постоянно меняется и очень сильно.
Хотя течнически я не вижу здесь особой проблемы - мне пришло в голову быстрое решение, возможно там есть подводные камни, но решение есть на мой взгляд. Интересны, Вы, пройдя некоторый самостоятельный курс освоения DB2 for zOS поймете что я имею в виду?

[zVlad]

В Вашей практике, Дима, роль DBA слишком расплывчата, что может быть приемлемо для стартапа, но не для ответственной продакшн системы, например, в банках, или атомной энергетики.

Ну, здесь раз на раз не приходится, zVlad.

Когда я сидел в Дойчебанке, то у меня основной задачей было - саппорт девелоперских и тестовых серверов. А еще - preproduction/production migration, а еще - саппорт ряда боевых как "чистого dba", так и в рамках анализа внедренной системы и помощь девелопменту в оптимизации работающей системы и внедрения новых фич. Плюс - участие в разработке новых вещей с точки зрения админа. Плюс - верификация кода, выкладываемого на базу (организация таблиц, ключей, запросы, серверный и клиентский код и пр.).

Все сильно зависит от того, на каком участке трудишься.

Те же production support dba из Лондона и Штатов - были более узко заточены на поддержку боевых систем + любой экстренный подъем упавших систем.

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

У DB2 for zOS есть такая возможность сконфигурировать права что DBA не сможет смотреть данные в таблицах, но сможет выполнять свои действительно DBA функции.

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

[crypto5]

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

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

Ну да, как всегда мегаадмины правят миром и решают что кому нужно

Хотя течнически я не вижу здесь особой проблемы - мне пришло в голову быстрое решение, возможно там есть подводные камни, но решение есть на мой взгляд. Интересны, Вы, пройдя некоторый самостоятельный курс освоения DB2 for zOS поймете что я имею в виду?

Я верю что можно придумать кучу костылей, но при логическом локе я напишу очень простой sql, а как там в случае с native локами? Озвучите?

[mynameiszb]

У DB2 for zOS есть такая возможность сконфигурировать права что DBA не сможет смотреть данные в таблицах, но сможет выполнять свои действительно DBA функции.

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

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

Речь не о том. Я хочу сказать, что аббревиатура "dba" зачастую под собой скрывает много разного, не только "бэкапы и профилактическое распитие пива"

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