JP Morgan Chase Oracle database outage

[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" зачастую под собой скрывает много разного, не только "бэкапы и профилактическое распитие пива"

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

[zVlad]

...

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

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

Никаких костылей. Выполняем два запросa, один с SKIP LOCKED DATA другой с WITH UR отбрасываем билеты присутствующие в обоих наборах, остальные будет те что заблокированы.

[KinDzaDza]

...

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

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

Никаких костылей. Выполняем два запросa, один с SKIP LOCKED DATA другой с WITH UR отбрасываем билеты присутствующие в обоих наборах, остальные будет те что заблокированы.

zVlad, а как Вы предлагаете решать вопрос с количеством пользователей, которые смогут одновременно пользоваться этой системой по Вашему сценарию. Ведь при использовании найтив-локов на уровне базы (пофиг какой), надо держать соединение открытым с незавершенной транзакцией и закрепленным за этим самым юзером все то время, пока сам юзер не снимет лок (купив/отказавшись) или пока не истечет тайм-аут на лок (бронь). А если юзеров тысячи?

[crypto5]

...

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

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

Никаких костылей. Выполняем два запросa, один с SKIP LOCKED DATA другой с WITH UR отбрасываем билеты присутствующие в обоих наборах, остальные будет те что заблокированы.

И вы прочитаете в том числе например билеты которые только занесены в систему, но транзакции которых еще не закомичены.

[crypto5]

...

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

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

Никаких костылей. Выполняем два запросa, один с SKIP LOCKED DATA другой с WITH UR отбрасываем билеты присутствующие в обоих наборах, остальные будет те что заблокированы.

zVlad, а как Вы предлагаете решать вопрос с количеством пользователей, которые смогут одновременно пользоваться этой системой по Вашему сценарию. Ведь при использовании найтив-локов на уровне базы (пофиг какой), надо держать соединение открытым с незавершенной транзакцией и закрепленным за этим самым юзером все то время, пока сам юзер не снимет лок (купив/отказавшись) или пока не истечет тайм-аут на лок (бронь). А если юзеров тысячи?

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

[KinDzaDza]

zVlad, а как Вы предлагаете решать вопрос с количеством пользователей, которые смогут одновременно пользоваться этой системой по Вашему сценарию. Ведь при использовании найтив-локов на уровне базы (пофиг какой), надо держать соединение открытым с незавершенной транзакцией и закрепленным за этим самым юзером все то время, пока сам юзер не снимет лок (купив/отказавшись) или пока не истечет тайм-аут на лок (бронь). А если юзеров тысячи?

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

А, ну это как в анекдоте про мышей и Мудрого Филина.

[Dmitry67]

KinDzaDza, +1 !!!

[zVlad]

....И вы прочитаете в том числе например билеты которые только занесены в систему, но транзакции которых еще не закомичены.

Что это за билеты такие?

[zVlad]

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

Не надо за меня отвечать.

[crypto5]

....И вы прочитаете в том числе например билеты которые только занесены в систему, но транзакции которых еще не закомичены.

Что это за билеты такие?

Билеты которые находятся в состоянии между insert into tickets и commit.

[crypto5]

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

Не надо за меня отвечать.

Да, ответьте за себя сами

[Flying Hen]

И все же, может кто нибудь выложить screenshot с select и результатом - не важно каким - просто интересно как 'выглядит рабочее' место DBA DB2

Рабочее место с принципе выглядит аналогично любой другой базе. Есть командная строка, довольно неуклюжий, но юзабельный Control Center, еще какие-то гуёвые тулзы, которые лично я не использую. Есть сторонние продукты, работающие с DB2 точно также, как с другими базами.
CLP
Control Center
Visual Explain

[Dmitry67]

Интересно, почему такие большие фирмы (IBM, Oracle) так мало уделяют усилий созданию GUI к своим базам
Для MS SQL я вообще ни разу не видел DBA, у которого основным бы не был Enterprise manager/Management Studio от Microsoft.
Мне даже не известны конкуренты в данной нише (хотя есть куча 3rd party tools для вспомогательных вещей)

[iDesperado]

Интересно, почему такие большие фирмы (IBM, Oracle) так мало уделяют усилий созданию GUI к своим базам
Для MS SQL я вообще ни разу не видел DBA, у которого основным бы не был Enterprise manager/Management Studio от Microsoft.
Мне даже не известны конкуренты в данной нише (хотя есть куча 3rd party tools для вспомогательных вещей)

ну про оракл вы зря, оракловый EM (вебный) сегодня фору даст майкрософту как по удобству так и по наворотам. менеджмент студия у МС мягко говоря не очень наворочена, сравните с pl/sql developer или Toad (3rd party tools). кстати один из конкурентов Toad for MSSQL.
сам же оракл свой sqldeveloper потихоньку пилит, до pl/sql developer или Toad ему далеко, но на фоне менеджмент студии как минимум не уступает в наворочености. единственно жава гуй тяжеловат имхо.

[zVlad]

Интересно, почему такие большие фирмы (IBM, Oracle) так мало уделяют усилий созданию GUI к своим базам
Для MS SQL я вообще ни разу не видел DBA, у которого основным бы не был Enterprise manager/Management Studio от Microsoft.
Мне даже не известны конкуренты в данной нише (хотя есть куча 3rd party tools для вспомогательных вещей)

Дима, извините, но Вы наивный человек. С одной стороны Вы говорите у Вас сотни серверов, с другой Вы надеетесь кликами их администрировать (и видимо администрируете, я не понимаю как). У меня был опыт работы с репликацией в MS SQL из DB2 на МФ. Там был только GUI интерфейс в том числе Enterprise Manager если не ошибаюсь. Так это была каторга. Чтобы одну таблицу "зарядить" в репликацию нужно было на стороне MS SQL "кликнуть" раз двадцать. А у нас больше 500 таблиц реплицируется.

Наш стиль на МФ таков чтобы все работы однажды спроектированные далее выполнялись в автоматическом режиме. GUI используется только для анализа проблем, наблюдения и поиск корневой причины. Фиксаем и управляем мы только через интерфэйс терминала 3270 (это конечно не GUI в современном виде, но это и не командная строка telnet-a Unix. 3270 - это полноэкранный режим работы, т.е. в виде форм с полями и даже некоторой имитацией окон. Более чем достаточно).

[Dmitry67]

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