JP Morgan Chase Oracle database outage

[zVlad]

....

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

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

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

[zVlad]

Action Request System, "Remedy" from BMC Software Inc.

Из описания в вики - эта система работает на разных БД, ну и случай описанный вами я бы например не реализовывал через БД локи, а делал некие логические локи(например флаг в таблице что доkумент открыт с соответствующим таймаутом), то есть на мой взгляд этот пример иррелевантен сравнению механизмов обеспечения concurrency и consistency в разных БД.

Это делается проще. В начальным момент когда я открываю запись в базе не локируется. Если я надумал запись модифицировать, то я должен кликнуть на некую кнопку ("Update") и тогда делается повторное чтение записи для апдайта и накладывается лок (штатными средствами БД, не важно какой - SELECT FOR UPDATE). Если эта запись уже кем-то взята для изменения, то wait-timeout и сообщение "недоступно для изменения повторите попытку позже". По окончании изменения клик на "Save", сохраниние и лок снимается.
В том с чем я работаю все поля формы открыты для изменения неважно собираюсь я их менять или просто зашел посмотреть. Следовательно никаких локов нет, что и приводит в итоге к проблемам когда я решил сохранить измененную запись.

[iDesperado]

Во-первых такого чтобы в один и тот же момент поступило сразу значительное количество инсертов в одну и ту же таблицу это еще надо постараться сделать.

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

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

может в МФ и есть такие ограничения, а вот у меня ограничений таких в процессоре нет. процессор у меня не один и в нем обычно 4 ядра и 8 параллельных потока, которые исключают ситуацию при которой бы, что либо выстроилось бы в очередь.
тригер обновляющий единственную запись итога это классическая ошибка проектирования, которую разбирают практически в любой книге по проектированию. у нас за такое проектирование архитекта бы уволили не разбираясь в причинах. просто по тому, что это азы.

[iDesperado]

Это делается проще. В начальным момент когда я открываю запись в базе не локируется. Если я надумал запись модифицировать, то я должен кликнуть на некую кнопку ("Update") и тогда делается повторное чтение записи для апдайта и накладывается лок (штатными средствами БД, не важно какой - SELECT FOR UPDATE). Если эта запись уже кем-то взята для изменения, то wait-timeout и сообщение "недоступно для изменения повторите попытку позже". По окончании изменения клик на "Save", сохраниние и лок снимается.

какой кашмар. у нас за такое вы бы снова удостоились бы увольнения:
В начальным момент когда я открываю запись в базе не локируется. Если я надумал запись модифицировать, то я должен кликнуть на некую кнопку ("Update")

пока вы нажимаете кнопку "Update", конкурирующая транзакция обновляет запись которую вы так и не удосужились залочить. в результате вы получите стандартный феномен lost update, затерев данные конкурентной транзакции, о которой вы и не подозревали.
так делать нельзя!

[crypto5]

Если эта запись уже кем-то взята для изменения, то wait-timeout и сообщение "недоступно для изменения повторите попытку позже". По окончании изменения клик на "Save", сохраниние и лок снимается.

Этот подход имеет недостатки: в случае открытия уже залоченного документа пользователю нужно ждать тайм аута транзакции что бы узнать что документ залочен, а это может быть продолжительное время. В случае логического лока, он моментально увидит сообщение об этом. К тому же на листах документов можно будет без проблем отмечать залоченные документы специальной иконкой и давать информацию кто залочил. Еще в случае логического лока можно будет выставлять тайм аут лока отличный от размера тайм аута субд.

[mynameiszb]

Этот подход имеет недостатки: в случае открытия уже залоченного документа пользователю нужно ждать тайм аута транзакции что бы узнать что документ залочен, а это может быть продолжительное время. В случае логического лока, он моментально увидит сообщение об этом. К тому же на листах документов можно будет без проблем отмечать залоченные документы специальной иконкой и давать информацию кто залочил. Еще в случае логического лока можно будет выставлять тайм аут лока отличный от размера тайм аута субд.

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

[crypto5]

Этот подход имеет недостатки: в случае открытия уже залоченного документа пользователю нужно ждать тайм аута транзакции что бы узнать что документ залочен, а это может быть продолжительное время. В случае логического лока, он моментально увидит сообщение об этом. К тому же на листах документов можно будет без проблем отмечать залоченные документы специальной иконкой и давать информацию кто залочил. Еще в случае логического лока можно будет выставлять тайм аут лока отличный от размера тайм аута субд.

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

Есть уже устоявшиеся паттерны как такое обходить, например хранить в базе дату истечения лока.

[mynameiszb]

Есть уже устоявшиеся паттерны как такое обходить, например хранить в базе дату истечения лока.

Возможно. Но вопрос тогда - зачем городить логический огород, если то же самое сообщение о залоченной записи другим пользователем мы получаем при выставлении физической блокировки?

[iDesperado]

Возможно. Но вопрос тогда - зачем городить логический огород, если то же самое сообщение о залоченной записи другим пользователем мы получаем при выставлении физической блокировки?

вебное стейтлес приложение, например.
ну или connection pool, пока пользователь заполняет форму его коннекция могла бы обслужить сотню запросов, а так мертвым грузом висит удерживая блокировку напрасно кушая ту же память.
физической блокировкой придется руками воротить кучу функционала, например как/чем убивать транзакции если какой-то лапоть оставил открытым окно не завершив транзакции. а логическую любой фреймворк из коробки обеспечит без лишнего программирования.

[mynameiszb]

а логическую любой фреймворк из коробки обеспечит без лишнего программирования.

Понял.
А живые примеры есть таких фреймворков?

[iDesperado]

Понял.
А живые примеры есть таких фреймворков?

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

[mynameiszb]

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

Хорошо, сам пороюсь, когда приспичит. Я пока в живую с подобным просто не сталкивался...

[zVlad]

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

И пару слов относительно консистенси. Остается все таки в силе возможность использовать более рестриктед уровни изоляции чтобы на фоне ОЛТП получать консистент репортс. И вовсе не верно что в результате получается однопользовательская БД при этом. Но важнее то что такие репорты когда вовлекаются текущие данные ОЛТП никому не нужны, просто по той причине что сразу после получения такого репорта все изменится и репорт уже не отражает текущую (то что нам нужно было) ситуацию. Зачем нужно банку знать сумму остатков по счетам его клиентов, скажим в 11:15 am если известно что в течении дня в БД банка отражаются только транзакции внутри банка, и следовательно общий баланс остается таким же каким был на момент открытия банка, или на любой другой момент времени до того как придут данные из других банков, а приходят они не в онлайн режиме как известно.
По этому на практике репорты строятся как правило на определенный момент времени по определенным графикам и следовательно данные для такого репорта вряд ли нужны ОЛТП процессам.
Тут с насмешкой поминался "банковсий" день который якобы только и можно реализовать на МФ. На самом деле это называется "операционный" день и он существует во всех банках на любых используемых банками платформах. Так банковская система устроена. А если когда-нибудь останется в мире один единственный банк то ему тем более не нужны будут отчеты о сумме остатков по счетам клиентов, просто потому что эта сумма будет константой, по крайней мере эта сумма будет меняться гораздо реже чем переводы с одного клиентского счета на другой.

P.S. Я ничего не сказал про ДБ2 - это не порядок. В ДБ2 мы полностью полагаемся на ее механизм блокировок. В ДБ2 (по крайней мере на МФ) использоется большое количество разных типов локов (не один иначе говоря), и в ДБ2 для это используется отдельная компонента называемая IRLM - Internal Resource Lock Manager, который выполняется в собственном AS и занимается только локами. Программисты для ДБ2 на МФ вообще мало что знают о локах и как правило используют накатанные подходы не особо вдумываясь в них. В результате нам, DBA, порой приходится с программистами проводить разъяснительную работу о том что надо делать чтобы не только написать программу, но и сделать так чтобы программа работала эффективно в многопользовательской среде выполнения.

[Dmitry67]

Ну то что вы нерите, это ваши проблемы, тем не менее это так. Да что за примерами ходить - возьмите мой пример с ОДНОЙ таблицей (куда уж проще) и предложите работающее решение

ЧТо касается точности отчетов. Мне сходу не привести пример когда это критично (прошу помощи у зала, в тяпницу голова плохо работает)

Но я приведу другой пример. Неконстистетные отчеты (даже если точность не нужна) могу обладать иными странностями.
Ну например, пусть у неких объектов есть владелец (комнаты в отеле и проживающие, владельцы счетов итд).
пусть владелец может владеть только одним объектом (ну например проживающий и комната где он находится)
Inconsistent report может вернуть данные, что один человек назодится в двух комнатах однвоременно, а другие люди могут вообще потеряться.
Это может для ряда случаев тоже не смертельно, но вообще то хреново (например, вы не можете рассчитывать на уникальность некоторых колонок итд)

[zVlad]

Ну то что вы нерите, это ваши проблемы, тем не менее это так. Да что за примерами ходить - возьмите мой пример с ОДНОЙ таблицей (куда уж проще) и предложите работающее решение

ЧТо касается точности отчетов. Мне сходу не привести пример когда это критично (прошу помощи у зала, в тяпницу голова плохо работает)

Но я приведу другой пример. Неконстистетные отчеты (даже если точность не нужна) могу обладать иными странностями.
Ну например, пусть у неких объектов есть владелец (комнаты в отеле и проживающие, владельцы счетов итд).
пусть владелец может владеть только одним объектом (ну например проживающий и комната где он находится)
Inconsistent report может вернуть данные, что один человек назодится в двух комнатах однвоременно, а другие люди могут вообще потеряться.
Это может для ряда случаев тоже не смертельно, но вообще то хреново (например, вы не можете рассчитывать на уникальность некоторых колонок итд)

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

[crypto5]

- сам Оракл делает это как-то не очень

А конкретнее? Дискуссия логические против native DB локов велась безотносительно конкретной БД, и все вышесказанное абсолютно абстрагировано от конкретной БД.

и поэтому программисты для Оракл придумали некие "логические" локи и создали разные внешние относительно Оракл фрэймворки и функционалы.

Не поэтому, и не для оракл, а для любой БД, и как мы узнали - не создали..

[zVlad]

- сам Оракл делает это как-то не очень

А конкретнее? Дискуссия логические против native DB локов велась безотносительно конкретной БД, и все вышесказанное абсолютно абстрагировано от конкретной БД.

и поэтому программисты для Оракл придумали некие "логические" локи и создали разные внешние относительно Оракл фрэймворки и функционалы.

Не поэтому, и не для оракл, а для любой БД, и как мы узнали - не создали..

Как я уже сказал, но Вы как обычно не придали этому значение, в ДБ2 нет такой проблематики. В ДБ2 используются native локи и трудно, даже я бы сказал невозможно, представить чем логические локи могли бы помочь ДБ2, наоборот они бы все испортили. Как минимум это верно хотя бы потому что native локи в ДБ2 мы не можем отключить, разве что для селектов.
Так что Вы не правы считая что все базы данные одинаковы в этом плане. Не одинаковы. Я не знаю что творится в Оракл с этим, и в MS SQL, но за ДБ2 я готов отвечать определенно.

[crypto5]

- сам Оракл делает это как-то не очень

А конкретнее? Дискуссия логические против native DB локов велась безотносительно конкретной БД, и все вышесказанное абсолютно абстрагировано от конкретной БД.

и поэтому программисты для Оракл придумали некие "логические" локи и создали разные внешние относительно Оракл фрэймворки и функционалы.

Не поэтому, и не для оракл, а для любой БД, и как мы узнали - не создали..

Как я уже сказал, но Вы как обычно не придали этому значение, в ДБ2 нет такой проблематики. В ДБ2 используются native локи и трудно, даже я бы сказал невозможно, представить чем логические локи могли бы помочь ДБ2, наоборот они бы все испортили. Как минимум это верно хотя бы потому что native локи в ДБ2 мы не можем отключить, разве что для селектов.
Так что Вы не правы считая что все базы данные одинаковы в этом плане. Не одинаковы. Я не знаю что творится в Оракл с этим, и в MS SQL, но за ДБ2 я готов отвечать определенно.

Вы просто невнимательно читали дискуссию:
- как дб2 native локи спасают от того что connection в connection пуле в j2ee приложении нельзя реюзать, пока лок не снят?
- как мне приатачить дополнительную информацию к локу что бы в списке документов показать юзеру кто и когда залочил документ?
- как вы предлагаете проверять залочен ли документ или нет во время отркытия?

Я не знаю что творится в Оракл с этим, и в MS SQL

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

[zVlad]

....
....
- как мне приатачить дополнительную информацию к локу что бы в списке документов показать юзеру кто и когда залочил документ?
- как вы предлагаете проверять залочен ли документ или нет во время отркытия?

- Во-первых при наступлении нежелательного события, связанного с локами (таймаут или дэдлок) DB2 выдает сообщение со всем необходимым что можно пожелать знать об этом:

Code: Select all

04.57.27 STC15040  DSNT376I  -DB04 PLAN=DISTSERV WITH  636
   636                     CORRELATION-ID=adbagent.exe
   636                     CONNECTION-ID=SERVER
   636                     LUW-ID=GA00530F.I207.594C18041100=69
   636                     THREAD-INFO=NHWMS1:*:NHWMS1:adbagent.exe
   636                     IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=B4BPASS WITH
   636                     CORRELATION-ID=E7MIN10P
   636                     CONNECTION-ID=BATCH
   636                     LUW-ID=NET.DB04LU.C699519D5BE0=14877
   636                     THREAD-INFO=SS4XX:*:*:*
   636                     ON MEMBER DB04
   636
04.57.27 STC15040  DSNT501I  -DB04 DSNILMCL RESOURCE UNAVAILABLE  637
   637                        CORRELATION-ID=adbagent.exe
   637                        CONNECTION-ID=SERVER
   637                        LUW-ID=GA00530F.I207.594C18041100=69
   637                        REASON 00C9008E
   637                        TYPE 00000304
   637                        NAME TB04BDB .STBPKMST.X'000163' '.X'04'

- До наступления нежелательного события можно (но не нужно) использовать Instrumentation Facility Interface (IFI) с кодами instrumentation facility component identifiers (IFCIDs) 0149 и 0150:

0149
Information indicating who (the thread identification token) is holding locks and waiting for locks on a particular resource and hash token. The data provided is in the same format defined for IFCID 0150.

0150
All the locks held and waited on by a given user or owner (thread identification token).

[zVlad]

....- как дб2 native локи спасают от того что connection в connection пуле в j2ee приложении нельзя реюзать, пока лок не снят?
....

Я не Java программист и никогда им не был, поэтому мне нечего сказать по этому поводу кроме того что не думаю что в случае ДБ2 эта проблема (если она вообще имеет место быть) трудноразрешима.

[zVlad]

....

Я не знаю что творится в Оракл с этим, и в MS SQL

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

Я сделал предположение на основании развернувшейся дискуссии по поводу "логических локов", которые я знаю не имеют отношение к ДБ2.

[crypto5]

....
....
- как мне приатачить дополнительную информацию к локу что бы в списке документов показать юзеру кто и когда залочил документ?
- как вы предлагаете проверять залочен ли документ или нет во время отркытия?

- Во-первых принаступлении нежелательного события (таймаут или дэдлок) DB2 выдает сообщение со всем необходимым что можно пожелать знать об этом:

Code: Select all

04.57.27 STC15040  DSNT376I  -DB04 PLAN=DISTSERV WITH  636
   636                     CORRELATION-ID=adbagent.exe
   636                     CONNECTION-ID=SERVER
   636                     LUW-ID=GA00530F.I207.594C18041100=69
   636                     THREAD-INFO=NHWMS1:*:NHWMS1:adbagent.exe
   636                     IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=B4BPASS WITH
   636                     CORRELATION-ID=E7MIN10P
   636                     CONNECTION-ID=BATCH
   636                     LUW-ID=NET.DB04LU.C699519D5BE0=14877
   636                     THREAD-INFO=SS4XX:*:*:*
   636                     ON MEMBER DB04
   636
04.57.27 STC15040  DSNT501I  -DB04 DSNILMCL RESOURCE UNAVAILABLE  637
   637                        CORRELATION-ID=adbagent.exe
   637                        CONNECTION-ID=SERVER
   637                        LUW-ID=GA00530F.I207.594C18041100=69
   637                        REASON 00C9008E
   637                        TYPE 00000304
   637                        NAME TB04BDB .STBPKMST.X'000163' '.X'04'

Я не хочу дожидаться таймаута, что бы узнать что документ залочен.

- До наступления нежелательного события можно (но не нужно) использовать Instrumentation Facility Interface (IFI) с кодами instrumentation facility component identifiers (IFCIDs) 0149 и 0150:

0149
Information indicating who (the thread identification token) is holding locks and waiting for locks on a particular resource and hash token. The data provided is in the same format defined for IFCID 0150.

0150
All the locks held and waited on by a given user or owner (thread identification token).

Так нужно или не нужно? Какое правильное решение этой задачи вы предлагаете для ДБ2?

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

Ну и опять же в случае логического лока всю информацию я получаю одним простым портабельным селектом, вы считаете что ваш способ столь же прост?

[crypto5]

....- как дб2 native локи спасают от того что connection в connection пуле в j2ee приложении нельзя реюзать, пока лок не снят?
....

Я не Java программист и никогда им не был, поэтому мне нечего сказать по этому поводу кроме того что не думаю что в случае ДБ2 эта проблема (если она вообще имеет место быть) трудноразрешима.

Ну а вам не сложно было бы обьяснить что дает вам основания так думать?

[crypto5]

....

Я не знаю что творится в Оракл с этим, и в MS SQL

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

Я сделал предположение на основании развернувшейся дискуссии по поводу "логических локов", которые я знаю не имеют отношение к ДБ2.

Еще раз - они(логические локи) имеют такое же отношение к ораклу как и к ДБ2.

[Zombie416]

- Во-первых при наступлении нежелательного события, связанного с локами (таймаут или дэдлок) DB2 выдает сообщение со всем необходимым что можно пожелать знать об этом:

Пример: Простая система с одной таблицей "Customers" и многими клерками, которые могут забивать туда информацию.

Клерк №1 меняет адрес пользователя John Smith, разговаривая с его секретаршей по телефону и некоторым образом заблокировав запись. При этом сам John Smith звонит по другому телефону клерку №2, и тоже хочет поменять адрес.

Принимая что запись блокируется на уровне базы:

Вопрос №1: сколько времени пройдет пока клерк №2 узнает что запись заблокирована и кем?

Вопрос №2: какое выражение лица будет у клерка №2 когда он увидит на экране подобное сообщение " со всем необходимым что можно пожелать "?