Медленный фетч данных в FB

← →
jack128 © (2007-04-09 18:49) [0]

FB - 1.5
IBX - 10, 10

Итак, суть проблемы:

Есть запрос:

select rf.id as folder_id, ro.id as org_id, ro.title as org_title, ro.inn as inn, d.id as dongle_id, d.pn as dongle_pn, d.sn as dongle_sn, d.dongletype, d.smetausers, d.ginfousers, lo.title as licobj_title, cc.sellingdate from rcards rc left join sp_get_rcard_data_content(rc.data) cc on 1 = 1 join rdongles rd on rd.id = rc.rdongleid join stddongles d on d.id = rd.stddongleid join rorgs ro on ro.id = rd.rorgid join rfolders rf on rf.id = ro.rfolderid join ters lo on lo.id = cc.licobjid where rf.branchid = 11876 and rc.cardtype = 1 and cc.sellingdate >= "1890-04-01" and cc.sellingdate <= "2007-04-10"

хп sp_get_rcard_data_content(rc.data) парсит блоб(ну не сама, а через udf, конечно) и выдает набор данных. Никаких SQL запросов не делает.

Запрос вполняется достаточно быстро, возвращает порядка 60000 записей. Проблема возникает в фетче, а именно - некоторые записи (их очень мало, буквально несколько штук) фетчатся по несколько СЕКУНД! При этом FB на 100% грузит проц.Результирующий набор данных не содержит никаких блоб, только числа и строки(не большие, в среднем по 100 символов, максимум - 261 символ).

В чем проблема то? Есть мысли какие?

PS udf - написана правельно, да и не может быть в ней проблема, запрос то сам нормально отрабатывает.
PPS подключение через localhost

← →
Johnmen © (2007-04-09 20:12) [1]

В чём проблема трудно сказать наверняка, но можно сделать некоторые предположения...
Попробуй:
1. порядок условий в where сделать 4-3-1-2 вместо 1-2-3-4
2. вообще выкинуть 3
3. left join сделать после всех join"ов

← →
StriderMan © (2007-04-09 20:54) [2]

А план запроса смотрел?

> записи (их очень мало, буквально несколько штук) фетчатся
> по несколько СЕКУНД!

backup-restore давно делал?

← →
jack128 © (2007-04-10 10:38) [3]

Еще раз уточню: скорость выполнения ЗАПРОСА меня устраивает. Меня не устраивает скорость фетча данных.
StriderMan © (09.04.07 20:54) [2]
backup-restore давно делал?
Можно сказать - только что. Я просто бекап рабочей базы взял.

Johnmen © (09.04.07 20:12) [1]
Я попробую, конечно, но можнго пояснить, какое влияние это окажет на фетч?

← →
jack128 © (2007-04-10 11:02) [4]

Блин. Наверно я чего то не понимаю в этой жизни. После выполнения это
Johnmen © (09.04.07 20:12) [1]
3. left join сделать после всех join"ов

рекомендации все стало летать. НО ПОЧЕМУ??????

← →
Desdechado © (2007-04-10 11:37) [5]

> НО ПОЧЕМУ?
Порядок расположения таблиц во FROM имеет значение (как и порядок соединения таблиц и записи условий WHERE, о чем сказал Johnmen). От этого зависит работа оптимизатора. Думаю, план будет весьма разный.

> скорость выполнения ЗАПРОСА меня устраивает.
> Меня не устраивает скорость фетча данных.
Фишка в том, что при выполнении запроса твоя процедура скорре всего не вызывается, т.к. условия соединения с ней всегда истинно. А вот при фетче как раз может происходить вызов.
Кстати, рекомендую обратить внимание на поедаемую память, если у тебя в UDF она загребается и "отпускается". По моим наблюдениям фактическое освобождение памяти происходит не при выходе из UDF, а при завершении выполнения запроса (освобождение ресурсов сервера, занятых этим запросом). Поэтому если у тебя в UDF идет большая работа с пямятью, то есть риск нарваться на своп или физическую недостачу памяти (у меня были такие приколы, когда внутри ХП обрабатывалось около 100 тыс блобов).

← →
jack128 © (2007-04-10 12:04) [6]

Desdechado © (10.04.07 11:37) [5]
Фишка в том, что при выполнении запроса твоя процедура скорре всего не вызывается, т.к. условия соединения с ней всегда истинно. А вот при фетче как раз может происходить вызов.

Э-э-э. Чесно говоря говоря не думал, что такое возможно.

Desdechado © (10.04.07 11:37) [5]
Кстати, рекомендую обратить внимание на поедаемую память, если у тебя в UDF она загребается и "отпускается". По моим наблюдениям фактическое освобождение памяти происходит не при выходе из UDF,
Ну когда осводится память в udf зависит от её манагера памяти, наверно..

← →
jack128 © (2007-04-10 12:10) [7]

а с планом вот такая штука:
в тормознутом варианте:
PLAN JOIN (JOIN (RC NATURAL,SP_GET_RCARD_DATA_CONTENT NATURAL),JOIN (RD INDEX (PK_RDONGLES),LO INDEX (PK_TERS),D INDEX (PK_STDDONGLES),RO INDEX (PK_RORGS),RF INDEX (PK_RFOLDERS)))

Натурал по Rcards

в быстром:
PLAN JOIN (JOIN (JOIN (RF NATURAL,RO INDEX (FK_RORGS_1),RD INDEX (FK_RDONGLES_1),D INDEX (PK_STDDONGLES),RC INDEX (RCARDS_IDX1)),SP_GET_RCARD_DATA_CONTENT NATURAL),LO INDEX (PK_TERS))

Натурал по rfolders.
При этом в rcards записей на порядок боьше записей, чем в rfolders. А вот как влияет сам порядок джойнов на производительность, мне не понятно.

← →
jack128 © (2007-04-10 12:10) [8]

jack128 © (10.04.07 12:10) [7]
вот как влияет сам порядок джойнов в плане на производительность, мне не понятно

← →
Desdechado © (2007-04-10 12:51) [9]

jack128 © (10.04.07 12:10) [8]
По правилам скобок :)

← →
Romkin © (2007-04-10 13:55) [10]

Скобки, кстати, ставить тоже можно :)
from ((a join b on ...) join c on ...) join d on ... и тд

← →
jack128 © (2007-04-10 14:25) [11]

Desdechado © (10.04.07 12:51) [9]
По правилам скобок :)
В каком порядке они соединяются, я понял. Меня интересует, какой лудше план например для такого запроса:

select * from a
join b on a.a_field = b.b_field

PLAN JOIN (A NATURAL,B INDEX (IDX_B_FIELD))
или
PLAN JOIN (B NATURAL,A INDEX (IDX_A_FIELD))

если в таблице a - 1 млн записей, а в таблице b - 100 тыс ? Я так понимаю, второй лудше. Я прав?

← →
Sergey13 © (2007-04-10 14:48) [12]

> [11] jack128 © (10.04.07 14:25)
> Я прав?

ИМХО, нет. При таком запросе будут выбраны ВСЕ записи таблицы А, и некоторые из таблицы Б. Т.е. по А все равно будет полное сканирование, а поиск будет идти в таблице Б. Так что индекс нужнее в Б.

← →
jack128 © (2007-04-10 15:11) [13]

Sergey13 © (10.04.07 14:48) [12]
При таком запросе будут выбраны ВСЕ записи таблицы А,
а не наоборот? я так понимаю, что при PLAN JOIN (B NATURAL,A INDEX (IDX_A_FIELD)) как раз таблица B - будет полностью просканирована, и для каждой её записи по индексу будет найдены соотетствующие записи из A.

> [13] jack128 © (10.04.07 15:11)

Зародил ты во мне сомнения, если честно. Разбираться жаль некогда.
Но вроде таблица А по тексту запроса явялется ведущим потоком, поэтому будет читаться первой.

Sergey13 © (10.04.07 16:18) [14]
Но вроде таблица А по тексту запроса
А причем тут текст запроса? Я так понимаю, запрос описывает ЧТО мы хотим получить, какие нам нужны данные. А план описывает КАК нужно получить эти данные.

> [15] jack128 © (10.04.07 16:58)
> А причем тут текст запроса?

Ну ты же сам просто поменял текст и получил другой план.

Sergey13 © (10.04.07 17:00) [16]
Ну ты же сам просто поменял текст и получил другой план.

Да, естественно. Но можно изменить план, не меняя текста запроса. Как например в [11]

← →
Jan1 (2007-04-10 18:35) [18]

сейчас прочитал. по поводу первой статьи - там как раз и описан нормальный, работоспособный способ соединения таблицы с ХП, который я и использую. А вторая, ИМХО, вообще не в тему..

Медленный фетч данных в FB Найти похожие ветки