Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Открыть новую тему     Написать ответ в эту тему

miwa

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
russko
Дополню абсолютно правильные уточнения chAlx еще одним:
 
2.5 Покажите результат выполнения комманды
 show table npc_active_dv_temp
в isql, либо же весь текст кроме комментариев из вкладки ddl в IBExpert.
 
chAlx

Цитата:
На ЭсКуЭльРу же принято красоваться друг перед другом, изысканно обсирая нубов, но ни в коем случае не объяснять, что неправильно и как исправить. По-меньшей мере это характерно для ветки про Interbase.  

На скуль.ру отвечают в основном достаточно компетентные люди, которые предполагают, что у спрашивающего есть минимальные понятия о том, о чем он спрашивает. Не более и не менее. Или у вас есть ссылка, где на заданный вопросс не был дан конкретный ответ или не менее конкретный уточняющий вопросс?
 

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

Ну и с этого места - можно поподробнее? Просто интерессно стало - когда я такое веселье пропустил.
 
OXDBA

Цитата:
Ставлю на FetchAll  = ~ 2 часа

Ну, если натираем хрусталь, то я, пожалуй, поддержу версию ant0ni02004 насчет тригеров
 
 
xpin2013

Цитата:
. Я очень уважаю miwa и знаю его давно, ещё с прошлого моего ника (не хочу светить - адвансом был

Спасибо. Если что, я знаю и ваш предыдущий ник и помню вас на скуле. Поэтому пользуясь случаем хочу сказать, что на вас иногда находит довольно серьезное косноязычие и понять написанное решительно невозможно. Не знаю, могло ли это быть причиной бана, но это точно было причиной одного обмена публичными сообщениями "на грани фола" между нами здесь, на руборде.

Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 23:52 27-11-2014
chAlx

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
miwa

Цитата:
На скуль.ру отвечают в основном достаточно компетентные люди, которые предполагают, что у спрашивающего есть минимальные понятия о том, о чем он спрашивает. Не более и не менее. Или у вас есть ссылка, где на заданный вопросс не был дан конкретный ответ или не менее конкретный уточняющий вопросс?  

Блин, открыл старые темы там -- как в повидле весь измазался...
 
Честно говоря, это было давно. И даже не один раз: уходил, через несколько лет приходил -- всё так же, всё те же. Я даже у администрации пытался выяснить, должно ли так быть или ошибка какая-то. Но им было в общем-то пофигу.
 
Вот, например, один из типичных примеров, и с моим участием (просто открыл одну из последних тем, где отписывался). Сценарий стандартный:
 
Нуб или простой DBA, у которого, как у любого, остались где-то пробелы в знаниях, приходит эти пробелы заполнить на примере своего практического вопроса. Умники лениво отстреливаются дежурными "наводящими вопросами", не упуская шанса поглумиться над тупым автором. При первом же шансе съехать на что-то менее актуальное, но более интересное, про изначальный вопрос забывают и начинают перетирать отвлечённые темы. При этом отчаянно лажают, но не подают виду (а скорее всего, с высоты своего полёта даже не допускают такой вероятности). Автора достают в край, он ругается и уходит. Аксакалы потирают руки, довольные, что наставили на путь ещё одну заблудшую душу. Отчасти, так и есть: души находят пристанище в более приличных местах.

Всего записей: 1691 | Зарегистр. 19-03-2003 | Отправлено: 03:13 28-11-2014
russko



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Перевожу вопросы, не раскрытые в постановке задачи:
 
1. select count(*) from npc_dv(-1,-1,2,2) как долго выполняется?
 
2. Какие у npc_active_dv_temp есть индексы и триггеры? И как она вообще создаётся -- временная, в отдельном файле или нормальная?

 
1. Данный запрос, как я говорил выше, выполняется около 5-ти минут.
 
2. У таблицы  npc_active_dv_temp нет не индексов, не триггеров. Это временная нормальная таблица-буфер, которая ежедневно чистится. Добавление различных индексов влияния не оказывает...
 
Структура таблицы npc_active_dv_temp
структура
 
После наполнения таблицы npc_active_dv_temp происходит перенос всех данных в рабочую npc_active_dv. Данная операция проходит секунд за 10-15.

Цитата:
 
insert into npc_active_dv
select * from npc_active_dv_temp;
 

Для чего был сделан именно такой алгоритм сказать трудно, проект достался в таком виде...вот и разбираемся.

Всего записей: 176 | Зарегистр. 20-07-2005 | Отправлено: 07:22 28-11-2014 | Исправлено: russko, 07:23 28-11-2014
exteris

Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
1. Данный запрос, как я говорил выше, выполняется около 5-ти минут.  

Вы говорили про select * from ...
А вас спросили за select count(*) from ...

Всего записей: 382 | Зарегистр. 14-04-2003 | Отправлено: 08:14 28-11-2014
russko



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Вы говорили про select * from ...
А вас спросили за select count(*) from ...  

 
Виноват...слеповат к старости стал ))
Запрос на count выполняется также чуть больше 2-х часов.

Всего записей: 176 | Зарегистр. 20-07-2005 | Отправлено: 08:45 28-11-2014
exteris

Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Вооот, OXDBA прав.
В случае когда запрос выполняется 5 минут, вычитываются не все данные, а только первая порция. А на все уходит 2 часа.

Всего записей: 382 | Зарегистр. 14-04-2003 | Отправлено: 09:23 28-11-2014
russko



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
В случае когда запрос выполняется 5 минут, вычитываются не все данные, а только первая порция. А на все уходит 2 часа.  

Это конечно понятно...вопрос тогда состоит в следующем - каким образом можно еще ускорить запрос передачи данных из ХП в таблицу. Саму хранимую процедуру уже оптимизировали как смогли ((( Может есть какие-то нюансы, о которых в силу своей нубости я не знаю?

Всего записей: 176 | Зарегистр. 20-07-2005 | Отправлено: 09:32 28-11-2014
exteris

Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Скорость передачи данных тут не при чем. Всё упирается в скорость выполнения процедуры.
 
Добавлено:
Можете, кстати, привести ее здесь+DDL+планы выполнения. Может чего и подскажут.

Всего записей: 382 | Зарегистр. 14-04-2003 | Отправлено: 10:33 28-11-2014
miwa

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
russko

Цитата:
вопрос тогда состоит в следующем - каким образом можно еще ускорить запрос передачи данных из ХП в таблицу. Саму хранимую процедуру уже оптимизировали как смогли ((( Может есть какие-то нюансы, о которых в силу своей нубости я не знаю?

Надо тогда полный текст процедуры. Дьявол ведь - он в деталях.
 
Если полный текст - коммерческая тайна, тогда максимально точное описание того, что она делает.
 
chAlx

Цитата:
Вот, например, один из типичных примеров, и с моим участием (просто открыл одну из последних тем, где отписывался). Сценарий стандартный:  

Ух, голова моя-головушка...
 
Вижу полностью некомпетентного человека, который пытается администрировать базу данных на несколько сотен одновременных подключений. Ему задают вопросы (в том числе и лично вы; вопросы компетентные и при наличии ответов можно пытаться помочь человеку), сбрасывают ссылку на похожие проблемы. Отдельно один учасник форума пытается троллить другого (не ТС-а). Плюс не забываем контекст - ТС уже один раз успел всем поднадоесть другим топиком о выборе сервера парой дней раньше. И во всей этой карусели ни одного ответа от человека, которому нужна помощь - только "да смотрю я, все нормально" и сразу же "ладно, я ухожу, вы все плохие".
 
Где там наезды на ТСа ДО ТОГО как он сам начал обижаться? И где попытки ТСа разобраться в его же проблеме?
 
Вот тогда паралель. У пользователя russko здесь тоже проблема с производительностью. Мы тоже задаем ему вопросы, пытаемся гадать на хрустальном шаре. Паралельно обсуждаем какие-то посторонные темы; старожилы по-дружески толкают друг друга. Если при этом russko вдруг решит, что "все, ладно, пошли вы все" - реакция тоже может быть разной. Правда, отличие есть: russko отвечает на вопросы и пытается разобраться в своей проблеме

Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 10:35 28-11-2014
russko



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Надо тогда полный текст процедуры. Дьявол ведь - он в деталях.
 
Если полный текст - коммерческая тайна, тогда максимально точное описание того, что она делает.  

 
Прикладываю скрипт процедуры...тайны особой, кроме интеллектуальной нет ))
Процедура
 
Проблема очевидно кроется во втором подзапросе. Без него все выполняется в считанные минуты.
Подзапрос
 
Добавлено:

Цитата:
Правда, отличие есть: russko отвечает на вопросы и пытается разобраться в своей проблеме

 
Я бы может и забил на это...но кол-во записей, выводимых данной процедурой, растет ежедневно на 100-200 и следовательно времени на обработку тратиться все больше и больше. Скоро можно придти к ситуации, когда и ночи не хватит на выполнение и пополнение (

Всего записей: 176 | Зарегистр. 20-07-2005 | Отправлено: 10:47 28-11-2014 | Исправлено: russko, 10:55 28-11-2014
exteris

Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
Проблема очевидно кроется во втором подзапросе.

Ну так и продолжайте выцеплять, что в это подзапросе тормозит.  
Лично меня смущают множественные подселекты, типа - ,(select RESULT_SUMMA from NPC_SCHETA_OPL_NEOPL(NSz.ID,1,2,null,NSz.summa_v_valute_sch)) OPLACHENO_PROCENTOV

Всего записей: 382 | Зарегистр. 14-04-2003 | Отправлено: 11:09 28-11-2014
miwa

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
russko

Цитата:
Проблема очевидно кроется во втором подзапросе. Без него все выполняется в считанные минуты.

Тогда выполните только этот подзапрос, выполните его и покажите его план выполнения и статистику (все что выводит ИБексперт после выполнения запроса в нижней части экрана).

Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 11:22 28-11-2014
russko



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Спасибо всем за участие...навели на путь истинный )
Причина всех тормозов получается в двух таблицах, в которых программист напихал кучу вычисляемых полей..даже простой фэтч по любой из этих таблиц происходит крайне долго.
 
Теперь буду искать где эти поля используются и как от них отказаться...если конечно получится (

Всего записей: 176 | Зарегистр. 20-07-2005 | Отправлено: 11:56 28-11-2014
miwa

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ну это надо очень постараться, чтобы вычисляемыми полями затормозить простую выборку. Дело ваше, но я бы таки посмотрел на DDL этой таблицы, а также на статистику и план обсуждаемого запроса. Возможно, еще пара путей найдется. Всегда лучше больше путей, чем меньше

Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 13:34 28-11-2014
chAlx

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

miwa:

Цитата:
Вижу полностью некомпетентного человека, который пытается администрировать базу данных на несколько сотен одновременных подключений.

А все люди в чём-то некомпетентны. (Sic: 300 не одновременных подключений, а всего клиентов.) Есть такие, кто тупит и разбираться не хочет, а есть просто неопытные. На том форуме принято заранее считать всех тупыми: мол, не смог решить квесты и продраться через строй насмешников -- не очень-то и хотел. Это не всем подходит и едва ли может считаться нормой.
 
Наводящие вопросы должны помогать разобраться, а не иллюстрировать, какой автор недоумок, раз не знает про тонкости реализации разных версий сервера, которые знают все 10 местных завсегдатаев (половина, по-совместительству, пишет код сервера или статьи про него). Если намёк, понятный своим, непонятен адресату -- скорее всего, он неправильно сформулирован. А точнее, он вообще написан, чтобы между собой поржать над тупицей, а не чтобы помочь.
 

Цитата:
Отдельно один учасник форума пытается троллить другого (не ТС-а). Плюс не забываем контекст - ТС уже один раз успел всем поднадоесть другим топиком

А не надо троллить, переходить на личности, учитывать контекст не относящихся к теме топиков, учить жить. Для этого есть другие разделы.
 

Цитата:
Мы тоже задаем ему вопросы, пытаемся гадать на хрустальном шаре.  

 
Ответ в стиле sql.ru:
  • Ставлю на FetchAll  = ~ 2 часа
    Это вообще не ответ на вопрос, это как бы обращение к окружающим ("своим"). Да, прошаренному пользователю оно может помочь, но если не помогло -- это не значит, что он лишается права на помощь. И так понятно, что самые прошаренные таких вопросов не задают.
    Хотя в единичном намёке нет ничего плохого, если после него не разворачивается троллинг про то, "как можно не допереть до тривиальных вещей, когда уже тыкнули носом". Здесь вот последовали уточнения и решение проблемы, на sql.ru скорее всего никто бы не удосужился "разжевать очевидную истину". Наводку не осилил -- лох. А вот это надо тут же обсудить -- на фоне нубов легко казаться асом.
     
    Сравни с нормальными ответами:
  • попробуйте перед запуском процедуры это всё отключать а после - включать  
  • Вы говорили про select * from ... А вас спросили за select count(*) from ...
    Это -- конкретные действия, которые можно реально выполнить и продвинуться в решении. Не все попадают пальцем в небо, но и в личность ТСа вообще не тыкают. А на флуд на РуБорде модераторы реагируют чётко, а не "пусть тешатся, они же ветераны".
     
     
    Просто надо понимать, что IT -- тема реально сложная. Да, очень интересно общаться с профессионалами, узнавать от них что-то новое. Но объективная реальность такова, что профессионалы далеко не все.  Если не хочешь с такими общаться -- сиди и помалкивай, никто не тянет. Если полез отвечать -- сделай так, чтобы помочь автору решить заданный вопрос, а не осознать свою ничтожность. В конце-концов, такие площадки в сети создаются в первую очередь для взаимопомощи (и извлечения прибыли из уникального трафика), а потом уж для пустого трёпа завсегдатаев.
     
    В IT постоянно встречаются системы с сотнями переменных факторов. Даже опытному специалисту непросто сформулировать вопрос и перечислить все нужные для ответа условия, не вытаскивая простыню лишних. Да и мало кто станет решать (да и ставить) задачи типа "вот дамп моей виртуалки, что-то тормозит" -- всем подавай локализованную проблему. Поэтому абсолютное большинство пользователей поначалу задаёт вопросы некорректно: очевидно, что раз вопрос возник, то автор не настолько разбирается в теме, чтобы угадать все параметры сразу. И это нормально.

  • Всего записей: 1691 | Зарегистр. 19-03-2003 | Отправлено: 16:54 28-11-2014 | Исправлено: chAlx, 16:57 28-11-2014
    ant0ni02004

    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    russko
    вряд ли дело в вычисляемых полях (если мы об одном и том же говорим)
    скорее дело в большом кол-ве подзапросов из второго запроса, типа вот таких (я уже не говорю о простых типа SUM())
     
         ,(select RESULT_SUMMA from NPC_SCHETA_OPL_NEOPL(NSz.ID,1,2,null,NSz.summa_v_valute_sch)) OPLACHENO_PROCENTOV  
     
            ,(select min(Data_Opl) from NPC_Scheta_Oplata nso where nso.Schet_ID=nspz.Schet_ID ) DATA_OPL_FIRST  
     
            ,(select case when max(Data_Opl)<>min(Data_Opl) then max(Data_Opl) end from NPC_Scheta_Oplata nso where nso.schet_ID=nspz.Schet_ID ) DATA_OPL_LAST  
     
    попробуйте их по одному "выключать" (напр. ,0.000 OPLACHENO_PROCENTOV ) и увидите, что же реально тормозит. а потом будет видно как ускорить - или индекс добавить, или получать в цикле, или даже хранить результаты в таблице
     

    Всего записей: 442 | Зарегистр. 26-10-2004 | Отправлено: 19:40 28-11-2014
    xpin2013



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    miwa

    Цитата:
    Спасибо. Если что, я знаю и ваш предыдущий ник и помню вас на скуле. Поэтому пользуясь случаем хочу сказать, что на вас иногда находит довольно серьезное косноязычие и понять написанное решительно невозможно. Не знаю, могло ли это быть причиной бана, но это точно было причиной одного обмена публичными сообщениями "на грани фола" между нами здесь, на руборде.

    Скорее всего Вы не правы. На sql.ru кто-то начал светить мои личные данные и тролить по этому поводу. Я был выпивший и не зная что так принято высказался грубо. К личным данным я отношусь следующим образом. В 1993 году я решил что я больше не хаккер. В 1994 написал свой архиватор. После этого я взломал всего 2 программы. Одна из них моя собственная, я потерял исходники, а они были зашифрованы в этой программе. На ru-board отказались её ломать - объяснили "грязные технологии". Все формы программы были зашифрованы. Но в моей программе был JCL дебаг для лога экзепшена. Я написал программу которая вытаскивает этот лог и нашёл функцию IsFebruary4. Тут то я её и хакнул, но защита действительно сложная. Я не хаккер. Личные данные я уважаю. И я считаю что айтишник который взламывает программы, пишет собственные архиваторы, пишет собственные TDataset (на что Вы и обиделись), такой человек не является нубом. И никакой завсегдатай sql.ru не выше его. Напишите в ветку Ассемблер, что Вы все нубы и не знаете sql. Полагаю их ответы смогут Вас просветить, кто действительно нуб в просторах интернета. Не обижайтесь, я Вас действительно уважаю - иногда Вы можете чудом натолкнуть на идею.
     
    chAlx
    Предлагаю прикрыть про sql.ru, они не стоят.
     
    Добавлено:
    miwa
    Да кстати новости, хотел поделиться. Я Вам предложил соавторство, так как Вы натолкнули на идею, но помнится Вы отказались. Так вот, в моём датасете теперь есть ForeigKeys. Но пока я не решил - индексы отдельно. ForeignField должна иметь уникальный иднекс, а FieldName тоже должна иметь индекс, на случай CASCADE или SET NULL. Ключи пока создаются только в оболочке DElphi, но vdbXplor их подхватывает. Плюс и я смог перейти на EhLib XE6. Так что мой простенький клиентдатасет всё ещё поживает. Всегда велком.

    Всего записей: 291 | Зарегистр. 16-01-2014 | Отправлено: 15:07 29-11-2014
    noisy

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    форумчане, вышла бета версия Firebird 3.
     
    багрепорты приветствуються. просьба прогнать на своих проектах.  
     
    Добавлено:
    не забываем что FB3 не допускает смешивать явный и неявный джоин
    т.е. запрос:
     Select * from table1, table2 inner join table3 on (table2.id = table3.id)
     
    не сработает на FB3
     

    Всего записей: 991 | Зарегистр. 30-05-2002 | Отправлено: 19:36 01-12-2014
    xpin2013



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    noisy
    Я почитал, что там наворочено. Этого за 10 лет не выучить - вот уж постарались. Особенно мне понравился update returning old.value new.value.
     
    Про триггер выяснилось случайно недавно, что у моего коллеги хранимая процедура когда ей дают в параметре null, она шарашит всю таблицу. Old.id в insert триггере null. Так что это не FireBird такой, это как обычно мы чуток кривоватые. Простите.

    Всего записей: 291 | Зарегистр. 16-01-2014 | Отправлено: 19:38 03-12-2014
    noisy

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Вышло обновление Firebird версии 2.1 и 2.5.

    Всего записей: 991 | Зарегистр. 30-05-2002 | Отправлено: 14:40 10-12-2014
    Открыть новую тему     Написать ответ в эту тему

    Страницы: 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 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

    Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru