powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
25 сообщений из 69, страница 2 из 3
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38566180
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrреализовать это будет точно совсем не просто. Но главное - зачем?
Каждая нода сможет накапливать в себе статистики своего выполнения для конкретного запроса
самостоятельно и по запросу формировать свой кусочек плана с выдачей этих статистик.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38566193
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

накапливает она и сейчас. Ибо на самом деле дерево выполнения ссылается на копию процедуры. Каждое дерево имеет свою копию, каждая копия имеет свои счетчики статистики. Проблема не в этом, а в том, что сейчас самый низкий уровень накопления статистики - риквест, копить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого, ибо таких элементов тупо в разы больше.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38566217
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrкопить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого,
ибо таких элементов тупо в разы больше.
Но и статистики там могут быть попроще: количество записей обработанных, подпавших под
условие или отвергнутых, количество вообще обращений к ноде, входное условие (если было
одно) и т.п. Большинство из этого - простые инкременты, делающиеся за один такт.

На их основе могут делаться выводы об эффективности условий, их цены и т.п.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38566225
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

тогда не надо статистику пока. Ибо лишние тормоза не к чему. Достаточно и вот этого:

- id курсора
- ссылка на стейтмент
- текст запроса курсора
- план (explain)
- тип курсора (однонаправленный или двунаправленный)
- количество отфетченных записей (для двунаправленных наверное равняется общему кол-ву)
- текущий номер записи (для двунаправленных это может быть полезно)
- состояние курсора (активен или нет, правда я не знаю может быть как только курсор не активен он тут же пропадает)
- используется ли блокировка (FOR UPDATE WITH LOCK)

Тут ещё возникает ситуация когда один курсор крутится внутри другого можно ещё и дать ссылку на "родительский" курсор
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567027
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати. Раз уж тут разговор зашёл о мониторинге всех курсоров в том числе и тех что выполняются внутри ХП. То может и в трассировку такую информацию добавить и вот там уже выводить полную статистику?
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567060
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

пока разговор идет лишь о том, надо ли такое вообще
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567076
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

пока против вроде никто не высказался.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567084
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениспока против вроде никто не высказался
если это никому не надо, то и не выскажутся :-)
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567532
Alex Truhin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,
учитывая, что сейчас нет ни каких средств отладки/оптимизации SP, я думаю, что любые средства в этом направлении нужны всем
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38567552
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex Truhin,

это точно нельзя отнести к отладке, даже насчет оптимизации я не уверен (без статистики, по крайней мере)
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38687190
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrБыла мысль отдельной таблицей выводить все курсоры данного стейтмента (юзерского или кешированной процедуры), соответственно у каждого курсора свой план (блоб). Но тут надо подумать, что еще имеет смысл выводить для курсоров, только ради планов такой огород нет смысла городить...
. . .
боюсь, что вести полную статистику для каждого курсора будет слишком затратно
. . .
Проблема не в этом, а в том, что сейчас самый низкий уровень накопления статистики - риквест, копить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого, ибо таких элементов тупо в разы больше. Up!!

Три "счастливых" дня
было у меня,
было у меня с трейсОм" (почти (С)).

Я поднимаю тему, т.к. напоролся по полной программе на то, что один из стейтментов (inner join двух таблиц) в некоторой ХП время от времени выполнял natural-сканы большой таблицы.
Причём делалось это не стабильно, а только когда статистика по индексам:
1) отсутствовала (т.е. на старте, когда база только что залита)
2) устаревала до какой-то степени, что в итоге приводило оптимизатор к неверному плану.

И что бы понять, в где именно внутри ХП поменялся план, пришлось танцевать с бубном трое суток
Доводы о том, что накапливать планы по каждому курсору слишком затратно, выглядят для мну теперь... как бы это помягче сказать... ладно, не буду - сами догадаетесь.
У каждой группы разрабов всегда есть более-менее актуальная копия продакшена на отдельном хосте. Когда кто-то из них запускает трейс с установкой connect_id = <my_connect_id>, то даже при всех включённых опциях это мало повлияет на работу его коллег-разрабов (а не усеров! те вообще про это не узнают).
Я совершенно не понимаю, как можно в нынешнем 3.х (в отличие от 2.х!) вести поиск проблемных мест в ХП, состоящей из нескольких отдельных стейтментов, каждый из которых в свою очередь вызывает другие ХП - и там тоже по несколшьку отдельных стейтментов, и т.д.

2 dimitr, hvlad: добавьте хотя бы в трейс ключик, позволяющий вываливать в лог все генерируемые планы! Если еще и статистику по отдельным стейтментам внутри ХП/функций/триггеров сделаете - будет вообще супер.

PS. Идея "отдельной таблицей выводить все курсоры данного стейтмента" - настораживает: это что, опять mon$-таблица будет ? Если да, то... может не надо, а ?... ;-Q

PPS. Кстати: тикет в трекере есть на эту тему ?
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38687204
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсли еще и статистику по отдельным стейтментам внутри ХП/функций/триггеров сделаете - будет вообще суперДа, именно так.
Потому что как иначе понять, на что ушли 68 сек вот тута:
Код: plaintext
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.
2014-07-03T19:03:48.5980 (6599:0x7f10c15a9228) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_166, SYSDBA:NONE, NONE, TCPv4:192.168.43.62)
        C:\1INSTALL\FB25SNAP\bin\isql.exe:1696
                (TRA_293036, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 774851:
-------------------------------------------------------------------------------
execute block returns( invoice_id bigint, total_lines int, total_invoice_qty int, total_invoice_purchase numeric(12,2) )
as begin
    if ( exists( select * from v_qdistr_ord_sup ) ) then
    begin
      select
         min(p.doc_list_id) stock_order_id,
         count(*) total_lines,
         sum(p.qty) total_invoice_qty,
         sum(p.purchase) total_invoice_purchase
      from sp_supplier_invoice p 
      into invoice_id, total_lines, total_invoice_qty, total_invoice_purchase;
      suspend;
   end
end
1 records fetched
  67529 ms, 264 write(s), 67487 fetch(es), 6653 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$DATABASE                            2
RDB$INDICES                                       1
TMP$SHOPPING_CART                      12         1         1        11
TMP$RESULT_SET                        765                           255
Z_USED_VIEWS                                     13
OPTYPES                                          27
RULES_FOR_QDISTR                       91        11
DOC_LIST                                         23        11         1
DOC_DATA                                       2904                  11
QDISTR                                         1592       535       255       255                           122
QSTORNED                                        255       255       255
DOC_STATES                                        1
INVNT_TURNOVER_LOG                               13                  11
PERF_LOG                                          3         3         3
(знаю, надоел я уже с этим вопросом; но уж очень печалька сильная сейчас из-за всего этого...)
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38712931
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
подниму тему:

Симонов ДенисДостаточно и вот этого:

- id курсора
- ссылка на стейтмент
- текст запроса курсора
- план (explain)
- тип курсора (однонаправленный или двунаправленный)
- количество отфетченных записей (для двунаправленных наверное равняется общему кол-ву)
- текущий номер записи (для двунаправленных это может быть полезно)
- состояние курсора (активен или нет, правда я не знаю может быть как только курсор не активен он тут же пропадает)
тут возникает две проблемы, маленькая и большая:

1) Курсор с т.з движка это не то же самое, что с т.з. пользователя. В частности, подзапросы являются курсорами. Это можно видеть в планах любой версии ФБ - отдельная строчка PLAN на каждый подзапрос. Выводить в мониторинге подзапросы как курсоры - сильно не красиво. Можно попробовать в движке их как-то разделить, но что-то мне кажется это невозможным в общем случае - например, IF (A = (SELECT ... )) THEN - это курсор или нет? Если да, то почему WHERE EXISTS (SELECT ....) это не курсор?

2) Для внутренностей PSQL у нас нет текстов запросов. В лучшем случае, если все карты легли удачно - есть исходный текст всей процедуры и номер строки/столбца внутри нее. Но может и этого не быть. Как в итоге идентифицировать курсоры внутри mon$cursors - непонятно. Имя курсора можно выводить, но в подавляющем большинстве случаев оно отсутствует. Можно пытаться разобраться по планам, но это изврат.

Что-то мне сильно не хочется делать бесполезную фичу, несмотря на первоначальную привлекательность :-(
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38712958
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

да уж печально.

Если ещё по первому пункту можно надеется что в будущих версиях часть подзапросов внутри SELECTов можно будет преобразовать в полу джойны, то по второму и сказать нечего.

Можно в мониторинге хотя бы агрегированную статистику по курсорам показывать (сколько активно в данный момент, сколько всего было открыто)? Хотя полезность этой информации гораздо ниже.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38712963
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

а ещё можно для запросов показывать сколько он контекстов задействовал, а то их расчёт не очевиден.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38712995
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисможно надеется что в будущих версиях часть подзапросов внутри SELECTов можно будет преобразовать в полу джойны
это далеко не все случаи подзапросов, самый проблемный - select (select ...) ...

Симонов ДенисМожно в мониторинге хотя бы агрегированную статистику по курсорам показывать (сколько активно в данный момент, сколько всего было открыто)?
пока не вижу в этом практического смысла

Симонов Дениса ещё можно для запросов показывать сколько он контекстов задействовал, а то их расчёт не очевиден
тоже не вижу смысла. Подгонять текст запроса под лимит - ущербная практика, проще сразу делить его на части и выносить их в процедуры.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713049
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr> самый проблемный - select (select ...) ...

А почему он проблемный, если не секрет?
С т.з. отображения можно было бы и вполне
понятно/удобно было бы рассматривать его
как два "курсора" (в твоих терминах).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713058
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

dimitr наверное имел ввиду, что его в полуджойн не преобразовать. А если рассматривать как курсор, то он ведь будет открыт столько раз сколько записей в запросе верхнего уровня
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713077
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамА почему он проблемный, если не секрет?
во-первых, его никак не преобразуешь. Во-вторых, внутри движка нет понятия "select list". Данный подзапрос будет подставлен как выражение там, где идет обращение к нему по имени. И привязать его к "родительскому" курсору может быть затруднительно.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713080
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис> он ведь будет открыт столько раз сколько записей в запросе верхнего уровня

С какой стати? Пусть будут два некореллированный/материализованный курсор.
Или просто два независимых, если некореллированный трудно отобразить.

Впрочем, даже после объяснения ДЕ я нихрена не понял, в чём проблема, так что ХЗ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713090
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамС какой стати? Пусть будут два некореллированный/материализованный курсор.
Или просто два независимых, если некореллированный трудно отобразить.

а статистику то по ним как выводить? При выполнении на самом деле это каждый раз новый курсор на новую запись.
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713096
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисДостаточно и вот этого:
. . .
- ссылка на стейтмент
. . .
- план (explain)+1!

SP всё равно состоит из отдельных стейтментов, какие бы сложные они там не были.
Необходимо показывать план и статистику с точностью всего лишь до отдельного стейтмента , более детально - сколько и чего там делают его отдельные подзапросы, типа where exists(select * from . . .), - не нужно, перетопчемся.
Почему-то fbclient.dll при возникновении ошибки в N-ом стейтменте (если она не перехватывается when-блоком и далее не пробрасывается exception'ом) может точно показать номер строки + столба, где это случилось. Неужели нельзя вытряхивать такую же инфу (номер строки + столба) в трейс, без всякой там доп. идентификации стейтмента ?
Т.е. просто показывать что-то типа этого:
Код: plaintext
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.
2014-08-04T13:47:40.1200 (18377:0x7f3ca4739300) EXECUTE_ SINGLE _STATEMENT_FINISH
        oltp30 (ATT_1834, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2332
                (TRA_161283, CONCURRENCY | WAIT | READ_WRITE)

 Unit: MY_POOR_PROCEDURE, row: 150, col: 10 
-------------------------------------------------------------------------------
select count(*) from tsour into n
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    -> Table "TSOUR" Full Scan
0 records fetched
 12518 ms, 109217 read(s), 15802049 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TSOUR                             4999850


. . . . . . . .

2014-08-04T13:47:52.1360 (18377:0x7f3ca4739300) EXECUTE_ SINGLE _STATEMENT_FINISH
        oltp30 (ATT_1834, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2332
                (TRA_161283, CONCURRENCY | WAIT | READ_WRITE)

 Unit: MY_POOR_PROCEDURE, row: 156, col: 10 
-------------------------------------------------------------------------------
insert into ttarg(id, s01) select id, s01 from tsour
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    -> Table "TSOUR" Full Scan
0 records fetched
 15418 ms, 1217 read(s), 217255 write(s), 158022049 fetch(es), 35807862 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TSOUR                             4999850
TTARG                                                           4999849             4999849
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713098
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис> а статистику то по ним как выводить?

Так со статистикой и щас вроде нет проблем или как?

> При выполнении на самом деле это каждый раз новый курсор на новую запись.

Не понял. В простом случае при выполнении реально всего
один курсор. В сложных случаях возможны варианты, наверное.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713129
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНеужели нельзя вытряхивать такую же инфу (номер строки + столба) в трейс, без всякой там доп. идентификации стейтмента ?
Т.е. просто показывать что-то типа этого :
ты сам себе противоречишь. Как выводить стейтмент, если нет исходников процедуры? Что выводить на месте стейтмента, если на заданной строке стоит одно лишь слово select? Парсить до ближайшей точки с запятой? Чтобы трейс еще сильнее тормозил?
...
Рейтинг: 0 / 0
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
    #38713145
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrКак выводить стейтмент, если нет исходников процедуры?Хм... А куда они делись ? Если их разраб приложения грохнул, то проблема индейцев, чего её тут обсуждать ?

dimitrЧто выводить на месте стейтмента, если на заданной строке стоит одно лишь слово select? Парсить до ближайшей точки с запятой? Чтобы трейс еще сильнее тормозил?Трейс и сейчас выполняет вывод кода стейтмента, который может быть достаточно длинным - и ничего, не помер никто.
Но даже если опасаться тормозов от парсинга, то вывод всего лишь "координат" (номера строки и столба) - и того достаточно:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2014-08-04T13:47:40.1200 (18377:0x7f3ca4739300) EXECUTE_ SINGLE _STATEMENT_FINISH
        oltp30 (ATT_1834, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2332
                (TRA_161283, CONCURRENCY | WAIT | READ_WRITE)
 Unit: MY_POOR_PROCEDURE, row: 150, col: 10 
select count(*) from tsour into n
Select Expression
    -> Table "TSOUR" Full Scan
0 records fetched
 12518 ms, 109217 read(s), 15802049 fetch(es)
Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
TSOUR                             4999850

PS. А еще я бы выкинул к ЧМ все эти "^^^^^^^^^^^^^^^^^^^" и "***********************". Уж от них-то точно никакой пользы, вывод только засоряют.
...
Рейтинг: 0 / 0
25 сообщений из 69, страница 2 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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