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

[Митяй]

1000 терминалов, допустим, 1 транзакция в минуту. Допустим, в одной транзакции лочится 100 записей. Допустим, сообщение о блокировке занимает 0.5 кб со всей служебной информацией. Получаем 1000 * 100 *2 (залочить / разлочить) = 200,000 сообщений и 100 Mb в минуту, примерно 30,000 / 1.5MByte в секунду. 10Mbit сеть такого точно не потянет, 100MBit будет загружена на 20% _теоретического_ предела (который весьма теоретичен для мелких сообщений).

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

Уведомление клиенту о кратковременных блокировках в реальной системе отправляется не раз в минуту, а гораздо чаще. В системе продажи театральных и подобных билетов, в разработке которой я участвовал, данные о блокировках обновляются у клиента по умолчанию раз в 5 секунд. Казалось бы все еще хуже, чем Вы написали. Однако это не так. Дело в том, что обновлению подвергаются только те данные, которые в каждый момент времени интересуют каждого клиента. Рассмотрим сценарий работы кассира с покупателем. Пока кассир просматривает расписания и обсуждает с покупателем, какой зал и какое представление выбрать, никакого принудительного обновления данных не требуется. Когда выбран конкретный сеанс или спектакль, кассир открывает схему зала, на которой видны статусы мест. В этот момент один раз из базы отдается полная схема статусов мест. Затем раз в пять секунд, пока сервер приложений знает, что у данного клиента открыта схема зала, он посылает клиенту инкрементальные обновления, то есть только изменения статусов с использованием специализированного протокола. Поскольку с одним залом и одном сеансом одновременно редко работает больше двух-трех кассиров, статусы мест меняются довольно медленно. Оптимизированая сервисная посылка, содержащая данные об изменениях статусов мест в среднем (статистика реальной системы) по объему не превышает 10 байт (чаще всего передается только флаг отсутствия изменений). Что в 50*100*2 раз меньше Вашей оценки для одного рабочего места. А учитывая, что работа со схемой зала занимает не более 30% активного времени каждого кассира, трафик будет еще меньше. И даже с учетом того, что данные во время работы со схемой передаются в 12 раз чаще, чем Вы предположили, на самом деле, даже при предложенной Вами недетской активности пользователей суммарный сервисный трафик не превысит 10 байт *12 раз в минуту * 1000 р. мест * 30% времени ~ 40 КБайт в минуту или менее 1 КБайта в секунду. Причем это будет пиковый трафик на уровне теоретического предела активности. Модема 14400 вполне хватит

А стандартными средствами это делается (в Информиксе)-
set wait to 10 -- seconds
set isolation to repeatable read
begin
select ... -- records locked by share lock, if anybody updates record
we wait for 10 sec
update ... -- if somebody locked this record we wait for 10 sec
commit

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

Прэлэстно. Значит, сервер приложений раз в пять секунд запускает select для каждого терминала ? При 1000 работающих терминалов - 200 selectов в секунду ? Или вы пошли дальше, и наваяли заодно и типа сервер базы данных ?

Кстати, расскажите как вы уместите TCP пакет в 10 байт. Или вы предлагаете и свой протокол связи заодно наваять ?

И это при том, что по условиям задачи, "с одним залом и одном сеансом одновременно редко работает больше двух-трех кассиров, статусы мест меняются довольно медленно. ". Т.е. для ваших условий вполне подходит Commited Read / Update с весьма редкими случаями отказа клиенту в уже выбранном месте. И вся ваша система нагорожена исключительно для того, чтобы _наглядно_ показать клиенту, что он долго щелкал клювом и у него увели место из-под носа ?

[Palych]

Угу
Даешь передачу голых SQL скриптов !
Даешь 1000 вызовов голых запросов в транзакции !
Изза которых выполение операции длится 30sec, а могло бы 1sec.
Зато логика на клиенте
Правда потом http timeout, и непонятно что делать...

Единственный выход нанимать таких как я и платить им деньги

А я вроде бы про логику на клиенте ничего не говорил. Логика должна быть на сервере. Только на другом

С нашей высокомерной точки зрения сервера все остальные - жалкие клиенты

У нас недавно нарвались на такие грабли: писали приблуду на ProC, которая читала из Stored Procedure около 1000 строк.
Работала минут 5. Перешли на голый SQL - несколько секунд. При этом SP практически ничего ни делала, просто вызывала SELECT.
Оказалось что при обращении к SP ProC не умеет кешировать данные и делать batch retrieve.

[SGA]

Unlike Oracle, DB2 doesn’t give us SQL statement is to be deadlocked.

zVlad,

Пожалуйста уточняйте каждый раз
"Unlike Oracle, DB2 for OS/390 doesn’t give us SQL statement is to be deadlocked"

DB2 UDB for Unix and Windows с diaglevel=4 пишет информацию о
SQL statement is to be deadlocked в db2diag.log file
и дает возможность получить исчерпывающую deadlock-related
информацию в db2 event monitor for deadlocks.

[Dmitry67]

У нас недавно нарвались на такие грабли: писали приблуду на ProC, которая читала из Stored Procedure около 1000 строк.
Работала минут 5. Перешли на голый SQL - несколько секунд. При этом SP практически ничего ни делала, просто вызывала SELECT.
Оказалось что при обращении к SP ProC не умеет кешировать данные и делать batch retrieve.

Это где все так запущено ?
Вообще то кеширует данные сервер... И непонятно как такое может быть

Единственно что могу предполоджить - values with irregular selectivivty, rjulf

select * from ... where col=1234

генерит совершенно другой план чем

select * from ... where col=@var

потому что значение 1234 - особенное

[zVlad]

Unlike Oracle, DB2 doesn’t give us SQL statement is to be deadlocked.

zVlad,

Пожалуйста уточняйте каждый раз
"Unlike Oracle, DB2 for OS/390 doesn’t give us SQL statement is to be deadlocked"

DB2 UDB for Unix and Windows с diaglevel=4 пишет информацию о
SQL statement is to be deadlocked в db2diag.log file
и дает возможность получить исчерпывающую deadlock-related
информацию в db2 event monitor for deadlocks.

Привет коллега-DB2-шник. Спасибо за дополнение. Как-то редко здесь на форуме DB2-ника встретишь. Вообще то когда я писал фразу понравившуюся Вам, я и сам думал, что возможно можно и оператор выудить откуда нибудь. Есть Trace, IFI для этого. Event Monitor тоже есть. Тогда уточняю - в оперативном сообщении нет этой информации.
Если продолжить эту тему то позвольте спросить (всех) - а что собственно дает знание какой оператор был deadlocked без знания оператора вызвавшего deadlock в свете известного фокта что deadlock - это чисто проблема дизайна (как справедливо незатейливо напоминает Оракл), т.е. созданая сознательно при программировании? Хотя я тут же могу сам себя (а может быть и Оракл) опровергнуть - причиной deadlock может быть неправильный уровень блокирования - page level locking instead of row level (кстати?, Tengiz, мы тут недавно касались этой темы. Удовлетворите любопытство - MS SQL обеспечив row level locking в 1998 году оставил возможность использовать page level locking? А какие размеры страниц кроме 8K еще доступны?).
Вот сколько много вопросов я сегодня с утра спросил после посещения вчера "Русской бани".

[zVlad]

...........

Кстати, SGA, а что Вы не поделились когда мы с Tengiz-om, обменивались мнениями о статье "...Oracle to DB2...." - там ведь DB2 for Windows, Unix имется в виду - не DB2 for OS/390? Мне и мысли в голову не приходило (и сейчас не приходит) сказать - да мол это Toronto Lab со своим DB2 - это на California DB2. DB2 - она везде DB2.

[vc]

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

У нас недавно нарвались на такие грабли: писали приблуду на ProC, которая читала из Stored Procedure около 1000 строк.
Работала минут 5. Перешли на голый SQL - несколько секунд. При этом SP практически ничего ни делала, просто вызывала SELECT.
Оказалось что при обращении к SP ProC не умеет кешировать данные и делать batch retrieve.

Could you post a small test case showing the above behaviour ?

One has to work really hard to make a stored procedure work so slow. The only scenario I can think of would be the one in which an SP is called once per each row instead of getting the whole result set at one go, but, again, a separte select would perform as badly in this case...

Also, if you mean the prefetch in your last sentence, then Pro*C should behave in the same way regardless of how the result set was created.

Rgds.

Rgds.

[Palych]

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

У нас недавно нарвались на такие грабли: писали приблуду на ProC, которая читала из Stored Procedure около 1000 строк.
Работала минут 5. Перешли на голый SQL - несколько секунд. При этом SP практически ничего ни делала, просто вызывала SELECT.
Оказалось что при обращении к SP ProC не умеет кешировать данные и делать batch retrieve.

Could you post a small test case showing the above behaviour ?

One has to work really hard to make a stored procedure work so slow. The only scenario I can think of would be the one in which an SP is called once per each row instead of getting the whole result set at one go, but, again, a separte select would perform as badly in this case...

Also, if you mean the prefetch in your last sentence, then Pro*C should behave in the same way regardless of how the result set was created.

Rgds.

Rgds.

I'm not really familiar with that project. The guy who worked claimed that the problem was not in the SP, but in the Pro*C framework, which made round-trip to the server for each row.
Oracle support recomended using SELECT.
The joke is - it works much faster in Java/JDBC, although the main purpose of that project was performance improvement...

[vc]

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

... skipped ...
I'm not really familiar with that project. The guy who worked claimed that the problem was not in the SP, but in the Pro*C framework, which made round-trip to the server for each row.
Oracle support recomended using SELECT.
The joke is - it works much faster in Java/JDBC, although the main purpose of that project was performance improvement...

Well, it' most definitely possible to achieve better performance in Pro*C than in Java/JDBC in comparable circumstances, Oracle support recommendations notwithstanding. Even the default prefetch size is higher in Pro*C than in JDBC (100 vs. 15) which means that there is only one round-trip per each 100 rows.

One can hardly blame the tool for one's inability to use it properly.

Rgds.

[hren]

Прэлэстно. Значит, сервер приложений раз в пять секунд запускает select для каждого терминала ? При 1000 работающих терминалов - 200 selectов в секунду ? Или вы пошли дальше, и наваяли заодно и типа сервер базы данных ?

На самом деле, 200 простых запросов в секунду - это не слишком высокая загрузка. Тем более, что их при описанном мной сценарии не 200, а 60 (30%), а в реальности еще меньше. Но в нашем случае селекты происходят заметно реже, поскольку основную массу запросов обрабатывает сервер приложений (EJB)без обращений в базу (за счет использования паттерна read-mostly).

Кстати, расскажите как вы уместите TCP пакет в 10 байт. Или вы предлагаете и свой протокол связи заодно наваять ?

Тут Вы несомненно правы. Я ошибся, посчитал только логический обмен данными. Умножьте в 5 раз, чтобы учесть заголовки пакетов. Умножьте еще в 5 раз, чтобы учесть прочие оверхеды, которые наверняка есть. Будет аж 25 Кбайт в секунду и модема 14400 катастрофически не хватит. Увы, жизнь не удалась

И это при том, что по условиям задачи, "с одним залом и одном сеансом одновременно редко работает больше двух-трех кассиров, статусы мест меняются довольно медленно. ". Т.е. для ваших условий вполне подходит Commited Read / Update с весьма редкими случаями отказа клиенту в уже выбранном месте. И вся ваша система нагорожена исключительно для того, чтобы _наглядно_ показать клиенту, что он долго щелкал клювом и у него увели место из-под носа ?

Система не нагорожена, а просто сделана и вполне пристойно работает. Апдейт статусов мест был одним из требований заказчика при постановке задачи. Сделать это оказалось совсем несложно, никакого особенного оверхеда в реальной жизни она не создает, а приложение сильно выигрывает в глазах конечного пользователя (маркетологи заказчика очень активно используют именно это свойство, доказывая, что система является true online, в отличие от конкурентов - чушь, конечно, но им приятно).

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

[hren]

Нет, это работает не так. При использовании пользовательских блокировок в ORACLE или SQL Server статус ресурса - заблокирован/свободен - легко выясняется посылкой пробного запроса на блокирование с нулевым таймайутом. Когда Вашему приложению нужно произвести действия с ресурсом, тогда оно и спросит, доступен ли он для запрашиваемых действий. Хранимый в БД код для этого совсем не нужен, хотя я, возможно, не понимаю, что Вы имеете в виду. Системные процедуры для работы с абстрактными пользовательскими блокировками разумеется можно вызывать напрямую, без необходимости писать специальные промежуточные хранимые процедуры.

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

[tengiz]

Если продолжить эту тему то позвольте спросить (всех) - а что собственно дает знание какой оператор был deadlocked без знания оператора вызвавшего deadlock в свете известного фокта что deadlock - это чисто проблема дизайна (как справедливо незатейливо напоминает Оракл), т.е. созданая сознательно при программировании? Хотя я тут же могу сам себя (а может быть и Оракл) опровергнуть - причиной deadlock может быть неправильный уровень блокирования - page level locking instead of row level

Причина deadlock в подавляющем числе случаев приложений без adhoc запросов - это ошибка дизайна. Поэтому так важно иметь исчерпывающую диагностику, чтобы точно понять какая точно последователность действий привела к deadlock и сделать необходимые коррекции. Неправильный уровень блокирования - таблица, страница или строка - это хоть не всегда проблема дизайна, но коррекции скорее всего всё равно нужно делать в приложении. И опять, подробная диагностика поможет сориентироваться и сделать необходимые изменения. Это может быть порядок вызова операторов, создание нового индекса или удаление ненужных, использование locking hints и пр. А административные меры в качестве лечения применяются намного реже. В любом случае - чем больше информации о ситуации, в которой случился deadlock - тем лучше.

MS SQL обеспечив row level locking в 1998 году оставил возможность использовать page level locking? А какие размеры страниц кроме 8K еще доступны?

Да, оставил. 8K - это единственный доступный размер страницы для SQL Server начиная с версии 7.0.

[hooch]

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

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

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

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

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

Eto nepravda, v sluchae s Oracle SELECT FOR UPDATE pozvolyaet etogo izbezat..

[zVlad]

2zVlad: Это интересно, но описанное в статье различие нельзя назвать несовместимостью. Насколько я понимаю, на поведение приложений (семантически) это никак не влияет................

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

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

Eto nepravda, v sluchae s Oracle SELECT FOR UPDATE pozvolyaet etogo izbezat..

Кажется начинается 4-ая серия Если коротко:
1. Упоминался просто SELECT и из контекста ясно что не FOR UPDATE.
2. FOR UPDATE заблокирует все результирующее множество, а не только текущую строку. Могу ошибаться - поправьте.
3. Если бы там где надо в Оракл приложениях в самом деле писали бы FOR UPDATE - то с точки зрения concurrency такие приложения значительно уступали бы блокировочникам.

[Sabina]

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

ИБМ с нами бумажку какую-то подписали, ой, мама, счас начнется
И главное под самый крисмас. Прощайте праздники

Сабина