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

[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.

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

Сабина

[zVlad]

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

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

Сабина

Сабина, не дрейфь! Поможем!

[Dmitry67]

http://www.swissql.com/sql-server-to-db2.html

Случайно нашел по теме

[zVlad]

http://www.swissql.com/sql-server-to-db2.html

Случайно нашел по теме

Much more, regarding that, could be found here:

http://www-306.ibm.com/software/data/db2/migration/