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

[Writer]

Вероятно, у каждого админа, эксплуатирующего базу данных возникает проблема, быстро растущий объем данных. Axapta так же не лишена данной проблемы. Мое недолгое изыскание по уменьшению базы привели меня к следующим выводам:
объем можно уменьшить за счет удаления разнесенных журналов из таблицы LedgerJournalTrans, InventJournalTrans стандартными средствами Axapta;
также не мешает почистить историю по номерным сериям;
периодически очищать журнал баз данных;
журнал регистрации прихода товара;
удалять разнесенные заказы и закупки и т.д.;
на крайний случай отключить часть индексов.
Но это все мелочи. На которые в принципе можно сильно не обращать внимания. Зато есть всем знакомая табличка InventSettlement, размер ее оказался равным 50% от размера всей базы. Итак, база 5Гб, табличка 2,1 Гб (вместе с индексами), вот это пожалуй камень преткновения. Зачем она нужна, все надеюсь знают. Сам собой напрашивается вопрос, как ее уменьшить. Первый и наиболее безболезненный способ это удалить прямой и обратный ваучер по процедурам пересчета или коррекции. Остаются ваучеры пересчета и закрытия, которые никто не отменял. Их тоже можно удалить, но это надо сделать ювелирно. Если кто экспериментировал с этой таблицей прекрасно знает, что вмешательство в нее может привести к тому, что пересчета и закрытия у Вас больше не будет. Поделитесь господа своими соображениями как наиболее корректно удалить данные из этой таблички, может кто еще, что большое предложить удалить безболезненно.

[Lazy_Tiger]

А чего ж страшного в базе объемом в 5гб? было б там хотя б 500, да и то я б не стал удалять данные, я бы занялся тюнингом, раскидал бы таблички и индексы по дискам и т.д. (см. MS SQL Books Online).

А удалять данные на мой взгляд некрасиво, да и я бы на Вашем месте не брал на себя такую ответственность.

[mazzy]

Quote:

Изначально опубликовано Writer
как наиболее корректно удалить данные из этой таблички, может кто еще, что большое предложить удалить безболезненно.

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

А какая версия Аксапты?
На самом деле есть более тяжелые таблицы.
SalesParmLine+SalesParmTable и PurchParmLine+PurchParmTable
В 3.0 обработка по очистке выведена в главное меню в периодические операции.

Согласен с тем, что журналы, заказы и закупки суть - черновики.
И в нормальном режиме должны удаляться после того как разнесены.
(Кстати, обратите внимание на SalesTableDelete, SalesLineDelete и то же самое для Purch...)

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

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

[Writer]

Quote:

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

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

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

Quote:

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

Axapta 2.5 SP5HF1

Quote:

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

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

Quote:

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

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

Quote:

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

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

[EVGL]

Quote:

Тут надо EVGL спросить на каких он данных проверял скорость работы его запроса.

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

P.S. Ведь говорили мне: не ставь комментарии.

[mazzy]

Quote:

Изначально опубликовано Writer
Зачем хранить данные по сопоставлениям прошлых периодов, например прошлого года, когда по этим данным уже никто не будет отменять пересчет или закрытие.

А чтобы коррекция не ругалась.
Коррекция должна пересчитать inventTrans.CostAmountAdjusment в соответствии с содержимым InventSettlement.

Думаю, что удаление IS повлечут массу других побочных эффектов.
Надо проверить. Я бы эту таблицу не трогал.

Нашу птичку попрошу не обижать

[Writer]

Quote:

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

А чтобы коррекция не ругалась.
Коррекция должна пересчитать inventTrans.CostAmountAdjusment в соответствии с содержимым InventSettlement.
Нашу птичку попрошу не обижать

Я уже повторюсь, посмотри внимательно алгоритм и увидишь что CostAmountAdjusment + CostAmountPosted сверяются с балансом IS втом случае если ValueOpen = да в противном случае запрос по пересчету никак не затрагивает лоты с признаком нет и уж тем более сравнивает с IS. Если бы такое было то боюсь пересчет бы шел долго - долго, а програмеры бы жили мало-мало . Вообщем похоже, что эту проблем надо исследовать эмпирическим путем, и посмореть что в результате получиться.

P.S. А птичку я не трогаю, я ее можно сказать уважаю. Я вопрос задал и получил ответ, в принципе который и ожидал. Хотя есть задумки как оптимизировать книгу покупок, но это все надо проверять. Я так понимаю EVGL шел по пути того как это сделать безошибочно и применимо для всех случаев, а в каждом конктретном случае уже можно смотреть как применить оптимизацию. Вообщем зри у корень (Козьма Прутков)

[mazzy]

Спасибо. Надо подумать.

Quote:

Изначально опубликовано Writer
Я уже повторюсь, посмотри внимательно алгоритм и увидишь что ... надо исследовать эмпирическим путем, и посмореть что в результате получиться.

Так смотреть алгоритм или эмпирическим?

[Writer]

Quote:

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

Так смотреть алгоритм или эмпирическим?

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

[Dm]

Что тут говорить?
я нас база 250 Гиг. Тюнинг идет постоянно.
Сервер 2 Ксеона по 2,2, скази 15-ти тысячники и памяти 16 гиг.
И все работает и не жужжит.

Правда не на Аксапте, но скоро начинаем внедрять, и данные нужны не за месяц, а за два года.
А текущая база всего-то полтора года.

[komar]

Quote:

Изначально опубликовано Dm
Правда не на Аксапте, но скоро начинаем внедрять, и данные нужны не за месяц, а за два года.
А текущая база всего-то полтора года.

А откуда Вы недостающие полгода возьмете??

[ТРЕНЕР]

Он же сказал:
<b>не на Аксапте, но <font color="#ff0000">скоро</font> начинаем внедрять</b>
Вот это "скоро" и есть полгода. Хотя в реальности, думаю, будет через год-полтора, как это обычно бывает. Место-то на диске пока есть

[Волчара]

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

Новые люди, новый проект, новые деньги, новая слава!!! Ура!!!
Кто не спрятался, я не виноват.

[Елена Сысовская]

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