|
|
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
На первом сервере имеется таблица изменений остатков по счетам за последние 20 лет: Код: plsql 1. 2. 3. 4. 5. 6. 7. Есть индекс для определения остатка по счёту на дату: Код: plsql 1. Запрашиваем дату последнего изменения остатка по счёту: Код: plsql 1. Мгновенно выдаётся результат сканированием индекса. План такой: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. На втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам. Один день - одна партиция, в среднем по 100000 строк в день: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Есть локальный индекс для определения остатка по счёту на дату: Код: plsql 1. Запрашиваем дату последнего изменения остатка по счёту: Код: plsql 1. Результат выдаётся только через 1 минуту, т.к. оракл сканирует все партиции и не может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту. Когда где-то в самых последних партициях будет найдена последняя дата изменения остатка по счёту, тогда ораклу стоило бы прекращать дальнейшее сканирование локального индекса. План такой: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Кстати, запрос минимальной даты на втором сервере тоже висит минуту, как и запрос максимальной даты: Код: plsql 1. Статистика на втором сервере собирается обычным dbms_stats.gather_table_stats по партициям со стандартными параметрами. Итак, скан по локальному индексу партиционированной таблицы происходит на несколько порядков медленнее скана по индексу непарциционированной таблицы. Вопрос, как на втором сервере научить оракл сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту? (И когда где-то в самых последних партициях будет найдена последняя дата изменения остатка по счёту, тогда ораклу стоило бы прекращать дальнейшее сканирование локального индекса.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 11:52 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
yon_brover, а что ты хотел, если у тебя ключ секционирования не участвует в условия запроса? партишн прунинг не работает и приходится сканить каждую секцию индекса секционированной таблицы. и тут, как бы тебе не хотелось, но прочитать надцать маленьких индексов выходит медленнее, чем один большой, так как возникает оверхед по лишнему чтению структур индекса каждой его секции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:00 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
yon_broverне может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту.это с какого перепугу и на каких таких "подсказках" от тебя в виде констрейнтов, схемы секционирования и т.д. оракл должен был понять такое? где и чем ты ему гарантируешь, что всё оно будет именно так, как ты сказал, а не как-то по другому? лично я бы тебе на слово не поверил. собственно, оракл поступил также. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:05 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
yon_broverНа втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам. Один день - одна партиция 365*20=7300 секций, у Вас, видимо, какая-то особенная редакция oracle - обычный EE не позволяет больше 1000 создавать (3 года при посуточной нарезке). По сути вопроса - поскольку старые данные не удаляете, то просто замените индекс на глобальный и будет счастье. Из минусов - с очевидностью старые секции объединяются в более крупные, чтобы нарезать новые суточные секции. Эта операция станет дороже за счет необходимости обновлять глобальный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:40 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эхэто с какого перепугу и на каких таких "подсказках" от тебя в виде констрейнтов, схемы секционирования и т.д. оракл должен был понять такое? где и чем ты ему гарантируешь, что всё оно будет именно так, как ты сказал, а не как-то по другому? лично я бы тебе на слово не поверил. собственно, оракл поступил также. Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца. yon_brover... Результат выдаётся только через 1 минуту, т.к. оракл сканирует все партиции и не может сообразить, что партиции надо сканировать в обратном порядке, начиная с последней, и где-то в самых последних партициях и будет вероятнее всего найдена последняя дата изменения остатка по счёту ... Вы по своему плану не определите, все партиции сканировались или не все. И в каком порядке. Всегда в таком случае смотрите Pstart и Pstop и включите пошаговую статистику. Так что приводите версию и полный план с пошаговой статистикой выполнения. Или, если вам лень, просто делаете индекс глобальным, как показали выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:49 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Почему только 1000 ? Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:53 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, авторобычный EE не позволяет больше 1000 создавать это где такое написано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:54 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
AlexFF__|Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца. Но подобная оптимизация была введена с 11.1.0.6, версия ТС пока не озвучена. И я не уверен что она работает в случае доступа по индеху. Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:56 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousyon_broverНа втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам. Один день - одна партиция 365*20=7300 секций, у Вас, видимо, какая-то особенная редакция oracle - обычный EE не позволяет больше 1000 создавать (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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:56 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
K790авторобычный EE не позволяет больше 1000 создавать это где такое написано? Ну вообще в logical database limits, а что? https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:57 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
д0kА что я сделал не так ? Эээ... забыли забыли включить в группировку владельца? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:59 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
AlexFF__| Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца. с куя ли при секционировании по prodate и при запросе вида: select max(prodate) from lim where acc = '014654567 ' and currcode = '000' ; сканирование должно идти с конца секций? в каком месте написано и гарантируется серверу, что строки со значением acc = '014654567 ' and currcode = '000' лежат именно в последней секции, а не в первой, или не где-то в середине, если секции нарезаны по prodate? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 12:59 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousK790пропущено... это где такое написано? Ну вообще в logical database limits, а что? https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm 1024K - 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:00 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Maxim DemenkoAlexFF__|Ну не надо так категорично. Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца. Но подобная оптимизация была введена с 11.1.0.6, версия ТС пока не озвучена. И я не уверен что она работает в случае доступа по индеху. Best regards Maxim Поэтому и спрашиваю версию. А по индексу все-таки должно работать. Можно даже тест сделать. Потом ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:00 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Так там 1024K - 1 Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:00 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousK790пропущено... это где такое написано? Ну вообще в logical database limits, а что? https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm = 1 024 K, насколько я понимаю это к тысячам кило, т.е. миллион как минимум. -1 только не пойму, что это и почему именно -1 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:03 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхAlexFF__| Как раз в данном случае оптимизатор должен был разобраться, что нужно сканировать партиции с конца. с куя ли при секционировании по prodate и при запросе вида: select max(prodate) from lim where acc = '014654567 ' and currcode = '000' ; сканирование должно идти с конца секций? в каком месте написано и гарантируется серверу, что строки со значением acc = '014654567 ' and currcode = '000' лежат именно в последней секции, а не в первой, или не где-то в середине, если секции нарезаны по prodate? Потому что сканируя с конца, можно остановиться, найдя первую запись =) Неужели это в голову не приходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:03 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
K790, хотя есть подозрение, что за минусом первой партиции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:04 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
д0k1024K - 1 Шит. Бывает же. А мы как в анекдоте - до сих пор паровозы под откос пускаем... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:04 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
K790andrey_anonymousпропущено... Ну вообще в logical database limits, а что? https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm = 1 024 K, насколько я понимаю это к тысячам кило, т.е. миллион как минимум. -1 только не пойму, что это и почему именно -1 :) потому, что люди считают начиная с единицы , а компьютеры начиная с нуля... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:04 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousд0kА что я сделал не так ? Эээ... забыли забыли включить в группировку владельца? согласен но всервно больше 1000 Код: plsql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:08 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Быстренько, по структуре ТС: Создаем таблицу с 99 дневными партициями + индекс Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Вставляем в каждую партицию по 10 записей так, чтобы в последней не было таких, что удовлетворяют условию запроса Код: plsql 1. 2. Код: plsql 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:12 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
yon_brover, Покаж план этого запроса (и время выполнения): Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:17 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
AlexFF__|, да, у меня та же картина , походу работает. Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:19 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Maxim Demenkoда, у меня та же картина , походу работает. Но ТС рекомендация прежняя - создать глобальный (можно секционированный по hash от ACC) индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:23 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, С таким количеством партитиций (хотя это еще по божески), я бы начал смотреть в ASH (если доступен), на что время уходит, не исключено, что сам запрос может парсится приличное время, а исполняется довольно быстро. Ну в любом случае, можно было бы определить на что уходит время. Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:28 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Maxim Demenkoне исключено, что сам запрос может парсится приличное время, а исполняется довольно быстро. Запрос к единственной таблице с единственным индексом - и минуту парсится? Что-то сомневаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:35 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:38 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
AlexFF__|, Ещё раз. Мы ищем не просто максимальное значение поля-ключа секционирования во всей таблице. Мы ищем максимум этого поля для строк, удовлетворяющих доп.условию acc = '014654567 ' and currcode = '000' ;по полям, не входящим в ключ секционирования. Лично я даже не могу дать гарантии, что строки лежат в одной секции. Откуда есть уверенность, что они будут именно в последней секции? Может оказаться, что строки со значениями acc = '014654567 ' and currcode = '000'; есть вообще только в первой секции. Какой профит я получу, сканируя секции в обратном порядке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:40 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхКакой профит я получу, сканируя секции в обратном порядке?Что как только они появятся в данной секции, именно там будет максимальная дата. Нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:44 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, При очень большом количестве партиций (в таблице и в индехе) - хотя конечно понятие "очень большое" зависит от конкретной системы - возможны довольно серьезные проблемы с library cache / rowcache, особенно если система довольно нагружена. Best regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:46 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Да, забыл указать версию: Код: plsql 1. Спасибо, Ханч. Вариант Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. отрабатывает мгновенно. План у него такой: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 14:39 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
партицировали-партицировали, да не выпартицировали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 14:45 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эх Какой профит я получу, сканируя секции в обратном порядке? Ну тут все просто - условие останова. Если результат max() найден в секции n, то в секцию n-1 можно не заглячдывать. Правда имеет смысл только для min/max, для других функций, например avg, конечно нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 14:55 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
д0kФухх :).... У меня на локальных индексах все нормально .... Но по праймари ключу - жопа.... Код: 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. индекс по 16 млрд записям сканировался больше часа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 15:05 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
д0kиндекс по 16 млрд записям сканировался больше часа. Parallel не? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 15:33 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousд0kиндекс по 16 млрд записям сканировался больше часа. Parallel не? Не, паралелью я бы уложил пользователей по ВВ. вот интересно , план тот же а резульат кардинально другой ... Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 15:58 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
д0kвот интересно , план тот же Не, не тот же план - см. внимательнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:03 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
М-даа, знакомо, знакомо. Сразу ведь предложили - или глобальный индекс, или dynamic-ом перебирать партиции, генерируя имя на основании искомой даты ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:06 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Если без глобального индекса, то можно сделать некий гибридный вариант: Все это дело обернуть в функцию, которая генерирует и выполняет дайнамик запросы в количестве N штук начиная с последней партиции. Каждый такой запрос будет выполняться милисекунды по локальному индексу. Ну а если за N итераций искомого не нашли - запускать запрос по всем партициям. Но все равно основу механизма вам уже описывали... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:19 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Desert_Nomaddynamic-ом перебирать партиции, генерируя имя на основании искомой даты ;-)krokodaktilгенерирует и выполняет дайнамик запросы в количестве N штук начиная с последней партиции. 19497465 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:24 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Elic 19497465 ИИИИ???? Спасибо за пруф на синтаксис селекта с указание партиции как в явном виде, так и по значению ключа партицирования. Сам знал, но повторить никогда не помешает. :) А теперь можно пруф на то, где в постановке задачи написано, что известно, в какой партиции(или на какую дату) есть значение отвечающее WHERE? Не в каждой партиции есть искомое значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:34 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Elic, спасибо, конечно, за пруф, но тут нет задачи узнать имя партиции. От чего исходим: "На втором сервере имеется такая же таблица-копия изменений остатков по счетам за последние 20 лет, но партиционированная по датам. Один день - одна партиция...". Тут люди хотят организовать поиск с последних партиций принудительно. Решение в лоб - брать предположительные дни, начиная с последнего, и опрашивать соответствующие партиции на предмет нашли/не нашли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:38 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
krokodaktilА теперь можно пруф на то, где в постановке задачи написано, что известно, в какой партиции(или на какую дату) есть значение отвечающее WHERE? Не в каждой партиции есть искомое значение.Это ты у себя спрашиваешь? Я лишь про то, что незачем нетривиально динамить при наличии статического синтаксиса. yon_broverОдин день - одна партиция ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 16:42 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
Ну как, разобрались, что партиции сканируются в нужном порядке как минимум с 10g? Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 18:28 |
|
||
|
Cкан партиционированной таблицы медленнее непарциционированной.
|
|||
|---|---|---|---|
|
#18+
yon_brover, трассу 10053 приложи и экспортни всю статистику по таблице зы. и дропни таблицу PLAN_TABLE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 00:27 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1887276]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 461ms |

| 0 / 0 |
