|
|
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXLВы бы не могли написать подходит ли Вам скорость/загрузка для предложенного мной селекта из 20551953 сообщения не запустился, какой-то группировки не хватает? :( ORA-00937: not a single-group group function ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 11:15 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!для начала я бы просто посмотрел с хинтом /*+ RULE */ , он должен nested loop по индексам врубить Код: sql 1. 2. 3. если хинт RULE даст ожидаемые 10-30 сек, попробовал бы участвующие таблицы ALTER TABLE ... CACHE; в теории это может от фулскана избавить. план запроса с RULE Код: plsql 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. тоже самое без RULE Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. [/SRC] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 11:42 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, какое время с хинтом rule ? без хинта время это после ALTER TABLE ... CACHE ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 11:47 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXLДавно я такой ... не страдал А попробуй вот так: Код: plsql 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. такой запрос отработал за 77 секунд, штатный запрос работает 154 секунды ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 11:48 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!lonely_myp, какое время с хинтом rule ?время выполнения запроса с хинтом такое же как без хинта, 154 секунды. ALTER TABLE ... CACHE не делал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 11:51 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypвремя выполнения запроса с хинтом такое же как без хинта, 154 секунды. ALTER TABLE ... CACHE не делал. если у RULE то же время, то танцы с ALTER TABLE ... CACHE или не имеют смысла. значит надо лезть в логику запросов, избавляться от функций ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 12:03 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypMaximaXXLВы бы не могли написать подходит ли Вам скорость/загрузка для предложенного мной селекта из 20551953 сообщения не запустился, какой-то группировки не хватает? :( ORA-00937: not a single-group group function Попробуй пока так и скажи время: Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 13:06 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, и покажи плиз эти функции 1. straggrd 2. straggrdargs ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 13:10 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Предлагаю поедать осетра по частям. Начав с самого просто ))) GetManHour - проста как 3-и копейки Как я понимаю, народ просто пытается подсчитать сумму по PlanRepairMAP на заданную дату если idobject присутствует в Eam_ShiftrepairMAP с нужным idresponsible. Просто join не сделать, т.к. у них могут быть дубли Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Я бы этот селект написал так (into выкинул): Код: sql 1. 2. 3. 4. 5. 6. 7. или так (правильный вариант зависит от распределения данных по таблицам) Код: sql 1. 2. 3. 4. 5. 6. 7. Чисто эстетически, мне вариант с in нравится больше. Дополнительно воткнул там проверку на b.idplanrepair is not null. Я такого обычно не делаю, воткнул на всякий случай. Соответственно, сюда нужны индексы (колонки из select list тоже включил, для максимум performance): 1) Для первого варианта с in: create index z11 on Eam_ShiftrepairMAP (idresponsible, idplanrepair); create index z12 on EAM_PlanRepairMAP (trunc(dbegin), idobject, nmanhour) 2) Для второго варианта с exists create index z21 on Eam_ShiftrepairMAP (idresponsible, idplanrepair); create index z22 on EAM_PlanRepairMAP (trunc(dbegin), nmanhour); IMHO & AFAIK Надеюсь не ошибаюсь. Смотрим на план и радуемся. Индексы лучше называть пока как нибудь бредово, что бы потом легко в базе было эксперементы найти и удалить. Как автор топика собирается все свои доработки оформлять и документировать, я не знаю ))) подозреваю, кранты базе и саппорту ))) Лично я со стороны разработчика на это бы смотрел крайне настороженно Но это дело автора и его работодателей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 13:33 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
с exists немного ошибся (copy/past), но не принципиально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2017, 13:38 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЯ бы этот селект написал так (into выкинул): Код: sql 1. 2. 3. 4. 5. 6. 7. с ним тестовый запрос прошёл за 78 секунд (штатно 154 с.) Leonid KudryavtsevКак автор топика собирается все свои доработки оформлять и документировать, я не знаю ))) подозреваю, кранты базе и саппорту ))) Лично я со стороны разработчика на это бы смотрел крайне настороженно Но это дело автора и его работодателей. договор саппорта закончился года 3 назад. как иногда бывает, интерес разработчика угас сразу же после подписания договора, доработка оценённая в 3 человекочаса могла тянуться несколько месяцев, включая такие грязные приёмы как "мы вам ещё вчера всё сделали, не знаем почему у вас ничего не изменилось, завтра программист ещё раз перепроверит" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 08:23 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXLlonely_myp, и покажи плиз эти функции 1. straggrd 2. straggrdargs Код: plsql 1. 2. 3. Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 08:37 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypдоговор саппорта закончился года 3 назад. как иногда бывает, интерес разработчика угас сразу же после подписания договора, доработка оценённая в 3 человекочаса могла тянуться несколько месяцев, включая такие грязные приёмы как "мы вам ещё вчера всё сделали, не знаем почему у вас ничего не изменилось, завтра программист ещё раз перепроверит" ну если договора саппорта нет, тогда в общем претензий предъявлять некому другое дело, есть ли исходные коды в собираемом виде lonely_mypс ним тестовый запрос прошёл за 78 секунд (штатно 154 с.) "тестовый запрос" - это который весь огромный? тогда это крайне не плохо, одно узкое место убралось, осталось второе но лучше - в скайпе, правда до сегодняшнего дня я был свободен, а сегодняшя-завтра новая работа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 08:39 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
В GetWorks соответственно аналогично. Ну и планы хорошо бы видеть, исчезли ли hash join'ы и доступ к таблицам А лучше экран с pl/sql developer через skype [spoiler] Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ==> group by & join на in count(*) заменить на count(1) Код: sql 1. 2. 3. 4. 5. 6. 7. [spoiler] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 08:49 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
В GetWorks соответственно аналогично. Ну и планы хорошо бы видеть, исчезли ли hash join'ы и доступ к таблицам А лучше экран с pl/sql developer через skype Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ==> group by & join на in count(*) заменить на count(1) Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 08:53 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXLПопробуй пока так и скажи время: Код: plsql 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. вот именно этот не работает, ORA-00937: not a single-group group function а вот этот вот работает: Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 09:09 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВ GetWorks соответственно аналогично. Ну и планы хорошо бы видеть, исчезли ли hash join'ы и доступ к таблицам А лучше экран с pl/sql developer через skype Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ==> group by & join на in count(*) заменить на count(1) Код: sql 1. 2. 3. 4. 5. 6. 7. ускорилось с 78 секунд до 51 секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 09:32 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Я так понимаю что бяда моя непоправима, тормоза заложены разработчиками в самой базе Здорово конечно что в 3 раза ускорился один запрос, но к моему сожалению там везде так... банальная операция, просто открыть для просмотра перечень оборудования и то занимает 7 секунд. тоесть юзер нажимает кнопку "открыть" и лишь через 7 секунд отображается окно с двадцатью строчками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 09:39 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypЯ так понимаю что бяда моя непоправима, тормоза заложены разработчиками в самой базе Здорово конечно что в 3 раза ускорился один запрос, но к моему сожалению там везде так... банальная операция, просто открыть для просмотра перечень оборудования и то занимает 7 секунд. тоесть юзер нажимает кнопку "открыть" и лишь через 7 секунд отображается окно с двадцатью строчками. да, с таким дизайном системы, функция в функции, запускает функцию, мало чего можно придумать. все у вас упирается в процы. апгрейд процессоров, типа с 2.13Ghz на 3.8Ghz в лучшем случае в двое ускорит, т.е. особо не поможет. если бы упиралось в и/о, можно было бы жонглировать райдами, ssd, кешами ... но тут и/о считай и нет. но я бы прежде чем принимать окончательное решение все таки пригласил бы ораклового спеца, который бы все таки глянул живую систему и подтвердил бы диагноз. у меня все равно ощущение что на столь крошечных табличках, которые в памяти, все должно шустрее шевелиться, но очевидных косяков вроде уже не видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 11:13 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
в смысле даже с таким дизайном, с хинтом RULE, который почти гарантировал nested loops и юлозание по индексам и почти без и/о, не должно имхо 154 секунд занимать. не на столько уж страшные функции и космических вычислений в них вроде там нет. куда девается процессорное время мне до конца не ясно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 11:20 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, ох уж эти самописные агрегаторы ... а можешь проверить вот этот селект будет работать? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. в переменную :idObject поставь EAM_ShiftMAP.idObject который выбирался в диапазоне с 01.05.2017 - 05.05.2017 Я думаю (если все получиться) твой селект можно в 10 сек вогнать без проблемм З.Ы. если работать не будет, сразу попробуй вместо строки Код: plsql 1. написать Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 12:19 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
[quot Yo.!]lonely_mypапгрейд процессоров, типа с 2.13Ghz на 3.8Ghz в лучшем случае в двое ускоритна барахолке взял пару X5650 за 3 тыщи рулей, для эксперимента. время запроса ещё немного упало, до 37 секунд, заодно и пропылесосил. раньше загрузка системы была 25%, теперь загрузка системы 4% :D один единственный процесс оракла скачет по ядрам... неужели оракл никаким образом не умеет многопоточность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 19:06 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
alter table xxx parallel 8; alter system set parallel_max_servers=8; alter system set parallel_servers_target=8; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 19:31 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
девять женщин могутalter table xxx parallel 8; alter system set parallel_max_servers=8; alter system set parallel_servers_target=8; http://www.dba-oracle.com/art_so_oracle_standard_enterprise_edition.htm У автора вроде SE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 20:27 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypнеужели оракл никаким образом не умеет многопоточность?Твой - нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 21:43 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39471260&tid=1885744]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
154ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 471ms |

| 0 / 0 |
