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

[zVlad]

zVlad,

Позволю себе оставить без комментариев большую часть Ваших замечаний. Повторяться мне не хотелось бы. Насчёт остального:

- Полноценный RLL (row level locking) в SQL Server появился в версии 7 (1998), после того, как размер страницы стал 8K (был 2K), а в версии 6.5 (1995) был ограниченный вариант - insert row level locking.

- Честное слово, неудобно задавать этот вопрос, но, теме не менее - что такое, по-Вашему, deadlock detection?

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

- наличие или отсутствие эскалации блокировок никого по большому счёту не интересует. Главный вопрос в том, заткнётся ли сервер от недостатка ресурсов если почему-то понадобится наложить очень много блокировок? И здесь нет однозначного ответа, какой сервер лучше. Во-первых, ORACLE накладывает только X блокировки, в отличие от DB2. Во-вторых, у ORACLE действительно есть ограничение на максимальное количество транзакций, интересующихся строками в одной и той же странице. Но зато отсутствуют физические ограничения на общее количество X блокировок. У DB2 - всё наоборот: есть физической ограничение на общее количество блокировок, причём любых видов, а не только X, но нет никаких ограничений страничного уровня. И что по-Вашему лучше? Автор намекет, что DB2, разумеется лучше - вот это и есть поверхностный халтурный анализ.

Насчёт 4 страниц из 80 с лишним - да я на самом деле внимательно прочитал только эти 4, просто потому что остальное лично мне уже мало интересно. Как Вы думате, концентрация ляпов на оставшихся страницах намного ниже или мне просто невероятно повезло нарваться на самый смак?

Что такое deadlock detection ф толком не знаю. Т.е. внешнее описание как это работает, но как это реализованно, да еще в разных БД - ни малейшего понятия. Вы тут с vc на эту тему обменивались. Я толко понял, что Вы Tengiz подсвечивали какие-то слабые стороны Оракл, а vc (в вашей с ним последней дискуссии) поддел Вас. Кстати, а почем получается deadlock когда RR? Вроде бы не должно быть?

"Когда в CS курсор сходит со строки - она быть изменена другими транзакциями". Так определен этот уровень изоляции в DB2 и поверьте мне он широко и эффективно используется.

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

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

[vc]

I did not want to take part in the discussion but...

Re: http://forum.privet.com/viewtopic.php?t=45889

.... Я толко понял, что Вы Tengiz подсвечивали какие-то слабые стороны Оракл, а vc (в вашей с ним последней дискуссии) поддел Вас. .

1. I did no such thing. I have nothing but respect for Tengiz's knowledge and experience.

2. It was not a discussion. I wanted to clarify SQL Server behaviour in certain circumstances so I asked a question and I got a perfectly good answer. The 'RR' dead-lock possibility had not occured to me until later.

3. I believe any locking scheduler (Informix, DB2, Sybase) would behave in this scenario in the same way. Tengiz will correct me if I am wrong.

[tengiz]

Что такое deadlock detection ф толком не знаю. Т.е. внешнее описание как это работает, но как это реализованно, да еще в разных БД - ни малейшего понятия. Вы тут с vc на эту тему обменивались. Я толко понял, что Вы Tengiz подсвечивали какие-то слабые стороны Оракл, а vc (в вашей с ним последней дискуссии) поддел Вас. Кстати, а почем получается deadlock когда RR? Вроде бы не должно быть?

Другими словами Вас вполне должна устроить простая констатация, что deadlock detection в ORACLE имеется, причём абсолютно нормальный, полноценный, функционально ничем не отличающийся от того, что есть в DB2. В противоположность тому, что говорится в этом тексте. И это не просто ляп. Неважно, автор не понимает о чём пишет или понимает, но сознательно врёт. Халтура есть халтура. В дискусси с vc он меня справедливо поддел тем, что я зевнул довольно старое изменение в стандарте, касающееся коррелированных подзпароса в select list. Что никакого отношения ни к deadlock, ни к их detection не имеет.

"Когда в CS курсор сходит со строки - она быть изменена другими транзакциями". Так определен этот уровень изоляции в DB2 и поверьте мне он широко и эффективно используется.

Конечно, но только зачем врать, что все уровни, кроме UR гарантируют неизменность прочитанных данных, как это делается в тексте?

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

Если оставить в покое попытки оценить что лучше и что хуже, то и дело попадающиеся в тексте, то даже сугубо практичесий перевод приложения с ORACLE на DB2 руководствуясь сугубо практическими рекомендациями такого качества может закончиться сугубо практическим фиаско. Приложение либо задохнётся в дедлоках, либо просто не будет правильно работать и покажет чёрт знает что в отчётах из-за рекомендации обильно пользоваться UR. И это в лучшем случае. В худшем - наврёт в транзакциях по переводу денег. И кому это надо? На мой взгляд, статья должна быть прежде всего ориентирована на опытных разработчиков и администраторов ORACLE - а им обычно не нужно рассказывать как работает этот продукт. Тем более, когда это делается настолько безграмотно.

[Dmitry67]

tengiz, небольшая коррекция
Этот документ, как я понял, НЕ халтура, а довольно высококлассная работа, выполенная техническим специалистом под руководством опытного маркетолога

Впрочем, такими документами грешат все фирмы... Помню сравнение NT vs Novell в публикациях этих двух фирм... Да и документы от Oracle...

[hren]

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

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

[hren]

...Объясните, как Вы предлагаете делать описанные мной вещи с использованием только штатных средств блокировки СУБД (любой).

На ORACLE или MS SQL это делается при помощи штатного стредства - abstract locking manager, базовые возможности которого доступны прикладным программистам. В SQL Server это пара процедур sp_getapplock/sp_releaseapplock. В ORACLE это - dbms_lock.allocate_unique/dbms_lock.request/dbms_lock.release.

Тот же вопрос - какова техника уведомлений? Я уж не говорю о том, что с моей точки зрения в трех (или более)-уровневой системе использовать хранимый код вообще дурной тон - вся логика должна работать вне базы (сейчас меня БД-программисты прибьют )

[Dmitry67]

Я уж не говорю о том, что с моей точки зрения в трех (или более)-уровневой системе использовать хранимый код вообще дурной тон - вся логика должна работать вне базы (сейчас меня БД-программисты прибьют )

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

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

[zVlad]

Что такое deadlock detection ф толком не знаю...........

Другими словами Вас вполне должна устроить простая констатация, что deadlock detection в ORACLE имеется, причём абсолютно нормальный, полноценный, функционально ничем не отличающийся от того, что есть в DB2. ...... В дискусси с vc он меня справедливо поддел тем, что я зевнул довольно старое изменение в стандарте, касающееся коррелированных подзпароса в select list. Что никакого отношения ни к deadlock, ни к их detection не имеет.

"Когда в CS курсор сходит со строки - она быть изменена другими транзакциями". Так определен этот уровень изоляции в DB2 и поверьте мне он широко и эффективно используется.

Конечно, но только зачем врать, что все уровни, кроме UR гарантируют неизменность прочитанных данных, как это делается в тексте?

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

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

Как только подвернется случай и время я постараюсь заполнить мой пробел в смысле deadlock detection в Оракл. Простой констатации, что с этим все нормально на сегодняшний день мне абсолютно достаточно.
По поводу deadlock detection я спросил (и мне никто не ответил): "Может ли Оракл приложение знать доподлинно что отказ полученный от БД - это deadlock (естественно в случае deadlock)? Примерно как это выглядит?" Днем спрошу также знакомого программера об этом.

Еще раз перечитал о CS (Tengiz, за что Вы так не любите ИБМ? Не кажется ли Вам что Ваша "нелюбовь" к ИБМ приводит Вас к тому что Вы так бичуете - к неточностям, искажениям и т.д.). Не хочу снова переводит с английского на русский. Думаю, что любой желающий может прочитать сам и сделать свой вывод.

[hren]

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

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

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

[camel]

По поводу deadlock detection я спросил (и мне никто не ответил): "Может ли Оракл приложение знать доподлинно что отказ полученный от БД - это deadlock (естественно в случае deadlock)? Примерно как это выглядит?"

в одной из сессий, команда, вызвавшая deadlock, откатывается с ошибкой ORA-00060: deadlock detected while waiting for resource

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

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

*** 2003-10-16 09:31:51.560
*** SESSION ID:(31.589) 2003-10-16 09:31:51.525
DEADLOCK DETECTED
Current SQL statement for this session:
update dept set loc='DENVER' where deptno=20
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL.

[Dmitry67]

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

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

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

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

[zVlad]

I did not want to take part in the discussion but...

Re: http://forum.privet.com/viewtopic.php?t=45889

.... Я толко понял, что Вы Tengiz подсвечивали какие-то слабые стороны Оракл, а vc (в вашей с ним последней дискуссии) поддел Вас. .

1. I did no such thing. I have nothing but respect for Tengiz's knowledge and experience.

2. It was not a discussion. I wanted to clarify SQL Server behaviour in certain circumstances so I asked a question and I got a perfectly good answer. The 'RR' dead-lock possibility had not occured to me until later.

3. I believe any locking scheduler (Informix, DB2, Sybase) would behave in this scenario in the same way. Tengiz will correct me if I am wrong.

Sorry, guys, I made incorrect assumptions. I apologize.
I can confirm, DB2 works in the same way for that particular case you mentioned above.

[zVlad]

По поводу deadlock detection я спросил (и мне никто не ответил): "Может ли Оракл приложение знать доподлинно что отказ полученный от БД - это deadlock (естественно в случае deadlock)? Примерно как это выглядит?"

в одной из сессий, команда, вызвавшая deadlock, откатывается с ошибкой ORA-00060: deadlock detected while waiting for resource

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

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

*** 2003-10-16 09:31:51.560
*** SESSION ID:(31.589) 2003-10-16 09:31:51.525
DEADLOCK DETECTED
Current SQL statement for this session:
update dept set loc='DENVER' where deptno=20
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL.

Thank you Camel.
In DB2 (and all other blocking RDBMS), how many deadlocks happen is a matter of how application was written.
DB2 puts messages in generic diagnostic file, and those messages looks like (first message (DSN375I) is about who was a victim, and who was a holder, and second (DSN501I) one is about resource on which it happened in form <dbname>.<spacename>.<pagenumber>.<rownumber>):

11.03.56 STC15922 DSNT375I -DB01 PLAN=DSNREXX WITH
CORRELATION-ID=SIVB1
CONNECTION-ID=DB2CALL
LUW-ID=NET.DB01LU.BA2DF76B41EB=16652
THREAD-INFO=SIVB1:*:*:*
IS DEADLOCKED WITH PLAN=DSNTEP61 WITH
CORRELATION-ID=SIVBSPUF
CONNECTION-ID=BATCH
LUW-ID=NET.DB01LU.BA2DF770603D=16653
THREAD-INFO=SIVB:*:*:*
ON MEMBER DB01

11.03.56 STC15922 DSNT501I -DB01 DSNILMCL RESOURCE UNAVAILABLE
CORRELATION-ID=SIVB1
CONNECTION-ID=DB2CALL
LUW-ID=*
REASON 00C90088
TYPE 00000304
NAME DSNDB04 .NUMBERS .X'000002' '.X'01'

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

[tengiz]

Еще раз перечитал о CS (Tengiz, за что Вы так не любите ИБМ? Не кажется ли Вам что Ваша "нелюбовь" к ИБМ приводит Вас к тому что Вы так бичуете - к неточностям, искажениям и т.д.). Не хочу снова переводит с английского на русский. Думаю, что любой желающий может прочитать сам и сделать свой вывод.

ОК, ещё одна попытка (последняя!) сказать что уже сказал, но слегка другими словами и чуть подробнее: в тексте статьи утверждается, что данные прочитанные транзакцией остаются блокированными для всех уровней изоляции, кроме UR. Что неверно, хоть на русский переводи, хоть на грузинский. DB2 CS или ANSI READ COMMITTED только гарантирует, что он не прочитает грязные данные, но отнюдь не гарантирует, что прочитанные данные не будут изменены другими транзакциями. Единственное исключение, это когда в транзакции читается ровно одна строка, причём через курсор и когда этот курсор остаётся на этой единственной строке до конца транзакции.

[tengiz]

На ORACLE или MS SQL это делается при помощи штатного стредства - abstract locking manager, базовые возможности которого доступны прикладным программистам. В SQL Server это пара процедур sp_getapplock/sp_releaseapplock. В ORACLE это - dbms_lock.allocate_unique/dbms_lock.request/dbms_lock.release.

Тот же вопрос - какова техника уведомлений? Я уж не говорю о том, что с моей точки зрения в трех (или более)-уровневой системе использовать хранимый код вообще дурной тон - вся логика должна работать вне базы (сейчас меня БД-программисты прибьют )

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

[Митяй]

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, в отличие от конкурентов - чушь, конечно, но им приятно).

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