|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
31.05.2006, 13:18
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Дорогие спецы! помогите разобраться с ситуацией, возникающей при выборке из таблиц и записи. Часто стали появляться сообщение о тупиковой ситуации. Сообщение приложено в файле. Как ее можно обойти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.05.2006, 13:35
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
планировать транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 11:40
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Планировать транзакции? А как это можно сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 13:20
|
|||
|---|---|---|---|
Тупиковая ситуация |
|||
|
#18+
это мил человек и есть суть db2, точка мракобесия, все вот достаточно просто и приемлемо, но механизм блокировок это черпак ... дегтя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 13:42
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
просто старайтесь развести читающие и пишушие транзакции по времени и/или месту. Это можно сделать только зная логику приложения, общие рекомендации - это вряд ли. Опять же, какой процент строк таблицы затрагивается транзакцией, и прочая, и прочая - все в голове надо иметь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.06.2006, 18:57
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Это основная проблема в DB2 - блокировки при чтении. Если логика приложения не пострадает, то можно читать в UR-режиме - dirty reads. Этот режим указывается либо при описании курсора, либо при компияции (но уже для всего модуля). Плюс этого режима в том, что он не блокирует. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.06.2006, 19:17
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Попробуй. db2set DB2SKIPINSERTED=YES db2set DB2SKIPDELETED=YES ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.06.2006, 09:55
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
вообще-то, это не совсем проблема, так как это основной способ достижения высокой производительности. Просто есть плюсы и минусы, минус - в том, что думать надо, как транзакции развести. В дополнение к сказанному Николаем - evaluate_uncommited тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.06.2006, 10:11
|
|||
|---|---|---|---|
Тупиковая ситуация |
|||
|
#18+
ggvпросто старайтесь развести читающие и пишушие транзакции по времени и/или месту. Вот это меня больше всего умиляет. Скажите, вы всегда знаете кто из 100 пользователей, что в данный момент делает? Мы можете спланировать каждое их действие? ИМХО, не надо никого разводить (во всех смыслах), для начала надо стараться, чтобы изменения (update/insert/delete) вносились как можно быстрее, т.е. организовать транзакции таким образом, чтобы эти операции делались сразу перед commit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.06.2006, 10:17
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
про commit и так во всех доках написано. А про юзверей - я ужо говорил как-то, в моем мире юзверей нет. Вот запросы от них приходят, но "в очередь, сукины дети, в очередь!" А когда они в очереди, то как их выбирать, в какой последовательности, по какому приоритету, и прочее - вот это и позволяет развести по месту и времени. Ясный пень, когда идет запрос на update 3/4 содержимого большой таблицы, то легко может оказаться легче и быстрее отдать эту таблицу эксклюзивно этой транзакции, отмолотит и освободит. Да пустой спор, беспредметный. Если кому-то мешают юзвери - гнать их нафик! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.06.2006, 20:30
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Anton DemidovЭто основная проблема в DB2 - блокировки при чтении. Если логика приложения не пострадает, то можно читать в UR-режиме - dirty reads. Этот режим указывается либо при описании курсора, либо при компияции (но уже для всего модуля). Плюс этого режима в том, что он не блокирует. Код: plaintext 1. 2. Разрешите не согласиться с " Плюс этого режима в том, что он не блокирует. " Блокирует и не просто а 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.2006, 22:50
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
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) это никак не повлияет. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.06.2006, 09:32
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Anton DemidovПлюс этого режима в том, что он не блокирует. Даже если вы пишете в таблицу с ur, блокировка измененной записи сохраняется до конца транзакции. Т.е. ur поможет читателю и писателю, но не двум писателям. Так что высказывание все-таки не совсем корректное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.06.2006, 11:47
|
|||
|---|---|---|---|
Тупиковая ситуация |
|||
|
#18+
2 ggv Код: plaintext 1. что за очередь такая, кто ее контролирует, можно поподробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.06.2006, 12:25
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
WebSphere MQ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.06.2006, 12:53
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
ggvпро commit и так во всех доках написано. А про юзверей - я ужо говорил как-то, в моем мире юзверей нет. Вот запросы от них приходят, но "в очередь, сукины дети, в очередь!" А когда они в очереди, то как их выбирать, в какой последовательности, по какому приоритету, и прочее - вот это и позволяет развести по месту и времени. Ясный пень, когда идет запрос на update 3/4 содержимого большой таблицы, то легко может оказаться легче и быстрее отдать эту таблицу эксклюзивно этой транзакции, отмолотит и освободит. Да пустой спор, беспредметный. Если кому-то мешают юзвери - гнать их нафик! тоже отличная тема для рубрикатора информационных ресурсов.... Serge Reva ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.06.2006, 19:33
|
|||
|---|---|---|---|
|
|||
Тупиковая ситуация |
|||
|
#18+
Ясен пень блокирует каталог, а то вдруг ты таблицу дропнешь, а я в своём курсоре про это и не узнаю На одновременные обновления таблицы (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 " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=43&mobile=1&tid=1605282]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
75ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 265ms |
| total: | 429ms |
| 0 / 0 |
