|
|
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Имеется конструкция: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Правильно ли я пониманию, что изменения сделанные в CREATE_STEP2 будут сделаны и закомичены? Код: plsql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 21:04 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
muma1Правильно ли я пониманиюНет. Некомпилируемый код не может производить никаких изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 07:35 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Elicmuma1Правильно ли я пониманиюНет. Некомпилируемый код не может производить никаких изменений. Я не правильно поставил вопрос ? Могу ли я рассматривать "Deadlock detected" как любое другое EXCEPTION ? Буду ли я иметь в таблице msn_tmp2 2 записи со значением 8173, если этот код начнет выполняться одновременно в двух сессиях? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 09:58 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Оберни вставку автономкой. И deadlock не потребуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:21 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Спасибо, это хороший совет, но не ответ. Автономка не спасет от deadlock. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:35 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
muma1Автономка не спасет от deadlock.Заблуждаешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:43 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Автономка это просто еще одна транзакция. И в ней может быть exception. В том числе и deadlock. Почему я заблуждаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 11:52 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
muma1Почему я заблуждаюсь?В транзакции из одного insert-а не может быть deadlock-а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 12:16 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Elicmuma1Почему я заблуждаюсь?В транзакции из одного insert-а не может быть deadlock-а. Верно. но я же спрашивал авторесли этот код начнет выполняться одновременно в двух сессиях? Ничто не мешает двум транзакциям начаться одновременно в разных сессиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 12:35 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
muma1Верно. но я же спрашивал авторесли этот код начнет выполняться одновременно в двух сессиях?Ничто не мешает двум транзакциям начаться одновременно в разных сессиях.А я о том, что нужно делать, чтобы не задаваться вопросом о deadlock-е вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 12:40 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
С чего вообще возникло подозрение на DEADLOCK? Хоть примерно-то понятно когда и из-за чего он возникает? Вставка значений в разных сессиях может привести (и часто приводит) к БЛОКИРОВКЕ (на какое-то время), но к ВЗАИМОБЛОКИРОВКЕ достаточно редко ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 12:57 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровС чего вообще возникло подозрение на DEADLOCK? Никаких подозрений. При хорошей нагрузке реальная ситуация: Deadlock graph: ---------Blocker(s)-------- ---------Waiter(s)--------- Resource Name process session holds waits process session holds waits TX-00020012-008bab5f 132 133 X 115 629 S TX-0005000b-008f0edc 115 629 X 132 133 S session 133: DID 0001-0084-00036BFF session 629: DID 0001-0073-0008BF31 session 629: DID 0001-0073-0008BF31 session 133: DID 0001-0084-00036BFF Rows waited on: Session 133: no row Session 629: no row ----- Information for the OTHER waiting sessions ----- Session 629: current SQL: INSERT INTO MSN_CONTACT (CPT_ID, USR_KEY, CONTACT_NAME) SELECT :B1 , :B2 , NVL(USR_LOGIN, :B3 ) FROM DUAL LEFT JOIN USER_MASTER UM ON UM.USR_ID = :B2 AND :B1 IN (8170, 8320, 8278, 8299) WHERE NOT EXISTS(SELECT * FROM MSN_CONTACT WHERE CONTACT_KEY = :B4 ) ----- End of information for the OTHER waiting sessions ----- Information for THIS session: ----- Current SQL Statement for this session (sql_id=fcxhq8q1kjp9f) ----- INSERT INTO MSN_CONTACT (CPT_ID, USR_KEY, CONTACT_NAME) SELECT :B1 , :B2 , NVL(USR_LOGIN, :B3 ) FROM DUAL LEFT JOIN USER_MASTER UM ON UM.USR_ID = :B2 AND :B1 IN (8170, 8320, 8278, 8299) WHERE NOT EXISTS(SELECT * FROM MSN_CONTACT WHERE CONTACT_KEY = :B4 ) ----- PL/SQL Stack ----- ----- PL/SQL Call Stack ----- object line object handle number name 0xbfef28e60 55 package body VIDEKOMASTER.PACK_MSN 0xc0ddc0340 1 anonymous block =================================================== как вы видете, записей еще нет ни в одной сессии. И да, deadlock получается из-за использования CONTRAINT FOREIGN KEY для USR_ID, ссылающийся на другую таблицу. Но это никак не меняет сути вопроса. но к ВЗАИМОБЛОКИРОВКЕ достаточно редко Верно. Но "редко" - это относительно часто по сравнению с "никогда". Имменно из-за редкого случая мне не хочется всегда делать еще один LOCK(что опять не безопасно) на запись в другой таблице. Тем более, что у меня уже есть в этом месте вероятность DUP_VAL_ON_INDEX. Вот и возникла идея перехватить и deadlock. По существу можно, пожалуйста? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 14:01 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
muma1И да, deadlock получается из-за использования CONTRAINT FOREIGN KEY для USR_ID, ссылающийся на другую таблицу. Но это никак не меняет сути вопроса.Индекс-то есть на внешний ключ? muma1 но к ВЗАИМОБЛОКИРОВКЕ достаточно редко Верно. Но "редко" - это относительно часто по сравнению с "никогда". Имменно из-за редкого случая мне не хочется всегда делать еще один LOCK(что опять не безопасно) на запись в другой таблице. Тем более, что у меня уже есть в этом месте вероятность DUP_VAL_ON_INDEX. Вот и возникла идея перехватить и deadlock. По существу можно, пожалуйста?У тебя в графе ожиданий X и S для TX Это не типично. Либо внешние ключи, либо ITL (что в новых версиях достаточно редко), либо BITMAP индексы Ну и наиболее частая причина -- нарушение порядка. Если уж вставляешь -- вставляй упорядоченно, чтоб не получилось классической ситуации -- один вставляет 5 и 10, а второй 10 и 5 А по-существу что ты хочешь услышать? Ну перехватил ты исключение. Проглотил , только какую-то хрень записал во внутренний буфер. Обработкой это назвать трудно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 14:23 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудровдостаточно редкоЕсли в юник вставлять по две записи на транзакцию в случайном порядке, то редкость уже соизмеряется с количеством вставок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 14:25 |
|
||
|
deadlock handling
|
|||
|---|---|---|---|
|
#18+
Это может часто нарушаться в ad-hoc вставках Но, обычно в процедурах проектируют вполне себе порядок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 14:31 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39396364&tid=1886524]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 228ms |
| total: | 485ms |

| 0 / 0 |
