|
|
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitrреализовать это будет точно совсем не просто. Но главное - зачем? Каждая нода сможет накапливать в себе статистики своего выполнения для конкретного запроса самостоятельно и по запросу формировать свой кусочек плана с выдачей этих статистик. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:32 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, накапливает она и сейчас. Ибо на самом деле дерево выполнения ссылается на копию процедуры. Каждое дерево имеет свою копию, каждая копия имеет свои счетчики статистики. Проблема не в этом, а в том, что сейчас самый низкий уровень накопления статистики - риквест, копить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого, ибо таких элементов тупо в разы больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:37 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitrкопить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого, ибо таких элементов тупо в разы больше. Но и статистики там могут быть попроще: количество записей обработанных, подпавших под условие или отвергнутых, количество вообще обращений к ноде, входное условие (если было одно) и т.п. Большинство из этого - простые инкременты, делающиеся за один такт. На их основе могут делаться выводы об эффективности условий, их цены и т.п. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:47 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr, тогда не надо статистику пока. Ибо лишние тормоза не к чему. Достаточно и вот этого: - id курсора - ссылка на стейтмент - текст запроса курсора - план (explain) - тип курсора (однонаправленный или двунаправленный) - количество отфетченных записей (для двунаправленных наверное равняется общему кол-ву) - текущий номер записи (для двунаправленных это может быть полезно) - состояние курсора (активен или нет, правда я не знаю может быть как только курсор не активен он тут же пропадает) - используется ли блокировка (FOR UPDATE WITH LOCK) Тут ещё возникает ситуация когда один курсор крутится внутри другого можно ещё и дать ссылку на "родительский" курсор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:50 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Кстати. Раз уж тут разговор зашёл о мониторинге всех курсоров в том числе и тех что выполняются внутри ХП. То может и в трассировку такую информацию добавить и вот там уже выводить полную статистику? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 09:03 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, пока разговор идет лишь о том, надо ли такое вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 09:31 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr, пока против вроде никто не высказался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 09:41 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов Дениспока против вроде никто не высказался если это никому не надо, то и не выскажутся :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 09:51 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr, учитывая, что сейчас нет ни каких средств отладки/оптимизации SP, я думаю, что любые средства в этом направлении нужны всем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 14:08 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Alex Truhin, это точно нельзя отнести к отладке, даже насчет оптимизации я не уверен (без статистики, по крайней мере) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 14:21 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitrБыла мысль отдельной таблицей выводить все курсоры данного стейтмента (юзерского или кешированной процедуры), соответственно у каждого курсора свой план (блоб). Но тут надо подумать, что еще имеет смысл выводить для курсоров, только ради планов такой огород нет смысла городить... . . . боюсь, что вести полную статистику для каждого курсора будет слишком затратно . . . Проблема не в этом, а в том, что сейчас самый низкий уровень накопления статистики - риквест, копить ее еще ниже (на уровне курсора или ноды) - может выйти очень дорого, ибо таких элементов тупо в разы больше. Up!! Три "счастливых" дня было у меня, было у меня с трейсОм" (почти (С)). Я поднимаю тему, т.к. напоролся по полной программе на то, что один из стейтментов (inner join двух таблиц) в некоторой ХП время от времени выполнял natural-сканы большой таблицы. Причём делалось это не стабильно, а только когда статистика по индексам: 1) отсутствовала (т.е. на старте, когда база только что залита) 2) устаревала до какой-то степени, что в итоге приводило оптимизатор к неверному плану. И что бы понять, в где именно внутри ХП поменялся план, пришлось танцевать с бубном трое суток Доводы о том, что накапливать планы по каждому курсору слишком затратно, выглядят для мну теперь... как бы это помягче сказать... ладно, не буду - сами догадаетесь. У каждой группы разрабов всегда есть более-менее актуальная копия продакшена на отдельном хосте. Когда кто-то из них запускает трейс с установкой connect_id = <my_connect_id>, то даже при всех включённых опциях это мало повлияет на работу его коллег-разрабов (а не усеров! те вообще про это не узнают). Я совершенно не понимаю, как можно в нынешнем 3.х (в отличие от 2.х!) вести поиск проблемных мест в ХП, состоящей из нескольких отдельных стейтментов, каждый из которых в свою очередь вызывает другие ХП - и там тоже по несколшьку отдельных стейтментов, и т.д. 2 dimitr, hvlad: добавьте хотя бы в трейс ключик, позволяющий вываливать в лог все генерируемые планы! Если еще и статистику по отдельным стейтментам внутри ХП/функций/триггеров сделаете - будет вообще супер. PS. Идея "отдельной таблицей выводить все курсоры данного стейтмента" - настораживает: это что, опять mon$-таблица будет ? Если да, то... может не надо, а ?... ;-Q PPS. Кстати: тикет в трекере есть на эту тему ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 19:00 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
ТаблоидЕсли еще и статистику по отдельным стейтментам внутри ХП/функций/триггеров сделаете - будет вообще суперДа, именно так. Потому что как иначе понять, на что ушли 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 19:10 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
подниму тему: Симонов ДенисДостаточно и вот этого: - id курсора - ссылка на стейтмент - текст запроса курсора - план (explain) - тип курсора (однонаправленный или двунаправленный) - количество отфетченных записей (для двунаправленных наверное равняется общему кол-ву) - текущий номер записи (для двунаправленных это может быть полезно) - состояние курсора (активен или нет, правда я не знаю может быть как только курсор не активен он тут же пропадает) тут возникает две проблемы, маленькая и большая: 1) Курсор с т.з движка это не то же самое, что с т.з. пользователя. В частности, подзапросы являются курсорами. Это можно видеть в планах любой версии ФБ - отдельная строчка PLAN на каждый подзапрос. Выводить в мониторинге подзапросы как курсоры - сильно не красиво. Можно попробовать в движке их как-то разделить, но что-то мне кажется это невозможным в общем случае - например, IF (A = (SELECT ... )) THEN - это курсор или нет? Если да, то почему WHERE EXISTS (SELECT ....) это не курсор? 2) Для внутренностей PSQL у нас нет текстов запросов. В лучшем случае, если все карты легли удачно - есть исходный текст всей процедуры и номер строки/столбца внутри нее. Но может и этого не быть. Как в итоге идентифицировать курсоры внутри mon$cursors - непонятно. Имя курсора можно выводить, но в подавляющем большинстве случаев оно отсутствует. Можно пытаться разобраться по планам, но это изврат. Что-то мне сильно не хочется делать бесполезную фичу, несмотря на первоначальную привлекательность :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:37 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr, да уж печально. Если ещё по первому пункту можно надеется что в будущих версиях часть подзапросов внутри SELECTов можно будет преобразовать в полу джойны, то по второму и сказать нечего. Можно в мониторинге хотя бы агрегированную статистику по курсорам показывать (сколько активно в данный момент, сколько всего было открыто)? Хотя полезность этой информации гораздо ниже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 13:02 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr, а ещё можно для запросов показывать сколько он контекстов задействовал, а то их расчёт не очевиден. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 13:05 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов Денисможно надеется что в будущих версиях часть подзапросов внутри SELECTов можно будет преобразовать в полу джойны это далеко не все случаи подзапросов, самый проблемный - select (select ...) ... Симонов ДенисМожно в мониторинге хотя бы агрегированную статистику по курсорам показывать (сколько активно в данный момент, сколько всего было открыто)? пока не вижу в этом практического смысла Симонов Дениса ещё можно для запросов показывать сколько он контекстов задействовал, а то их расчёт не очевиден тоже не вижу смысла. Подгонять текст запроса под лимит - ущербная практика, проще сразу делить его на части и выносить их в процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 13:27 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitr> самый проблемный - select (select ...) ... А почему он проблемный, если не секрет? С т.з. отображения можно было бы и вполне понятно/удобно было бы рассматривать его как два "курсора" (в твоих терминах). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:03 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, dimitr наверное имел ввиду, что его в полуджойн не преобразовать. А если рассматривать как курсор, то он ведь будет открыт столько раз сколько записей в запросе верхнего уровня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:10 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамА почему он проблемный, если не секрет? во-первых, его никак не преобразуешь. Во-вторых, внутри движка нет понятия "select list". Данный подзапрос будет подставлен как выражение там, где идет обращение к нему по имени. И привязать его к "родительскому" курсору может быть затруднительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:25 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов Денис> он ведь будет открыт столько раз сколько записей в запросе верхнего уровня С какой стати? Пусть будут два некореллированный/материализованный курсор. Или просто два независимых, если некореллированный трудно отобразить. Впрочем, даже после объяснения ДЕ я нихрена не понял, в чём проблема, так что ХЗ. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:28 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамС какой стати? Пусть будут два некореллированный/материализованный курсор. Или просто два независимых, если некореллированный трудно отобразить. а статистику то по ним как выводить? При выполнении на самом деле это каждый раз новый курсор на новую запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:35 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисДостаточно и вот этого: . . . - ссылка на стейтмент . . . - план (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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:42 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
Симонов Денис> а статистику то по ним как выводить? Так со статистикой и щас вроде нет проблем или как? > При выполнении на самом деле это каждый раз новый курсор на новую запись. Не понял. В простом случае при выполнении реально всего один курсор. В сложных случаях возможны варианты, наверное. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:42 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
ТаблоидНеужели нельзя вытряхивать такую же инфу (номер строки + столба) в трейс, без всякой там доп. идентификации стейтмента ? Т.е. просто показывать что-то типа этого : ты сам себе противоречишь. Как выводить стейтмент, если нет исходников процедуры? Что выводить на месте стейтмента, если на заданной строке стоит одно лишь слово select? Парсить до ближайшей точки с запятой? Чтобы трейс еще сильнее тормозил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 14:58 |
|
||
|
ФБ 3.0: при вызове ХП перестал показывать нормальный план. Требую вернуть взад!
|
|||
|---|---|---|---|
|
#18+
dimitrКак выводить стейтмент, если нет исходников процедуры?Хм... А куда они делись ? Если их разраб приложения грохнул, то проблема индейцев, чего её тут обсуждать ? dimitrЧто выводить на месте стейтмента, если на заданной строке стоит одно лишь слово select? Парсить до ближайшей точки с запятой? Чтобы трейс еще сильнее тормозил?Трейс и сейчас выполняет вывод кода стейтмента, который может быть достаточно длинным - и ничего, не помер никто. Но даже если опасаться тормозов от парсинга, то вывод всего лишь "координат" (номера строки и столба) - и того достаточно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. PS. А еще я бы выкинул к ЧМ все эти "^^^^^^^^^^^^^^^^^^^" и "***********************". Уж от них-то точно никакой пользы, вывод только засоряют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 15:09 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38712931&tid=1563416]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
172ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 473ms |

| 0 / 0 |
