|
|
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Ситуация следующая. При вставке записи в определенную таблицу, сробатывает не слабый триггер, который добовляет множество записей в ряд других таблиц. Выполняется такой запрос долго и в итоге вылазит ошибка с кодом 693 335544663, что интерпритируется как Too many concurrent executions of the same request. Работаю через IBX Я пробовал задать в IBTransaction1.IdleTimer очень большое значение, например 1000000, но это не помогает. Кто нить знает, как можно решить эту проблему? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 15:28 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А не циклится ли тригер? Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 16:39 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Это ж сколько записей надо вставить чтобы такое вылезло? !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 16:40 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Я один раз папку саму в себя стал копировать ... красиво получилось! Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 16:42 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Да, поподробнее, пожалуйста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 16:42 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А с чем может быть связано очень долгое выполнение (зависание? не хватило терпения ждать больше 15ти минут ;P), с небольшой (~5%) при этом загрузкой процессора, следующего запроса : create view q1 (ID, ORGNAME, SERVICEPERCENT) as select distinct a.ID, a.ORGNAME, a.SERVICEPERCENT from INTERMED a, ORD b where ((a.ID = b.ID) and (b.DATEJOIN >= :D1 and b.DATEJOIN <= :D2 )) UNION ALL select distinct a.ID as ID, a.ORGNAME as ORGNAME, a.SERVICEPERCENT as SERVICEPERCENT from INTERMED a, FULFILDOC c, ORDITEMSTATE d, ORD e where ( (a.ID = e.ID) and (d.ORDNUM = e.NUM) and (c.NUM = d.FFDOCNUM) and (c.FFDOCT = 'L' OR c.FFDOCT = 'R') and (c.INPDATE >= :D1 and c.INPDATE <= :D2 ) ) на БД ~10тиметрвого объема ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2003, 18:09 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Ну во первых сам запрос очень тяжёлый (DISTINCT). Во вторых могут быть неправильно построены или использованы индексы и в третих - мог просто мусор из базы удаляться, к апримеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2003, 18:43 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
С индексами вроде всё ок... База сейчас локальна и зависание повторяется при повторных запусках - не мусор.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2003, 19:23 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А попробуй выполнить оба эти запроса не через view а напрямую.... И сначала без distinct-а, а потом с distinct-ом. И все время смотри планы запросов... Кстати, попробуй перед эти провести validation с Record Fragment.Enabled:=True. Небось без Forced write работаешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2003, 20:41 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Без создания viewa выполняется нормально.. Кстати, попробуй перед эти провести validation с Record Fragment.Enabled:=True. Небось без Forced write работаешь. Как (чем) проводится validation и где прописывается forced write ?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 13:18 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
- IBConsole - регистрируешь локальный сервер - подключаешься кнему - регистрируешь свою базу - правой мышкой по базе, пункт меню Validation - подключаешся к базе - правой мышкой по базе, пункт меню Properties, вкладка General, внизу Forced Writes ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 13:32 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Validation проходит нормально, forced writes был и остается enabled. Виснуть сейчас перестало, но viewы создает _пустые_ хотя соответствующие им запросы прекрасно выполняются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 14:47 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Выполняются с нормальным ненулевым результатом. Просто там для отчета выбираются данные в несколько viewов и потом сливаются в одну табличку. Курсоры в IB 7.0 я не нашел как заставить работать, делать все в виде одного запроса будет слишком (монстровая такая структура получится ) ), viewы выглядят тут наиболее естественно... Но не работают) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 14:53 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Вот нафига View использовать? Есть же ХП!!! Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 15:00 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Viewы проще и для отчетов их наиболее естественно использовать Если б работали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 15:24 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Мда.. оказывается внутри viewов нельзя использовать cast() : убрал - заработало Дурдом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 15:57 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
ХП - тот же View, только там можно использовать все что угодно и как угодно! Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 17:03 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А удалить ХП после работы прога сможет? Синтаксис запроса подскажите если да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 17:32 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Можно, но зачем? ХП пишется один раз и навсегда. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 17:40 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Только надо провильно установить типы для ID INTEGER, ORGNAME, SERVICEPERCENT Код: 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. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 18:00 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Удалять надо чтобы базу не засорять - отчет это дело клиентского приложения и если требования к нему изменятся, то хотелось бы при этом изменить только саму программу, и не лезть в базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 18:10 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
hyh Ну тогда удаляй себе на здоровье! DROP PROCEDURE NEW_PROCEDURE; Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 10:27 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
>этом изменить только саму программу, и не лезть в базу А "create/drop procedure" это не лазание в базу :) Еще вы явно нестрадаете предубежденностью в вопросе о модификации метеденных. Вообще конечно интересный подход с точки зрения оптимизации. IMHO оправдан только если (компиляция SP)+(запись в метаданные) дольше чем (построение плана для запроса) А такое возможно только для очень сложного запроса выполняемого более 1 раза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 11:00 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Лазание при изменении постановки задачи)) А когда на клиенте в начате работы программки она создается, в конце удаляется, то для изменения трогается только программа, а не сама база. К тому же прога в дальнейшем будет работать с несколькими базами, каждая из которых и так немаленькая и с десятком-другим процедур ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 11:46 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А про запросы.. Ну сами напросились) Основной : select q1.ID, q1.ORGNAME, q1.SERVICEPERCENT, q2.ZT, q3.CC, qL.LT, qR.RT from q1 full outer join q2 on (q2.ID = q1.ID) full outer join q3 on (q3.ID= q1.ID) full outer join qL on (qL.ID= q1.ID) full outer join qR on (qR.ID= q1.ID) order by q1.ID _____ create view q1 (ID, ORGNAME, SERVICEPERCENT) as select distinct a.ID as ID, a.ORGNAME as ORGNAME, a.SERVICEPERCENT as SERVICEPERCENT from INTERMED a, ORD b where ((a.ID = b.ID) ) UNION select distinct a.ID as ID, a.ORGNAME as ORGNAME, a.SERVICEPERCENT as SERVICEPERCENT from INTERMED a, FULFILDOC c, ORDITEMSTATE d, ORD e where ( (a.ID = e.ID) and (d.ORDNUM = e.NUM) and (c.NUM = d.FFDOCNUM) and (c.FFDOCT = 'L' OR c.FFDOCT = 'R') ) _____ create view q2 (ID, ZT) as select ID, sum(TOTAL) as ZT from ORD where (DATEJOIN not NULL) group by ID _____ create view q3 (ID, CC) as select ID, count (DISTINCT CLNUM) as CC from ORD where DATEJOIN not NULL group by ID _____ create view qL (ID, LT) as select a.ID, sum (b.TOTAL) as LT from INTERMED a, ORDITEM b, FULFILDOC c, ORDITEMSTATE d, ORD e where ( (a.ID = e.ID) and (d.ORDNUM = e.NUM) and (b.ITEMNUM = d.ITEMNUM) and (b.ORDNUM = d.ORDNUM) and (c.NUM = d.FFDOCNUM) and (c.FFDOCT = 'L') ) group by a.ID _____ create view qR (ID, RT) as select a.ID, sum (b.TOTAL) as RT from INTERMED a, ORDITEM b, FULFILDOC c, ORDITEMSTATE d, ORD e where ( (a.ID = e.ID) and (d.ORDNUM = e.NUM) and (b.ITEMNUM = d.ITEMNUM) and (b.ORDNUM = d.ORDNUM) and (c.NUM = d.FFDOCNUM) and (c.FFDOCT = 'R') ) group by a.ID _____ Вызываться основной запрос будет несколько раз подряд (просмотр отчетов за разные периоды) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 11:53 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
А да, и в конце каждого проверки конечно) по дате create view q1 (ID, ORGNAME, SERVICEPERCENT) as select distinct a.ID, a.ORGNAME, a.SERVICEPERCENT from INTERMED a, ORD b where ((a.ID = b.ID) and (b.DATEJOIN >= :D1 and b.DATEJOIN <= :D2 )) UNION select distinct a.ID as ID, a.ORGNAME as ORGNAME, a.SERVICEPERCENT as SERVICEPERCENT from INTERMED a, FULFILDOC c, ORDITEMSTATE d, ORD e where ( (a.ID = e.ID) and (d.ORDNUM = e.NUM) and (c.NUM = d.FFDOCNUM) and (c.FFDOCT = 'L' OR c.FFDOCT = 'R') and (c.INPDATE >= :D1 and c.INPDATE <= :D2 ) ) и тп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 11:55 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Ну что ? Все это можно сделать в одной процедуре и все будет достаточно быстро работать. P.S. Код: 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. Это совсем одинаковые запросы !!! Можно использовать параметр процедуры: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 12:02 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Я в курсе что почти одинаковые - я так и писал для единообразия) Про сделать я не сомневаюсь, а вот насчет быстроты.. В написанном виде он вообще виснет с 100% загрузкой... При замене full outer на left outer минут через 5 отвисает и выдает "EIBInterBaseError .. 'conversion error from string '' ''' " (2 пробел 3) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 12:31 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Если правильно организовать ХП и проанализировать планы запросов, то скорее всего выполнение процедуры будет занимать не больще пары минут. А сколько примерно записей в таблицах ? Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 12:46 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
300, 500 - в таком духе; больше 1000 вроде пока нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 13:06 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Вау! Да тут можно и в 1 минуту вписаться без проблем! Пишите ХП и проблем не будет. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 13:28 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Кстати говоря, вот в этом вашем запросе Код: 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. куда попадает результат первого selecta ? И можно ли как-нибудь кроме юниона реализовать исключение повторений в двух частях этого запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 18:53 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Прошу прощение я пропустил INTO :ID, :ORGNAME, :SERVICEPERCENT НО лучше использовать UNION. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2003, 19:01 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Если кому вдруг станет интересно, в результате получилось следующее : Код: 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. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 13:51 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Как быстро то работает ??? Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 13:59 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Возник вопрос о возможности проверки существования в базе объекта метаданных с таким-то именем. Перед созданием процедуры хотелось бы проверить ее существование (она удаляется в конце, но программа может завершится и некорректно..) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 14:01 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Работает вполне нормально - в пределах полуминуты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 14:02 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Есть системная табличка : RDB$RELATIONS , там описаны метаданные Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 14:17 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
И какой примерно синтаксис запроса к этой табличке о существовании какого-то объекта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 14:42 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
В описанном случае просто хотелось бы сделать проверки перед созданием и удалением процедуры И както сообщить Дельфям об их результате, чтобы по нему пускать или нет соответствующий IBSQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 14:46 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
SELECT 1 FROM RDB$PROCEDURES WHERE RDB$PROCEDURE_NAME = 'PROC_NAME' Если вернет 1 - значит есть такая Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2003, 15:02 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Код: 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. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. Немного мутировавшая, уже упоминавшаяся процедура теперь изволит работать на 20ти метровых базах, но виснет на 430метровой с той же структурой.. Причем как при вызове из проги, так и при прямом исполнении из SQLexplorera и IBExperta ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2003, 16:58 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2003, 17:16 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
PLAN JOIN (E INDEX (XAK1ORD),D INDEX (XPKORDITEMSTATE,XIF217ORDITEMSTATE),B INDEX (XPKORDITEM,XIF85ORDITEM),C INDEX (RDB$PRIMARY46)) JOIN (E INDEX (XAK1ORD),D INDEX (XPKORDITEMSTATE,XIF217ORDITEMSTATE),B INDEX (XPKORDITEM,XIF85ORDITEM),C INDEX (RDB$PRIMARY46)) JOIN (E INDEX (XAK1ORD),D INDEX (XPKORDITEMSTATE),C INDEX (RDB$FOREIGN134,RDB$PRIMARY46),B INDEX (XPKORDITEM,XIF85ORDITEM)) JOIN (E INDEX (XAK1ORD),D INDEX (XPKORDITEMSTATE),C INDEX (RDB$FOREIGN134,RDB$PRIMARY46),B INDEX (XPKORDITEM,XIF85ORDITEM)) SORT (JOIN (A NATURAL,E INDEX (XAK1ORD),D INDEX (XPKORDITEMSTATE,XIF217ORDITEMSTATE,RDB$FOREIGN173,XIF217ORDITEMSTATE,RDB$FOREIGN173,XIF217ORDITEMSTATE,RDB$FOREIGN173),C INDEX (RDB$PRIMARY46))) Это план select * from rep_ph('1-10-2003','11-10-2003') Wondering откудова там sort :/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2003, 18:35 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Sort убирается после стирания distinct'a но NATURAL при этом остается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2003, 18:54 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
На мелких базах(20тиметровых) performance editor показывает ~12000 индексированных и 120 неиндексированных запросов для select * from rep_ph('1-10-2003','11-10-2003') Без distincta и соответственно без sorta на большой базе виснет так же, natural тоже, видимо, ни при чем : >1% запросов вряд ли сильно замедляют... Ф чём же может быть проблема?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2003, 12:55 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Мне кажется что дело может быть в UNION. Сейчас посмотрю что у меня получается на 600 метрах ... Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2003, 14:01 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
hyh Поставь счетчик и по достижению N вызывай Exit !!! Кстати UNION тут совсем не причем ... Можно попробовать поиграть с порядком JOIN. Странно, но у меня NATURAL не возникает. Попробуй посмотреть что получается вот с эти запросом ... заковыка в нем : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2003, 14:43 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Вопщем я в полных непонятках.. Видимо это баг какой-то :/ Сделал 2 процедуры: Код: 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. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 0я выполняется ~50 секунд на 430метровой базе и честно выдает 2 записи 1я на той же базе нафик виснет Причем для таблички INTERMED(которая там по сравнению с остальными очень небольшая) упорно не желает использовать индексы, и те которые там есть, и те, что я создавал руками... Вроде бы ну и ладно - как было написано выше, т.о. неиндексированными получаются < 1% запросов к базе, но в чем же тогда то проблема? Вот уже полчаса IBExpert пытается дождаться выполнения 1й процедуры... Не создает ли оно там декартово произведение этих табличек если запрос к одной неиндексирован?.. Это как-то неправдоподобно, только вот я еще не придумал, как еще объяснить такое поведение при выполнении 2х почти идентичных процедур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2003, 13:01 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Код: 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. А вот это работает так же в пределах 50ти сек и делает то же, что RP1 Бред around :| ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2003, 13:46 |
|
||
|
Выполнение очень долгого запроса.
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. Вот как это млин называется вообще :/ Ну какого он безиндексные запросы создает ... Кто это писал вообще ??) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2003, 15:46 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1579472]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
171ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 503ms |

| 0 / 0 |
