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