|
|
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Всем привет. Столкнулся со странным поведением оптимизатора, хотя может сам где-то туплю. Создадим: Код: 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. Теперь сделаем так: Код: plsql 1. 2. 3. 4. 5. 6. 7. Получим такой план: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Теперь сделаем так(в вывод добавили только одну колонку "B.my_test": Код: plsql 1. 2. 3. 4. 5. 6. 7. получим такой план: Код: 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. Проблема. В первом случае rows-10500(корректно!), во втором 5000. Видно, что во втором случае план конечно меняется и кол-во строк в партиции оракл оценивает некорректно - 500 в одной => сумма тоже некорректна. Если уменьшать период, то кол-во строк в одной партиции оценивается всё хуже. Не могу сообразить какую статистику я не собрал? P.S> FK создал для примера, наверное можно было и без него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 10:00 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Pavel_PVПроблема. В первом случае rows-10500(корректно!), во втором 5000. Видно, что во втором случае план конечно меняется и кол-во строк в партиции оракл оценивает некорректно - 500 в одной => сумма тоже некорректна. Если уменьшать период, то кол-во строк в одной партиции оценивается всё хуже. Не могу сообразить какую статистику я не собрал? Первый план не требует доступа к D_TIME, оценивается количество строк main_t за 10-дневный интервал. Когда добавили в select-list поле из D_TIME - то исключить эту таблицу оптимизатор уже не может и строит план по соединению. Ведущая D_TIME, оттуда ожидается 10 строк. Далее заход NL-ем в MAIN_T на каждый отдельный ключ, найденный в D_TIME оптимизатор ожидает 500 строк из MAIN_T. Это НЕ количество строк в разделе MAIN_T, это количество строк, которое, как полагает оптимизатор, вернет rowsource по ключу за один заход из NL. На счет статистики... Попробуйте поиграть с гранулярностью (статистика может быть как глобальная на уровне таблицы, так и на уровне секции), но не уверен, что это что-либо изменит в указанном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 10:32 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Pavel_PV, в первом запрос за B.day_id не нужно было идти в таблицу поскольку он в inner join provar.D_TIME B on A.DATE_ID=B.day_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 10:34 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
[quot andrey_anonymous]. Далее заход NL-ем в MAIN_T на каждый отдельный ключ, найденный в D_TIME оптимизатор ожидает 500 строк из MAIN_T. Это НЕ количество строк в разделе MAIN_T, это количество строк, которое, как полагает оптимизатор, вернет rowsource по ключу за один заход из NL.[quot] Это я понимаю прекрасно, может написал как-то криво конечно:-" оракл оценивает некорректно - 500 в одной ". Ну дальше понятно 500*10=5000. Вопрос, откуда взялись эти 500? Как оракл получил эту цифру? Ещё до темы я проверил статистику по партициям/таблице/гистограммы и там всё корректно, кол-во написано ровно то которое и должно быть. Не совсем понял причем тут гранулярность, можно подробнее? Если так мысли в слух. Конечно понятно, что виной всему "join" и нежелание оракла глянуть в FK. В первом случае он использует FK и поэтому ошибки нет(благодаря FK получается нужный план), во втором же случае он уже опирается на другую статистику и начинает сильно ошибаться. На таких объемах, а ошибка уже в 2 раза. При этом - всё собрано, гистограммы есть. Я сначала подумал, что не всё знаю про FK и мне сейчас ткнут в доку - вот написано как надо. В общем хочется разобраться, на системе такая ошибка приводит к кривым планам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 10:51 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Подробнее про гранулярность тут: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461 По поводу как получилась оценка... попробуйте посмотреть (explain plan) планчики для запросов: select A.* from provar.MAIN_T A where A.DATE_ID = date'2017-10-20'; -- может использовать гистограмму для оценки селективности select A.* from provar.MAIN_T A where A.DATE_ID = :1 ; -- затруднительно использовать гистограмму Ведомый rowsource в NL похож на запрос с биндом. Что касается рассуждений на тему FK и его использования... проиндексируйте хотя бы свой FK. О вреде неиндексированных FK где только не написано, включая заборы и подзаборья. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 11:07 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Ну и, само собой, наиболее подробный ответ на тему "как оно получилось" можно найти в трассе 10053 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 11:09 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПодробнее про гранулярность тут: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461 По поводу как получилась оценка... попробуйте посмотреть (explain plan) планчики для запросов: select A.* from provar.MAIN_T A where A.DATE_ID = date'2017-10-20'; -- может использовать гистограмму для оценки селективности select A.* from provar.MAIN_T A where A.DATE_ID = :1 ; -- затруднительно использовать гистограмму Ведомый rowsource в NL похож на запрос с биндом. Что касается рассуждений на тему FK и его использования... проиндексируйте хотя бы свой FK. О вреде неиндексированных FK где только не написано, включая заборы и подзаборья. План для первого скорее всего будет использовать статистику по 1 партиции, там всё хорошо будет. Во втором думаю что-то похожее, нужно брать несколько партиций чтобы использовалась общая статистика по таблице. 10053 снять не проблема, но там формулу вроде не пишут. За ссылку спасибо, прочту и попробую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2017, 11:34 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Сразу не отписался. Про гранулярность конечно красиво написано, но не взлетело. Решил сразу сделать с Код: sql 1. Странно это конечно, особенно странно что оракл использует fk как будто не на таблицу целиком, а на поле в ней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2017, 11:30 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Pavel_PV Код: plsql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2017, 10:18 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
Не в этом корень проблемы, проверял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2017, 12:33 |
|
||
|
Какую статистику не собрал? Пляшет estimated rows
|
|||
|---|---|---|---|
|
#18+
проблема видимо в некорректном распределении данных по партициям Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. если данные сгенерировать равномерно Код: plsql 1. 2. то планы начинают выглядеть более адекватно (но дату в запросах нужно другую указывать в таком случае ) Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2017, 13:05 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39547324&tid=1884976]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
| others: | 206ms |
| total: | 356ms |

| 0 / 0 |
