База FB тормозит

← →
Ярослав (2005-06-01 07:54) [0]

Подскажите с какой частотой следует собирать статискику индексов, и перекомпилировать ХП.

Есть небольшая БД примерно 30МБ в таблицах примерно по 40000-60000 записей, и вот она переодически начинает тормозить, после сбора статистики индексов и перекомпиляции ХП и триггеров все нормально, но если раньше это приходилось делать раз в месяц а то и реже, то теперь каждую неделю... не слишком ли часто?

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

← →
Johnmen © (2005-06-01 09:08) [1]

>перекомпилировать ХП.

Это ещё зачем ? Кто надоумил ?
Временные таблицы - признак проблем в консерватории, как правило :)
Да и вообще, дело не в индексах, а в сборке мусора.
Читать от корки до корки ibase.ru

← →
Ярослав (2005-06-01 09:22) [2]

> Johnmen © (01.06.05 09:08) [1]

ibase.ru конечно прочитаю, но юзеры не ждут, они же порвут меня...

> перекомпилировать ХП.
> Это ещё зачем ? Кто надоумил ?

Это в IBExpert есть, помогает ведь... хоть на некоторое время.

> Временные таблицы - признак проблем в консерватории, как правило :)

Это как чейто не понял?

← →
Johnmen © (2005-06-01 09:26) [3]

>Ярослав (01.06.05 09:22) [2]
>Это в IBExpert есть, помогает ведь... хоть на некоторое время.

Это иллюзия.

>Это как чейто не понял?

Просчёты в проектировании.

А так, не хочешь читать, не читай. Мне то что...

← →
Ярослав (2005-06-01 09:38) [4]

> Это иллюзия.
Как иллюзия, когда запрос выполняеться в несколько раз быстрей.
В нормальном режиме он должен выполняться мгновенно, однако если начинает тормозить то дело может доходить до 30 и болие секунд, а после сбора статистики и перекомпиляции все возращаеться на свои места. Вот только делать это приходиться все чаще.
Но все таки 30 секунд это не иллюзия

Кстати если все дело в сборке мусора то Backup/Restore должно помочь?
Я конечно проверю, но неделю ждать долго до новых ожидаемых тормозов, хотелось бы быть уверенным.

← →
Johnmen © (2005-06-01 09:41) [5]

>а после сбора статистики и перекомпиляции все возращаеться на свои места.

Это ничего не доказывает. Убери второе и посмотри время.

>Кстати если все дело в сборке мусора то Backup/Restore должно помочь?

Должно.

← →
Ярослав (2005-06-01 09:45) [6]

> Убери второе и посмотри время.
Это перекомпиляцию надо пологать?

← →
stud © (2005-06-01 10:03) [7]

> Это перекомпиляцию надо пологать?

нет это временную таблицу

← →
Ярослав (2005-06-01 10:40) [8]

stud © (01.06.05 10:03) [7]
А при чем тут временная таблица?
Запрос раньше работал без нее и я прекрасно помню сколько он работал, дак использование временной таблици увеличило скорость выполнения аж более чем в 100 раз!!!
Возможно запрос был изночально не правильно спроектирован, но он есть и он огромный, страниц десят текста если его весь развернуть, включая все используемые XP. В нем производиться довольно сложный расчет.
Без временной таблицы он выполнялся приблицительно 3 мин. а с ней мгновенно.

← →
Desdechado © (2005-06-01 10:52) [9]

организуй сборку мусора планировщиком по ночам (gfix)
можешь для эксперимента вызывать select count(*) from vremennayatablica - тоже сбрасывает счетчики использования у удаленных записей

← →
Zacho © (2005-06-01 11:34) [10]

Desdechado © (01.06.05 10:52) [9]
можешь для эксперимента вызывать select count(*) from vremennayatablica

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

А "торможения", действительно, скорее всего из-за накопления мусора во "временной" таблице

← →
Prohodil Mimo © (2005-06-02 12:25) [11]

Ярослав (01.06.05 10:40) [8]

а временную таблицу на индексы нельзя заменить? Индексы тоже не слабо помогают.

← →
Desdechado © (2005-06-02 13:36) [12]

думаю, что логичнее запрос заменить на ХП, а временную таблицу - на FOR SELECT

← →
Zacho © (2005-06-02 16:09) [13]

Desdechado © (02.06.05 13:36) [12]

Поддерживаю :)

За 7 лет работы с IB/FB/Ya у меня ни разу не было действительной необходимости во "временных" таблицах.

← →
Ярослав (2005-06-03 06:41) [14]

>> Desdechado © (02.06.05 13:36) [12]
>> Zacho © (02.06.05 16:09) [13]

Запрос этот как раз и состоит из нескольких ХП (если все читать внимательно)
До использования временной таблицы как раз и было на основе For Select, замены на временную таблицу все стало (как я уже писал выше) в сто раз быстрее как минимум.

← →
Zacho © (2005-06-03 10:46) [15]

Ярослав (03.06.05 6:41) [14]

Возможно. Но всё-таки думаю, что можно было перепроектировать БД так, что бы и временных таблиц не было, и ХП быстро работали.

Ты "мусор" убирать пробовал ? Как результаты ?

← →
вп (2005-06-03 11:51) [16]

> Zacho © (03.06.05 10:46) [15]
> Ярослав (03.06.05 6:41) [14]
>
> Возможно. Но всё-таки думаю, что можно было перепроектировать
> БД так, что бы и временных таблиц не было, и ХП быстро работали.
>
> Ты "мусор" убирать пробовал ? Как результаты ?

Я конечно, извиняюсь.. Но как решить такую задачу без временной таблицы(учет оплаты посещения в д/с)... Есть перечень л/с, содержащий: остаток на начало периода, оплата, начисленно, выходной остаток..
И есть движение: движение об оплате, и движение по посещениям.. Причем по посещениям имеет такую структуру (примерно):
л/с, количество дней, ГРУППА, РЕЖИМ... Два последних выделил поодной простой причине - в течении рабочего периода ГРУППА и РЕЖИМ могут довольно произвольно менятся (перевод из одной грппы в другую).. Нужно получить оборотку в виде:
Группа
Л/с сальдо_Вх дней начисленно льготы оплачено исх_дт исх_кт
Т.е. Л/с может мелькать в разных группах.. И для разных групп - разная цена дня.. Сответсвенно, начисленно будет разным.. НО ВСЕ ЭТ ОПО РАЗНЫМ ГРУППАМ ДОЛЖНО "ЛЕЧЬ" НА ИСХОДЯЩИЙ ОСТАТОК Л/С !
Если просто обьединить - будут удвоены(утроены и тд) как входящие так и исходящие остатки... Я другого рещения, как анализ данных в промежуточной таблице не придумал...

← →
Johnmen © (2005-06-03 12:17) [17]

>вп (03.06.05 11:51) [16]

Напрасно. Здесь уже говорили о ХП.
А во-вторых, проблема "удвоены(утроены и тд)" таковой не является. Запросы надо грамотно писать...:)

← →
вп (2005-06-03 13:09) [18]

Таблица Л/с
Л/с Вх Оплата начисленно Исх
100 1,20 5,00 10,00 6,20

Причем начисленно: по 1-й группе 2,00 по 2-й 3,00 по 3-й 5,00
Нужно получить оборотку:
л/с Вх Оплаченно Начисленно Исх
Группа 1
100 1,20 5,00 2,00 -1,80
...
Итого по группе
ГРуппа 2
100 0,00 0,00 3,00 3,00
...
Итого по группе
Группа 3
100 0,00 0,00 5,00 5,00
...
Итого по группе

Итого по организации
Как это получить запросом/ХП ?

← →
stud © (2005-06-03 13:15) [19]

а где взять по какой группе начислено??????

← →
stud © (2005-06-03 13:16) [20]

в общем-то обычная группировка, а хп это реализуется элементарно.

← →
Sergey13 © (2005-06-03 13:36) [21]

2[18] вп (03.06.05 13:09)
А почему во 2 и 3 группах ВХ=0? Если оплата идет вперед, то остаток дожен переноситься. Если оплата после, то почему не держать ее отдельно для каждой группы? Или я не въехал в постановку?

ЗЫ: Вообще не дурно бы свою ветку завести наверное, раз пошло обсуждение другого вопроса.

← →
вп (2005-06-03 14:35) [22]

Суть в чем.. За ребенком числится № лицевого.. Родителям дается платежка, с №=№ л/с... И ему однохерственно, в какой группе ребенок был.. Ему дали: "Заплати 15,60", он(родитель) и платит... Но в оборотке привязка идет к л/с, а ребенок может "болтаться" по разным группам.. При чем в течении расчетного периода... Оплата - в таблице оплат, по пачкам и л/с.. Т.е. оплата идет НА Л/С, а не на группу..Я в данном варианте использую для показа оплаты и входящего ту группу, которая была последней в предыдущем периоде..Но есть вариант, когда в табеле посещаемости перевод идет с первого дня следующего периода... И как тут можно обойтись без ТЕМП-таблицы ? не представляю..Вот если бы при переводе давался новый Л/С - тогда бы этой проблемы не было...Но тогда - куча платежек лишних... Да и не очень удобно...Так все-таки л/с хочешь не хочешь, а запоминаешь... Табель дается в бумажном виде "от руки" написанному...

← →
Sergey13 © (2005-06-03 14:49) [23]

2[22] вп (03.06.05 14:35)
> И ему однохерственно
Но если тебе не так же, ты вполне можешь разнести платеж по разным группам и группировать по реквизиту (составному) л/с-группа. Вот тебе и разные л/с фактически.

← →
вп (2005-06-03 14:57) [24]

А входящий остаток ? Остаток то "висит" на л/с...И как разнести платеж по разным группам, если ты еще даже не занешь, где, в какой группе был этот л/с ?

← →
Sergey13 © (2005-06-03 15:51) [25]

2 [24] вп (03.06.05 14:57)
Огроворюсь сразу. Я не утверждаю, что то что я говорю - истина. Просто то что мне в голову пришло, а она у меня занята сейчас другим. 8-)

Я же говорил тебе про пред/пост оплату. Это надо учитывать естественно. Не пойдет так не пойдет.
Я не принципиальный противник ТЕМПов. Просто пытался дать полезные (надеюсь) советы. Не получилось - жаль.
Я отключаюсь.

← →
stud © (2005-06-03 16:09) [26]

> Т.е. оплата идет НА Л/С, а не на группу

что вообще такое ГРУППА? что она характеризует, что ее необходимо отображать в очете?

← →
вп (2005-06-03 16:20) [27]

Группа детского сада.. Ясельная №1 10 часовая, Средняя № 2 12 часовая...Санаторные группы и тд.

← →
stud © (2005-06-03 16:42) [28]

> а ребенок может "болтаться" по разным группам

непонятно конечно, организационный бардак программными средствами не разруливается.
платежка привязана к л/с, но сумма платежа зависит от того где находится (находился) ребенок? если да - значит на этапе выписки платежки можно однозначно определить в какой группе находится ребенок
у тебя же учитывается в какой группе находится ребенок?

← →
stud © (2005-06-03 16:44) [29]

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

← →
вп (2005-06-03 17:17) [30]

Учитывается.. Но ты спутал платежку с обороткой... И это не бардак... Ребенка по возрасту могут перевести в другую группу, родители попросили (напримр, с 10-часовой на 12-ти часовую - не могут раньше забрать..А это занчит, что возрастает цена дня (ребенок не только обедает, но и ужинает)).. И т.д. Конечно, если при переводе открывать новый л/с - проблем нет...Но.. это не удобно...По одной простой причине... Платят в течении месяца, а табеля дают - в конце (сколько дней ребенок посещал ту или иную группу)..Потому и разносят оплату по пачкам на л/с... Все это оправдано...Да и напечатать ОДНУ платежку или ДЕСЯТЬ - разница большая.. хотя я и преувеличил.. но..

← →
вп (2005-06-03 17:22) [31]

А вообще я спроси это.. :-)

> вп (03.06.05 13:09) [18]
> Таблица Л/с
> Л/с Вх Оплата начисленно Исх
> 100 1,20 5,00 10,00 6,20
>
> Причем начисленно: по 1-й группе 2,00 по 2-й 3,00 по 3-й
> 5,00
> Нужно получить оборотку:
> л/с Вх Оплаченно Начисленно Исх
> Группа 1
> 100 1,20 5,00 2,00 -1,80
> ...
> Итого по группе
> ГРуппа 2
> 100 0,00 0,00 3,00 3,00
> ...
> Итого по группе
> Группа 3
> 100 0,00 0,00 5,00 5,00
> ...
> Итого по группе
>
> Итого по организации
> Как это получить запросом/ХП ?

← →
stud © (2005-06-03 17:26) [32]

тут сложно чтолибо сказать, т.к. не понятна структура хранимых данных и порядок оформления документов

← →
carmen © (2005-06-03 19:51) [33]

Лично я пишу АРМы для водоканала, РЕМ, Газа, ЖЕка. Каждая база содержит историю движения начисления, оплати, субсидий, контрольних обходов, льгот и т.п. В каждой базе более 500 тис. записей (проги работают около 5 лет). Все отчеты, в т.ч. и развернутую сальдовку (вся информация о клиенте, начисления, оплаты, коректировки и т.д.) по всех абонентах (23тис.-51тис. абонентов) формирую без всяких временных таблиц используя хранимые процедуры. Время выболнения всреднем 5-15 секунд.

← →
вп (2005-06-06 09:09) [34]

> carmen © (03.06.05 19:51) [33]
> Лично я пишу АРМы для водоканала, РЕМ, Газа, ЖЕка. Каждая
> база содержит историю движения начисления, оплати, субсидий,
> контрольних обходов, льгот и т.п. В каждой базе более 500
> тис. записей (проги работают около 5 лет). Все отчеты, в
> т.ч. и развернутую сальдовку (вся информация о клиенте,
> начисления, оплаты, коректировки и т.д.) по всех абонентах
> (23тис.-51тис. абонентов) формирую без всяких временных
> таблиц используя хранимые процедуры. Время выболнения всреднем
> 5-15 секунд.

Согласен... Но у вас привязка (по идеи) только к л/с... А у меня еще и группам... При этом оплата идет на л/с, а оборотка - по группам и л/с...И показать я должен и оплату, и входящий остаток, и исходящий остаток Да, и отчет делает менее 2-х секунд.
И все же, упрощу задачу.. :-). Как с помощью запроса/ХП получить такой набор (к примеру):
л/с вх оплачено начисленно исх
100 1,20 5,00 10,00 6,20
100 0,00 5,00 6,00 1,00
100 0,00 5,00 4,00 -1,00

При этом на л/с должно "упасть" в исходящий 6,20... Для каждой строки различие - только по группе..А сам л/с - одна и та же запись в таблице л/с

← →
stud © (2005-06-06 09:23) [35]

> Как с помощью запроса/ХП получить такой набор (к
> примеру):

тут обычный селект, с условием по л/с=100, чтобы получить суммарные данные
select л/с, сум(вх), сум(оплачено), сум(начислено), сум(исх) from л/с where л/с=100
group by л/c

← →
stud © (2005-06-06 09:25) [36]

> А вообще я спроси это.. :-)

а где здесь в исходных данных фигурирует группа?

>> Л/с Вх Оплата начисленно Исх
> > 100 1,20 5,00 10,00 6,20

← →
Виталий Панасенко (2005-06-06 09:47) [37]

← →
Ярослав (2005-06-06 09:47) [38]

Сборка мусора вроде помогла, пока тормозов не видно.
А на счет того что использовать for select или временную таблицу, это зависит от условий, т.е. у меня в одном for select имеется вложенный и как не крути он там нужен, так вот временная таблица его заменяет, за счет чего и увеличивается производительнось причем весьма заметно. И как в этом случяе без нее обойтись? Конечно можно менять логику базы вообще, но зачем, в MS SQL есть временные таблицы и ими все вовсю пользуются, их даже в книгах по MS SQL рекомендуют использывать для избавления от курсоров (тот же for select). Ни чего плохого я в них не вижу.

> На сколь я вижу, тут группа фигурирует...

если не секрет где?

> так вот временная таблица его заменяет

а если view создать вместо таблицы?

← →
Ярослав (2005-06-06 10:07) [40]

>> а если view создать вместо таблицы?
А это к чему? view вместо временной таблицы куда помещаются данные из for select, это как?

У меня отчеты формируются с привязкой к л/с, льготе, подстанции, КТП, линии .... Чем это не группы?

[38]
Внутрь FOR SELECT можно вложить сколько угодно дополнительных мелких (и не только) запросов. При этом не обязательно втискивать их в условие самого FOR SELECT, часто удобнее внутрь обработки его результата.
Пример с MSSQL некорректен, ибо:
1. MSSQL имеет спец механизмы обработки временных таблиц, а FB - нет
2. FB - версионник, т.е. хранит много версий одной записи, а MSSQL - блокировочник, т.е. только текущую
3. в MSSQL реализация временных таблиц - это практически синоним для таких вот курсоров. "Общественность" настояла, не желая связываться с именованными курсорами.

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

← →
Ярослав (2005-06-06 11:23) [44]

>> Desdechado © (06.06.05 10:56) [42]
>> Внутрь FOR SELECT можно вложить сколько угодно дополнительных мелких (и не только) запросов. При этом не обязательно втискивать их в условие самого FOR SELECT, часто удобнее внутрь обработки его результата.

Все это я знаю....

>> 1
А жаль, но и в IB/FB их без труда можно сделать.
>> 2
Ну и что, это здесь причем??? Ко временным таблицам то как относится?
>>
Это вообще о чем? Какой еще синоним? И какая разница имеет курсор имя или нет?

> for select

зачем делать селект, потом эти данные записывать в таблицу из которой потом делать селект?
вынести этот селект в качестве формирующего view

> Ко временным таблицам то как относится?

нету в фб временных таблиц! это самая обычная таблица со всеми вытекающими последствиями.
и если она часто меняется то "мусора" в базе будет достаточно, чтобы тормозилась работа

← →
Ярослав (2005-06-06 11:48) [47]

>> stud © (06.06.05 11:41) [45]
Не селект а for select т.е. с обработкой + каждый раз новые входные условия, а причем тут view?

[44]
2 - самое прямое отношение - накопление старых версий записей (мусора), из-за чего ветка и возникла
3 - именованный или нет курсор обычно разницы нет, просто для именованных в MSSQL сделали альтернативное понятие "временная таблица", что по сути почти то же самое в контексте сессии пользователя

и не надо на дыбы становиться. мы тебе помочь хотим. ты же за этим сюда пришел?

> а причем тут view

view не будет "мусорить" как твоя таблица, т.е. один из факторов торможения будет устранен.
и в обшем получается, что обсуждаем то - не видя что))
поэтому не можем понять что у тебя есть и почему ты отказываешся от того, что предлагают

← →
Ярослав (2005-06-06 12:25) [50]

>> обсуждаем то - не видя что
Это точно, я понимаю что такое view и с чем его едят, но использовать его в данном случае не возможно. Временная таблица действительно сильно мусорит.
В Desdechado © (01.06.05 10:52) [9]
прозвучало "select count(*) from vremennayatablica" дак я вставил это в конце XP и теперь жду произойдут ли изменения т.е. станет ли база тормозить, результат будет известен самое малое через неделю, но после Backup/Restore может и месяц, если тормозить будет, буду дамать как логику менять. Постоянный Backup/Restore не выход, сервер во вне рабочее время выключаеться. А самому его делать даже раз в месяц это не дело.
Но пока буду ждать, когда еще такой эксперемент представится провести на реальной базе...

← →
Ярослав (2005-06-06 12:27) [51]

> "select count(*) from vremennayatablica"

на количество мусора это не повлияет

> но использовать его в данном случае не возможно.

уверен что возможно. твоя таблица формируется на основании существующих данных, т.е. по сути это много селектов результат которых будет не запись во временную таблицу а формирование этого самого просмотра. т.е. в простешем случае должно исчезнуть выражение insert into ......

База FB тормозит Найти похожие ветки