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

hren · Post by **hren** » 10 Oct 2003 17:01

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

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

WildVlad · Post by **WildVlad** » 10 Oct 2003 18:01

zVlad wrote: 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 :mrgreen:

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

sp123 · Post by **sp123** » 10 Oct 2003 19:22

hren wrote:Для меня остается неясным, каким образом подобный уровень изоляции можно использовать с 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 · Post by **zVlad** » 10 Oct 2003 20:39

sp123 wrote:
hren wrote:Для меня остается неясным, каким образом подобный уровень изоляции можно использовать с 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 · Post by **zVlad** » 10 Oct 2003 20:42

duplicate was deleted.

tengiz · Post by **tengiz** » 11 Oct 2003 00:14

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

sp123 · Post by **sp123** » 11 Oct 2003 00:24

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

tengiz · Post by **tengiz** » 11 Oct 2003 00:32

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

sp123 · Post by **sp123** » 11 Oct 2003 01:30

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

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

. Потому что ни разу не видел OLTP в чистом виде. Обычно есть еще много чего, исполняющегося в batch mode.

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

Не понял, sorry.

zVlad · Post by **zVlad** » 11 Oct 2003 02:53

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

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

Make sense?

zVlad · Post by **zVlad** » 11 Oct 2003 03:11

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

Замечательно, Sp123. Вы все очень красочно и доходчиво описали. Сразу видно прикладника находящегося в гуще событий динамичного приложения. Я, к сожалению, серый, тупой DBA. Но я бы предположил, что такой экзотический (для Оракл и MS SQL) уровень (именно) изоляции как Cursor Stability мог бы разрешить красочно описанную Вами проблему (а может быть и Uncommitted read? Почему нет? речь то идет об уже состоявшихся фактах, не так ли? Вряд ли в Вашем примере то что под вопросом есть предмет интенсивной обработки в OLTP? Или, например, я могу сказать аналитику: "Давай сначала разберемся с теми, кто был вчера и позже?" Я знаю, он ответит: "Давай". И в этом случае, если наша система имеет понятие времени то никаких пересечений OLTP с моим dirty read не будет. Не так ли?

zVlad · Post by **zVlad** » 11 Oct 2003 03:27

hren wrote:2zVlad: спасибо за комментарий. Я не совсем с Вами согласен или, точнее, я не совсем понял, что Вы имеете в виду, говоря о "программе чтения с возможным изменением". .....

Мне кажется это одна из самых типичных задач. Возьмем систему резервирования билетов (на что угодно). Что надо сделать? Получить какое-то представление о том что доступно, выбрать, подержать, и ... или отпустить или забрать одно из мест. Что мы можем сделать в Оракле? Прочитать не учитывая, что кто-то уже меняет (резервирует) места, но еще не закомиттел. Порешать, выбрать .... и узнать, что это место уже взято. Oh, sorry, let's try again. Нет конечно так на Оракл такой приклад не пишется (я думаю). В прикладе сразу выдается ... что? Правильно SELECT ..... FOR UPDATE. И во что после этого превращается Оракл? А Оракл после этого превращается ....опять правильно - "в элегантные шорты", т.е. в блокировочник. Я не прав?
В DB2 для таких задач имеется Isolation Level Cursor Stability! Я знаю точно что я не прав, но не сильно.

zVlad · Post by **zVlad** » 11 Oct 2003 03:46

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

Люди! Слушайте - это эпохальное сообщение на форуме!
Кроме шуток, Tengiz, лучше и проще не скажешь. Браво! Только Ораклоиды понять, наверное, не смогут. Не обижайтесь, парни, я это так к слову сказал. Все что я пытался донести - здесь, у Tengiz-a. Просто и понятно. Еще раз - Браво, Tengiz!

Но наше с Вами, Tengiz, различие остается - я в отличии от Вас не так опасаюсь "dirty read", В том смысле, что при правильном применении это дает тот же результат (и причем гарантированный), но без блокировок вовсе (чем, собственно, и сщеголяют наши Оракловцы). Так что let's show goes on.

zVlad · Post by **zVlad** » 11 Oct 2003 03:57

tengiz wrote:........ наличие накладных расходов на поддержание мультиверсионности (диск, память, циклы процессора) сведёт эти преимущества на нет.

Еще одну мысль навеял этот по истинне бесконечно мудрый постинг Tengiz-a.
Версионник всегда не бесплатен (и даже дорого стоит), "dirty же read" - всегда бесплатен. No locking, no undo segment needed, nothing.

olegkin · Post by **olegkin** » 11 Oct 2003 05:15

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

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

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

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

В схожей ситуации ( Java, web services, MSSQL ) и конвертация в DB2, перенес данные с помощью какой-то программки из db2, скриптики частично переписал. С нуля, без знания db2, в одиночку - заняло неделю примерно. Может две. Время конечно зависит от количества скриптов, но главное что там нет принципиальных различий.
С оракл пришлось повозиться намного дольше, вплоть до написания своей программы конвертации данных из-за того, что родная ораклавская не понимала unicode. Скриптики под оракл тоже была морока переписывать, но ничего сверхсложного.

Привет

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

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