|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидНу вот скажи мне: где в этой "картинке" может быть побочный эффект ? Ты мне сначала скажи: на какой таблице ты получаешь этот багчек? ТаблоидИ только затем идут уже обмены кортежами между таблицами-"внуками" (см триггер tdx_bud for tdx active before update or delete). И идут они в nowait транзакции, где ошибку нарушения ключей можно получить наткнувшись на ещё несобранный мусор. Стоит очень быстро перекинуть одну запись туда-обратно в параллельных транзакциях и нате вам. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 18:11 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТы мне сначала скажи: на какой таблице ты получаешь этот багчек?Дык я НЕ получаю багчек! и вообще хрен с ним, не до него сейчас :-) Я получаю вот это: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Один раз получил еще и FK violation, ну да ладно, с PK бы сначала разобраться. Dimitry SibiryakovТаблоидИ только затем идут уже обмены кортежами между таблицами-"внуками" (см триггер tdx_bud for tdx active before update or delete).И идут они в nowait транзакции, где ошибку нарушения ключей можно получить наткнувшись на ещё несобранный мусор . Стоит очень быстро перекинуть одну запись туда-обратно в параллельных транзакциях и нате вам.А разве в мусоре нет инфы о том, в какой транзакции была создана эта версия и какое сейчас состояние этой транзакции ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 18:22 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Таблоид Код: plaintext 1.
Таблоид Код: plaintext 1. 2. 3. 4. 5.
Ась ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 18:37 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидА разве в мусоре нет инфы о том, в какой транзакции была создана эта версия и какое сейчас состояние этой транзакции ? Есть. Но ничто не мешает этой транзакции быть ещё активной. Твоя процедура может в одной и той же транзакции переместить одни и те же записи туда и обратно несколько раз. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 18:43 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
hvladАсь ? Индексы получают имена по констрейнам, не наоборот. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 18:54 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
hvladАсь ?А чё ? :-) в ddl таблиц TQ1 & TQ2 нет имён констрейнтов , есть только имена у индексов: Код: plaintext 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:10 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТвоя процедура может в одной и той же транзакции переместить одни и те же записи туда и обратно несколько раз. НЕ может: там отбор по условию, что этот документ еще не обрабатывался в данной транзакции Код: plaintext 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.
Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:13 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидА чё ? :-)А то :) Я тоже не всё помню - вот чё :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:16 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
hvlad, ну так шо, может, глянешь повнимательнее на "артефакты" ? А то я в трейс уже с головой ушёл, лог в 1.4 Гб тут изучаю... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:19 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Таблоидтам отбор по условию В каком месте Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
это условие? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:21 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТаблоидтам отбор по условиюВ каком месте это условие?Это старый скрипт, там этого не было - ты же недавно токнул мну в эту сторону. Вот что я гоняю сейчас и воспроизводимо получаю PK violation через 5-10 минут, при нагрузке 100 окон. Полный DDL : см в нём ХП "p_tmx_hadle_doc", нужное там выделено цветом Код: plaintext 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. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301.
Скрипт, скармливаемый isql'ям: repeat 100500 times Код: plaintext 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.
Ну, и батник тоже повторю сюда: run: tq_run.bat NN, NN = number of ISQLs to be opened Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:41 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидА то я в трейс уже с головой ушёл, лог в 1.4 Гб тут изучаю... Ну, вот я и вернулся. И хочу там/нам/вам всем рассказать одну страшную историю. Вот что записано в таблице-логе для "плохой ошибки" (335544665 = PK/UK violation):SEL_IDUNITHANDLE_MODEFB_GDSCODEATT_IDTRN_IDDTS351821tdx_budtry: ins tq2, del in tq1 , id= 351866 3355446654701727612.08.2014 18:07:57.024351821p_tmx_hadle_docupd in tmx , id= 351821 3355446654701727612.08.2014 18:07:57.084Здесь: 0) 17276 - номер транзакции, которая обломалась; 1) id=351866 - это ПК, который странным образом был "увиден" транзакцией 17276 в таблице tq2; 2) id=351821 - это ID заголовка документа (т.е. master-записи), который должна была предварительно залочить транзакция 17276, прежде чем обрабатывать далее подчинённые строки, и в том числе - делать перекидку кортежей из tq1 в tq2. Слова " должна была " - потому что в ХП p_tmx_hadle_doc делается вот это: Код: sql 1. 2. 3. 4. 5. 6. 7.
- и при невозможности залочить запись управление должно перескочить в when-секцию. А при успехе залочивания код будет продолжен и выполнится вот это: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
А теперь - внимание, уважаемые знатоки. Имеется две транзакции, 16396 и 17276 . И вот что по ним получено при расковыривании трейса (данные упорядочены по графе " Время "):NN п/пНомер транзакцииСобытие трейса Время Результат события или примечание116936START_TRANSACTION18:07:00.3910216936EXECUTE_PROCEDURE_START - Procedure P_TMX_HADLE_DOC18:07:31.1350316936SET_CONTEXT: DEBUG_TRACED_ACTION = "try: ins tq2, del in tq1, id=351866"18:07:31.1450SUCCESS - см ниже строку 6416936EXECUTE_TRIGGER_START - TDX_BUD FOR TDX (BEFORE UPDATE)18:07:31.1450517276START_TRANSACTION18:07:48.7540616936EXECUTE_TRIGGER_FINISH - TDX_BUD FOR TDX (BEFORE UPDATE)18:07:56.459025314 ms, 28 write(s), 73735 fetch(es), 16582 mark(s) 7 16936 EXECUTE_PROCEDURE_FINISH - Procedure P_TMX_HADLE_DOC18:07:56.9660817276EXECUTE_PROCEDURE_START - Procedure P_TMX_HADLE_DOC18:07:56.9950 9 17276 SET_CONTEXT: DEBUG_TRACED_ACTION = "try: ins tq2, del in tq1, id=351866" 18:07:57.0060FAILED - см ниже строку N 111017276EXECUTE_TRIGGER_START - TMX_BUD FOR TMX (BEFORE UPDATE)18:07:57.00601117276FAILED EXECUTE_TRIGGER_FINISH - TDX_BUD FOR TDX (BEFORE UPDATE)18:07:57.04201217276FAILED EXECUTE_PROCEDURE_FINISH - Procedure P_TMX_HADLE_DOC18:07:57.100013335544665 : violation of PRIMARY or UNIQUE KEY constraint "INTEG_112" on table "TQ2", 335545072 : Problematic key value is ("ID" = 351866)18:07:57.1050ATT_4701417276COMMIT_TRANSACTION18:07:57.11501516936COMMIT_TRANSACTION18:07:58.4750 Таким обр., транзакция 17276 всё-таки как-то смогла добраться до кода, обновляющего кортежи таблиц TQ1 & TQ2 - - "внуков" для оглавления документов TMX, и добралась она туда: 1) *после* того, как транзакция 16936 УСПЕШНО завершила процедуру обновления TMX (см строки 7 и 9); 2) *до* того, как транзакция 16936 выполнила свой коммит, т.е. обновлённая запись TMX с id = 351821 еще удерживалась этой (16936-ой) транзакцией. Чтобы точно в этом убедиться, я полез в трейс с поисками записей, в которых видно, как обе эти транзакции проходят точку блокировки заголовка документа с id=351821. И вот что я вижу там для trn = 16936 : Код: plaintext 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.
А вот что в трейсе для trn = 17276 : Код: plaintext 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.
Ну, и как могло случиться такое горе с транзакцией 17276 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 22:25 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидСлова " должна была " - потому что в ХП p_tmx_hadle_doc делается вот это: Код: sql 1. 2. 3. 4. 5. 6. 7.
А ты уверен, что здесь v_rnd_id == sel_id ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 22:37 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
hvladА ты уверен, что здесь v_rnd_id == sel_id ?Они почти в 100% случаев НЕ будут равны. А в чём, собс-но, трабл ? Переменная v_rnd_id ("якорь" для старта поиска) после этого места в ХП уже не используется: SP p_tmx_hadle_doc Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 22:43 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
ТаблоидПеременная v_rnd_id ("якорь" для старта поиска) после этого места в ХП уже не используется:Согласен Но я уже потерялся - то у тебя проблемы с 351821, то с 351866 В общем - 16431065 никуда не делось ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 22:52 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
hvladНо я уже потерялся - то у тебя проблемы с 351821, то с 351866да там всё просто :-) Таблоид1) id=351866 - это ПК, который странным образом был "увиден" транзакцией 17276 в таблице tq2; 2) id=351821 - это ID заголовка документа (т.е. master-записи), который должна была предварительно залочить транзакция 17276, прежде чем обрабатывать далее подчинённые строки, и в том числе - делать перекидку кортежей из tq1 в tq2. hvladВ общем - 16431065 никуда не делосьААААА!!! НЕЕЕЕТТТ!!! Блин, ну поможи разобрацца-то! Всё равно ведь все дороги в твою степь ведут... Ты можешь запустить на своей тачанке 30-40 isql'ей ? Ресурсы её позволят ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 23:00 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Интересно, чем закончилось-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2016, 10:30 |
|
Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Cobalt747, закончилось это перепиской с Главным Источником Света и удивительнейшим открытием, которое расписано тут . ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2016, 15:25 |
|
|
start [/forum/topic.php?fid=40&msg=38718663&tid=1562379]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 273ms |
total: | 424ms |
0 / 0 |