|
|
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!...а я теперь не вижу совсем явного криминала. основные индексы видно есть, IDX_EAM_PLANREPAIRM_DTRBEGIN явно FBI индекс с TRUNC БессовкаХотелось бы сказать много и нецензурно, но так как этого делать нельзя- соответствующие термины Вы можете добавить сами ,во время чтения,согласно Вашему воображению Вот зачем там индекс с Trunc ??? В условие where, что написано ??? Так и индекс такой должен быть, как минимум из ДВУХ полей. Два индекса по одному полю, это совсем НЕ ТОЖЕ САМОЕ, что индекс по двум полям. IMHO & AFAIK А вообще, конечно, что бы что-то советовать, нужно видеть систему и иметь доступ к экране и клавиатуре. Хотя бы по скайпу или team viewer'У. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 17:28 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!...не факт. там табличка 1.5 мб, 100% закеширована. обращаться по индексу к такой мелкой может быть просто дороже По опыту из Oracle 8.1.5, даже на крохотных табличках (а не 1.5 mb) с парой полей и парой десятков (меньше сотни) записей, индекс творит чудеса )))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 17:31 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Там HASH JOIN быть не должно. Как факт не должно. Тупые Nested Loop'ы Я бы, даже, раз есть проблема со скоростью, не остановился бы пока даже table access из плана не убрал бы. Таблички маленькие, запросы простые, проблемы со скоростью - все по индексам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 17:34 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevТак и индекс такой должен быть, как минимум из ДВУХ полей. Два индекса по одному полю, это совсем НЕ ТОЖЕ САМОЕ, что индекс по двум полям. я ничего не знаю о системе, может там мульоны таких вот функций, плодить индексы заточенные на две функции из миллиона тоже может быть не лучшее решение. ну и составной индекс по двум полям в лучшем случае лишь слегка ускорит какую-то часть, а тут явно провал в 2-3 порядка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 17:49 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!я ничего не знаю о системе, может там мульоны таких вот функций, плодить индексы заточенные на две функции из миллиона тоже может быть не лучшее решение. Полностью согласен Поэтому я уже третье сообщение заканчиваю словами "нужно видеть систему" Но кроме как плодить индексы под запросы - ничего не остается. Код системы не поменяешь. А пара лишних индексов, может и не есть хорошо, но при размере БД топик стартера, и не так уж плохо. IMHO Yo.!...в лучшем случае лишь слегка ускорит какую-то часть... СЛЕГКА ???? Если привести в разумный вид, а не этот ужас, который сейчас в плане, я думаю в 5-50 раз ускориться "легко" Т.е. если сейчас "вот маленький запрос на 3 минуты" потребляет 25 % CPU, то будет 10-15 секунд при 10% CPU. Как-то так. "Быстро" при таком дизайне системы - не будет. Но судя по приведенным планам, сделать более-менее терпимо - вполне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 18:03 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, Я так понял селекты переписать нельзя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 00:25 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevCREATE INDEX EAM_PlanRepairMAP_z1 ON EAM_PlanRepairMAP ( idobject, trunc(dbegin) ); CREATE INDEX Eam_ShiftrepairMAP_z2 ON Eam_ShiftrepairMAP ( idresponsible, idplanrepair ); снизили время запроса с 3 минут до 2:22 =) третий индекс не создался, CREATE INDEX Eam_Typerepair_z3 ON Eam_Typerepair ON (id); ORA-00906: missing left parenthesis я попробовал CREATE INDEX Eam_Typerepairmap_z3 ON Eam_Typerepairmap (IDOBJECT); но он уже есть ORA-01408: such column list already indexed планы запросов, изменились, у GetManHour стоимость ЦПУ упала вдвое, а у GetWorks ЦПУ стоимость мало изменилась. план GetManHour : ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:35 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
план GetWorks: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:36 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, переписать можно, доступ к конфигурации нам предоставлен, но на данный момент смысла в этом мало, т.к. я у нас самый умный оракловщик. Leonid Kudryavtsev"нужно видеть систему" я над этим думаю, по идее я могу выставить демо версию базы которую присылал разработчик, но там нет такого объёма данных чтобы ощутить адские тормоза и оценить принимаемые меры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:47 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevНо кроме как плодить индексы под запросы - ничего не остается. Код системы не поменяешь.поменять можно, просто некому))) я щас в процессе осознавания как пользоваться планом запроса, конечно это не единственный запрос который можно ускорить. если я разберусь с планами и индексами уже что-то, тогда пробегусь по остальным часто используемым операциям в программе и хотябы слегка её ускорю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:51 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypснизили время запроса с 3 минут до 2:22 =) ну это ожидаемо. range scan по двум индексам в лучшем случае в двое медленее, чем с одного составного, а это лишь часть запроса, который явно можно в 50 раз затюнить. покажи план первого запроса, а не составных функций. там ответы. только найди как в текст этот план вытащить текст. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:52 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp...планы запросов, изменились, у GetManHour стоимость ЦПУ упала вдвое... Это все не то (((, там никакой порнографии с Hash join быть не должно, ну или я что-то не понимаю. Скайп есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 18:02 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!в текст этот план вытащить Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 16:38 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypMaximaXXL, переписать можно, доступ к конфигурации нам предоставлен, но на данный момент смысла в этом мало, т.к. я у нас самый умный оракловщик. Давно я такой ... не страдал А попробуй вот так: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 19:05 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Как Вы братцы круто взялись. Я бы сначала с маленьких, с простых запросов начал ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 19:26 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, Да какая крутость, для каждой строчки запускать 31 запрос (31 проход) да ще и поле транкейтить (а там может быть мульен записей) вместо разброса с и по. Индексы по транкейченому полю как по мне - лишнее. Как по мне, сразу переписать в 1 запрос тут делов на 30 мин. Только бы понять на сколько ускорился/замедлился. Без базы, в оффлайне (вспоминаю институт и програмки на бумажке) ускорять что-то - сущий ад ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 20:13 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
MaximaXXLКак по мне, сразу переписать в 1 запрос тут делов на 30 мин. у меня есть смутное подозрение, что данный запрос авто-генеренный MaximaXXLБез базы, в оффлайне (вспоминаю институт и програмки на бумажке) ускорять что-то - сущий ад аналогичного мнения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 23:29 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, Вот это должно работать ... Код: 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. хотя я и не понимаю что это такое Код: plsql 1. и зачем передавать знак "-" а потом его реплейсить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 09:05 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev данный запрос авто-генеренныйда, собирается на нужное число дней. более общий вид Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 12:59 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Взять и переписать. Система не так уж и плоха, как кажется на первый взгляд. Функции, генерация кода тоже на сторед-процедурах... Т.ч., в принципе, все понятно. Взять и переписать. Те куски, которые работают анормально большое кол-во времени. Малой кровью, ф-ции GetAllManHour, GetAllQty. Делов на пару часов, если иметь доступ хотя бы к экрану компьютера (скайп, TeamViewer). Будет быстрее раз в 5-50 Чуть побольше, подумать и переделать всю эту сборки, как предлагает MaximaXXL. Отказаться от ф-ций и все данные доставать одним запросом (или With...select... ). Это уже посложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 13:24 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_myp, хм ... я уже и забыл как план с UDF выглядит, думал на картинках план обрезан... не думаю что переписывать чужой sql хорошая идея, по хорошему надо докопаться чего сбивает оптимизатор. все таблички выглядят крошечными, может это как-то сбивает его с толку. для начала я бы просто посмотрел с хинтом /*+ RULE */ , он должен nested loop по индексам врубить Код: sql 1. 2. 3. если хинт RULE даст ожидаемые 10-30 сек, попробовал бы участвующие таблицы ALTER TABLE ... CACHE; в теории это может от фулскана избавить. плюс пересобрал бы системную статистику, может у оптимизатора неверные данные о скорости дисков/процессора exec dbms_stats.gather_system_stats(gathering_mode=>'start') ; тут часик нагрузки ... exec dbms_stats.gather_system_stats(gathering_mode=>'stop') ; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 10:27 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!...по хорошему надо докопаться чего сбивает оптимизатор... IMHO бесконечно вложенные один в другой подзапросы что бы добавить hint, я так подозреваю, на SE все равно придется код запроса править У авторов запросов очень не традиционное мышление. Очень изощренный способ с помощью вложенного подзапроса, group by и join изобразить in (select...) IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 14:21 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
lonely_mypLeonid Kudryavtsev данный запрос авто-генеренныйда, собирается на нужное число дней. более общий вид Вы бы не могли написать подходит ли Вам скорость/загрузка для предложенного мной селекта из 20551953 сообщения, сделать его автогенерируемым, не составит большого труда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 19:42 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsevчто бы добавить hint, я так подозреваю, на SE все равно придется код запроса править не, хинт зашивать в код я не предлагаю. хинт чисто посмотреть даст ли nested loop ожидаемые 10-30 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 20:08 |
|
||
|
Низкая загрузка ЦП ораклом. не выше 25% всегда.
|
|||
|---|---|---|---|
|
#18+
Yo.!если хинт RULE даст ожидаемые 10-30 сек Yo.!не, хинт зашивать в код я не предлагаю. хинт чисто посмотреть даст ли nested loop ожидаемые 10-30 секунд. Ну RULE и nested loop как бы вещи достаточно не связанные. Вангую, что при RULE там тоже NL не будет тогда надо ORDERED и USE_NL ==> но тогда как минимум нужно подзапросы местами переставлять ==> тогда уж посмотреть, какой будет план и скорость с нормальными запросами с in и exists ==> тогда уж посмотреть и попытаться понять, что за информация в табличках, что лучше in или exists исходя из логики был бы доступ к экрану или, на худой конец, skype - делов на полчаса (или несколько часов). Но через форум... слишком много надо наводящих вопросов для простейшего запроса из 2-х табличек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2017, 02:40 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39467110&tid=1885744]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 447ms |

| 0 / 0 |
