|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
Добрый вечер. Есть следующий кусок логики. Объявляем курсор: Код: plsql 1. 2. 3. 4. 5. 6. 7.
Потом открываем его и в цикле читаем строчка за строчкой: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
При этом вычитав строчку делаем там всякие проверки и модицикации с данными в переменных, после чего выполняем апдейт строки в той же таблице по которой ходит курсор, а именно той же строки, которую мы этим курсором только что вычитали: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
Все бы хорошо, если бы периодически не происходил как я понимаю дедлок: -244 Could not do a physical-order read to fetch next row Кто-то может объяснить от чего? Если от того что обновляется строка, которую только что считал курсор, то почему дедлок случается лишь иногда с некоторыми строками. А если не от этого, то откуда дедлок? -- ВУЗы Украины ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2013, 23:44 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
MaximFomenko, для обновления строк, которые выбираются в цикле, обычно используется SELECT ... FOR UPDATE OF...., UPDATE ... WHERE CURRENT OF .... Или нужно таки разобраться откуда ноги ростут? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 04:41 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
MaximFomenko-244 Could not do a physical-order read to fetch next row откуда дедлок? Ошибка -244 не обязательно означает deadlock (взаимная блокировка). Надо смотреть сопутствующее ISAM-сообщение. Что бы сделать правильные выводы, для начала нужно глянуть на вывод onstat -u, onstat -g ses в момент появления ошибки. Возможно, что потребуется запустить oncheck на таблицу или индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 08:19 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
victor16MaximFomenko-244 Could not do a physical-order read to fetch next row откуда дедлок? Ошибка -244 не обязательно означает deadlock (взаимная блокировка). Надо смотреть сопутствующее ISAM-сообщение. Что бы сделать правильные выводы, для начала нужно глянуть на вывод onstat -u, onstat -g ses в момент появления ошибки. Возможно, что потребуется запустить oncheck на таблицу или индекс. Сопутствующее ISAM сообщение с кодом -143 - т.е. судя по описанию этого кода - таки дедлок. Выполнение onstat -u, onstat -g ses в момент ошибки затруднено, т.к. дело происходит на базе клиента, который пользует софт. А доступа к их системе у меня нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 12:42 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
АнатоЛойMaximFomenko, для обновления строк, которые выбираются в цикле, обычно используется SELECT ... FOR UPDATE OF...., UPDATE ... WHERE CURRENT OF .... Или нужно таки разобраться откуда ноги ростут? Ага, нашел примеры синтаксиса. Спасибо. Говорите это поможет? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 12:43 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
MaximFomenkoАнатоЛой обычно используется SELECT ... FOR UPDATE OF...., UPDATE ... WHERE CURRENT OF .... ... Говорите это поможет? Можно добавить совет выставить уровень изоляции, возможно с опцией RETAIN UPDATE LOCKS. Подробнее можно посмотреть в блоге SELECT… FOR UPDATE , ну или в документации. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 13:31 |
|
Дедлок при курсоре
|
|||
---|---|---|---|
#18+
если этот процесс может выполняться несколькими пользователями одновременно, то я бы добавил сортировку чтобы обрабатывать строки в одном и том же порядке. SELECT basedep_num, part_code, branch_code, .... order by basedep_num, part_code, branch_code, even_sum, dbtturn_even, crdturn_even; ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2013, 15:09 |
|
|
start [/forum/topic.php?fid=44&msg=38168945&tid=1607072]: |
0ms |
get settings: |
18ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
26ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
163ms |
get tp. blocked users: |
0ms |
others: | 290ms |
total: | 508ms |
0 / 0 |