JP Morgan Chase Oracle database outage

[zVlad]

....
Этой статье в декабре исполнится шесть лет. А Вы на полном серьезе говорите "не столь вопиющи как раньше, но они есть.". А может уже и нет, шесть лет срок не малый, согласитесь. В статье используются данные о DB2 v7 и v8. DB2 v7 уже давно даже не саппортается ИБМ-ом и вот-вот появится DB2 v10.

а вот тут мне кажется вы потеряли нить. я утверждал, что db2/zOS и db2/LUW это разные субд имеющие разные архитектуры и ветки кода и соответственное разное все остальное, в том числе и языки SQL и SQLPL. то что различий в языках сегодня меньше чем 6 лет назад говорит только о том IBM выделила больше ресурсов на рихтование внешнего сходства продуктов db2, но никак не опровергает суть моих утверждений. т.е. степень актуальности статьи сегодня не меняет сути.
кстати и вы косвенно подтверждаете: на МФ принято писать статик приложения, а LUW вот тяготеет к SQLPL. и я согласен, просто эти субд из разных миров ...

У Вас неправильная причинно-следственная связь. Не потому языки разные что ветки кода и архитектура разные, а скорее потому что языки не могут быть сто процентно одинаковы потому и ветки кода разные. Кроме того язык , на котором написана ДБ2 - это ассемблер МФ. Такого языка нет больше нигде. И никогда не будет. Различия в SQL И SQLPL уменьшается, но никогда не будет сведено к нулю просто потому что разработчики на МФ никогда не откажутся от тех прелестей которые они имеют на МФ и которых нет на других платформах. Тем не менее, если перед девелопером ставится задача написать приложение так чтобы оно без переделки выполнялось на любой платформе у него есть для этого Gross-platform SQL Reference, заметьте не перечень отличий, а полноценный документ с описанием того подмножества языков SQL и SQLPL DB2 которое одинаково и на zOS и на LUW и еще где-то. Так устраивает.

[Flying Hen]

С чего Вы взяли что это невозможно в ДБ2? Если Вы имеете в виду "dirty-red", то это ведь не единственно возможный, есть и другие, которые дают consistent reports.

можете описать хотя бы один способ ?

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

[zVlad]

С чего Вы взяли что это невозможно в ДБ2? Если Вы имеете в виду "dirty-red", то это ведь не единственно возможный, есть и другие, которые дают consistent reports.

можете описать хотя бы один способ ?

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

Дорого в каком смысле? А есть еще и Read Stability.

[Flying Hen]

Дорого в каком смысле? А есть еще и Read Stability.

Дорого в том смысле, что блокирует таблицу, AFAIK. Read Stability не спасает от фантомов, то есть новых записей, вставленных другими транзакциями пока мы трудились над нашим отчетом.

[zVlad]

Дорого в каком смысле? А есть еще и Read Stability.

Дорого в том смысле, что блокирует таблицу, AFAIK. Read Stability не спасает от фантомов, то есть новых записей, вставленных другими транзакциями пока мы трудились над нашим отчетом.

Это если повторять запрос в рамках одной транзакции. А зачем нам его повторять? Выполнили запрос единожды, и строим репорт. Никаких фантомов нет, uncommitted данных тоже. Все в порядке - цель достигнута.

[Flying Hen]

Дорого в каком смысле? А есть еще и Read Stability.

Дорого в том смысле, что блокирует таблицу, AFAIK. Read Stability не спасает от фантомов, то есть новых записей, вставленных другими транзакциями пока мы трудились над нашим отчетом.

Это если повторять запрос в рамках одной транзакции. А зачем нам его повторять? Выполнили запрос единожды, и строим репорт. Никаких фантомов нет, uncommitted данных тоже. Все в порядке - цель достигнута.

Репорты разные бывают. Может надо несколько раз прочитать одну и ту же таблицу, мало ли что юзеру приспичит.

Кстати, интересно, как эта проблема решается с версионниках. Хоть они и эмулируют версии, но ведь данные то для всех одни, иначе это будет не совместная база. Чтобы транзакция завершилась, нужно чтобы ее результаты были увидены всеми остальными. Значит могут появляться фантомы в других транзакциях. Не означает ли это, что где-то под ковром база имеет все те же проблемы с блокировками?

[zVlad]

....

Кстати, интересно, как эта проблема решается с версионниках. Хоть они и эмулируют версии, но ведь данные то для всех одни, иначе это будет не совместная база. Чтобы транзакция завершилась, нужно чтобы ее результаты были увидены всеми остальными. Значит могут появляться фантомы в других транзакциях. Не означает ли это, что где-то под ковром база имеет все те же проблемы с блокировками?

Конечно у них не все так здорово как говорится. В случае интенсивных апдейтов запрос по чтению может завершится аварийно из-за нехватки места в служебном табличном пространстве. Чтобы этого не было порой они используют SELECT FOR UPDATE, и включается блокировочник поскольку апдейты не версионятся. Есть и более сильные проблемы. Мы давно все это здесь на форуме разбирали по ниточкам.

[PavelM]

В Канада у RBC как-то лег несколько лет назад, тоже очень похоже было по описанию.

Ничего подобного. Мы здесь уже тот случай разбирали. Он был связан с ошибкой в batch job scheduling.

Слышал, что там было несколько проще и менее технологично.

1. Банально плохое тестирование приложения.
2. Банально неработающая процедура восстановления.

Результат - три дня лежки на спине к верху лапами.

[iDesperado]

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

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

[Dmitry67]

Дорого в каком смысле? А есть еще и Read Stability.

Дорого в том смысле, что блокирует таблицу, AFAIK. Read Stability не спасает от фантомов, то есть новых записей, вставленных другими транзакциями пока мы трудились над нашим отчетом.

Это если повторять запрос в рамках одной транзакции. А зачем нам его повторять? Выполнили запрос единожды, и строим репорт. Никаких фантомов нет, uncommitted данных тоже. Все в порядке - цель достигнута.

Это не важно
inconsistent отчет можно получить и при однократном чтении в режиме read committed (surprise! surprise!)
Одному парню, который в это не верил, мне даже пришлось соорудить макет

[iDesperado]

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

Cursor Stability расставит шаред локи до конца запроса, т.е. заблокирует олтп транзакции которые попробуют что-то менять во время работы этого запроса (например агригаты из тригеров)

[iDesperado]

Конечно у них не все так здорово как говорится. В случае интенсивных апдейтов запрос по чтению может завершится аварийно из-за нехватки места в служебном табличном пространстве.

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

Чтобы этого не было порой они используют SELECT FOR UPDATE, и включается блокировочник поскольку апдейты не версионятся. Есть и более сильные проблемы. Мы давно все это здесь на форуме разбирали по ниточкам.

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

[iDesperado]

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

Cursor Stability расставит шаред локи до конца запроса, т.е. заблокирует олтп транзакции которые попробуют что-то менять во время работы этого запроса (например агригаты из тригеров)

UPD. извиняюсь наврал, IBM парит своими нестандартными названиями Read Stability так будет себя вести, а вот Cursor Stability это аналог Read Commited, так он начитает неконсистентную кашу, т.е. агрегаты которые были исправлены по ходу чтения, агрегаты которые появились после старта чтения репорта, т.е. полную кашу.

[iDesperado]

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

выглядит, что у вас снова провал в памяти. вы снова забываете о существовании Oracle/zOS где языки именно стопроцентно одинаковы. еще раз, там pl/sql и SQL на 100% одинаков на платформе zOS, как и любой другой платформе.

[zVlad]

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

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

Вы все свалили в одну кучу. И вариант построения отчетов без триггеров и вариант с триггерами. Если говорить о триггерах, о это примерно следущие. Есть таблица куда пихает строки ОЛТП и на ней триггер по инсерт, который, наприрем, увеличивает сумму чего и количество событий в, например, единственной итоговой строке хранимой в другой таблице. Наш запрос для отчета должен прочитать эту единственную строку и сообщить какаова текущая сумма и сколько событий произошло на данный момент. Чтобы отчет был консистент мы хотим это делать суровнем изоляции, как Вы говорите, Read Committed, т.е. мы хотим заблокировать эту запись. Но она в момент начала выполнения запроса для репорта заблокирована для триггера по инсерт, это значит мы встали в очередь. Сам инсерт и триггер по инсерт не берут много времени, это инсерт одной строки, поэтому мы быстро продвигаемся в очереди даже если впереди нас несколько инсертов. И вот наступает наша очередь, мы блокируем одну запись, быстренько читаем ее и отпускаем. Процесс ОЛТП возобновляется.
Без триггера происходит все примерно также только мы блокируем набор записей в неагрегированной таблице что скорее всего не блокирует инсерты в эту таблицу со стороны ОЛТП.
Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

[zVlad]

Дорого в каком смысле? А есть еще и Read Stability.

Дорого в том смысле, что блокирует таблицу, AFAIK. Read Stability не спасает от фантомов, то есть новых записей, вставленных другими транзакциями пока мы трудились над нашим отчетом.

Это если повторять запрос в рамках одной транзакции. А зачем нам его повторять? Выполнили запрос единожды, и строим репорт. Никаких фантомов нет, uncommitted данных тоже. Все в порядке - цель достигнута.

Это не важно
inconsistent отчет можно получить и при однократном чтении в режиме read committed (surprise! surprise!)
Одному парню, который в это не верил, мне даже пришлось соорудить макет

Я с Вами не смогу спорить потому не знаю такого уровня Read Committed. У ДБ2 такого нет. Есть CS, RS, и RR. Могу лишь догадываться что Вы имете в виду CS - Cursor Stability. Да для отчета такой уровень не совсем пригоден, но ведь есть еще RS - Read Stability, и собственно о нем шла речь.

[zVlad]

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

Cursor Stability расставит шаред локи до конца запроса, т.е. заблокирует олтп транзакции которые попробуют что-то менять во время работы этого запроса (например агригаты из тригеров)

СS расставит ровно один лок, на текущую строку. Все остальные строки будут свободны. Если ОЛТП надо менять содержимое этой строки то да, ОЛТП придется подождать, но для изменения агрегатов отслеживаемых триггерами нужна только новая или изменяемая строка и строка в таблице агрегатов. Это довольно узкий набор объектов, который не будет обрабатывать сколько нибудь долго и таким ожиданием можно принебречь.

[zVlad]

Конечно у них не все так здорово как говорится. В случае интенсивных апдейтов запрос по чтению может завершится аварийно из-за нехватки места в служебном табличном пространстве.

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

Чтобы этого не было порой они используют SELECT FOR UPDATE, и включается блокировочник поскольку апдейты не версионятся. Есть и более сильные проблемы. Мы давно все это здесь на форуме разбирали по ниточкам.

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

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

[zVlad]

Если нужно открыть курсор и прочитать из него данные один раз, то сойдет стандартный Cursor Stability, грязных данных там не будет. Если нужно читать много раз и получать одни и те же данные, и чтобы не было фантомов, то нужен Repeatable Read, а это дорого.

Cursor Stability расставит шаред локи до конца запроса, т.е. заблокирует олтп транзакции которые попробуют что-то менять во время работы этого запроса (например агригаты из тригеров)

UPD. извиняюсь наврал, IBM парит своими нестандартными названиями Read Stability так будет себя вести, а вот Cursor Stability это аналог Read Commited, так он начитает неконсистентную кашу, т.е. агрегаты которые были исправлены по ходу чтения, агрегаты которые появились после старта чтения репорта, т.е. полную кашу.

Я агрегатами называю, например, сумму, среднее значение, количество. А Вы что называете агрегатами?

[iDesperado]

Чтобы отчет был консистент мы хотим это делать суровнем изоляции, как Вы говорите, Read Committed, т.е. мы хотим заблокировать эту запись.

хотеть то мы можем, только вот получить консистентный отчет на уровне Cursor Stablity он же Read Commited не сможем. при всем желании.

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

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

[zVlad]

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

выглядит, что у вас снова провал в памяти. вы снова забываете о существовании Oracle/zOS где языки именно стопроцентно одинаковы. еще раз, там pl/sql и SQL на 100% одинаков на платформе zOS, как и любой другой платформе.

Вы как-то легко перескакиваете с обсуждения DB2 на разных платформах к обсуждению Оракла. Кроме того я Вам пытаюсь объяснить почему DB2 не может быть одинаков на разных платформах, а Вы меня отсылаете к факту что Оракл одинаков, не замечая что это лишь потому так что Оракл (вендор) не может и не хочет использовать возможности МФ, он хочет лишь портировать то что наваял под Юникс в zOS и отрапортовать. Это разные бизнес модели не более того.

Кроме того различия в ДБ2 объясняются тем что ДБ2 на МФ появилось много раньше чем ДБ2 на LUW. DB2 LUW появилось на платформе где же имели сформированные Ораклом стереотипы, традиции и стандарты (вполне объективные). И зачем было бы с ними бороться? На МФ свои стандарты давно сформировались и в свою очередь Оракл на МФ выглядит как бедный родственник.

[iDesperado]

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

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

Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

если отчет состоит из нескольких запросов вы получаете гарантированную неконсистентную кашу.

[iDesperado]

Вы как-то легко перескакиваете с обсуждения DB2 на разных платформах к обсуждению Оракла. Кроме того я Вам пытаюсь объяснить почему DB2 не может быть одинаков на разных платформах, а Вы меня отсылаете к факту что Оракл одинаков, не замечая что это лишь потому так что Оракл (вендор) не может и не хочет использовать возможности МФ, он хочет лишь портировать то что наваял под Юникс в zOS и отрапортовать. Это разные бизнес модели не более того.

"DB2 не может быть одинаков на разных платформах" - это лишь ваше предположение. я с ним не согласен. во времена появления LUW ничто не мешало ИБМ написать отпимизатор и подсистему с SQLPL на переносимом языке типа С и под LUW и zOS, как это в свое время сделал оракл. ничто не мешало. если бы эти подсистемы были бы из единого кода, можно было бы получить 100% идентичные языки на всех платформах используемых db2. но ИБМ предпочла тащить весь груз непероносимых никуда нароботок под МФ и получила то что получила. 3 раных субд, объединеных лишь названием. zOS, LUW, AS/400 (или что там теперь iSeries ?)

в свою очередь Оракл на МФ выглядит как бедный родственник.

снова лишь ваше предположение, по мне так db2/zOS сильно бедней, я уже пару раз перечислял насколько богаче возможности предоставляет оракл на том же zOS.

[Dmitry67]

Мне трудно представить что может быть в базе на разных платформах, кроме специфики указания имен файлов в командах BACKUP и CREATE DATABASE и совсем мелких деталей. Да и имена файлов прячутся в строки так что на синтаксис не влияют

Представим что Microsoft сошла с ума и портировала MS SQL на Linux
Что в таком продукте будет другого?

1. Имена файлов в строках будут естественно юниксовые
2. xp_cmdshell будет вызывать юниксовую команду
3. ну и функции для связи с OLE отвалятся, но они используются для всяких извращений
4. CLR - ну так они и .Net могут туда портировать

[zVlad]

...

Кстати запрос в БД и расчет - это разные этапы. Первый взаимодействует с БД, второй уже нет. Ничто нам не мешает по окончании запроса выдать commit и отпустив блокировки продолжить расчет.

если отчет состоит из нескольких запросов вы получаете гарантированную неконсистентную кашу.

Если это делается кривыми руками, то возможно.
Кстати, я несколько лет вынужден использовать приложение написанное для Оракл. Это наша корпоративная Change Control System. Вот что меня умиляет. Когда я открываю change и неспешно вношу в него изменеия, то последующий save может породить сообщение что мол пока ты репу чесал твой change был изменен кем-то, что желаешь (на выбор) похерить изменения сделанные тем другим, или похерить свои изменения. Я как правило херил чужые изменения и возможно кто-то матерился в итоге. Недавно на новую версию перешли, тоже под Ораклом. Примерно тоже самое происходит только возможности похерить чьи-то изменения не дает, только мои изменения похерить предлагает. Порой не мало изменений сделаешь и оказаывается должен их повторять. Ваши комментарии?