powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ora 00060
25 сообщений из 36, страница 1 из 2
ora 00060
    #39400274
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Периодически получаю ошибку ora 00060 взаимная блокировка при ожидании ресурса.
Никак не могу понять в чем может быть причина. Вставка (при которой и происходит ошибка) происходит в таблицу EVENTS, которая никак не связана с PROCESS_DATA, тем не менее в trace-файле указан запрос с участием этой таблицы.
Подскажите пожалуйста в какую хотя бы примерно сторону мне копать?

DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-0005001e-00202ec5 27 202 X 52 7 X
TX-00090010-002368b5 52 7 X 27 202 S

session 202: DID 0001-001B-00499FAC session 7: DID 0001-0034-00029C60
session 7: DID 0001-0034-00029C60 session 202: DID 0001-001B-00499FAC

Rows waited on:
Session 202: no row
Session 7: obj - rowid = 00015A48 - AAAVpIAAEAAAGJ9AAB
(dictionary objn - 88648, file - 4, block - 25213, slot - 1)

----- Information for the OTHER waiting sessions -----
Session 7:
sid: 7 ser: 53971 audsid: 21378073 user: 90/ADMIN
flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 52 O/S info: user: SYSTEM, term: SERV3, ospid: 11716
image: ORACLE.EXE (SHAD)
client details:
O/S info: user: NT AUTHORITY\SYSTEM, term: SERV3, ospid: 4404:3612
machine: ES\SER3 program: Spv.exe
application name: Spv.exe, hash value=2114354173
current SQL:
UPDATE PROCESS_DATA SET LAST_TEXT = '10:12:22 => ГбвРТЪШ їѕґ°Зё їАѕІѕ»ѕєё : Іє» ' WHERE AREA_ID = 600 AND STATION_CODE = 2

----- End of information for the OTHER waiting sessions -----

Information for THIS session:

----- Current SQL Statement for this session (sql_id=a6ucacxaw10kf) -----
INSERT INTO EVENTS(REPORT_COUNTER, EVENT_COUNTER, EVENT_CODE, EVENT_DATE, EVENT_CLASS, TEXT)VALUES (:B3 , (SELECT NVL(MAX(EVENT_COUNTER),0)+1 FROM EVENTS WHERE REPORT_COUNTER=:B3 ), 0, SYSDATE, 1003, 'ВЮЫйШЭР иЫРЪР: '||TO_CHAR(:B2 )|| ' cЬ. (јРббР иЫРЪР : '||TO_CHAR(:B2 *0.2)||' вЮЭЭ. АРбзХвЭРп ЬРббР ЬХвРЫЫР: '||TO_CHAR(:B1 )||' вЮЭЭ)')
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
object line object
handle number name
343B2D44 183 procedure ADMIN.FREEBOARD
37FB0DA0 165 procedure ADMIN.ZAPROS_DANNYH
237D302C 1 anonymous block
===================================================
...
Рейтинг: 0 / 0
ora 00060
    #39400303
Jonhson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
триггеры, не?
...
Рейтинг: 0 / 0
ora 00060
    #39400359
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jonhsonтриггеры, не?В предположении уникальности, инсерт однозначно неконкурентно-устойчивый, а изменение таблиц может идти в транзакциях поочередно в цикле или просто в разном порядке и не важно из триггера или приложения.
...
Рейтинг: 0 / 0
ora 00060
    #39400379
Jonhson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
всё мб, но я бы начал с триггеров на эти 2 таблички.
...
Рейтинг: 0 / 0
ora 00060
    #39400384
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jonhson,
На таблицах и правда есть триггеры.
На events триггер не делает никаких действий так как сообщение которое вставляю не подходит под условие.
На PROCESS_DATA тоже есть триггер, но он к events никакого отношения не имеет. Вставляет в другую таблицу старое, новое значение строки.
Текст триггеров, к сожалению, предоставить не могу так как уже не на работе.
Спасибо за совет, завтра буду пытаться разобраться
...
Рейтинг: 0 / 0
ora 00060
    #39400385
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-,
Да этот select max+1 явно нехорош, но всё это сделано давно и не мной, тут уже ничего поправить не смогу.
Может быть из-за этого поля ошибка?
...
Рейтинг: 0 / 0
ora 00060
    #39400394
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дану нафиг, не думаю что дело в триггерах.
Где-то в коде делает SELECT ID INTO :ID FROM T1 (без FOR UPDATE), а чуть позже там же делает UPDATE T1 WHERE ID = :ID.
И в конкурентной борьбе система накрывается тазом в этом месте.
...
Рейтинг: 0 / 0
ora 00060
    #39400401
Jonhson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А чего это она должна накрываться тазом, ну в предположении, что id это пк и что его не меняют апдейтом
...
Рейтинг: 0 / 0
ora 00060
    #39400403
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jonhson,

его может и не меняют, а строку-то меняют
...
Рейтинг: 0 / 0
ora 00060
    #39400412
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
--Eugene--,
то есть где-то рядом из PROCESS_DATA station_code выбирают? Почему тогда вставка в другую таблицу обваливается?
...
Рейтинг: 0 / 0
ora 00060
    #39400444
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Zaknafeir,

потомучто скорее всего где-то между SELECT FROM PROCESS_DATA (без FOR UPDATE) и UPADTE PROCESS_DATA есть DML по EVENTS
...
Рейтинг: 0 / 0
ora 00060
    #39400520
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Возможно, PROCESS_DATA ссылается на EVENTS и это поле неиндексировано
...
Рейтинг: 0 / 0
ora 00060
    #39400552
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно воспроизвести с bitmap-ами.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
SQL> create table process_data (
  2    process_date date default sysdate);

Table created.

SQL> create table events (
  2    event_code char(1));

Table created.

SQL> 
SQL> create bitmap index events_code_bi on events(event_code);

Index created.

SQL> 
SQL> insert into process_data values (default);

1 row created.

SQL> commit;

Commit complete.

-- session1
SQL> 
SQL> doc
DOC>  ===== session1 =====
DOC>#
SQL> update process_data
  2   set process_date=default;

1 row updated.

SQL> 
SQL> pause T1 Press return
T1 Press return

-- session2
SQL> doc
DOC>  ===== session2 =====
DOC>#
SQL> insert into events values('x');

1 row created.

SQL> 
SQL> pause T2 Press return
T2 Press return

-- session1
SQL> pause T1 Press return
T1 Press return

SQL> 
SQL> insert into events values('x');

-- session2
SQL> pause T2 Press return
T2 Press return

SQL> 
SQL> update process_data
  2   set process_date=default;

-- session1
SQL> insert into events values('x');
insert into events values('x')
            *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource



Граф.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
DEADLOCK DETECTED ( ORA-00060 )
See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors
[Transaction Deadlock]
 
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-0002000C-000074D3-00000000-00000000         73     131     X             74      42           X
TX-00050017-00007453-00000000-00000000         74      42     X             73     131           S
 
session 131: DID 0001-0049-00000622     session 42: DID 0001-004A-00000337 
session 42: DID 0001-004A-00000337      session 131: DID 0001-0049-00000622 
 
Rows waited on:
  Session 131: no row
  Session 42: obj - rowid = 00035055 - AAA1BVAAGAAAJSmAAA
  (dictionary objn - 217173, file - 6, block - 38054, slot - 0)
 
----- Information for the OTHER waiting sessions -----
Session 42:
  sid: 42 ser: 63710 audsid: 3901823815 user: 666/TC
    flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 74 O/S info: user: oracle, term: UNKNOWN, ospid: 870833
    image: oracle@localhost
  client details:
    O/S info: user: oracle, term: pts/54, ospid: 12332
    machine: localhost program: sqlplus@localhost (TNS V1-V3)
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  update process_data
   set process_date=default
 
----- End of information for the OTHER waiting sessions -----
 
Information for THIS session:
 
----- Current SQL Statement for this session (sql_id=0619xrd492p25) -----
insert into events values('x')



Если RDA DA для ORA-60 натравить на этот трейс-файл, это он и выдаст.
ITL contention определяется по наличию характерных ожиданий.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
ISSUE DETECTED (Most Recent):
Located in section containing "DEADLOCK DETECTED ( ORA-00060 )" in tracefile :
    ora12_ora_870830.trc

Deadlock graph:
                                          ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name                             process session holds waits  process session holds waits
TX-0002000C-000074D3-00000000-00000000         73     131     X             74      42           X
TX-00050017-00007453-00000000-00000000         74      42     X             73     131           S
 
End of Deadlock Graph


ERROR: ORA-00060 Deadlock Graph with >1 Row, at Least 1 Row is "TX X S" 

SOLUTION:
There are 2 primary causes of deadlocks with this signature: bitmap indexes or
ITL contention.
 The 2 types can be identified by whether any of the objects involved in the 
query are bitmap indexes or not.
The "#### Objects That May Be Involved In The Deadlock ####" section in the 
output below can help you to identify whether bitmap indexes are involved in 
the query. 


Bitmap Index Deadlocks: 

If the object ids retrieved from the trace identify a bitmap index then the
likelihood is that the problem is related to this as opposed to ITLs. When 
bitmap indexes are used, multiple rows are covered by the same bitmap index 
fragment. If these rows are locked in different orders then you can encounter
deadlocks. Look at the application to check that the order rows are dealt 
with is consistent. 

If any of the objects are Bitmap Indexes then there is a high likelihood that 
this is a bitmap index issue. 



ZaknafeirПодскажите пожалуйста в какую хотя бы примерно сторону мне копать?
Если нет разработчиков, то достаточно получить DML из задействованных транзакций с последовательностью выполнения, воспроизвести deadlock и подумать, как исправлять. Получить DML - косвенно, по flashback_transaction_query (xid в графе есть), системно через LogMiner.
...
Рейтинг: 0 / 0
ora 00060
    #39400576
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bitmap - индексов на таблицах нет.
На events - REPORT_COUNTER, EVENT_COUNTER (primary key) и REPORT_COUNTER (внешний ключ к другой таблице). На process_data AREA_ID, STATION_CODE (primary key). Все индексы типа normal.

Из process_data select into нигде не делается.
Разве что select count(*) into quant_rec_st from process_data where station_code=cod_station.
Вставка в events происходит в последнюю очередь.
...
Рейтинг: 0 / 0
ora 00060
    #39400583
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeaGate Получить DML - косвенно, по flashback_transaction_query (xid в графе есть), системно через LogMiner.

А что из этого xid?
...
Рейтинг: 0 / 0
ora 00060
    #39400601
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Zaknafeirbitmap - индексов на таблицах нет.

Тогда то, что писали ранее:
-2-В предположении уникальности, инсерт однозначно неконкурентно-устойчивый, а изменение таблиц может идти в транзакциях поочередно в цикле или просто в разном порядке и не важно из триггера или приложения.


Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
SQL> create table process_data (
  2    process_date date default sysdate);

Table created.

SQL> create table events (
  2    event_id char(1) primary key);

Table created.

SQL> 
SQL> insert into process_data values (default);

1 row created.

SQL> commit;

Commit complete.

-- session1
SQL> 
SQL> doc
DOC>  ===== session1 =====
DOC>#
SQL> update process_data
  2   set process_date=default;

1 row updated.

SQL> 
SQL> pause T1 Press return
T1 Press return

-- session2
SQL> doc
DOC>  ===== session2 =====
DOC>#
SQL> insert into events values('x');

1 row created.

SQL> 
SQL> pause T2 Press return
T2 Press return

-- session1
SQL> pause T1 Press return
T1 Press return

SQL> 
SQL> insert into events values('x');

-- session2
SQL> pause T2 Press return
T2 Press return

SQL> 
SQL> update process_data
  2   set process_date=default;

-- session1
SQL> pause T1 Press return
T1 Press return

SQL> 
SQL> insert into events values('x');
insert into events values('x')
            *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource



Граф.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
DEADLOCK DETECTED ( ORA-00060 )
See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors
[Transaction Deadlock]
 
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-00080013-00006E0A-00000000-00000000         78      32     X             80      44           X
TX-00020009-00007533-00000000-00000000         80      44     X             78      32           S
 
session 32: DID 0001-004E-00000178      session 44: DID 0001-0050-00000123 
session 44: DID 0001-0050-00000123      session 32: DID 0001-004E-00000178 
 
Rows waited on:
  Session 32: no row
  Session 44: obj - rowid = 0003505D - AAA1BdAAGAAAJS+AAA
  (dictionary objn - 217181, file - 6, block - 38078, slot - 0)
 
----- Information for the OTHER waiting sessions -----
Session 44:
  sid: 44 ser: 150 audsid: 119456786 user: 666/TC
    flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 80 O/S info: user: oracle, term: UNKNOWN, ospid: 36995
    image: oracle@localhost
  client details:
    O/S info: user: oracle, term: pts/74, ospid: 20920
    machine: localhost program: sqlplus@localhost (TNS V1-V3)
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  update process_data
   set process_date=default
 
----- End of information for the OTHER waiting sessions -----
 
Information for THIS session:
 
----- Current SQL Statement for this session (sql_id=0619xrd492p25) -----
insert into events values('x')



ZaknafeirА что из этого xid?

В случае TX:
Код: plsql
1.
2.
3.
4.
5.
SQL> select id1_tag, id2_tag from v$lock_type where type='TX';

ID1_TAG         ID2_TAG
--------------- --------
usn<<16 | slot  sequence


Соответственно, для TX-0005001e-00202ec5: xid=hextoraw('0005001e00202ec5')
...
Рейтинг: 0 / 0
ora 00060
    #39400636
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeaGate,
Вроде бы данный запрос UPDATE PROCESS_DATA SET LAST_TEXT выполняется только в 1-й сессии (вот этим приложением, которое указано в tracе Spv.exe). Вставка в EVENTS идет из разных сессий.
Если дело всё же в неконкурентно-устойчивом ключе, то как можно поправить процедуры, чтобы уменьшить количество ошибок?

Запрос select * from flashback_transaction_query t where t.xid=hextoraw('0005001e00202ec5') ничего не выдаёт
...
Рейтинг: 0 / 0
ora 00060
    #39400642
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Zaknafeir,

INSERT INTO EVENTS(REPORT_COUNTER, EVENT_COUNTER, EVENT_CODE, EVENT_DATE, EVENT_CLASS, TEXT)VALUES (:B3 , (SELECT NVL(MAX(EVENT_COUNTER),0)+1 FROM EVENTS WHERE REPORT_COUNTER=:B3 ), 0, SYSDATE, 1003, 'ВЮЫйШЭР иЫРЪР: '||TO_CHAR(:B2 )|| ' cЬ. (јРббР иЫРЪР : '||TO_CHAR(:B2 *0.2)||' вЮЭЭ. АРбзХвЭРп ЬРббР ЬХвРЫЫР: '||TO_CHAR(:B1 )||' вЮЭЭ)')

Можно поменять : INSERT INTO EVENTS ... select MAX(EVENT_COUNTER).. from EVENTS WHERE ..
на INSERT INTO EVENTS ... Values( seq_x

c использованием sequence для таблицы EVENTS.
...
Рейтинг: 0 / 0
ora 00060
    #39400652
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fortnet,
Да, я знаю про последовательности, но в эту таблицу вставляют строки все процедуры и проекты именно таким образом(max+1). Менять везде всё на последовательности не очень бы хотелось.
Если использовать sequence только в этом месте проблема разрешится, не породив при этом других?
...
Рейтинг: 0 / 0
ora 00060
    #39400665
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Zaknafeirв эту таблицу вставляют строки все процедуры и проекты именно таким образом(max+1)Говнокод в законе. И ты ещё удивляешься отчего deadlock? Странно, что оно хоть как-то "работает".
...
Рейтинг: 0 / 0
ora 00060
    #39400674
Zaknafeir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Elic,
Понятия не имею кому пришло в голову использовать сиё в качестве ключа. Можно это как-то обслужить теперь или sequence единственный выход?
...
Рейтинг: 0 / 0
ora 00060
    #39400731
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Zaknafeir,
Чем раньше поправите, тем лучше.
И да - править желательно везде, где найдёте.
Этакий лёгкий реинжениринг системы.
...
Рейтинг: 0 / 0
ora 00060
    #39400739
alrx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ZaknafeirМенять везде всё на последовательности не очень бы хотелось.

Можно менять в одном месте - в триггере
...
Рейтинг: 0 / 0
ora 00060
    #39400743
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alrxZaknafeirМенять везде всё на последовательности не очень бы хотелось.

Можно менять в одном месте - в триггере

Нет, :)

Тогда уже везде + еще и в триггере
...
Рейтинг: 0 / 0
ora 00060
    #39400752
Jonhson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если товарищ не разработчик данного кода, а судя по всему админ или внедренец, то с какого перепоя он должен править?

Потом его и обвинят, когда что-то завалится...

имхо заявка разрабам и/или эскалация начальнику.
...
Рейтинг: 0 / 0
25 сообщений из 36, страница 1 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ora 00060
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]