|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Всем доброе время суток. Перешел недавно на FB3. Сейчас осваиваю в работе новые фичи в том числе и пакеты. В процедуре из пакета использую запрос вида where ( not :flag and t.f1=:f1 and t.f2=:f2 and t.f3=:f3 and t.f4=:f4 and t.f5=:f5 and t.f6=:f6 and t.f7=:f7 and t.f8=:f8 and t.f9=:f9 ) or ( :flag and t.g1=:g1 and t.g2=:g2 and t.g3=:g3 and t.f4=:f4 and t.f5=:f5 and t.f6=:f6 and t.f7=:f7 and t.f8=:f8 and t.f9=:f9 ) fetch first 1000 rows only Соответствующие индексы созданы, create index idx1 on t (f1,f2,f3,f4,f5,f6,f7,f8,f9) create index idx2 on t (g1,g2,g3,f4,f5,f6,f7,f8,f9) но оптимизатор их явно не использует: в таблице t около 10000000 записей, запрос отрабатывает примерно за 8 минут при выборке первых тысячи записей. Подсовываю оптимизатору план plan (t index (idx1,idx2)) - запрос отрабатывается за несколько секунд. В общем все-бы ничего пусть бы его план и остается, но провожу тестовое восстановление базы и получаю ошибку вида: ... Error while parsing procedure test_pack.test_proc`s BLR. index idx1 cannot be used in the specified plan. there is no index idx2 for table t. unknown ISC error 336330835. ... Ну и собственно старый как мир вопрос: кто виноват и что делать? Заранее спасибо неравнодушным! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2016, 15:22 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Ritter, явные планы зло. Композиты по 100500 полям тоже. Условие я бы сделал покороче Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Вне пакета запрос даёт нормальный план? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2016, 15:31 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Rittercreate index idx1 on t (f1,f2,f3,f4,f5,f6,f7,f8,f9) create index idx2 on t (g1,g2,g3,f4,f5,f6,f7,f8,f9) это полная бессмыслица. Нужно выбрать столбец с наиболее уникальными значениями, по нему (одному) и создать индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2016, 15:53 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
RitterВ процедуре из пакета использую запрос вида .... за который на серьёзном продакшене увольняют за профнепригодность. Это ДВА совершенно разных запроса. За их склеивание в один ты, собственно, и получаешь неприятности. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2016, 16:19 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Симонов Денис Вне пакета запрос даёт нормальный план? Да. При запуске в окне SQL-Редактора план выбирается автоматически по указанным индексам. Условие я бы сделал покороче Это понятно. Я специально переписал запрос в форме, в которой оптимизатору было проще(ИМХО). Но увы. kdv это полная бессмыслица. Нужно выбрать столбец с наиболее уникальными значениями, по нему (одному) и создать индекс f1 - Фамилия f2 - Имя f3 - Отчество f4 - Дата рождения f5 и f6 - даты начала и окончания обращения f7 - код учреждения f8 - код специалиста f9 - личный код специалиста По специфике задачи два ключа поиска: flag: признак выбора фамилии 1, имени 1 , отчества 1, ...остальные поля - вариант 1 not flag: признак выбора фамилии 2, имени 2, отчества 2, ... остальные - вариант 2 На самом деле тут нет бессмыслицы. Индекс создавался как для ускорения поиска, так и для универсальности: эти индексы постоянно используются как по всем полям, так и по части полей с начала индекса. Например: - Фамилия,Имя, Отчество, Дата Рождения - Фамилия,Имя, Отчество, Дата Рождения, даты начала и окончания обращения - и т.д. Так что индексы мне нужны именно в такой форме. Dimitry Sibiryakov .... за который на серьёзном продакшене увольняют за профнепригодность. Это ДВА совершенно разных запроса. За их склеивание в один ты, собственно, и получаешь неприятности. Спасибо на добром слове! Дело в том, что при указании плана в SQL запросе все прекрасно и быстро работает. Про два отдельных SQL запроса Вы частично правы, но есть один момент: этот запрос исполняется за один раз и требует меньших ресурсов от сервера, а так же когда писался запрос был еще сервер FB 2.5 с его ограничением 64К на процедуру - приходилось оптимизировать код. Про неприятности. В тестах я пробовал использовать упрощенную конструкцию вида where ( t.f1=:f1 and t.f2=:f2 and t.f3=:f3 and t.f4=:f4 and t.f5=:f5 and t.f6=:f6 and t.f7=:f7 and t.f8=:f8 and t.f9=:f9 ) но и в этом случае оптимизатор игнорирует индекс idx1 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 08:44 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Провел дополнительный анализ ситуации. Собственно я не удачно сформировал свое первоначальное сообщение. Попробую еще раз, причем разбив его на два отдельных. 1. Есть таблица t которой порядка 10 000 000 записей. В структуре таблице в числе прочих полей присутствуют поля f1 - Фамилия f2 - Имя f3 - Отчество f4 - Дата рождения f5 и f6 - даты начала и окончания обращения f7 - код учреждения f8 - код специалиста f9 - личный код специалиста Для ускорения поиска по указанной комбинации полей создан индекс create index idx1 on t (f1,f2,f3,f4,f5,f6,f7,f8,f9) . Кроме того у таблицы t есть так же другие индексы построенные как по отдельным полям, так и по их другим комбинациям из указанного списка - но индекс idx1 имеет наилучшую селективность . При выполнении в процедуре SQL запроса с where условием вида where t.f1=:f1 and t.f2=:f2 and t.f3=:f3 and t.f4=:f4 and .f5=:f5 and t.f6=:f6 and t.f7=:f7 and t.f8=:f8 and t.f9=:f9 с указанием плана plan (t index (idx1)) влоб запрос отрабатывает быстро. Если убираем строку плана, то оптимизатор отказывается использовать указанный индекс idx1 и, судя по времени исполнения запроса, использует какой-то один из других индексов или их комбинацию(какие конкретные индексы как узнать?). В этом случае время выполнения запроса падает минимум на порядок. Собственно вопрос: почему оптимизатор отказывается использовать индекс idx1, построенный по тем же полям и в том же порядке что и в условии where, имеющий наилучшую селективность, а использует какой-то другой, построенный по части из указанных полей. 2. С переходом на FB 3 стал использовать пакеты. При этом если в процедурах пакетов в SQL запросах я использую план исполнения запросов в лоб, то при выполнении процедуры backup/restore утилитой gbak при выполнении restore появляется ошибка ... Error while parsing procedure test_pack.test_proc`s BLR. index idx1 cannot be used in the specified plan. there is no index idx2 for table t. unknown ISC error 336330835. ... и restore прерывается. Убираю из SQL запросов все сроки plan ... - в этом случае backup/restore утилитой gbak происходит без ошибок. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 09:21 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
RitterЕсли убираем строку плана, то оптимизатор отказывается использовать указанный индекс idx1 и, судя по времени исполнения запроса, использует какой-то один из других индексов или их комбинацию(какие конкретные индексы как узнать?). В этом случае время выполнения запроса падает минимум на порядок. План запроса можно посмотреть в IBExpert, выполнив в нем этот запрос или сделав ему prepare. RitterСобственно вопрос: почему оптимизатор отказывается использовать индекс idx1, построенный по тем же полям и в том же порядке что и в условии where, имеющий наилучшую селективность, а использует какой-то другой, построенный по части из указанных полей. Не анализируя запрос я вижу 2 варианта: - оптимизатор не может использовать этот индекс из-за разных условий на равенство-неравенство по одним и тем же полям. - оптимизатору показалось что использовать другой индекс будет лучше, но он ошибся. Вообще говоря, использование индекса - не показатель эффективности запроса. Бывают случаи когда оптимизатор хватается не за то что надо, ему ручками запрещаешь это делать, запрос выполняется вообще натуралом и при этом гораздо быстрее. В частности бывает при соединении таблиц и при наличии индекса по полю по которому сделан order by. Без индекса по полю сортировки он сначала ограничивает выборку, получается к примеру 10 записей и их натуралом по любому быстрее отсортировать. А если он подхватывает индекс - то сначала отсортирует сотни тысяч записей по индексу (ну и нафига?) и только потом их них отберет 10 реально нужных. Поскольку у тебя запрос уже внутри процедуры - не вижу проблем разбить его на 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 09:49 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Без указания плана оптимизатор вероятно берет только один индекс и вторую половину условий ему приходится проверять натуралом, а может быть даже и обе части. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 09:56 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Ritter, Ну твой план не совсем корректен. Точнее отображаться то он так конечно может, но вот происходящее внутри никак не описывает. Глянь в explain план и увидишь, что там происходит на самом деле. Что такое g1, g2, g3? Что за задача такая что нужно искать точное соответствие по всем полям? Теперь об индексах. Вот если бы у тебя были индексы Код: sql 1. 2.
то по запросу с условием Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
было бы частичное совпадение при любых условиях, а так огребай конечно. Я глубоко сомневаюсь в ценности твоих композитов, но уж если хочешь композиты и именно такое условие, то сделай три индекса. Код: sql 1. 2. 3.
З.Ы. Раз стоит fetch first 1000 rows only то эта выборка ещё и не фига не уникальна, что наводит на размышления. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 09:57 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Симонов ДенисЗ.Ы. Раз стоит fetch first 1000 rows only то эта выборка ещё и не фига не уникальна, что наводит на размышления. Скорее всего это просто страховка от получения на клиента всех 10млн записей при наличии незаполненных полей или чего-то такого. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 10:00 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
А нет ли в исходном запросе ORDER BY? Было бы неплохо увидеть запрос/процедуру целиком. Текст скриптов лучше выделять тегами не италика а SRC PLSQL При больших простынях бывает удобно все это дело еще завернуть в тег SPOILER (в редакторе прячется справа за кнопкой "дополнит.") Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 10:08 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
fetch first 1000 rows only Это я вводил для тестов: на 1000, 100 и 10 записях. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 12:49 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Вопрос про оптимизатор не самый важный - всегда можно использовать план влоб. Гораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe: Код: 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. 27. 28. 29. 30. 31.
Индексы: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 13:48 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
RitterГораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe: Посмотри полный лог. Когда восстанавливаются пакеты и когда - индексы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 13:54 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Ritterэтот запрос исполняется за один раз и требует меньших ресурсов от сервера сделай один запрос из двух частей через UNION ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 13:55 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Ritter, потому что ты указал некорректный план. Другой вопрос почему процедура изначально скомпилировалась. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 13:55 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, да план у него кривой. Там должно быть SORT или ORDER. Ritter, запусти этот запрос вне процедуры без указания плана и посмотри какой план должен быть ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 13:57 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovRitterГораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe: Посмотри полный лог. Когда восстанавливаются пакеты и когда - индексы. Судя по логу до индексов еще дело не доходит: домены, поля таблиц, параметры процедур и ошибка. AriochRitterэтот запрос исполняется за один раз и требует меньших ресурсов от сервера сделай один запрос из двух частей через UNION ? Спасибо. Попробую. Симонов ДенисDimitry Sibiryakov, да план у него кривой. Там должно быть SORT или ORDER. Ritter, запусти этот запрос вне процедуры без указания плана и посмотри какой план должен быть Точно, с планом косяк. Запустил в SQL редакторе: Код: sql 1.
Спасибо, буду пробовать запустить backup/restore. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 14:12 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
RitterСудя по логу до индексов еще дело не доходит: домены, поля таблиц, параметры процедур и ошибка. Вот теперь ты знаешь почему не надо использовать планы в процедурах. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 14:15 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 14:25 |
|
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
|
|||
---|---|---|---|
#18+
RitterНа самом деле тут нет бессмыслицы. бессмыслица в использовании индекса с таким количеством столбцов. RitterТак что индексы мне нужны именно в такой форме. слишком "жирный" индекс получается, достаточно 3х столбцов. надо смотреть, какой план выдается исходно, и сколько идет page reads и fetches в том или ином случае (с разными индексами, длинными и короткими). А так вы тыкаете в Firebird палкой, непонятно куда, глядя на реакцию. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2016, 19:19 |
|
|
start [/forum/topic.php?fid=40&msg=39293730&tid=1562002]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 156ms |
0 / 0 |