Миграция с MS SQL на DB2

[Sabina]

В свете возможного выгодного deal-а с ИБМ, босс посматривает в сторону переноса приложения (Java, web services, MSSQL) также и на DB2.

C кодом все понятно, а вот с SQL скриптами... На вопрос начальства сколько понадобится на это дело, наш маленький коллектив хором ответил что недели две.( )

ИБМ предлагает migration toolkit. Хорош ли он? Может еще на что стоит посмотреть ?


Спасибо,
Сабина

[Dmitry67]

Про миграцию SQL скриптов нельзя сказать НИЧЕГО
Либо недели две (если SQL там почти стандратный)
Либо... в общем в пределе эквивалент разработки с нуля если используются вещи специфические для MS SQL

Вообще совместимость баз между собой сильно преувеличена... и даже не выходя за рамки стандарта SQL можно получить разный результат для запроса на Oracle и MS SQL. ЧТо говорить о более солжных вещах ?

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

[zVlad]

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

http://www7b.software.ibm.com/dmdd/zone ... index.html

Например руководство по портированию с MS SQL 2000 на DB2 здесь:

http://www7b.software.ibm.com/dmdd/libr ... 3rada.html

Буду очень признателен если, в последствии, Вы поделитесь с нами Вашими впечатлениями от этого процесса.

Dmitry67, даже из дискусии здесь на этом форуме видно, что MS SQL и DB2 более совместимы друг с другом (блокировка, NULL, например) чем они оба и Оракл. У меня иногда даже возникает мысль, что Оракл так специально задумал, что бы клиенты не могли легко уйти. Шучу конечно.
В тоже время ИБМ делает в DB2 вещи облегчающие переход на DB2. Например, аналога PL/SQL в DB2 не было до версии 7 (и не нужно было. Никто не страдал). Сделали. Зачем? Чтобы облегчить участь тех кто решил перейти с Оракл. И другие аналогичные примеры имеются.

[zVlad]

del

[hren]

Dmitry67, даже из дискусии здесь на этом форуме видно, что MS SQL и DB2 более совместимы друг с другом (блокировка, NULL, например) чем они оба и Оракл.

А что там с блокировками? Я как-то пропустил, нельзя ли point me out, just curious. Заранее спасибо.

[zVlad]

Dmitry67, даже из дискусии здесь на этом форуме видно, что MS SQL и DB2 более совместимы друг с другом (блокировка, NULL, например) чем они оба и Оракл.

А что там с блокировками? Я как-то пропустил, нельзя ли point me out, just curious. Заранее спасибо.

I couldn't find our late discussions about locking differences. It disappeared. Hren, you can read this article:

http://www-3.ibm.com/software/data/pubs ... ocking.pdf

[hren]

2zVlad: Это интересно, но описанное в статье различие нельзя назвать несовместимостью. Насколько я понимаю, на поведение приложений (семантически) это никак не влияет. Единственным исключением может быть упомянутый факт, что блокировки в Oracle могут выдаваться не в том порядке, в каком выдаются запросы на их получение. Это надо обдумать. Со стороны DB2 выглядит несколько сомнительным утверждение о том, что блокировки не должны храниться на диске. Я поищу объяснение этому феномену со стороны Oracle, вероятно, какое-то должно быть. Будет интересно сравнить аргументацию. Спасибо за ссылку.

[Flying Hen]

Мне доводилось делать миграцию Sybase -> DB2, я так понимаю что Sybase это близко к MS SQL. Вкратце, проблем с SQL запросами я не припомню ни одной, вообще процессор запросов в DB2 выше всяких похвал. Вот со встроенными процедурами гораздо сложнее. Насчет двух недель это вы погорячились. Есть такой язык

DB2 SQL Procedural Language for Linux, Unix and Windows

и есть такая вещица как

IBM DB2 Migration Toolkits

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

Вот еще полезная ссылочка для начинающих:
DB2 UDB Programming Fastpath Course

Короче дерзайте Если есть вопросы - задавайте.

[Sabina]

Sabina, судя по всему Ваш шеф имеет способность посматривать в правильную сторону.

Cкорее уж туда, где платят

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

http://www7b.software.ibm.com/dmdd/zone ... index.html

Например руководство по портированию с MS SQL 2000 на DB2 здесь:

http://www7b.software.ibm.com/dmdd/libr ... 3rada.html

Большое спасибо за линки.

Буду очень признателен если, в последствии, Вы поделитесь с нами Вашими впечатлениями от этого процесса.

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

[Sabina]

Спасибо всем за информацию.

Насчет двух недель это вы погорячились.

Обычно когда у нас говорят 2 недели на деле получается недели 3

Это я на всякий случай спрашиваю, окончательного решения пока не принято. Но когда примут, начнут сразу на пятки наступать (is it done yet?). Лучше уж заранее подготовиться.

[zVlad]

2zVlad: Это интересно, но описанное в статье различие нельзя назвать несовместимостью. Насколько я понимаю, на поведение приложений (семантически) это никак не влияет. Единственным исключением может быть упомянутый факт, что блокировки в Oracle могут выдаваться не в том порядке, в каком выдаются запросы на их получение. Это надо обдумать. Со стороны DB2 выглядит несколько сомнительным утверждение о том, что блокировки не должны храниться на диске. Я поищу объяснение этому феномену со стороны Oracle, вероятно, какое-то должно быть. Будет интересно сравнить аргументацию. Спасибо за ссылку.

Как раз наоборот, Hren, различия эти делают семантическую разницу. Например, когда мы пишем для DB2 програму чтения с возможным изменением мы пользуемся уровнем Cursor Stability, который навешивает замок на ту запись, которая в данный момент просматривается и может быть изменена. В случае Оракл мы пишем SELECT, и пока клиент решает менять или не менять, кто-нибудь другой может эту запись изменить. Следовательно приклад должен осуществить доп. контроль перед сохранением. Я как раз имею такое приложение и меня раздражает сообщение в ответ на просьбу сохранить некую много атрибутную запись после долгих модификаций атрибутов говорящее что "запись была изменена другим кем-то. Хотите перекрыть его изменения Вашими": Вот как в таких случаях нужно поступать?

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

Вы знаете, Hren, за почти десять лет довольно активного участия в дискусии "Оракл и весь остальной мир" я видел только одного человека, который соглашался, что с Оракл не все в порядке. Для всех остальных Оракловцев предметом святой веры и глубоким убеждением является незыблемость утверждения: "Оракл - лучше всех".
Мне также знаком лишь один человек - это я - представитель DB2, который бы так упорно и долго пытался достичь справедливости в вопросе сопоставления Оракл и DB2, а также Оракл и "другие базы данных".
Мною прочитано много исследований на эту тему, я также постоянно посещаю Оракл веб сайт в поисках новых высказываний. Общее впечатления от этого чтения этих исследований таково, что когда читаешь что-нибудь со стороны Оракл то не можешь избавиться от впечатления, что находишься ...скажем на политзанятии в разгар "развитого социализма". Да и то тем политрукам еще поучиться надо у тех кто продвигает Оракл, включая его самого.
Читая в пользу ИБМ, видишь понятный мне, техническому человеку, стиль описания как это там и как это здесь. Как правило даже оценок не дается. Редко делатся вывод в пользу одного из подходов. Что особенно убивает так это то, что даже в Оракловской тех документации агитация продолжается, что напрочь отсутствует у ИБМ.

[Dmitry67]

zVlad, по поводу хранения на диске Вы ошибаетесь
Дело в том что в Oracle блокировки насколько я знаю храняться прямо в данных
Соответственно их не надо эскалировать
А место под них всегда есть - прямо в данныз...

[zVlad]

zVlad, по поводу хранения на диске Вы ошибаетесь
Дело в том что в Oracle блокировки насколько я знаю храняться прямо в данных
Соответственно их не надо эскалировать
А место под них всегда есть - прямо в данныз...

You are right. And were those data reside? On disks?
This is from link I mentioned above:

"How Oracle Manages Locks
Oracle actually stores lock information on the same data page (called a block
in Oracle terminology) that the data rows exist on. On every data and index
page, Oracle has a section of the header called the transaction layer. This
section is variable in size and will grow as more transactions simultaneously
access records on the data page. Every time a transaction accesses a row on a
data page, an entry is put in the Interested Transaction List (ITL) on that
page. For every transaction, 24 bytes on the page are used up for an ITL. As
more transactions access the same data page, the transaction layer grows in
size (using up more disk space for transactional information)."

There is also picture there. I cannot put it here.

[hren]

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

То, о чем Вы говорите, относится скорее к управлению семантикой поведения сервера при выделении блокировок, а точнее к более общей проблеме реализации конкурентности (уровней изоляции). Oracle работает на уровне изоляции Read Commited с использованием оптимистической мульти-версионной изоляции, известной также как snapshot isolation. DB2 я не знаю, как уже признавался. Из Ваших слов я делаю вывод, что DB2 поддерживает много уровней изоляции (возможность выбора уровня cursor stability). Для меня остается неясным, каким образом подобный уровень изоляции можно использовать с concurrent OLTP applications under heavy load - ведь он подразумевает пусть ограниченную, но блокировку по чтению. Если все это так, то Oracle и DB2 действительно сильно отличаются и приложения для них при портировании могут требовать существенной переделки.

Относительно преимуществ и недостатков, а также борьбы сторонников и противников разных СУБД. Я не отношусь ни к одному из идеологических лагерей, я не вижу тут идеологии. Для меня СУБД - интересные артефакты. Так получилось, что я знаю в некоторых пределех Oracle, но не знаю DB2. Oracle имеет массу недостатков, но имеет и массу достоинств. Это концептуально-цельный продукт и мощный инструмент, возможностей которого мне лично всегда было достаточно. Поэтому, пока компания Oracle продолжвает развитие продукта и его поддержку, я никому бы не посоветовал из каких-либо общих соображений, включая философию, моду, экономику (TCO), производительность и т.п. переходить с Oracle на что-либо другое. Я уверен, что большинство проблем имеют в Oracle оптимальное решение, а сам идея перехода с одной удовлетворительно работающей среды на другую - для меня нонсенс (поэтому я не CTO и никогда им не стану ). Что касается выбора Oracle как целевой среды для вновь проектируемого приложения, здесь не все так однозначно. Именно здесь можно проводить осмысленный сравнительный анализ СУБД как инструментов, учитывая также и собственные особенности (skills, expertise, whatever). О DB2 я слышал много хорошего и от разработчиков и от администраторов. Мне интересно узнать из первых рук, в чем ее преимущества, это позволит в дальнейшем более грамотно планировать архитектуру наших систем, рассматривая DB2 как опцию. Не секрет, что зачастую эта СУБД по прежнему воспринимается как некая экзотика, что-то очередное из недр IBM, где все всегда "свое", ни на что не похожее

Относительно документации Вы несоменно правы. Не забывайте однако, что Oracle - это компания с антрепренерским стилем управления, по сути детище одного очень своеобразного человека. Также как и Microsoft. Для IBM DB2 - это маленьких кусочек побочного бизнеса, из-за которого не стоит копья ломать, да и вообще не солидно это для компании таких масштабов и с такой историей

[zVlad]

2zVlad: спасибо за комментарий. ...... Поэтому, пока компания Oracle продолжвает развитие продукта и его поддержку, я никому бы не посоветовал из каких-либо общих соображений, включая философию, моду, экономику (TCO), производительность и т.п. переходить с Oracle на что-либо другое. Я уверен, что большинство проблем имеют в Oracle оптимальное решение, а сам идея перехода с одной удовлетворительно работающей среды на другую - для меня нонсенс (поэтому я не CTO и никогда им не стану ).....
........Относительно документации Вы несоменно правы. Не забывайте однако, что Oracle - это компания с антрепренерским стилем управления, по сути детище одного очень своеобразного человека. Также как и Microsoft. Для IBM DB2 - это маленьких кусочек побочного бизнеса, из-за которого не стоит копья ломать, да и вообще не солидно это для компании таких масштабов и с такой историей

I'll give you more feedback latter (I'm tied in time now, and I don't like English for seriouse discussions). At the moment I just recommend you to read this:

http://www.computerworld.com.au/index.p ... =16&fpid=0

I call it - "events from life". When I read this my feeling was like Oracle discredited all relational data bases versa non-relational.

I absolutally agree with that Oracle is "детище одного очень своеобразного человека". This is a biggest isuue for Oracle's and their clients issue. My guess is that Oracle could be much better with another bussiness model (of course, for less money for Larry personally). By the way, Microsoft gets better from this point of view (I would say more realistic approach to modern competition). IBM and Microsoft made common agreement in area of Web Services recently.

I totally disagree with that "DB2 - это маленьких кусочек побочного бизнеса IBM". At this specific time DB2 is one of the most important IBM product for IBM itself. Second one I want to mention about is WebSphere.

You are right saying: "Не секрет, что зачастую эта СУБД по прежнему воспринимается как некая экзотика, что-то очередное из недр IBM, где все всегда "свое", ни на что не похожее ". IBM had changed this way of dealing bussiness long time ago. I think in a midle of 90s. What I see now that other companies (yes, like Oracle, and partially Microsoft) start to make the same mistakes which were hurt (for some period of time) IBM in the past.

[hren]

Статья про Telstra не слишком информативна, нельзя понять ни специфики задач, ни причин отказа от Oracle, ни архитектуры и параметров того, что они используют вместо. Поскольку это крупнейший телеком провайдер, надо думать у них есть масса оперативных задач, вроде network monitoring, customer care, billing, их собственное управление и прочее, есть множество OLAP задач. Вообще терабайтные базы часто характерны для телекомов, где собираются ежедневно гигабайты CDR, сетевой статистики и т.п. Рост в 1.5 TB в месяц весьма впечатляет, интересно было бы узнать подробности.

Насчет бизнеса IBM - софтверный бизнес для них, конечно, важен, но дает лишь 16% общего дохода (по итогам 2002 года) и является третьим по важности после консалтинга и железа. Так что трудно ставить на одну доску по степени озабоченности продвижением своих СУБД IBM и Oracle, который весь живет вокруг десятка своих продуктов и до сих пор получает намного больше денег от продажи лицензий, нежели чем от консалтинга.

[WildVlad]

I totally disagree with that "DB2 - это маленьких кусочек побочного бизнеса IBM". At this specific time DB2 is one of the most important IBM product for IBM itself. Second one I want to mention about is WebSphere.

Только порядок наоборот. WebSphere приносит денег больше, чем DB2 Не помню где это видел - но revenues за вебзверя были раза в 2 выше чем за DB2.

[sp123]

Для меня остается неясным, каким образом подобный уровень изоляции можно использовать с concurrent OLTP applications under heavy load - ведь он подразумевает пусть ограниченную, но блокировку по чтению. Если все это так, то Oracle и DB2 действительно сильно отличаются и приложения для них при портировании могут требовать существенной переделки.

Разрешите присоединиться к дискуссии. Предлагаю вместо отвлеченных рассуждений разобрать простейший пример. Есть некая таблица, над которой одновременно трудятся два типа приложений: front-end и back-end. Front-end вставляет/модифицирует записи - транзакций много, каждая из них короткая (update одну-две записи и тут же commit) и должна отрабатывать моментально - никакие задержки не допустимы, поскольку затрагивают конечного пользователя. Back-end тем временем раз в час делает всевозможные select'ы - формирует xml-и, рассылает alert'ы, отчеты, обычная рутина.

Вопрос к zVlad: нужно ли в DB2 делать что-либо, чтобы обеспечить отсутствие каких-либо блокировок со стороны back-end и, в то же время, непротиворечивость выдаваемых им select'ов, и если да, то как это выглядит на практике.

Спасибо !

[zVlad]

Для меня остается неясным, каким образом подобный уровень изоляции можно использовать с concurrent OLTP applications under heavy load - ведь он подразумевает пусть ограниченную, но блокировку по чтению. Если все это так, то Oracle и DB2 действительно сильно отличаются и приложения для них при портировании могут требовать существенной переделки.

Разрешите присоединиться к дискуссии. Предлагаю вместо отвлеченных рассуждений разобрать простейший пример. Есть некая таблица, над которой одновременно трудятся два типа приложений: front-end и back-end. Front-end вставляет/модифицирует записи - транзакций много, каждая из них короткая (update одну-две записи и тут же commit) и должна отрабатывать моментально - никакие задержки не допустимы, поскольку затрагивают конечного пользователя. Back-end тем временем раз в час делает всевозможные select'ы - формирует xml-и, рассылает alert'ы, отчеты, обычная рутина.

Вопрос к zVlad: нужно ли в DB2 делать что-либо, чтобы обеспечить отсутствие каких-либо блокировок со стороны back-end и, в то же время, непротиворечивость выдаваемых им select'ов, и если да, то как это выглядит на практике.

Спасибо !

In DB2 (as well as in any other truly blocking systems), there is just one way "обеспечить отсутствие каких-либо блокировок" - dirty read. In DB2 terminology Uncommited Read.
What you mean saying "непротиворечивость выдаваемых им select'ов"?
Unlike Oracle, DB2 makes referential and data control before actual data changes. Therefore, in case of DB2 UR you will see consistent (in terms of referential and data integrity) but (possibly) never committed. That’s all.
When you run Oracle, first, you have no way to see uncommitted data, even though you want to, second, with dirty read (I’m not sure if it is even possible) in Oracle you will (possibly) see inconsistent data in terms of referential and data integrity. Just due to fact that Oracle can make data inconsistent with UPDATE/INSERT and check those integrities (mostly) by the end of transactions (default). We discussed it a lot before. It was clear there.
I would add here now is that systems like RDBM likes a human body. Everything is related to each other and depends on. Choosing versioning means not just “readers don’t block writers” and vise versa, but also UNDO segments troubles and failures with serialized queries, which finally means, by the way, applications abends and lower level of concurrent access, and also mean that applications must be designed appropriately. We discussed it.
Do you think IBM just is not capable to implement versioning? No, not at all. Versioning was considered in IBM's structures as an approach to handle those issues long time ago, and was refused. I don’t know why.
It is impossible "обеспечить отсутствие каких-либо блокировок со стороны back-end и, в то же время, непротиворечивость выдаваемых им select'ов" unless you produce versions of data. But, be agreed, when Oracle creates undo segment for update it means that reader sees data which are already changed (I agree data are in consistent status. See above, with DB2 UR data are in consistent status too).

[zVlad]

duplicate was deleted.

[tengiz]

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

[sp123]

zVlad, давайте оставим в покое Oracle, он мне в данный момент не интересен. Вопрос был про простую ситуацию, и мне хотелось узнать, как люди решают подобные проблемы. OK, если dirty read - единственный способ ничего не блокировать, то необходимо пересмотреть дизайн и обеспечить непересекаемость работающих приложений, устроить replication, no problem. Но все это слегка пугает и выглядит как весьма серьезный downgrade. Как быть с элементарным траблшутингом? Предположим, мне звонит customer support и говорит: "Слушай, у нас тут, кажися, налог неправильно считается после вчерашнего релиза, ты не мог бы глянуть, что там щас происходит и выдать нам отчетик с отклонениями? А то нас тута всех расстреляют, и тебя заодно". Я им - но проблемо, гайз, щас устроим. Только вот записей этих с кривым налогом у меня, похоже, уже миллионов несколько накопилось, мой select с перерасчетами будет шуршать часа два, а блокировать записи нельзя, и dirty read не катит, мне нужны только завершившиеся транзакции. Наверняка у людей, работающих под DB2, подобная ситуация возникает - как из нее выходить? Объяснять customer support'у о достоинствах новой базы по сравнению с похеренным ораклом и просить зависших кастомеров подождать? Или я чего-то не понимаю?

[tengiz]

sp123, Ваш пример малотипичен для обычных систем обработки транзакций. Для такой задачи скорее подойдёт тразнакционня очередь, куда в высоком темпе без задержек будут сваливаться данные, которые с другого конца очереди будет заливаться в обычную СУБД. При достаточной длине очереди и достаточной средней пропускной способности системы в целом, отчёты и пр. вполне будут уживаться с постоянным потоком входных данных. Мультиверсионность в некоторой степени упрощает реализацию, так как при не очень высоком темпе поступления данных позволяет обойтись без буфера в виде очереди, однако когда система должна работать на пределе пропускной способности аппаратуры, наличие накладных расходов на поддержание мультиверсионности (диск, память, циклы процессора) сведёт эти преимущества на нет.

[sp123]

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

Натюрлих, это и имелось в виду, когда речь шла про front-end. Обычная система - несколько shared connection pool, т.е. тех самых очередей, куда валятся те самые короткие транзакции. При этом жизненно важно не допускать не только блокировок, но и любых задержек, т.к. застревает не только "крайняя" транзакция, но и все остальные позади нее. Из-за чего, собственно, я так и разволновался, услышав про блокировки по чтению при использовании cursor stability . Потому что ни разу не видел OLTP в чистом виде. Обычно есть еще много чего, исполняющегося в batch mode.

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

Не понял, sorry.

[zVlad]

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

Ничего я, Tengiz, не мешаю. Мне еще в прошлый раз осталось не понятно почему Вы и vc так и не узрели связи между вопросами блокировка/версионка и referential integrity. Между тем они (и я думаю другие неожиданные вещи) тесно связаны, в том смысле, что если вы выбрали блокировочную схему изоляции то вы должны проверять интегрити сразу, чтобы не допустить "грязного чтения" не только uncommitted datа (в случае "dirty read" как стандарт этого допускает) но также и inconsistent data (чего я думаю при внимательном чтении стандарта окажется не допускается).
Версионник же Оракл может при этом щеголять с одной стороны тем, что он никогда не даст читать "грязные данные" (какими бы они не были) и даст возможность нарушать (до конца транзакции) всякие интегрити (не велик подвиг коль скоро ты версионик). И все вроде бы при этом счастливы. Но Вы то ведь, Tengiz, знаете что цена этому дуратские месэджи вроде "сегмент UNDO переполнен" или " не могу сериалайзить" как только нагрузка становится "не желательной, ненормальной". В то время как блокировочник будет упорно (я бы сказал тупо) накладывать замки в соответствии с выбранным уровнем изоляции и ставить всех в очередь и обслуживать без таких дуратских сообщений, пусть не сразу - а кто это может заметить, если приклад написан нормально?

Make sense?