|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-seИ что же делать с SORTHEAP и остальными автоматическими настройками? Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.? Хороший вопрос... Если это преимущественно транзакционная система, то такой большой SORTHEAP может "скрывать" проблемы приложений. Транзакционые запросы не должны делать большие сортировки. Если при маленьком SORTHEAP вы можете отловить такие запросы по кол-ву переполнений сортировок (SORT_OVERFLOWS), то при большом вы их, скорее всего, не увидите, этих переполнений. И вам придется обнаруживать такие запросы по другим признакам, например, по заметному TOTAL_SECTION_SORT_TIME. Это если вы вообще этим занимаетесь... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2016, 18:32 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-seMark Barinsteinuse-se, Суда по цене запроса план с HSJOIN имеет заметно меньшую цену, когда вы значительно расширили SORTHEAP. Теперь можно попробовать без профиля попробовать (должно выбрать HSJOIN) и время выполнения с HSJOIN. Ну и всё же с intra-parallel тоже надо бы попробовать. Мда, результат есть, ранее лучшее время было 2ч 30м - сейчас 38минут, и таки да, я увидел скорость чтения 100-300 стабильно и в пике 700мб/с. Большое спасибо всем кто помог и учавствовал. И что же делать с SORTHEAP и остальными автоматическими настройками? Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.? Я помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении). Так что или я глючу и всё напутал, или имеет смысл попробовать поменять порядок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Кроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым. MDC, де-факто, это IOT (Index Organized Table), только когда в обычном индексе вы при поиске c1_id получаете строку (или несколько строк с равным c1_id), здесь вы найдёте сразу экстент (или набор экстентов) с равным c1_id, к чему можно применить многоблочное чтение. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2016, 23:08 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Mark Barinsteinuse-seИ что же делать с SORTHEAP и остальными автоматическими настройками? Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.? Хороший вопрос... Если это преимущественно транзакционная система, то такой большой SORTHEAP может "скрывать" проблемы приложений. Транзакционые запросы не должны делать большие сортировки. Если при маленьком SORTHEAP вы можете отловить такие запросы по кол-ву переполнений сортировок (SORT_OVERFLOWS), то при большом вы их, скорее всего, не увидите, этих переполнений. И вам придется обнаруживать такие запросы по другим признакам, например, по заметному TOTAL_SECTION_SORT_TIME. Это если вы вообще этим занимаетесь... Основную массу занимают сравнительно небольшие транзакционные запросы и до недавнего времени я вообще считал, что у меня все работает как надо. Сейчас думаю несколько иначе. В принципе, я понимаю в какую сторону нужно двигаться, буду делать ревизию всего. Victor MetelitsaКроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым. Да Вы правы за мной должок: 1) Тест с MDC по С1 2) Тест с профилем, который Вы предложили в последнем письме 3) Не уверен, что нужен тест с HJ на FlashSystem, но если кого заинтересует то сделаю 4) Думаю все же сделать тест с профилем NL, и индексом на малую таблицу (первый/старый план), и с увеличенным SORTHEAP 5) С включенным INTRA_PARALLEL=YES Только прошу не ожидать от меня быстрых результатов, тесты буду делать в свободное от работы время и по доступности ресурсов. Еще раз всем большое спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2016, 11:37 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor MetelitsaЯ помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении).Да, это так. DB2 build (или inner) сторону (маленькую таблицу) показывает справа, в отличие от Oracle. У DB2 правило - outer таблица join'а - слева, inner - справа. Victor MetelitsaКроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым. MDC, де-факто, это IOT (Index Organized Table), только когда в обычном индексе вы при поиске c1_id получаете строку (или несколько строк с равным c1_id), здесь вы найдёте сразу экстент (или набор экстентов) с равным c1_id, к чему можно применить многоблочное чтение. Статистика по C1_ID большой таблицы: Number of distinct column values: 200 644 459 (из 5 242 341 755) Для MDC очень опасная ситуация - в среднем по 25 значений на один id. Даже с минимальными pagesize = 4 K и extent size = 2 это будет очень большая трата дискового места зря - 8K для 25 коротких записей. Я бы очень не рекомендовал использовать MDC здесь - у поля слишком высокая кардинальность. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2016, 17:17 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Проверил и убедился, что таки сглючил Код: 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.
и поленился просчитать MDC. Правда, у меня тут же возникла мысль делать MDC не по C1_ID, а по выражению вроде C1_ID/1000 (и для верности прибавить h. C1_ID/1000=l. C1_ID/1000 в условие), но, хотя растрату пространства таким способом можно радикально уменьшить, выигрыш в скорости под сомнением. По-видимому, он будет, если диапазон возможных значений C1_ID в маленькой таблице "радикально" меньше диапазона в большой. В таком случае "нужные" строчки сконцентрируются в относительно небольшом количестве экстентов. В целом, сомнительная затея. Ну, а кусок буферного пула под крупноблочность в любом случае должно быть полезно выделить. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2016, 18:33 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Кстати, поскольку речь шла не о простой выборке, а о выборке со вставкой в таблицу, ограничивать могут транзакционные логи и чистка грязного буферного пула. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 09:33 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor MetelitsaКстати, поскольку речь шла не о простой выборке, а о выборке со вставкой в таблицу, ограничивать могут транзакционные логи и чистка грязного буферного пула. Там NOT LOGGED INITIALLY. Относительно MDC, получается что таблица займет примерно 1.6 ТБ? С практичекой точки зрения это не применимо. Поскольку таблицу все равно придется читать полностью, то и скорость выборки не уверен что вырастет. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 12:30 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Ну да, Марк показал, что MDC не годится, а я поленился подсчитать. Но чисткой буферного пула стоит поинтересоваться. Насколько я его понимаю, запись из пула на диск всегда мелкоблочная, то бишь страничная. См. num_iocleaners http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.config.doc/doc/r0000332.html DB2_USE_ALTERNATE_PAGE_CLEANING http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005665.html и т.п. По-хорошему, конечно, следовало бы сперва посмотреть мониторингом на то, во что оно таки упирается. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 14:33 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor MetelitsaНу да, Марк показал, что MDC не годится, а я поленился подсчитать. Но чисткой буферного пула стоит поинтересоваться. Насколько я его понимаю, запись из пула на диск всегда мелкоблочная, то бишь страничная. См. num_iocleaners http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.config.doc/doc/r0000332.html DB2_USE_ALTERNATE_PAGE_CLEANING http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005665.html и т.п. По-хорошему, конечно, следовало бы сперва посмотреть мониторингом на то, во что оно таки упирается. Спасибо за подсказку, но пока не планирую совершать каких либо резких движений. 1) За время обсуждения данной проблемы мои взгляды на текущее состояние БД сильно пошатнулись и мне сейчас гораздо важнее найти другие проблемы, которые сейчас для меня не видны. К примеру, те же планы запросов пересмотреть с увеличенными SORTHEAP и пр. Нужно разобраться с использованием временых TS. 2) БД преймущественно OLTP и рассматриваемый запрос запускается 1 раз в сутки. Сейчас стоит вот так: Код: plaintext 1.
Пока в планах попробовать отказаться от STMM. Кстати, параметр NUM_IOCLEANERS практически всегда держится на ~40 и практически не плавает. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 17:43 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Полезно же понять, что запрос упирается именно во вставку (или не упирается), в том числе в сопутствущую чистку буферов, пусть и не делая никаких "резких движений". ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 18:19 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor MetelitsaПолезно же понять, что запрос упирается именно во вставку (или не упирается), в том числе в сопутствущую чистку буферов, пусть и не делая никаких "резких движений". Вы абсолютно правы. Просто, нужно хотя бы сделать те тесты, что я описал ранее. И вот прошел день, а я даже не начинал, то одно то другое и все вроде важное. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2016, 19:38 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor Metelitsaпропущено... Я помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении). Так что или я глючу и всё напутал, или имеет смысл попробовать поменять порядок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
пропущено.... 2) Вот план запроса, если в профиле поменять местами таблицы (inner,outer) Код: 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. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713.
5) Сделал отдельный bufferpool на 200 000 страниц с numblockpages 50 000 для TS большой таблицы. Включил intra_parallel. Включил monitor switches, сделал выборку. Время выборки уменьшилось с 38 минут до 35. План запроса тут: Код: 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. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775.
Снял снимок Код: 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.
если честно, то я не понял есть ли какие либо ограничения в выборке и в чем они выражаются. Возможно следует смотреть не через snapshot а посредством иных инструментов, подскажите если что... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2016, 15:09 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-se, Сколько времени выполняется теперь запрос ниже, каков его план? SELECT count(h.PAY_STATUS) FROM SH1.BIG_TAB h, SH2.SMALL_TAB l WHERE h.C1_ID = l.C1_ID WITH UR Он должен гораздо быстрее выполняться... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2016, 21:48 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Mark Barinsteinuse-se, Сколько времени выполняется теперь запрос ниже, каков его план? SELECT count(h.PAY_STATUS) FROM SH1.BIG_TAB h, SH2.SMALL_TAB l WHERE h.C1_ID = l.C1_ID WITH UR Он должен гораздо быстрее выполняться... Запрос выполняется 19 минут. Его план тут: Код: 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. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748.
я немного не понял "быстрее" относительно какого запроса, с агрегированием данных, но выполненным ранее? Дело в том, что в базовом запросе данные клиенту тоже не возвращаются, а вставляются в таблицу, выглядит это примерно так: Код: plsql 1. 2.
и тесты я соответственно делаю такие же. Опять же я немного не понимаю суть intra_parallel и как DB2 выбирает эту параллельность. К примеру сейчас, для теста, я разбил TS на 10 контейнеров, раскидал их по разным логическим дискам (правда в пределах одного массива на СХД), 40 CPU (условно), все свободно, но насколько я понял из плана, параллельность = 2. ??? Практически цель вопроса, ускорить выгрузку, достигнута, 35 минут это хороший даже отличный результат, за что Вам и всем кто принимал участие большое спасибо, но есть одна небольшая проблема, теперь поселился червячок сомнения, а вдруг, что то еще не так и возможно производильность может быть и выше ))) Вот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem. Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще? 1) Нужно ли менять эти 2 параметра при переносе БД? 2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД? Вот такие сомнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 12:15 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-se, Можете попробовать: Код: sql 1. 2.
OVERHEAD, TRANSFERRATE: Table space impact on query optimization В плане у вас: Код: plaintext
db2 выделяет для работы N агентов, которые патаются выполнять работу параллельно, передавая результаты своей работы координирующему агенту. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 15:38 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-se, 38 минут однозначно долго. как я понял хеш таблица на диск пишется, т.е. HJ вместо read-ahead по большой таблице читает то временную хеш-таблицу, то большую таблицу. надо добиться, что бы хеш таблица от чтения маленькой таблицы умещалась в память, тогда еще в несколько раз быстрее будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 16:30 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Yo.!use-se, 38 минут однозначно долго. как я понял хеш таблица на диск пишется, т.е. HJ вместо read-ahead по большой таблице читает то временную хеш-таблицу, то большую таблицу. надо добиться, что бы хеш таблица от чтения маленькой таблицы умещалась в память, тогда еще в несколько раз быстрее будет. Не пишется хеш ни маленькой не большой таблицы, иначе была бы заметна запись на диск в темповый TS. Да и из плана видно, что inner(правая) это маленькая таблица. И на снимке я не увидел чтобы как то использовалась временная область. Однако, я подумал, что 38 минут это хорошо, Вы сказали - плохо. ))) Опять есть о чем думать. )) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 16:44 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Mark Barinsteinuse-se, Можете попробовать: Код: sql 1. 2.
OVERHEAD, TRANSFERRATE: Table space impact on query optimization В плане у вас: Код: plaintext
db2 выделяет для работы N агентов, которые патаются выполнять работу параллельно, передавая результаты своей работы координирующему агенту. Пробовал я ранее делать Load, параметры были немного другими. Там другая проблема, я уже писал об, виснет наглухо процесс db2syscs, вот так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Про параметры TS видел, но думал может есть рекомендации конкретно по каждому СХД. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 16:55 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-se, Оттаял процесс, суммарно load длился 1 час 16 м ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2016, 17:31 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-seВот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem. Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще? 1) Нужно ли менять эти 2 параметра при переносе БД? 2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД? Вот здесь (правда для SAP'а) для IBM Flash System рекомендуется : OVERHEAD = 0.3 TRANSFERRATE = 0.1 Для сторвайзов будет зависеть от того на каком конкретно пуле (HDD, SSD, гибридный) будут лежать соответствующие VDISK'и Также для сторвайзов рекомендуется использовать число VDISK'ов кратное 4-ем. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2016, 12:55 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Параметры OVERHEAD и TRANSFERRATE используются для вычисления стоимости. Пример OVERHEAD=12.67 миллисекунд TRANSFERRATE=0.18 миллисекунд на страницу размер страницы 4К размер экстента 4 страницы Тогда в 1 мебайте 256 страниц, при линейном чтении (без overhead) это оценивается, что прочитается примерно за 256*0.18 = 46 миллисекунд, т.е. скорость оценивается 21 мег в секунду. Но если мы прочитаем это постранично случайным доступом, время оценивается как 256*(12.57+0.18)= 3264 миллисекунд (3.264 секунды), в 71 раз медленнее линейного чтения. Но если мы прочитаем это поэкстентно, время оценивается как 64*12.57+256*0.18 = 851 миллисекунда, в 18 раз медленнее линейного чтения. DB2-шные таймероны, в которых указана стоимость, как я понимаю, это и есть расчётные миллисекунды. Эти цифры OVERHEAD=12.67 миллисекунд TRANSFERRATE=0.18 миллисекунд на страницу не мне кажутся адекватными для данного случая. Но я не знаю, как получить параметры, особенно на системах хранения, кроме как воспользовавшись как IOmeter'ом или ORION'ом (а ORION ныне идёт только в комплекте с Oracle Server). Надо ещё прибавить, что чем больше одновременных запросов (из разных процессов или нитей) наваливается на диски, тем OVERHEAD больше (растёт в разы), но оптимизатор про это не знает. Ну, и в статье, которую я недавно читал про оптимизатор (в поисках DB2 LEO), автор заявил, что эти цифры не очень важны, а настоящая проблема в оценке cardinality у предикатов. В самом деле, от этого очень сильно зависит, когда индекс нужен, когда не нужен, когда nested loop join использовать и когда hash join и в каком порядке. Жестокая борьба ведётся (Ораклем!), но результаты ... неоднозначные. Ещё надо иметь в виду ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2016, 00:35 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
use-seMark Barinsteinuse-se, Сколько времени выполняется теперь запрос ниже, каков его план? SELECT count(h.PAY_STATUS) FROM SH1.BIG_TAB h, SH2.SMALL_TAB l WHERE h.C1_ID = l.C1_ID WITH UR Он должен гораздо быстрее выполняться... Запрос выполняется 19 минут. А вставка 30. Напрашивается мысль о сильном влиянии чистки грязного буферного пула. Но нужен мониторинг диска и процессоров, чтобы это подтвердить. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2016, 00:37 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
mitekuse-seВот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem. Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще? 1) Нужно ли менять эти 2 параметра при переносе БД? 2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД? Вот здесь (правда для SAP'а) для IBM Flash System рекомендуется : OVERHEAD = 0.3 TRANSFERRATE = 0.1 Для сторвайзов будет зависеть от того на каком конкретно пуле (HDD, SSD, гибридный) будут лежать соответствующие VDISK'и Также для сторвайзов рекомендуется использовать число VDISK'ов кратное 4-ем. Большое спасибо. Попробую. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2016, 14:29 |
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
---|---|---|---|
#18+
Victor Metelitsause-seпропущено... Запрос выполняется 19 минут. А вставка 30. Напрашивается мысль о сильном влиянии чистки грязного буферного пула. Но нужен мониторинг диска и процессоров, чтобы это подтвердить. Мне кажется, что при использовании агрегатных функци, DB2 несколько иначе обрабатывает строки, возможно я ошибаюсь. Если вместо вставки в таблицу использовать экспорт на диск, то суммарно время выборки незначительно но возрастает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2016, 14:56 |
|
|
start [/forum/topic.php?fid=43&gotonew=1&tid=1600519]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
68ms |
get topic data: |
10ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 187ms |
0 / 0 |