|
|
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Есть таблица записей, условно говоря это строки документов, содержат товар (ID), дату (со временем), ну и ссылку на шапку документа. На таблицу уже есть индексы по дате, продукту, документу. Есть запрос по движению товара, рекомендован индекс по продукту, то есть он через индекс продуктов собирает данные по продукту по всей таблице (500 млн строк), а это может быть и 1000 и 150 тысяч, а потом отбирает их по дате. Причем даже если делаешь отбор за 2 дня все равно выбирает все продукты к примеру 115 тысяч строк, то есть длится запрос может пол часа, а вот если за те же 2 дня отбираешь по дате, то он отбирает 800 тысяч и по ним отбирает уже продукт, но получается это все равно за 4 минуты, видимо потому что эти данные все лежат в одном месте, а не размазаны по нескольким файлам. Ставила в подсказки индекс и по дате тоже (оба), но тогда и за пол года начинает отбирать по дате, и все тушите свет. Напрашивается индекс продукт-дата, делала причем даже делала DESC по дате, индекс получился какой-то очень громоздкий, 16 гб и постоянно висел в памяти почти весь, и был по объему даже больше, чем хранимая в памяти часть таблицы. Не то. Может какие-то хитрости есть? может партиционирование поможет, хотя не могу понять как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 12:27 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845Может какие-то хитрости есть? Нанять специалиста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 12:38 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
mefman, У нас разработчик есть на это дело, но он чего-то ускорять ничего не стремится, и так сойдет. Просто интересно, что тут можно предпринять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 12:45 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
mefmannata44845Может какие-то хитрости есть? Нанять специалиста.который сможет сформулировать тему менее литературно, но более содержательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 12:47 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Давайте кратко: нужен отбор и по дате и по продукту, если используешь индекс по продукту идет по всей таблице от сотворения, а потом отбирает по дате, если используешь индекс по дате даже за 2 дня отбирает офигенный объем данных, а потом из них отбирает нужный продукт, период месяц-полгода по дате дают просто нереальные объемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 12:53 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Если идет отбор и по дате и по номеру документа, то в идеале нужен составной индекс. Для поиска используются значения хранящиеся в индексе. Если индекс содержит только одно поле указанное в условии отбора, то база читает в кэш все значение найденные по этому индексу, т.к. чтобы применить второе условие отбора нужны данные второго поля, а для этого эти данные нужно прочитать. Если у вас номера документов повторяются в разные даты тогда решение только составной индекс (при условии что таблица большая). По хорошему под вопросом оптимизации запроса нужно помещать сам запрос, который оптимизируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 13:43 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845Напрашивается индекс продукт-дата, делала причем даже делала DESC по дате, индекс получился какой-то очень громоздкий, 16 гб и постоянно висел в памяти почти весь, и был по объему даже больше, чем хранимая в памяти часть таблицы. Не то. И что же в написанном не устраивает? если в таблице 3 поля и индекс создается по 2 из ним, почему он должен быть маленьким? он должен быть сравним с размером таблицы. То что объем индекса в кэше больше таблицы, так чего вы хотите, если почти все данные хранятся в индексе? база обращается к таблице только когда требуется id шапки документа, в других случаях нужная информация уже получена из индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 13:49 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845Давайте кратко Если кратко - нужен autotrace, или скрин sql-monitora. Ну и сам запрос конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 13:56 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, Пробовали таблицу партиционировать (напр. по месяцам) по дате + локальный индекс по продукту? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 13:58 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
partition by range, В принципе вариант тоже может помочь, другое дело что согласятся ли переводить таблицу в партицированную, все-таки составной индекс более универсальный вариант. Но если партицирование не проблема то попробуйте оба варианта и выберете в итоге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 14:05 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Ой, вместо цитирования ответить нажал ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 14:07 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, советую хотя бы схематично табличку с полями, плана запроса сюда накидать. иначе 80% заглянувших в топик даже читать не станут ваше литературное описалово проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 14:35 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
если сделать индекс по функции trunc(), он будет поменьше таблицы и скорее всего будет лучше восприниматься оптимизатором, чем индекс по дате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 14:41 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
heroin2если сделать индекс по функции trunc(), он будет поменьше таблицы и скорее всего будет лучше восприниматься оптимизатором, чем индекс по дате.советую прочитать раздел про типы данных и автора темы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 14:52 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
-2-, спасибо! автор вроде бы не пишет что ищет тоже со временем, если ты об этом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 15:15 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
heroin2если ты об этомпроблем задействовать индекс нет:nata44845Ставила в подсказки индекс и по дате тоже (оба), но тогда и за пол года начинает отбирать по дате, и все тушите свет.и с другой стороны. В чем польза от trunc? Продемонстрируй конкретными числами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 15:49 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
heroin2, Во-во, такая мысль меня тоже посещает. Индекс по продукту - дате со временем получается слишком ветвящимся из-за того что по одному продукту может идти 10-50 продаж за одну дату, и в датах на каждом уровне по 1 листу. Индекс только по дате будет иметь больше листьев на уровне, но опять же будет ли он использоваться если запрос вида ДАТА>='01.01.2016 00:00:00' и ДАТА<='01.02.2012 23:59:59' Ведь в индексе дата обрезана, получается для 01.02.2012 придется все равно лезть в таблицу уточнять. Полезет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:03 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
ПС. В таблице не 3 столбца, 3 столбца это рабочие, по которым данные отбираются, а их там еще штук 50, строки длинные... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:06 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Запрос приблизительный SELECT /*+USE_CONCAT ORDERED INDEX(X X_BY_PRODUCT) INDEX(Y Y_PK)*/ X.ID as P54526635,X.DOCUMENT as P54526637 FROM X,Y WHERE ((X.CLASS IN(14286850,14286851)) AND (X.DATE>=TO_DATE('23.08.2016','DD.MM.YYYY')) AND (X.DATE<=TO_DATE('26.08.2016','DD.MM.YYYY')) AND (X.PRODUCT='8C000000000165F8') AND (X.DOCUMENT=Y.ID) AND (X.STATE>0) AND (X.TYPE<>42401878)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:17 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
на индекс положить, если места не хватат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:21 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Taciturn12partition by range, другое дело что согласятся ли переводить таблицу в партицированную Ну да нужно подождать пока там будет 1 млрд записей, потом можно уже) Битмап партиционированные индексы хороший вариант тут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 00:00 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
партицирование по дате упростит таблицу для исходной выборки, потом строить индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 11:14 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Во-первых - форматирование: Код: sql 1. 2. 3. 4. 5. 6. Во-вторых: Код: sql 1. крЫсотища... без хинтов пробовали? ORDERED - #аццскийсотона, IMHO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 11:32 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, зачем таблица Y , если она не используется в select или where? В индексе есть столбец "DATE" до других range столбцов в фильтре? При наличии индекса стоит сравнить IN LIST ITERATOR замен планса с USE_CONCAT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 11:44 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, домино? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 12:02 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. Поправила на первоначальный запрос, там в начале адский кейс по типу документа, без ордеред пробовала, оно тут роли как раз не играет, первый отбор все равно идет по X, а документ там привязывается уже к готовому. По отделу отбор тоже не подойдет, это почти пол базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 13:06 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
pihelnata44845, зачем таблица Y , если она не используется в select или where? В индексе есть столбец "DATE" до других range столбцов в фильтре? При наличии индекса стоит сравнить IN LIST ITERATOR замен планса с USE_CONCAT Код: sql 1. таки используется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 13:23 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, 1. покажите план запроса с предикатами. Используется ли в access доступе для индекса дата DATE? Интересно посмотреть во что развернет +USE_CONCAT такое количество IN, должен быть адский план. 2. покажите статистику на столбцах фильтрации: сколько уникальных значений на каждом. На самых селективных создан ли индекс? Есть ли перекос в данных в этих столбцах, если есть то созданы ли гистограммы (надеюсь bind pickup не отключен) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 15:05 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Так как база не под рукой пока так отвечу, индексы для каждого столбца свой, так как там стоит рекомендованный индекс по продукту, то он и используется. Индекс по дате более менее равномерный, а вот по продукту... Есть некоторые продукты по которым продано порядка 2000 товаров, там вжик и все, очень удобно, а есть просто гиганты. Сегодня наблюдала как тетка делает отчет по бананам за 3 дня, так как задействован индекс продукт, она полтора часа сидела ждала, по индексу продукт выбралось 450 тысяч записей по всей базе, потом ей надоело. А есть еще кофе 3в1 почти 2 миллиона записей за весь период. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:05 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, нужно чтобы фильтр по дате был до других сканирований по диапазону (STATE, TYPE), т.е. чтобы по продукту и дате был access (не filter ! ) nata44845Есть некоторые продукты по которым продано порядка 2000 товаров, там вжик и все, очень удобно, а есть просто гиганты. Т.е. написанные вами хинты в этом случае только мешают. Если нужно отобрать большой кусок, то тут делать hash join + parallel + хорошо бы побить фактовую таблицу на секции, чтобы было меньше сканировать, т.к. не будет индекса и будет full table scan. Желательно всего этого добиться без хинтов, чтобы оракл сам понимал когда нужен NL по 2000 товаров, а когда hash join по 450т записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:12 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
pihel, На маленьких периодах получается нормально, а вот если период за месяц, то будет выбрано нааамного больше строк чем пара миллионов. Индекс к слову тут не мой, я на запрос даже влиять не могу, только план закрепить. Или поискать решение и попросить разработчика переделать. Без подсказки запрос скатывается в индекс по дате, что тоже не есть хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:27 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, INDEX RANGE SCAN - 458К (access по индексу) TABLE ACCESS BY INDEX ROWID - 998 строк (дофильтрация индекса filter). Сделайте индекс чтобы после access было минимум строк. Такого рода запрос будет нормально работать с NL. По статистике не видно какие предикаты были у запроса, странно что нет вкладки "plan". Именно там можно увидеть какие столбцы были acces по индексу, а какие filter ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:37 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
pihel, Про то что нужен индекс и по дате и по индексу я и так поняла, но тот который я делала по продукту и дате получился тяжелым и ветвистым. Сегодня на маленькой тестовой делала индекс по product, trunc(date) desc А потом еще делала по ASC Ставила его в рекомендованные в тестовом запросе, индекс уходил в FULL SCAN. В понедельник еще базу с партиционированной таблицей там подниму. А вообще всем приятных выходных, до понедельника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:39 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
тьфу блин, по продукту, заговорилась ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 16:41 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845Сегодня на маленькой тестовой делала индекс по product, trunc(date) desc А потом еще делала по ASC Ставила его в рекомендованные в тестовом запросе, индекс уходил в FULL SCAN. вот скажите, у вас в запросе фигурирует просто дата в диапазоне, так на уя в индексе trunc лепить, кто вам эту ерунду насоветовал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2016, 09:30 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
опс... , это был вредный совет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2016, 09:38 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1. денормализация с добавлением class и department в x 2. create index index_name on x (product, date, class, department, state, type, price .... (ну и все поля, участвующие в селекте :)) 3. пишем запрос только к x: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 4. по возможности избавиться от DEPARTMENT IN (например, добавлением отдельного признака/справочника типа группы отделов) 5. ну и с патишенами было бы удобнее наверно ж ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2016, 12:51 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Avotge, что толку от денормализации? а индекс по всем полям это вообще жесть, нужно будет попробовать. у автора проблема в том что запрос при разных условиях должен идти по разным планам(не важно 1 там таблица или 10) при том что все выполняется по связываемым переменным и план в общем-то один. его можно тюнить подсказками, но все равно в другом случае опять будет неоптимально. кстати есть cursor_sharing_exact, но это тоже изврат. нужно партицировать таблицу и тогда даже при неоптимальных планах будет нормальное время выполнения, т.к. запрос будет затрагивать только часть этой большой таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2016, 14:23 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
heroin2что толку от денормализации? а индекс по всем полям это вообще жесть, нужно будет попробовать. у автора проблема в том что запрос при разных условиях должен идти по разным планам(не важно 1 там таблица или 10) при том что все выполняется по связываемым переменным и план в общем-то один. его можно тюнить подсказками, но все равно в другом случае опять будет неоптимально. кстати есть cursor_sharing_exact, но это тоже изврат. нужно партицировать таблицу и тогда даже при неоптимальных планах будет нормальное время выполнения, т.к. запрос будет затрагивать только часть этой большой таблицы. 1. По денормализации. По-мне так, если мы имеем таблицу с сотнями млн записей, из которых надо быстро доставать пару млн или сотни тыс. записей, то лазить для этого в другую таблицу (особенно по индекс рейндж скан с последующим обращением к данным связываемой таблицы), то (если полей из другой таблицы надо достать одно-два) лучше их протащить в основную таблицу (основную для запроса). 2. По индексу по всем полям. Как бы очевидно, что запрос будет работать быстрее, если все поля запроса уже будут в индексе, особенно если идет большой разброс самих данных по диску. При этом речь не идет о том, чтобы засунуть все поля таблицы, а именно те, которые используются в запросе. Такая практика вроде тоже имеет место быть ) 3. По проблеме автора. В проблему не вникал :) Просто мысли по представленному запросу ) Насчет того, что запрос должен идти по разным планам в зависимости от параметров, наск. понимаю, зависит от статистики, но имхо, если выполнить п.1 и п.2 с большой вероятностью итак будет нормуль ) (в крайнем построить еще необх. индекс(ы), а там пусть выбирает )) 4. По патиционированию. Не факт, что поможет в плане скорости: - смотря как патиционировать - основное время тратиться ж на чтения с диска, при этом: - сначала читается индекс одной таблицы + данные - плюс читается индекс другой таблицы + данные Если же выполнить п.1. и п.2 будет читаться один индекс и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2016, 15:19 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845Есть таблица записей, условно говоря это строки документов, содержат товар (ID), дату (со временем), ну и ссылку на шапку документа. На таблицу уже есть индексы по дате, продукту, документу. Есть запрос по движению товара, рекомендован индекс по продукту, то есть он через индекс продуктов собирает данные по продукту по всей таблице (500 млн строк), а это может быть и 1000 и 150 тысяч, а потом отбирает их по дате. Причем даже если делаешь отбор за 2 дня все равно выбирает все продукты к примеру 115 тысяч строк, то есть длится запрос может пол часа, а вот если за те же 2 дня отбираешь по дате, то он отбирает 800 тысяч и по ним отбирает уже продукт, но получается это все равно за 4 минуты, видимо потому что эти данные все лежат в одном месте, а не размазаны по нескольким файлам. Ставила в подсказки индекс и по дате тоже (оба), но тогда и за пол года начинает отбирать по дате, и все тушите свет. Напрашивается индекс продукт-дата, делала причем даже делала DESC по дате, индекс получился какой-то очень громоздкий, 16 гб и постоянно висел в памяти почти весь, и был по объему даже больше, чем хранимая в памяти часть таблицы. Не то. Может какие-то хитрости есть? может партиционирование поможет, хотя не могу понять как. Тут задача и админам, и программистам. 500 млн строк - на таком объёме уже давно пора использовать партиционирование. Партиционирование прежде всего по месяцу, вторые партиции - по конкретной дате. Можно вообще разбить на помесячные таблицы и сделать в них партиционирование подневно. А для общих запросов использовать вьюху с таким же названием, как сейчас у этой таблицы. Только надо будет обновлять вьюху каждый месяц и каждый месяц создавать новую месячуню таблицу с подневным партиционированием. Это всё можно сделать при помощи Job-ов. Так точно будет работать очень быстро. Ещё вот это прочитай - для новичков хорошо написано Также, если позволяет железо - можно запускать один запрос в несколько потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2016, 11:53 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Тестировала запрос на партиционированной и не партиционированной небольших базах, подняла две одинаковых схемы, в одной таблицы партиционировала, и опять подняла. При индексе только по продукту количество чтений с диска 5000 партиционированная против 25000 не партиционированная. При индексе по продукту и дате стоимость практически не отличается во всех видах индексов (product+date,date desc,trunc(date),trunc(date) desc), 3300-3800. Потом решила вынести эти таблицы в отдельные табличные пространства, а в партиционированной каждую партицию. Пока это делала залезла в табличное пространство в главной базе, а там... 20 файлов, таблицы, индексы навалены, копии базы поднимали 2 раза тестово и тоже в это табличное пространство. Пол субботы распихивала это по отдельным табличным пространствам. В табличном пространстве остались небольшие таблицы и самая большая таблица, занимает процентов 70 табличного пространства, 300 гиг. И все это размазано по файлам ровным слоем. Вопрос что с этим делать, можно вытащить мелкие таблицы, а эту оставить одну в табличном пространстве. Можно как-нибудь перетащить записи в первые n файлов, а прочие удалить? move на нее займет часов 15 в лучшем случае. Или просто shrink сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 17:26 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, не майтесь дурью с табличными пространствами, используйте более рационально вашу неуемную энергию. у вас честно, какая-то каша. У вас есть четкая цель - что вы хотите получить ? что у вас там за железо ? что такое 3300 чтений - и чем оно вас так пугает? такое количество должно выполняться за доли сек. Почитайте какие виды join оптимизатор оракла может использовать, что больше подходит под вашу задачу. Сколько строк должен вернуть запрос. А обсуждение здесь пока очень похоже на обсуждение того самого теоретического коня округлой формы, насоветуют вам на полгода исследований. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2016, 08:26 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
опс..., Результат беру из этого запроса Код: sql 1. 2. 3. сразу после перезапуска тестовой базы и запуска первого запроса, то есть запрос каждый раз выполняю один раз, чтобы не брал данные из кэша. buffer_gets кстати тоже различаются в разы. Я бы честно партиционировала, но боюсь разработчик по рукам надает, поэтому пока базу в порядок привожу немного. Да и инсерт при партиционировании может занять некоторое неопределенное время, поэтому думаю все таки оставить это опцию разработчику. А вот пожать данные мне ничего не мешает, да и индекс создать тоже, но как я поняла индексы что про trunc, что desc тут бессмысленны, по desc вообще странный план получается, поэтому проще сделать индекс asc по двум столбцам, и посмотреть что будет. А вот как бы главное табличное пространство с этой таблицей подрезать еще... Там без этой таблицы вся база гиг 50, а с нею 500. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2016, 11:22 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
ПС. У меня есть главный сервер, где железо я считаю очень неплохое, вчера утащила в отдельное табличное пространство продукты, 7 миллионов, и перестраивала индексы, на каждый индекс фулл скан 2 минуты. А есть сервер тестовый виртуальный, со всеми вытекающими, но на нем можно сравнить разные варианты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2016, 11:28 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845сразу после перезапуска тестовой базы и запуска первого запроса, то есть запрос каждый раз выполняю один раз, чтобы не брал данные из кэша. охох ) Вы теоретическое исследование делаете или реальной базой занимаетесь ? ) 1. Сколько строк возвращает запрос. 2. Сколько фактически строк в каждой по-отдельности таблице строк, удовлетворяющих условиям запроса(без join). 3. План запроса, время выполнения разных планов. 4. ... еще раз - ну бросьте вы табличные пространства мучить, эффективность этого к затраченному времени - если не отрицательная, то практически абсолютный ноль ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2016, 11:38 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
План для desc В плане для Asc дата уходит в INDEX RANGE SCAN - Predicate - по результатам самый оптимальный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2016, 11:39 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
опс..., Не знаю почему вы так считаете, я всего лишь делаю по рекомендациям на 111-112 странице Oracle 10G Луни-Брила. Вот что пока получилось. Утащила временные табличные пространства каждой схемы на винчестер с бэкапами (это я давно сделала). Растащила данные левых пользователей по их табличным пространствам, все равно эти схемы тестовые и с ними не работают. Разнесла крупные таблицы в отдельные табличные пространства и индексы тоже. Мелкие таблицы пыталась поделить на группы по интенсивности доступа. Код: sql 1. 2. 3. 4. 5. 6. 7. Вот тут вышло хуже, оказалось данная выборка очень часто меняется, по итогу сгрузила все мелкие таблицы в одно табличное пространство, а индексы в другое. В главном табличном пространстве осталась самая большая таблица и индексная таблица, которая пересоздается ночью (это не моя задумка), ее тоже утащила к мелким таблицам, табличное пространство по умолчанию поменяла, корзину отключила. Индексная таблица там конечно тоже не очень хорошее решение. Главную таблицу пытаюсь сжать хотя бы COMPACT, очень грузит систему, и не могу понять при прерывании SHRINK возвращается все на свои места или нет. MOVE для данной таблицы сделать быстро не реально, она процентов 90 всей базы. И еще проблема из запроса Код: sql 1. 2. 3. 4. 5. пропали все остальные таблицы и индексы корме главной таблицы L и индексной, не могу понять обновляется вьюшка v$bh или нет. То есть таблицы явно в памяти, не может он их читать каждый раз, но тут их не видно, загадка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 06:30 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
nata44845, эх, твою бы энергию, да в нужное русло... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 08:43 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Дело кончилось тем, что я создала новый индекс на 2 столбца продукт и дата, помучилась с привязкой к нему планов, посмотрела, как медленно стали удаляться данные и за доп. индекса, посмотрела на соседнюю таблицу (а там в индекс по продукту добавлена дата, видимо разработчиком), грохнула свой индекс и добавила дату в продуктовый индекс (тем более, что тот индекс прописан в подсказках во всех запросах), привязки планов соответственно почистила. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2016, 08:04 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1887102]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
168ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
85ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 510ms |

| 0 / 0 |
