|
|
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
Раза три в день в errorlog появляется deadlock(отличается только параметрами процедур): errorlog00:00000:00140:2008/11/17 11:44:14.61 server Deadlock Id 5 detected Deadlock Id 5: detected. 1 deadlock chain(s) involved. Deadlock Id 5: Process (Familyid 112 112) (suid 842) was executing a INSERT command in the procedure 'recive_act_item_add'. SQL Text: equipment_weight=null,@percent_refuse=null,@weight_refuse=null,@pure_weight_nett=null,@cargo_defect_descrip='НА 6 ПАК. ОБОРВАНО ПО 1 К/Л.',@packet_defect_descrip=null,@revision_descrip=null,@invoice_code=null,@contract='Д0810-191005-003377',@refuse_name=null,@commentary=null,@supply_act_item_code=null,@stack_number=null,@weight_tare=103 Deadlock Id 5: Process (Familyid 140 140) (suid 51) was executing a INSERT command in the procedure 'report_cargo_moves_list'. SQL Text: exec dbo.report_cargo_moves_list @start_date='2008-11-14 07:00',@end_date='2008-11-17 07:00',@object_type=3,@object_code='14',@only_cargo_group=1,@allow_agreement=0,@allow_shipper=0,@allow_consignee=null,@allow_forward=0,@allow_agreement_cargo=null,@reciving_act=1,@supply_acts_rec=1,@supply_acts_trans=1,@discharge_act=1,@expenses_order=1,@cargo_loading_list=1 Deadlock Id 5: Process (Familyid 0, Spid 140) was waiting for a 'shared row' lock on row 4 page 825392 of the 'reciving_acts' table in database 4 but process (Familyid 112, Spid 112) already held a 'exclusive row' 'range' lock on it. Deadlock Id 5: Process (Familyid 0, Spid 112) was waiting for a 'exclusive table' lock on the 'reciving_act_items' table in database 4 but process (Familyid 140, Spid 140) already held a 'shared table' lock on it. Deadlock Id 5: Process (Familyid 0, 112) was chosen as the victim. End of deadlock information. Смущает две вещи: 1 обе таблицы ROL(row only lock), откуда беруться табличные блокировки(exclusive table и shared table)? 2 Если процедуру report_cargo_moves_list запустить самому и посмотреть sp_lock, то некаких sh_table, а только sh_intent. подозревал что эти блокировки просто эскалируются, но нет блокировок мало! в обоих процедурах нет явных блокировок(lock tablt) и повышения уровня изоляции, все работает на уровне изоляции 1. Есть подозрение что что-то делаетсяя на клиенте(ур.изол 2 устанавливает), но программисты клянуться что у них все нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2008, 19:59 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
а и еще, в процедуре(report_cargo_moves_list) где происходит shared table lock кроме нескольких insert into #temp select... , больше ничего нет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2008, 20:12 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
1.блокировки на строки-низший уровень, при необходимости они поднимаются до уровня табтицы (HWM,LWM,PWM). 2.блокировку обновления тоже стожно поймать, но иногда получается.сервер принимает решение о повышении уровня блокировки (см 1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2008, 23:16 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > Автор: "cherrex_Den" > Раза три в день в errorlog появляется deadlock(отличается только > параметрами процедур): > errorlog > 00:00000:00140:2008/11/17 11:44:14.61 server Deadlock Id 5 detected > Deadlock Id 5: detected. 1 deadlock chain(s) involved. > > Deadlock Id 5: Process (Familyid 112 112) (suid 842) was executing a > INSERT command in the procedure \'recive_act_item_add\'. > SQL Text: > equipment_weight=null,@percent_refuse=null,@weight_refuse=null,@pure_weight_nett=null,@cargo_defect_descrip=\'НА > 6 ПАК. ОБОРВАНО ПО 1 > К/Л.\',@packet_defect_descrip=null,@revision_descrip=null,@invoice_code=null,@contract=\'Д0810-191005-003377\',@refuse_name=null,@commentary=null,@supply_act_item_code=null,@stack_number=null,@weight_tare=103 > Deadlock Id 5: Process (Familyid 140 140) (suid 51) was executing a > INSERT command in the procedure \'report_cargo_moves_list\'. > SQL Text: exec dbo.report_cargo_moves_list @start_date=\'2008-11-14 > 07:00\',@end_date=\'2008-11-17 > 07:00\',@object_type=3,@object_code=\'14\',@only_cargo_group=1,@allow_agreement=0,@allow_shipper=0,@allow_consignee=null,@allow_forward=0,@allow_agreement_cargo=null,@reciving_act=1,@supply_acts_rec=1,@supply_acts_trans=1,@discharge_act=1,@expenses_order=1,@cargo_loading_list=1 > Deadlock Id 5: Process (Familyid 0, Spid 140) was waiting for a \'shared > row\' lock on row 4 page 825392 of the \'reciving_acts\' table in database > 4 but process (Familyid 112, Spid 112) already held a \'exclusive row\' > \'range\' lock on it. Тут видно 2 вещи: 1) что работал какой-то запрос в параллель, с worker process. Так обычно работают только плохо оптимизируемые тяжёлые запросы. (хотя могу ошибаться). 2) already held a \'exclusive row range\' lock on it. - это предикативная блокировка ключа, обычно применяется для транзакций на высоком уровне изоляции - повторное чтение и пр. > Смущает две вещи: > 1 обе таблицы ROL(row only lock), откуда беруться табличные > блокировки(exclusive table и shared table)? От эскалации. При эскалации блокировок строчные прыгают на табличные. Кроме того, явными коммандами блокировки таблицы можно заблокировать таблицу. > 2 Если процедуру report_cargo_moves_list запустить самому и посмотреть > sp_lock, то некаких sh_table, а только sh_intent. > подозревал что эти блокировки просто эскалируются, но нет блокировок мало! > в обоих процедурах нет явных блокировок(lock tablt) и повышения уровня > изоляции, все работает на уровне изоляции 1. Есть подозрение что что-то > делаетсяя на клиенте(ур.изол 2 устанавливает), но программисты клянуться > что у них все нормально. Ну, вы ж сами всё знаете ! Нет, думаю всё же эскалация. Её ж по большому счёту избежать невозможно. Ищите. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 00:38 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
а средства промониторить эскалацию есть? Или как-то можно просмотреть все локи которые были у коткретного запроса?(типо dbcc traceon(3604, ...)). а то постоянно вызывать sp_lock не хорошо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 08:58 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > а средства промониторить эскалацию есть? Или как-то можно просмотреть > все локи которые были у коткретного запроса?(типо dbcc traceon(3604, > ...)). а то постоянно вызывать sp_lock не хорошо! sp_lock sp__wholocks Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 10:33 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
еще можно запустить sp_sysmon с секцией locks тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 11:42 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
Попробуйте добиться от программистов кода клиентсой части. По идее примерно должно быть так на клиенте: sqlca.autocommit = true exec report_cargo_moves_list sqlca.autocommit = false ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 14:33 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
вот произошел дидлок как раз когда работал sp_sysmon: Код: 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. и Total Lock Promotions одни нули. значит эскалации небыло? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 14:47 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
да, значит эскалации не было с какими параметрами запускался sysmon ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 15:30 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
komradда, значит эскалации не было с какими параметрами запускался sysmon ? Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 15:51 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
если внимательно посмотреть на текст дедлока, то видно, что процесс 112 хотел получить эксклюзивную блокировку на таблицу reciving_act_items, которую держал 140-ой процесс (shared table) процесс 140 хотел получить shared row lock на запись номер 4 страницы 825392 таблицы reciving_acts, которую держал процесс 112 эксклюзивной блокировкой диапазона ('exclusive row' 'range' lock). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Вопрос: что покажет скрипт ? Код: plaintext 1. я бы на Вашем месте просмотрел код процедур, которые вызвали дедлок, и изыскал возможность единообразного обращения к таблицам... либо напрячь этим программеров PS названия таблиц написаны с ошибками (rec e iving) - может в этом дело? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 16:11 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
komradВопрос: что покажет скрипт ? select lockscheme('reciving_act_items') select lockscheme('reciving_acts') resultdatarows datarows komradя бы на Вашем месте просмотрел код процедур, которые вызвали дедлок, и изыскал возможность единообразного обращения к таблицам... либо напрячь этим программеров по идеи скрипт процедуры не должен влиять на блокировки(ну косвенно по крайней мере). komradPS названия таблиц написаны с ошибками (receiving) - может в этом дело? ;) lingvo говорит что reciving тоже "приемный" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 16:46 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
Процедуры-то не должны, код процедур должен Вы вот что. Раз доказано, что нет эскалации (ну если вы в этом уверены конечно), то получается, что какая-то из этих процедур эксклюзивно блокирует таблицу. Процедур у вас две, обе известны, смотрите их код и ищите, где они блокируют. Или ставят высокий уровень изоляции. И исправляйте -- эксклюзивная блокировка таблицы - это всегда плохо (ну до тех пор, конечно, если она не абсолютно необходима). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 19:11 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
MasterZivПроцедуры-то не должны, код процедур должен Вы вот что. Раз доказано, что нет эскалации (ну если вы в этом уверены конечно), то получается, что какая-то из этих процедур эксклюзивно блокирует таблицу. Процедур у вас две, обе известны, смотрите их код и ищите, где они блокируют. Или ставят высокий уровень изоляции. И исправляйте -- эксклюзивная блокировка таблицы - это всегда плохо (ну до тех пор, конечно, если она не абсолютно необходима). а это не может влиять(установки на таблицу)? какие-то они странные(если не сказать больше) row lock promotion HWM =2147483647(max) row lock promotion LWM =2 row lock promotion PCT =35 в процедуре(которая ждет 'exclusive table) нечего такого нет, ну может вы что-то найдёте? Код: 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. P.S. Процедуру и границы эскалации писал/ставил не я! Так что не судите строга! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 20:16 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
Одним селектом данные из dbo.car_invoice_items никак нельзя было получить? И похоже функция isnull() разработчикам была не знакома. Давайте код второй процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 21:44 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
rcryoОдним селектом данные из dbo.car_invoice_items никак нельзя было получить? И похоже функция isnull() разработчикам была не знакома. Давайте код второй процедуры. Код: 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. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 22:11 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > а это не может влиять(установки на таблицу)? какие-то они странные(если > не сказать больше) > row lock promotion HWM =2147483647(max) > row lock promotion LWM =2 > row lock promotion PCT =35 Так только это и может влиять. И влияет. Но у вас же, вроде бы как выяснилось, нет эскалаций. LWM очень маленький - от двух записей. PCT конечно тоже будет работать, но такой маленький LWM даже смысла нет ставить. HWM =2147483647 наоборот, очень большой. У вас есть столько локов-то ? (number of locks) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 01:55 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: К делу не относится, но за такое : > if @car_invoice_item_code is not null begin > select @cargo_code = (select cargo_code from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @packet_code = (select packet_code from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_place_count = (select place_count from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @weight_gross = (select weight_gross from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @weight_nett = (select weight_nett from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_mark = (select cargo_mark from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_size = (select cargo_size from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > end у нас сразу одно место оторвут. Почему не одним запросом ? В 7 РАЗ ДОЛЬШЕ чем нужно работать будет кусок, и главное, что абсолютно без всякой причины. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 01:59 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > create procedure dbo.recive_act_item_add в этой процедуре ничего криминального нет, но у вас их ДВЕ, вторую смотрели ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 02:01 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: Два замечания : > create procedure dbo.report_cargo_moves_list .... > set forceplan on это очень плохой тон, форсить стазу все запросы (их штук шесть, сложные довольно). Тоже надо настучать. > > create table #cargo_moves_list ( Если эта процедура вызывается во внешней транзакции, то будет заблокирована tempdb.sysobjects до конца этой транзакции. Возможно, это оно и есть. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 02:06 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
да, вотермарки любопытные... и процедуры тоже cherrex_Den, покажи плз sp_configure !только аттачем, а не всей простыней ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 09:30 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
MasterZiv cherrex_Den пишет: Два замечания : > create procedure dbo.report_cargo_moves_list .... > set forceplan on это очень плохой тон, форсить стазу все запросы (их штук шесть, сложные довольно). Тоже надо настучать. процедуре 4 года и возможно, что тогда forceplan был необходим - мы же не знаем подробностей, правда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 09:32 |
|
||
|
Странный deadlock
|
|||
|---|---|---|---|
|
#18+
MasterZiv cherrex_Den пишет: > а это не может влиять(установки на таблицу)? какие-то они странные(если > не сказать больше) > row lock promotion HWM =2147483647(max) > row lock promotion LWM =2 > row lock promotion PCT =35 Так только это и может влиять. И влияет. Но у вас же, вроде бы как выяснилось, нет эскалаций. LWM очень маленький - от двух записей. PCT конечно тоже будет работать, но такой маленький LWM даже смысла нет ставить. HWM =2147483647 наоборот, очень большой. У вас есть столько локов-то ? (number of locks) я подазреваю что это было сделано исходя из следуюшей логики(хотя очень странной): чтоб не заморачиваться с количеством строк в таблице каждый раз, зделали просто, если в таблице залочены 35% процентов строк, тогда делать эскалацию! MasterZivcherrex_Den пишет: К делу не относится, но за такое : > if @car_invoice_item_code is not null begin > select @cargo_code = (select cargo_code from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @packet_code = (select packet_code from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_place_count = (select place_count from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @weight_gross = (select weight_gross from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @weight_nett = (select weight_nett from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_mark = (select cargo_mark from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > select @cargo_size = (select cargo_size from dbo.car_invoice_items where car_invoice_item_id = @car_invoice_item_code) > end у нас сразу одно место оторвут. Почему не одним запросом ? В 7 РАЗ ДОЛЬШЕ чем нужно работать будет кусок, и главное, что абсолютно без всякой причины. это плохо согласен! думаю пора откапывать топор войны и идти к программерам! MasterZivв этой процедуре ничего криминального нет, но у вас их ДВЕ, вторую смотрели ? криминального нет, но 'exclusive table' поставить хочет! MasterZivЕсли эта процедура вызывается во внешней транзакции, то будет заблокирована tempdb.sysobjects до конца этой транзакции. Возможно, это оно и есть. Код: plaintext 1. The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 09:32 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=35658918&tid=2011279]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
26ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 31ms |
| total: | 172ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...