|
|
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Периодически получаю ошибку 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 =================================================== ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 16:51 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Jonhsonтриггеры, не?В предположении уникальности, инсерт однозначно неконкурентно-устойчивый, а изменение таблиц может идти в транзакциях поочередно в цикле или просто в разном порядке и не важно из триггера или приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 18:12 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
всё мб, но я бы начал с триггеров на эти 2 таблички. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 18:32 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Jonhson, На таблицах и правда есть триггеры. На events триггер не делает никаких действий так как сообщение которое вставляю не подходит под условие. На PROCESS_DATA тоже есть триггер, но он к events никакого отношения не имеет. Вставляет в другую таблицу старое, новое значение строки. Текст триггеров, к сожалению, предоставить не могу так как уже не на работе. Спасибо за совет, завтра буду пытаться разобраться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 18:40 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
-2-, Да этот select max+1 явно нехорош, но всё это сделано давно и не мной, тут уже ничего поправить не смогу. Может быть из-за этого поля ошибка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 18:42 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Дану нафиг, не думаю что дело в триггерах. Где-то в коде делает SELECT ID INTO :ID FROM T1 (без FOR UPDATE), а чуть позже там же делает UPDATE T1 WHERE ID = :ID. И в конкурентной борьбе система накрывается тазом в этом месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 19:03 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
А чего это она должна накрываться тазом, ну в предположении, что id это пк и что его не меняют апдейтом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 19:11 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Jonhson, его может и не меняют, а строку-то меняют ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 19:17 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
--Eugene--, то есть где-то рядом из PROCESS_DATA station_code выбирают? Почему тогда вставка в другую таблицу обваливается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 19:43 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Zaknafeir, потомучто скорее всего где-то между SELECT FROM PROCESS_DATA (без FOR UPDATE) и UPADTE PROCESS_DATA есть DML по EVENTS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 21:00 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Возможно, PROCESS_DATA ссылается на EVENTS и это поле неиндексировано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 02:32 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Можно воспроизвести с 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. Граф. Код: 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. Если 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. ZaknafeirПодскажите пожалуйста в какую хотя бы примерно сторону мне копать? Если нет разработчиков, то достаточно получить DML из задействованных транзакций с последовательностью выполнения, воспроизвести deadlock и подумать, как исправлять. Получить DML - косвенно, по flashback_transaction_query (xid в графе есть), системно через LogMiner. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 05:39 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
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 происходит в последнюю очередь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 08:40 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
SeaGate Получить DML - косвенно, по flashback_transaction_query (xid в графе есть), системно через LogMiner. А что из этого xid? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 08:48 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
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. Граф. Код: 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. ZaknafeirА что из этого xid? В случае TX: Код: plsql 1. 2. 3. 4. 5. Соответственно, для TX-0005001e-00202ec5: xid=hextoraw('0005001e00202ec5') ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 09:16 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
SeaGate, Вроде бы данный запрос UPDATE PROCESS_DATA SET LAST_TEXT выполняется только в 1-й сессии (вот этим приложением, которое указано в tracе Spv.exe). Вставка в EVENTS идет из разных сессий. Если дело всё же в неконкурентно-устойчивом ключе, то как можно поправить процедуры, чтобы уменьшить количество ошибок? Запрос select * from flashback_transaction_query t where t.xid=hextoraw('0005001e00202ec5') ничего не выдаёт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 09:57 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 10:11 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
fortnet, Да, я знаю про последовательности, но в эту таблицу вставляют строки все процедуры и проекты именно таким образом(max+1). Менять везде всё на последовательности не очень бы хотелось. Если использовать sequence только в этом месте проблема разрешится, не породив при этом других? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 10:25 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Zaknafeirв эту таблицу вставляют строки все процедуры и проекты именно таким образом(max+1)Говнокод в законе. И ты ещё удивляешься отчего deadlock? Странно, что оно хоть как-то "работает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 10:35 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Elic, Понятия не имею кому пришло в голову использовать сиё в качестве ключа. Можно это как-то обслужить теперь или sequence единственный выход? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 10:42 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
Zaknafeir, Чем раньше поправите, тем лучше. И да - править желательно везде, где найдёте. Этакий лёгкий реинжениринг системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 12:02 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
ZaknafeirМенять везде всё на последовательности не очень бы хотелось. Можно менять в одном месте - в триггере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 12:08 |
|
||
|
ora 00060
|
|||
|---|---|---|---|
|
#18+
alrxZaknafeirМенять везде всё на последовательности не очень бы хотелось. Можно менять в одном месте - в триггере Нет, :) Тогда уже везде + еще и в триггере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2017, 12:12 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39400739&tid=1886447]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
189ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
| others: | 237ms |
| total: | 514ms |

| 0 / 0 |
