Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.07.18;
Скачать: [xml.tar.bz2];

Вниз

База 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]


> stud ©   (06.06.05 09:25) [36]

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

> вп   (03.06.05 17:22) [31]


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

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


 
stud ©   (2005-06-06 09:59) [39]


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

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


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

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


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

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



Страницы: 1 2 вся ветка

Форум: "Базы";
Текущий архив: 2005.07.18;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.56 MB
Время: 0.054 c
3-1117710731
andrex
2005-06-02 15:12
2005.07.18
Отмена изменений


8-1111194529
Tga
2005-03-19 04:08
2005.07.18
Что в tga отвечает за прозрачность ?


14-1119623829
WondeRu
2005-06-24 18:37
2005.07.18
Ошибка "Класс TQuery не найден"


8-1111347889
COOLer
2005-03-20 22:44
2005.07.18
Помогите узнать информацию о файлах


14-1119360078
вразлет
2005-06-21 17:21
2005.07.18
LOL





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский