Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaДв, не очень маленькая. 112 мег? согласен, не маленькая, а микроскопическая ... особенно на фоне 384GB сервера, в которые у 112 мег есть хорошие шансы уместиться даже в виде хеша Victor Metelitsa"Разумеется", у DB2 хеш джойн есть. Возможно, настройки не позволили выделить нужное количество памяти. я конечно не высокого мнения о db2, но о наличии хэш джина подозревал :D и тоже голосую за настройки памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:52 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa, Способ, которым маленькая таблица попадёт в память, не так важен, ка кэффективность последующего доступа к ней. При HSJOIN таблица полностью сканируется, причём да, большими блоками. Но делается это только для того, чтобы построить "хэш-индекс". А здесь таблица уже проиндексирована и, скорее всего, и так уже сидит в памяти вся. Насколько более или менее эффективен такой построенный индекс, чем существующий - вопрос стоимости, который оптимизатор должен оценить. Ещё раз: не всегда для соединения "больших" таблиц HJOIN эффективнее NLJOIN или MSJOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 23:12 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
И тогда мы вновь возвращаемся к вопросу в первом письме = почему "суммарная нагрузка на СХД очень мала (примерно 25 -35 MB/s)". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 23:37 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Yo.!Mark BarinsteinПро одноблочное чтение - это откуда взято? В плане - табличное сканирование большой (внешней) таблицы. Метод доступа - sequential prefetch - это чтение экстентами (большими блоками). я так понимаю в плане 2, на каждую запись большой таблицы идет IXSCAN: (Index Scan) с PREFETCH: NONE. сканирование реально один блок читает, т.е. тот самый долбеж. разве нет ?Нет, не правильно. Большая таблица (описание доступа в операторе 3) - слева, маленькая - справа. авторMark BarinsteinКакой здесь смысл здесь таблицу из одного уникального проиндексированного поля засовывать в память, вычислять хэш для каждого уникального поля, чтобы потом по нему получать доступ? не так. в оракле из pk маленькой таблицы построился бы хеш в памяти, потом пошел бы фуллскан большой. по мере чтения большой создавался бы хеш по pk и сравнивался с хеш-таблицой в памяти. если ключ не найдет в баню, если найден, в результирующий курсор нужные поля. таким образом он мог бы хоть петабайты большой таблицы читать и получить результат за адекватное время. думаю с 347 гб таблицы реально минут за 20 справиться по такой схеме.Здесь 2 варианта, в обоих - сканирование большой таблицы. Отличаются они только способом к маленькой таблице. db2 сканирует большую, но не строит хеш-индекс по маленькой, а пользуется существующим индексом по ней. Другой вариант мог бы быть сканированием маленькой, построением хеш-индекса в памяти, доступ к ней по каждой строке из большой не по существующему индексу (который тоже вполне себе может сесть в память и быть не менее эффективным), а по фактически новому (хеш-индексу), построенному в процессе работы. Я бы вот так сразу безапелляционно не сказал, какой способ лучше для пета- или экза- байтов лучше подойдёт. У обоих методов есть плюсы и минусы, и это надо на цену запроса и на время выполнения смотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 23:44 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaИ тогда мы вновь возвращаемся к вопросу в первом письме = почему "суммарная нагрузка на СХД очень мала (примерно 25 -35 MB/s)".Да. Здесь, наверное, можно просто простое сканирование на одну большую таблицу запустить (только с какой-нибудь агрегатной функцией, но чтоб было табличное сканированием плане), чтоб выяснить, на что система способна. Можно и нужно также поэкспериментировать с block-based буфером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 23:52 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Альтернативный вариант получения HSJOIN без профиля - убить индекс на маленькую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 23:56 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinYo.!пропущено... я так понимаю в плане 2, на каждую запись большой таблицы идет IXSCAN: (Index Scan) с PREFETCH: NONE. сканирование реально один блок читает, т.е. тот самый долбеж. разве нет ?Нет, не правильно. Большая таблица (описание доступа в операторе 3) - слева, маленькая - справа. Долбёж может быть по маленькой таблице, а точнее, по индексу маленькой таблицы. Конечно, если он закеширован, то всё должно быть ОК. А закеширован ли он? Я не уверен ни в чём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 09:42 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Добрый день. к сожалению, временно не смогу поводить тесты в том объеме, что ранее. Понимаю, что звучит глупо, но это временно. Буду выкладывать по готовности. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 12:42 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinАльтернативный вариант получения HSJOIN без профиля - убить индекс на маленькую таблицу. Индекс на маленькую таблицу убил и получил новый план, но по прежнему с NL, но маленькая идет первой и в большой ищется по индексу. Профиль не прописывал. Но это только план, сам тест пока запустить не могу. Код: 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. 776. 777. 778. 779. 780. 781. 782. 783. 784. 785. 786. 787. 788. 789. 790. 791. 792. 793. 794. 795. 796. 797. 798. 799. 800. 801. 802. 803. 804. 805. 806. 807. 808. 809. 810. 811. 812. 813. 814. 815. 816. 817. 818. 819. 820. 821. 822. 823. 824. 825. 826. 827. 828. 829. 830. 831. 832. 833. 834. 835. 836. 837. 838. 839. 840. 841. 842. 843. 844. 845. 846. 847. 848. 849. 850. 851. 852. 853. 854. 855. 856. 857. 858. 859. 860. 861. 862. 863. 864. 865. 866. 867. 868. 869. 870. 871. 872. 873. 874. 875. 876. 877. 878. 879. 880. 881. 882. 883. 884. 885. 886. 887. 888. 889. 890. 891. 892. 893. 894. 895. 896. 897. 898. 899. 900. 901. 902. 903. 904. 905. 906. 907. 908. 909. 2) Сделал копию большой таблицы с секционированием на 20 партиций. На тестах скорость чтения немного выше (40МБ/с), но в целом результат хуже. Эталонная выборка 2ч 30 минут, на партиционной почти 3 часа, но возможно какие либо погрешности. 3) Запустил команду вида: Код: plaintext 4) Команда: Код: plaintext Увеличить SORTHEAP без отключения STMM у меня не очень получилось )). Возможно стоит вообще подумать об отключении STMM, но с другой стороны работает уже давно и дает какое то субъективное спокойствие (работает не трогай). Когда снова появятся ресурсы, сделаю остальное: а) Тестовю выгрузку по 1 пункту б) MDC на большую таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 17:13 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se4) Команда: Код: plaintext я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan) добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 18:37 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Yo.!use-se4) Команда: Код: plaintext я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan) добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так. Ок. Спасибо большое. Я понял Вас еще по первому письму и пытаюсь к этому прийти. Да и подсказали уже относительно SORTHEAP. Ресурсы не всегда доступны для тестов и сейчас мне придется подождать. Но у меня к Вам тоже вопрос, почему на разных СХД с разной производительностью (DS5100 & Storwize v7000) одни и те-же времена выборки, а бывает и хуже? Так или иначе все равно приходится сканировать большую таблицу, выходит узкое место не в СХД? Тогда где? Если бы я видел хоть какое либо значительное потребление ресурсов, CPU к примеру, или еще чего. Мне кажется, что в данный момент я не могу даже правильно задать вопрос, наметив направление. Думаю как только будут результаты тестов, включас HS, будет проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 19:28 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seОк. Спасибо большое. Я понял Вас еще по первому письму и пытаюсь к этому прийти. Да и подсказали уже относительно SORTHEAP. Ресурсы не всегда доступны для тестов и сейчас мне придется подождать. Но у меня к Вам тоже вопрос, почему на разных СХД с разной производительностью (DS5100 & Storwize v7000) одни и те-же времена выборки, а бывает и хуже? Так или иначе все равно приходится сканировать большую таблицу, выходит узкое место не в СХД? Тогда где? Если бы я видел хоть какое либо значительное потребление ресурсов, CPU к примеру, или еще чего. Мне кажется, что в данный момент я не могу даже правильно задать вопрос, наметив направление. Думаю как только будут результаты тестов, включас HS, будет проще. не знаю как в db2, а в оракле мы врубаем трейс по которому все видно. с какой скорости читает и что читает. у меня часто такие эффекты были когда insert into select писал в таблицу с констреинтами и одноблочное чтение оказывается вообще долбит третью таблицу из-за foreign key. по трейсу все четко видно, где и что читает, каким способом. ничего не надо гадать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 20:34 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, Создаем таблицу профилей, если еще нету Код: sql 1. 2. 3. 4. 5. 6. 7. optprof.xml Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. optprof.txt"SH1","PROF1","optprof.xml" q1.sql Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. db2 "IMPORT FROM optprof.txt OF DEL MODIFIED BY LOBSINFILE INSERT_UPDATE INTO SYSTOOLS.OPT_PROFILE" db2 "set current optimization profile SH1.PROF1" db2 "flush optimization profile cache SH1.PROF1" db2 -tf q1.sql Покажите план из exfmt.txt ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 20:50 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Yo.!я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan) добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так.Многоблочное чтение маленькой таблицы закончится в самом начале сразу после построения хэш-индекса. Потом при скане большой таблицы вне зависимости от того, какой именно индекс будет использоваться - существующий или хэш - для каждой записи большой таблицы придется обращаться к одной из 5М записей по этому индексу, и тут уже никакого многоблочного обращения быть не может. Даже если всё хозяйство для маленькой таблицы будет в памяти, это далеко не бесплатная операция. Именно поэтому, скорее всего, оно и не может быстрее сканировать большую таблицу - не может быстрее обращаться в маленькую по индексу, каким бы эффективным он ни был. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 20:59 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se3) Запустил команду вида: Код: plaintext 4) Команда: Код: plaintext use-seУвеличить SORTHEAP без отключения STMM у меня не очень получилось )). Возможно стоит вообще подумать об отключении STMM, но с другой стороны работает уже давно и дает какое то субъективное спокойствие (работает не трогай).Трудно помочь с такой диагностикой проблемы - "не получилось". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 22:19 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinМногоблочное чтение маленькой таблицы закончится в самом начале сразу после построения хэш-индекса. Потом при скане большой таблицы вне зависимости от того, какой именно индекс будет использоваться - существующий или хэш - для каждой записи большой таблицы придется обращаться к одной из 5М записей по этому индексу, и тут уже никакого многоблочного обращения быть не может. Даже если всё хозяйство для маленькой таблицы будет в памяти, это далеко не бесплатная операция. Именно поэтому, скорее всего, оно и не может быстрее сканировать большую таблицу - не может быстрее обращаться в маленькую по индексу, каким бы эффективным он ни был. не верю. в оракле бы Yo.!не так. в оракле из pk маленькой таблицы построился бы хеш в памяти, потом пошел бы фуллскан большой. по мере чтения большой создавался бы хеш по pk и сравнивался с хеш-таблицой в памяти. если ключ не найдет в баню, если найден, в результирующий курсор нужные поля. таким образом он мог бы хоть петабайты большой таблицы читать и получить результат за адекватное время. думаю с 347 гб таблицы реально минут за 20 справиться по такой схеме. читать с HDD большую и параллельно сверять с хеш-таблицой в фоне думаю уже десятилетия не проблема. имхо все упирается в ограничения ио ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 23:10 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Хеш-джойн на оракле тем больше выгоден по сравнению с индексом, чем больше строк в таблице, которая стала хеш-таблицей. При условии, что всё влезло в память и хеш-функция адекватна для встретившихся данных (ну, свою в Oracle/DB2 мы всё равно задать не можем). Потому что доступ осуществляется "сразу", без прохода по дереву. Не видно причин, почему на DB2 должно быть по-другому. Смысл работы с хешем в том, чтобы индекс отменить, осуществлять не проход по страницам индекса с бинарным поиском на каждой, а доступ a la x := хештаблица[хешфункция(искомыйключ)], где x - это список найденных значений с одинаковым значением хешфункция(искомыйключ), и при "хорошей" хешфункции его размер "обычно" должен быть 0 или 1. Если поисками в small_tab перегружен процессор, можно подумать о параллельном выполнении сканирования big_tab. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2016, 23:25 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Yo.!читать с HDD большую и параллельно сверять с хеш-таблицой в фоне думаю уже десятилетия не проблема. имхо все упирается в ограничения ио use-se4) Команда: select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 00:01 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaХеш-джойн на оракле тем больше выгоден по сравнению с индексом, чем больше строк в таблице, которая стала хеш-таблицей. При условии, что всё влезло в память и хеш-функция адекватна для встретившихся данных (ну, свою в Oracle/DB2 мы всё равно задать не можем). Потому что доступ осуществляется "сразу", без прохода по дереву. Не видно причин, почему на DB2 должно быть по-другому. Смысл работы с хешем в том, чтобы индекс отменить, осуществлять не проход по страницам индекса с бинарным поиском на каждой, а доступ a la x := хештаблица[хешфункция(искомыйключ)], где x - это список найденных значений с одинаковым значением хешфункция(искомыйключ), и при "хорошей" хешфункции его размер "обычно" должен быть 0 или 1. Если поисками в small_tab перегружен процессор, можно подумать о параллельном выполнении сканирования big_tab.Логически это то же индексирование, только сделанное немного по другому. Поиск одного знчения из миллионов "сразу" не бывает при любом подходе. Заставить оптимизатор "присмотреться" к HS без профиля можно, значительно увеличив SORTHEAP, конечно. Несколько агентов (intra-parallelism) должны, конечно, помочь. Но ТС писал, что это не особо помогает, хотя я бы убедился в том, что в его тестах параллелизм действительно работает (план запроса надо получать из package cache в этом случае). В этом конкретном случае хорошо помогла бы DPF - обе таблицы распределяются по ключу соединения, соединение на каждом разделе локальное. Очень хорошо должно параллелизоваться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 11:07 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinuse-se, Создаем таблицу профилей... ... Покажите план из exfmt.txt В таком варианте план подрос Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 11:45 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, Бессмысленно использовать HSJOIN в этой ситуации, как видно из цены запроса в плане, пока: Код: plaintext Увеличте SORTHEAP до, скажем, 50000 (4K страниц) или даже 100000 и повторите получение плана запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 12:21 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, Вы можете попробовать получить план запроса даже на другом сервере db2 с гораздо меньшими характеристиками, даже на пустых таблицах, но с загруженной статистикой с промышленной системы. Для этого вам надо: - выгрузить DDL для каждой таблицы со статистикой: db2look -d mydb -e -m -z SH1 -t BIG_TAB -o BIG_TAB.ddl db2look -d mydb -e -m -z SH2 -t SMALL_TAB -o SMALL_TAB.ddl - выполнить команды из файлов в тестовой БД - установить характеристики пром. системы на тесте с помощью db2fopt (значения для opt_* взять из шапки плана запроса) Дальше вы можете получать планы запроса на тестовой системе, играться там с опт. профилями, сравнивая цену запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 12:36 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinuse-se, Вы можете попробовать получить план запроса даже на другом сервере db2 с гораздо меньшими характеристиками, даже на пустых таблицах, но с загруженной статистикой с промышленной системы. Для этого вам надо: - выгрузить DDL для каждой таблицы со статистикой: db2look -d mydb -e -m -z SH1 -t BIG_TAB -o BIG_TAB.ddl db2look -d mydb -e -m -z SH2 -t SMALL_TAB -o SMALL_TAB.ddl - выполнить команды из файлов в тестовой БД - установить характеристики пром. системы на тесте с помощью db2fopt (значения для opt_* взять из шапки плана запроса) Дальше вы можете получать планы запроса на тестовой системе, играться там с опт. профилями, сравнивая цену запроса. Болшое спасибо за помощь и за советы. Я к сожалению сам по себе "небыстрая лань", но и в добавок бываю периоды, когда приходится заниматься многоми задачами в параллель. Поэтому прошу простить за задержки. Это план с 100 000 страницами сортировки: Код: 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. Думаю картина без dbm & db параметров все равно будет не полной. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 14:07 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, Сравнение 2-х планов Код: 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. Суда по цене запроса план с HSJOIN имеет заметно меньшую цену, когда вы значительно расширили SORTHEAP. Теперь можно попробовать без профиля попробовать (должно выбрать HSJOIN) и время выполнения с HSJOIN. Ну и всё же с intra-parallel тоже надо бы попробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 14:26 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinuse-se, Суда по цене запроса план с HSJOIN имеет заметно меньшую цену, когда вы значительно расширили SORTHEAP. Теперь можно попробовать без профиля попробовать (должно выбрать HSJOIN) и время выполнения с HSJOIN. Ну и всё же с intra-parallel тоже надо бы попробовать. Мда, результат есть, ранее лучшее время было 2ч 30м - сейчас 38минут, и таки да, я увидел скорость чтения 100-300 стабильно и в пике 700мб/с. Большое спасибо всем кто помог и учавствовал. И что же делать с SORTHEAP и остальными автоматическими настройками? Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2016, 16:56 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=39329411&tid=1600519]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 151ms |

| 0 / 0 |
