[mazzy]

Часто жалуются на очень быстрый рост базы данных при работе Microsoft Axapta (до 10 Гб в месяц). Дело в том, что Аксапта при работе создает различные логи. Эти логи помогают выполнять "разбор полетов", но никак не влияют на работу самой Аксапты. В этом совете приводится список таблиц, которые можно безболезненно очищать при работе Аксапты. Благодарю Вадима Гончаренко и Максима Горбунова за ценные дополнения к этому совету.

Подробнее...
http://axapta.mazzy....growthsolution/

[serge kotov]

Спасибо, Сергей за очень полезные советы по очистке таблиц.

В нашем случае суммарный "вес" всех указанных таблиц (за исключением InventSettlement и исторических данных в таблицах закупок и продаж) в общем росте базы данных составляет приблизительно 15 % от общего объема.

Это действительно не мало в абсолютном исчислении, поэтому мы в рабочей базе данных также периодически чистим наиболее существенные из них (в нашем случае это SalesParmLine и SysDataBaseLog).

Выравнивание влево также может дать в нашем случае приблизительно 5 % экономии.

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

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

[Vadik]

serge kotov (03.12.2004, 12:51) писал:

В нашем случае суммарный "вес" всех указанных таблиц (за исключением InventSettlement и исторических данных в таблицах закупок и продаж) в общем росте базы данных составляет приблизительно 15 % от общего объема.
..

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

Сергей, у вас ОЧЕНЬ сильно кастомизирована SalesLine . Количество записей в ней тоже, разумеется, недетское

Кстати, а что мешает использовать для анализа не ее, а, например, CustInvoiceTrans?

[serge kotov]

Исторические реалии во-первых Не раз уж мысль проскальзывала, эх если бы делать всё сначала, то уж тогда бы...

Во-вторых, сложность с текущими отгрузками.

А в принципе согласен с этой идеей.

[mazzy]

serge kotov (03.12.2004, 11:51) писал:

Выравнивание влево также может дать в нашем случае приблизительно 5 % экономии.

Выравнивание влево дает экономию в индексах.
Индексы занимают меньше экстентов, следовательно меньше медленных дисковых операций. К тому же больше попаданий в кэш.

[serge kotov]

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

[mazzy]

Да, исследования не помешали бы.

В свое время, еще на 2.5 изменение выравнивания уменьшило базу на 30%. Но это были времена, когда откорреспондированные проводки в LedgerTrans не группировались, когда LedgerTrans была самой емкой таблицей...

[Vadik]

serge kotov (03.12.2004, 16:21) писал:

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

Это один из тех "кирпичей", из которых складывается общая производительность. Что касается места, занимаемого под данные и индексы, было немного здесь. Что касается скорости обработки, то в вашей БД параметр "процент попаданий в кэш" смысла особого не имеет, так как самые большие таблицы целиком в памяти сидят - чтение (Disk reads) практически отсутствует. Подождите еще год - размер БД удвоится, вернемся к этой теме

[mazzy]

Vadik (03.12.2004, 15:32) писал:

Что касается скорости обработки, то в вашей БД...

Комментарий по поводу ВАШЕЙ БД.
Речь идет об этом случае http://axapta.mazzy....axapta_itanium/

А вообще говоря, процент хитов - важный показатель, за который стоит биться.

[serge kotov]

mazzy (03.12.2004, 15:47) писал:

mazzy:
А вообще говоря, процент хитов - важный показатель, за который стоит биться.

vadik:
Подождите еще год - размер БД удвоится, вернемся к этой теме

Сейчас кстати состояние счетчика SQL Server\Buffer Manager\Buffer Cache Hit Ratio крутится вокруг 99.85 +-0.03 Так что настроение

Надеюсь через год не вернемся, через 9 месяцев уже запланирован второй в связку Вот только SQL SERVER 2000 EE похоже может адресовать не более 64 GB

[komar]

Да, а должностных лиц вообще искоренять надо. Вместе с кривыми постановщиками и программистами.

[serge kotov]

serge kotov (03.12.2004, 16:48) писал:

Вот только SQL SERVER 2000 EE похоже может адресовать не более 64 GB

Дополнение: SQL Server 2000 64-bit может адресовать 512 GB к счастью.

http://www.microsoft...fo/overview.asp