Уменьшение базы данных Axapta

[Writer]

Цитата:

Изначально опубликовано mazzy

Из ЭТОЙ таблички - никак.

Вот тут я с тобой не согласен. Зачем хранить данные по сопоставлениям прошлых периодов, например прошлого года, когда по этим данным уже никто не будет отменять пересчет или закрытие. Получается мертвый груз. Тем более что у нас партионный учет и когда партия полностью израсходована, то она полностью закрыта, второго прихода в другом периоде по данной партии уже быть не может (наша идеология такая). Поэтому для пересчета баланса по данной партии не будет (алгоритм пересчета и закрытия складов устроен так). Значит, данные можно удалять. Вообще обрати внимание на такую вещь в системе в таблице InventTrans как ValueOpen, как только она становиться нет, то и в пересчете и закрытии данный лот не участвует. Соот-но можно очистить все записи в InventSettlement c RecId равным этому лоту. Естественно что нужно учитывать дату закрытия провдки и выбрать разумный лаг времени, раньше которого не подчищать данные.

Цитата:

А какая версия Аксапты?

Axapta 2.5 SP5HF1

Цитата:

На самом деле есть более тяжелые таблицы.
SalesParmLine+SalesParmTable и PurchParmLine+PurchParmTable

В нашем случае они не такие тяжелые

Цитата:

Есть еще один камень. Если включена корреспонденция, то самая тяжелая таблица - LedgerTrans. А если раздута сверх меры финансовая аналитика, то LedgerBalancesDim...

Ты будешь приятно удивлен, но проводки у нас все пишутся, и эксплуатируется все, (закупки, заказы, производство, расчеты с персоналом, касса, и прочее) и баланс мы формируем из Axapta и все это весит сейчас в LedgetTrans каких то 180Мб

Цитата:

Согласен c Lazy_Tiger, 5Гиг - это еще небольшая база. Надо не резать, надо тюнить. Если вас интересует быстродействие, начните со сбора статистики и мониторинга длинных запросов в Аксапте, а не с обрезания.

Частично с этим я согласен. Постоянно оптимизируем различные отчеты и запросы, пишем доп. фичи для ускорения формирования сложных отчетов, кстати никто не занимался оптимизацией запроса формирования книги покупок или продаж, вот там запрос!!! Тут надо EVGL спросить на каких он данных проверял скорость работы его запроса. Просто ждать формирования книги продаж 6 часов и это на 2-х процессорном Xeone с винтами по 15 тыс. оборотов каждый (быстрее чем SCISI винты) это я считаю долго (при этом процессора почти в 80% загрузке).
Ну и как гласит наш любимый Microsoft максимальную производительность мы получим только тогда, когда размер базы будет меньше чем размер оперативной памяти. Вот отсюда и появляется стремление уменьшать БД.