09.07.2007 14:14
Сидел проверял алертлог и увидел постоянно вываливающиеся ошибки
Цитата:
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/udump/matrixco_ora_1738.trc
глядим в этот трэйс и видим следюющее

Цитата:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /opt/oracle/product/9ir2
System name: Linux
Node name: proliant
Release: 2.6.5-7.244-bigsmp
Version: #1 SMP Mon Dec 12 18:32:25 UTC 2005
Machine: i686
Instance name: matrixco
Redo thread mounted by this instance: 1
Oracle process number: 250
Unix process pid: 1738, image: oracle@proliant (TNS V1-V3)

*** 2007-06-29 11:29:58.273
*** SESSION ID:(239.4871) 2007-06-29 11:29:58.250
DEADLOCK DETECTED ( ORA-00060 )
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL.
The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-0006002b-0005f893 250 239 X 247 235 X
TX-0007000f-00060e91 247 235 X 250 239 X
session 239: DID 0001-00FA-0000000C session 235: DID 0001-00F7-0000001A
session 235: DID 0001-00F7-0000001A session 239: DID 0001-00FA-0000000C
Rows waited on:
Session 235: obj - rowid = 0000542E - AAAFQuAA8AAAzMPAAJ
(dictionary objn - 21550, file - 60, block - 209679, slot - 9)
Session 239: obj - rowid = 0000542E - AAAFQuAA8AAAzMPAAC
(dictionary objn - 21550, file - 60, block - 209679, slot - 2)
Information on the OTHER waiting sessions:
Session 235:
pid=247 serial=12308 audsid=15718490 user: 3315/SUPERMAG
O/S info: user: SYSTEM, term: DUO, ospid: 816:2016, machine: MATRIX-UFA\DUO
program: Sm.Post.Server.exe
application name: Sm.Post.Server.exe, hash value=0
Current SQL Statement:
DELETE FROM SMOBJECTCHANGE WHERE OBJTYPE = 'PT' AND OBJID = :b1
End of information on OTHER waiting sessions.
Current SQL statement for this session:
DELETE FROM SMOBJECTCHANGE WHERE OBJTYPE = 'PT' AND OBJID = :b1
----- PL/SQL Call Stack -----
object line object
handle number name
0x8028b6b0 883 package body SUPERMAG.POST
0x80290340 2 SUPERMAG.SMPOSTPACKAGESCHANGE
0x8023b074 9 procedure SUPERMAG.SMPOSTDONEVP
0x802425c8 1 anonymous block
===================================================
PROCESS STATE
-------------
Process global information:
process: 0x7a530f2c, call: 0x8a79fbec, xact: 0x7f51d3a4, curses: 0x7a5d98b8, usrses: 0x7a5d98b8
Я так понимаю, это проблемы в процедурах обработки очереди почтовых пакетов.
Счастливые пользователи почтового модуля версии 1.025 СП3 подтвердите у всех это или нет.
09.07.2007 21:11
И еще нужно про количество потоков уточнять. Я давно подозревал многопоточную загрузку в нехороших вещах.
10.07.2007 07:44
Количество потоков 2, без 3-го СП очень опасно выставлять количество отличное от 1.
19.11.2012 13:05
Коллеги, что-то меня начинает глодать смутное чувство, подсказывающее, что в 1028.2 что-то поменяли в почтовике и это что-то теперь регулярно дерется с пользователями, вызывая дедлоки даже при одном потоке приема. Посмотрите, пожалуйста в алертлоги, не встречается ли эта ошибка? Настаивать не буду, просто не уверен в чистоте структуры БД там, где это стало часто встречаться со сменой версии.
29.11.2012 08:33
ни у кого нет? или всем влом разбираться? :)
30.11.2012 07:56
Session 235: obj - rowid = 0000542E - AAAFQuAA8AAAzMPAAJ (dictionary objn - 21550, file - 60, block - 209679, slot - 9)
Session 239: obj - rowid = 0000542E - AAAFQuAA8AAAzMPAAC (dictionary objn - 21550, file - 60, block - 209679, slot - 2)

Все дело в параллельности. 2 сессии 239, 235 блокируют друг друга, работая с одним блоком.
У нас такие ошибки иногда возникали при своей параллельной обработки.

Вот по rowid можно узнать что это за документ.
https://olegon.ru/showthread.php?p=128945#post128945
30.11.2012 08:02
это если потоков несколько? что такое дедлок в принципе понятно, интересно, это только ли у меня или нет...
30.11.2012 22:06
во избежание Оффтопа предлогаю эту тему тоже закрыть....
Часовой пояс GMT +3, время: 17:47.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.