powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
22 сообщений из 22, страница 1 из 1
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293369
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем доброе время суток.

Перешел недавно на 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.
...


Ну и собственно старый как мир вопрос: кто виноват и что делать?
Заранее спасибо неравнодушным!
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293372
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ritter,

явные планы зло. Композиты по 100500 полям тоже.

Условие я бы сделал покороче

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
...
WHERE
      T.F4 = :F4
  AND T.F5 = :F5
  AND T.F6 = :F6
  AND T.F7 = :F7
  AND T.F8 = :F8
  AND T.F9 = :F9
  AND ((T.F1 = :F1 AND T.F2 = :F2 AND T.F3 = :F3 AND NOT :FLAG) OR
       (T.G1 = :G1 AND T.G2 = :G2 AND T.G3 = :G3 AND :FLAG))
FETCH FIRST 1000 ROWS ONLY



Вне пакета запрос даёт нормальный план?
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293387
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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)
это полная бессмыслица.
Нужно выбрать столбец с наиболее уникальными значениями, по нему (одному) и создать индекс.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293404
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RitterВ процедуре из пакета использую запрос вида
.... за который на серьёзном продакшене увольняют за профнепригодность. Это ДВА совершенно
разных запроса. За их склеивание в один ты, собственно, и получаешь неприятности.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293673
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис
Вне пакета запрос даёт нормальный план?

Да. При запуске в окне 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
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293699
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Провел дополнительный анализ ситуации.
Собственно я не удачно сформировал свое первоначальное сообщение. Попробую еще раз, причем разбив его на два отдельных.

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 происходит без ошибок.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293714
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
if (not :flag) then begin
  --------------------------------------
  select f1, f2, f3
  from ...
  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
  )
  fetch first 1000 rows only
  into :f1, :f2, :f3;
  --------------------------------------
end else begin
  --------------------------------------
  select f1, f2, f3
  from ...
  where (
  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
  into :f1, :f2, :f3;
  --------------------------------------
end
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293716
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Без указания плана оптимизатор вероятно берет только один индекс и вторую половину условий ему приходится проверять натуралом, а может быть даже и обе части.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293717
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ritter,

Ну твой план не совсем корректен. Точнее отображаться то он так конечно может, но вот происходящее внутри никак не описывает. Глянь в explain план и увидишь, что там происходит на самом деле.

Что такое g1, g2, g3?

Что за задача такая что нужно искать точное соответствие по всем полям?

Теперь об индексах. Вот если бы у тебя были индексы

Код: sql
1.
2.
create index idx1 on t (f4,f5,f6,f7,f8,f9, f1,f2,f3)
create index idx2 on t (f4,f5,f6,f7,f8,f9, g1,g2,g3)



то по запросу с условием

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
WHERE
      T.F4 = :F4
  AND T.F5 = :F5
  AND T.F6 = :F6
  AND T.F7 = :F7
  AND T.F8 = :F8
  AND T.F9 = :F9
  AND ((T.F1 = :F1 AND T.F2 = :F2 AND T.F3 = :F3 AND NOT :FLAG) OR
       (T.G1 = :G1 AND T.G2 = :G2 AND T.G3 = :G3 AND :FLAG))
FETCH FIRST 1000 ROWS ONLY



было бы частичное совпадение при любых условиях, а так огребай конечно.

Я глубоко сомневаюсь в ценности твоих композитов, но уж если хочешь композиты и именно такое условие, то сделай три индекса.

Код: sql
1.
2.
3.
create index idx0 on t (f4,f5,f6,f7,f8,f9);
create index idx1 on t (f1,f2,f3);
create index idx2 on t (g1,g2,g3);



З.Ы. Раз стоит fetch first 1000 rows only то эта выборка ещё и не фига не уникальна, что наводит на размышления.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293720
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЗ.Ы. Раз стоит fetch first 1000 rows only то эта выборка ещё и не фига не уникальна, что наводит на размышления.

Скорее всего это просто страховка от получения на клиента всех 10млн записей при наличии незаполненных полей или чего-то такого.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293730
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А нет ли в исходном запросе ORDER BY?
Было бы неплохо увидеть запрос/процедуру целиком.

Текст скриптов лучше выделять тегами не италика а SRC PLSQL
При больших простынях бывает удобно все это дело еще завернуть в тег SPOILER (в редакторе прячется справа за кнопкой "дополнит.")

Код: plsql
1.
123
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293859
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fetch first 1000 rows only

Это я вводил для тестов: на 1000, 100 и 10 записях.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293899
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вопрос про оптимизатор не самый важный - всегда можно использовать план влоб.

Гораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
IBE: Starting restore. Current time: 13:28:59
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
     Error while parsing procedure MEK_DUBL.INSUR_CASE_BY_FIOD_KS's BLR.
     index SLUCH_IDX_FIOD cannot be used in the specified plan.
     there is no index SLUCH_IDX_FIO_P_DR for table SLUCH.
     Exiting before completion due to errors.
IBE: Restore completed. Current time: 13:29:09. Elapsed time: 00:00:10



Сама процедура:

Код: 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.
procedure INSUR_CASE_BY_FIOD_KS(
    lpu_src varchar(6),date_1_src date,date_2_src date,prvs_src smallint,
    fam varchar(40),im varchar(40),ot varchar(40),dr date,
    novor_src varchar(10),fam_p varchar(40),im_p varchar(40),ot_p varchar(40))
  returns (
    case_id bigint)
as
begin
  
  for select s.case_id
        from sluch s
        where (
               not sluch_is_novor(:novor_src) and
               s.fam=:fam and s.im=:im and s.ot=:ot and s.dr=:dr and
               s.date_1=:date_1_src and s.date_2=:date_2_src and
               s.file_mp=1 and s.vid_mp=3 and s.lpu=:lpu_src and s.prvs=:prvs_src
              )
              or
              (
               sluch_is_novor(:novor_src) and
               s.fam_p=:fam_p and s.im_p=:im_p and s.ot_p=:ot_p and s.dr=:dr and
               s.date_1=:date_1_src and s.date_2=:date_2_src and
               s.file_mp=1 and s.vid_mp=3 and s.lpu=:lpu_src and s.prvs=:prvs_src
             )
        plan (s index (sluch_idx_fiod,sluch_idx_fio_p_dr))
        order by s.sluch_id asc
        fetch first 1 row only
  into case_id
  do suspend;

end



Индексы:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
ALTER TABLE SLUCH ADD CONSTRAINT PK_SLUCH PRIMARY KEY (SLUCH_ID);

CREATE INDEX SLUCH_IDX_FIOD ON SLUCH (FAM, IM, OT, DR, DATE_1, DATE_2, FILE_MP, VID_MP, LPU, PRVS);
CREATE INDEX SLUCH_IDX_FIO_P_DR ON SLUCH (FAM_P, IM_P, OT_P, DR, DATE_1, DATE_2, FILE_MP, VID_MP, LPU, PRVS );

CREATE INDEX SLUCH_IDX_CASE_ID ON SLUCH (CASE_ID);
CREATE INDEX SLUCH_IDX_DATE_1_2 ON SLUCH (DATE_1, DATE_2);
CREATE INDEX SLUCH_IDX_FILE_VID_MP ON SLUCH (FILE_MP, VID_MP);
CREATE INDEX SLUCH_IDX_LPU ON SLUCH (LPU);

...
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293907
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RitterГораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe:

Посмотри полный лог. Когда восстанавливаются пакеты и когда - индексы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293908
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ritterэтот запрос исполняется за один раз и требует меньших ресурсов от сервера

сделай один запрос из двух частей через UNION ?
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293909
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ritter,

потому что ты указал некорректный план. Другой вопрос почему процедура изначально скомпилировалась.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293912
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

да план у него кривой. Там должно быть SORT или ORDER.

Ritter,

запусти этот запрос вне процедуры без указания плана и посмотри какой план должен быть
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293934
Ritter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovRitterГораздо важнее узнать причину появляется сообщения об ошибке при restore gbak.exe:

Посмотри полный лог. Когда восстанавливаются пакеты и когда - индексы.

Судя по логу до индексов еще дело не доходит: домены, поля таблиц, параметры процедур и ошибка.

AriochRitterэтот запрос исполняется за один раз и требует меньших ресурсов от сервера

сделай один запрос из двух частей через UNION ?
Спасибо. Попробую.

Симонов ДенисDimitry Sibiryakov,

да план у него кривой. Там должно быть SORT или ORDER.

Ritter,

запусти этот запрос вне процедуры без указания плана и посмотри какой план должен быть

Точно, с планом косяк. Запустил в SQL редакторе:
Код: sql
1.
PLAN (S ORDER PK_SLUCH INDEX (SLUCH_IDX_FIOD, SLUCH_IDX_FIO_P_DR))



Спасибо, буду пробовать запустить backup/restore.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293937
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RitterСудя по логу до индексов еще дело не доходит: домены, поля таблиц, параметры процедур и
ошибка.

Вот теперь ты знаешь почему не надо использовать планы в процедурах.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39293945
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
select s.case_id, s.sluch_id
  from sluch s
  where (not sluch_is_novor(:novor_src) and
         s.fam=:fam and s.im=:im and s.ot=:ot and s.dr=:dr and
         s.date_1=:date_1_src and s.date_2=:date_2_src and
         s.file_mp=1 and s.vid_mp=3 and s.lpu=:lpu_src and s.prvs=:prvs_src)

union all

select s.case_id, s.sluch_id
  from sluch s
  where (sluch_is_novor(:novor_src) and
         s.fam_p=:fam_p and s.im_p=:im_p and s.ot_p=:ot_p and s.dr=:dr and
         s.date_1=:date_1_src and s.date_2=:date_2_src and
         s.file_mp=1 and s.vid_mp=3 and s.lpu=:lpu_src and s.prvs=:prvs_src)

order by sluch_id asc
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39294194
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RitterНа самом деле тут нет бессмыслицы.
бессмыслица в использовании индекса с таким количеством столбцов.
RitterТак что индексы мне нужны именно в такой форме.
слишком "жирный" индекс получается, достаточно 3х столбцов.
надо смотреть, какой план выдается исходно, и сколько идет page reads и fetches в том или ином случае (с разными индексами, длинными и короткими).
А так вы тыкаете в Firebird палкой, непонятно куда, глядя на реакцию.
...
Рейтинг: 0 / 0
FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
    #39294204
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery
Код: sql
1.
union all



а вот ALL тут не нужен, не нужен

в оригиналде OR стояло же
...
Рейтинг: 0 / 0
22 сообщений из 22, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB3 - пакеты: работа оптимизатора и ошибка полного рестора базы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]