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

[zVlad]

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]

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

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

[zVlad]

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

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

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

[zVlad]

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

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

[olegkin]

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

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

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


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

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

[Sabina]

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

Cпасибо, очень обнадеживает. Мы с ужасом ждем понедельника, ибо если начальство решить "попробовать" с ИБМ, то нам придется попотеть не на шутку. При том что мы и сейчас воздух не пинаем. Примерно каждые 3 дня по новому объекту в базе и сервису с ГУЕМ и это усилиями 4 человек. Вообще то, что они хотят идет немного в разрез с назначением нашего приложения и нехило его усложняет в то время как прелесть его в простоте.

Но нам надо срочно "продасться"

[sp123]

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

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

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

Насчет "понять не смогут" - это почему жа? Тенгиз дал исчерпывающее разъяснение тому, что OLTP, построенная без мультиверсионности, будет дешевле в плане ресурсов. Так кто бы спорил, так оно и есть. Пойнт-то не в этом. Описанный им механизм стандартного построения OLTP для web applications в виде очереди транзакций - это в точности то, что я тут называл front-end частью системы, и то, с чем я тут работаю уже четыре года. К слову сказать, при этом подходе Ваш пример с резервированием билетов не проходит - очередь транзакций не может ждать дольше долей секунды на исполнение каждой операции. То, чего я добивался - удовлетворительного решения проблемы взаимодействия OLTP с тем, что принято назвать back-end, я так и не увидел, к сожалению. Вероятно, наличие подсистем вроде offline credit card authorization и им подобным - на самом деле малотипично. Но они вот есть, и мне стало интересно, как такое наиболее безболезненно можно реализовать в DB2, ради чего я и задавал наивные вопросы. Ну и ладно, это было просто любопытство, не более того

[Merle]

Но я бы предположил, что такой экзотический (для Оракл и MS SQL) уровень (именно) изоляции как Cursor Stability мог бы разрешить красочно описанную Вами проблему (а может быть и Uncommitted read?

zVlad, мы же уже как-то разобрались, что DB2'шный Cursor Stability - это ANSI'шный и MSSQL'ный READ COMMITTED, да и Oracle'овский Read Committed, совсем мало отличается. Так что ничего экзотического в этом уровне изоляции нет.

[zVlad]

Но я бы предположил, что такой экзотический (для Оракл и MS SQL) уровень (именно) изоляции как Cursor Stability мог бы разрешить красочно описанную Вами проблему (а может быть и Uncommitted read?

zVlad, мы же уже как-то разобрались, что DB2'шный Cursor Stability - это ANSI'шный и MSSQL'ный READ COMMITTED, да и Oracle'овский Read Committed, совсем мало отличается. Так что ничего экзотического в этом уровне изоляции нет.

С воему стыду должен признаться что не очень точно помню всех детали нашей той дискусии. Скорее всего Вы правы, но хочется все таки добавить для полноты изложения, что ANSI's READ COMMITTED представлен в DB2 двумя уровнями - Cursor Stability and Read Stability. И они безусловно хоть как-то но отличаются.

[zVlad]

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

Cпасибо, очень обнадеживает. Мы с ужасом ждем понедельника, ибо если начальство решить "попробовать" с ИБМ, то нам придется попотеть не на шутку. При том что мы и сейчас воздух не пинаем. Примерно каждые 3 дня по новому объекту в базе и сервису с ГУЕМ и это усилиями 4 человек. Вообще то, что они хотят идет немного в разрез с назначением нашего приложения и нехило его усложняет в то время как прелесть его в простоте.

Но нам надо срочно "продасться"

Вы меня явно заинтриговали, Sabina. Не могли бы развернуть мысли о том "...что они хотят идет немного в разрез с назначением нашего приложения и нехило его усложняет в то время как прелесть его в простоте". Чем DB2 может усложнить жизнь то? Или дело не в DB2?

[zVlad]

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

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

............

Насчет "понять не смогут" - это почему жа? Тенгиз дал исчерпывающее разъяснение тому, что OLTP, построенная без мультиверсионности, будет дешевле в плане ресурсов. Так кто бы спорил, так оно и есть. Пойнт-то не в этом. Описанный им механизм стандартного построения OLTP для web applications в виде очереди транзакций - это в точности то, что я тут называл front-end частью системы, и то, с чем я тут работаю уже четыре года. К слову сказать, при этом подходе Ваш пример с резервированием билетов не проходит - очередь транзакций не может ждать дольше долей секунды на исполнение каждой операции. То, чего я добивался - удовлетворительного решения проблемы взаимодействия OLTP с тем, что принято назвать back-end, я так и не увидел, к сожалению. Вероятно, наличие подсистем вроде offline credit card authorization и им подобным - на самом деле малотипично. Но они вот есть, и мне стало интересно, как такое наиболее безболезненно можно реализовать в DB2, ради чего я и задавал наивные вопросы. Ну и ладно, это было просто любопытство, не более того

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

"удовлетворительного решения проблемы взаимодействия OLTP с тем, что принято назвать back-end, я так и не увидел, к сожалению". Вариантов решений такого взаимодействия может быть несколько. Я уже устал намекать на "dirty read". С подачи Tengiza но этом как бы табу лежит у нас здесь. Не безинтересен репликационный подход. Тоже недопонят как-то.

А вообще, сдается мне что мы, в программировании, как-то разучились аккуратно использовать смысл слов. Вот мы толкуем об изоляции. Слово для русского языка иностранное, может поэтому мы его так до конца и не осознаем. В самом деле, изолированный - ведь значит недоступный? Возьмем пример - электрический провод. Если он не изолирован, то прикосновение к нему вызовет доступ к электричеству и как следствие - удар электротоком. Если же провод изолирован - то к электричеству в этом проводе мы никак не сможем прикоснуться. Распространим эту аналогию на наши дела скорбные.
Уровень изоляции UR говорит вот провод (данные) он не изолирован, можно к нему прикасаться, но он может оказаться под напряжением. Если мы, к примеру, знаем график подачи напряжения на этот провод, то мы можем бесопасно к нему прикасаться в определенные отрезки времени.
Следующий уровень - Read Committed (и другие его модификации). Мы не знаем когда там может быть электричество и не хотим знать. Мы хотим прикасаться только к оголенному проводу и только когда в нем точно нет электричества. Что бы это обеспечить кто-то должен делать следующее: перед подачей тока изолировать провод, подавать ток, и по отключении снова убирать изоляцию. У кого-либо есть другие предложения как это можно сделать? Что должен делать тот кому надо прислониться к оголенному проводу? - ждать.
Щедрый же Оракл говорит (сам себе): ну чудаки ребята, хотят к голому проводу под напряжением прикоснуться, ладно дам им такой же провод, как был тот что им нужен перед подачей тока. Нате парни - держитесь. О, блин, еще один хочет - на тебе тоже. А тебе парень я дать такого же провода не могу - кончились у меня такие провода.
Вот примерно так я рассуждаю когда утверждаю - нет в Оракл уровней изоляции. Есть совпадения с некоторыми следствиями (свойствами) из принципа изоляции данных выраженных в ANSI стандарте.
Я думаю это было бы более понятно если бы Оракл разработал специальную теорию для версионности, а не пытался бы мимикрировать под совсем другие принципы работы.
Я помню мне указывали на то, что стандарт не диктует как уровни должны быть обеспечены. Но сдатся что когда уровни формулировались подразумевался механизм ограничения доступа к единичной копии данных. Потому что если мы каждому даем свою копию для чтения то о какой проблеме целостности вообще может итди речь? Очевидно, что копия на момент начала транзакции изменения - целостна.

Вопрос к Sp123: в Вашем конкретном back-end, или это возможно (согласно предикатам в SELECT-ах) прикосаться к данным, которые могут быть предметом модификации front-end-ом? Или это два непересекающихся ЛОГИЧЕСКИ сегмента данных?

[tengiz]

zVlad,

Я думаю, что у Вас закончились бы вопросы и претензии к ORACLE по поводу атнинаучной еретической лженауки про многоверсионность, если бы Вы наконец прочитали что-нибудь толковое по теме. Например, вот этот классический учебник по обработке транзакций, написанный в середине 80-х, когда теория многоверсионности уже была в очень зрелом состоянии и ссылку на который я уже пару раз здесь выкладывал: Concurrency Control and Recovery in Database Systems by Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman. И в частности главу 4 (Non-locking schedulers) и главу 5 (Multiversion concurrency control).

Желаю Вам приятного чтения!

[tengiz]

но хочется все таки добавить для полноты изложения, что ANSI's READ COMMITTED представлен в DB2 двумя уровнями - Cursor Stability and Read Stability. И они безусловно хоть как-то но отличаются.

DB2 REPEATABLE READ == ANSI SERIALIZABLE
DB2 READ STABILITY == ANSI REPEATABLE READ
DB2 CURSOR STABILITY == ANSI READ COMMITTED

[zVlad]

но хочется все таки добавить для полноты изложения, что ANSI's READ COMMITTED представлен в DB2 двумя уровнями - Cursor Stability and Read Stability. И они безусловно хоть как-то но отличаются.

DB2 REPEATABLE READ == ANSI SERIALIZABLE
DB2 READ STABILITY == ANSI REPEATABLE READ
DB2 CURSOR STABILITY == ANSI READ COMMITTED

Cогласен (в смысле у меня на данный момент нет возражений и я не вижу смысла возражать в контексте более важной темы, а скорее всего Вы просто правы. Прямо сейчас, не знаю).

[zVlad]

zVlad,

Я думаю, что у Вас закончились бы вопросы и претензии к ORACLE по поводу атнинаучной еретической лженауки про многоверсионность, если бы Вы наконец прочитали что-нибудь толковое по теме. Например, вот этот классический учебник по обработке транзакций, написанный в середине 80-х, когда теория многоверсионности уже была в очень зрелом состоянии и ссылку на который я уже пару раз здесь выкладывал: Concurrency Control and Recovery in Database Systems by Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman. И в частности главу 4 (Non-locking schedulers) и главу 5 (Multiversion concurrency control).

Желаю Вам приятного чтения!

Спасибо, Tengiz, я обязательно почитаю. Я знаю что у меня есть пробел в фундаментальных знаний на эту тему, я больше практик. которых пытается что-то домыслить.

Но вот "...по поводу атнинаучной еретической лженауки про многоверсионность....", позвольте мне это Вам не позволить. В смысле нет у меня такой постановки. Я не считаю многоверсионность лженаукой. Я считаю не правильным делать вид, что мы (Оракл) мол круче чем DB2 и MS SQL потому что у нас "readers don't block writers and writers don't block readers" и при этом замалчивать истинную цену этому и то где эта лафа просто вред.
Я первым приду поклониться Ларри если он и его компания начнет говорит правду об Оракл. Просто правду.

Вопрос Вам, Tengiz, почему MS SQL не многоверсионник? А также, страдает ли от этого Ваш клиент?

[tengiz]

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

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

Вопрос Вам, Tengiz, почему MS SQL не многоверсионник? А также, страдает ли от этого Ваш клиент?

Почему MS SQL не весрионник? По разным причинам, прежде всего потому, что это никогда не было в числе первых приоритетов.

Клиент страдает, особенно в последние 3-4 года ввиду того, что:

1) MS SQL активно стал влезать на традиционный рынок ORACLE и разработчики привыкшие к многоверсионности не хотят полностью отказываться от своих привычек.
2) Многие традиционные клиенты MS SQL тоже активно хотят иметь эту возможность: versioning - один из наиболее популярных запросов пользователей.

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

[sp123]

Вопрос к Sp123: в Вашем конкретном back-end, или это возможно (согласно предикатам в SELECT-ах) прикосаться к данным, которые могут быть предметом модификации front-end-ом?
Или это два непересекающихся ЛОГИЧЕСКИ сегмента данных?

[/quote]

Если под словом "данные" понимать rows, то пересечения - сплошь и рядом. К примеру, есть в таблице поля A и B. Изначально записи создаются на front-end со значением B = 'CREATED', в дальнейшем front-end это поле не меняет, зато все время очень активно модифицирует поле A и страшно злится, если что-то "зависло". Раз в полчаса некая back-end программа (назовем ее "авторизация") должна выбрать все записи с B = 'CREATED', поменять значение на 'PENDING', поманипулировать со всякого рода датой, может быть даже файлы какие-нибудь туда-сюда погонять по ftp, после чего обновить значение B на 'SUCCESS' или 'FAIL'. При этом никакие долгие блокировки не допустимы, за select for update бьют канделябром. Кроме этого есть еще одно приложение (назовем его "караул"), которое раз в день выбирает записи в соcтоянии 'PENDING-дольше-трех-дней-по-состоянию-на-9:00pm' и отсылает злобный e-mail заинтересованным начальникам для разбора полетов. После чего кто-нибудь начинает активно придумывать и гонять select'ы и искать виновных. Итого имеем как минимум два запроса, для которых uncommited read не годится:
- "авторизация" не должна видеть записи c В = 'CREATED', для которых еще не было commit, потому как front-end может их rollback, а поезд уже ушел
- "караул" хочет видеть точный снимок состояния таблицы на 9 утра безо всяких там dirty
... и одного дятла, который стучит по кнопкам, будучи в состоянии стресса (ему, мы, конечно, строго накажем использовать только uncommited read, но кто его, дурака, знает).

О чем нужно позаботиться разработчику под Oracle для того, чтобы не подвесить front-end? Поскольку единственное место, где блокировка может произойти - это update в программе "авторизация", будем делать этот самый update по ROWID и немедленно COMMIT после каждой записи. Поскольку front-end по определению тоже длинными транзакциями не грешит, все довольны и никто никому не мешает.

Теперь мы решили переехать на DB2... Как много изменений нужно будет внести в это простейшее приложение? Думается, это будет уже совсем другое приложение. И виноват в этом, конечно же, Oracle, который не следует стандарту SQL92.

PS. Хорошо, когда выходной. Всякую лабуду можно сочинять

[tengiz]

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

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

IBM имеет стандартное решение в виде комбинации MQ Series + DB/2. Так же как и MS: MSMQ + SQL Server. Очень крупные системы веб-торговли построены именно так.

[zVlad]

Вопрос к Sp123: в Вашем конкретном back-end, или это возможно (согласно предикатам в SELECT-ах) прикосаться к данным, которые могут быть предметом модификации front-end-ом?
Или это два непересекающихся ЛОГИЧЕСКИ сегмента данных?

Sp123 wrote:
"Если под словом "данные" понимать rows, то пересечения - сплошь и рядом. К примеру, есть в таблице поля A и B. Изначально записи создаются на front-end со значением B = 'CREATED', в дальнейшем front-end это поле не меняет, зато все время очень активно модифицирует поле A и страшно злится, если что-то "зависло". Раз в полчаса некая back-end программа (назовем ее "авторизация") должна выбрать все записи с B = 'CREATED', поменять значение на 'PENDING', поманипулировать со всякого рода датой, может быть даже файлы какие-нибудь туда-сюда погонять по ftp, после чего обновить значение B на 'SUCCESS' или 'FAIL'. При этом никакие долгие блокировки не допустимы, за select for update бьют канделябром. Кроме этого есть еще одно приложение (назовем его "караул"), которое раз в день выбирает записи в соcтоянии 'PENDING-дольше-трех-дней-по-состоянию-на-9:00pm' и отсылает злобный e-mail заинтересованным начальникам для разбора полетов. После чего кто-нибудь начинает активно придумывать и гонять select'ы и искать виновных. Итого имеем как минимум два запроса, для которых uncommited read не годится:
- "авторизация" не должна видеть записи c В = 'CREATED', для которых еще не было commit, потому как front-end может их rollback, а поезд уже ушел
- "караул" хочет видеть точный снимок состояния таблицы на 9 утра безо всяких там dirty
... и одного дятла, который стучит по кнопкам, будучи в состоянии стресса (ему, мы, конечно, строго накажем использовать только uncommited read, но кто его, дурака, знает).

О чем нужно позаботиться разработчику под Oracle для того, чтобы не подвесить front-end? Поскольку единственное место, где блокировка может произойти - это update в программе "авторизация", будем делать этот самый update по ROWID и немедленно COMMIT после каждой записи. Поскольку front-end по определению тоже длинными транзакциями не грешит, все довольны и никто никому не мешает."

Теперь мы решили переехать на DB2... Как много изменений нужно будет внести в это простейшее приложение? Думается, это будет уже совсем другое приложение. И виноват в этом, конечно же, Oracle, который не следует стандарту SQL92.

PS. Хорошо, когда выходной. Всякую лабуду можно сочинять [/quote]"


Конец цитаты

Прежде всего. То что Вы описали - это результат "творческого" осмысления неким первичным девелопером бизнес-задачи. Если заниматься этим прикладом всерьез то нужно было бы вникнуть в то а почему это так нужно? Подвергнуть принятые ранее проектные решения критики с точки зрения желательного механизма конкурентного доступаю И я Вас уверяю хорошее решение будет найдено и в случае DB2. Такое переосмысление было бы не вредно в любом случае. Чутье мне подсказывает - то что Вы описали - выражение заблуждения относительно бизнес требований.

Несколько конкретных вопросов:
"....При этом никакие долгие блокировки не допустимы, за select for update бьют канделябром. ..." - я так понимаю это что принята практика когда сначала делается просто SELECT, а затем UPDATE with ROWID. Так? Что если между SELECT и UPDATE произошло обновление выбранных записей? Ведь блокировать то их нельзя.

"...Кроме этого есть еще одно приложение (назовем его "караул"), которое раз в день выбирает записи в соcтоянии 'PENDING-дольше-трех-дней-по-состоянию-на-9:00pm.... " - почему здесь "dirty read" то не годиться? А как вообще "PENDING" может дольше трех дней висеть если "..."авторизация") должна выбрать все записи с B = 'CREATED', поменять значение на 'PENDING', ......, после чего обновить значение B на 'SUCCESS' или 'FAIL'"?


"О чем нужно позаботиться разработчику под Oracle для того, чтобы не подвесить front-end? Поскольку единственное место, где блокировка может произойти - это update в программе "авторизация", будем делать этот самый update по ROWID и немедленно COMMIT после каждой записи." - В DB2 это было бы:

Isolation level CS, and

OPEN CURSOR C52 ... WITH HOLD
DO FOREVER
FETCH C52 INTO ......
COMMIT
END

[sp123]

Прежде всего. То что Вы описали - это результат "творческого" осмысления неким первичным девелопером бизнес-задачи. Если заниматься этим прикладом всерьез то нужно было бы вникнуть в то а почему это так нужно? Подвергнуть принятые ранее проектные решения критики с точки зрения желательного механизма конкурентного доступаю

А там вникать-то и не во что. Человек сделал заказ в магазине, но в момент on-line авторизации кредитной карты, которую делает third-party контора черт знает где, "дверью провод передавили". Кастомер не виноват, заказ условно принят, остальные данные введены и началась их первичная обработка, но авторизация отложена "на потом". Бизнес-логика сомнению не подлежит и не дискутируется - раз не смогли авторизовать в on-line по техническим причинам, то делайте это в back-end. Вот и вся бизнес-задача.

Критиковать проектное решение с точки зрения проблем конкурентного доступа, когда эти проблемы в данной базе отсутствуют - это немного странно. Делать все базо-независимо? Да, так можно. Вся бизнес-логика - на Java, база данных - сарай. Как-нибудь без меня . Предлагаю также неплохую идею - надо писать приложения для DB2 с учетом стандартов PostgreSQL, там тоже есть много интересного и правильного с их точки зрения. И не пользоваться JCL, потому что его нет в Unix.

И я Вас уверяю хорошее решение будет найдено и в случае DB2.

Несомненно.

Такое переосмысление было бы не вредно в любом случае. Чутье мне подсказывает - то что Вы описали - выражение заблуждения относительно бизнес требований.

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

Несколько конкретных вопросов:
"....При этом никакие долгие блокировки не допустимы, за select for update бьют канделябром. ..." - я так понимаю это что принята практика когда сначала делается просто SELECT, а затем UPDATE with ROWID. Так? Что если между SELECT и UPDATE произошло обновление выбранных записей? Ведь блокировать то их нельзя.

Ни одно приложение, кроме указанного, поле B не меняет. "Update" - на самом деле несколько более сложная вещь в виде stored procedure, которая делает предварительный анализ того, что она хочет менять, и проверяет, были ли критически важные для данной задачи изменения в записи между select и update.

"...Кроме этого есть еще одно приложение (назовем его "караул"), которое раз в день выбирает записи в соcтоянии 'PENDING-дольше-трех-дней-по-состоянию-на-9:00pm.... " - почему здесь "dirty read" то не годиться?

Ни один отчет не должен отражать незавершенные транзакции. Бизнес-правило.

А как вообще "PENDING" может дольше трех дней висеть если "..."авторизация") должна выбрать все записи с B = 'CREATED', поменять значение на 'PENDING', ......, после чего обновить значение B на 'SUCCESS' или 'FAIL'"?

А это тот самый alert на событие, которое не должно было случиться. Затянувшиеся "технические проблемы" со стороны third-party, в результате которых ни FAIL, ни SUCCESS не пришел. Можно заменить три дня на десять минут, суть не меняется. Можно, опять же, передизайнить. На том и порешили .

[Sabina]

Вы меня явно заинтриговали, Sabina. Не могли бы развернуть мысли о том "...что они хотят идет немного в разрез с назначением нашего приложения и нехило его усложняет в то время как прелесть его в простоте". Чем DB2 может усложнить жизнь то? Или дело не в DB2?

Нет, конечно же не в DB2 дело. ИБМ проявили интерес к нашей программе, но им надо чтобы она делала совершенно специфичные вещи, а именно работала с их help desk для фермы серверов, типа той что в Колорадо.
Сама программа для network management, интегрирована с Visio. Прелесть ее в том, что она достаточно проста.

Многие коллеги считают, что мы убъем кучу времени пытаясь переделать продукт, и все понапрасну. Менеджмент пытается получить с них спецификации ....

А переход на DB2, это как бы само собой разумеется раз под IBM.

[zVlad]

Вы меня явно заинтриговали, Sabina. Не могли бы развернуть мысли о том "...что они хотят идет немного в разрез с назначением нашего приложения и нехило его усложняет в то время как прелесть его в простоте". Чем DB2 может усложнить жизнь то? Или дело не в DB2?

Нет, конечно же не в DB2 дело. ИБМ проявили интерес к нашей программе, но им надо чтобы она делала совершенно специфичные вещи, а именно работала с их help desk для фермы серверов, типа той что в Колорадо.
Сама программа для network management, интегрирована с Visio. Прелесть ее в том, что она достаточно проста.

Многие коллеги считают, что мы убъем кучу времени пытаясь переделать продукт, и все понапрасну. Менеджмент пытается получить с них спецификации ....

А переход на DB2, это как бы само собой разумеется раз под IBM.

Sabina, мне кажется Вы и Ваши коллеги немножко перебарщиваете. Сотрудничество с ИБМ - это должно быть здорово (если конечно ваш менежемент умеет держать форму). Но для вас это ... сами понимаете - все мы люди подневольные. Не мы с ИБМ-ами и Мелкософтами общаемся, а наши менеджеры. Что касается DB2 - там все должно быть ОК. Иначе пишите, вылезу из кожи - помогу.

[Sabina]

Sabina, мне кажется Вы и Ваши коллеги немножко перебарщиваете. Сотрудничество с ИБМ - это должно быть здорово (если конечно ваш менежемент умеет держать форму). Но для вас это ... сами понимаете - все мы люди подневольные. Не мы с ИБМ-ами и Мелкософтами общаемся, а наши менеджеры. Что касается DB2 - там все должно быть ОК. Иначе пишите, вылезу из кожи - помогу.

Cпасибо за предложение помощи. Она мне конечно очень нужна, я ведь интерн вообще говоря. Но мне очень многое на работе доверяют. То ли их положение такое, то ли я заслуживаю доверия. В случае второго тем более хочется его оправдать.

То, что deal с ИБМ, был бы для нас большой удачей, это понятно. Но ведь поскольку "не мы с ИБМ-ами и Мелкософтами общаемся", кто их там знает какой на самом деле разговор состоялся между их представителем и нашим sales. Хочется надеятся, что хотя бы спецификации будут на бумаге...

[zVlad]

Sabina, мне кажется Вы и Ваши коллеги немножко перебарщиваете. Сотрудничество с ИБМ - это должно быть здорово (если конечно ваш менежемент умеет держать форму). Но для вас это ... сами понимаете - все мы люди подневольные. Не мы с ИБМ-ами и Мелкософтами общаемся, а наши менеджеры. Что касается DB2 - там все должно быть ОК. Иначе пишите, вылезу из кожи - помогу.

Cпасибо за предложение помощи. Она мне конечно очень нужна, я ведь интерн вообще говоря. Но мне очень многое на работе доверяют. То ли их положение такое, то ли я заслуживаю доверия. В случае второго тем более хочется его оправдать.

То, что deal с ИБМ, был бы для нас большой удачей, это понятно. Но ведь поскольку "не мы с ИБМ-ами и Мелкософтами общаемся", кто их там знает какой на самом деле разговор состоялся между их представителем и нашим sales. Хочется надеятся, что хотя бы спецификации будут на бумаге...

Sabina, ИБМ - это как партком в советские времена - никогда не подведет. Надежный как ... я не знаю что..

[Sabina]

[Sabina, ИБМ - это как партком в советские времена - никогда не подведет. Надежный как ... я не знаю что..

Влад, вы не смотрели фильм Pirates of Silicon Valley? Он тут был по телеку несколько лет назад, муж где-то в И-нете купил его недавно на VHS.
Я в это фильм просто влюбилась. Он о временах начала Apple и Microsoft. Любопытно что Джобс и Гейтс сказали посмотрев этот фильм
Так вот там очень любопытный образ IBM нарисован.