Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 Тупиковая ситуация  [new]
Chacanov
Member

Откуда:
Сообщений: 31
Дорогие спецы!
помогите разобраться с ситуацией, возникающей при выборке из таблиц
и записи.
Часто стали появляться сообщение о тупиковой ситуации.
Сообщение приложено в файле.
Как ее можно обойти?
31 май 06, 13:18    [2725183]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
nkulikov
Guest
планировать транзакции.
31 май 06, 13:35    [2725302]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Chacanov
Member

Откуда:
Сообщений: 31
Планировать транзакции?
А как это можно сделать?
8 июн 06, 11:40    [2753211]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
warIord
Member

Откуда:
Сообщений: 207
это мил человек и есть суть db2, точка мракобесия, все вот достаточно просто и приемлемо, но механизм блокировок это черпак ... дегтя
8 июн 06, 13:20    [2753999]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
ggv
Member

Откуда:
Сообщений: 1810
просто старайтесь развести читающие и пишушие транзакции по времени и/или месту.
Это можно сделать только зная логику приложения, общие рекомендации - это вряд ли.
Опять же, какой процент строк таблицы затрагивается транзакцией, и прочая, и прочая - все в голове надо иметь.
8 июн 06, 13:42    [2754147]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Это основная проблема в DB2 - блокировки при чтении.
Если логика приложения не пострадает, то можно читать в UR-режиме - dirty reads. Этот режим указывается либо при описании курсора, либо при компияции (но уже для всего модуля). Плюс этого режима в том, что он не блокирует.

--
Антон
Per rectum ad astrum
9 июн 06, 18:57    [2760420]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Попробуй.
db2set DB2SKIPINSERTED=YES
db2set DB2SKIPDELETED=YES
9 июн 06, 19:17    [2760475]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
ggv
Member

Откуда:
Сообщений: 1810
вообще-то, это не совсем проблема, так как это основной способ достижения высокой производительности.
Просто есть плюсы и минусы, минус - в том, что думать надо, как транзакции развести.
В дополнение к сказанному Николаем - evaluate_uncommited тоже.
13 июн 06, 09:55    [2764319]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
--
Guest
ggv
просто старайтесь развести читающие и пишушие транзакции по времени и/или месту.

Вот это меня больше всего умиляет. Скажите, вы всегда знаете кто из 100 пользователей, что в данный момент делает? Мы можете спланировать каждое их действие?
ИМХО, не надо никого разводить (во всех смыслах), для начала надо стараться, чтобы изменения (update/insert/delete) вносились как можно быстрее, т.е. организовать транзакции таким образом, чтобы эти операции делались сразу перед commit.
15 июн 06, 10:11    [2773075]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
ggv
Member

Откуда:
Сообщений: 1810
про commit и так во всех доках написано.
А про юзверей - я ужо говорил как-то, в моем мире юзверей нет.
Вот запросы от них приходят, но "в очередь, сукины дети, в очередь!"
А когда они в очереди, то как их выбирать, в какой последовательности, по какому приоритету, и прочее - вот это и позволяет развести по месту и времени.
Ясный пень, когда идет запрос на update 3/4 содержимого большой таблицы, то легко может оказаться легче и быстрее отдать эту таблицу эксклюзивно этой транзакции, отмолотит и освободит.
Да пустой спор, беспредметный.
Если кому-то мешают юзвери - гнать их нафик!
15 июн 06, 10:17    [2773106]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
New Guest
Guest
Anton Demidov
Это основная проблема в DB2 - блокировки при чтении.
Если логика приложения не пострадает, то можно читать в UR-режиме - dirty reads. Этот режим указывается либо при описании курсора, либо при компияции (но уже для всего модуля). Плюс этого режима в том, что он не блокирует.

--
Антон
Per rectum ad astrum

Разрешите не согласиться с " Плюс этого режима в том, что он не блокирует.
" Блокирует и не просто а catalog tables!
"catalog locks are acquired even in uncommitted read applications using dynamic SQL. "
http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/c0005276.htm
15 июн 06, 20:30    [2776856]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
New Guest
Разрешите не согласиться с " Плюс этого режима в том, что он не блокирует.
" Блокирует и не просто а catalog tables!
"catalog locks are acquired even in uncommitted read applications using dynamic SQL. "
http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/c0005276.htm

Ясен пень блокирует каталог, а то вдруг ты таблицу дропнешь, а я в своём курсоре про это и не узнаю
На одновременные обновления таблицы (insert/update/delete) это никак не повлияет.

--
Антон
Per rectum ad astrum
15 июн 06, 22:50    [2777098]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4949
Anton Demidov
Плюс этого режима в том, что он не блокирует.

Даже если вы пишете в таблицу с ur, блокировка измененной записи сохраняется до конца транзакции.
Т.е. ur поможет читателю и писателю, но не двум писателям.
Так что высказывание все-таки не совсем корректное.
16 июн 06, 09:32    [2777628]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
warIord
Member

Откуда:
Сообщений: 207
2 ggv
Вот запросы от них приходят, но "в очередь, сукины дети, в очередь!"
А когда они в очереди, то как их выбирать, в какой последовательности, по какому приоритету, и прочее - вот это и позволяет развести по месту и времени.

что за очередь такая, кто ее контролирует, можно поподробнее?
16 июн 06, 11:47    [2778565]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
WebSphere MQ
16 июн 06, 12:25    [2778870]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
lazy-beaver
Member

Откуда: donetsk, UA
Сообщений: 186
ggv
про commit и так во всех доках написано.
А про юзверей - я ужо говорил как-то, в моем мире юзверей нет.
Вот запросы от них приходят, но "в очередь, сукины дети, в очередь!"
А когда они в очереди, то как их выбирать, в какой последовательности, по какому приоритету, и прочее - вот это и позволяет развести по месту и времени.
Ясный пень, когда идет запрос на update 3/4 содержимого большой таблицы, то легко может оказаться легче и быстрее отдать эту таблицу эксклюзивно этой транзакции, отмолотит и освободит.
Да пустой спор, беспредметный.
Если кому-то мешают юзвери - гнать их нафик!


тоже отличная тема для рубрикатора информационных ресурсов....

Serge Reva
16 июн 06, 12:53    [2779088]     Ответить | Цитировать Сообщить модератору
 Re: Тупиковая ситуация  [new]
Guest new
Guest
Ясен пень блокирует каталог, а то вдруг ты таблицу дропнешь, а я в своём курсоре про это и не узнаю
На одновременные обновления таблицы (insert/update/delete) это никак не повлияет.

Это повлияет не только на (insert/update/delete) но даже на select из другой сессии. Это редкая ситуация как и lock itself из-за UR, но она бывает. То что не все чисто с UR говорит следующая фраза из IBM doc
"UR isolation acquires almost no locks on rows or pages." And one more
"ISOLATION (UR) Allows the application to read while acquiring few locks"
16 июн 06, 19:33    [2781900]     Ответить | Цитировать Сообщить модератору
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить