[Cramac]

Всем привет. 

Есть ли решение по оптимизации архивных таблиц? Или удалять все старше года?

 

П.С. утм 5.3-003, база на 180гб.

[taf_321]

По законодательству РФ данные нужно хранить минимум три года + данные за текущий (в максиме получается данные за четыре года). То, что уже нагенерено лучше не трогать. Может имеет смысл обратить внимание на то, что генерит слишком много записей? К примеру, увеличить промежуток агрегации (ЕМНИП, за это отвечает параметр traffic_agregation_interval). И еще помедитировать над количеством списаний в течении расчетного периода для типа списания "в течении всего расчетного периода" (flow_discounts_per_period)

[Cramac]

Спасибо, посмотрю. Списание у нас раз в сутки.

еще смотрел таблицы, есть дубли записей.

 

p.s. Что то не нашел таких опций.

[taf_321]

Указанные параметры задаются через админку: Настройка -> Настройки системы. Если их нет, то можно добавить самостоятельно. У нас тарифные планы все исключительно безлимитные, поэтому параметр traffic_agregation_interval выставлен в 7200. В итоге в таблицы discount_transactions_all и discount_transactions_iptraffic_all записи вносятся раз в два часа по каждому активному клиенту.

 Главным засирателем базы у меня был родной нетуповский радиус, который на каждый Acc-Update вместо банального UPDATE в базе генерил Session-Stop - Session-Start. Разрабам по этому поводу в свое время писал, и даже тикет создавался с развестистой перепиской, но они поклали прибор объявив такое поведение правильным. В итоге переехал на FreeRADIUS.

[Cramac]

Да, радиус у нас их используется.

flow_discounts_per_period=64

 

raffic_agregation_interval Было 900, увеличил.

 

я уже думаю, может просуммировать записи за день и лишнее удалить

[taf_321]

Содержимое discount_transactions_all и discount_transactions_iptraffic_all я бы не рекомендовал трогать и менять, так как можно получить в итоге кривые данные при генерации отчетов. Если старые данные уже отсеяны в архивные таблицы, то пусть лежат. Реально они занимают не так и много места.